Kontrola dostępu oparta na atrybutach (ABAC)

Kontrola dostępu oparta na atrybutach, znana jako ABAC, to model autoryzacji, w którym decyzja nie wynika wyłącznie z przypisanej roli. Reguła sprawdza zestaw cech, na przykład kto składa żądanie, do jakiego zasobu sięga, jaką akcję chce wykonać oraz w jakim kontekście. Atrybutem może być identyfikator klienta, status umowy, poufność dokumentu, właściciel projektu, kraj przetwarzania albo fakt, że akcja wymaga zatwierdzenia. Dostęp jest przyznawany dopiero, gdy warunki polityki są spełnione.

W systemie AI ABAC odpowiada na konkretne pytanie: czy ten agent, działający teraz w imieniu tej osoby, może użyć tego narzędzia na tych danych? Sama rola „administrator” lub „asystent” zwykle nie wystarcza. Agent do podsumowań spotkań może mieć poprawną rolę, ale nie powinien czytać nagrań innego klienta tylko dlatego, że oba leżą w tym samym dysku. Atrybut tenantId albo clientId w żądaniu, danych i regule pozwala wymusić zgodność tych trzech wartości przed pobraniem dokumentu.

ABAC różni się od kontroli opartej na rolach, czyli RBAC. RBAC jest prostszy: rola redaktora może edytować wpisy, a rola księgowej może odczytać faktury. Jest dobrym początkiem, gdy zespół i zasoby są małe. ABAC dodaje warunki dynamiczne. Ta sama osoba może odczytać fakturę tylko dla swojej firmy, tylko w aktywnym projekcie i tylko z urządzenia spełniającego politykę. Nie oznacza to, że trzeba zastąpić RBAC. W praktyce rola często stanowi pierwszy filtr, a atrybuty doprecyzowują decyzję.

Praktyczny przykład: ekspert ma system, który po rozmowie sprzedażowej tworzy streszczenie i szkic follow-upu. Agent dostaje identyfikator rozmowy oraz klienta. Zanim pobierze transkrypcję, warstwa autoryzacji sprawdza: czy użytkownik należy do tego klienta, czy rozmowa ma status dostępny do przetwarzania oraz czy narzędzie ma uprawnienie tylko do odczytu. Przed zapisem szkicu do CRM system sprawdza dodatkowo, czy rekord należy do tego samego klienta. Wysyłka e-maila nie przechodzi automatycznie, bo polityka wymaga atrybutu humanApproved=true.

Dobre wdrożenie zaczyna się od mapy zasobów i atrybutów, a nie od listy skomplikowanych reguł. Wypisz zasoby, na przykład pliki, kontakty, leady, transkrypcje i kampanie. Przy każdym określ właściciela, klienta, klasyfikację danych oraz dozwolone akcje. Następnie nazwij atrybuty podmiotu: użytkownik, agent, rola, organizacja. Na końcu dodaj atrybuty środowiska, takie jak czas, kanał lub poziom ryzyka. Dopiero z tej mapy buduj małe, testowalne polityki.

Najważniejsza zasada brzmi: atrybutów nie wolno brać bezkrytycznie z tekstu promptu ani z parametrów, które może zmienić przeglądarka. clientId powinien pochodzić z uwierzytelnionej sesji lub zostać porównany z własnością rekordu po stronie serwera. Podobnie agent nie może sam ustawić sobie humanApproved=true. To ma być wynik niezależnego działania użytkownika, zapisany i możliwy do audytu. ABAC działa tylko wtedy, gdy źródła atrybutów są wiarygodne, a reguła jest egzekwowana przed wywołaniem narzędzia.

Ograniczeniem ABAC jest złożoność. Gdy atrybuty są niepełne, niespójne lub mają niejasne nazwy, polityki zaczynają odmawiać dostępu przypadkowo albo otwierają zbyt szerokie wyjątki. Dlatego nie twórz jednej reguły z dwudziestoma warunkami. Wersjonuj polityki, zapisuj decyzje allow i deny z ich powodem oraz testuj przypadki graniczne: nowy klient, wygasła umowa, brak atrybutu, próba dostępu między tenantami i akcja wykonywana przez agenta. Odmowa domyślna jest bezpieczniejsza niż zgoda „na wszelki wypadek”.

Dla soloprzedsiębiorcy sensowny pierwszy krok jest skromny. Wprowadź stały identyfikator klienta do każdego źródła danych i każdej automatyzacji. Przy każdym wywołaniu narzędzia porównuj go z identyfikatorem aktywnego kontekstu. Następnie rozdziel trzy skutki: odczyt, tworzenie szkicu oraz wykonanie nieodwracalnej akcji. Odczyt i szkic mogą przejść automatycznie po spełnieniu warunków, ale wysyłka, płatność czy usunięcie powinny wymagać osobnej polityki i zatwierdzenia człowieka. To daje realną barierę przed pomyłką agenta bez budowania korporacyjnego labiryntu.