SY0-701: Authentication, Authorization, Accounting (PL)

Framework (czyli ramy, które definiują strukturę oraz ogólny mechanizm działania) określany mianem AAA (Authentication, Authorization, Accounting) jest istotnym elementem bezpieczeństwa sieciowego, a jego zadaniem jest kontrola i rejestrowanie dostępu do chronionych zasobów. Mówiąc krótko: determinuje, kto i do jakich elementów systemu ma dostęp, a także śledzi poczynania zalogowanych użytkowników.

Jak wygląda bardzo ogólny proces nadawania dostępu do wybranych zasobów, będący częścią frameworka AAA:

1. Pierwszym krokiem jest identyfikacja (ang. identification). jeżeli chcemy uzyskać dostęp do systemu, musimy się przedstawić jako jego uprawniony użytkownik. W najczęstszym przypadku polega to na podaniu danych uwierzytelniających w postaci unikatowej nazwy użytkownika i hasła, ale mogą to być również inne czynniki uwierzytelniające, takie jak odcisk palca czy sprzętowy klucz USB.
2. Kiedy już się kulturalnie przedstawiliśmy, przechodzimy do etapu uwierzytelnienia (ang. authentication). Teraz system weryfikuje podane przez nas informacje uwierzytelniające i próbuje potwierdzić na podstawie danych w swojej bazie, iż na pewno jesteśmy tymi, za kogo się podajemy. jeżeli wszystko się zgadza, zostajemy uwierzytelnieni i otrzymujemy dostęp do systemu.
3. Po potwierdzeniu naszej tożsamości, czas na autoryzację (ang. authorization). To, iż umożliwiono nam wejście do systemu, nie oznacza automatycznie, iż mamy dostęp do wszystkich jego zasobów. Proces autoryzacji polega na przyznawaniu użytkownikowi dostępu do określonych zasobów, w zależności od jego uprawnień. Na przykład, kiedy logujemy się do naszej bankowości elektronicznej, mamy dostęp jedynie do naszego konta, a nie do kont innych klientów. Pracownicy banku również są użytkownikami systemu bankowego i mogą mieć szerszy zakres uprawnień (np. podgląd kont swoich klientów, ale bez możliwości wykonywania na nich operacji).
4. Trzecim filarem frameworka AAA jest śledzenie i rejestrowanie działań użytkowników w systemie, czyli tzw. accounting (można to przetłumaczyć dosłownie jako rozliczanie bądź księgowanie). Monitorowanie aktywności użytkowników w systemie (czas logowania/wylogowania; operacje wykonywane na określonych zasobach itp.) jest bardzo istotnym elementem dbania o bezpieczeństwo. Dzięki temu administratorzy systemu mogą z powodzeniem przeprowadzać audyty bezpieczeństwa, wykrywać anomalie, a także analizować skutki oraz przyczyny ewentualnych incydentów.

Pamiętajmy, iż przedstawiony wyżej ogólny opis frameworka AAA jest jedynie abstrakcyjnym konceptem, którego implementacja może mocno różnić się od strony technicznej, w zależności od potrzeb. Inaczej wygląda mechanizm pilnowania dostępu do pojedynczego urządzenia (np. przez protokół SSH), gdzie cały proces AAA może odbywać się pod kontrolą systemu operacyjnego tego urządzenia, a jeszcze inaczej, gdy użytkownik próbuję uzyskać dostęp do całej sieci (np. przez VPN), w której funkcjonuje scentralizowany serwer AAA.

Ogólny proces kontroli dostępu do chronionych zasobów, z wykorzystaniem scentralizowanego serwera AAA (na przykładzie protokołu RADIUS), mógłby wyglądać następująco:

Framework AAA, na przykładzie scentralizowanego serwera RADIUS.
Źródło: opracowanie własne.

Przykłady popularnych protokołów AAA:

• RADIUS (Remote Access Dial-In User Service) – protokół będący otwartym standardem, realizujący założenia frameworka AAA, który powstał w 1991 roku i jest do dzisiaj wykorzystywany (głównie w sieciach bezprzewodowych). Uwierzytelnienie oraz autoryzacja są realizowane w ramach pojedynczego kroku, podczas gdy śledzenie aktywności odbywa się w osobnym procesie. Starsze implementacje wykorzystywały porty UDP o numerach 1645 (authentication, authorization) oraz 1646 (accounting), natomiast nowsze wersje używają w tym samym celu portów UDP 1812 (uwierzytelnienie i autoryzacja) oraz 1813 (rejestrowanie poczynań). Podczas komunikacji sieciowej jedynie hasła są zaszyfrowane – pozostałe informacje są przesyłane w formie jawnej.
• TACACS+ (Terminal Access Controller Access-Control System) to protokół opracowany przez firmę Cisco (aktualnie wspierany również przez innych dostawców) i jest wykorzystywany głównie do zarządzania urządzeniami sieciowymi. W odróżnieniu od RADIUS-a, szyfrowana jest cała zwartość pakietów podczas komunikacji sieciowej, a nie tylko hasła. Poza tym, TACACS+ operuje na porcie 49 TCP oraz rozdziela proces uwierzytelnienia od autoryzacji, co umożliwia bardziej szczegółową kontrolę.

Authenticating people

Uwierzytelnianie osób (ludzi) opiera się na trochę innych zasadach niż uwierzytelnianie systemów, gdzie polegamy głównie na certyfikatach i podpisach cyfrowych.

Mechanizmy odpowiedzialne za uwierzytelnienie człowieka muszą odznaczać się pewną dozą zaufania, ponieważ tak naprawdę nie są w stanie określić, podczas weryfikacji, czy wybrane atrybuty okazywane w świecie cyfrowym mają odzwierciedlenie w świecie rzeczywistym (np. czy prawidłowe hasło rzeczywiście podał uprawniony użytkownik).

Dodatkowym wyzwaniem jest dobranie takich czynników uwierzytelniających, które nie będą stanowić poważnego naruszenia prywatności. Cała sztuka polega na oparciu mechanizmów uwierzytelniających na możliwie najmniejszej liczbie atrybutów, które są w stanie jednoznacznie potwierdzić, iż ich właściciel jest rzeczywiście tym, za kogo się podaje.

Szczegółowość weryfikacji określonych atrybutów powinna być też adekwatna do wymagań danego systemu. Na przykład, systemy bankowe powinny być bardziej wnikliwe w procesie uwierzytelniania, niż internetowe fora wędkarskie (nawet jeżeli ktoś jest fanatykiem wędkarstwa).

Popularne czynniki (atrybuty) uwierzytelniające, które mogą charakteryzować daną osobę i stanowić podstawę do jej uwierzytelnienia:

• Coś, co wiesz (ang. something you know) – najpopularniejsza metoda uwierzytelniająca, opierająca się na tym, iż dany użytkownik wie coś, czego nie wiedzą inni. Przeważnie jest to hasło, kod PIN, odpowiedzi na pytania weryfikujące itd.
• Coś, co posiadasz (ang. something you have) – metoda powszechnie stosowana jako dodatkowy czynnik uwierzytelniający (MFA, 2FA), bazująca na tym, iż dany użytkownik jest w posiadaniu czegoś, czego nie mają inni. Może to być telefon z aplikacją mobilną, generującą jednorazowe kody dostępu, bądź też klucz sprzętowy.
• To, kim jesteś (ang. something you are) – metoda weryfikujące unikatowe, fizyczne cechy użytkownika (biometria). Polega na sprawdzaniu linii papilarnych, rozpoznawaniu twarzy i/lub głosu, czy też skanowaniu siatkówki oka. Dobrze zaimplementowana biometria jest jedną z najskuteczniejszych metod uwierzytelniających jeżeli chodzi o ludzi, jednak może powodować inne problemy: konieczność stosowania specjalistycznego sprzętu; potrzeba przechowywania w bezpieczny sposób wrażliwych danych biometrycznych użytkowników.
• Miejsce, w którym przebywasz (ang. somewhere you are) – metoda sprawdzająca fizyczną lokację użytkownika. Jest to do pewnego stopnia możliwe poprzez sprawdzenie źródłowego adresu IP, współrzędnych GPS urządzenia, czy też na podstawie stacji bazowych w przypadku urządzeń GSM. Należy jednak pamiętać, iż dane tego typu mogą zostać podstawione (spoofing), więc ten czynnik powinien stanowić jedynie dodatkową ochronę.
• To, jak się zachowujesz (ang. something you do) – weryfikacja na podstawie wzorców zachowań danego użytkownika, np. sposobu posługiwania się myszką, klawiaturą, ekranu dotykowego, czy też sposobu korzystania z danej aplikacji. Ta metoda, m.in. ze względu na swoją nieprecyzyjność, również powinna być traktowana jedynie jako czynnik wspierający.

Authenticating systems

W rozbudowanych systemach nie tylko człowiek wymaga potwierdzenia swojej tożsamości. Zdarza się, szczególnie w środowiskach rozproszonych, iż dwie usługi (ang. services) muszą się ze sobą komunikować.

Weźmy jako przykład system sprzedażowy, w którym jedna z usług, odpowiedzialna za przetwarzanie płatności, wywołuje API (np. przez protokół HTTP) innej usługi, obsługującej przygotowanie i wysłanie towaru. Chcemy mieć jednak pewność, iż tylko zaufana część naszego systemu (m.in. ta, która jest w stanie potwierdzić otrzymanie zapłaty) była w stanie uruchomić procedurę wysyłki. Usługa odpowiedzialna za wysyłkę musi więc jakoś potwierdzić tożsamość nadawcy żądania, który w tym przypadku nie jest człowiekiem, a inną usługą.

Teoretycznie można wykorzystać w tym celu hasło bądź inny klucz API, który jest weryfikowany po stronie odbiorcy żądania. Stwarza to jednak dodatkowe problemy z zakresu bezpieczeństwa, ponieważ zarówno klient (usługa wysyłająca żądanie) oraz serwer (usługa przyjmująca i obsługująca żądanie) muszą gdzieś przechowywać dane dostępowe, w taki sposób, żeby te przez przypadek nie wyciekły. Najczęstszym przykładem takiego wycieku jest omyłkowe dołączenie danych uwierzytelniających do repozytorium z kodem aplikacji.

Oczywiście nie oznacza to, iż nie stosuje się takiej formy uwierzytelnienia. Należy jednak zachować przy tym szczególną ostrożność i dane uwierzytelniające, automatycznie wysyłane przez aplikację bądź usługę, przechowywać w przeznaczonym do tego miejscu. Wiele rozwiązań umożliwiających zarządzanie środowiskiem rozproszonym oferuje narzędzia, które pozwalają na bezpieczne przechowywanie wrażliwych danych (np. Kubernetes Secrets, Azure Key Vault).

Jeśli korzystamy z rozwiązań chmurowych, często mamy do dyspozycji narzędzia, które umożliwiają uwierzytelnienie pomiędzy usługami, bez konieczności jawnego posługiwania się danymi dostępowymi w postaci haseł, kluczy czy sekretów. Przykładem takiego rozwiązania jest Azure Managed Identities.

Innym przykładem jest potrzeba nadania dostępu do sieci organizacji jedynie zaufanym urządzeniom. Pracownik, aby uzyskać dostęp do firmowej sieci VPN, nie tylko jest zobligowany do podania swoich danych dostępowych, ale może to zrobić jedynie za pośrednictwem służbowego laptopa.

W tym konkretnym przypadku, rozwiązaniem może być umieszczenie cyfrowo podpisanego certyfikatu na urządzeniu (laptop pracownika z przykładu). Taki certyfikat, wygenerowany i podpisany przez organizację, jest później weryfikowany podczas próby połączenia się z siecią. Dzięki temu, oprócz danych samego użytkownika (pracownika), sprawdzamy również, czy połączenie nawiązano z zaufanego urządzenia, nad którym mamy kontrolę do pewnego stopnia (np. wiemy, iż przed wydaniem sprzętu zainstalowano w systemie oprogramowanie typu anti-malware).

Authorization models

Kiedy użytkownik bądź usługa (każdy byt, który przechodzi proces uwierzytelnienia, można określić zbiorczym terminem: identity) potwierdzą swoją tożsamość, trzeba jeszcze sprawdzić, do jakich zasobów mają dostęp. Mówiąc krótko: czas na autoryzację.

Najprostszym podejściem, ale też trudnym w utrzymaniu, jest nadawanie konkretnych uprawnień do wybranych zasobów na poziomie uwierzytelnionego konta. Na przykład, jawnie definiujemy, iż konto użytkownika menadżer może odczytać arkusze kalkulacyjne, zawierające informacje o wysokości wynagrodzeń pracowników danego departamentu. jeżeli konto menadżera mogłoby modyfikować wspomniane arkusze, potrzebne jest kolejne uprawnienie, tym razem do edycji, i tak dalej. Kiedy chcemy nadać identyczne uprawnienia dyrektorowi departamentu, znowu musielibyśmy je definiować dla kolejnego konta.

Takie podejście jest mało efektywne, szczególnie jeżeli w naszej organizacji musimy zarządzać setkami (jeśli nie tysiącami) kont reprezentujących określoną tożsamość (dla uproszczenia, w dalszej części tekstu, będziemy posługiwać się terminem konto użytkownika). Podobnie jest z zasobami, których w organizacji może być ogromna ilość. Dlatego stosuje się odpowiednie modele autoryzacji, będące warstwą pośredniczącą pomiędzy uwierzytelnionymi użytkownikami/usługami, a chronionym zasobami.

Model autoryzacji można więc potraktować jako warstwę abstrakcyjną, która pozwala odseparować konta użytkowników od informacji, do których próbują uzyskać dostęp. Dzięki temu, nie mamy bezpośredniego powiązania pomiędzy poszczególnymi użytkownikami i zasobami, przez co łatwiej jest zarządzać dostępem.

Lista najpopularniejszych modeli autoryzacji, które zostaną opisane bardziej szczegółowo przy okazji omawiania zagadnienia Access Control (rozdział 4.6 w rozpisce egzaminacyjnej SY0-701):

• Role-Based Access Control (RBAC) – dostęp jest przyznawany na podstawie ról, które mają zdefiniowane odpowiednie zestawy uprawnień. Następnie, te role są przypisywane użytkownikom.
• Attribute-Based Access Control (ABAC) – dostęp jest przyznawany na podstawie atrybutów (cech charakterystycznych): użytkownika; środowiska, w którym przechowywane są zasoby; urządzenia, z którego korzysta dany użytkownik. Pozwala na tworzenie rozbudowanych reguł dostępowych uwzględniających wiele atrybutów oraz zapewnia bardziej granularną kontrolę niż model RBAC i często stanowi jego dopełnienie.
• Relationship-Based Access Control (ReBAC) – decyzje dotyczące dostępu opierają się na relacjach między użytkownikami/zasobami. Na przykład: menadżer ma dostęp do zasobów należących do członków swojego zespołu.
• Mandatory Access Control (MAC) – dostęp jest ściśle regulowany przez polityki organizacyjne, bez swobody użytkownika w zmienianiu dostępu, choćby w stosunku do zasobów, które sam utworzył.
• Discretionary Access Control (DAC) – dostęp jest kontrolowany przez właściciela zasobu, który może swobodnie nadawać uprawnienia innym użytkownikom.

Projektując rozwiązania w naszej organizacji, powinniśmy się dobrze zastanowić i wybrać odpowiedni model autoryzacji, który będzie najbardziej dopasowany do naszych potrzeb. Warto przy tym wziąć pod uwagę następujące czynniki:

• Wymagany poziom bezpieczeństwa – inaczej potraktujemy wrażliwe dane osobowe, a inaczej listę zakupów. Pamiętajmy, iż niektóre modele są bardziej restrykcyjne niż pozostałe.
• Wygoda użytkowników – wybrany model powinien zapewniać odpowiedni poziom bezpieczeństwa, ale też nie powinien niepotrzebnie utrudniać pracy pracownikom.
• Złożoność – jeżeli nasze wymagania są specyficzne i rozważamy skomplikowane scenariusze, powinniśmy się zastanowić nad modelami, które oferują większą kontrolę.
• Skalowalność – na początku proste modele wydają się być wystarczające, jednak miejmy na uwadze, iż organizacja będzie się rozwijać i może okazać się, iż musimy gwałtownie dostosować się do nowych realiów.

Materiały źródłowe

• Na Styku Sieci: AAA, RADIUS i TACACS+ – podstawy.
• Fred B. Schneider: Authentication of People.
• The Different Types of Authorization Models.