Kontrola dostępu oparta na rolach (RBAC) to sposób decydowania, kto może co zrobić w systemie, polegający na przypisywaniu uprawnień do ról, a następnie przypisywaniu ludzi do tych ról. Nikt nie otrzymuje uprawnień pojedynczo. Handlowiec, kontroler finansowy i lider supportu dostają dostęp potrzebny do ich pracy i nic ponad to. Ten przewodnik wyjaśnia, jak działa RBAC, jak projektować role, które pozostają łatwe w zarządzaniu, kiedy lepszym wyborem jest kontrola dostępu oparta na atrybutach (ABAC) i co się zmienia, gdy agenci AI zaczynają odczytywać i zapisywać dane Twojej firmy.

W skrócie

Spis treści

Czym jest kontrola dostępu oparta na rolach

RBAC to model autoryzowania dostępu do systemów, aplikacji i danych na podstawie wcześniej zdefiniowanej roli użytkownika. IBM opisuje go jako sytuację, w której administrator przypisuje każdemu użytkownikowi jedną lub więcej ról, a każda rola reprezentuje zestaw uprawnień lub przywilejów.

Cechą definiującą jest to, że cały dostęp przechodzi przez role. Według FAQ NIST Computer Security Resource Center rola to w istocie zbiór uprawnień, a użytkownicy otrzymują uprawnienia wyłącznie poprzez przypisane im role lub role dziedziczone w hierarchii ról. To odróżnia RBAC od zwykłych grup, w których uprawnienia mogą być powiązane zarówno z użytkownikami, jak i z grupami. NIST zauważa, że tworzy to lukę, przez którą trudno kontrolować relacje między użytkownikami a uprawnieniami.

Konkretny przykład dla firmy SaaS:

Rola Typowy dostęp w CRM Typowy dostęp w systemie finansowym Typowy dostęp w panelu administracyjnym produktu
Account Executive Własne konta i transakcje, odczyt i zapis Brak Brak
Sales Manager Konta zespołu, widoki prognozy Status faktur tylko do odczytu Brak
Finance Controller Dane kont tylko do odczytu Pełny dostęp do fakturowania i raportowania Brak
Customer Success Manager Przypisane konta, pola odnowień Status faktur tylko do odczytu Ograniczone ustawienia tenanta
Support Engineer Kontakty kont tylko do odczytu Brak Diagnostyka tenanta
Administrator Konfiguracja Konfiguracja Pełny

Gdy do zespołu dołącza nowy account executive, przypisujecie mu jedną rolę. Nie odtwarzacie kilkunastu pojedynczych decyzji dotyczących uprawnień.

Jak działa RBAC: trzy zasady i cztery składniki

Model NIST opiera się na trzech zasadach, opisanych w publikacji NIST Role Engineering: Methods and Standards:

  1. Przypisanie roli. Użytkownik może skorzystać z uprawnienia tylko wtedy, gdy ma przypisaną rolę.
  2. Autoryzacja roli. Aktywna rola użytkownika musi być dla niego autoryzowana.
  3. Autoryzacja uprawnienia. Użytkownik może skorzystać z uprawnienia tylko wtedy, gdy jest ono autoryzowane dla jego aktywnej roli.

Ta sama publikacja podaje, że NIST zaproponował ujednolicony model RBAC w 2000 roku, a w 2004 roku został on zatwierdzony jako amerykański standard krajowy INCITS 359-2004.

Zgodnie z dokumentem ANSI INCITS 359-2004 standard ten składa się z czterech komponentów:

Podział obowiązków ma największe znaczenie w finansach. Osoba, która tworzy płatność na rzecz dostawcy, nie powinna być osobą, która ją zatwierdza. Statyczny podział obowiązków egzekwuje to już w momencie przypisania ról, co jest najprostszym i najłatwiejszym do audytu sposobem.

Jak projektować role, które pozostają łatwe w zarządzaniu

To na etapie projektowania większość projektów RBAC odnosi sukces lub ponosi porażkę. Zestaw ról odzwierciedlający sposób działania firmy łatwo wyjaśnić i przeglądać. Zestaw ról odzwierciedlający pola wyboru w każdym narzędziu staje się labiryntem.

Zacznijcie od funkcji biznesowych

Wytyczne IBM dotyczące wdrożeń mówią, że najbardziej solidne projekty zaczynają się od funkcji biznesowych i procesów, a nie od menu aplikacji. Zamiast pytać, które pola zaznaczyć w CRM, zapytajcie, co faktycznie robi handlowiec, a następnie opiszcie te czynności jako definicje ról, które można odwzorować w wielu systemach.

Ten ostatni punkt ma praktyczne znaczenie. Rola „Customer Success Manager” powinna oznaczać to samo w Waszym CRM, narzędziu do rozliczeń, systemie obsługi klienta i każdym portalu wewnętrznym. Definiujecie ją raz jako rolę biznesową, a następnie odwzorowujecie w każdym systemie.

Jedna rola biznesowa odwzorowana w czterech systemach

Wybierzcie podejście do inżynierii ról

Publikacja NIST o inżynierii ról opisuje trzy podejścia:

Dokumentacja Oracle dotycząca tożsamości również zaleca podejście hybrydowe przy eksploracji ról (role mining). W firmie liczącej od 20 do 200 osób podejście hybrydowe jest zwykle realistyczne. Poświęćcie kilka godzin z szefem każdej funkcji na opracowanie szkicu ról, a następnie wyeksportujcie bieżące uprawnienia z CRM i systemu finansowego i sprawdźcie, gdzie rzeczywistość się różni. Połączenie obu metod pozwala uniknąć ról zbyt teoretycznych oraz ról budowanych wokół kilku odstających przypadków.

Praktyczna sekwencja

  1. Zinwentaryzujcie systemy i dane. Wypiszcie systemy przechowujące dane o klientach, przychodach i produkcie oraz zaznaczcie, które rekordy są wrażliwe.
  2. Opracujcie szkic ról dla każdej funkcji. Zacznijcie od szerokich kategorii. IBM zauważa, że organizacje często zaczynają od rozdzielenia administratorów, specjalistów lub użytkowników eksperckich oraz użytkowników końcowych.
  3. Wyeksportujcie rzeczywiste uprawnienia. Pobierzcie z każdego systemu bieżący dostęp każdej osoby i pogrupujcie podobne wzorce.
  4. Uzgodnijcie różnice. Tam, gdzie ktoś ma znacznie więcej dostępu niż wynika z jego szkicu roli, zdecydujcie, czy błędna jest rola, czy osoba zgromadziła dostęp, który powinna utracić.
  5. Wskażcie właściciela każdej roli. Jedna osoba odpowiada za to, co rola zawiera.
  6. Wdróżcie, a potem przeglądajcie. Przenieście osoby na role, usuńcie uprawnienia nadane bezpośrednio i zaplanujcie pierwszy przegląd.

Dobre praktyki RBAC w długiej perspektywie

Wytyczne IBM mówią, że długoterminowa kondycja RBAC zależy od nadzoru: okresowych przeglądów dostępu skupionych na wyjątkach i przypadkach odstających, procesów joiner-mover-leaver, które automatycznie zmieniają role na podstawie zdarzeń w HR, oraz ograniczonych w czasie, zatwierdzonych wyjątków dla nietypowego dostępu.

Stosujcie zasadę najmniejszych uprawnień poprzez projekt

Przewodnik Avatier po najlepszych praktykach RBAC w przedsiębiorstwach wymienia cztery mechanizmy prowadzące do najmniejszych uprawnień:

Drugi mechanizm jest najczęściej pomijany. Osoby zmieniające zespoły gromadzą dostęp. Po dwóch lub trzech zmianach customer success manager może mieć uprawnienia do lejka sprzedaży i rozliczeń, których nikt nie planował.

Zapobiegaj lawinowemu wzrostowi liczby ról

To samo źródło określa lawinowy wzrost liczby ról jako dominujący sposób, w jaki takie systemy zawodzą: nowa, szyta na miarę rola dla każdego przypadku brzegowego. Zapobieganie jest tańsze niż porządkowanie. Przypisz każdej roli właściciela, wybieraj łączenie istniejących ról zamiast tworzenia nowych i przeprowadzaj recertyfikację według harmonogramu. Przydatny test: jeśli proponowana rola miałaby tylko jednego posiadacza, to prawdopodobnie jest wyjątkiem, a nie rolą. Potraktuj ją jako zatwierdzony wyjątek ograniczony w czasie.

Utrzymuj niewielki nakład na utrzymanie

Okta zwraca uwagę, że RBAC nie wymaga intensywnego utrzymania: uprawnienia podążają za rolami, więc nowe stanowisko staje się nową rolą nadawaną wielu osobom przy niewielkim wysiłku administratora. Dotyczy to jednak tylko sytuacji, gdy zestaw ról pozostaje mały i uporządkowany, dlatego tak ważne są odpowiedzialność i przeglądy.

Krótka lista kontrolna

RBAC a ABAC: którego potrzebujesz?

ABAC decyduje o dostępie, oceniając względem polityki atrybuty użytkownika, zasobu, działania, a czasem także środowiska. Tak definiuje to NIST SP 800-162, zauważając przy tym, że ACL i RBAC są pod pewnymi względami szczególnymi przypadkami ABAC, jeśli chodzi o używane atrybuty.

Mówiąc prosto: RBAC pyta „jaka jest Twoja praca?”, a ABAC pyta „jaka jest Twoja praca, czego dotykasz, jak wiele jest stawką i skąd działasz?”

Porównanie Okta wskazuje, że RBAC sprawdza się w małych, prosto zorganizowanych zespołach i środowiskach z jasno określonymi funkcjami stanowisk. ABAC pasuje do zespołów rozproszonych geograficznie lub działających w określonych ramach czasowych oraz do sytuacji, w których potrzeby dostępu zmieniają się w zależności od dokumentu, a nie roli.

Pytanie RBAC ABAC
Podstawa decyzji Rola Atrybuty użytkownika, zasobu, działania i kontekstu
Najłatwiejszy do wyjaśnienia audytorowi Tak Wymaga więcej wysiłku
Obsługuje „tylko transakcje poniżej ustalonej kwoty” Niewygodne, zwykle prowadzi do dodawania ról Naturalne
Obsługuje „tylko konta z Twojego regionu” Wymaga roli dla każdego regionu Naturalne
Nakład na wdrożenie Niższy Wyższy

Większość rosnących firm SaaS nie wybiera jednego z nich. Zespół ds. tożsamości w Okta zauważa, że wiele organizacji stosuje podejście hybrydowe: RBAC dla szerokich poziomów dostępu i ABAC dla precyzyjnych kontroli. Avatier wskazuje to samo z drugiej strony: RBAC jest podstawą, a decyzje zależne od kontekstu, takie jak czas, lokalizacja, kwota czy urządzenie, należą do ABAC nałożonego na wierzch. Praktyczna zasada brzmi: zacznij od RBAC i dodawaj reguły oparte na atrybutach tylko tam, gdzie liczba ról musiałaby się w przeciwnym razie mnożyć, na przykład przy limitach regionalnych lub limitach wartości transakcji.

Narzędzia wewnętrzne i RBAC

Narzędzia wewnętrzne to miejsce, w którym kontrola dostępu po cichu zawodzi. Eksport arkusza z CRM, panel administracyjny zbudowany przez jednego inżyniera, pulpit finansowy udostępniony linkiem: każde z nich to miejsce, w którym role są omijane. Pomagają trzy nawyki:

Jeśli budujesz lub kupujesz wewnętrzne portale, zapytaj, jak definiowane są role, kto może je zmieniać i czy zmiany są rejestrowane. To pytania, które zada recenzent bezpieczeństwa lub kwestionariusz klienta.

RBAC, gdy pojawiają się agenci AI

AI zmienia kwestię dostępu w jeden konkretny sposób: asystent lub agent może w jednym zapytaniu sięgnąć do wielu systemów. Jeśli jest połączony za pomocą szerokiego konta usługowego, może zwrócić dane, do których osoba pytająca nigdy nie miała dostępu.

Rozwiązaniem nie jest nowy model bezpieczeństwa. Jest nim zastosowanie tego, który już masz:

Jest też miejsce, w którym AI nie powinno mieć głosu: decydowanie o tym, kto dostaje dostęp. Nadawanie, zmiana i zatwierdzanie ról powinny pozostać w rękach wskazanych osób, które działają zgodnie z Państwa polityką. Agent może przygotować listę do przeglądu lub zasygnalizować odstępstwa, ale decyzję podejmuje człowiek.

Regulacje wskazują ten sam kierunek. GDPR, NIS2 i EU AI Act dotyczą sposobu kontroli danych i systemów, a dobrze zaprojektowana kontrola dostępu jest jednym z typowych elementów, na których firmy opierają się, pracując nad zgodnością. RBAC sam w sobie nie zapewnia zgodności firmy z przepisami, a ten artykuł nie stanowi porady prawnej. Proszę zapytać swojego doradcę prawnego, co dotyczy Państwa firmy.

Więcej o tym, jak łączą się ład organizacyjny i AI, znajdą Państwo w naszym materiale AI governance framework dla firm SaaS B2B.

Perspektywa

Ten sam schemat widzimy w firmach SaaS zatrudniających od 20 do 200 osób. Role nigdy nie zostały zaprojektowane. Dostępy narastały wraz z każdym nowym narzędziem, a potem pojawiła się AI, która zaczęła czytać dane z nich wszystkich.

Dlatego budujemy w ustalonej kolejności. Najpierw fundament danych: Państwa dane z CRM i finansów jako uzgodnione źródło prawdy, z rolami, które znaczą to samo w każdym systemie. Potem warstwa AI, która łączy te dane z asystentem, z którego Państwa zespół już korzysta. Następnie agenci działowi dla Finansów, Sprzedaży i Customer Success. Każda warstwa dziedziczy zasady dostępu warstwy niższej.

Naszym zdaniem agent nigdy nie powinien mieć większego zaufania niż osoba, która z niego korzysta. Działa w granicach uprawnień tej osoby, prosi o zatwierdzenie tam, gdzie działanie ma znaczenie, i zostawia ślad audytowy. Projektowanie ról nie jest dodatkowym zadaniem w projekcie AI. Jest jego pierwszym elementem.

Claus Nielsen

Gdzie pasuje NordOps Consulting

Jeśli Państwa zespół już korzysta z AI, ale nikt nie odpowiada za to, jak ona dotyka Państwa danych, dobrym pierwszym krokiem jest zaprojektowanie dostępów. NordOps Consulting działa jako Fractional Chief AI Officer dla firm SaaS B2B w Europie: jedna wskazana osoba, która decyduje, gdzie AI się opłaca, buduje fundament danych oraz tworzy agentów, z których Państwa ludzie korzystają zwykłym językiem, w granicach uprawnień i ze śladem audytowym.

AI Readiness Assessment to jasno określony punkt wyjścia, od €4,500. Na potrzeby stałej odpowiedzialności abonament Fractional CAIO zaczyna się od €1,500 miesięcznie. Można też zacząć od bezpłatnej, 30-minutowej rozmowy wstępnej umówionej przez naszą stronę. Aby zobaczyć, jak przebiegają kolejne etapy pracy, proszę przeczytać jak to działa lub zajrzeć do Admin Portal, gdzie role i dostępy użytkowników są zarządzane razem z agentami.

FAQ

Jaka jest różnica między rolą a uprawnieniem?

Uprawnienie to pojedyncza dozwolona czynność na zasobie, na przykład odczyt faktury lub edycja transakcji. Rola to nazwany zestaw uprawnień odpowiadający funkcji zawodowej. Użytkownikom przypisuje się role, a role niosą uprawnienia.

Czy RBAC wystarczy, czy potrzebuję ABAC?

Dla większości zespołów RBAC jest właściwym punktem wyjścia, ponieważ łatwo go wyjaśnić i poddać audytowi. Reguły ABAC warto dodawać dopiero wtedy, gdy liczy się kontekst, na przykład ograniczanie dostępu według regionu, wielkości transakcji lub czasu. Wiele organizacji stosuje oba podejścia: RBAC dla szerokich poziomów, a ABAC dla szczegółów.

Ile ról powinna mieć firma?

Nie ma standardowej liczby. Role powinny być powiązane z rzeczywistymi funkcjami zawodowymi, każda powinna mieć właściciela, a jednorazowe potrzeby należy traktować jako wyjątki ograniczone w czasie. Jeśli rolę miałaby pełnić tylko jedna osoba, to znak, że jest to wyjątek, a nie rola.

Jak często należy przeglądać role i dostępy?

Warto ustalić regularny harmonogram i dodatkowo przeprowadzać przegląd za każdym razem, gdy ktoś zmienia stanowisko lub odchodzi. Wytyczne IBM zalecają okresowe przeglądy dostępów skoncentrowane na wyjątkach i odstępstwach oraz automatyczne zmiany uruchamiane zdarzeniami HR. Proszę wybrać rytm, który zespół jest w stanie utrzymać, ponieważ pominięty przegląd jest gorszy niż lżejszy.

Jak traktować agentów AI w modelu RBAC?

Należy traktować ich jako działających w imieniu osoby, z jej rolą i bez dodatkowych uprawnień. Warto rozdzielić uprawnienia do odczytu i zapisu, wymagać zatwierdzenia dla wrażliwych działań oraz prowadzić dziennik każdego działania. Decyzje o tym, kto dostaje dostęp, powinny pozostać w rękach ludzi.

Źródła