brak wersjonowania ról użytkowników

Brak wersjonowania ról użytkowników to usterka uniemożliwiająca prześledzenie historii zmian w strukturze uprawnień.

Na czym polega brak wersjonowania ról użytkowników

Brak wersjonowania ról użytkowników oznacza, że system przechowuje wyłącznie bieżący stan definicji ról albo zapisuje zmiany w sposób niewystarczający do odtworzenia wcześniejszych konfiguracji. Rola użytkownika jest zwykle zestawem uprawnień przypisanych do określonych operacji, zasobów lub funkcji aplikacji. Jeżeli po zmianie nie pozostaje poprzednia wersja, nie można jednoznacznie ustalić, jakie uprawnienia obowiązywały przed modyfikacją.

Usterka nie musi polegać na całkowitym braku logów. Dziennik może odnotowywać fakt wykonania operacji, na przykład zmianę roli, ale bez zapisania wartości przed zmianą i po zmianie. W takiej sytuacji widoczna jest informacja, że ktoś zmodyfikował konfigurację, lecz nie da się sprawdzić, czy dodano uprawnienie do odczytu, usunięto możliwość zatwierdzania operacji, czy zmieniono zakres dostępu do konkretnego zasobu. Wersjonowanie wymaga co najmniej rozróżnienia kolejnych stanów, czasu ich obowiązywania oraz informacji o operacji, która doprowadziła do zmiany.

Dlaczego historia ról wpływa na ocenę uprawnień

Role są elementem modelu kontroli dostępu opartego na rolach, określanego jako RBAC. Uprawnienia wynikające z roli mogą wpływać na to, jakie dane użytkownik widzi, jakie czynności może wykonać i które operacje wymagają dodatkowego zatwierdzenia. Gdy system zna tylko aktualną definicję roli, bieżące uprawnienia można obliczyć, ale nie można wiarygodnie odtworzyć stanu z wcześniejszego momentu.

Brak historii utrudnia analizę zdarzeń, w których znaczenie ma dokładny czas. Przykładowo, jeżeli użytkownik wykonał operację w poniedziałek, a jego rola została zmieniona we wtorek, sama aktualna konfiguracja nie wyjaśnia, czy poniedziałkowa operacja była dozwolona. Potrzebne jest ustalenie, jaka wersja roli obowiązywała w chwili wykonania działania. Bez tego analiza opiera się na domysłach albo na dodatkowych kopiach konfiguracji tworzonych poza aplikacją.

Wersjonowanie pomaga także rozróżnić zmianę definicji roli od zmiany przypisania roli użytkownikowi. Są to dwa różne zdarzenia. W pierwszym przypadku modyfikowany jest zestaw uprawnień wspólny dla wielu osób, a w drugim zmienia się lista ról przypisana do konkretnego konta. System pozbawiony odpowiedniej historii może mieszać te zdarzenia, przez co trudniej ustalić rzeczywistą przyczynę zmiany efektywnego dostępu.

Objawy i sprawdzanie przepływu zmian

Typowym objawem problemu jest możliwość edycji roli bez numeru wersji, identyfikatora rewizji albo informacji o poprzednim stanie. Innym sygnałem jest nadpisywanie jednego rekordu przy każdej zmianie. W bazie lub interfejsie administracyjnym pozostaje wtedy tylko ostatnia konfiguracja, a wcześniejsze wartości znikają. Nieprawidłowość może ujawnić się również wtedy, gdy dziennik zdarzeń zawiera nazwę zmodyfikowanej roli, lecz nie pokazuje zmienionych uprawnień, autora operacji ani momentu rozpoczęcia obowiązywania nowej wersji.

Sprawdzenie powinno objąć pełny przepływ: utworzenie roli, dodanie uprawnienia, usunięcie uprawnienia, zapis zmian, przypisanie roli użytkownikowi oraz wyliczenie jego efektywnego dostępu. Należy zweryfikować, czy każda modyfikacja tworzy odrębną wersję, czy poprzednia wersja pozostaje dostępna tylko do odczytu i czy użytkownik przypisany do roli otrzymuje zmienione uprawnienia zgodnie z przewidzianym momentem aktywacji. Ważne jest też sprawdzenie, czy równoczesne edycje nie powodują utraty jednej ze zmian.

W praktyce warto porównać co najmniej dwa kolejne stany tej samej roli oraz sprawdzić, czy można wskazać różnicę między nimi. Przydatne informacje obejmują identyfikator wersji, czas utworzenia, autora zmiany, przyczynę operacji, zakres zmodyfikowanych uprawnień i ewentualny status wersji, taki jak robocza, aktywna lub wycofana. Sam znacznik czasu nie rozwiązuje problemu, jeśli nie wiadomo, do którego stanu odnosi się zapis lub gdy zegary komponentów systemu nie są ze sobą zgodne.

Naprawa mechanizmu historii i kontrola po zmianie

Usunięcie usterki wymaga rozdzielenia bieżącej konfiguracji od historii zmian. Kolejna modyfikacja roli powinna tworzyć nową rewizję zamiast niszczyć poprzednią. Każda wersja powinna mieć jednoznaczny identyfikator, określony czas utworzenia oraz zapis pełnego zestawu uprawnień albo kompletną, możliwą do odtworzenia sekwencję zmian. W rozwiązaniach, w których znaczenie ma czas obowiązywania, należy dodatkowo rozróżnić moment utworzenia wersji od momentu jej aktywacji.

Po wdrożeniu poprawki trzeba sprawdzić odczyt historii, porównywanie wersji, wycofanie błędnej zmiany oraz zachowanie przypisań użytkowników. Test powinien potwierdzić, że przywrócenie wcześniejszej wersji tworzy kolejną zmianę w historii, a nie usuwa śladów wcześniejszych operacji. Należy również zweryfikować przypadki równoczesnej edycji, nieudanego zapisu i częściowej awarii. Jeżeli po błędzie użytkownik otrzymuje uprawnienia inne niż wynikające z aktywnej wersji roli, problem dotyczy już nie tylko historii, lecz także przepływu danych między modułem administracyjnym, przechowywaniem konfiguracji i mechanizmem sprawdzającym dostęp.

W przypadku diagnozowania takiej usterki na komputerze używanym do pracy należy zabezpieczyć kopię aktualnej konfiguracji i logów przed rozpoczęciem zmian oraz odnotować moment wykonania każdego testu. Pozwala to odróżnić stan zastany od efektu późniejszej modyfikacji. Diagnostyka laptopa lub komputera PC może obejmować sprawdzenie działania aplikacji administracyjnej, dostępu do zapisanych logów, poprawności komunikacji z lokalnymi komponentami oraz integralności plików konfiguracyjnych, bez zakładania, że sama awaria sprzętu jest przyczyną braku historii ról.