Modyfikacja roli

Modyfikacja roli to zmiana jej składu lub uprawnień, wpływająca na wszystkich przypisanych do niej użytkowników.

Zakres i skutek modyfikacji roli

Modyfikacja roli oznacza zmianę zestawu uprawnień przypisanego do nazwanej roli albo zmianę jej członkostwa. Rola jest pośrednim poziomem kontroli dostępu: użytkownik otrzymuje uprawnienia nie bezpośrednio, lecz przez przypisanie do jednej lub kilku ról. Zmiana definicji roli może więc wpłynąć na wiele kont jednocześnie. Jeżeli do roli zostanie dodane uprawnienie odczytu, wszyscy jej członkowie mogą uzyskać dostęp do objętych nim zasobów. Odebranie uprawnienia działa odwrotnie, o ile użytkownik nie otrzymuje tego samego dostępu z innej roli lub z nadania indywidualnego.

Zakres modyfikacji może obejmować uprawnienia do odczytu, tworzenia, zmiany i usuwania danych, uruchamiania określonych operacji, korzystania z aplikacji albo zarządzania konfiguracją. W systemach stosujących model RBAC, czyli kontrolę dostępu opartą na rolach, istotne jest rozróżnienie między rolą a kontem użytkownika. Rola opisuje funkcję lub zakres obowiązków, natomiast konto określa konkretną tożsamość, która może tę rolę otrzymać. Dzięki temu jedna zmiana może być zastosowana spójnie do większej grupy użytkowników.

Dodawanie, odbieranie i dziedziczenie uprawnień

Najczęstszą formą modyfikacji roli jest dodanie albo odebranie pojedynczego uprawnienia. Uprawnienie może dotyczyć konkretnego obiektu, takiego jak plik, katalog, tabela, rekord, funkcja programu lub zasób sieciowy, albo większego obszaru systemu. Przy analizie skutku trzeba sprawdzić, czy zmieniana rola ma uprawnienia bezpośrednie, dziedziczy je z innej roli nadrzędnej albo przekazuje je roli podrzędnej. W modelu hierarchicznym rola niższego poziomu może przejmować uprawnienia roli wyższego poziomu, dlatego edycja jednego elementu hierarchii może rozszerzyć dostęp poza bezpośrednich członków modyfikowanej roli.

Ważnym przypadkiem jest odebranie dostępu, które nie zawsze daje oczekiwany rezultat. Użytkownik może nadal mieć uprawnienie nadane indywidualnie, odziedziczone z drugiej roli albo wynikające z reguły dotyczącej grupy. Należy również uwzględnić uprawnienia warunkowe, ograniczenia związane z zakresem zasobu oraz reguły rozstrzygania konfliktu między zezwoleniem a odmową. Sama obecność roli na liście przypisań nie wystarcza do ustalenia rzeczywistego dostępu. Konieczne jest prześledzenie całej ścieżki uprawnień prowadzącej od konta do chronionego zasobu.

Bezpieczna procedura zmiany roli

Przed modyfikacją warto zapisać aktualny skład roli, listę jej uprawnień oraz zależności z innymi rolami. Taki stan wyjściowy ułatwia porównanie zmian i pozwala odtworzyć wcześniejszą konfigurację, jeżeli nowa reguła spowoduje niepożądany skutek. Zmiana powinna obejmować tylko niezbędny zakres. Dodawanie szerokiego uprawnienia administracyjnego w celu rozwiązania pojedynczego problemu zwiększa ryzyko nadmiernego dostępu i utrudnia późniejszą kontrolę konfiguracji.

Po zapisaniu modyfikacji należy sprawdzić działanie zarówno dla użytkownika, który powinien uzyskać dostęp, jak i dla użytkownika, który powinien go utracić. Test powinien obejmować operację dozwoloną, operację niedozwoloną oraz próbę dostępu do zasobu znajdującego się poza zakresem roli. W systemach wykorzystujących pamięć podręczną uprawnień, tokeny sesyjne lub okresowe odświeżanie członkostwa rezultat może nie być widoczny natychmiast. Należy wtedy uwzględnić ponowne uwierzytelnienie, odświeżenie sesji albo ponowne pobranie informacji o uprawnieniach.

W środowisku użytkowym każda zmiana powinna mieć opis, wskazanie osoby wykonującej operację, zakres modyfikacji i uzasadnienie. Przydatne jest także sprawdzenie logów audytowych przed i po zmianie. Pozwala to ustalić, czy modyfikacja została przyjęta, kiedy zaczęła obowiązywać i czy nie wywołała serii błędów autoryzacji. Jeżeli rola jest wykorzystywana przez aplikację, trzeba zweryfikować również zadania automatyczne, integracje i procesy uruchamiane bez udziału człowieka.

Rozpoznawanie problemów po zmianie konfiguracji

Nieprawidłowa modyfikacja roli może objawiać się komunikatem o braku autoryzacji, zniknięciem funkcji z interfejsu, odmową zapisu danych albo błędem występującym tylko dla części kont. Odmienny objaw może wskazywać na nadmiarowe uprawnienia: użytkownik widzi zasoby, których nie powinien widzieć, może wykonać operację przeznaczoną dla administratora albo uzyskuje dostęp pośredni przez funkcję aplikacji. Sama treść komunikatu nie zawsze pokazuje źródło problemu, ponieważ aplikacja może ukrywać szczegóły decyzji mechanizmu kontroli dostępu.

Diagnostyka powinna rozpocząć się od ustalenia konkretnego konta, zasobu i operacji, która zakończyła się powodzeniem albo błędem. Następnie należy porównać efektywne uprawnienia tego konta z uprawnieniami konta testowego o znanym zakresie dostępu. Trzeba sprawdzić członkostwo w rolach, hierarchię ról, reguły dziedziczenia, indywidualne wyjątki oraz stan sesji. Jeżeli problem pojawił się po zmianie, pomocne jest tymczasowe odtworzenie poprzedniej konfiguracji i ponowienie tego samego testu. Takie porównanie pozwala odróżnić błąd modyfikacji roli od problemu z aplikacją, synchronizacją konta lub dostępnością zasobu.

W przypadku awarii związanej z konfiguracją uprawnień diagnostyka i naprawa powinny obejmować zarówno system, w którym zdefiniowano rolę, jak i komputer używany do zarządzania tym systemem. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC oraz ich podzespołów, gdy przyczyną problemu są usterki sprzętowe lub nieprawidłowe działanie oprogramowania na urządzeniu roboczym.