RBAC

RBAC (role-based access control) to model kontroli dostępu, w którym uprawnienia przypisuje się rolom, a użytkownikom nadaje się role, zamiast konfigurować dostęp osobno dla każdej osoby. NIST opisuje go jako model, w którym każdy użytkownik ma jedną lub więcej ról, a każda rola jedno lub więcej uprawnień ^[1]. RBAC jest sposobem realizacji autoryzacji, czyli decyzji, co wolno zrobić tożsamości już potwierdzonej przez uwierzytelnianie. Na RBAC opiera się system ról i uprawnień WordPressa.

Jak działa

Model rozdziela dwie relacje: użytkownik–rola i rola–uprawnienie. Administrator nie zmienia listy uprawnień każdej osoby, tylko przypisuje ją do roli. Zmiana roli działa od razu na wszystkich jej członków. Norma opisuje zbiory podstawowych elementów RBAC: użytkowników, role, uprawnienia, operacje i obiekty ^[1].

Decyzja o dostępie przebiega w kilku krokach, pokazanych na schemacie poniżej.

RYS. 1Decyzja o dostępie w RBAC

W chmurze Azure przypisanie roli składa się z trzech elementów: podmiotu zabezpieczeń, definicji roli i zakresu ^[5]. Zakres zawęża działanie roli, na przykład do jednej grupy zasobów ^[5]. Microsoft zaznacza, że jego RBAC jest modelem addytywnym: efektywne uprawnienia to suma przypisań ról ^[5]. Ta sama zasada obowiązuje w wielu innych systemach. Dołożenie roli nigdy niczego nie odbiera, więc łatwo o nadmiar uprawnień.

OWASP zaleca, by uprawnienia sprawdzać przy każdym żądaniu, bez względu na to, czy pochodzi ze skryptu AJAX, z serwera czy z innego źródła ^[2]. Domyślną decyzją powinna być odmowa ^[2].

Odmiany i porównanie

Model sformalizowali w 1992 roku David Ferraiolo i Rick Kuhn z NIST ^[1]. W 2000 roku ich model połączono z ramą Sandhu i współpracowników w jednolity model NIST ^[1]. Standard ANSI/INCITS 359-2004 przyjęto 11 lutego 2004 roku, a w 2012 roku ukazała się jego zmieniona wersja INCITS 359-2012 ^[1].

RBAC nie jest jedynym modelem. OWASP porównuje go z kontrolą opartą na atrybutach i na relacjach ^[2].

OWASP wskazuje, że w dużych projektach z wieloma rolami łatwo pominąć albo źle wykonać sprawdzenie roli ^[2]. Dlatego przy tworzeniu aplikacji zaleca zwykle ABAC i ReBAC ^[2]. RBAC pozostaje jednak podstawą wielu paneli administracyjnych, także w zarządzaniu tożsamością i dostępem.

W WordPressie

WordPress stosuje RBAC w czystej postaci. Ma sześć predefiniowanych ról: superadministratora, administratora, redaktora, autora, współpracownika i subskrybenta ^[3]. Każda rola ma zestaw zadań zwanych uprawnieniami (capabilities), na przykład publish_posts, moderate_comments czy edit_users ^[3]. Subskrybent ma tylko uprawnienie read ^[3]. Dokumentacja podkreśla, że żadnej roli nie należy traktować jako starszej od innej; role określają zakres obowiązków użytkownika na stronie ^[3]. Szczegóły opisuje hasło role i uprawnienia użytkowników.

Role i uprawnienia są zapisane w tabeli opcji, pod kluczem user_roles ^[4]. Wtyczki tworzą własne role funkcją add_role() i dodają uprawnienia metodą add_cap() ^[4]. Po pierwszym wywołaniu add_role() rola trafia do bazy, a kolejne wywołania nic nie zmieniają ^[4]. Przykład roli dla osoby, która tylko wgrywa pliki i pisze szkice:

add_role( 'redakcja_mediow', 'Redakcja mediów', array(
    'read'         => true,
    'edit_posts'   => true,
    'upload_files' => true,
) );

Kod sprawdza uprawnienie, a nie nazwę roli. Służy do tego current_user_can() ^[4], opisane w haśle weryfikacja uprawnień. Domyślną rolę nowych kont ustawia się w ustawieniach ogólnych ^[3]; zob. default_role.

Zagrożenia i skutki

MITRE opisuje słabość CWE-269 jako sytuację, w której produkt niewłaściwie nadaje, zmienia, śledzi lub sprawdza uprawnienia i tworzy w ten sposób niezamierzoną sferę kontroli ^[6]. W modelu ról typowe błędy to:

• rola z uprawnieniami szerszymi niż potrzeba, na przykład redaktor z dostępem do instalacji wtyczek;
• kod wtyczki, który sprawdza tylko zalogowanie, a nie uprawnienie; to brak kontroli uprawnień (missing authorization);
• możliwość zmiany własnej roli przez formularz albo punkt końcowy API, czyli eskalacja uprawnień;
• nieusunięte konta byłych współpracowników z rolą administratora.

Każdy z tych błędów należy do kategorii Broken Access Control. Skutkiem bywa nieautoryzowane konto administratora i pełne przejęcie konta strony.

Jak się bronić

MITRE zaleca stosować zasadę najmniejszych uprawnień przy nadawaniu praw w systemie ^[6]. W praktyce oznacza to kilka reguł.

• Rolę dobierać do zadania, a nie do stanowiska. Autor tekstów nie potrzebuje roli administratora.
• Nowe role budować od najmniejszego zestawu uprawnień i dodawać tylko potrzebne.
• Okresowo przeglądać listę kont z wysokimi rolami.
• W kodzie sprawdzać konkretne uprawnienie przy każdym żądaniu ^[2].
• Konta uprzywilejowane chronić uwierzytelnianiem wieloskładnikowym.

Historia i przykłady

Według NIST jego prace nad RBAC miały oszczędzić przemysłowi 1,1 mld dolarów w ciągu kilku lat, co oszacował raport RTI International z 2010 roku ^[1]. W tym samym roku większość użytkowników w firmach zatrudniających 500 i więcej osób korzystała już z RBAC ^[1].

Przykładem z WordPressa jest podatność CVE-2023-3460 we wtyczce Ultimate Member. Singapurska agencja CSA ostrzegła 6 lipca 2023 roku, że błąd w wersjach 2.6.6 i starszych pozwala nieuwierzytelnionemu atakującemu tworzyć konta z uprawnieniami administratora ^[7]. Ocena CVSS wyniosła 9,8 na 10 ^[7]. Agencja zaleciła aktualizację, przegląd wszystkich kont administratorów i zmianę haseł ^[7].