W dzisiejszym artykule opiszemy dobre praktyki zabezpieczania dostępu i konfiguracji kontrolerów domeny AD – czyli najważniejszych serwerów w firmie.

Jeśli często odwiedzasz nasz portal to z pewnością wiesz, że dużo piszemy o bezpieczeństwie Active Directory w kampaniach oraz dedykowanych artykułach. Publikowaliśmy też informacje o specjalnej akcji „Zabarykadowania AD w firmie”, szczególnie ważnej w tych trudnych czasach, wojny i odbywających się nasilonych atakach na infrastrukturę informatyczną. Szczegóły opisaliśmy w artykule pt. „Jak zabezpieczyłeś Active Directory na wypadek ataku?”
Dzisiejszy artykuł poświęcony jest dobrym praktykom zabezpieczania dostępu i konfiguracji kontrolerów domeny AD, które pozwolą jeszcze bardziej zabezpieczyć środowisko domenowe AD. Przy czym odpuściliśmy w nim opisywanie jaką rolę w firmie pełni kontroler domeny, czym skutkuje jego przejęcie i co to jest Active Directory, bo pewnie doskonale o tym wiesz Drogi Czyteniku. Jak nie to zapraszamy do naszych wcześniejszych artykułów ?


Active Directory w hybrydzie z Azure AD

Od ostatnich kilku lat obserwujemy wśród firm posiadających usługi katalogowe AD trend zmierzający w kierunku korzystania z platformy tożsamości opartej na chmurze, takiej jak Azure Active Directory. Dzięki temu firmy mogą korzystać z nowszych metod uwierzytelniania, takich jak uwierzytelnianie bez hasła, korzystania z dostępu warunkowego w celu wymuszania metodyki zerowego zaufania (Zero Trust) i dążenia do zmniejszenia obecności lokalnej infrastruktury sprzętowej i serwerowej przez wycofywanie lokalnego Active Directory. Nie oznacza to, że pozbywają się one lokalnego Active Directory. Wręcz tworzą hybrydę, która jest i nadal będzie dla wielu klientów ważnym elementem jeszcze przez długi czas. Trzeba wiedzieć, że również w takiej architekturze kontrolery domeny nadal działają jako kluczowy element infrastruktury, a tożsamości przechowywane w usłudze Active Directory są często celem atakujących. O bezpieczeństwie w chmurze Azure AD jeszcze napiszemy, lecz dzisiaj skupimy się na bezpieczeństwie lokalnej infrastruktury Active Directory


Active Directory On-prem

Ochrona kontrolerów domeny (DC) przed atakiem zawsze była priorytetem dla administratorów oraz działów bezpieczeństwa w firmie. Oprócz zabezpieczeń realizowanych przez specjalistyczne oprogramowanie firm trzecich oraz ich odpowiednim monitorowaniem z pewnością istotnym aspektem jest zabezpieczenie fizyczne i hardening kontrolerów domeny (DC) jako serwerów. Pamiętaj, że nawet najlepsze oprogramowanie do bezpieczeństwa i monitorowania nie zabezpieczy Ciebie przed podstawowymi błędami, które możesz wyeliminować. Jednym z nich jest niekontrolowany dostęp fizyczny.

Oto kilka przykładów, w jakie organizacje dbają o bezpieczeństwo swoich kontrolerów domeny:

  • Ograniczenie korzystania z uprawnień administratora domeny
  • Używanie jump hosts (serwerów przesiadkowych), w celu uzyskania dostępu do protokołu RDP lub dostępu do konsoli MMC łączącej się do AD.
  • Nieinstalowanie aplikacji innych firm na DC (poza oczywiście oprogramowaniem do zabezpieczania)
  • Ograniczanie dostęp do Internetu z kontrolerów domeny

Biorąc pod uwagę wyzwania, przed którymi stoi nowoczesny zespół ds. bezpieczeństwa, istnieje możliwość ponownego przyjrzenia się najlepszym praktykom, aby zobaczyć, gdzie można wprowadzić ulepszenia.
Poniżej postanowiliśmy je zebrać i uporządkować. Kroki do zalecanego zabezpieczenia AD uzupełniliśmy także o koncepcję Zabarykadowania AD.


1. Bezpieczeństwo fizycznych kontrolerów domeny


W przypadku bezpieczeństwa fizycznego istnieje jedna złota zasada:

„Jeśli atakujący posiada nieograniczony fizyczny dostęp do twojego komputera, to już nie jest to twój komputer”

Oznacza to tyle, że jeśli posiadamy nawet najlepsze zabezpieczenia kontrolerów, a nie są one odpowiednio chronione w dostępie fizycznym to istnieje poważne zagrożenie, że ktoś może taki serwer zhackować. Dlatego w centrach danych fizyczne kontrolery domeny powinny być instalowane w dedykowanych, bezpiecznych szafach rackowych, które są oddzielone od innych serwerów. Microsoft zaleca także, jeśli to możliwe, aby kontrolery domeny były skonfigurowane z układami Trusted Platform Module (TPM), a wszystkie woluminy na serwerach kontrolerów domeny powinny być chronione za pomocą szyfrowania dysków funkcją BitLocker. Funkcja ta dodaje niewielki narzut na wydajność (kilkuprocentowy wzrost), ale za to chroni katalog przed złamaniem zabezpieczeń, nawet jeśli dyski są usuwane z serwera. BitLocker może również pomóc w ochronie systemów przed atakami, takimi jak rootkity, ponieważ modyfikacja plików rozruchowych spowoduje uruchomienie serwera w trybie odzyskiwania, aby można było załadować oryginalne pliki binarne. Jeśli kontroler domeny jest skonfigurowany do korzystania z programowego RAID, szeregowo dołączanego SCSI, pamięci masowej SAN/NAS lub woluminów dynamicznych, nie można zaimplementować funkcji BitLocker, więc lokalnie dołączana pamięć masowa (ze sprzętowym RAID lub bez) powinna być zawsze używana w przypadku kontrolerów domeny.


2. Bezpieczeństwo wirtualnych kontrolerów domeny


Podobna sytuacja tyczy się w przypadku implementacji wirtualnych kontrolerów domeny. Należy upewnić się, że kontrolery domeny działają również na oddzielnych hostach fizycznych niż inne maszyny wirtualne w środowisku. W przypadku wirtualizacji, należy zabezpieczyć też samą platformę do wirtualizacji (Hyper,czy VMWare) i rozdzielić w niej zarządzanie maszynami wirtualnymi innych serwerów od DC. Należy również zwrócić uwagę na dostęp fizyczny do plików maszyn wirtualnych tak, aby nie wpadły w niepowołane ręce.
W przypadku wirtualizacji DC’ków i innych maszyn wirtualnych serwerów na tym samym fizycznym hoście należy rozważyć separację obowiązków na podstawie ról. Zapewni to kompleksową ochronę przed złośliwymi lub nieświadomymi administratorami sieci szkieletowej (w tym administratorami wirtualizacji, sieci, pamięci masowej i kopii zapasowych).


3. Kontrolery w oddziałach


Jeśli posiadasz wdrożone fizyczne kontrolery domeny w oddziałach, to również powinieneś je zabezpieczyć przynajmniej w takim stopniu, w jakim są zabezpieczone serwery centrum danych. Fizyczne kontrolery domeny należy skonfigurować z układami TPM i szyfrowaniem dysków funkcją BitLocker dla wszystkich woluminów serwerów. Jeśli kontroler domeny nie może być przechowywany w zamkniętym pomieszczeniu w lokalizacjach oddziałów, należy rozważyć wdrożenie kontrolerów domeny tylko do odczytu (RODC) w tych lokalizacjach.
Podobna zasada bezpieczeństwa jak w przypadku wirtualnych kontrolerów a data center dotyczy wirtualnych kontrolerów w oddziałach. Jeśli to możliwe należy je wydzielać na osobnych fizycznych hostach. W oddziałach, w których wirtualne kontrolery domeny nie mogą działać na oddzielnych hostach fizycznych od reszty wdrożonych serwerów wirtualnych, należy wdrożyć chipy TPM i szyfrowanie dysków funkcją BitLocker na hostach, na których wirtualne kontrolery domeny działają co najmniej, oraz na wszystkich hostach, jeśli to możliwe. W zależności od wielkości oddziału i bezpieczeństwa hostów fizycznych należy rozważyć wdrożenie kontrolerów RODC w lokalizacjach oddziałów.


4. Konfiguracja systemu operacyjnego na kontrolerze domeny i zarządzanie AD


Poniżej zamieszczamy najważniejsze aspekty kontroli i zabezpieczania kontrolerów domeny pozwalające wyeliminować ryzyko przejęcia domeny Active Directory

  • Utrzymywanie najnowszej wersja systemu operacyjnego i aktualizacji
    Możemy teraz przejść do konfiguracji i zabezpieczenia samego systemu operacyjnego. O tym, że najlepiej, aby był on w najnowszej wersji nie musimy tłumaczyć. Podobna sprawa dotyczy najnowszych wydawanych przez Microsoft aktualizacji, o które musi dbać dział IT.

  • Użycie okrojonej konfiguracji systemu operacyjnego
    Konfiguracja systemu operacyjnego kontrolerów domeny jest także możliwa w specjalnej, okrojonej wersji instalacyjnej systemu Server Core. Zapewnia on wiele korzyści, takich jak minimalizacja powierzchni ataku, poprawa wydajności i zmniejszenie prawdopodobieństwa błędu ludzkiego. Warto tez pamiętać, że im więcej zainstalujemy komponentów systemowych oraz innego oprogramowania na kontrolerze, to staję się on bardziej podatny na atak.

  • Bezpieczne zarządzanie
    Istotne są również kwestie samego zarządzania serwerami (domeną AD). Zaleca się, aby wszystkie operacje i zarządzanie były wykonywane zdalnie, z dedykowanych, wysoce zabezpieczonych punktów końcowych, takich jak stacje robocze z uprzywilejowanym dostępem lub bezpiecznych hostów administracyjnych. W naszej koncepcji zabarykadowania AD, znajduję się także jeden, bardzo ważny element uproszczający zarządzanie, a mianowicie specjalny Bastion do bezpiecznego zarządzania.

  • Hardening ustawień na kontrolerze
    Bezpieczna konfiguracja kontrolerów domeny ma duży wpływ na to na co pozwalamy, a na co nie podczas zarządzania oraz w jaki sposób są zabezpieczone lokalne zasoby na serwerze.
    Istnieją narzędzia, które pomagają w tworzeniu początkowej linii bazowej konfiguracji zabezpieczeń dla kontrolerów domeny, którą można później wymusić przez obiekty zasad grupy (GPO). Jedno z nich znajdziesz tutaj.

  • Ograniczenia zdalnego połączenia RDP
    W przypadku zdalnych połączeń do serwera musimy zadbać o to, aby zezwalać na połączenia RDP tylko od autoryzowanych użytkowników i systemów, takich jak serwery przesiadkowe (jump hosts).
    Konfigurację tych ustawień można przeprowadzić za pomocą dedykowanych GPO (kombinację ustawień praw użytkownika i konfiguracji WFAS) i wdrożyć te ustawienia na kontrolery, aby polityka była konsekwentnie stosowana.

  • Odpowiednie zarządzanie zmianą
    W przypadku wprowadzania jakichkolwiek zmian na kontrolerach, czy to w systemie operacyjnym. (np. wprowadzanych aktualizacjach), czy w konfiguracji samych obiektów katalogu AD (np. zmiany w członkostwie grup), powinniśmy zaplanować cały proces i kontrolować go. Śledzenie zmian oraz możliwość ich przywracania na pewno zabezpieczy nas na wypadek niepowodzeń oraz powrotów do ostatniej stabilnej konfiguracji. Idąc dalej, w naszej koncepcji zabarykadowania AD możemy chronić zmianę nawet przed wysoko- uprawnionym użytkownikiem lub administratorem. Bez odpowiedniej akceptacji taka zmiana nie będzie możliwa do wykonania.

  • Zabezpieczenie aplikacji zarządzających infrastrukturą
    Jeśli w firmie korzystasz z oprogramowania do zarządzania konfiguracją serwerów lub monitorowania, to musisz pamiętać, że złamanie zabezpieczeń takiego oprogramowania może zostać wykorzystane do złamania lub zniszczenia wszystkich składników infrastruktury zarządzanych przez to oprogramowanie. Poprzez oddzielenie zarządzania poprawkami i systemami dla kontrolerów domeny od innych serwerów, można zmniejszyć ilość oprogramowania instalowanego na kontrolerach domeny, a także umożliwić ich ścisłą kontrolę. Warto tez kontrolować dostęp do takich aplikacji i poddawać je restrykcyjnym audytom.

  • Blokowanie dostępu do Internetu dla kontrolerów domeny
    Ile razy spotykałeś się z możliwością odpalenia przeglądarki na kontrolerze domeny i przeglądania Internetu? A może jest taka możliwość u Ciebie w organizacji?
    Żadna przeglądarka internetowa nie powinna być używana na kontrolerach domeny. Sam Microsoft odnosi się do tej możliwości bardzo stanowczo i krytycznie:

    „Analiza tysięcy kontrolerów domen ujawniła liczne przypadki, w których uprzywilejowani użytkownicy używali programu Internet Explorer do przeglądania intranetu lub Internetu organizacji”.

    Pamiętaj, że:

    „Przeglądanie Internetu lub zainfekowanego intranetu z jednego z najpotężniejszych komputerów w infrastrukturze Windows (czyli DC) przy użyciu wysoce uprzywilejowanego konta stanowi nadzwyczajne zagrożenie dla bezpieczeństwa organizacji. Niezależnie od tego, czy chodzi o dysk przez pobranie, czy przez pobranie zainfekowanych złośliwym oprogramowaniem „narzędzi”, atakujący mogą uzyskać dostęp do wszystkiego, czego potrzebują, aby całkowicie naruszyć lub zniszczyć środowisko Active Directory.”

    Podobna sytuacja dotyczy pracy na komputerze stacjonarnym na zalogowanym użytkowniku z uprawnieniami administracyjnymi do domeny. Jest to bardzo duże zagrożenie i powinno być eliminowane w każdej organizacji.

    Jeśli jest konieczność użycia przeglądarki internetowej na DC, to pamiętaj, aby uruchamianie jej było ograniczone zasadami i kontrolami technicznymi. Ponadto ogólny dostęp do Internetu do i z kontrolerów domeny powinien być również ściśle kontrolowany.

  • Skonfigurowanie ograniczeń na firewall
    Pod żadnym pozorem nie powinno się zezwalać na firewallach brzegowych na połączenia wychodzące z kontrolerów domeny do Internetu. Istnieją jednak pewne wyjątki jak np. komunikacja DC z innymi serwerami DC w lokalizacjach. Należy do tego podchodzić bardzo restrykcyjnie i postępować zgodnie z tymi wytycznymi.

Podziel się z innymi tym artykułem!