Kontrola dostępu oparta na rolach (RBAC)

Kontrola dostępu oparta na rolach, po angielsku Role-Based Access Control lub RBAC, to model autoryzacji. Nie przyznajesz uprawnień osobno każdemu kontu, tylko definiujesz role, a następnie przypisujesz im dozwolone działania. Konto użytkownika, konto techniczne automatyzacji albo agent AI dostaje jedną lub kilka ról. Rola może na przykład pozwalać odczytać plik, dodać rekord do CRM lub zatwierdzić płatność, ale nie musi dawać dostępu do wszystkiego naraz.

W praktyce RBAC rozdziela trzy rzeczy: tożsamość, rolę i uprawnienie. Tożsamość odpowiada na pytanie, kto lub co wykonuje akcję. Rola opisuje funkcję w procesie, na przykład redaktor, kwalifikator leadów lub administrator. Uprawnienie określa konkretną operację i zasób, na przykład odczyt tabeli klientów albo utworzenie szkicu wiadomości. NIST wskazuje, że ten model ogranicza koszt i podatność na błędy administracji, bo reguły są związane z funkcją, a nie ręcznie powielane dla każdej osoby.

Dla eksperta budującego własny system AI RBAC jest ważny wtedy, gdy agent przestaje być zwykłym czatem i łączy się z narzędziami. Agent do researchu może potrzebować dostępu tylko do odczytu do folderu z materiałami. Automatyzacja formularza może dodać lead do CRM, ale nie powinna kasować kontaktów ani wysyłać wiadomości bez akceptacji. Osobne role zmniejszają skutki błędu w prompcie, błędnej konfiguracji webhooka lub przejętego tokenu.

Praktyczny przykład: tworzysz system, który po zapisie na newsletter streszcza odpowiedzi z formularza i zapisuje tag w CRM. Nadaj mu rolę „kwalifikacja leada” z trzema uprawnieniami: odczyt danych z tego formularza, utworzenie lub aktualizacja kontaktu oraz utworzenie notatki. Nie dawaj tej roli prawa do eksportu całej bazy, usuwania rekordów ani wysyłania kampanii. Przed uruchomieniem sprawdź na koncie testowym, czy każda dozwolona akcja przechodzi, a każda niedozwolona jest odrzucana.

RBAC dobrze działa przy stałych, czytelnych obowiązkach. Gdy decyzja zależy od kontekstu, na przykład od klienta, regionu, etapu zgody lub własności konkretnego rekordu, same role mogą być za mało precyzyjne. Wtedy potrzebujesz dodatkowych reguł opartych na atrybutach lub relacjach. OWASP zaleca podejście „odmów domyślnie”, sprawdzanie uprawnień przy każdym żądaniu i nadawanie wyłącznie minimalnego zakresu potrzebnego do wykonania zadania.

Nie myl RBAC z uwierzytelnianiem ani OAuth 2.0. Uwierzytelnianie potwierdza, kim jest użytkownik lub usługa. OAuth 2.0 może przekazać aplikacji ograniczony token dostępu bez udostępniania hasła. RBAC odpowiada dopiero na pytanie, co dana tożsamość może zrobić po uzyskaniu dostępu. Bez regularnego przeglądu ról, krótkiego życia tokenów, logów i kontroli człowieka RBAC nie naprawi zbyt szerokich integracji.

Najprostszy start to mapa ról i akcji w jednym dokumencie. Wypisz każdy workflow, dane, które czyta, akcje, które wykonuje, oraz osobę zatwierdzającą zmianę zakresu. Zacznij od dostępu tylko do odczytu. Zapis i wysyłkę dodawaj pojedynczo, po teście. Połącz tę praktykę z OAuth 2.0 dla integracji oraz z barierami ochronnymi AI, aby agent nie mógł wykonać kosztownej lub nieodwracalnej akcji tylko dlatego, że pojawiła się w treści dokumentu albo promptu.