RBAC vs ABAC: którego modelu dostępu potrzebujemy?

Czym jest RBAC, po ludzku

Kontrola dostępu oparta na rolach grupuje uprawnienia w role i nadaje ludziom dostęp poprzez przypisanie ich do tych ról. Rola to nazwany zestaw uprawnień przypisany do stanowiska: „agent wsparcia", „księgowy", „inżynier". Rola agenta wsparcia może dawać dostęp do odczytu w systemie zgłoszeń i w kartotece klienta, ale nie w systemie płacowym. Uprawnień nie nadaje się ludziom bezpośrednio. Przypisuje się ludzi do ról, a to rola niesie ze sobą uprawnienia.

Sens tej pośredniości leży w administracji. Gdy dołącza nowy agent wsparcia, przypisujesz jedną rolę zamiast dwudziestu pojedynczych nadań. Gdy zespół wsparcia zyskuje dostęp do nowego narzędzia, zmieniasz rolę raz, a wszyscy w niej dziedziczą tę zmianę. Gdy ktoś zmienia stanowisko, zmieniasz mu rolę. Dostęp staje się czymś, o czym myślisz w kategoriach funkcji zawodowej, a nie konkretnej osoby.

RBAC ma formalny rodowód. David Ferraiolo i Rick Kuhn sformalizowali model w pracy z 1992 roku, a później przyjęto go jako amerykański standard krajowy, ANSI/INCITS 359 (zatwierdzony w 2004, zrewidowany w 2012). Standard definiuje podstawowe elementy: użytkowników, role, uprawnienia i przypisania między nimi, a także opcjonalne rozszerzenia, takie jak hierarchie ról, w których rola wyższego szczebla dziedziczy uprawnienia roli niższego szczebla. Nie trzeba czytać standardu, żeby korzystać z RBAC, ale model jest dobrze zdefiniowany, a nie doraźny.

Czym jest ABAC, po ludzku

Kontrola dostępu oparta na atrybutach decyduje o każdym żądaniu, oceniając atrybuty względem polityki. Zamiast pytania „czy ta osoba ma rolę, która na to pozwala", pojawia się pytanie „czy atrybuty tego żądania spełniają regułę". Atrybuty pochodzą z czterech szerokich źródeł: podmiotu (dział, staż, poziom dostępu, status zatrudnienia danej osoby), zasobu (jego klasyfikacja, właściciel, projekt), akcji (odczyt, edycja, usunięcie) i środowiska (pora dnia, sieć, lokalizacja, stan urządzenia).

Polityka to wtedy reguła zapisana na tych atrybutach. Na przykład: „użytkownik z działu finansowego, na zarządzanym urządzeniu, w godzinach pracy, może otwierać dokumenty sklasyfikowane jako wewnętrzne lub niższe". Żaden z tych warunków nie jest rolą. To fakty dotyczące żądania, sprawdzane w momencie, gdy ktoś prosi o dostęp. Zmień urządzenie, porę dnia albo klasyfikację dokumentu, a ta sama osoba może dostać inną odpowiedź.

NIST przedstawił referencyjną definicję w Special Publication 800-162. Siłą ABAC jest ekspresywność: można zakodować szczegółowe, świadome kontekstu reguły, których RBAC nie ujmie bez wymyślania osobnej roli dla każdej kombinacji. Koszt jest taki, że trzeba te atrybuty zdefiniować, pozyskać i im ufać, a do tego utrzymywać polityki, które z nich korzystają.

Porównanie obok siebie

• O dostępie decyduje · RBAC (oparty na rolach): Rola, jaką dana osoba pełni · ABAC (oparty na atrybutach): Atrybuty żądania, sprawdzane względem reguł
• Kluczowe pytanie · RBAC (oparty na rolach): „Jaką rolę ma ta osoba?" · ABAC (oparty na atrybutach): „Czy te atrybuty spełniają politykę?"
• Typowe dane wejściowe · RBAC (oparty na rolach): Funkcja zawodowa, zespół, staż · ABAC (oparty na atrybutach): Dział, lokalizacja, urządzenie, pora dnia, wrażliwość danych, status zatrudnienia
• Granularność · RBAC (oparty na rolach): Od zgrubnej do średniej: na poziomie roli · ABAC (oparty na atrybutach): Drobna: na poziomie kombinacji atrybutów, świadoma kontekstu
• Nakład wdrożeniowy · RBAC (oparty na rolach): Niższy: role definiuje się raz · ABAC (oparty na atrybutach): Wyższy: trzeba zdefiniować atrybuty, źródła i polityki
• Łatwość audytu · RBAC (oparty na rolach): Wysoka: wystarczy wylistować role i ich członków · ABAC (oparty na atrybutach): Niższa: trzeba analizować reguły i bieżące wartości atrybutów
• Łatwość wyjaśnienia · RBAC (oparty na rolach): Wysoka: „ona ma rolę księgowej" · ABAC (oparty na atrybutach): Niższa: zależy od wielu warunków w momencie żądania
• Wyjątki obsługuje przez · RBAC (oparty na rolach): Dodanie kolejnej roli (ryzyko eksplozji ról) · ABAC (oparty na atrybutach): Dostosowanie reguły lub atrybutu, bez nowej roli
• Standard referencyjny · RBAC (oparty na rolach): ANSI/INCITS 359 (Ferraiolo i Kuhn, 1992) · ABAC (oparty na atrybutach): NIST SP 800-162
• Najlepiej pasuje do · RBAC (oparty na rolach): Większości firm z segmentu mid-market, stabilnych struktur stanowisk · ABAC (oparty na atrybutach): Dużych lub regulowanych środowisk, które potrzebują kontroli świadomej kontekstu

Kompromis: prostota kontra elastyczność

Uczciwe podsumowanie jest takie, że RBAC oddaje elastyczność w zamian za prostotę, a ABAC oddaje prostotę w zamian za elastyczność. Żaden z nich nie jest bardziej zaawansowany ani bardziej poprawny. Oba znajdują się w różnych punktach tej samej osi.

RBAC jest prostszy w projektowaniu, audytowaniu i wyjaśnianiu. Możesz wylistować każdą rolę i wszystkich, którzy ją mają. Gdy ankieta od klienta albo przegląd dostępów pyta „kto ma dostęp do systemu rozliczeniowego", odpowiadasz, wymieniając role, które go dają, i czytając listę ich członków. Ta czytelność jest powodem, dla którego RBAC pozostaje wyborem domyślnym. W firmie liczącej kilkaset osób z względnie stabilnymi stanowiskami role mapują się czysto na sposób organizacji pracy, a model sam się broni.

ABAC jest silniejszy tam, gdzie liczy się kontekst. Jeśli dostęp naprawdę zależy od warunków: wrażliwości dokumentu, tego, czy urządzenie jest zarządzane, pory żądania, same role zmuszają cię do mnożenia ich liczby, żeby zakodować każdy przypadek. ABAC pozwala wyrazić warunek raz, jako regułę. Cena jest realna: potrzebujesz wiarygodnych danych o atrybutach, miejsca do oceny polityk i dyscypliny, żeby reguły pozostały zrozumiałe. Polityka, której nikt nie potrafi odczytać, to osobny rodzaj ryzyka, bo nikt nie powie z pewnością, co ona faktycznie zezwala.

Eksplozja ról: sygnał, że RBAC zaczyna się nie wyrabiać

Najwyraźniejszym sygnałem, że przeciągacie RBAC poza jego komfortowy zakres, jest eksplozja ról. Dzieje się tak, gdy każdy wyjątek staje się nową rolą. Jedna osoba potrzebuje dostępu agenta wsparcia plus jednego dodatkowego raportu, więc tworzycie rolę „agent wsparcia plus raportowanie". Potem wariant dla zespołu z UE, kolejny dla nocnej zmiany, jeszcze inny dla wersji kontraktorskiej. Każda z osobna wygląda sensownie. Po kilku latach administrujecie większą liczbą ról niż macie ludzi, a role przestają cokolwiek znaczyć, bo każda opisuje konkretny stos dostępu jednej osoby, a nie stanowisko.

Gdy już tam jesteście, RBAC traci właściwość, dla której w ogóle warto go było wdrożyć. Role miały czynić dostęp czytelnym i łatwym w administrowaniu, a katalog niemal identycznych ról z jednym posiadaczem działa odwrotnie. To moment, żeby zapytać, czy wyjątki, które wciąż kodujecie jako role, nie są w rzeczywistości zamaskowanymi atrybutami: regionem, zmianą, statusem umowy, wrażliwością danych. Jeśli tak, reguła oparta na atrybutach może zastąpić tuzin ról jedną polityką, i macie odpowiedź, gdzie ABAC zdobywa swoje miejsce.

Utrzymywanie małej liczby ról, powiązanych z realnymi funkcjami zawodowymi i regularnie przeglądanych, zapobiega większości przypadków eksplozji. Gdy zapobieganie już nie wystarcza, sama eksplozja jest diagnozą.

Kiedy który model pasuje

RBAC to właściwy punkt startowy i sensowny wybór domyślny dla większości firm z segmentu mid-market. Wybierzcie go, gdy wasze potrzeby dostępowe rozsądnie mapują się na funkcje zawodowe, gdy chcecie decyzji, które audytor odczyta na pierwszy rzut oka, i gdy nie macie jeszcze jasnej, powtarzającej się potrzeby reguł świadomych kontekstu. Większość organizacji jest w tej sytuacji dla większości swoich systemów, a sięganie po więcej rozwiązuje problem, którego nie mają.

ABAC zarabia na swoją złożoność, gdy kontekst faktycznie napędza dostęp. Wybierzcie go tam, gdzie wrażliwość danych musi bramkować dostęp niezależnie od roli, gdzie lokalizacja lub jurysdykcja zmienia, co ktoś może zobaczyć, gdzie trzeba egzekwować stan urządzenia albo porę dnia, albo gdzie liczba odrębnych sytuacji dostępowych jest zbyt duża, żeby modelować ją jako czyste role. Duże przedsiębiorstwa i środowiska regulowane trafiają na te warunki wcześniej, dlatego to tam ABAC pojawia się jako pierwszy.

Praktyczny test to nie „który jest lepszy", tylko „czy mam powtarzającą się potrzebę, z którą role radzą sobie słabo". Jeśli nie potraficie wskazać żadnej, RBAC wystarczy. Jeśli potraficie, to właśnie tam mają swoje miejsce atrybuty.

Czemu większość zespołów łączy oba modele

W praktyce oba modele zwykle się łączy, a to połączenie jest dojrzałą odpowiedzią, nie kompromisem. Role obsługują szerokie pociągnięcia: stanowisko danej osoby decyduje o większości tego, do czego ma dostęp. Atrybuty obsługują warunki, z którymi role radzą sobie słabo: ta rola, ale tylko na zarządzanym urządzeniu; ta rola, ale tylko dla danych sklasyfikowanych jako wewnętrzne lub niższe.

Częsty kształt to RBAC jako szkielet, z warunkami opartymi na atrybutach nałożonymi na przypadki, które ich potrzebują. Zachowujecie czytelność ról dla codziennego obrazu: „ona jest księgową, oto, do czego księgowe mają dostęp", a reguły atrybutowe rezerwujecie dla garści sytuacji, w których płaska rola albo nadawałaby zbyt wiele, albo zmuszała do eksplozji ról. Dzięki temu system pozostaje wytłumaczalny, a jednocześnie reaguje na kontekst tam, gdzie kontekst ma znaczenie.

Dyscyplina, która zapobiega eksplozji ról, czyli wyprowadzanie ról z realnych stanowisk i utrzymywanie ich w małej liczbie, ułatwia też późniejsze przejście w stronę atrybutów, bo będziecie już rozumieć, które z waszych wyjątków są w rzeczywistości atrybutami.

Źródła

• NIST, Role Based Access Control project (FAQs and standards) · https://csrc.nist.gov/projects/role-based-access-control (model RBAC, pochodzenie z pracy Ferraiolo-Kuhn 1992, standaryzacja INCITS 359)
• ANSI, Role Based Access Control (RBAC), INCITS 359 · https://blog.ansi.org/ansi/role-based-access-control-rbac-incits-359/ (INCITS 359-2004, zrewidowany w 2012)
• NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations · https://csrc.nist.gov/pubs/sp/800/162/upd2/final (definicja ABAC, kategorie atrybutów, podmiot/zasób/akcja/środowisko)
• NIST SP 800-162 full text (PDF) · https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf (opis funkcjonalny ABAC i uwagi)