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.
Krótka odpowiedź: zacznij od RBAC — uprawnień przypisanych do ról. Pokrywa potrzeby zdecydowanej większości aplikacji firmowych i jest zrozumiały dla osób, które będą nim zarządzać.
ABAC — uprawnienia wyliczane z atrybutów użytkownika, zasobu i kontekstu — wprowadzaj punktowo, tam gdzie reguła zależy od danych, na przykład „handlowiec widzi wyłącznie klientów ze swojego regionu". Model mieszany jest w praktyce najczęstszy i najlepszy.
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.
| Aspekt | RBAC | ABAC |
|---|---|---|
| Podstawa decyzji | Przypisana rola | Atrybuty i reguły |
| Zrozumiałość dla administratora | Wysoka | Niska |
| Elastyczność | Ograniczona | Bardzo duża |
| Koszt wdrożenia | Niski | Wysoki |
| Audyt uprawnień | Prosty — lista ról | Trudny — trzeba wykonać reguły |
| Typowe zastosowanie | Większość aplikacji firmowych | Dostęp zależny od danych i kontekstu |
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.
Zasada, która oszczędza najwięcej pracy. Rozdziel dwa pytania: co użytkownik może robić (uprawnienie) oraz na których danych (zakres). Handlowiec i kierownik sprzedaży mogą mieć identyczne uprawnienia do czynności, różniąc się wyłącznie zakresem widocznych klientów. Połączenie tych wymiarów w jedną rolę prowadzi do wykładniczego przyrostu ich liczby.
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.
Najczęstsze pytania
W większości przypadków tak. Role odwzorowują sposób, w jaki firma myśli o dostępie — w kategoriach stanowisk — więc są zrozumiałe dla osób zarządzających systemem i łatwe do zweryfikowania podczas audytu. Reguły oparte na atrybutach warto dokładać punktowo, tam gdzie dostęp zależy od danych.
Rozdzielić dwa wymiary: uprawnienia do czynności i zakres widocznych danych. Handlowiec i kierownik mogą mieć identyczne uprawnienia, różniąc się wyłącznie tym, których klientów widzą. Połączenie obu wymiarów w jedną rolę prowadzi do sytuacji, w której po dwóch latach istnieje trzydzieści ról różniących się drobiazgami.
Ponieważ każda nowa rola wymaga wtedy zmiany kodu i wdrożenia. Warunek powinien odwoływać się do uprawnienia elementarnego, na przykład „podgląd faktur", a przypisanie tego uprawnienia do ról powinno być konfiguracją. Dzięki temu utworzenie nowej roli jest czynnością administracyjną, a nie programistyczną.
Co najmniej raz na kwartał, a przy danych wrażliwych częściej. Niezależnie od przeglądów potrzebna jest procedura odbierania dostępów w dniu odejścia pracownika lub zmiany stanowiska. Bez niej po dwóch latach znaczna część aktywnych dostępów należy do osób, które ich już nie potrzebują.
W eksportach, raportach i interfejsie programistycznym. Widok listy w aplikacji zwykle ma poprawnie zaimplementowane zawężenie, natomiast funkcja eksportu do arkusza bywa pisana osobno i pomija ten warunek. Dlatego reguła zakresu powinna być egzekwowana w warstwie dostępu do danych, a nie powtarzana w każdym zapytaniu.
Bezpłatna wycena Twojego projektu
Opisz w kilku zdaniach, co chcesz zbudować — stronę, aplikację czy sklep. Odpowiadamy w ciągu 24 godzin roboczych konkretną propozycją zakresu i harmonogramu. Konsultacja i wycena są bezpłatne, bez zobowiązań.