Dlaczego usługa Active Directory jest bezpieczna i warto jej używać?
September 30, 2021, 12:21
Bezpieczeństwo usługi Active Directory możemy wzmacniać na wiele sposobów. Warto jednak wiedzieć jak realizowane jest bezpieczeństwo usługi AD jeśli chodzi o organizację dostępu do zasobów „od środka”, tzn. co faktycznie się dzieje, gdy logujemy się do różnych zasobów w środowisku opartym na tej usłudze i co sprawia, że jest ona tak wysoce bezpieczna.
Wszystko za sprawą protokołu Kerberos, którego implementację możemy znaleźć właśnie w usłudze AD. Opracowany przez amerykański instytut MIT uznawany jest za jeden z najbezpieczniejszych protokołów na świecie. Kerberos realizuje bezpieczeństwo w trzech aspektach:
- weryfikacja tożsamości komunikujących się stron,
- integralność przesyłanych danych,
- poufność danych.
Protokół opiera się na opracowanym wcześniej protokole kluczy symetrycznych, stworzonym przez Rogera Needhama i Michaela Schroedera. Istnieje kilka jego wersji, natomiast najnowszą jest wersja 5. Najistotniejszą zaletą usługi Kerberos, jest to, że hasła wprowadzane przez użytkowników nie są przesyłane przez sieć. Używane są tutaj tzw. bilety oraz klucze (wykorzystywana jest wieloetapowa kryptografia symetryczna).
Najistotniejszym elementem systemu jest tzw. centrum dystrybucji kluczy (Key Distribution Center), złożone z komponentu AS (serwer uwierzytelniania – Authentication Server) oraz TGS (serwer przepustek – Ticket Granting Service), działających na kontrolerach domeny. Schemat działania mechanizmu wygląda następująco:
W pewnym uproszczeniu działanie protokołu przebiega następująco:
- użytkownik wprowadza swój login i hasło na stacji roboczej;
- system kliencki na komputerze użytkownika konwertuje hasło na klucz symetryczny (używana jest tutaj jednokierunkowa funkcja haszująca generująca unikalny i niepowtarzalny dla danego hasła ciąg znaków);
- klient (system stacji roboczej) wysyła w jawnej postaci komunikat (zawierający m.in. swoje ID oraz ID serwera TGS oraz znacznik czasowy umożliwiający synchronizację zegarów obydwu stron) do modułu AS prosząc o bilet do komunikacji z serwerem TGS;
- AS na podstawie przechowywanego u siebie hasła użytkownika tworzy klucz szyfrowania, którym zaszyfrowuje komunikat przesyłany w odpowiedzi do klienta (zawierający: ID serwera TGS, klucz sesyjny znany klientowi i TGS, znacznik czasu oraz okres ważności biletu);
- w dalszej części komunikatu od AS zawarta jest tzw. przepustka udzielająca przepustek (TGT – Ticket Granting Ticket) zaszyfrowana kluczem wspólnym dla AS i TGS. Taka przepustka nie jest odszyfrowywana przez system klienta, będzie ona używana w dostępie do żądanych usług (np. określonych zasobów serwera plików);
- kiedy klient po otrzymaniu TGT będzie chciał następnie uzyskać dostęp np. do serwera plików, system na jego komputerze wyśle do TGS prośbę o „bilet” do takiego serwera z danymi. Prośba taka zaszyfrowana jest kluczem sesji uzyskanym wcześniej od AS, zawiera także TGT;
- TGS tworzy i wysyła w odpowiedzi klucz sesji do komunikacji klienta z serwerem usługi (w tym przypadku serwerem plików) oraz specjalny bilet (TS) umożliwiającą dostęp do serwera usługi;
- otrzymany przez klienta bilet do usługi jest następnie „okazywany” serwerowi plików podczas próby żądania dostępu do jego zasobów. Zawiera on klucz sesji (do szyfrowania komunikacji klient <-> serwer usługi), ID klienta i serwera, znacznik czasu oraz swój czas ważności. Bilet ten jest zaszyfrowany kluczem współdzielonym przez TGS i serwerem usługi;
- serwer odszyfrowywuje przesłane żądanie, sprawdza przesłane informacje i jeśli wszystko się zgadza następuje nawiązanie sesji z klientem i udostępnienie zasobów plikowych.
Korzystając z dobrodziejstw zabezpieczeń protokołu Kerberos warto jednak pomyśleć o dodatkowych zabezpieczeniach usługi AD (uniemożliwiających podsłuchiwanie komunikatów czy zabezpieczających dostęp do kontrolerów domeny w sieci), gdyż mimo że jest on uznawany za jeden z najbezpieczniejszych protokołów zabezpieczających dostęp do zasobów na świecie, to ma też swoje słabości).
O dodatkowej ochronie środowiska Active Directory możecie poczytać w naszych osobnych artykułach, m.in. "Jak aktywnie zabezpieczyć Active Directory"
Jeśli kogoś z Państwa zainteresował temat bezpieczeństwa AD to zapraszamy do kontaktu - cyberVOL@vol.com.pl
PK