Bezpečnostní audit Active Directory: co kontrolovat a proč

Active Directory je srdcem identit ve většině firemních sítí — a zároveň jeden z prvních cílů útočníka. Stačí jeden zapomenutý privilegovaný účet nebo starý protokol a z drobné chyby je cesta k převzetí celé domény. Tenhle přehled shrnuje, co u auditu AD řeším nejčastěji, jaké bývají typické nálezy a jak audit probíhá.

Proč dělat audit Active Directory

Adresářová služba se ve firmách buduje roky a postupně se v ní nabaluje historie — staré účty, výjimky „jen dočasně", oprávnění, na která si už nikdo nepamatuje. Útočník po průniku do sítě typicky míří právě sem: hledá privilegované účty, špatně chráněná hesla a slabá místa v protokolech, kterými se dostane z běžné stanice až k řadiči domény. Cílem auditu je tahle slabá místa najít dřív, než to udělá někdo jiný, a srovnat stav s osvědčenými postupy.

Audit dává smysl před modernizací infrastruktury, po incidentu, při přebírání prostředí po jiném dodavateli nebo prostě jako pravidelná kontrola. Není to jednorázová „kontrola splněno", ale podklad pro plán nápravy seřazený podle dopadu a naléhavosti.

Co audit Active Directory zahrnuje

Komplexní audit prochází několik oblastí. Tady jsou hlavní z nich — stejné, na kterých stojí i můj interaktivní checklist auditu AD.

Účty a hesla

Správa hesel lokálních administrátorů přes LAPS (Windows LAPS), vynucená délka a kvalita hesel, politika uzamčení účtu proti password sprayingu, úklid neaktivních účtů a kontrola servisních účtů — ideálně přechod na gMSA tam, kde to jde. Pozornost si zaslouží i účty s nastavením „heslo nikdy nevyprší".

Privilegovaný přístup a tiering

Kolik účtů je ve skupinách Domain a Enterprise Admins, jestli mají administrátoři oddělené účty pro správu (ne pro běžnou práci a e-mail) a zda je zavedený tiering model (Tier 0/1/2) nebo PAW. Klíčové je, aby se účty z Tier 0 nepřihlašovaly na běžné stanice, a vícefaktorové ověření (MFA) u administrátorů a vzdáleného přístupu.

Kerberos a delegace

Rotace hesla účtu krbtgt, žádná neomezená (unconstrained) delegace, odolnost vůči Kerberoastingu (účty se SPN mají silná hesla nebo gMSA) a AS-REP roastingu, zákaz slabých šifer RC4/DES ve prospěch AES a synchronizovaný čas v doméně.

Ochrana přihlašovacích údajů a staré protokoly

Ochrana procesu LSASS (Credential Guard nebo RunAsPPL) proti dumpování hesel, omezená lokální admin práva na stanicích a žádná hesla uložená v GPP nebo skriptech v SYSVOL. Z protokolů řeším vypnutí SMBv1, NTLMv1 a LM hashů, LLMNR a NetBIOS (kvůli útokům typu Responder), vynucené LDAP signing a channel binding a vypnutý Print Spooler na řadičích domény.

Monitoring, doménové řadiče a zálohování

Centrální sběr bezpečnostních logů z řadičů (SIEM, syslog, Zabbix), auditing přihlášení a změn privilegovaných skupin a sledování podezřelých událostí (DCSync, Golden Ticket, hromadné uzamčení účtů). U řadičů aktuální záplaty, dedikovaná role a redundance. A nakonec to, na co se nejčastěji zapomíná: pravidelná záloha AD (System State), otestovaný plán obnovy lesa a offline/immutable kopie odolná vůči ransomwaru.

Nejčastější nálezy v praxi

• Příliš mnoho účtů v Domain Admins a admini, kteří se stejným účtem čtou e-maily i spravují řadiče.
• Hesla lokálních adminů stejná napříč stanicemi (chybí LAPS) — ideální pro boční pohyb útočníka.
• Stále zapnutý SMBv1, NTLMv1 nebo LLMNR, nevynucené LDAP signing.
• Účty se SPN se slabým heslem (riziko Kerberoastingu) a neměněný krbtgt.
• Žádný centrální sběr logů, takže incident není kde dohledat.
• Záloha AD existuje, ale obnova lesa nikdy nebyla otestovaná.

Jak audit probíhá

Obvykle ve čtyřech krocích: sběr dat (čtení konfigurace AD, GPO, oprávnění a logů, většinou jen pro čtení), vyhodnocení proti osvědčeným postupům, sestavení reportu s nálezy seřazenými podle rizika a předání konkrétního plánu nápravy. Podle dohody pak pomohu nápravu i realizovat, nebo ji předám vašemu týmu či technologickému partnerovi.