Active Directory Hardening – Deo 2: Group Policy i delegiranje ovlašćenja

U prvom delu serije pokrili smo tier model, privilegovane naloge i protokole autentifikacije. Drugi deo se bavi dvema temama koje su podjednako bitne, a mnogo ređe se ozbiljno proveravaju: Group Policy objekti (GPO) i delegiranje ovlašćenja unutar organizacionih jedinica (OU). Obe teme imaju zajedničku osobinu — greške se ovde ne prave namerno, već se akumuliraju godinama, kroz "privremena" rešenja koja niko ne ukloni.

Zašto su GPO i delegacija toliko osetljivi

Group Policy je mehanizam kojim se centralno primenjuju bezbednosna podešavanja na hiljade računara odjednom — što ga čini izuzetno korisnim alatom za administraciju, ali i izuzetno atraktivnom metom. Ko god može da menja ili poveže GPO na Organizational Unit gde se nalaze domain kontroleri ili serveri, taj u praksi ima ekvivalent Domain Admin ovlašćenja, čak i ako formalno nije član te grupe.

Isti princip važi i za delegaciju: ako je neko davno dobio pravo da resetuje lozinke u jednom OU-u "da pomogne kolegi iz IT podrške", a to pravo nikad nije uklonjeno niti ograničeno, taj nalog predstavlja rizik koji standardna revizija članstva u Domain Admins grupi neće ni otkriti — jer se taj nalog nikad nije ni nalazio u toj grupi.

Group Policy — bezbednosna podešavanja

Polazna tačka za hardening GPO-a nije pisanje politika od nule, već korišćenje Microsoft-ovih Security Baseline predložaka (Security Compliance Toolkit) kao osnove, a zatim prilagođavanje specifičnim potrebama okruženja. Baseline dolazi sa dokumentacijom koja objašnjava svako podešavanje, što uveliko olakšava i sam proces revizije.

Posebnu pažnju zaslužuje User Rights Assignment (URA) sekcija u Default Domain Controllers Policy — ovo je deo koji se u praksi retko čisti, pa se u njemu često zadrže dodeljena prava nalozima koji više ne postoje, ugašenim servisnim nalozima ili grupama koje odavno nemaju razlog da tu budu.

Šta treba uraditi

• Preuzeti najnoviji Microsoft Security Baseline za odgovarajuću verziju Windows Server-a i koristiti ga kao referentnu tačku, ne kao gotovo rešenje koje se primenjuje bez provere
• Proveriti User Rights Assignment u Default Domain Controllers Policy i ukloniti zastarele ili neobjašnjive dodele prava
• Ograničiti ko sme da uređuje i da povezuje (link) GPO-ove — ovo pravo mora da bude podjednako strogo čuvano kao i članstvo u Domain Admins grupi
• Uvesti proces odobravanja za izmene GPO-a (change control), bilo kroz alat poput Advanced Group Policy Management (AGPM) ili kroz jednostavniji proces: izmene radi samo dedikovan nalog sa PAW-a, uz obavezan tiket u sistemu za upravljanje promenama
• Pratiti Event ID 5136 (izmena objekta u direktorijumu) filtriran na GPO kontejnere, kako bi se svaka izmena GPO-a mogla naknadno rekonstruisati
• Redovno praviti backup GPO-ova i porediti verzije, da bi se neovlašćene izmene mogle otkriti i van standardnog audit loga

Napomena o riziku: primena Microsoft Security Baseline-a i uklanjanje "zastarelih" dodela u User Rights Assignment mogu prekinuti rad servisa, zakazanih poslova ili starijih aplikacija koje se, ispostaviće se, oslanjaju baš na to pravo koje je delovalo neobjašnjivo. Pre primene baseline-a na produkcione domain kontrolere, obavezno ga prvo testirati u odvojenom OU-u ili test okruženju, i svaku URA dodelu koja se uklanja dokumentovati pre brisanja, kako bi se izmena mogla brzo vratiti ako nešto prestane da radi.

Delegiranje ovlašćenja — OU struktura

Dobra OU struktura je preduslov za bezbedno delegiranje. Ako su korisnici, računari i servisni nalozi razbacani po istim organizacionim jedinicama bez logike, delegacija po definiciji mora da bude ili preširoka, ili se uopšte ne primenjuje.

Najčešća greška koju viđamo na tehničkim proverama jeste korišćenje ugrađenih (built-in) grupa poput Account Operators ili Server Operators za delegaciju. Ove grupe imaju veoma široka, unapred definisana ovlašćenja na nivou celog domena i ne mogu se suziti na jedan OU — dodeljivanjem članstva u njima se gotovo uvek daje mnogo više prava nego što je zadatak zahtevao.

Ispravan pristup je suprotan: kreirati namensku bezbednosnu grupu za svaki konkretan zadatak (npr. "HelpDesk-ResetPassword-Prodaja"), dodeliti joj tačno određena prava na tačno određenom OU-u kroz Delegation of Control Wizard ili dsacls, i u tu grupu dodavati naloge — nikad direktno na nivou pojedinačnog korisnika.

Šta treba uraditi

• Nikad ne koristiti Domain Admins, Account Operators, Server Operators ili slične ugrađene grupe za rutinske zadatke delegacije
• Za svaki delegiran zadatak kreirati posebnu, imenovanu bezbednosnu grupu sa jasno opisanom svrhom (npr. u nazivu grupe navesti i zadatak i OU na koji se odnosi)
• Delegirati prava isključivo grupama, nikad pojedinačnim nalozima — pojedinačna delegacija se vremenom gubi iz vida i teško je za audit
• Voditi "katalog delegacija" — jednostavnu evidenciju koja beleži koji zadaci postoje, koja prava su za njih dodeljena i na kom OU-u važe
• Periodično (bar jednom godišnje) proći kroz sve delegacije u domenu i ukloniti one za koje niko ne može da objasni trenutnu poslovnu potrebu

Skriveni administratori (shadow admins)

Shadow admin je nalog, grupa ili servisni princip koji može da postigne efekat administratorskog naloga — na primer da izmeni članstvo privilegovane grupe, preuzme kontrolu nad GPO-om ili resetuje lozinku administratora — a da pritom formalno nije član nijedne od očigledno privilegovanih grupa. Ovakvi nalozi se najčešće kriju u ugnježdenim (nested) grupama, u zaboravljenim OU delegacijama ili u ACL listama na osetljivim objektima poput domain root-a, AdminSDHolder objekta ili same Domain Controllers OU jedinice.

Ako je AD u vašoj organizaciji godinama "pažljivo" delegiran, a nikad sistematski revidiran, realno je pretpostaviti da shadow admin nalozi postoje dok se suprotno ne dokaže proverom.

Šta treba uraditi

• Izvući punu, tranzitivnu listu članstva svih privilegovanih grupa (uključujući ugnježdene grupe) i uporediti je sa prethodnim izveštajem — svaka nova, neobjašnjena promena zaslužuje proveru
• Proveriti ACL liste na domain root objektu, na AdminSDHolder objektu i na Domain Controllers OU jedinici, i ukloniti svaki nalog ili grupu koja tu ne pripada
• Posebno proveriti da li su poslovne (ne-IT) grupe greškom ugnježdene u privilegovane grupe — ovo je čest, a lako previdiv nalaz
• Uvesti fine-grained password policy sa strožim zahtevima (duža minimalna lozinka, kraći maksimalni vek lozinke, niži prag za lockout) posebno za privilegovane naloge poput Domain Admins i Enterprise Admins

U sledećem delu serije prelazimo na Kerberos — Kerberoasting, zaštitu servisnih naloga i podešavanja koja se tiču delegacije autentifikacije (constrained i unconstrained delegation), gde se često kriju neke od najozbiljnijih, a najređe pronađenih ranjivosti u AD okruženju.