Audyt uprawnień w Active Directory – jak znaleźć nadmiarowe dostępy

Dlaczego uprawnienia w AD wymykają się spod kontroli

Zjawisko nazywane permission creep (narastanie uprawnień) dotyczy niemal każdej firmy korzystającej z Active Directory od kilku lat. Pracownik zmienia dział, awansuje, przechodzi na inne stanowisko - a jego stare uprawnienia zostają, bo nikt ich nie odbiera. Do tego dochodzą konta po zwolnionych pracownikach, testowe konta administracyjne zakładane ad hoc oraz grupy zagnieżdżone w grupach, których pochodzenia nikt już nie pamięta.

Efekt jest taki, że w wielu organizacjach faktyczny zakres dostępów jest znacznie szerszy niż wynikałoby to z aktualnej struktury firmy. To nie tylko problem zgodności z RODO czy NIS2, ale realna furtka dla atakującego - im więcej kont ma szerokie uprawnienia, tym łatwiej o eskalację po przejęciu jednego z nich.

• Konta byłych pracowników wciąż aktywne w grupach z dostępem do zasobów
• Grupy zagnieżdżone w grupach (nested groups) bez udokumentowanego celu
• Konta serwisowe z uprawnieniami administratora domeny bez uzasadnienia
• Uprawnienia nadane tymczasowo na projekt, który zakończył się rok temu

Jak zrobić inwentaryzację grup i uprawnień

Audyt zaczyna się od rzetelnego spisu stanu faktycznego. Nie trzeba od razu inwestować w drogie narzędzia klasy Identity Governance - większość pracy da się wykonać natywnymi mechanizmami Windows Server.

1. Wyeksportuj listę wszystkich grup zabezpieczeń i ich członków poleceniem Get-ADGroup oraz Get-ADGroupMember w PowerShell.
2. Sprawdź uprawnienia NTFS na kluczowych zasobach sieciowych poleceniem Get-Acl lub narzędziem dsacls - porównaj je z listą osób, które faktycznie z tych zasobów korzystają.
3. Zidentyfikuj konta nieaktywne dłużej niż 90 dni (Search-ADAccount -AccountInactive) - to najczęstsze źródło zbędnych uprawnień.
4. Wypisz wszystkich członków grup uprzywilejowanych: Domain Admins, Enterprise Admins, Account Operators - te grupy powinny być praktycznie puste na co dzień.
5. Zestaw wynik z aktualną strukturą organizacyjną firmy - kto naprawdę powinien mieć dostęp do danego zasobu.

Wynik tej pracy warto zapisać w prostym arkuszu jako punkt odniesienia dla kolejnych przeglądów - bez tego każdy audyt zaczyna się od zera.

Porządkowanie zagnieżdżonych grup i modelu AGDLP

Najczęstszym źródłem chaosu są grupy dodawane do innych grup bez żadnej logiki. Warto wrócić do sprawdzonego modelu AGDLP (Account - Global - Domain Local - Permission): konta użytkowników trafiają do grup globalnych odzwierciedlających role biznesowe, te z kolei są dodawane do grup domain local, które dopiero otrzymują konkretne uprawnienia do zasobów.

W praktyce oznacza to:

• Jedna grupa globalna = jedna rola lub dział (np. Ksiegowosc-Uzytkownicy)
• Jedna grupa domain local = jeden zasób i poziom dostępu (np. DL-Serwer-Faktury-Odczyt)
• Zero uprawnień nadawanych bezpośrednio na kontach użytkowników
• Każda grupa ma przypisanego właściciela biznesowego odpowiedzialnego za jej zawartość

Uporządkowanie istniejącej struktury bywa żmudne, ale wystarczy zacząć od grup z dostępem do najbardziej wrażliwych danych - kadr, finansów, serwerów produkcyjnych - i rozszerzać porządkowanie stopniowo na resztę środowiska.

Regularny przegląd dostępów zamiast jednorazowej akcji

Jednorazowy audyt daje chwilową poprawę, ale bez cyklicznego przeglądu problem wraca w ciągu kilku miesięcy. Warto wdrożyć harmonogram, w którym właściciele grup - a więc kierownicy działów, nie dział IT - regularnie potwierdzają, kto powinien pozostać w danej grupie.

• Przegląd grup z dostępem do danych wrażliwych - co kwartał
• Przegląd pozostałych grup - co pół roku
• Przegląd kont uprzywilejowanych (administratorzy) - co miesiąc
• Automatyczne wyłączanie kont nieaktywnych powyżej ustalonego progu dni

W środowiskach hybrydowych, gdzie AD jest zsynchronizowane z chmurą, ten sam rytm warto powiązać z mechanizmem przeglądów dostępu w Entra ID, tak aby lokalne konta i role w Microsoft 365 były weryfikowane spójnie, a nie jako dwa osobne, oderwane od siebie procesy.

Monitorowanie zmian i szybkie wykrywanie nadużyć

Sam przegląd co jakiś czas to za mało - zmiany w grupach uprzywilejowanych powinny być widoczne od razu. Warto włączyć audyt zdarzeń bezpieczeństwa w zasadach grupy i śledzić kluczowe identyfikatory zdarzeń w dzienniku zdarzeń kontrolera domeny:

• 4728 / 4732 / 4756 - dodanie użytkownika do grupy globalnej, lokalnej domenowej lub uniwersalnej
• 4720 - utworzenie nowego konta użytkownika
• 4735 - zmiana właściwości grupy zabezpieczeń

W małej firmie te zdarzenia można przeglądać ręcznie raz w tygodniu, w większej warto przekierować je do centralnego systemu logowania, który wygeneruje alert w momencie dodania kogokolwiek do grupy Domain Admins poza zaplanowanym oknem zmian. To rozwiązanie znacznie tańsze niż odtwarzanie skutków po fakcie, gdy przejęte konto z nadmiarowymi uprawnieniami posłuży do rozprzestrzenienia ataku po całej sieci.