Model warstw w Active Directory: Tier 0 w praktyce

Większość przejęć domeny, które widziałem, nie zaczyna się od exploita na kontrolerze domeny. Zaczyna się od stacji roboczej, na której ktoś kiedyś zalogował się kontem o wysokich uprawnieniach, albo od serwera aplikacyjnego, na którym działa usługa z kontem należącym do grupy administratorów domeny. Reszta jest już tylko podążaniem ścieżką, którą organizacja sama zbudowała.

Model warstw jest odpowiedzią na ten problem. Nie polega na tym, żeby „bardziej chronić kontrolery domeny”, tylko na tym, żeby poświadczenia uprzywilejowane nigdy nie pojawiały się w miejscach, których nie da się obronić. To zmiana organizacyjna wsparta konfiguracją, a nie produkt do kupienia.

Zasada czystego źródła

Punkt wyjścia jest jedno zdanie: obiekt jest tak bezpieczny, jak najsłabszy podmiot, który ma nad nim kontrolę. Jeżeli kontroler domeny jest zarządzany przez system dystrybucji oprogramowania, to bezpieczeństwo kontrolera równa się bezpieczeństwu tego systemu. Jeżeli kopie zapasowe kontrolera trafiają na serwer, do którego dostęp ma dziesięć osób, to bezpieczeństwo domeny równa się bezpieczeństwu tego serwera, bo z kopii można odtworzyć bazę tożsamości.

To rozumowanie prowadzi do wniosku, który dla wielu zespołów jest zaskakujący: granica Tier 0 nie przebiega tam, gdzie stoją kontrolery domeny, tylko tam, gdzie kończy się zdolność do wykonania kodu lub zmiany konfiguracji na kontrolerach.

Trzy warstwy

Podział klasyczny wygląda następująco.

Tier 0 obejmuje tożsamość i kontrolę nad nią: kontrolery domeny, konta i grupy o prawach na poziomie domeny lub lasu, infrastrukturę certyfikatów, systemy federacji i synchronizacji z chmurą, a także wszystko, co pośrednio potrafi te systemy przejąć.

Tier 1 to serwery, aplikacje i dane biznesowe. Administrator tej warstwy zarządza serwerami aplikacyjnymi i bazami, ale nie ma żadnej ścieżki do przejęcia tożsamości.

Tier 2 to stacje robocze i konta użytkowników wraz z zespołem wsparcia, który je obsługuje.

Reguła kierunkowa brzmi: konto z warstwy wyższej nigdy nie loguje się interaktywnie do systemu z warstwy niższej, a system z warstwy niższej nigdy nie kontroluje systemu z warstwy wyższej. Administrowanie odbywa się z góry w dół, ale bez pozostawiania poświadczeń w niższej warstwie — to rozróżnienie jest sednem, bo zdalne logowanie do stacji użytkownika kontem administratora domeny łamie model nawet wtedy, gdy „to tylko na chwilę, żeby pomóc”.

Nowsze ujęcie Microsoftu, opisane jako model dostępu przedsiębiorstwa, dzieli świat na płaszczyznę kontroli, płaszczyznę zarządzania i płaszczyznę danych oraz jawnie włącza tożsamość w chmurze. To ważna aktualizacja, bo w środowisku hybrydowym role uprzywilejowane w katalogu chmurowym są częścią Tier 0, niezależnie od tego, gdzie stoją serwery.

Co naprawdę należy do Tier 0

Ta lista jest dłuższa, niż sądzi większość organizacji. Poza kontrolerami domeny i kontami z prawami domenowymi należą do niej:

Urząd certyfikacji i szablony certyfikatów, ponieważ możliwość wystawienia certyfikatu uwierzytelniającego dla dowolnego podmiotu jest równoważna posiadaniu jego hasła.

Systemy zarządzania konfiguracją i dystrybucji oprogramowania, jeśli obejmują zasięgiem kontrolery domeny — wykonują kod jako system lokalny na każdym zarządzanym hoście.

Systemy kopii zapasowych obejmujące kontrolery, bo kopia bazy katalogu to kopia wszystkich sekretów.

Warstwa wirtualizacji, na której działają kontrolery, wraz z konsolą zarządzania — administrator hipernadzorcy ma dostęp do pamięci maszyny.

Agenci działający na kontrolerach: monitoring, EDR, inwentaryzacja, harmonogramy zadań. Każdy agent z możliwością zdalnego uruchomienia polecenia jest ścieżką do wykonania kodu na kontrolerze, a jego serwer zarządzający należy do Tier 0.

Zasady grup powiązane z jednostkami organizacyjnymi Tier 0 oraz konta z prawem do ich edycji.

Systemy zarządzania dostępem uprzywilejowanym i skarbce haseł, jeżeli przechowują poświadczenia Tier 0.

Konta i grupy z prawami zapisu na obiektach powyższych systemów — to najczęściej pomijana kategoria, bo uprawnienie nadane lata temu przez delegację nie jest widoczne w składzie grup, tylko w listach kontroli dostępu.

Test pomocniczy jest prosty: jeżeli kompromitacja danego systemu pozwala wykonać kod na kontrolerze domeny, odtworzyć jego dane albo wystawić poświadczenia w jego imieniu, to ten system jest Tier 0. Nie ma znaczenia, że w rejestrze aktywów figuruje jako „narzędzie IT”.

Typowe błędy, które kasują cały model

Konto serwisowe z prawami domenowymi. Usługa uruchamiana na kilkudziesięciu serwerach kontem należącym do grupy administratorów domeny sprawia, że przejęcie dowolnego z tych serwerów kończy sprawę.

Jedno konto administracyjne do wszystkiego. Administrator używa tego samego konta do logowania na stację, do serwerów aplikacyjnych i do kontrolerów. Model warstw wymaga oddzielnych kont per warstwa, bez wyjątków dla wygody.

Wspólne hasło lokalnego administratora. Identyczne hasło na wszystkich stacjach zamienia jedno przejęcie w dostęp poziomy do całej floty. Rozwiązaniem jest mechanizm losowania i rotacji haseł lokalnych.

Wsparcie z prawem do kont uprzywilejowanych. Zespół obsługujący użytkowników, który może zresetować hasło konta administracyjnego, faktycznie należy do Tier 0, choć w schemacie organizacyjnym jest w Tier 2.

Delegacje w Active Directory bez przeglądu. Uprawnienia nadane pojedynczym obiektom kumulują się latami i nikt ich nie odwołuje. To najczęstsze źródło ścieżek eskalacji, których nie widać w składzie grup.

Logowanie „na chwilę”. Zdalna pomoc udzielona kontem uprzywilejowanym na stacji użytkownika zostawia materiał uwierzytelniający w pamięci systemu, do którego atakujący ma już dostęp.

Egzekwowanie techniczne

Sam podział na papierze nie działa; potrzebne są mechanizmy, które łamanie modelu czynią niemożliwym, a nie tylko zabronionym.

Blokada logowania między warstwami realizowana przez przypisanie praw użytkownika w zasadach grup: konta Tier 0 mają jawnie odmówione logowanie lokalne, sieciowe i przez usługi pulpitu zdalnego na systemach Tier 1 i Tier 2. To jest fundament, od którego zaczyna się wdrożenie.

Zasady uwierzytelniania i silosy pozwalają związać konto z konkretnym zbiorem systemów: bilet dla konta Tier 0 jest wydawany tylko wtedy, gdy żądanie pochodzi z hosta należącego do silosu. To znacznie mocniejsza kontrola niż same zasady grup, bo działa po stronie protokołu uwierzytelniania.

Grupa użytkowników chronionych wyłącza dla członków słabsze mechanizmy uwierzytelniania i skraca czas życia biletów, ograniczając wartość wykradzionego materiału.

Wydzielona struktura jednostek organizacyjnych dla Tier 0 z wyczyszczonymi delegacjami i wyłączonym dziedziczeniem uprawnień, tak aby konta niższych warstw nie miały praw zapisu na obiektach warstwy najwyższej.

Ograniczenia sieciowe na kontrolerach: zarządzanie wyłącznie z dedykowanych stacji administracyjnych, a nie z całej sieci biurowej.

Stacje uprzywilejowane jako obowiązkowy punkt startowy dla administrowania Tier 0: osobny sprzęt lub osobna maszyna, bez poczty, bez przeglądania internetu, z ograniczoną listą dozwolonego oprogramowania. To niewygodne i to jest cena za usunięcie najczęstszej ścieżki ataku, czyli phishingu na stację administratora.

Konta usług zarządzane przez grupę zamiast kont serwisowych z hasłem znanym człowiekowi, oraz rotacja haseł kont lokalnych.

Migracja bez przestoju

Wdrożenie modelu warstw w działającej organizacji jest projektem, nie zmianą konfiguracji. Kolejność ma znaczenie, ponieważ zbyt wczesne włączenie blokad kończy się awarią i wycofaniem całej inicjatywy.

Etap pierwszy: widoczność. Ustal, kto loguje się na kontrolery domeny i inne systemy Tier 0, jakie konta usług tam działają, które systemy zarządzające mają na nich agentów oraz jakie uprawnienia zostały delegowane na obiektach. Wynikiem jest lista faktycznych ścieżek kontroli, zwykle dłuższa od oczekiwań.

Etap drugi: konta. Utwórz oddzielne konta administracyjne dla każdej warstwy i przenieś na nie codzienną pracę. Na tym etapie nic jeszcze nie blokujesz — pozwalasz zespołom przyzwyczaić się do pracy na właściwych kontach.

Etap trzeci: usługi. Zamień konta serwisowe z prawami domenowymi na konta o minimalnych uprawnieniach lub konta zarządzane. To najbardziej pracochłonny etap i najczęstsze źródło opóźnień, bo wymaga współpracy z właścicielami aplikacji.

Etap czwarty: stacje administracyjne. Wprowadź dedykowane stacje dla Tier 0 i przenieś na nie administrowanie kontrolerami.

Etap piąty: egzekwowanie. Dopiero teraz włącz blokady logowania między warstwami, najpierw w trybie obserwacji, potem w trybie wymuszania, warstwa po warstwie.

Etap szósty: czyszczenie. Odwołaj zbędne delegacje, usuń konta tymczasowe, ogranicz członkostwa w grupach uprzywilejowanych do wartości bliskiej zeru w stanie spoczynku i wprowadź podnoszenie uprawnień na czas.

Każdy etap powinien mieć zdefiniowane kryterium wyjścia i plan wycofania. Konta awaryjne, przechowywane w sposób fizycznie zabezpieczony i monitorowane, są warunkiem koniecznym — model warstw bez konta ratunkowego to gotowy scenariusz odcięcia się od własnej domeny.

Weryfikacja i detekcja

Model warstw weryfikuje się dwoma sposobami. Pierwszy to analiza ścieżek — mapowanie relacji uprawnień w katalogu i sprawdzanie, czy z warstwy niższej istnieje jakakolwiek droga do warstwy wyższej. Taka analiza znajduje to, czego nie widać w schemacie organizacyjnym: delegacje, prawa zapisu, zagnieżdżone grupy i uprawnienia na szablonach certyfikatów.

Drugi to ćwiczenie zespołowe, w którym zespół ofensywny startuje z pozycji przeciętnej stacji roboczej i sprawdza, jak daleko dojdzie, a zespół obrony sprawdza, co z tego zobaczył.

Po stronie detekcji warto monitorować kilka konkretnych zdarzeń: logowanie konta Tier 0 na systemie spoza Tier 0 — w dojrzałym środowisku to zdarzenie nie powinno występować nigdy; zmiany w składzie grup uprzywilejowanych; zmiany w konfiguracji szablonów certyfikatów; nowe delegacje uprawnień na obiektach; nietypowe operacje replikacji katalogu; utworzenie konta z prawem do logowania na kontrolerze.

Wartość tych reguł bierze się z tego, że w poprawnie wdrożonym modelu warstw generują one bardzo mało szumu. Zdarzenie, które nie powinno wystąpić nigdy, jest najlepszym możliwym sygnałem.

Warstwy w środowisku hybrydowym

Jeżeli katalog lokalny jest synchronizowany z chmurą, granica Tier 0 rozszerza się w obie strony. Serwer synchronizacji jest systemem Tier 0, ponieważ ma dostęp do materiału uwierzytelniającego. Role uprzywilejowane w katalogu chmurowym są odpowiednikiem grup domenowych i wymagają tego samego reżimu: oddzielne konta, dostęp na czas, silne uwierzytelnianie odporne na phishing i administrowanie ze stacji uprzywilejowanej.

Warto też przemyśleć kierunek zaufania. Konto chmurowe z rolą zarządzania urządzeniami potrafi wykonać kod na stacjach, a więc realnie należy do wyższej warstwy niż wynika z jego nazwy.

Najczęstsze obiekcje i odpowiedzi na nie

Wdrożenie modelu warstw rzadko blokuje się na technice. Blokuje się na rozmowie, więc warto mieć przygotowane odpowiedzi.

„To spowolni pracę administratorów.” Spowolni operacje wykonywane kontem uprzywilejowanym — i o to chodzi, bo tych operacji powinno być mało. Codzienna praca odbywa się na koncie zwykłym i nie zmienia się wcale. Realny koszt to logowanie na osobną stację przy zadaniach dotyczących tożsamości, czyli kilka razy w tygodniu, a nie kilkadziesiąt razy dziennie.

„Mamy już uwierzytelnianie wieloskładnikowe, to wystarczy.” Drugi składnik chroni przed użyciem wykradzionego hasła. Nie chroni przed przejęciem sesji już uwierzytelnionej ani przed materiałem uwierzytelniającym pozostawionym w pamięci systemu, na którym ktoś się zalogował. To są różne warstwy problemu i drugi składnik nie zastępuje separacji.

„Kupiliśmy rozwiązanie do zarządzania dostępem uprzywilejowanym.” Dobrze, ale skarbiec haseł rozwiązuje przechowywanie i rozliczalność, a nie ekspozycję. Jeżeli konto pobrane ze skarbca loguje się na stację użytkownika, poświadczenie i tak trafia w niebezpieczne miejsce.

„Nie mamy zasobów na osobne stacje.” Punkt startowy nie musi być kosztowny: wydzielona maszyna wirtualna z ograniczonym dostępem sieciowym, bez poczty i przeglądarki, dostępna tylko dla administratorów Tier 0, jest znaczącym postępem względem administrowania z laptopa z pocztą.

„Zrobimy to przy okazji migracji.” Migracje przesuwają się latami, a lista ścieżek eskalacji rośnie w tym czasie. Etapy pierwszy i drugi — widoczność i rozdzielenie kont — nie zależą od żadnej migracji i można je wykonać od razu.

Checklista

Istnieje spisana lista systemów Tier 0 i jest przeglądana przy każdej zmianie architektury. Konta administracyjne są oddzielne dla każdej warstwy. Konta Tier 0 mają zablokowane logowanie na systemach niższych warstw. Administrowanie Tier 0 odbywa się wyłącznie ze stacji uprzywilejowanych. Konta usług nie należą do grup domenowych. Hasła lokalnych administratorów są losowe i rotowane. Delegacje na obiektach katalogu są zinwentaryzowane i przeglądane. Kopie zapasowe i wirtualizacja kontrolerów są traktowane jako Tier 0. Role uprzywilejowane w chmurze podlegają temu samemu reżimowi. Istnieją konta awaryjne z procedurą użycia i monitoringiem. Ścieżki eskalacji są okresowo analizowane narzędziowo.

Wniosek

Tiering nie jest projektem o kontrolerach domeny. Jest projektem o tym, gdzie lądują poświadczenia i kto może wykonać kod na systemach, od których zależy tożsamość. Organizacje, które wdrożyły go rzetelnie, mają tę własność, że pojedyncze przejęcie stacji roboczej pozostaje incydentem lokalnym, a nie pierwszym krokiem do szyfrowania całego środowiska.

Najtrudniejsza część nie jest techniczna. Jest nią uczciwa inwentaryzacja tego, co faktycznie kontroluje domenę — bo prawie zawsze okazuje się, że lista jest dłuższa, a granica warstwy najwyższej przebiega przez systemy, których nikt tak nie klasyfikował.

Źródła pierwotne: Microsoft Learn — Enterprise access model, Microsoft Learn — Privileged access devices, Microsoft Learn — Protected Users security group.