Tiering administracyjny w Active Directory – jak chronić domenę przed przejęciem uprawnień administratora
Tiering administracyjny w Active Directory – jak chronić domenę przed przejęciem uprawnień administratora
Jednym z największych błędów popełnianych podczas projektowania bezpieczeństwa Active Directory jest traktowanie wszystkich kont administracyjnych tak samo.
W wielu firmach wygląda to podobnie:
Administrator domeny loguje się tym samym kontem do:
- kontrolera domeny,
- komputera użytkownika,
- serwera aplikacji,
- stacji roboczej działu IT.
Na pierwszy rzut oka jest to wygodne.
Problem pojawia się wtedy, gdy jedna z tych maszyn zostanie zainfekowana.
Jeżeli administrator zalogował się tam kontem posiadającym wysokie uprawnienia, atakujący może przejąć jego poświadczenia i wykorzystać je do eskalacji uprawnień w całej domenie.
Właśnie przed takim scenariuszem ma chronić Administrative Tiering Model, czyli model warstwowego zarządzania uprawnieniami administracyjnymi w Active Directory.
To nie jest pojedyncza funkcja Windows Server. To sposób projektowania całej architektury bezpieczeństwa domeny.
Czym jest administracyjny tiering?
Tiering oznacza podział środowiska na poziomy zaufania.
Idea jest prosta:
Im bardziej krytyczny zasób, tym bardziej izolowane powinno być konto administracyjne używane do jego obsługi.
Administrator zarządzający kontrolerami domeny nie powinien używać tego samego konta do:
- poczty,
- przeglądania internetu,
- administracji zwykłymi komputerami.
Każda warstwa powinna mieć własne konta, własne zasady logowania i własne ograniczenia.
Dlaczego zwykły model administracji jest niebezpieczny?
Załóżmy typową sytuację.
Administrator posiada konto:
admin.marek
należące do:
Domain Admins
Używa go codziennie do:
- zarządzania serwerami,
- instalacji programów,
- pomocy użytkownikom,
- logowania na własnym komputerze.
Pewnego dnia jego komputer zostaje zainfekowany malware.
Atakujący może wykorzystać:
- pamięć procesu,
- zapisane tokeny,
- bilety Kerberos,
- poświadczenia w systemie.
Jeżeli znajdzie dane konta Domain Admin, droga do całej domeny stoi otworem.
To jeden z najczęstszych scenariuszy ataków typu Pass-the-Hash, Pass-the-Ticket lub kradzieży tokenów uwierzytelniających.

Klasyczny model trzech poziomów administracji
Najczęściej stosowany model składa się z trzech warstw.
Tier 0 – infrastruktura krytyczna
To najwyższy poziom zaufania.
Obejmuje zasoby, które kontrolują całą domenę.
Przykłady:
- kontrolery domeny,
- Active Directory Domain Services,
- Active Directory Federation Services,
- PKI,
- systemy zarządzania tożsamością,
- konta Domain Admin,
- konta Enterprise Admin.
Konta Tier 0 mogą przejąć praktycznie całe środowisko.
Dlatego:
- nie powinny logować się na zwykłych komputerach,
- nie powinny być używane do poczty,
- nie powinny służyć do codziennej pracy.
Tier 1 – serwery i aplikacje
Drugi poziom obejmuje systemy biznesowe.
Przykłady:
- serwery plików,
- serwery baz danych,
- serwery aplikacyjne,
- Hyper-V,
- SQL Server.
Administrator Tier 1 może zarządzać serwerami, ale nie powinien posiadać uprawnień do kontrolerów domeny.
Przykład:
Administrator SQL:
może:
- restartować usługę SQL,
- zarządzać bazą,
- konfigurować serwer.
Nie powinien:
- dodawać użytkowników domenowych,
- zmieniać polityk AD,
- zarządzać Domain Admin.
Tier 2 – stacje robocze
Najniższy poziom administracji.
Obejmuje:
- komputery użytkowników,
- helpdesk,
- lokalną administrację PC.
Przykłady zadań:
- instalacja oprogramowania,
- konfiguracja drukarek,
- resetowanie problemów użytkownika.
Konto Tier 2 nie powinno mieć dostępu do serwerów ani domeny.
Jak wygląda poprawny podział kont?
Administrator często powinien posiadać kilka kont.
Przykład:
Konto zwykłe
marek.nowak
Do:
- poczty,
- dokumentów,
- codziennej pracy.
Konto Tier 2
marek.nowak.t2
Do:
- zarządzania komputerami użytkowników.
Konto Tier 1
marek.nowak.t1
Do:
- administracji serwerami.
Konto Tier 0
marek.nowak.t0
Do:
- Active Directory,
- kontrolerów domeny.
Takie podejście może wydawać się niewygodne.
Jednak właśnie ta niedogodność jest elementem bezpieczeństwa.
Zasada: nigdy nie loguj się niższym poziomem do wyższego
Tiering działa w jedną stronę.
Administrator Tier 0 może zarządzać Tier 1 i Tier 2.
Ale:
Administrator Tier 2 nie powinien mieć możliwości wejścia na Tier 1.
Administrator Tier 1 nie powinien mieć dostępu do Tier 0.
Dlaczego?
Ponieważ niższa warstwa jest bardziej narażona.
Komputer użytkownika:
- ma więcej aplikacji,
- korzysta z internetu,
- otwiera dokumenty,
- jest częstszym celem ataków.
Kontroler domeny powinien być znacznie bardziej izolowany.
Techniczne mechanizmy realizujące tiering
Sam podział kont nie wystarczy.
W praktyce stosuje się dodatkowe zabezpieczenia.
Restricted Groups i Group Policy
Za pomocą zasad grupowych można ograniczyć:
- kto może logować się lokalnie,
- kto może korzystać z RDP,
- kto może wykonywać administrację.
Przykład:
Tylko:
Tier0 Admins
mogą logować się na kontrolery domeny.
Logon Restrictions
Active Directory pozwala ograniczać miejsca logowania kont.
Przykład:
Konto:
admin.t0
może logować się tylko na:
DC01
DC02
Nie może wejść na:
PC123
LAPTOP45
Privileged Access Workstations (PAW)
Jednym z najważniejszych elementów nowoczesnego modelu bezpieczeństwa są specjalne stacje administracyjne.
PAW to komputer przeznaczony wyłącznie do administracji.
Nie służy do:
- poczty,
- internetu,
- pracy biurowej.
Administrator Tier 0 wykonuje zadania tylko z takiej stacji.
Dzięki temu ogranicza się ryzyko kradzieży poświadczeń.
Just Enough Administration (JEA)
Microsoft rozwija również podejście:
Just Enough Administration
czyli:
„wystarczająca administracja”.
Administrator otrzymuje tylko te możliwości, które są potrzebne.
Przykład:
Operator może:
- restartować usługę,
- sprawdzić status serwera.
Ale nie może:
- uruchomić PowerShell jako administrator domeny,
- zmienić konfiguracji zabezpieczeń.
Tiering a Kerberos
Active Directory opiera się na Kerberos.
Atakujący często próbuje zdobyć:
- bilety Kerberos,
- hash haseł,
- tokeny dostępu.
Jeżeli administrator Tier 0 loguje się na zwykłym komputerze, jego dane uwierzytelniające mogą zostać przechwycone.
Dlatego izolacja kont administracyjnych jest tak ważna.
Tiering i Microsoft Defender for Identity
W środowiskach firmowych analiza poziomów administracyjnych jest często wspierana przez narzędzia bezpieczeństwa.
Przykładowo:
- Microsoft Defender for Identity,
- SIEM,
- systemy EDR.
Mogą wykrywać:
- nietypowe logowania,
- użycie kont uprzywilejowanych,
- próby eskalacji,
- ruch boczny w sieci.
Najczęstsze błędy podczas wdrażania tieringu
Jedno konto administratora do wszystkiego
Najczęstszy problem.
Administrator domeny loguje się na komputerze użytkownika
Bardzo ryzykowne.
Brak osobnych kont serwisowych
Usługi uruchomione na kontach uprzywilejowanych mogą stać się celem ataku.
Brak kontroli członkostwa grup
Grupy takie jak:
Domain Admins
Enterprise Admins
Administrators
powinny być regularnie audytowane.
Czy tiering jest potrzebny w małej firmie?
Nie każda firma potrzebuje pełnej architektury jak korporacja.
Jednak podstawowe zasady warto stosować zawsze:
- osobne konto administracyjne,
- brak używania kont uprzywilejowanych do codziennej pracy,
- ograniczenie logowania administratorów,
- MFA dla kont uprzywilejowanych,
- regularny audyt grup.
Nawet kilka prostych zmian znacząco podnosi bezpieczeństwo.
Podsumowanie
Administracyjny tiering w Active Directory nie polega na komplikowaniu życia administratorom. Jego celem jest ograniczenie skutków jednego z najgroźniejszych scenariuszy:
przejęcia konta osoby posiadającej wysokie uprawnienia.
Dobrze zaprojektowany model zakłada, że:
- konto użytkownika służy do pracy,
- konto Tier 2 zarządza komputerami,
- konto Tier 1 zarządza serwerami,
- konto Tier 0 kontroluje infrastrukturę tożsamości.
Najważniejsza zasada brzmi:
Administrator nie powinien używać najpotężniejszego klucza do otwierania każdych drzwi. Powinien posiadać dokładnie taki klucz, jaki jest potrzebny do wykonania konkretnego zadania.
To właśnie podejście odróżnia zwykłą administrację Active Directory od świadomego projektowania bezpieczeństwa środowiska Windows.






