A tartományi rendszergazda a saját laptopján olvassa a leveleit, aztán ugyanonnan, ugyanazzal a fiókkal távoli asztallal belép egy tartományvezérlőre. Kényelmes, és sok hálózatban évekig semmi baj nem lesz belőle. Ha viszont azon a laptopon egyszer lefut egy kártékony melléklet, és a támadó helyi adminisztrátori jogot szerez, a gép memóriájából kiolvashatja azt a hitelesítő adatot, amellyel az egész tartomány kezelhető.
A tier-modell erre a helyzetre ad szabályt. A rendszereket aszerint sorolja rétegekbe, hogy mekkora kárt okozna az átvételük, és megtiltja, hogy egy magasabb réteg fiókja alacsonyabb rétegű gépre belépjen. Az alábbiakban sorra vesszük, miért marad nyoma egy bejelentkezésnek, hogyan épülnek fel a rétegek, milyen Windows-beállítások kényszerítik ki a szabályt, és milyen sorrendben érdemes bevezetni.
Hol marad nyoma egy rendszergazdai bejelentkezésnek
Windowsban a bejelentkezés módján múlik, marad-e újrahasználható hitelesítő adat a gépen. Interaktív bejelentkezésnél, tehát a konzolon vagy távoli asztallal, a helyi biztonsági alrendszer folyamata (LSASS) a munkamenet idejére a memóriában tartja a felhasználó NTLM-hashét és Kerberos-jegyeit, hogy a hálózati erőforrások eléréséhez ne kelljen újra jelszót kérnie. Ugyanez történik a RunAs paranccsal indított programnál. Ha egy szolgáltatás vagy ütemezett feladat tartományi fiók nevében fut, a jelszava tartósan a gépen tárolódik.
Hálózati bejelentkezésnél, például egy fájlmegosztás megnyitásakor vagy egy távoli felügyeleti konzol csatlakozásakor, a célgépre általában nem kerül újrahasználható adat. Két kivétel van: a CredSSP-vel hitelesített kapcsolat, amely a jelszót is továbbítja, és a korlátozás nélküli Kerberos-delegálásra beállított célgép, amelyre a felhasználó jegymegadó jegye (TGT) is átkerül. Emellett a gép gyorsítótárban őrzi a korábbi tartományi bejelentkezések ellenőrző adatát, hogy tartományvezérlő nélkül is beengedje a felhasználót. Ezzel közvetlenül hitelesíteni nem lehet, offline viszont törhető.
Akinek egy gépen helyi adminisztrátori joga van, ezeket kiolvashatja. A kiolvasott hash-sel (pass-the-hash) vagy jeggyel (pass-the-ticket) jelszó ismerete nélkül hitelesíthet más gépeken. A tartományvezérlő így egy olyan munkaállomáson keresztül is elérhető, amelyre nemrég tartományi rendszergazda lépett be.
A modell alapgondolata ebből következik: egy rendszer csak annyira biztonságos, mint az a gép, amelyről kezelik, és az a fiók, amellyel kezelik. A Microsoft dokumentációja ezt a tiszta forrás elvének (clean source principle) nevezi.
A három réteg: tartományvezérlők, szerverek, munkaállomások
A klasszikus modell három réteget különít el. A számozás a hozzáférés értékét jelzi: a 0. rétegű rendszer átvétele az egész környezet átvételét jelenti.
| Réteg | Mit tartalmaz | Tipikus fiókok |
|---|---|---|
| 0. réteg | Tartományvezérlők, az Active Directory maga, és minden, ami ezeket irányítani tudja | Domain Admins, Enterprise Admins, Schema Admins és a beépített operátori csoportok tagjai |
| 1. réteg | Tagszerverek, alkalmazások, adatbázisok, fájlszerverek | Szerver- és alkalmazás-adminisztrátorok |
| 2. réteg | Munkaállomások, laptopok, a felhasználói eszközök | Ügyfélszolgálati és munkaállomás-adminisztrátorok |
Két szabály tartja egyben a rétegeket. Egy fiók a saját és az alacsonyabb rétegeket irányíthatja, de alacsonyabb rétegű gépre nem léphet be. Fordítva sem mehet az irányítás: egy munkaállomás-adminisztrátor nem kaphat jogot szerverre, és egy szerveren futó ügynök sem adhat parancsot tartományvezérlőnek.
A 0. réteg határa
A tervezés legnehezebb része annak eldöntése, hogy pontosan mely rendszerek tartoznak a 0. rétegbe. A tartományvezérlőkön túl ide kerül minden rendszer, amely közvetve a tartomány felett rendelkezik: a tanúsítványkiadó (AD CS), az összevont hitelesítés kiszolgálója (AD FS), az Entra ID-val szinkronizáló kiszolgáló, a tartományvezérlőket futtató virtualizációs gazdák és azok kezelőfelülete, a tartományvezérlőket mentő rendszer, és minden felügyeleti ügynök, amely szoftvert telepíthet egy tartományvezérlőre. Aki a virtualizációs platform adminisztrátora, az a tartományvezérlő virtuális lemezéhez is hozzáfér, tehát a gyakorlatban 0. rétegű jogot birtokol.
Ugyanez igaz a jogosultságokra. Egy fiók akkor is 0. rétegű, ha nem tagja a Domain Admins csoportnak, de jelszót állíthat vissza valamelyik tagjának, vagy írási joga van egy tartományvezérlőkre kapcsolt csoportházirend-objektumra. Az ilyen rejtett jogosultsági láncokról az Active Directory támadási útjairól szóló cikk ír részletesebben.
Külön adminisztrátori fiókok és felügyeleti munkaállomások
A szabály gyakorlati következménye, hogy egy rendszergazdának több fiókja lesz. A hétköznapi fiókkal levelez, böngészik és dokumentumokat szerkeszt. Mellette rétegenként külön adminisztrátori fiókot kap, de csak azokhoz a rétegekhez, amelyeket ténylegesen kezel. Az elnevezésből látsszon a réteg, például egy előtaggal, hogy a naplóban és a csoporttagságokban azonnal feltűnjön, ha egy fiók rossz helyen jár. Az adminisztrátori fióknak nincs postafiókja, és nem használják internetezésre.
A külön fiók még kevés, ha ugyanarról a laptopról használják, amelyen a levelezés fut. Ha a laptop fertőzött, a támadó a billentyűleütéseket is rögzítheti, és a 0. rétegű fiók jelszavát begépeléskor kapja el. A 0. réteg kezelésére ezért felügyeleti munkaállomás (privileged access workstation, PAW) kell: keményített gép, amelyről nem lehet levelezni és szabadon böngészni, és amelyen csak a felügyeleti eszközök futnak.
A PAW lehet külön fizikai gép, vagy ugyanazon a hardveren virtualizálva is kiépíthető. Ilyenkor a megbízhatóbb rendszer legyen a gazda: a PAW fut a hardveren, a hétköznapi munka pedig virtuális gépben. Fordított felállásban a fertőzött gazdagép a rajta futó felügyeleti virtuális gépet is látja.
Az ugrószerver (jump server) önmagában nem oldja meg a problémát. Ha a rendszergazda egy fertőzött munkaállomásról lép be rá, a hitelesítő adata már az ugrószerver előtt kiszivárog. Ugrószerver akkor segít, ha a hozzá vezető gép is a saját rétegének megfelelő tisztaságú.
A privilegizált fiókok kezelését egy PAM-rendszer tovább szigoríthatja, például időkorlátos jogosultsággal és a munkamenetek rögzítésével. Erről a PAM-ról szóló cikk szól.
Bejelentkezési korlátozások csoportházirenddel
A rétegek szétválasztását fegyelemre bízni kevés, mert egyetlen sietős éjszakai hibaelhárítás felülírja. A Windows a felhasználói jogok kiosztásával (User Rights Assignment) technikailag is kikényszeríti. A csoportházirendben a következő tiltó jogok állíthatók be:
- Deny log on locally: a fiók nem jelentkezhet be a gép konzolján.
- Deny log on through Remote Desktop Services: a fiók távoli asztallal sem léphet be.
- Deny access to this computer from the network: a fiók hálózaton keresztül sem érheti el a gépet.
- Deny log on as a batch job és Deny log on as a service: a fiók nevében nem futhat ütemezett feladat vagy szolgáltatás.
A munkaállomásokra kapcsolt házirend a 0. és az 1. rétegű adminisztrátori csoportokat zárja ki, a tagszerverekre kapcsolt a 0. rétegűeket. Ehhez olyan szervezetiegység-szerkezet kell, amelyben a gépek és a fiókok rétegenként külön egységben vannak, így a házirend egyértelműen kapcsolható. A tiltó jog mindig erősebb az engedélyezőnél, tehát egy helyi adminisztrátori csoporttagság sem írja felül.
A hálózati hozzáférés tiltása túlmegy a belépési szabályon, hiszen a hálózati bejelentkezés a korábban említett kivételektől eltekintve nem hagy újrahasználható adatot a célgépen. Azért mégis érdemes beállítani, mert ezeket a kivételeket is lezárja, és a munkaállomásokat, tagszervereket így a saját rétegük adminisztrátori fiókjával kezelik.
Hitelesítési házirendek és silók
A csoportházirend a célgépen dönt. A Windows Server 2012 R2 tartományi működési szinttől elérhető hitelesítési házirendek és silók (authentication policy silos) a tartományvezérlő oldalán korlátozzák, mely gépekről kaphat Kerberos-jegyet egy fiók. Így a tiltás már a jegykiadáskor érvényesül, akkor is, ha egy gép házirendje valamiért nem frissült. Az eszközalapú korlátozáshoz a kliensoldali Kerberos-páncélzat (FAST) támogatása is kell.
A munkaállomások és szerverek további keményítő beállításairól a Windows hardeningről szóló cikk ír.
Protected Users csoport és a hitelesítő adatok védelme
A Windows Server 2012 R2 óta létező Protected Users biztonsági csoport tagjaira a rendszer további beállítás nélkül szigorúbb hitelesítési szabályokat alkalmaz:
- nem hitelesíthetnek NTLM-mel, csak Kerberosszal;
- a Kerberos-előhitelesítésben nem használható DES és RC4 titkosítás;
- a fiók semmilyen delegálásban nem vehet részt;
- a jegymegadó jegy (TGT) alapértelmezetten négy óráig érvényes, és nem újítható meg, utána újra hitelesíteni kell;
- a kliensen nem marad gyorsítótárazott tartományi bejelentkezési adat, és a CredSSP, valamint a WDigest nem tárol egyszerű szöveges jelszót.
A kliensoldali védelmekhez Windows 8.1 vagy Windows Server 2012 R2, illetve újabb rendszer kell, a tartományvezérlő-oldaliakhoz Windows Server 2012 R2 tartományi működési szint.
Szolgáltatásfiók és számítógépfiók nem való a csoportba. Ezeknek gyakran kell NTLM vagy delegálás, és a csoporttagság után leállnak. Az adminisztrátori fiókokat érdemes fokozatosan felvenni, mert egy csak NTLM-et ismerő régi alkalmazás ezután nem engedi be őket. A gyorsítótárazott bejelentkezés hiánya miatt egy vészhelyzeti fiók maradjon a csoporton kívül, hogy tartományvezérlő elérése nélkül is be lehessen lépni. Azoknál az adminisztrátori fiókoknál, amelyek valamiért nem lehetnek a csoport tagjai, legalább az „Account is sensitive and cannot be delegated” jelzőt érdemes bekapcsolni.
A memória védelme
A Credential Guard virtualizációalapú biztonsággal elkülöníti az NTLM-hasheket, a Kerberos jegymegadó jegyeket (TGT) és a tárolt tartományi hitelesítő adatokat, így egy helyi adminisztrátori joggal futó program sem olvassa ki őket közvetlenül. Az LSA-védelem az LSASS folyamatot védett folyamatként futtatja, így más folyamatok nehezebben olvassák a memóriáját. Távoli asztali kapcsolatnál a Remote Credential Guard és a Restricted Admin mód azt éri el, hogy a hitelesítő adat ne kerüljön át a célgépre. Restricted Admin módban viszont a munkamenet a célgépen annak helyi identitásával fut, és a Microsoft dokumentációja ezt a célgép felé pass-the-hash kockázatként tartja számon.
Ezek a technikák a memóriából való kiolvasást nehezítik. A begépelt jelszót egy kompromittált gépen a támadó továbbra is elkaphatja, ezért a rétegek szétválasztására mellettük is szükség van.
Bevezetés lépésekben, a tier-modelltől az Enterprise Access Modelig
A tier-modellt egy működő tartományban nem lehet egy hétvége alatt bevezetni. Minden szolgáltatásfiókot, ütemezett feladatot és megszokott munkafolyamatot érint. A 0. réteggel érdemes kezdeni, mert annak a fiókjai érnek a legtöbbet egy támadónak, és ott a legkevesebb a fiók.
- A 0. réteg leltára. Mely gépek, fiókok, csoportok és szolgáltatások irányíthatják a tartományt, a beágyazott csoporttagságokkal és a delegált jogokkal együtt.
- Külön fiókok és PAW a tartományi rendszergazdáknak. A régi, mindenre használt fiókoktól a 0. rétegű jogot el kell venni, a 0. rétegű csoportokban csak a dedikált fiókok maradhatnak.
- Megfigyelés a tiltás előtt. A 4624-es biztonsági események gyűjtésével kiderül, hova lépnek be ma a 0. rétegű fiókok. A 2-es bejelentkezési típus a helyi, a 10-es a távoli asztali belépést jelzi. Ami itt előkerül, az a tiltás után üzemzavart okozna, ezért előbb azt kell rendezni.
- Tiltó házirendek és Protected Users. A tiltó házirendeket először a munkaállomásokra, aztán a tagszerverekre kell kapcsolni. Ezzel együtt a 0. rétegű adminisztrátori fiókok bekerülnek a Protected Users csoportba.
- Az 1. réteg ugyanígy. Külön szerveradminisztrátori fiókok, tiltás a munkaállomásokon, a helyi adminisztrátori jelszavak kezelése LAPS-szal, hogy egy gép átvétele ne adjon hozzáférést a többihez.
Az Enterprise Access Model
A Microsoft a dokumentációjában a tier-modellt ma régi (legacy) megközelítésként tartja számon, az utódja az Enterprise Access Model. A rétegek elve megmaradt benne, szélesebb hatókörrel. A 0. rétegnek a vezérlősík (control plane) felel meg, amely a helyszíni tartomány mellett az Entra ID-t és a felhős felügyeleti felületeket is magában foglalja. Az 1. és 2. réteg helyét a felügyeleti sík, valamint az adat- és munkaterhelés-sík veszi át, és a modell külön tárgyalja a felhasználói és az alkalmazás-hozzáférés útvonalait.
Hibrid környezetben ez azt jelenti, hogy egy felhős globális adminisztrátor ugyanolyan értékes célpont, mint egy tartományi rendszergazda, és ugyanazok a szabályok vonatkoznak rá: külön fiók, védett eszköz, szűk szerepkör. A felhős oldal adminisztrátori fiókjairól a Microsoft 365 bérlő biztonsági beállításairól szóló cikk ír. A helyszíni Active Directoryban a tier-modell szabályai továbbra is érvényesek.
Kapcsolódó szolgáltatás: Active Directory felülvizsgálat és keményítés →
