W dzisiejszym artykule zajmiemy się genezą i ewolucją specyfikacji RBAC. Pokusimy się o głębszą analizę i porównamy RBAC z ABAC. Wyjaśnienie tych terminów jest kluczowe dla zrozumienia zarządzania tożsamością, bowiem zarządzanie przez role jest nieodłącznym elementem systemów klasy IAM/IGA.
W jednym z wcześniejszych artykułów cyklu opisaliśmy pojęcia związane z tożsamością cyfrową i głównymi procesami z nią powiązanymi. Przypomnijmy, iż pojęcie tożsamości (identity) w kontekście systemów klasy IAM\IGA nie jest związane wyłącznie z kontem użytkownika w usługach katalogowych takich jak np. Active Directory, ponieważ tożsamość może reprezentować osobę (pracownika) lub maszynę (urządzenie, usługę), która w organizacji może posiadać różne konta w różnych systemach, gdzie każde konto może mieć inny zestaw uprawnień (np. przydziałów do grup). W tym kontekście można zadać pytanie: „Jak efektywnie zarządzać uprawnieniami tożsamości – czyli zarządzać kontami przypisanymi do tożsamości i przydziałami grup (uprawnień) dla tychże kont?”. W przypadku braku systemu klasy IAM\IGA w organizacji nadawanie uprawnień do poszczególnych kont realizowane może być poprzez np. wnioski papierowe czy zlecenia mailowe. Jest to jednak proces nieefektywny, podatny na błędy oraz niepozwalający tak naprawdę na udzielenie odpowiedzi na pytanie, dlaczego pracownik posiada akurat te konkretne uprawnienia. Również w przypadku zmian organizacyjnych (np. w wyniku zmiany stanowiska pracownika) taki ręczny proces może powodować nadmierne gromadzenie uprawnień i dostępów wynikających z całej historii pracy w firmie. Jednym ze sposobów rozwiązania tego problemu jest wykorzystanie funkcjonalności systemów IAM\IGA oraz automatyzacja zarządzania uprawnieniami i dostępami za pomocą ról z wykorzystaniem modelu RBAC. Role pozwalają uprościć zarządzanie dostępami, ponieważ redukują złożoność wynikającą z przypisywania poszczególnych uprawnień do kont użytkowników (np. konta AD do grup domenowych) poprzez przypisanie uprawnień do roli, a następnie odpowiedniej roli do tożsamości.
Czym jest rola w systemie zarządzania tożsamością?
W kontekście zarządzania uprawnieniami rola oznacza funkcję, jaką pełni tożsamość w organizacji, oraz definiuje, co jest tożsamości potrzebne do tego, by mogła realizować zadania przypisane do danej roli.
RBAC – rys historyczny
Role-Based Access Control (RBAC) jest kluczowym modelem zarządzania dostępem, który zrewolucjonizował sposób, w jaki systemy bezpieczeństwa zarządzają dostępem do zasobów. Jego koncepcja powstała jako odpowiedź na potrzebę zyskania większej kontroli i efektywności w zarządzaniu dostępem. Ale jak doszło do powstania RBAC i jak ewoluował on wraz z upływem czasu?
Model RBAC, choć obecnie bardzo popularny, nie zawsze był standardem w zarządzaniu dostępem. W rzeczywistości RBAC rozwinął się jako rozwiązanie alternatywne dla innych, wcześniej stosowanych modeli zarządzania dostępem, takich jak Discretionary Access Control (DAC) i Mandatory Access Control (MAC).
Co to jest DAC?
DAC, opierający się na indywidualnym przydzielaniu uprawnień, okazał się niewystarczająco skalowalny w przypadku dużych systemów. Przykładem implementacji systemów DAC są dyskretne listy uprawnień do plików i katalogów, gdzie na poziomie obiektu określone jest, jacy użytkownicy czy grupy użytkowników mają określony dostęp do danego obiektu. Innym przykładem zastosowania modelu DAC są usługi chmurowe, takie jak Google Drive czy Dropbox, korzystające z modelu DAC i pozwalające użytkownikom na zarządzanie dostępem do ich plików i folderów. Na przykład użytkownik może udostępnić link do pliku innym i zdecydować, czy mogą oni tylko wyświetlić plik, czy też mają uprawnienia do edycji.
Co to jest MAC?
MAC był z kolei zbyt rygorystyczny i niepraktyczny w wielu zastosowaniach. MAC działa odmiennie od DAC i opiera się na zasadzie przyznawania użytkownikom odpowiednich poziomów zezwoleń, określających, czy użytkownik ma dostęp do obiektów na danym poziomie. Model MAC jest często używany w środowiskach wojskowych, gdzie klasyfikacja informacji i dostęp do nich jest ściśle kontrolowany. Na przykład informacje oznaczone jako „tajne” mogą być dostępne tylko dla użytkowników, którzy mają odpowiednie uprawnienia i klasyfikację bezpieczeństwa.
Kiedy powstał RBAC?
RBAC zaczął nabierać kształtów w latach 90. jako alternatywny dla powyższych modeli. W 1992 roku David Ferraiolo i Richard Kuhn z National Institute of Standards and Technology (NIST) opublikowali pierwszy artykuł na temat modelu RBAC. Wzrost popularności modelu doprowadził do stworzenia różnych produktów bazujących na tej koncepcji, które wykorzystują model RBAC do zarządzania dostępem do zasobów.
RBAC – zasada działania
Kluczową ideą w RBAC jest przypisanie uprawnień do ról, a nie bezpośrednio do tożsamości czy kont użytkowników powiązanych z tożsamością. Tożsamości są przypisywane do ról, a role są związane z uprawnieniami. Przy takim podejściu każda rola reprezentuje zestaw uprawnień niezbędnych do wykonania określonego zadania lub zadań wynikających z funkcji, jaką pracownik pełni w organizacji. Model RBAC jest zwykle podzielony na cztery poziomy, z których każdy dodaje większą granularność i złożoność:
- Flat RBAC: Najprostsza forma, w której tożsamości są przypisywane do ról, a role są przypisane do uprawnień.
- Hierarchiczny RBAC: Pozwala na definiowanie ról nadrzędnych i podrzędnych, tworząc hierarchię ról. Uprawnienia są dziedziczone w dół hierarchii.
- Constrained RBAC: Dodaje reguły ograniczeń, które określają, w jakich okolicznościach role mogą być przydzielane lub uprawnienia mogą być wykonane.
- Symmetric RBAC: Rozszerza model o możliwość definiowania relacji między różnymi rolami.
RBAC dzięki swojej prostocie i efektywności stał się standardem w wielu obszarach, od systemów operacyjnych po sieci korporacyjne. Przy tym modelu zarządzania dostępem administratorzy mogą łatwo przypisać, zmienić lub usunąć uprawnienia, co przekłada się na większą kontrolę i zgodność z regulacjami. Oczywiście w tak krótkim artykule nie możemy opisać wszystkich aspektów związanych z budowaniem modelu ról w organizacji, ani też wyzwań, które są z tym procesem związane. Warto jednak podkreślić, że istnieją rozwiązania, które od strony analitycznej oraz zarządzania cyklem życia roli mogą stanowić znaczące ułatwienie dla organizacji.
RBAC vs. ABAC
RBAC jest modelem uporządkowanym i prostym w zarządzaniu, ale może nie być wystarczająco elastyczny w niektórych zastosowaniach. Wejście na scenę ABAC rozwiązało te problemy, wprowadzając bardziej granularne i dynamiczne podejście do zarządzania dostępem. Attribute-Based Access Control (ABAC) powstał jako rozszerzenie i dalsza ewolucja modeli zarządzania dostępem takich jak Role-Based Access Control (RBAC). Główną motywacją do stworzenia ABAC była potrzeba większej elastyczności i dynamiki w zarządzaniu dostępem. Podczas gdy RBAC opiera się na przypisywaniu uprawnień na podstawie ról, co jest skuteczne i łatwe do zarządzania, może nie zawsze być wystarczająco precyzyjny w środowiskach o wysokim stopniu złożoności. Przypisywanie dostępu wyłącznie na podstawie ról może prowadzić do nadmiernego przydzielania uprawnień (over-permissioning) lub zbyt ograniczonego dostępu (under-permissioning).
ABAC został zaprojektowany, aby rozwiązać te problemy. W ABAC dostęp do zasobów jest kontrolowany na podstawie wartości atrybutów, które mogą obejmować informacje o użytkowniku, zasobie, akcji i środowisku. Na przykład polityka dostępu w ABAC może pozwolić pracownikowi działu HR na dostęp do pewnych danych osobowych tylko w godzinach pracy i tylko z siedziby firmy.
Dzięki tej granularności i dynamiczności ABAC może dostosować polityki dostępu do specyficznych potrzeb i wymagań biznesowych. Daje to organizacjom większą kontrolę nad dostępem do zasobów, pomaga w spełnianiu wymagań zgodności i zwiększa bezpieczeństwo poprzez minimalizację ryzyka nadmiernego przydzielania uprawnień. Główne cechy modelu ABAC to:
- Granularność: ABAC pozwala na definiowanie polityk dostępu na podstawie dowolnej kombinacji atrybutów, takich jak tożsamość użytkownika, czas, lokalizacja, rodzaj operacji, a nawet kontekst żądania. RBAC z kolei opiera się wyłącznie na roli użytkownika w systemie.
- Dynamika: ABAC umożliwia dynamiczne zmiany dostępu na podstawie zmieniających się atrybutów. Na przykład dostęp do pewnych zasobów może być ograniczony poza godzinami pracy. W RBAC dostęp jest zwykle statyczny i zmienia się tylko wtedy, gdy zmieni się rola użytkownika.
- Złożoność: Choć ABAC jest bardziej elastyczny, jest też bardziej skomplikowany do wdrożenia i zarządzania. RBAC, z jego prostym modelem bazującym na rolach, jest zazwyczaj łatwiejszy do zrozumienia i zarządzania.
Zgodność: W przypadku organizacji muszących przestrzegać określonych standardów bezpieczeństwa RBAC jest często preferowany ze względu na jego prostotę i łatwość audytu. ABAC tymczasem może oferować większą precyzję, ale jest trudniejszy do audytu i weryfikacji zgodności.
Podsumowując, RBAC i ABAC mają swoje unikalne mocne strony i słabości. Wybór między nimi zależy od specyficznych wymagań organizacji i środowiska, w którym system jest wdrażany. Model RBAC jest implementowany praktycznie w każdym rozwiązaniu klasy IAM\IGA, natomiast ABAC stosowany jest w rozwiązaniach dostarczających usług autoryzacji. Jeżeli interesuje Cię, jak w praktyce wygląda różnica pomiędzy tożsamością a kontem użytkownika i zarządzanie uprawnieniami przez role w modelu RBAC, zapraszamy do kontaktu z firmą Prolimes