Jak projektować role dostępowe, żeby nie zamieniły się w bałagan?

czym naprawdę jest RBAC

Kontrola dostępu oparta na rolach to prosty pomysł, który łatwo zepsuć. Zamiast nadawać uprawnienia ludziom pojedynczo, tworzysz role, podpinasz do nich uprawnienia i przypisujesz role ludziom. Rola to nazwany zestaw uprawnień odpowiadający jakiejś odpowiedzialności: „specjalista ds. zobowiązań”, „agent wsparcia”, „opiekun repozytorium”.

Reguła definiująca ten model, wywodząca się z modelu Ferraiolo i Kuhna z 1992 roku, na którym opierają się dzisiejsze systemy, mówi, że cały dostęp przechodzi przez role. Uprawnienia łączą się wyłącznie z rolami, a użytkownicy otrzymują uprawnienia jedynie przez role, które posiadają. NIST tłumaczy to wprost: w organizacji role są stosunkowo stabilne, podczas gdy użytkownicy i uprawnienia są liczni i szybko się zmieniają, więc kontrolowanie całego dostępu przez role upraszcza zarządzanie dostępem i jego przeglądanie.

Ta jedna reguła daje RBAC jego wartość. Jeśli potrafisz odpowiedzieć na pytania „co ta rola pozwala komuś robić?” i „kto ma tę rolę?”, potrafisz odpowiedzieć na pytanie „kto może to zrobić?” bez przeglądania każdego konta z osobna. W chwili, gdy pozwolisz, żeby uprawnienia były przypięte bezpośrednio do osoby poza jakąkolwiek rolą, otwierasz z powrotem lukę, którą RBAC miał zamknąć, i twój uporządkowany model zaczyna cię okłamywać.

Model został zestandaryzowany w 2004 roku jako ANSI/INCITS 359, zrewidowany jako INCITS 359-2012, i zbudowany z czterech komponentów. Core RBAC to minimum: użytkownicy, role, uprawnienia, przypisania między nimi oraz sesja, w której użytkownik aktywuje część swoich ról. Hierarchical RBAC dodaje hierarchie ról, więc rola wyższego szczebla dziedziczy uprawnienia roli niższego szczebla. Statyczne i dynamiczne ograniczenia rozdziału obowiązków pozwalają zadeklarować, że pewne role nigdy nie mogą być trzymane przez tę samą osobę ani aktywowane w tej samej sesji. Nie musisz mieć wszystkich czterech, żeby zacząć. Samo Core RBAC wprowadza porządek w większości środowisk mid-market.

role to nie to samo co grupy

Ludzie używają słów „rola” i „grupa” zamiennie, a systemy w tym nie pomagają: grupa w Active Directory i rola RBAC wyglądają w oknie dialogowym niemal identycznie. NIST rozdziela to jasno. Grupa to zwykle zbiór użytkowników. Rola to zbiór uprawnień. Problem z grupami w typowej implementacji polega na tym, że uprawnienia można podpiąć zarówno do grupy, jak i bezpośrednio do pojedynczych członków, co znowu otwiera tę samą lukę. Rola na to nie pozwala. Wiele zespołów buduje RBAC na mechanizmach grupowych, co jest w porządku, ale dyscyplinę trzeba utrzymać samodzielnie: uprawnienia idą na grupę reprezentującą rolę, nigdy na osobę.

pułapka eksplozji ról

Oto jak czysty projekt RBAC zamienia się w bagno. Zaczynasz od rozsądnej garstki ról. Potem jeden sprzedawca potrzebuje dostępu do raportu, którego reszta sprzedaży nie powinna widzieć, więc tworzysz rolę „Sprzedaż plus ten raport”. Potem ktoś w biurze w Monachium potrzebuje wariantu istniejącej roli, więc ją klonujesz. Potem zespół się dzieli, rusza projekt, kontraktor potrzebuje roli marketingu, ale nie do końca takiej samej. Każdy wyjątek wydaje się rozsądny. Każdy zamienia się w nową rolę.

To jest eksplozja ról i to jest charakterystyczny sposób, w jaki zawodzi RBAC. Przyczyna leży w tym, że RBAC potrafi wyrazić tylko „kto ma jaką rolę i co ta rola pozwala robić”. Nie ma natywnego sposobu, żeby powiedzieć „w godzinach pracy”, „tylko z sieci firmowej”, „tylko dla rekordów, które ktoś posiada”, albo „tylko w regionie Monachium”. Każdy z tych warunków, wyrażony w czystym RBAC, wymaga nowej roli. Role mnożą się szybciej niż ludzie.

Liczby robią się absurdalne. Analizy branżowe opisują organizacje zatrudniające tysiąc osób, które kończą z kilkoma tysiącami ról, czyli więcej ról niż użytkowników, co odwraca cały sens modelu. Jedno omówienie przedstawia to na konkretnej arytmetyce: pracownik potrzebujący dziesięciu aplikacji po dwie role każda to dwadzieścia ról dla jednej osoby, a przy rosnącym zbiorze aplikacji sumy sięgają setek i tysięcy. W tym momencie przeglądy dostępów zamieniają się w archeologię. Nikt nie potrafi powiedzieć, które role są jeszcze realne, audytorzy gubią wątek, a administratorzy spędzają czas na katalogu ról zamiast na faktycznym ryzyku.

RBAC nie jest tutaj zepsuty. Role powinny odwzorowywać trwałe funkcje zawodowe, a warunki zmienne dla poszczególnych osób, momentów czy rekordów trzeba obsłużyć w inny sposób. Kiedy łapiesz się na tym, że zaraz sklonujesz rolę, żeby doczepić do niej jeden warunek, zatrzymaj się. To sygnał, że dotarłeś do granicy tego, w czym role są dobre.

wyprowadzanie ról z realnych funkcji zawodowych

Droga wyjścia z eksplozji ról zaczyna się, zanim jeszcze stworzysz pierwszą rolę: projektuj role wokół tego, co ludzie faktycznie robią, a nie wokół dostępu, jaki akurat zdążyli nagromadzić.

NIST i literatura o inżynierii ról opisują dwa podejścia i potrzebujesz obu.

Podejście odgórne (top-down) zaczyna od biznesu. Patrzysz na funkcje zawodowe, rozmawiasz z ludźmi odpowiedzialnymi za każdą z nich i definiujesz rolę dla każdej funkcji, z uprawnieniami, jakich ta funkcja rzeczywiście wymaga. To daje dokładne, sensowne role, ale NIST zaznacza, że jest to żmudne i czasochłonne, bo trzeba dobrze rozumieć procesy biznesowe, a samo w sobie ignoruje dostęp, jaki ludzie już mają.

Podejście oddolne (bottom-up), często nazywane role mining, idzie w drugą stronę. Zaczynasz od uprawnień aktualnie przypisanych wszystkim użytkownikom i szukasz skupisk: grup ludzi mających niemal ten sam zestaw uprawnień. Te skupiska to kandydaci na role. To ujawnia rzeczywistość, w tym dostęp, o którego istnieniu zapomniałeś, ale samo w sobie grozi wpieczeniem dzisiejszego bałaganu, łącznie z nadmiernymi nadaniami, w jutrzejsze role.

Praktyczna metoda to hybryda. Naszkicuj role odgórnie na podstawie funkcji zawodowych, a potem sprawdź je oddolnie względem tego, kto co faktycznie ma. Tam, gdzie te dwa podejścia się rozjeżdżają, dowiadujesz się czegoś: albo roli brakuje uprawnienia, którego ludzie zasadnie potrzebują, albo grupa osób ma dostęp, którego ich stanowisko nie uzasadnia, co samo w sobie jest ustaleniem wartym działania.

Sprawdzona sekwencja dla zespołu z segmentu mid-market:

1. Wypisz odrębne funkcje zawodowe w firmie, nie stanowiska. Dwie osoby z różnymi tytułami często robią z punktu widzenia dostępu to samo, a jedna osoba może pełnić dwie funkcje.
2. Dla każdej funkcji zapisz systemy i poziom dostępu potrzebny do wykonania pracy, i nic ponadto. To tutaj wchodzi least privilege: rola powinna nadawać tylko to, czego funkcja wymaga.
3. Pobierz aktualne dane o uprawnieniach i pogrupuj je w skupiska. Porównaj skupiska z projektami swoich ról.
4. Rozwiąż rozbieżności. Dodaj brakujące uprawnienia do ról i oznacz do usunięcia dostęp, którego nikt nie potrafi uzasadnić.
5. Trzymaj liczbę ról w ryzach. Przydatny test rozsądku: większość ludzi powinna mieścić się w niewielkiej liczbie standardowych ról, a prawdziwe wyjątki obsługuj przez wniosek, a nie przez wymyślanie roli dla jednej osoby.

Celuj w role wystarczająco szerokie, żeby były wielokrotnego użytku i stabilne, a jednocześnie wystarczająco precyzyjne, żeby respektować least privilege. Rola pasująca dokładnie do jednej osoby to zwykle znak, że zamodelowałeś zestaw uprawnień, a nie stanowisko.

birthright access przez grupy

Część dostępu to nie przywilej, o który trzeba prosić. To baza, bez której stanowisko w ogóle nie istnieje: e-mail, katalog firmowy, narzędzie do czatu, wspólny dysk, z którego korzystają wszyscy, portal samoobsługowy HR. Zmuszanie ludzi, żeby prosili o to pojedynczo, marnuje czas wszystkich i z niecierpliwości ma tendencję do produkowania nadmiernych nadań.

Ta baza to birthright access: z góry zdefiniowany minimalny zestaw uprawnień, który przychodzi z rolą lub rodziną stanowisk, nadawany automatycznie, a nie na żądanie. W praktyce wdraża się to, mapując dane tożsamości na członkostwo w grupach. Kiedy HR zapisuje, że ktoś jest nowym „specjalistą ds. marketingu w Berlinie”, provisioning przypisuje grupy niosące bazę marketingową i standardową bazę ogólnofirmową, a osoba ma to, czego potrzebuje, już pierwszego dnia, bez żadnych zgłoszeń.

Dobrze zrobiony birthright access działa na rzecz least privilege, a nie przeciwko niej. Ludzie zaczynają od minimum, jakiego wymaga ich rola, zamiast dostawać szeroki dostęp, który ktoś musi później odbierać. Dyscyplina, która to utrzymuje, polega na trzymaniu zestawu birthright wąsko: to najmniejsza stabilna baza, jakiej rola potrzebuje do funkcjonowania, a wszystko ponadto idzie przez wniosek. Tryb awarii, którego trzeba unikać, to dopychanie birthright access „żeby zaoszczędzić czas później”. Każde uprawnienie dodane do bazy jest nadawane automatycznie i po cichu każdemu przyszłemu posiadaczowi tej roli, i tak właśnie przywileje kumulują się w skali. Jeśli dostęp jest wrażliwy albo potrzebuje go tylko część osób w danej roli, nie ma miejsca w zestawie birthright.

birthright access kontra dostęp na żądanie

Te dwie ścieżki się uzupełniają. Birthright pokrywa przewidywalną bazę. Dostęp na żądanie pokrywa wszystko inne: dodatkowy system, podwyższone uprawnienie, tymczasowy dostęp do projektu. Wniosek powinien nieść ze sobą zatwierdzenie, uzasadnienie i najlepiej termin wygaśnięcia, żeby zostawiał ślad, który można później przejrzeć. Wnioski ograniczone czasowo są szczególnie przydatne dla dostępu, który jest naprawdę tymczasowy, bo wygasają same, zamiast stawać się trwałe przez zaniedbanie.

Uważaj na jedną pułapkę: jeśli twoja baza birthright jest zbyt wąska, a proces wniosków powolny albo uciążliwy, ludzie ją obchodzą, i ścieżka wniosków po cichu zamienia się w drugą ścieżkę birthright, w której wszyscy proszą o te same dodatkowe rzeczy pierwszego dnia. Naprawą jest dostrojenie bazy tak, żeby naprawdę pokrywała typowy przypadek, i utrzymanie ścieżki wniosków wystarczająco szybkiej, żeby nikt nie czuł pokusy magazynowania dostępu.

kiedy sięgnąć po ABAC

Kontrola dostępu oparta na atrybutach decyduje o dostępie inaczej. Zamiast „czy ten użytkownik ma tę rolę”, ocenia atrybuty względem polityki: atrybuty użytkownika (dział, poziom uprawnień, lokalizacja), zasobu (wrażliwość, właściciel, projekt), akcji, a czasem środowiska (pora dnia, sieć). NIST definiuje ABAC w Special Publication 800-162 jako autoryzację ustalaną przez ocenę atrybutów względem reguł, które wyrażają dozwolone operacje dla danego zestawu atrybutów.

Siła ABAC to dokładnie słabość RBAC. Warunki powodujące eksplozję ról, „w godzinach pracy”, „z sieci firmowej”, „tylko dla rekordów, które ktoś posiada”, „tylko w swoim regionie”, są w ABAC naturalne, bo to po prostu atrybuty w regule. Piszesz jedną politykę zamiast klonować rolę dla każdej kombinacji, a NIST SP 800-162 zaznacza, że dzięki temu można nadawać dostęp bez wcześniejszej znajomości konkretnego użytkownika, jakiej wymaga RBAC.

Koszt jest jednak realny. ABAC trudniej ogarnąć rozumowo. Przy RBAC możesz zapytać „kto ma tę rolę?” i dostać listę. Przy ABAC, kto ma dostęp, jest wynikiem polityk ocenianych na podstawie danych atrybutów, więc musisz ufać zarówno logice polityki, jak i jakości zasilających ją atrybutów. Jeśli twoje dane HR mówią, że ktoś jest w złym dziale, ABAC wiernie nada mu zły dostęp. Zależy od czystych, wiarygodnych atrybutów, których wiele firm mid-market jeszcze nie ma.

Dla większości zespołów odpowiedzią jest RBAC jako szkielet, z atrybutami dołożonymi na warunki, z którymi role radzą sobie słabo. Używaj ról dla stabilnego „jakie to jest stanowisko”. Używaj atrybutów dla kontekstowego „w jakich okolicznościach”. Częsty wzorzec: rola nadaje szeroką zdolność, a reguła atrybutu ją zawęża, więc „Sprzedaż” plus „region = DACH” zastępuje osobną rolę „Sprzedaż-DACH” i zapobiega całej rodzinie klonów. Sięgaj po ABAC, kiedy zauważasz, że zaraz sklonujesz rolę, żeby zakodować warunek. To jest moment, w którym atrybuty zarabiają na swoją złożoność.

jak utrzymać role w stanie możliwym do zarządzania

Role to nie projekt, który się kończy. To system, który się prowadzi. Bez utrzymania degradują się w przewidywalny sposób: ludzie zmieniają stanowiska i zatrzymują stare role obok nowych, wyjątki się piętrzą, martwe role zalegają w katalogu, a konta gromadzą dostęp daleko wykraczający poza obecną funkcję. Ten dryf, privilege creep, to jedna z najczęściej wymienianych pierwotnych przyczyn incydentów związanych z ryzykiem wewnętrznym, dlatego usuwanie musi być nawykiem wbudowanym w projekt, a nie czymś, co robi się po incydencie.

Co utrzymuje system ról w dobrej kondycji:

• Powiąż zmiany ról z cyklem życia. Kiedy ktoś dołącza, zmienia stanowisko albo odchodzi, jego role powinny się zmieniać razem z nim. Osoba zmieniająca stanowisko powinna w szczególności stracić dostęp ze starej pracy, a nie tylko zyskać dostęp z nowej. Trzymanie obu naraz to sposób, w jaki ludzie kończą z rozrośniętym, nie do obronienia dostępem zbieranym przez całą karierę. Szerzej opisuje to przewodnik o joiner-mover-leaver.
• Przeglądaj okresowo i skup się na wyjątkach. Cykliczne przeglądy dostępów sprawdzają, czy ludzie wciąż mają tylko role uzasadnione ich stanowiskiem. Najbardziej wartościowe przeglądy porównują przypisany dostęp z faktycznym użyciem, co ujawnia nieużywane role, nieaktualne uprawnienia i dostęp, który wykroczył poza czyjąś funkcję. Poświęć uwagę uprawnieniom wysokiego ryzyka i wyjątkom, a nie automatycznemu zatwierdzaniu oczywistej bazy.
• Usuwaj to, co nieużywane. Rola, której nikt nie ma, albo uprawnienie, z którego nikt nie korzysta, to ryzyko bez żadnej korzyści. Wygaszaj uśpione role i odwołuj nieaktualne nadania. Celem jest katalog, w którym każda rola wciąż odwzorowuje realne stanowisko.
• Utrzymuj jawne reguły rozdziału obowiązków. RBAC został zaprojektowany z myślą o rozdziale obowiązków, a standard wspiera deklarowanie, że konfliktujące role nie mogą być trzymane ani aktywowane razem. Tam, gdzie kombinacja pozwoliłaby jednej osobie zarówno tworzyć, jak i zatwierdzać tę samą transakcję, zakoduj ten konflikt, zamiast liczyć, że ludzie o nim pamiętają.
• Trzymaj zasadę braku bezpośrednich nadań. Dyscyplina, która utrzymuje uczciwość całego modelu, to nigdy nie podpinać uprawnień bezpośrednio do osoby. Każde nadanie przechodzi przez rolę albo przez śledzony, wygasający wniosek. W chwili, gdy zrobisz pierwszy wyjątek „tylko tym razem”, zaczyna się dryf z powrotem w stertę.

Utrzymywalność to w większości gotowość do odejmowania. Większość systemów ról zawodzi, bo wszyscy dokładali, a nikt nie usuwał. Wbuduj usuwanie w rytm, a projekt się utrzyma.

Źródła

• Role Based Access Control RBAC, NIST CSRC FAQs · https://csrc.nist.gov/projects/role-based-access-control/faqs (model Ferraiolo-Kuhna z 1992 roku, reguła całego dostępu przez role, rozróżnienie rola kontra grupa, struktura standardu INCITS 359 i cztery komponenty, rozdział obowiązków)
• Role Engineering and RBAC Standards, NIST CSRC · https://csrc.nist.gov/projects/role-based-access-control/role-engineering-and-rbac-standards (inżynieria ról odgórna kontra oddolna, role mining, podejście hybrydowe)
• Guide to Attribute Based Access Control (ABAC) Definition and Considerations, NIST SP 800-162 · https://csrc.nist.gov/pubs/sp/800/162/upd2/final (definicja ABAC, autoryzacja oparta na atrybutach, skalowanie bez wcześniejszej znajomości konkretnego użytkownika)
• INCITS Announces the New Standard for Role Based Access Control · https://www.incits.org/news-events/press-releases/incits-announces-the-new-standard-for-role-based-access-control-rbac (standaryzacja INCITS 359)
• Role Explosion: The Hidden Cost of RBAC, Permify · https://permify.co/post/role-explosion/ (mechanika eksplozji ról, arytmetyka dziesięciu aplikacji i dwudziestu ról, więcej ról niż użytkowników)
• Role Explosion, Evolveum Docs · https://docs.evolveum.com/iam/role-explosion/ (tysiąc pracowników do tysięcy ról, wyjątki zamieniające się w role)
• Using attribute-based access control to solve role explosion, Thoughtworks · https://www.thoughtworks.com/insights/blog/microservices/using-abac-solve-role-explosion (ograniczenia wyrazowe RBAC, warunki, których RBAC nie potrafi zakodować natywnie)
• What is the difference between birthright access and request-based access, NHIMG · https://nhimg.org/faq/what-is-the-difference-between-birthright-access-and-request-based-access/ (birthright access kontra dostęp na żądanie, wąska baza, ukryta ścieżka birthright)
• What is Birthright Access, BeyondTrust · https://www.beyondtrust.com/resources/glossary/birthright-access (birthright access przez zautomatyzowany provisioning, least privilege od podstaw projektu)
• Which RBAC Approach Is Better: Top-Down or Bottom-Up, Idenhaus · https://idenhaus.com/rbac-approach-top-down-bottom-up/ (kompromisy inżynierii ról odgórnej i oddolnej)
• What is Principle of Least Privilege, Cyberhaven · https://www.cyberhaven.com/infosec-essentials/what-is-principle-of-least-privilege-polp (least privilege, certyfikacja dostępu, usuwanie nieaktualnych uprawnień, privilege creep jako pierwotna przyczyna ryzyka wewnętrznego)