Co to jest RBAC? Porównanie RBAC z ABAC na praktycznych przykładach

RBAC (Role-Based Access Control) to model kontroli dostępu, w którym uprawnienia przypisuje się rolom, a nie konkretnym osobom — użytkownik dostaje rolę, np. „Księgowa”, i automatycznie wszystkie uprawnienia tej roli. ABAC (Attribute-Based Access Control) idzie dalej: o dostępie decyduje reguła sprawdzająca atrybuty użytkownika, zasobu, akcji i kontekstu, np. dział, poziom poufności dokumentu, godzinę czy lokalizację.

Krótko mówiąc: RBAC jest prostszy i łatwiejszy do audytu, ABAC — bardziej precyzyjny i elastyczny, ale trudniejszy w utrzymaniu. W większości firm najlepiej sprawdza się połączenie obu modeli. Poniżej wyjaśniamy, jak działa każdy z nich, jak wyglądają w prawdziwych systemach i jak wybrać właściwy.

Kontrola dostępu: gdzie RBAC i ABAC mieszczą się w IAM

Zarządzanie tożsamością i dostępem (IAM) odpowiada na dwa pytania: kim jesteś (uwierzytelnianie) i co wolno Ci zrobić (autoryzacja). RBAC i ABAC to modele autoryzacji — zaczynają działać dopiero wtedy, gdy system już wie, kto wysłał żądanie, np. po zalogowaniu hasłem i kluczem FIDO2.

Historycznie stosowano kilka modeli:

Wszystkie służą temu samemu celowi: realizacji zasady najmniejszych uprawnień (least privilege), czyli dawaniu ludziom i usługom tylko takiego dostępu, jakiego naprawdę potrzebują.

Co to jest RBAC i jak działa kontrola dostępu oparta na rolach

W RBAC występują trzy podstawowe elementy:

1. Użytkownicy (lub konta usług),
2. Role — odzwierciedlają funkcje w organizacji: „Administrator sieci”, „Redaktor”, „Księgowy”,
3. Uprawnienia — pary „operacja + zasób”, np. „odczyt faktur”, „usuwanie wpisów”.

Uprawnienia przypisujesz do ról, a role do użytkowników. Gdy nowa osoba dołącza do działu księgowości, dostaje rolę „Księgowy” i od razu ma komplet potrzebnych uprawnień. Gdy odchodzi — odbierasz rolę i dostęp znika. Nie trzeba ręcznie przeglądać dziesiątek pojedynczych uprawnień.

Odmiany RBAC według modelu NIST

Model RBAC został ustandaryzowany przez NIST, a następnie jako norma ANSI INCITS 359. Opisuje on kolejne poziomy:

• Flat RBAC (podstawowy) — użytkownicy, role i uprawnienia, bez dodatkowych zależności.
• Hierarchical RBAC — role tworzą hierarchię i dziedziczą uprawnienia, np. „Kierownik zespołu” ma wszystko, co „Pracownik”, plus zatwierdzanie urlopów.
• Constrained RBAC — dochodzi rozdzielenie obowiązków (Separation of Duty). Statyczne (SSD) zabrania nadania jednej osobie dwóch sprzecznych ról, np. „zlecający przelew” i „zatwierdzający przelew”. Dynamiczne (DSD) pozwala mieć obie role, ale nie aktywować ich w tej samej sesji.
• Symmetric RBAC — dodaje możliwość przeglądu przypisań uprawnień do ról w obu kierunkach (jakie role dają dane uprawnienie), co ułatwia audyt.

Przykład RBAC w Kubernetesie

Kubernetes ma wbudowany mechanizm RBAC (opisany w dokumentacji Kubernetesa). Rola definiuje dozwolone operacje, a RoleBinding przypisuje ją użytkownikowi:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
  - kind: User
    name: jan
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Użytkownik jan może teraz przeglądać pody w przestrzeni nazw dev, ale nie może ich usuwać ani tworzyć.

Przykład RBAC w bazie danych

Bazy danych od dawna działają w modelu ról. W PostgreSQL wygląda to tak:

CREATE ROLE raporty NOLOGIN;
GRANT SELECT ON ALL TABLES IN SCHEMA sprzedaz TO raporty;

CREATE ROLE anna LOGIN PASSWORD 'zmien-mnie';
GRANT raporty TO anna;

Podobnie działają grupy zabezpieczeń w Active Directory Domain Services — grupa to w praktyce rola, której nadajesz uprawnienia do udziałów, folderów czy aplikacji.

Co to jest ABAC i jak działają polityki oparte na atrybutach

ABAC został szczegółowo opisany przez NIST w publikacji SP 800-162. Decyzja o dostępie zapada na podstawie reguły (polityki), która ocenia cztery grupy atrybutów:

Przykładowa reguła ABAC: „Pracownik może edytować dokument, jeśli należy do tego samego działu co dokument, dokument nie jest oznaczony jako ściśle tajny, a logowanie odbywa się z urządzenia służbowego”. Zapisanie tego w czystym RBAC wymagałoby osobnej roli dla każdego działu i każdego wariantu urządzenia.

Architektura ABAC: PEP, PDP, PIP, PAP

Standard XACML i NIST opisują elementy systemu ABAC:

• PEP (Policy Enforcement Point) — miejsce, które przechwytuje żądanie i egzekwuje decyzję, np. bramka API lub middleware aplikacji,
• PDP (Policy Decision Point) — silnik oceniający polityki i zwracający „zezwól” albo „odmów”,
• PIP (Policy Information Point) — źródło atrybutów, np. katalog użytkowników, CMDB, system HR,
• PAP (Policy Administration Point) — miejsce, w którym tworzy się i zarządza politykami.

Przykład ABAC w Open Policy Agent

Dziś ABAC rzadko wdraża się w XACML. Popularniejsze są silniki polityk takie jak Open Policy Agent (język Rego) czy Cedar od AWS. Przykładowa polityka w Rego:

package app.authz

default allow := false

allow if {
    input.action == "read"
    input.user.department == input.resource.department
    input.user.clearance >= input.resource.classification
}

Aplikacja wysyła do OPA dane o użytkowniku, zasobie i akcji, a OPA zwraca wynik allow. Reguły są oddzielone od kodu aplikacji, więc można je zmieniać i testować niezależnie.

ABAC jest też dostępny u dostawców chmury: w AWS IAM możesz uzależnić dostęp od tagów zasobu i tagów użytkownika (np. aws:ResourceTag/projekt równy aws:PrincipalTag/projekt), a w Azure — dodać warunki do przypisań ról dla danych w Azure Storage.

Porównanie RBAC z ABAC: najważniejsze różnice

Zalety i wady RBAC

Zalety: prostota, przewidywalność, łatwy audyt i zgodność z tym, jak działa organizacja (działy, stanowiska). Większość systemów — od Windowsa po chmury publiczne — obsługuje RBAC natywnie.

Wady: brak kontekstu i tendencja do nadmiernych uprawnień. Gdy ktoś potrzebuje wyjątku, łatwiej dodać go do kolejnej roli niż zaprojektować nową, więc z czasem użytkownicy kumulują dostęp. Przy wielu wyjątkach powstaje eksplozja ról — setki ról, których nikt nie rozumie.

Zalety i wady ABAC

Zalety: precyzja, możliwość reagowania na kontekst (np. blokada eksportu danych poza siecią firmową), mniej ról do utrzymania i łatwiejsze wdrożenie zasad Zero Trust.

Wady: większa złożoność. Polityki trzeba pisać, testować i wersjonować jak kod, a cały model jest tak dobry, jak dane o atrybutach — jeśli system HR nie zaktualizuje działu pracownika, ABAC podejmie błędną decyzję. Trudniej też odpowiedzieć audytorowi na pytanie, kto dokładnie ma dostęp do danego zasobu.

Ważne: ABAC nie poprawia samego uwierzytelniania. Jeśli ktoś przejmie konto, dostanie uprawnienia jego właściciela w każdym modelu. Atrybuty kontekstu, np. wymóg MFA czy zarządzanego urządzenia, mogą jedynie ograniczyć skutki takiego przejęcia.

RBAC czy ABAC — który model wybrać

Wybierz RBAC, gdy:

• organizacja ma czytelną strukturę stanowisk i niewiele wyjątków,
• liczy się łatwy audyt i szybkie wdrożenie,
• korzystasz z systemów, które natywnie obsługują role (AD, Microsoft Entra ID, Kubernetes, bazy danych).

Wybierz ABAC (lub dodaj go do RBAC), gdy:

• dostęp zależy od cech danych, np. klasyfikacji, regionu klienta, projektu,
• potrzebujesz reguł kontekstowych (godziny, lokalizacja, stan urządzenia),
• obsługujesz wielu klientów w jednej aplikacji (multi-tenant) i musisz pilnować, by nikt nie widział cudzych danych,
• liczba ról zaczyna rosnąć szybciej niż liczba stanowisk.

Model hybrydowy w praktyce

Najczęstszy scenariusz to RBAC z warunkami. Rola „Handlowiec” daje dostęp do modułu CRM, a reguła oparta na atrybutach ogranicza go do klientów z regionu przypisanego handlowcowi. Tak działa m.in. Azure, gdzie do przypisania roli można dodać warunek, oraz AWS, gdzie polityki IAM łączą role z tagami.

Niezależnie od modelu nie zapominaj o kontach uprzywilejowanych. Dostęp administracyjny warto objąć dodatkowym nadzorem — o tym, jak to zrobić, przeczytasz w tekście o Privileged Access Management (PAM) i w artykule wyjaśniającym PIM, PAM i PSM.

Jak wdrożyć kontrolę dostępu krok po kroku

1. Zinwentaryzuj zasoby i ich właścicieli — nie zabezpieczysz tego, o czym nie wiesz.
2. Spisz rzeczywiste funkcje w organizacji i zaprojektuj role na ich podstawie, a nie na podstawie uprawnień konkretnych osób.
3. Zdefiniuj konflikty ról (rozdzielenie obowiązków), np. tworzenie i zatwierdzanie płatności.
4. Zidentyfikuj reguły, których nie da się sensownie wyrazić rolami — to kandydaci do ABAC.
5. Ustal wiarygodne źródła atrybutów (HR, katalog użytkowników, system klasyfikacji danych).
6. Wprowadź cykliczne przeglądy dostępu (np. kwartalne) i automatyczne odbieranie uprawnień przy zmianie stanowiska lub odejściu z firmy.
7. Loguj decyzje autoryzacyjne — przydadzą się przy incydencie i audycie.

Dobrze zaprojektowany model ról i polityk jest też jednym z najlepszych sposobów na ograniczenie skutków przejęcia konta czy nieautoryzowanych narzędzi w firmie.