RBAC vs ABAC — jak zaprojektować role

System uprawnień jest projektowany raz, na początku, na podstawie niepełnej wiedzy o tym, jak firma naprawdę pracuje. Potem przez lata dokłada się do niego wyjątki. Po trzech latach nikt nie potrafi odpowiedzieć na pytanie, kto ma dostęp do danych finansowych — i to jest moment, w którym koszt złej decyzji projektowej staje się widoczny.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Dwa modele w praktyce

Różnica sprowadza się do tego, skąd bierze się odpowiedź na pytanie o dostęp. W RBAC odpowiedź wynika z przypisania: użytkownik ma rolę, rola ma zestaw uprawnień. W ABAC odpowiedź jest wyliczana z reguły uwzględniającej cechy użytkownika, cechy zasobu i kontekst operacji.

Dlaczego RBAC wystarcza w większości przypadków

Firmy myślą o dostępie w kategoriach stanowisk, a nie reguł logicznych. Zdanie „księgowość widzi faktury, magazyn widzi wydania" jest naturalne dla osoby zarządzającej systemem i łatwe do zweryfikowania. Model odwzorowujący ten sposób myślenia jest przez to tańszy w utrzymaniu i mniej podatny na błędy konfiguracji.

Praktyczna zaleta ujawnia się przy audycie i przy zmianach kadrowych. Odpowiedź na pytanie, kto ma dostęp do danych płacowych, sprowadza się do wyświetlenia listy osób z odpowiednią rolą. W modelu opartym na regułach ta sama odpowiedź wymaga wykonania reguł dla każdego użytkownika i zasobu.

Jak zaprojektować role, żeby nie rozsypały się po roku

Najczęstszy błąd polega na tworzeniu roli dla każdego stanowiska w firmie. Po dwóch latach istnieje trzydzieści ról, z których połowa różni się jednym uprawnieniem, a nikt nie pamięta dlaczego. Skuteczniejsze podejście oddziela uprawnienia od ról.

• Zdefiniuj uprawnienia elementarne — pojedyncze czynności, jak „podgląd faktur" czy „zmiana ceny". To one są przedmiotem sprawdzenia w kodzie.
• Zbuduj role jako zestawy uprawnień, nazwane językiem firmy, nie językiem systemu.
• Utrzymuj kilka ról podstawowych zamiast kilkudziesięciu wariantów.
• Pozwól na wiele ról jednocześnie — osoba łącząca funkcje dostaje sumę uprawnień, zamiast wymuszać tworzenie nowej roli.
• Sprawdzaj w kodzie uprawnienie, nie rolę. Warunek odwołujący się do nazwy roli oznacza, że dodanie nowej roli wymaga zmian w kodzie.
• Zakres danych trzymaj osobno od uprawnień do czynności — to dwa różne wymiary dostępu.

Kiedy potrzebny jest ABAC

Model oparty na atrybutach staje się niezbędny, gdy dostęp zależy od danych, a nie od stanowiska. Kilka typowych sytuacji, w których czyste role przestają wystarczać.

• Podział terytorialny — handlowiec widzi wyłącznie klientów ze swojego regionu.
• Struktura organizacyjna — kierownik widzi dane podległych mu osób, a struktura zmienia się w czasie.
• Status dokumentu — zatwierdzonej faktury nie może edytować nikt poza wskazaną rolą.
• Limit kwotowy — zamówienia powyżej określonej wartości wymagają dodatkowej akceptacji.
• Kontekst czasowy lub sieciowy — dostęp do danych wrażliwych wyłącznie w godzinach pracy lub z sieci firmowej.
• Powiązanie z zasobem — autor dokumentu może go edytować niezależnie od pełnionej roli.

W takich przypadkach nie trzeba przebudowywać całego systemu. Wystarczy zachować role jako podstawę i dołożyć warstwę reguł zawężających zakres widocznych danych.

Model mieszany — jak to wygląda w praktyce

Sprawdzone podejście dzieli decyzję na dwa etapy. Najpierw rola odpowiada na pytanie, czy użytkownik w ogóle może wykonać daną czynność. Następnie reguła zakresu zawęża zbiór rekordów, których to dotyczy.

Przykładowo: rola „handlowiec" daje uprawnienie do podglądu i edycji klientów. Reguła zakresu ogranicza widoczność do klientów przypisanych do tego handlowca lub do jego regionu. Kierownik ma tę samą rolę z szerszym zakresem, a zarząd — z zakresem pełnym. Liczba ról pozostaje mała, a elastyczność jest zachowana.

Ważne, żeby reguły zakresu były egzekwowane w jednym miejscu, na poziomie warstwy dostępu do danych. Powielanie warunku w każdym zapytaniu prowadzi do sytuacji, w której jedno miejsce zostaje pominięte — najczęściej jest to eksport danych albo raport.

Checklista wdrożenia

• Uprawnienia sprawdzane po stronie serwera przy każdym żądaniu, z domyślną odmową dostępu.
• Interfejs ukrywa niedostępne funkcje, ale nie jest to traktowane jako zabezpieczenie.
• Zakres danych egzekwowany w jednym miejscu, obejmujący także raporty, eksporty i interfejs programistyczny.
• Rejestr zmian uprawnień — kto, komu i kiedy nadał rolę.
• Rejestr dostępu do danych wrażliwych, jeśli aplikacja je przetwarza.
• Widok podsumowania pokazujący, do czego uprawniona jest wskazana osoba.
• Okresowy przegląd uprawnień, co najmniej raz na kwartał.
• Procedura odejścia pracownika odbierająca dostępy tego samego dnia.
• Testy automatyczne sprawdzające, że użytkownik jednej roli nie sięgnie po zasoby innej.

Najczęstsze błędy

• Sprawdzanie roli zamiast uprawnienia w kodzie — każda nowa rola wymaga wtedy zmian programistycznych.
• Rola „administrator" nadawana z wygody osobom, które potrzebują dwóch dodatkowych uprawnień.
• Brak rozdzielenia czynności od zakresu danych, prowadzący do wykładniczego przyrostu liczby ról.
• Uprawnienia egzekwowane wyłącznie w interfejsie, przy niezabezpieczonych żądaniach.
• Pominięcie eksportów i raportów przy egzekwowaniu zakresu danych.
• Brak przeglądu uprawnień — po dwóch latach połowa dostępów należy do osób, które zmieniły stanowisko lub odeszły.

Podsumowanie

Dla większości aplikacji firmowych właściwym punktem wyjścia jest RBAC z uprawnieniami elementarnymi zebranymi w niewielką liczbę ról. Ten model jest zrozumiały dla osób nim zarządzających i pozwala szybko odpowiedzieć na pytania audytowe.

Reguły oparte na atrybutach warto dokładać punktowo, tam gdzie dostęp zależy od danych — regionu, struktury organizacyjnej, statusu dokumentu czy kwoty. Kluczowe jest przy tym rozdzielenie dwóch wymiarów: co użytkownik może robić i na których danych. Ta jedna decyzja projektowa decyduje o tym, czy po trzech latach system uprawnień będzie nadal zrozumiały.