RBAC – role-based access control
RBAC (role-based access control, kontrola dostępu oparta na rolach) to model nadawania uprawnień, w którym prawa do systemów i danych przypisuje się rolom, np. „księgowa” albo „akceptujący faktury”, a użytkownikom - role. Zmiana stanowiska oznacza zmianę roli, a nie ręczne przestawianie kilkunastu pojedynczych uprawnień.
Jak działa RBAC - użytkownik, rola, uprawnienie
Model ma trzy warstwy. Uprawnienie to zgoda na konkretną operację na konkretnym obiekcie: odczyt faktury, akceptację wniosku, eksport rejestru umów. Rola to nazwany zestaw uprawnień odpowiadający funkcji w firmie. Użytkownik dostaje jedną lub kilka ról i tylko przez nie ma dostęp do czegokolwiek. Ta ostatnia zasada odróżnia RBAC od zwykłych grup: grupa to zbiór ludzi, rola to zbiór uprawnień, a w czystym RBAC nie ma uprawnień przypisanych osobie z pominięciem roli. Model sformalizowali w 1992 r. badacze amerykańskiego instytutu NIST, a jego ujednolicona wersja stała się podstawą normy ANSI INCITS 359, zaktualizowanej w 2012 r. Dziś RBAC stosuje się powszechnie - od chmury Microsoft Azure po systemy kadrowe i obiegu dokumentów.
Hierarchia ról i rozdział obowiązków w RBAC
Trzy mechanizmy odróżniają dojrzały RBAC od listy ról w arkuszu.
- Hierarchia ról - rola nadrzędna dziedziczy uprawnienia podrzędnej. Główna księgowa ma wszystko, co księgowa, plus zamknięcie miesiąca, więc nie trzeba powtarzać uprawnień w dwóch miejscach.
- Statyczny rozdział obowiązków - pary ról, których jedna osoba nie może mieć jednocześnie, np. „zmiana rachunków kontrahentów” i „zatwierdzanie przelewów”. System odrzuca takie przypisanie.
- Dynamiczny rozdział obowiązków - osoba może mieć obie role, ale nie może ich używać jednocześnie, w jednej sesji pracy. W obiegu dokumentów tę samą zasadę stosuje się do sprawy: kto złożył wniosek zakupowy, nie zaakceptuje go, nawet jeśli w innych sprawach jest akceptującym.
RBAC a ABAC i uprawnienia imienne
RBAC zakłada, że dostęp wynika z funkcji. Gdy decyzja zależy od cech dokumentu lub sytuacji - kwoty, klauzuli poufności, działu - same role prowadzą do ich mnożenia: osobna rola dla każdej kombinacji spółki, działu i progu kwotowego. Tę pułapkę nazywa się eksplozją ról. Częstym rozwiązaniem jest rola z zakresem. W Azure RBAC przypisanie składa się z trzech elementów: kto, jaka rola i w jakim zakresie, np. w której grupie zasobów. W obiegu dokumentów zakresem bywa dział, MPK albo spółka. Model ABAC idzie dalej i opiera całą decyzję na atrybutach. W praktyce role dają podstawowy zakres, a atrybuty go zawężają. Przeciwieństwem RBAC są uprawnienia imienne, nadawane każdej osobie osobno - tak działają np. uprawnienia w KSeF do wystawiania i przeglądania faktur.
RBAC w obiegu dokumentów e-MSI
Na platformie JobRouter®, na której e-MSI wdraża procesy, każdy proces ma określone role, a system zarządzania uprawnieniami i rolami kontroluje dostęp do dokumentów. Po zalogowaniu użytkownik widzi tylko te procesy i dane, do których uprawniają go przypisane role. Rola decyduje też o przydziale pracy: dokument może automatycznie trafić do zadania dla wybranej roli lub użytkownika, a moduł JobSub pozwala definiować zastępstwa dla poszczególnych ról. W e-Teczce dostęp do dokumentów pracowniczych opiera się na rolach, grupach i poziomach uprawnień, a każdy dostęp, edycja lub pobranie pliku jest rejestrowane. Więcej na stronie bezpieczeństwo systemów i w artykule uprawnienia w systemie obiegu dokumentów.
Najczęstsze błędy przy projektowaniu ról
- Rola na jedną osobę, np. „uprawnienia Anny” - to uprawnienia imienne pod inną nazwą.
- Role zbudowane przez skopiowanie obecnych uprawnień, razem z nadmiarami narosłymi przez lata, zamiast z opisu stanowisk i procesów.
- Uprawnienia dopisywane użytkownikom obok ról - przy przeglądzie nikt nie wie, skąd się wzięły.
- Brak właściciela roli po stronie biznesu. IT technicznie ją utrzymuje, ale nie wie, co rola powinna móc.
- Brak listy ról, których nie wolno łączyć - rozdział obowiązków istnieje tylko w regulaminie.
- Eksplozja ról zamiast ról z zakresem - po roku ról jest więcej niż pracowników.
Przykłady zastosowania
Nowa księgowa dostaje rolę „Księgowość - faktury kosztowe” i od pierwszego dnia widzi rejestr faktur, dekretację i raporty, bez osobnego wniosku o każde uprawnienie.
Kierownik marketingu ma rolę „Akceptujący” z zakresem ograniczonym do swojego MPK. Akceptuje faktury swojego działu, a faktur działu produkcji w ogóle nie widzi.
Pracownik działu zakupów zmienia w kartotece numer rachunku dostawcy. System nie pozwala nadać mu roli „Zatwierdzanie przelewów”, bo obie role są na liście ról, których nie wolno łączyć.
W urzędzie sekretariat pełni rolę „Kancelaria” - rejestruje i dekretuje pisma, a referenci w roli „Prowadzący sprawę” widzą tylko sprawy przydzielone ich komórce.
Firma prowadzi tabelę, która rola w obiegu faktur odpowiada któremu uprawnieniu w KSeF, bo tam uprawnienia do wystawiania i przeglądania faktur nadaje się imiennie. Przy zmianie stanowiska dział IT zmienia rolę, a osoba zarządzająca uprawnieniami w KSeF - uprawnienie w KSeF.
Najczęstsze pytania
Czym jest RBAC?
RBAC, czyli kontrola dostępu oparta na rolach, to sposób zarządzania uprawnieniami, w którym dostęp do systemów i dokumentów wynika z roli pełnionej w firmie. Administrator definiuje role, np. księgowa, kierownik, kadry, przypisuje im uprawnienia, a pracownikom nadaje role. Nikt nie dostaje uprawnień z pominięciem roli.
Czym różni się rola od grupy?
Grupa to zbiór ludzi, na przykład wszyscy pracownicy działu finansów. Rola to zbiór uprawnień, na przykład odczyt i akceptacja faktur kosztowych. W praktyce grupy z katalogu, takiego jak Active Directory, często mapuje się na role w systemie, ale to rola określa, co wolno zrobić.
RBAC czy ABAC - który model wybrać?
RBAC jest prostszy w utrzymaniu i przeglądzie, dlatego sprawdza się jako podstawa. ABAC decyduje na podstawie atrybutów osoby, dokumentu i sytuacji, np. kwoty lub klauzuli poufności, i jest bardziej elastyczny, ale trudniejszy do audytu. W praktyce często łączy się oba: rola daje zakres, a atrybuty go zawężają.
Co to jest Azure RBAC?
To system autoryzacji w chmurze Microsoft Azure oparty na rolach. Przypisanie roli składa się z trzech elementów: podmiotu, czyli użytkownika, grupy lub aplikacji, definicji roli z listą dozwolonych akcji oraz zakresu, np. subskrypcji lub grupy zasobów. Uprawnienia z kilku przypisań sumują się.
Na czym polega rozdział obowiązków w RBAC?
Na regułach, które nie pozwalają jednej osobie przejść całej ryzykownej operacji samodzielnie. W wersji statycznej system blokuje nadanie dwóch sprzecznych ról, np. zmiany rachunku kontrahenta i zatwierdzania przelewów. W wersji dynamicznej osoba ma obie role, ale nie może ich użyć jednocześnie, np. w tej samej sesji albo sprawie.
Jak zaprojektować role w firmie?
Zacząć od procesów i stanowisk, a nie od obecnych uprawnień. Dla każdej funkcji spisać, co musi czytać, zmieniać i zatwierdzać, nadać roli właściciela w biznesie i określić role, których nie wolno łączyć. Zakres, np. dział lub MPK, lepiej dodać do roli niż tworzyć osobną rolę dla każdego działu.
Powiązane hasła
Zobacz, jak wygląda to w systemach, które wdrażamy w polskich firmach.
