LAPS, gMSA in vecnivojska administracija: trije stebri obrambe AD

Po letih prodiranja v okolja Active Directory lahko z zaupanjem rečem, da bi me tri kontrole ustavile ali bistveno upočasnile v veliki večini mojih projektov: LAPS za lokalna administratorska gesla, Group Managed Service Accounts za storitve in večnivojski administratorski model za privilegirani dostop. Posamezno vsaka odstrani kritičen vektor napada. Skupaj spremenijo okolje AD iz lahke tarče v resnično zahtevno.

Večina organizacij je slišala za te kontrole. Nekatere so delno uvedle eno ali dve. Skoraj nobena ni pravilno uvedla vseh treh. Tukaj je, kako to storiti pravilno.

Microsoftova dokumentacija opisuje upravljanje lokalnih in storitvenih gesel ter ločevanje privilegiranega dostopa. Microsoft: Windows LAPS; Microsoft: secure group managed service accounts; Microsoft: Enterprise access model.

LAPS: konec ponovne uporabe gesel med napravami

Local Administrator Password Solution zagotavlja, da ima vsaka naprava v vaši domeni edinstveno, naključno generirano lokalno administratorsko geslo. Brez LAPS organizacije običajno uporabljajo eno samo lokalno administratorsko geslo na vseh delovnih postajah, včasih tudi na strežnikih. Ko kompromitiram eno napravo in izvlečem zgoščeno vrednost lokalnega administratorja iz baze SAM, jo lahko uporabim za avtentikacijo na vsaki drugi napravi z istim geslom. To je lateralno premikanje v najpreprostejši obliki in deluje v večini okolij, ki jih testiram.

LAPS to popolnoma reši s shranjevanjem edinstvenega gesla za vsak računalnik v atributu Active Directory (ms-Mcs-AdmPwd za starejši LAPS, msLAPS-Password za Windows LAPS). Geslo se samodejno rotira po urniku, ki ga določite. Tudi če izvlečem lokalno administratorsko geslo ene naprave, je neuporabno na vsaki drugi napravi v domeni.

Kritična podrobnost uvedbe, ki jo večina organizacij zgreši, je konfiguracija ACL. Privzeto lahko gesla LAPS berejo Domain Admini. Toda pogosto najdem okolja, kjer so bila dovoljenja razširjena -- včasih lahko "Domain Users" berejo vsako geslo LAPS v domeni, kar popolnoma izniči kontrolo. Revidirajte, kdo lahko bere gesla LAPS z uporabo modula PowerShell: Find-AdmPwdExtendedRights. Omejite bralni dostop samo na specifične skupine, ki ga potrebujejo za vsak OU. Osebje pomoči uporabnikom bi moralo imeti možnost branja gesel samo za delovne postaje v svojem obsegu, ne za strežnike ali krmilnike domene.

Namestite LAPS na vsako napravo, priključeno v domeno, brez izjem. Redno ugotavljam, da 20-30% naprav nima nameščenega LAPS, ker so bile uvedene izven standardnega procesa ali ker GPO ni bil povezan z vsemi OU-ji. Uporabite PingCastle za identifikacijo naprav brez nameščenega LAPS in odpravite vrzeli.

Group Managed Service Accounts: omejitev tveganja Kerberoastinga

Tradicionalni storitveni računi so najšibkejši člen v večini okolij AD. Imajo statična gesla, ki se redko spreminjajo, ta gesla so pogosto dovolj šibka za razbijanje, računi sami pa so običajno preveč privilegirani. Kerberoasting izkorišča vse tri te slabosti hkrati.

Group Managed Service Accounts bistveno zmanjšajo tveganje zaradi šibkih, ročno upravljanih gesel. Geslo gMSA je 240 bajtov naključnih podatkov, ki jih samodejno upravlja Active Directory. Privzeto se rotira vsakih 30 dni. Gesla ni treba ročno vnašati, zaradi njegove dolžine in naključnosti pa ugibanje praviloma ni izvedljivo. Dostop do pridobivanja gesla mora biti še vedno strogo omejen. Storitev pridobi svoje geslo neposredno iz AD prek varnega kanala.

Proces migracije je za večino storitev neposreden. Ustvarite gMSA, podelite računu računalnika dovoljenje za pridobitev gesla, konfigurirajte storitev za izvajanje kot gMSA in odstranite stari storitveni račun. Microsoft SQL Server, bazeni aplikacij IIS, načrtovana opravila in večina sodobnih aplikacij nativno podpirajo gMSA. Za aplikacije, ki resnično ne morejo podpirati gMSA, uporabite dolga naključna gesla, shranjena v trezorju PAM, in jih rotirajte vsaj vsako četrtletje.

Po migraciji revidirajte svojo domeno za preostale račune s SPN-ji. Vsak račun s SPN-jem, ki ni gMSA ali račun naprave, je potencialno ranljiv za Kerberoasting. Redno poganjajte Get-ADUser -Filter {ServicePrincipalName -like '*'} in raziščite vse rezultate. Vas cilj je nič računov, ki jih upravlja človek, s SPN-ji.

Večnivojska administracija: omejevanje obsega škode

Večnivojski administratorski model, ki ga Microsoftov širši Enterprise Access Model nadgrajuje, je najvplivnejša arhitekturna sprememba, ki jo lahko naredite za varnost svojega AD. Koncept je preprost: ločite svoje okolje na tri nivoje glede na občutljivost in nikoli ne dovolite, da so poverilnice višjega nivoja izpostavljene na nižjem nivoju.

Nivo 0 je vaša infrastruktura identitete: krmilniki domene, strežniki za upravljanje AD, infrastruktura PKI in strežniki Azure AD Connect. Nivo 1 so vaši strežniki: aplikacijski strežniki, podatkovni strežniki, datotečni strežniki. Nivo 2 so vaše delovne postaje in uporabniške naprave. Temeljno pravilo je, da se administratorski račun nivoja 0 nikoli ne prijavi v sistem nivoja 1 ali 2, administratorski račun nivoja 1 pa se nikoli ne prijavi v sistem nivoja 2.

Brez razdelitve na nivoje lahko ena sama kompromitirana delovna postaja vodi do dostopa Domain Admin v nekaj urah. Tukaj je zakaj: IT administrator se prijavi na delovno postajo uporabnika za odpravljanje težav s svojim računom Domain Admin. Njegova zgoščena vrednost NTLM in vozovnice Kerberos so zdaj predpomnjene na tej delovni postaji. Ko kompromitiram delovno postajo prek lažnega sporočila ali kateregakoli drugega vektorja, izvlečem te predpomnjene poverilnice in jih uporabim za neposreden dostop do krmilnikov domene. Ta napadalna pot obstaja v skoraj vsakem nerazdeljenem okolju, ki ga testiram.

Implementacija razdelitve na nivoje zahteva ločene administratorske račune za vsak nivo. Vas račun DA-JSmith upravlja samo vire nivoja 0 in se prijavlja samo s privilegiranih delovnih postaj (PAW). Vas račun SA-JSmith upravlja strežnike nivoja 1 in se prijavlja samo s skočnih strežnikov nivoja 1. Vas navaden račun JSmith obravnava vsakodnevno delo na delovnih postajah nivoja 2. Skupinska politika uveljavlja te meje z omejevanjem pravic prijave na vsakem nivoju.

Zaznavanje in neprekinjena validacija

Uvedba teh kontrol ni dovolj. Neprekinjeno morate preverjati, da ostanejo učinkovite. Redno poganjajte BloodHound za obrambo, da identificirate nove napadalne poti, ki se lahko pojavijo ob spremembah vašega okolja. Uporabite PingCastle in Purple Knight vsako četrtletje za oceno celotne varnostnega stanja vašega AD in sledite svojemu rezultatu skozi čas.

Spremljajte kršitve vašega modela razdelitve na nivoje. Nastavite opozorila na račune nivoja 0, ki se prijavljajo v sisteme nivoja 1 ali 2 (dogodek ID 4624 in 4625 na teh napravah). Opazujte nove storitvene račune s SPN-ji, ki se ustvarjajo izven procesa gMSA. Sledite vrzelim pokritosti LAPS, ko se uvajajo nove naprave.

Te tri kontrole -- LAPS, gMSA in večnivojska administracija -- predstavljajo temelj branljivega okolja Active Directory. Niso eksotične ali drage. So vgrajene funkcije Windows, ki jih večina organizacij preprosto ni uvedla. Vsak teden, ko odlašate uvedbo, je še en teden, ko ena kompromitirana delovna postaja lahko vodi do popolne kompromitacije domene.

Povezano branje: Omejitve MFA v notranjem omrežju; Napadalna veriga v Active Directory.