Security Accounts Manager (SAM): a Windows hitelesítési adatbázisának működése

A Windows operációs rendszer mélyén, a felhasználói fiókok és a biztonsági beállítások labirintusában egy alapvető fontosságú komponens működik csendben, de rendkívül hatékonyan: a Security Accounts Manager, röviden SAM. Ez a kulcsfontosságú adatbázis a Windows hitelesítési rendszerének gerincét adja, felelős a helyi felhasználói fiókok, a csoporttagságok és a jelszó-hash-ek tárolásáért. Anélkül, hogy tudnánk róla, minden egyes alkalommal, amikor bejelentkezünk egy Windows alapú számítógépbe, vagy egy program hozzáférést kér egy erőforráshoz, a SAM kulcsszerepet játszik a folyamatban. Megértése nem csupán a rendszergazdák és biztonsági szakemberek számára elengedhetetlen, hanem mindenki számára, aki mélyebben bele szeretne látni a Windows belső működésébe és a digitális biztonság alapjaiba.

Ez a cikk részletesen bemutatja a SAM adatbázis működését, felépítését, a benne tárolt információk típusait, valamint azt, hogy miként járul hozzá a Windows biztonságához. Kitérünk a hitelesítési folyamatokra, a jelszó-hash-ek tárolására, a biztonsági azonosítók (SID-ek) szerepére, valamint a SAM-et érintő potenciális támadásokra és a védekezési lehetőségekre is. Célunk, hogy egy átfogó, mégis könnyen érthető képet adjunk erről a komplex, de nélkülözhetetlen rendszerelemről, kiemelve annak kritikus szerepét a modern operációs rendszerek biztonságában.

A Security Accounts Manager (SAM) alapjai: Mi is ez pontosan?

A Security Accounts Manager (SAM) egy belső adatbázis a Microsoft Windows operációs rendszerekben, amely a helyi felhasználói fiókokra és csoportokra vonatkozó biztonsági információkat tárolja. Ez az adatbázis az operációs rendszer telepítésével jön létre, és minden olyan Windows rendszeren megtalálható, amely képes helyi felhasználók kezelésére, legyen szó egy önálló munkaállomásról vagy egy tartományhoz csatlakoztatott szerverről. A SAM elsődleges feladata, hogy egy központi helyen tárolja azokat az adatokat, amelyek alapján a Windows hitelesíti a felhasználókat és meghatározza az erőforrásokhoz való hozzáférési jogosultságaikat.

A SAM nem csupán a felhasználóneveket és jelszavakat tárolja, hanem jóval komplexebb információkat is magában foglal. Ide tartoznak például a felhasználók egyedi biztonsági azonosítói (SID-ek), a csoporttagságok, a fiók beállításai (pl. fiók letiltva, jelszó lejárt), valamint a jelszavak kriptográfiai hash-ei. Fontos megjegyezni, hogy a SAM soha nem tárolja a jelszavakat nyílt szöveges formában, hanem mindig valamilyen hash-algoritmus eredményeként kapott, visszafordíthatatlan értéket, ami a biztonság alapvető pillére.

Történelmileg a SAM a Windows NT alapú operációs rendszerekkel jelent meg, és azóta is a helyi hitelesítés központi eleme. Bár a tartományi környezetekben az Active Directory (AD) veszi át a felhasználói fiókok központi kezelését, a SAM továbbra is létfontosságú marad minden egyes tartományi taggépen, mivel az kezeli a helyi rendszergazdai fiókokat és azokat a felhasználókat, akik nem tagjai a tartománynak, vagy a tartományi fiókjaik mellett helyi fiókokat is használnak.

A SAM tehát egy olyan kritikus komponens, amelynek integritása és védelme alapvető fontosságú a Windows rendszer általános biztonsága szempontjából. Bármely kompromittálása súlyos biztonsági kockázatokkal járhat, beleértve a jogosulatlan hozzáférést a rendszerhez és az adatokhoz. Éppen ezért a Microsoft számos védelmi mechanizmust épített be a SAM adatbázis és a benne tárolt információk védelmére, amelyekről a későbbiekben részletesebben is szó lesz.

A SAM adatbázis felépítése és kulcsfontosságú elemei

A SAM adatbázis nem egy egyszerű szöveges fájl, hanem egy strukturált adatgyűjtemény, amely a Windows rendszerleíró adatbázisának (Registry) egy speciálisan védett részén található. Pontosabban a HKEY_LOCAL_MACHINE\SAM kulcs alatt helyezkedik el, de ez a kulcs alapértelmezés szerint nem közvetlenül hozzáférhető a legtöbb felhasználó számára, még a rendszergazdák számára sem. Ennek oka a benne tárolt érzékeny információk védelme. Az adatbázis több alklucsot és értéket tartalmaz, amelyek mind a felhasználói fiókok és csoportok biztonsági attribútumaihoz kapcsolódnak.

A SAM adatbázis legfontosabb elemei a következők:

• Felhasználói fiókok (User Accounts): Minden egyes helyi felhasználói fiókhoz tartozik egy bejegyzés a SAM-ben. Ez a bejegyzés tartalmazza a felhasználó nevét, egyedi azonosítóját (SID), a jelszó-hash-ét, a fiók állapotát (aktív/inaktív, zárolt), a jelszó lejáratának dátumát, és egyéb fiókspecifikus beállításokat.
• Csoportok (Groups): A SAM adatbázis a helyi csoportokat is tárolja, például a „Rendszergazdák”, „Felhasználók” vagy „Vendégek” csoportokat. Minden csoportnak van egy egyedi SID-je, és a csoporttagságok is itt kerülnek rögzítésre. Amikor egy felhasználó egy csoport tagja, az adott csoport jogosultságait is megörökli, ami egyszerűsíti az engedélyek kezelését.
• Jelszó-hash-ek (Password Hashes): Ez az egyik legérzékenyebb információ a SAM-ben. A felhasználói jelszavak soha nincsenek nyílt szöveges formában tárolva. Ehelyett a Windows egy egyirányú kriptográfiai hash-függvényt alkalmaz a jelszavakra, és az így kapott hash-értéket tárolja. A bejelentkezéskor megadott jelszót is hash-elik, és az eredményt összehasonlítják a SAM-ben tárolt hash-sel. Ha a két érték megegyezik, a hitelesítés sikeres. A SAM jellemzően NTLM hash-eket tárol, és régebbi rendszereken LM hash-eket is tárolhatott.
• Biztonsági azonosítók (Security Identifiers – SID-ek): Minden felhasználói fiók, csoport és számítógép egyedi, globálisan egyedi azonosítóval rendelkezik a Windows környezetben. Ezek a SID-ek alapvető fontosságúak a jogosultságok kezelésében, mivel a Windows nem a felhasználónevek, hanem a SID-ek alapján azonosítja a biztonsági entitásokat. A SID-ek struktúrája és jelentősége kulcsfontosságú a rendszer biztonságának megértésében.

A SAM adatbázis fizikai fájljai a %SystemRoot%\System32\config\SAM és %SystemRoot%\System32\config\SECURITY útvonalon találhatók, de ezeket a fájlokat az operációs rendszer folyamatosan zárolva tartja, amíg a Windows fut. Ez megakadályozza a közvetlen hozzáférést és manipulációt futásidőben, ami egy kritikus biztonsági intézkedés. Az adatbázishoz való hozzáférés kizárólag a Local Security Authority (LSA) alrendszeren keresztül történhet, amely egy védett folyamatként fut a rendszeren.

A SAM adatbázis szerkezete és a benne tárolt adatok komplexitása rávilágít arra, hogy miért olyan alapvető fontosságú a Windows biztonsága szempontjából. A benne található információk birtokában egy támadó potenciálisan teljes hozzáférést szerezhet a rendszerhez, ezért a SAM védelme kiemelt prioritást élvez minden Windows környezetben.

A SAM adatbázis nem csupán egy jelszótár; ez a Windows helyi biztonsági identitásainak és jogosultságainak központja, amely minden egyes bejelentkezés és hozzáférési kérelem alapját képezi.

A hitelesítési folyamat a SAM és az LSA tükrében

Amikor egy felhasználó megpróbál bejelentkezni egy Windows számítógépbe, vagy egy szolgáltatás hitelesítést igényel, egy összetett folyamat indul el, amelynek kulcsszereplője a Local Security Authority (LSA) és a SAM adatbázis. Az LSA egy védett alrendszer, amely felelős a helyi biztonsági házirendek betartatásáért, a felhasználói és csoportazonosítók kezeléséért, valamint a hitelesítésért és az engedélyezésért.

Nézzük meg lépésről lépésre, hogyan zajlik a hitelesítési folyamat:

1. Bejelentkezési kísérlet: A felhasználó megadja a felhasználónevét és jelszavát a bejelentkezési képernyőn (vagy egy alkalmazás küld hitelesítési adatokat).
2. Kérés továbbítása az LSA-nak: A grafikus alrendszer (Winlogon) vagy az alkalmazás továbbítja ezeket az adatokat az LSA alrendszernek.
3. Hitelesítési csomagok bevonása: Az LSA nem maga végzi el a jelszó ellenőrzését, hanem átadja a feladatot egy vagy több hitelesítési csomagnak (Authentication Package). A Windowsban a leggyakoribb helyi hitelesítési csomag az MSV1_0, amely a SAM adatbázisban tárolt információkat használja.
4. Jelszó-hash generálása: A hitelesítési csomag fogja a felhasználó által megadott jelszót, és ugyanazzal a hash-algoritmussal (pl. NTLM) hash-eli, amellyel a jelszót eredetileg a SAM-be tárolták.
5. SAM adatbázis lekérdezése: A hitelesítési csomag lekérdezi a SAM adatbázist a megadott felhasználónévhez tartozó tárolt jelszó-hash és a felhasználói fiók egyéb attribútumai (pl. fiók állapota, jelszó lejárat) iránt.
6. Hash-ek összehasonlítása: A generált hash-t összehasonlítják a SAM-ből kiolvasott tárolt hash-sel.
7. Eredmény visszajelzése:
   • Ha a hash-ek megegyeznek, és a fiók aktív, az LSA sikeres hitelesítést jelent.
   • Ha a hash-ek nem egyeznek, vagy a fiók zárolva van/lejárt, az LSA sikertelen hitelesítést jelez.
8. Biztonsági token létrehozása: Sikeres hitelesítés esetén az LSA létrehoz egy biztonsági tokent (Access Token) a felhasználó számára. Ez a token tartalmazza a felhasználó SID-jét, a csoportok SID-jeit, amelyeknek a felhasználó tagja, és a felhasználóhoz rendelt jogosultságokat. Ez a token lesz az alapja minden további hozzáférési kérelem engedélyezésének a rendszeren belül.

Ez a folyamat alapvetően biztosítja, hogy a jelszavak soha ne legyenek nyíltan leleplezve a rendszeren belül, még a hitelesítés során sem. Az LSA és a SAM közötti szoros integráció, valamint az LSA védett környezetben való futása kritikus fontosságú a Windows biztonságának fenntartásában. Az LSA titkok (LSA Secrets) további védelmet nyújtanak bizonyos érzékeny információk, például a szolgáltatások jelszavai vagy a gyorsítótárazott tartományi hitelesítő adatok tárolásához, tovább erősítve a rendszer ellenállását a támadásokkal szemben.

Fontos megérteni, hogy bár a SAM a helyi fiókokat kezeli, egy tartományhoz csatlakoztatott számítógépen az LSA az Active Directoryval is kommunikálhat a tartományi fiókok hitelesítéséhez. Ebben az esetben a SAM továbbra is kezeli a helyi fiókokat, de a tartományi hitelesítés a tartományvezérlőkön történik, ahol az Active Directory adatbázis (NTDS.DIT) tárolja a tartományi felhasználók adatait.

Jelszó-hash-ek a SAM adatbázisban: LM, NTLM és a modern megközelítések

A jelszavak tárolásának módja a SAM adatbázisban kritikus fontosságú a Windows biztonsága szempontjából. Ahogy már említettük, a jelszavak soha nincsenek nyílt szöveges formában tárolva; ehelyett kriptográfiai hash-függvények eredményeként kapott, visszafordíthatatlan hash-értékek kerülnek mentésre. A Windows története során különböző hash-algoritmusokat használtak, amelyek közül kettő emelkedik ki: az LM hash és az NTLM hash.

LM hash (LAN Manager hash)

Az LM hash a Windows operációs rendszerek korai verzióiban (például Windows 95, 98, NT 4.0) használt jelszó-hash algoritmus volt. Rendkívül sebezhetőnek bizonyult, és ma már elavultnak számít. A sebezhetőségei a következők voltak:

• Kisbetűk átalakítása nagybetűvé: Az LM hash először az összes kisbetűt nagybetűvé alakította, ami jelentősen csökkentette a lehetséges jelszókombinációk számát.
• Jelszó felosztása: A jelszót két, 7 karakteres részre osztotta (még ha a jelszó rövidebb is volt, 0-val töltötte ki). Ezt a két részt külön-külön hash-elte, ami megkönnyítette a feltörést.
• Gyenge kriptográfia (DES): A DES (Data Encryption Standard) algoritmust használta, amely ma már könnyen feltörhető brutális erővel.
• Nincs salt: Nem használt salt-ot, ami azt jelenti, hogy azonos jelszavak azonos hash-t eredményeztek, megkönnyítve a szótár- és szivárványtábla-támadásokat.

Ezen gyengeségek miatt az LM hash-eket rendkívül gyorsan fel lehetett törni, akár percek alatt is egy modern számítógéppel. A Microsoft már a Windows 2000-től kezdve letiltotta az LM hash-ek generálását alapértelmezés szerint, és erősen javasolja, hogy a rendszerek ne tároljanak LM hash-eket. Bár régebbi rendszereken még találkozhatunk vele, a modern Windows installációk már nem generálják.

NTLM hash (NT LAN Manager hash)

Az NTLM hash az LM hash utódja, és a Windows NT-től kezdve a mai napig a helyi fiókok alapértelmezett jelszó-hash algoritmusa. Az NTLM hash egy MD4 alapú hash, amelyet a jelszó kódolt (Unicode) formájára alkalmaznak. Bár sokkal biztonságosabb, mint az LM hash, mégsem tekinthető teljesen feltörhetetlennek, és számos sebezhetőséggel rendelkezik:

• Nincs salt: Az NTLM hash sem használ salt-ot, ami azt jelenti, hogy azonos jelszavak azonos NTLM hash-t eredményeznek. Ez sebezhetővé teszi szótár- és szivárványtábla-támadásokkal szemben, bár ezek létrehozása az NTLM esetében sokkal erőforrásigényesebb.
• Relatív gyenge algoritmus: Az MD4 algoritmus ma már nem számít a legerősebb hash-algoritmusok közé, és léteznek gyors módszerek a feltörésére, különösen rövid vagy gyenge jelszavak esetén.
• Pass-the-Hash (PtH) támadások: Mivel az NTLM hash-sel közvetlenül is lehet hitelesíteni anélkül, hogy a tényleges jelszót tudnánk, a hash megszerzése önmagában is elegendő lehet a rendszerbe való bejutáshoz, ha a hash egy adminisztrátori fiókhoz tartozik.

A Windows továbbra is NTLM hash-eket tárol a SAM adatbázisban a helyi fiókok számára, de számos intézkedést tett a biztonság növelése érdekében. Például a modern Windows rendszerekben a jelszavak tárolása további védelmet kap az LSA titkok és a boot key révén, megnehezítve a SAM adatbázis offline feltörését.

Modern megközelítések és a jövő

Bár az NTLM hash továbbra is jelen van a SAM-ben, a Microsoft aktívan dolgozik a jelszókezelés biztonságának javításán. A modern Windows rendszerek, különösen a Microsoft fiókok vagy az Azure AD Join használatakor, sokkal erősebb és modernebb kriptográfiai algoritmusokat alkalmaznak, mint például a PBKDF2 (Password-Based Key Derivation Function 2). Ez az algoritmus salt-ot használ, és iterációk ezreit végzi el a jelszó hash-eléséhez, jelentősen megnövelve a brutális erővel történő feltörés idejét. Azonban ezek a fejlettebb mechanizmusok elsősorban a felhőalapú vagy domain-alapú hitelesítéshez kapcsolódnak, és a SAM adatbázisban tárolt helyi fiókok továbbra is az NTLM hash-re támaszkodnak.

A biztonságos jelszókezelés kulcsa a SAM-ben továbbra is az erős, egyedi jelszavak használata, a jelszóházirendek betartatása, és a SAM adatbázis fizikai és logikai védelme a jogosulatlan hozzáféréssel szemben. A táblázatban összefoglaljuk a két fő hash típus különbségeit:

Jellemző	LM Hash	NTLM Hash
Algoritmus alapja	DES (Data Encryption Standard)	MD4 (Message Digest Algorithm 4)
Jelszó átalakítás	Nagybetűvé alakítás, 7 karakteres blokkokra osztás	Unicode átalakítás
Salt használata	Nem	Nem
Sebezhetőség	Rendkívül magas (percek alatt feltörhető)	Közepes (napok/hetek gyenge jelszavak esetén)
Használat	Elavult, nem ajánlott	Alapértelmezett a helyi fiókoknál

A modern biztonsági gyakorlatok azt diktálják, hogy a rendszerek ne tároljanak LM hash-eket, és az NTLM hash-ek védelmére is kiemelt figyelmet kell fordítani, például a Pass-the-Hash támadások elleni védekezéssel.

Biztonsági azonosítók (SID-ek): A Windows egyedi ujjlenyomatai

A Windows operációs rendszerben minden biztonsági entitás – legyen szó felhasználói fiókról, csoportról vagy akár egy számítógépről – egyedi azonosítóval rendelkezik. Ez az azonosító a Biztonsági Azonosító (Security Identifier – SID). A SID-ek kulcsfontosságúak a Windows jogosultságkezelésében, mivel a rendszer nem a felhasználónevek, hanem ezeknek az egyedi, numerikus azonosítóknak az alapján azonosítja és kezeli a biztonsági entitásokat. Amikor egy felhasználó bejelentkezik, vagy egy folyamat megpróbál hozzáférni egy erőforráshoz, a Windows a SID-ek alapján dönti el, hogy az adott entitás rendelkezik-e a szükséges jogosultságokkal.

A SID struktúrája

Egy SID egy viszonylag hosszú, változó hosszúságú karakterlánc, amely pontosan meghatározott struktúrával rendelkezik. Formátuma a következő:

S-1-5-21-DomainID-RelativeID

Bontsuk fel ezt a struktúrát:

• S: Ez a karakter jelzi, hogy a string egy SID.
• 1: Ez a SID verziószámát jelöli (jelenleg mindig 1).
• 5: Ez az azonosító a Microsoft által kiadott azonosító hatóságot jelöli (NT Authority).
• 21: Ez a revíziós szám, amely a SID típusát jelöli. A 21-es érték általában egy egyedi azonosítót jelent, amely egy helyi vagy tartományi fiókhoz tartozik.
• DomainID (aldomain azonosító): Ez a rész egyedi módon azonosítja azt a tartományt vagy helyi számítógépet, amely a SID-et kiadta. Ez a DomainID több numerikus alértékből állhat, és biztosítja a SID globális egyediségét. Két különböző tartományban vagy két különböző helyi gépen soha nem lesz azonos a DomainID.
• RelativeID (RID): Ez a rész egy olyan szám, amelyet a DomainID-vel együtt használnak egy adott felhasználó, csoport vagy egyéb biztonsági entitás egyedi azonosítására a DomainID által azonosított tartományon vagy helyi gépen belül. Például a 500-as RID a beépített rendszergazda fiókhoz, az 501-es a vendég fiókhoz tartozik.

Például, egy tipikus felhasználói SID így nézhet ki: S-1-5-21-1234567890-9876543210-123456789-1001. Itt a 1001 a RelativeID, ami egy tipikus felhasználói fiókra utal.

A SID-ek fontossága a jogosultságkezelésben

A SID-ek a Windows jogosultságkezelési modelljének alapkövei:

• Egyediség: Minden SID globálisan egyedi. Ha egy felhasználót törlünk, majd újra létrehozunk azonos felhasználónévvel, az új fiók teljesen más SID-et kap. Ez megakadályozza, hogy egy törölt fiókhoz tartozó jogosultságok véletlenül egy új fiókhoz kerüljenek.
• Erőforrás-hozzáférés: Amikor egy felhasználó megpróbál hozzáférni egy fájlhoz, mappához, registry kulcshoz vagy bármilyen más védett erőforráshoz, a Windows a fájlhoz vagy mappához rendelt hozzáférés-vezérlési listát (Access Control List – ACL) ellenőrzi. Az ACL bejegyzések (Access Control Entries – ACE) SID-eket tartalmaznak, amelyek meghatározzák, hogy mely felhasználók vagy csoportok milyen típusú hozzáféréssel rendelkeznek.
• Biztonsági tokenek: Amikor egy felhasználó bejelentkezik, az LSA létrehoz egy biztonsági tokent, amely tartalmazza a felhasználó saját SID-jét, valamint az összes csoport SID-jét, amelynek a felhasználó tagja. Ez a token minden folyamattal együtt jár, amelyet a felhasználó indít, és ez alapján dönti el a rendszer, hogy az adott folyamat hozzáférhet-e egy adott erőforráshoz.
• Nevek és SID-ek feloldása: Bár a felhasználók a felhasználóneveket látják és használják, a Windows belsőleg a SID-ekkel dolgozik. Amikor egy felhasználónevet írunk be egy jogosultsági beállításnál, a Windows automatikusan feloldja azt a megfelelő SID-re.

Jól ismert SID-ek (Well-Known SIDs)

Léteznek előre definiált, „jól ismert” SID-ek, amelyek speciális beépített felhasználókat vagy csoportokat azonosítanak, és minden Windows rendszeren azonosak. Néhány példa:

• S-1-5-18: Helyi rendszer (Local System)
• S-1-5-19: Helyi szolgáltatás (Local Service)
• S-1-5-20: Hálózati szolgáltatás (Network Service)
• S-1-5-32-544: Rendszergazdák (Administrators)
• S-1-5-32-545: Felhasználók (Users)
• S-1-5-32-550: Operátorok (Print Operators, Server Operators, stb.)
• S-1-5-32-546: Vendégek (Guests)
• S-1-5-7: Névtelen bejelentkezés (Anonymous Logon)
• S-1-5-11: Hitelesített felhasználók (Authenticated Users)
• S-1-1-0: Mindenki (Everyone)

A SID-ek megértése alapvető fontosságú a Windows biztonsági modelljének átfogó megértéséhez. A SAM adatbázisban tárolt felhasználói fiókok és csoportok mind SID-ekkel rendelkeznek, és ezek az azonosítók a kulcsa minden hozzáférési döntésnek, amit az operációs rendszer meghoz.

A SID-ek a Windows biztonsági architektúrájának néma, de legfontosabb építőkövei. Nélkülük a jogosultságok kezelése kaotikus és megbízhatatlan lenne.

A SAM adatbázis védelme és a rendszerleíró adatbázis szerepe

A SAM adatbázis rendkívül érzékeny információkat tárol, ezért a Windows operációs rendszer számos védelmi mechanizmust alkalmaz annak érdekében, hogy megakadályozza a jogosulatlan hozzáférést és manipulációt. A SAM fizikailag a rendszerleíró adatbázis (Registry) egy speciálisan védett részén található, és a hozzáférése szigorúan korlátozott.

Helye a rendszerleíró adatbázisban

A SAM adatbázis a Registryben a HKEY_LOCAL_MACHINE\SAM kulcs alatt helyezkedik el. Azonban, ha megpróbáljuk megnyitni ezt a kulcsot a Registry Editorral (regedit.exe), azt fogjuk tapasztalni, hogy még rendszergazdai jogosultságokkal sem férhetünk hozzá közvetlenül. Ennek oka, hogy a Windows futásidőben folyamatosan zárolva tartja ezt a kulcsot, és csak a Local Security Authority (LSA) alrendszer férhet hozzá. Ez egy alapvető biztonsági intézkedés, amely megakadályozza, hogy rosszindulatú programok vagy felhasználók közvetlenül olvassák vagy módosítsák a SAM tartalmát.

A SAM adatbázis adatai valójában a %SystemRoot%\System32\config\SAM és %SystemRoot%\System32\config\SECURITY fájlokban vannak tárolva a merevlemezen. Ezeket a fájlokat is zárolva tartja az operációs rendszer, amíg fut, így offline módszerekkel lehet csak hozzáférni hozzájuk, ami jelentős biztonsági kockázatot jelenthet.

Az LSA titkok (LSA Secrets)

Az LSA titkok (LSA Secrets) egy másik védelmi réteget jelentenek a Windowsban. Ezek olyan titkosított adatok, amelyeket az LSA tárol, és amelyek kritikus fontosságúak a rendszer biztonsága szempontjából. Az LSA titkok tartalmazhatnak például:

• A SAM adatbázis titkosításához használt kulcsokat (beleértve a boot key-t is).
• Gyorsítótárazott tartományi hitelesítő adatokat (cached domain credentials).
• Szolgáltatások fiókjainak jelszavait.
• Rendszergazdai fiókok jelszavait, ha a rendszergazda bejelentkezett.

Az LSA titkokat a HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets kulcs alatt tárolják a Registryben, de ezek is erősen védettek és titkosítottak. Az LSA folyamat felelős ezeknek a titkoknak a kezeléséért és védelméért, és csak a legmagasabb szintű rendszerjogosultságokkal lehet hozzáférni hozzájuk.

Boot Key és Syskey

A Windows NT-től kezdve bevezetésre került egy további védelmi mechanizmus, a Boot Key (korábban Syskey néven ismert). Ennek célja a SAM adatbázis titkosítása, hogy még akkor is védett legyen, ha valaki offline hozzáférést szerez a merevlemezhez. A Boot Key egy titkosítási kulcs, amelyet a SAM adatbázisban tárolt jelszó-hash-ek titkosítására használnak. A kulcs tárolható:

• A rendszerindító lemezen (floppy disk)
• A rendszerleíró adatbázisban (alapértelmezett)
• A felhasználó által megadott jelszóként (startup password)

Ha a Boot Key a Registryben van tárolva, akkor is titkosított formában van jelen, és a rendszer a rendszerindítás során használja fel a SAM dekódolásához. Bár a Syskey funkciót a Windows 10 (1709-es verzió) és a Server 2016 óta elavulttá nyilvánították, és alapértelmezés szerint nem használják, a mögötte lévő elv – a SAM adatbázis titkosítása egy kulccsal – továbbra is releváns. A modern rendszerekben a BitLocker és az UEFI Secure Boot funkciók nyújtanak hasonló, sőt még erősebb védelmet az offline támadások ellen.

További védelmi rétegek

• Fájlrendszer jogosultságok: A SAM és SECURITY fájlokhoz tartozó NTFS jogosultságok rendkívül szigorúak, csak a SYSTEM fiók rendelkezik teljes hozzáféréssel.
• Védett folyamatok: Az LSA alrendszer védett folyamatként fut, ami azt jelenti, hogy még a rendszergazdák sem tudják közvetlenül leállítani vagy manipulálni, anélkül, hogy az operációs rendszer integritását veszélyeztetnék.
• Rendszerindítási védelem: A Secure Boot és a BitLocker titkosítás további védelmet nyújtanak a SAM adatbázis ellen, megakadályozva, hogy a támadók a rendszer indítása előtt módosítsák a rendszerfájlokat vagy hozzáférjenek a merevlemez tartalmához.

Ezek a mechanizmusok együttesen biztosítják a SAM adatbázis magas szintű védelmét a futó Windows rendszeren belül. Azonban, ahogy a következő szakaszban látni fogjuk, a támadók továbbra is találnak módszereket a SAM kompromittálására, különösen offline környezetben.

Támadási vektorok és sebezhetőségek: Hogyan kompromittálható a SAM?

Bár a SAM adatbázis számos védelmi mechanizmussal rendelkezik, a rosszindulatú szereplők folyamatosan keresik a módokat annak kompromittálására. A SAM sebezhetőségei és az ellene irányuló támadási vektorok megértése kulcsfontosságú a hatékony védekezés kidolgozásában. A támadások általában két fő kategóriába sorolhatók: online és offline támadások.

Offline SAM kinyerés (Offline SAM extraction)

Ez az egyik leggyakoribb és leghatékonyabb módszer a SAM adatbázis tartalmának megszerzésére. Mivel a futó Windows zárolja a SAM fájlokat (%SystemRoot%\System32\config\SAM és SECURITY), a támadónak valamilyen módon le kell állítania a rendszert, vagy egy másik operációs rendszer alól kell hozzáférnie a merevlemezhez. Ez általában a következőképpen történik:

• Live CD/USB: A támadó egy Live Linux disztribúcióval vagy egy Windows Preinstallation Environment (WinPE) lemezzel indítja el a gépet. Erről a környezetből könnyedén hozzáférhet a Windows partícióhoz és kimásolhatja a SAM és SECURITY fájlokat.
• Merevlemez eltávolítása: Fizikai hozzáférés esetén a merevlemezt eltávolíthatják a célgépről, és egy másik számítógéphez csatlakoztatva olvashatják ki a fájlokat.
• Shadow Copy (árnyékmásolat): A Windows Volume Shadow Copy Service (VSS) árnyékmásolatokat készít a rendszer állapotáról, amelyek tartalmazhatják a SAM fájlok másolatát. Bizonyos eszközökkel ezekből az árnyékmásolatokból is kinyerhető a SAM.

Miután a SAM és SECURITY fájlokat kinyerték, a támadók speciális eszközökkel (pl. pwdump, secretsdump a Impacket csomagból) képesek kivonni belőlük a jelszó-hash-eket. A SECURITY fájl tartalmazza az LSA titkokat, amelyek a SAM adatbázis titkosításához használt kulcsot is magukban foglalhatják, így elengedhetetlen a jelszó-hash-ek megfejtéséhez.

Jelszó feltörés (Password Cracking)

A kinyert jelszó-hash-ek önmagukban nem a jelszavak, hanem azok kriptográfiai lenyomatai. A támadóknak ezeket a hash-eket kell „feltörniük” a tényleges jelszavak megszerzéséhez. Erre a célra számos nyílt forráskódú és kereskedelmi eszköz létezik, mint például a John the Ripper vagy a Hashcat.

• Szótár-támadások (Dictionary Attacks): Ezek az eszközök előre elkészített szótárakat használnak, amelyek gyakori jelszavakat és azok hash-eit tartalmazzák. Ha a felhasználó egy gyenge, szótárban szereplő jelszót használt, a feltörés rendkívül gyors lehet.
• Brutális erővel történő támadások (Brute-Force Attacks): Ezek a támadások minden lehetséges karakterkombinációt kipróbálnak egy adott hosszúságig, amíg meg nem találják a hash-nek megfelelő jelszót. Ez rendkívül időigényes lehet, de grafikus processzorok (GPU) használatával jelentősen felgyorsítható.
• Szivárványtáblák (Rainbow Tables): Előre kiszámított hash-értékek hatalmas adatbázisai, amelyek felgyorsítják a feltörést azáltal, hogy elkerülik a hash-ek futásidejű kiszámítását. Az NTLM hash-ek esetében a szivárványtáblák kevésbé hatékonyak a nagyobb kulcstér miatt, de továbbra is veszélyt jelentenek.

Az LM hash-ek feltörése rendkívül gyors, míg az NTLM hash-ek feltörése sokkal több időt és erőforrást igényel, különösen, ha erős, hosszú és komplex jelszavakat használnak.

Pass-the-Hash (PtH) támadások

A Pass-the-Hash (PtH) támadások egy másik kifinomult módszer, amely kihasználja az NTLM hitelesítési protokoll sajátosságait. Mivel az NTLM protokoll lehetővé teszi a hitelesítést a jelszó-hash ismeretében, anélkül, hogy a tényleges jelszóra szükség lenne, egy támadó, aki megszerezte egy felhasználó NTLM hash-ét (például a SAM-ből vagy a memória dump-ból a Mimikatz segítségével), használhatja azt más rendszerekbe való bejelentkezéshez. Ez különösen veszélyes, ha egy adminisztrátori fiók hash-jét szerzik meg.

• Mimikatz: Ez a hírhedt eszköz képes kivonni a jelszavakat, hash-eket és Kerberos jegyeket a futó Windows rendszer memóriájából. Ha egy adminisztrátor bejelentkezett, a Mimikatz képes lehet kinyerni az adminisztrátor NTLM hash-jét, amelyet aztán PtH támadásokhoz használhatnak fel.

Helyi jogosultságnövelés (Local Privilege Escalation)

A SAM adatbázis elleni támadások gyakran egy nagyobb támadási lánc részét képezik. Egy támadó először egy alacsony jogosultságú fiókkal jut be a rendszerbe, majd sebezhetőségeket kihasználva növeli a jogosultságait „SYSTEM” szintre. Miután SYSTEM jogosultságokat szerzett, hozzáférhet az LSA titkokhoz és a SAM adatbázishoz, még akkor is, ha a Windows fut. Ezt követően kinyerheti a jelszó-hash-eket, vagy akár új adminisztrátori fiókokat is létrehozhat.

Védekezés a SAM kompromittálása ellen

A SAM elleni támadások kivédése több rétegű megközelítést igényel:

• Fizikai biztonság: Megakadályozni a jogosulatlan fizikai hozzáférést a számítógéphez.
• Erős jelszavak és jelszóházirendek: Kötelezővé tenni az erős, hosszú és komplex jelszavakat, amelyek ellenállnak a szótár- és brutális erővel történő támadásoknak.
• Rendszeres biztonsági frissítések: A Microsoft folyamatosan ad ki javításokat a Windows sebezhetőségeire, amelyek megakadályozhatják a jogosultságnövelő támadásokat.
• BitLocker/Teljes lemez titkosítás: A teljes merevlemez titkosítása megakadályozza az offline SAM kinyerést, mivel a titkosított adatokat nem lehet olvasni a titkosítási kulcs nélkül.
• Jelszókezelő megoldások: A jelszókezelő szoftverek használata segíthet az erős, egyedi jelszavak generálásában és tárolásában.
• Többfaktoros hitelesítés (MFA): Bár a SAM alapvetően a helyi jelszóra épül, az MFA bevezetése a tartományi vagy felhőalapú fiókok esetében jelentősen növeli a biztonságot.
• Adminisztrátori jogosultságok minimalizálása: Csak a feltétlenül szükséges felhasználók kapjanak adminisztrátori jogosultságokat.
• LSA Protection: A modern Windows verziókban az LSA Protection (LSA minimális védelem) funkció segít megvédeni az LSA folyamatot a memória dump-októl, ezzel megnehezítve a Mimikatz-hoz hasonló eszközök működését.

A SAM adatbázis védelme tehát egy komplex feladat, amely folyamatos figyelmet és proaktív biztonsági intézkedéseket igényel.

SAM és Active Directory: Különbségek és interakciók

A Windows környezetben a felhasználói fiókok kezelésének két fő modellje létezik: a helyi fiókok kezelése, amelyet a Security Accounts Manager (SAM) végez, és a tartományi fiókok kezelése, amelyet az Active Directory (AD) biztosít. Fontos megérteni a kettő közötti különbségeket és azt, hogy hogyan működnek együtt egy tartományi környezetben.

Helyi fiókok és a SAM

A SAM adatbázis minden egyes önálló Windows számítógépen (legyen az egy munkaállomás vagy egy tartománytól független szerver) megtalálható. Kizárólag az adott gépen lévő helyi felhasználói fiókokat és csoportokat kezeli. Ezek a fiókok csak azon a gépen érvényesek, ahol létrehozták őket. Ha egy felhasználó helyi fiókkal jelentkezik be, a hitelesítés kizárólag az adott gép SAM adatbázisa alapján történik, az LSA segítségével.

Jellemzők:

• Decentralizált: Minden gépnek saját SAM adatbázisa van.
• Korlátozott hatókör: A fiókok csak azon a gépen léteznek, ahol létrehozták őket.
• Egyszerűbb kezelés: Kisebb hálózatok, önálló gépek esetén elegendő.

Tartományi fiókok és az Active Directory

Az Active Directory egy központi címtárszolgáltatás, amelyet a Microsoft fejlesztett ki nagyvállalati hálózatokhoz. Az AD tartományvezérlőkön fut, és egyetlen központi adatbázisban (NTDS.DIT) tárolja az összes tartományi felhasználói fiókot, csoportot, számítógépet és egyéb hálózati erőforrást. Amikor egy felhasználó tartományi fiókkal jelentkezik be egy tartományhoz csatlakoztatott számítógépbe, a hitelesítést egy tartományvezérlő végzi, jellemzően a Kerberos protokoll segítségével (bár az NTLM is használható bizonyos esetekben).

Jellemzők:

• Centralizált: Egyetlen adatbázis kezeli az összes tartományi fiókot és erőforrást.
• Széles hatókör: A fiókok a tartomány bármely gépén érvényesek.
• Komplex kezelés: Nagyobb hálózatokhoz, központosított szabályozáshoz ideális (csoportszabályzatok – Group Policy).
• Skálázhatóság: Könnyen bővíthető és replikálható.

Az interakció egy tartományi környezetben

Amikor egy számítógépet tartományhoz csatlakoztatunk, az továbbra is rendelkezik saját SAM adatbázissal. Ez a SAM adatbázis továbbra is kezeli a helyi fiókokat, beleértve a beépített rendszergazdai és vendég fiókokat, valamint bármely más helyi fiókot, amelyet manuálisan hoztak létre a gépen. Azonban a tartományi fiókok hitelesítése már nem a helyi SAM-en keresztül történik.

A folyamat a következő:

1. Bejelentkezési kísérlet: A felhasználó megadja a felhasználónevét és jelszavát. Ha a felhasználónév formátuma DOMAIN\Username vagy username@domain.com, a rendszer tudja, hogy tartományi bejelentkezésről van szó.
2. LSA továbbítja a kérést: A helyi LSA az NTLM vagy Kerberos hitelesítési csomagok segítségével továbbítja a hitelesítési kérést egy tartományvezérlőnek.
3. Tartományvezérlő hitelesít: A tartományvezérlő az Active Directory adatbázisában ellenőrzi a felhasználó hitelesítő adatait.
4. Eredmény visszajelzése: Ha a hitelesítés sikeres, a tartományvezérlő visszajelez a helyi LSA-nak, amely létrehoz egy biztonsági tokent a felhasználó számára, amely tartalmazza a tartományi SID-eket és csoporttagságokat.

Fontos szerepe van a SAM-nek abban az esetben is, ha a tartományhoz csatlakoztatott gép offline állapotban van (nem éri el a tartományvezérlőket). Ebben az esetben a Windows a gyorsítótárazott tartományi hitelesítő adatokat (Cached Credentials) használhatja, amelyeket az LSA titkok között tárol. Ez lehetővé teszi a felhasználók számára, hogy bejelentkezzenek a gépbe, még akkor is, ha a hálózati kapcsolat megszakadt. Ezek a gyorsítótárazott adatok azonban nem a SAM-ben, hanem az LSA titkokban vannak tárolva, és szintén erősen védettek.

Összefoglalva, a SAM és az Active Directory kiegészítik egymást:

• A SAM kezeli a helyi fiókokat minden egyes Windows gépen.
• Az Active Directory kezeli a tartományi fiókokat központilag a tartományi környezetben.

Egy rendszergazdának mindkét mechanizmust ismernie kell a biztonságos és hatékony felhasználókezelés biztosításához. A helyi adminisztrátori fiókok védelme a SAM-en belül továbbra is kritikus fontosságú, még egy tartományi környezetben is, mivel ezek a fiókok gyakran szolgálnak „mentőövet” hálózati problémák vagy tartományi fiókproblémák esetén.

A SAM a helyi erődítmény, az Active Directory pedig a birodalom központja. Mindkettő elengedhetetlen a Windows biztonsági ökoszisztémájában.

A SAM szerepének evolúciója modern Windows rendszerekben

A Security Accounts Manager (SAM) a Windows operációs rendszerek alapvető része maradt a kezdetektől fogva, de a szerepe és az interakciói a felhasználói fiókok kezelésével jelentősen fejlődtek az évek során, különösen a modern Windows 10 és 11 rendszerek megjelenésével. Bár a SAM továbbra is a helyi hitelesítés gerince, az újabb funkciók és szolgáltatások alternatív vagy kiegészítő hitelesítési mechanizmusokat vezettek be.

Microsoft fiókok és a felhő integrációja

A Windows 8-tól kezdve a Microsoft lehetővé tette a felhasználók számára, hogy Microsoft fiókkal (korábban Windows Live ID) jelentkezzenek be a helyi gépekre. Ez a funkció elmosta a határt a helyi és a felhőalapú identitások között. Amikor egy felhasználó Microsoft fiókkal jelentkezik be egy Windows 10/11 gépbe, a rendszer valójában létrehoz egy helyi felhasználói profilt, de a hitelesítést a Microsoft online szolgáltatásai végzik. A helyi SAM adatbázisban ilyenkor továbbra is tárolódik egy bejegyzés a felhasználóról, de a jelszó-hash már nem a hagyományos értelemben vett helyi jelszóhoz tartozik, hanem egy szinkronizált, a Microsoft fiókhoz kapcsolódó hitelesítő adathoz. Ez a megközelítés lehetővé teszi a beállítások, alkalmazások és adatok szinkronizálását több eszköz között, és a felhőalapú biztonsági funkciók kihasználását.

Windows Hello és biometrikus hitelesítés

A Windows Hello egy biometrikus hitelesítési keretrendszer, amelyet a Microsoft vezetett be a Windows 10-ben. Lehetővé teszi a felhasználók számára, hogy ujjlenyomattal, arcfelismeréssel vagy PIN-kóddal jelentkezzenek be a rendszerbe. Fontos megérteni, hogy a Windows Hello nem helyettesíti a hagyományos jelszavakat, hanem egy kényelmesebb és biztonságosabb alternatívát kínál a bejelentkezéshez. A biometrikus adatok és a PIN-kódok kriptográfiailag védettek, és a rendszer egyedi kulcsokat generál a felhasználó számára, amelyeket a Trusted Platform Module (TPM) chip tárol (ha elérhető). Ezek a kulcsok a felhasználóhoz vannak kötve, és a biometrikus adatok soha nem hagyják el az eszközt, sem a felhőbe, sem a SAM-be nem kerülnek. A Windows Hello alapvetően a jelszó helyett egy erősebb, eszközre specifikus hitelesítési mechanizmust biztosít, de a mögöttes felhasználói profil továbbra is kapcsolódhat a SAM-ben tárolt helyi fiókhoz vagy egy Microsoft fiókhoz.

Azure AD Join és a felhőalapú tartományok

A vállalati környezetekben az Azure Active Directory (Azure AD) Join lehetőséget kínál arra, hogy a Windows 10/11 eszközöket közvetlenül az Azure AD-hez csatlakoztassák, anélkül, hogy hagyományos Active Directory tartományhoz kellene csatlakozniuk. Ez a felhőalapú megközelítés különösen releváns a modern, mobil munkaerő és a felhőalapú infrastruktúrák számára. Azure AD Join esetén a felhasználók Azure AD fiókjukkal jelentkeznek be az eszközre, és a hitelesítést az Azure AD végzi. A helyi SAM adatbázis ebben az esetben is létezik, és továbbra is kezeli a helyi rendszergazdai fiókot, de a felhasználói fiókok kezelése és a házirendek alkalmazása az Azure AD-n keresztül történik.

A SAM továbbra is alapvető

Mindezek az újítások ellenére a SAM továbbra is alapvető szerepet játszik a Windows operációs rendszerben. A következő okok miatt:

• Helyi fiókok kezelése: Bármilyen helyi fiók, amelyet nem Microsoft fiókkal vagy Azure AD fiókkal hoznak létre, továbbra is a SAM-ben tárolódik. Ez magában foglalja a beépített rendszergazdai és vendég fiókokat is.
• Offline hozzáférés: Ha egy gép nincs csatlakoztatva a hálózathoz, és nem tudja elérni a Microsoft fiók vagy Azure AD hitelesítési szolgáltatásokat, a helyi SAM-ben tárolt adatok alapján történik a hitelesítés (vagy a gyorsítótárazott tartományi/felhőalapú hitelesítő adatok alapján).
• Legacy alkalmazások: Régebbi alkalmazások vagy szolgáltatások, amelyek a helyi felhasználói fiókokra támaszkodnak, továbbra is a SAM-mel kommunikálnak.
• Rendszer-helyreállítás: Bizonyos helyreállítási forgatókönyvek esetén a helyi rendszergazdai fiók és a SAM adatbázis kritikus fontosságú lehet a rendszerhez való hozzáférés visszaszerzéséhez.

Összességében a SAM szerepe nem csökkent, hanem inkább átalakult. Míg a felhasználók számára a modern hitelesítési módszerek (Microsoft fiók, Windows Hello) kényelmesebb és biztonságosabb élményt nyújtanak, a SAM továbbra is a háttérben dolgozik, biztosítva a helyi fiókok és a hagyományos hitelesítési mechanizmusok alapjait. A rendszergazdáknak továbbra is tisztában kell lenniük a SAM működésével és védelmével, függetlenül attól, hogy milyen modern hitelesítési megoldásokat alkalmaznak a környezetükben.

Gyakorlati tippek a SAM adatbázis biztonságának megerősítéséhez

A Security Accounts Manager (SAM) adatbázis védelme létfontosságú a Windows rendszer integritásának és biztonságának fenntartásához. Mivel a SAM tartalmazza a helyi felhasználói fiókok jelszó-hash-eit és egyéb érzékeny biztonsági információkat, a kompromittálása súlyos következményekkel járhat. Az alábbiakban gyakorlati tippeket és bevált gyakorlatokat mutatunk be a SAM adatbázis biztonságának megerősítéséhez.

1. Erős jelszavak és szigorú jelszóházirendek

Ez az alapvető védelmi vonal. Minél erősebbek a jelszavak, annál nehezebb feltörni a SAM-ből kinyert hash-eket. Győződjön meg róla, hogy:

• A jelszavak hosszúak (minimum 12-14 karakter).
• Komplexek (tartalmaznak nagy- és kisbetűket, számokat és speciális karaktereket).
• Ne legyenek könnyen kitalálhatók vagy szótárban szereplő szavak.
• Rendszeresen változnak (bár a modern megközelítések a gyakori változtatás helyett az erős és egyedi jelszavakat részesítik előnyben).

Alkalmazzon erős jelszóházirendeket a helyi gépen (gpedit.msc > Számítógép konfigurációja > Windows-beállítások > Biztonsági beállítások > Fiókházirendek > Jelszóházirend) vagy tartományi környezetben (Group Policy) a jelszavak minőségének kikényszerítésére.

2. A helyi rendszergazdai fiókok körültekintő kezelése

A helyi „Administrator” fiók a SAM adatbázis egyik legértékesebb célpontja. Győződjön meg róla, hogy:

• Ne használja a beépített „Administrator” fiókot: Tiltsa le, vagy nevezze át, és hozzon létre egy másik fiókot adminisztrátori jogosultságokkal, egyedi, erős jelszóval.
• Minimalizálja az adminisztrátori fiókok számát: Csak azok kapjanak adminisztrátori jogosultságot, akiknek feltétlenül szükségük van rá.
• „Just Enough Administration” (JEA) elv: Ha lehetséges, alkalmazzon minimális jogosultság elvét, és használjon „just-in-time” adminisztrációt, amikor a jogosultságok csak akkor adhatók meg, amikor szükség van rájuk, és csak a szükséges ideig.

3. Fizikai biztonság és teljes lemez titkosítás

Az offline SAM kinyerés a fizikai hozzáférésen alapul. Ennek megakadályozására:

• Fizikai hozzáférés korlátozása: Győződjön meg róla, hogy a számítógépek biztonságos helyen vannak tárolva, és csak jogosult személyek férhetnek hozzájuk.
• Teljes lemez titkosítás (Full Disk Encryption – FDE): Használjon BitLocker-t (Windows Pro/Enterprise) vagy más FDE megoldást. Ez megakadályozza, hogy a támadók a merevlemez eltávolításával vagy Live CD-vel hozzáférjenek a SAM fájlokhoz, mivel azok titkosítva vannak.
• UEFI Secure Boot: Engedélyezze a Secure Boot funkciót az UEFI firmware-ben, hogy megakadályozza a jogosulatlan operációs rendszerek betöltését vagy a rendszerindító fájlok manipulálását.

4. Rendszeres biztonsági frissítések

A Microsoft folyamatosan ad ki biztonsági javításokat, amelyek orvosolják a Windowsban található sebezhetőségeket, beleértve azokat is, amelyeket a jogosultságnövelő támadások kihasználhatnak a SAM eléréséhez. Győződjön meg róla, hogy a rendszerek mindig naprakészek.

5. Az LSA Protection engedélyezése

A Windows 8.1 és újabb rendszerekben elérhető az LSA Protection (Local Security Authority process protection) funkció. Ez segít megvédeni az LSA folyamatot a jogosulatlan memória-dump-októl, amelyekből a Mimikatz-hoz hasonló eszközök kinyerhetik a jelszó-hash-eket. Győződjön meg róla, hogy ez a funkció engedélyezve van a csoportszabályzatokban (Computer Configuration\Administrative Templates\System\LSA\Configure LSASS to run as a protected process).

6. Helyi fiókok korlátozása

Ha egy gép tartományhoz van csatlakoztatva, fontolja meg a helyi fiókok bejelentkezési jogainak korlátozását. A csoportszabályzatok lehetővé teszik, hogy meghatározza, kik jelentkezhetnek be helyi fiókkal (Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Allow log on locally). Ideális esetben csak a legszükségesebb fiókoknak legyen erre jogosultsága.

7. Eseménynaplózás és auditálás

Konfigurálja az eseménynaplózást úgy, hogy rögzítse a SAM-hez és az LSA-hoz kapcsolódó biztonsági eseményeket. Különösen figyeljen a következőkre:

• Sikertelen bejelentkezési kísérletek (4625-ös eseményazonosító).
• Fiókkezelési események (fiókok létrehozása, módosítása, törlése – 4720, 4722, 4723, 4724, 4725, 4726, 4738, 4740, 4767 eseményazonosítók).
• Csoporttagság-változások (4728, 4732 eseményazonosítók).

A naplók rendszeres felülvizsgálata segíthet a gyanús tevékenységek korai felismerésében.

8. Jelszókezelő szoftverek

Felhasználói szinten a jelszókezelő szoftverek használata segíthet az erős, egyedi jelszavak generálásában és biztonságos tárolásában, csökkentve ezzel a gyenge jelszavakból adódó kockázatokat.

9. Többfaktoros hitelesítés (MFA)

Bár a SAM maga nem támogatja az MFA-t, az MFA bevezetése a hálózati erőforrásokhoz és a felhőalapú fiókokhoz (Microsoft fiók, Azure AD) jelentősen csökkenti a jelszó-hash lopásból eredő kockázatokat, mivel még a hash birtokában sem lehet bejelentkezni a második faktor nélkül.

Ezen intézkedések kombinációjával jelentősen megerősíthetjük a SAM adatbázis biztonságát, és ellenállóbbá tehetjük a Windows rendszereket a célzott támadásokkal szemben.

Eseménynaplózás és auditálás: A SAM-hez kapcsolódó biztonsági események nyomon követése

A SAM adatbázis és a felhasználói fiókokhoz kapcsolódó tevékenységek nyomon követése elengedhetetlen a Windows rendszerek biztonságának fenntartásához. Az eseménynaplózás és auditálás segítségével a rendszergazdák és biztonsági szakemberek felismerhetik a jogosulatlan hozzáférési kísérleteket, a jogosultságnövelő támadásokat, a fiókmanipulációkat és egyéb gyanús viselkedéseket. A Windows eseménynaplói részletes információkat szolgáltatnak ezekről az eseményekről, amennyiben megfelelően vannak konfigurálva.

A Windows biztonsági naplója

A Windows operációs rendszer a Biztonsági naplóban (Security Log) rögzíti a biztonsággal kapcsolatos eseményeket. Ez a napló tartalmazza a bejelentkezési kísérleteket, a fiókmódosításokat, a jogosultságok használatát és sok más, a SAM-mel és az LSA-val összefüggő tevékenységet. Az események konfigurálásához a Helyi biztonsági házirend (Local Security Policy) vagy a Csoportszabályzat (Group Policy) használható.

Főbb auditálási kategóriák a SAM-hez kapcsolódóan

A SAM adatbázis védelme szempontjából különösen fontos auditálási kategóriák a következők:

• Fiókkezelés auditálása (Audit Account Management): Ez a kategória rögzíti a felhasználói fiókok és csoportok létrehozását, módosítását és törlését. Kritikus fontosságú a jogosulatlan fióklétrehozások vagy jogosultságmódosítások észleléséhez.
• Bejelentkezési események auditálása (Audit Logon Events): Rögzíti a sikeres és sikertelen bejelentkezési kísérleteket a helyi gépen. A nagyszámú sikertelen bejelentkezési kísérlet brutális erővel történő támadásra utalhat.
• Objektum-hozzáférés auditálása (Audit Object Access): Bár nem közvetlenül a SAM-hez tartozik, konfigurálható a SAM fájlokhoz (%SystemRoot%\System32\config\SAM és SECURITY) való hozzáférés nyomon követésére, ha valaki megpróbálná azokat másolni vagy módosítani.
• Rendszeresemények auditálása (Audit System Events): Rögzíti a rendszerindítási és leállítási eseményeket, valamint a rendszerfolyamatokkal kapcsolatos hibákat, amelyek befolyásolhatják a SAM integritását.

Kiemelt eseményazonosítók

Az alábbi táblázat néhány kulcsfontosságú eseményazonosítót mutat be, amelyekre figyelni kell a SAM-hez kapcsolódó biztonsági incidensek felderítése során:

Eseményazonosító	Leírás	Kategória	Jelentőség
4624	Sikeres bejelentkezés	Bejelentkezés/kijelentkezés	Nyomon követi a jogosult hozzáférést.
4625	Sikertelen bejelentkezés	Bejelentkezés/kijelentkezés	Lehetséges brutális erővel történő vagy szótár-támadás jele.
4720	Felhasználói fiók létrehozva	Fiókkezelés	Kritikus, ha jogosulatlan fiókot hoztak létre.
4722	Fiók engedélyezve	Fiókkezelés	Rögzíti a letiltott fiókok újraaktiválását.
4723	Jelszó módosítási kísérlet	Fiókkezelés	Nyomon követi a jelszómódosítási kísérleteket.
4724	Jelszó visszaállítási kísérlet	Fiókkezelés	Nyomon követi a jelszó visszaállítási kísérleteket.
4725	Fiók letiltva	Fiókkezelés	Nyomon követi a fiókok letiltását.
4726	Felhasználói fiók törölve	Fiókkezelés	Kritikus, ha jogosulatlanul töröltek fiókot.
4732	Globális csoportba tag felvéve	Fiókkezelés	Különösen fontos, ha adminisztrátori csoportba kerül valaki.
4733	Globális csoportból tag eltávolítva	Fiókkezelés	Nyomon követi a csoporttagság-változásokat.
4738	Felhasználói fiók módosítva	Fiókkezelés	Részletes információ a fiókattribútumok változásairól.
4740	Fiók zárolva	Fiókkezelés	A zárolási házirend aktiválódása, brutális erővel történő támadás jele lehet.
4798	A helyi csoport tagsága számbavételre került	Fiókkezelés	Támadók gyakran használják az információgyűjtésre.

Az auditálási házirend konfigurálása

Az auditálási házirendet a következőképpen konfigurálhatja:

1. Nyissa meg a Helyi biztonsági házirendet (secpol.msc) vagy a Csoportszabályzat-szerkesztőt (gpedit.msc).
2. Navigáljon a Biztonsági beállítások > Helyi házirendek > Auditálási házirend útvonalra.
3. Engedélyezze a sikeres és sikertelen események auditálását a releváns kategóriákban (pl. Fiókkezelés auditálása, Bejelentkezési események auditálása).

A részletesebb auditáláshoz (Advanced Audit Policy Configuration) további beállításokat is elvégezhet, amelyek finomabb vezérlést biztosítanak az események naplózása felett.

Naplóelemzés és riasztás

Az eseménynaplók önmagukban nem elegendőek. Rendszeres elemzésre és adott esetben automatizált riasztási rendszerekre van szükség:

• Rendszeres felülvizsgálat: Rendszeresen ellenőrizze a biztonsági naplót gyanús mintázatok vagy események után kutatva.
• Központi naplógyűjtés: Nagyobb környezetekben használjon központi naplógyűjtő rendszert (pl. SIEM – Security Information and Event Management), amely képes összegyűjteni és elemezni a naplókat több gépről, és automatikusan riasztani a rendellenességekre.
• Automatizált elemzés: Használjon szkripteket vagy szoftvereket a naplók automatizált elemzésére, hogy gyorsabban felismerje a kritikus eseményeket.

Az eseménynaplózás és auditálás proaktív megközelítése kulcsfontosságú a SAM adatbázis és az egész Windows rendszer biztonságának monitorozásában és az incidensekre való gyors reagálásban.