Ochrona w tandemie

Większość sieci wykorzystuje obecnie dwa systemy uwierzytelniania: Kerberos lub RADIUS. Próba ograniczenia się tylko do jednego z nich nie ma sensu - każdy z nich ma swoją rolę do spełnienia.

Większość sieci wykorzystuje obecnie dwa systemy uwierzytelniania: Kerberos lub RADIUS. Próba ograniczenia się tylko do jednego z nich nie ma sensu - każdy z nich ma swoją rolę do spełnienia.

Mechanizmy uwierzytelniania i kontroli uprawnień są elementem każdego systemu informatycznego: sieci, systemu operacyjnego, bazy danych czy aplikacji. Spośród wielu takich mechanizmów dwa zyskały powszechną akceptację: Kerberos oraz RADIUS. W ramach jednego obszaru, np. na potrzeby sieci, wykorzystywany jest zwykle jeden z tych mechanizmów, co nie oznacza, że w innych obszarach nie może być stosowany ten drugi - i bardzo często tak właśnie jest.

W pewnych sytuacjach, np. przy okazji wdrożeń albo wymiany części infrastruktury, dochodzi do starć między administratorami, którzy bronią "swojego" protokołu uwierzytelniania. Aby zrozumieć, który z nich jest ważniejszy lub lepszy - trzeba zrozumieć zasadę ich działania i grupę zastosowań, dla jakich powstały. Poniższa garść faktów powinna w tym pomóc.

Tylko z biletami

System Kerberos powstał w ramach projektu naukowego Athena na Massachusetts Institute of Technology. Ma dobre podstawy teoretyczne i dobre wsparcie producentów komercyjnych rozwiązań IT, przez co jest bardzo popularny w przedsiębiorstwach. Implementacje Kerberos są obecne m.in. w systemach Windows (ISS) i Mac OS.

Serwer katalogowy Active Directory w systemie Windows integruje Kerberos z protokołem LDAP, a także kilka innych elementów, tworząc centralny punkt administracji użytkownikami i ich uprawnieniami. Kerberos zasadza się na koncepcji infrastruktury PKI, posługuje się pojęciem sesji, a dodatkowo także zezwoleń zwanych biletami (tickets). Całość zapewnia bezpieczne nawiązywanie połączeń i transmisję danych w sieci.

Istnieją także implementacje Kerberos w systemach typu Unix (Heimdal) i Linux. System ten można implementować w systemach przeznaczonych do różnorodnych celów, ale jego elastyczność, zwłaszcza wydajność i skalowalność okazują się w niektórych zastosowaniach na tyle problematyczne, że trzeba go zastąpić innym rozwiązaniem.

Kerberos często występuje razem z LDAP. LDAP, podobnie jak NIS czy NetInfo, to protokoły sieciowe, które nie zostały stworzone na potrzeby uwierzytelniania, ale mogą zostać do tego celu użyte jako rozwiązania pomocnicze. I raczej powinny - sam Kerberos zapewnia bowiem jedynie informację o tym, kim jest użytkownik, a więc uwierzytelnienie, zaś kontroli uprawnień nie obejmuje. Do tego właśnie służy LDAP, który z repozytorium odczytuje informację o tym, do jakich zasobów użytkownik ma prawa dostępu i z jakimi przywilejami.

Posłużenie się samym protokołem LDAP również nie ma sensu, ponieważ LDAP nie przechowuje i nie interpretuje zapytań o uprawnienia - nie wie, czemu one służą. W praktyce oznacza to, że każda próba dostępu do zasobu sieciowego będzie powodować konieczność zalogowania się. To Kerberos jest warstwą zdolną do interpretacji i to na nim buduje się systemy jednokrotnego logowania (single sign-on).

Pełna centralizacja

Kerberos jest systemem, który zasadza się na centralnym serwerze, w skład którego wchodzą dwa kluczowe elementy: serwer uwierzytelniający (AS - Authentication Server) oraz system przydzielający uprawnienia (TGS - Ticket Granting System). Na serwerze tym znajdują się wszystkie informacje o użytkownikach, hasłach, kluczach. Wszyscy użytkownicy działają na podstawie danych dostarczonych przez ten serwer.

Założenie leżące u podstaw architektury Kerberos jest takie, że bezpieczny jest tylko serwer centralny, zaś całe środowisko poza nim - nie jest. Jest przy tym oczywiste, że łatwiej jest zabezpieczyć jeden serwer, niż rozproszony system składający się z wielu węzłów, jak ma to obecnie miejsce w przypadku współczesnych implementacji serwerów LDAP.

Użytkownik chcący połączyć się z usługą w sieci (np. podłączyć dysk sieciowy) musi się przedstawić, by otrzymać uprawnienia. W imieniu użytkownika aplikacja wysyła więc do AS żądanie o przyznanie biletu umożliwiającego skontaktowanie się z serwerem TGS przyznającym bilety dające prawo dostępu do zasobów. Taki bilet (zwany Ticket Granting Ticket) jest wydawany jednorazowo. Za każdym następnym razem (w ramach tej samej sesji przypisanej temu samemu TGT) użytkownik zwraca się już bezpośrednio do TGS.

Od strony technicznej wszystko odbywa się w ramach infrastruktury klucza publicznego. Odpowiedzi na zapytania użytkownika są kodowane kluczem sesji dostarczonym przez AS, a nie kluczem użytkownika, który można łatwo złamać choćby ze względu na fakt, że jest on zwykle przechowywany w pamięci klienta. Odpowiedź (bilet) zawiera nowy klucz sesji - wygenerowany przez TGS w celu umożliwienia użytkownikowi skorzystania tylko z żądanej usługi. Bilet jest więc tymczasowym dokumentem tożsamości wydawanym, ważnym tylko na pewnym obszarze i tylko przez określony czas.


TOP 200