brak audytu przypisania ról

Brak audytu przypisania ról to luka uniemożliwiająca weryfikację, kto i kiedy nadał określone uprawnienia w systemie.

Na czym polega brak audytu przypisania ról

Brak audytu przypisania ról oznacza, że system nie zapisuje w sposób wystarczający informacji o zmianach uprawnień. Sama obecność listy ról nie pozwala wtedy ustalić, kto nadał użytkownikowi określone uprawnienie, kiedy wykonano zmianę, z jakiego konta operacyjnego skorzystano ani czy działanie wynikało z zatwierdzonego procesu. Problem dotyczy nie tylko całkowitego braku logów. Audyt może być również niepełny, gdy rejestrowane jest wyłącznie utworzenie konta, ale nie późniejsze dodanie roli, odebranie roli albo modyfikacja zakresu dostępu.

Przypisanie roli jest operacją zmieniającą model autoryzacji. Rola może grupować uprawnienia do odczytu, zapisu, zatwierdzania, konfiguracji lub zarządzania innymi kontami. Jeżeli zmiana nie pozostawia jednoznacznego śladu, późniejsza analiza incydentu musi opierać się na danych pośrednich: aktualnym stanie systemu, historii zgłoszeń, logach logowania albo ręcznych ustaleniach administratorów. Takie źródła nie zawsze pozwalają odtworzyć pełną kolejność zdarzeń, dlatego nie można wiarygodnie rozdzielić zmiany planowej od przypadkowej lub nieautoryzowanej.

Jakie informacje powinno zawierać zdarzenie zmiany roli

Użyteczny zapis audytowy powinien identyfikować podmiot wykonujący operację, konto lub grupę, której dotyczy zmiana, nazwę przypisywanej albo odbieranej roli oraz rodzaj działania. Istotny jest również czas zdarzenia zapisany w jednoznacznej strefie czasowej, identyfikator sesji lub żądania, źródło operacji oraz wynik wykonania. Informacja „zmieniono uprawnienia” jest zbyt ogólna, jeżeli nie wiadomo, czy chodziło o nadanie roli, jej odebranie, zastąpienie jednej roli inną czy zmianę członkostwa grupy dziedziczącej uprawnienia.

W systemach, w których role mogą być przypisywane bezpośrednio lub pośrednio, audyt powinien umożliwiać rozróżnienie tych przypadków. Użytkownik może otrzymać dostęp przez bezpośrednie przypisanie roli, członkostwo w grupie, mapowanie atrybutu tożsamości albo regułę wynikającą z organizacji zasobów. Brak takiego rozróżnienia utrudnia ocenę rzeczywistej przyczyny dostępu. Warto także zachować identyfikator poprzedniego i nowego stanu, ponieważ sam fakt wykonania operacji nie pokazuje, jakie uprawnienia obowiązywały przed zmianą i jaki zakres obowiązuje po niej.

Skutki operacyjne i sposób wykrywania luki

Brak audytu przypisania ról utrudnia przeglądy uprawnień, analizę błędów autoryzacji oraz wyjaśnianie nieoczekiwanego dostępu do funkcji lub zasobów. Gdy użytkownik uzyskuje możliwość wykonania operacji, której wcześniej nie mógł wykonać, bez historii zmian nie da się szybko ustalić, czy przyczyną była ręczna modyfikacja, synchronizacja katalogu, zmiana konfiguracji czy dziedziczenie z grupy. W efekcie reakcja może ograniczyć się do odebrania bieżącego dostępu, bez usunięcia mechanizmu, który spowodował problem.

Lukę można rozpoznać podczas przeglądu konfiguracji systemu, testu ścieżek administracyjnych oraz porównania historii zmian z aktualnym stanem przypisań. Należy sprawdzić, czy operacje nadawania i odbierania ról generują zdarzenia, czy wpisy są dostępne dla osób analizujących incydenty oraz czy logi obejmują także zmiany wykonywane przez interfejs administracyjny, API i automatyczne procesy synchronizacji. Weryfikacja powinna uwzględniać również nieudane próby zmiany uprawnień. Ich brak może oznaczać, że system zapisuje tylko pomyślne operacje, przez co nie pokazuje prób manipulowania mechanizmem kontroli dostępu.

Przywrócenie kontroli nad historią uprawnień

Usunięcie problemu wymaga włączenia rejestrowania zmian ról na poziomie wszystkich dostępnych kanałów administracyjnych oraz ustalenia jednolitego formatu zdarzeń. Log powinien pozwalać odtworzyć aktora, obiekt zmiany, poprzedni i nowy stan, czas, źródło oraz rezultat operacji. Zapisów nie należy traktować jako jedynej kontroli. Przydatne jest także okresowe porównywanie aktualnych przypisań z zatwierdzonym wykazem, ponieważ audyt pokazuje historię, natomiast rekonsyliacja wskazuje bieżące odstępstwa.

Podczas diagnostyki należy sprawdzić, czy historia nie jest nadpisywana przy rotacji logów, czy zegary urządzeń i usług są wzajemnie zgodne oraz czy osoby wykonujące zmiany nie mogą swobodnie usuwać własnych śladów. Należy przetestować nadanie, odebranie i zmianę roli, a następnie potwierdzić, że każde zdarzenie zawiera wystarczające dane do odtworzenia przebiegu operacji. W przypadku laptopa lub komputera używanego do administracji problem może wynikać również z błędnej konfiguracji klienta, narzędzia zarządzającego albo lokalnego przechowywania logów, dlatego analiza powinna objąć zarówno aplikację, jak i środowisko, z którego wykonywane są zmiany.