Dzisiaj nawiążemy do artykułu Kto jest kim w systemie IGA? i postaramy się przybliżyć zagadnienie analizy oraz budowy modelu ról RBAC w organizacji. Ale na początek trochę z innej perspektywy napiszemy, dlaczego jest to ważne przy wdrożeniach systemów IGA i czemu powinien być to jeden z obowiązkowych elementów każdego projektu IDM.
To, co w dużym stopniu decyduje o sukcesie wdrożenia systemu IDA w organizacji, to pozytywny odbiór systemu przez użytkowników końcowych. W zależności od etapu wdrożenia systemu i przyjętej strategii udostępniania funkcjonalności systemu w organizacji, grupa ta może być różna. o ile przyjęto, iż system zostanie w pierwszej fazie wdrożenia udostępniony wybranej grupie odbiorców (np. pracownikom działu IT), to ich doświadczenie może być zupełnie inne od tego, jakie będą mieli pracownicy reprezentujący szerszą populację. Ogólny odbiór zależy przede wszystkim od tego, z jakiej funkcjonalności systemu IDM dana grupa korzysta. o ile będą to pracownicy, którzy dosyć często mają do czynienia z wykorzystaniem narzędzi IT w organizacji, niektóre cechy funkcjonale systemu mogą oni odbierać inaczej niż odbiorcy biznesowi. Najbardziej znaczącą funkcjonalnością, która docelowo będzie miała największy wpływ na to, w jaki sposób będzie traktowany system IDM w całej organizacji, jest wnioskowanie o uprawnienia i akceptowanie wniosków o nie. Każda przeszkoda, która pojawi się w tym procesie, może spowodować duży dyskomfort w korzystaniu z systemu. Poniżej główne elementy, które powinny być dokładnie przeanalizowane:
- Opis elementów dostępnych do wnioskowania – użytkownik końcowy nie może mieć wątpliwości, o jakie uprawnienia wnioskuje. Czy jest to rola, która zapewnia dostęp do wielu aplikacji i zasobów, czy jest to pojedyncze uprawnienie, które zapewnia dostęp do jednej aplikacji czy pojedynczego zasobu – powinno to być jasne i nie może powodować błędów wynikających z nadmiarowo lub błędnie zawnioskowanych uprawnień. Jest to również bardzo istotne przy akceptowaniu wniosków, ale z punktu widzenia osoby, która odpowiada za zatwierdzanie żądań pracowników.
- Używane nazewnictwo – problem, który często możemy spotkać przy wdrożeniach w polskich firmach, gdzie przetłumaczone słowa z języka angielskiego nie zawsze dobrze pasują do kontekstu, w którym są używane w systemie IDM. Przykładem może być tutaj wyraz „request”, który używany jest do akcji związanej ze złożeniem wniosku w systemie IDM, tłumaczony jako „żądanie” jest odbierany nieprecyzyjnie przez użytkowników, którzy bardzo często zamiast tego posługują się słowem „wniosek”.
- Intuicyjność interfejsu – nie każde rozwiązanie jest w tym zakresie dopracowane, czasem większe znaczenie przykładane jest do niewidocznej dla użytkownika warstwy technicznej, niż do sposobu prezentacji danych wykorzystywanych w procesie wnioskowania, akceptowania czy okresowego przeglądu uprawnień pracowników.
Część z tych problemów można rozwiązać na etapie analizy i projektowania systemu (nazewnictwo, słowniki, opisy), ale wymaga to dużego zaangażowania po stronie organizacji. Pozostała część (interfejs aplikacji) wymaga znacznego przebudowania lub zaawansowanych zmian, co ma wpływ na koszty wdrożenia całego systemu, jak i jego późniejszego utrzymania.
Jak możemy podnieść komfort korzystania z systemu IDM?
Przede wszystkim wychodzimy z założenia, iż zarządzanie pojedynczymi uprawnieniami zawsze będzie dużym utrudnieniem w uruchomieniu systemu IDM w organizacji, która posiada wiele różnych aplikacji i systemów. To, do czego powinniśmy dążyć przy projektowaniu rozwiązania, to uproszczenie zarządzania uprawnieniami poprzez wprowadzenie katalogu ról biznesowych, czyli wdrożenie modelu RBAC (Co to jest RBAC? Porównanie RBAC z ABAC), które albo w sposób automatyczny, albo poprzez ich przypisanie na wniosek, zapewniają zgodność nadanych uprawnień z funkcją, jaką pełni pracownik w organizacji, wraz z zachowaniem zasady najmniejszych uprawnień. Budowa takiego katalogu ról daje nam następujące korzyści:
- Zamiast przypisywać uprawnienia pojedynczo, do różnych aplikacji i systemów – przypisujemy rolę do tożsamości, redukujemy w ten sposób liczbę wniosków lub reguł, które potrzebne są do nadania całego kompletu uprawnień dla tożsamości pracownika.
- Przy zmianie uprawnień dla danej roli (np. nowa aplikacja wykorzystywana na danym stanowisku albo wycofanie aplikacji z użycia), nie musimy wykonywać przeglądu pojedynczych uprawnień, wystarczy, iż właściciel roli zmieni jej definicję, co spowoduje automatyczne zmiany (lub wygenerowanie zadań) dla każdej tożsamości, która ma taką rolę przypisaną.
- Wykorzystanie ról pozwala na wprowadzanie automatyzacji – np. każdy pracownik w danej komórce organizacyjnej albo na określonym stanowisku posiada zestaw uprawnień zdefiniowany dla jego komórki lub stanowiska, nie ma potrzeby wnioskowania, nie ma potrzeby okresowego przeglądu – co ogranicza poziom interakcji z systemem IDM.
Żeby jednak osiągnąć wymienione wyżej korzyści, należy zadbać nie tylko o budowę słownika ról, ale także o zaprojektowanie i wdrożenie odpowiednich procesów w organizacji, które będą zapewniały aktualność i poprawność takiego słownika na przestrzeni czasu.
Jak podejść do analizy RBAC?
Opracowanie kompletnego i prawidłowego zestawu ról jest jednym z najważniejszych i najbardziej wymagających zadań we wdrażaniu kontroli dostępu opartej na rolach. Kluczowym problemem z tym związanym jest określenie, czy rola jest odpowiednia w kontekście powiązanych z nią uprawnień i kiedy rola jest wystarczająco dobra. Często używanym pojęciem w tym znaczeniu jest określenie „eksploracja ról” (role mining), oznaczające znalezienie optymalnego zestawu ról na podstawie istniejących uprawnień użytkownika. Cały proces budowania słownika ról jest tak naprawdę projektem, który wymaga określenia szeregu czynników. My skupimy się na wybranych aspektach tego projektu, takich jak główne kroki analizy danych. Niektóre z rozwiązań IGA posiadają funkcjonalność pozwalającą na taką eksplorację i zaproponowanie modelu, który pokazuje potencjalnych kandydatów do budowy takiego słownika. o ile nie posiadamy systemu IGA, analiza może być wykonana przez bardziej dedykowane narzędzia lub ostatecznie manualnie z wykorzystaniem takich narzędzi jak skrypt do czytania uprawnień i zapisywania wyników w arkuszach Excel. Niezależnie od wybranego narzędzia musimy mieć świadomość, iż każda taka propozycja musi być dokładnie przenalizowana, nie ma tutaj dostępnego żadnego magicznego środka, który wykona za nas pracę i zaproponuje gotowy do użycia model ról. Od strony technicznej najczęściej budowa takiego słownika wymaga podjęcia następujących kroków:
- Zaimportowanie danych organizacyjnych, takich jak tożsamości pracowników, kontraktorów oraz powiązanych struktur, czyli lista departamentów, lista stanowisk. Przy określaniu zakresu danych musimy uwzględnić wszystkie atrybuty, które w przyszłości będziemy chcieli wykorzystać do grupowania tożsamości.
- Zaimportowanie danych o kontach i uprawnieniach oraz korelacja kont z tożsamościami.
- Grupowanie tożsamości (podobni pracownicy – np. ze względu na stanowisko, departament lub inne wybrane atrybuty) oraz zaprezentowanie danych w postaci klastrów uprawnień dla poszczególnych grup tożsamości. Na tym etapie powstają prototypy ról, które następnie wymagają przeglądu i oceny pod kątem ich przydatności.
Po uzyskaniu w ten sposób danych możemy przejść do faktycznej analizy zaproponowanych ról, jest to niezbędne między innymi z następujących względów:
- Nie każda tożsamość, która została wybrana w grupowaniu posiada prawidłowo nadane uprawnienia – może to wynikać np. z faktu, iż pracownik przechodził przez różne działy w organizacji i posiada uprawnienia, których nie odebrano mu na czas.
- Nie każde uprawnienie w danej grupie jest adekwatne tylko dla wybranej grupy/roli pracowników – np. może to być uprawnienie lub uprawnienia wspólne dla całej organizacji.
- Niektóre konta mogą być kontami uprzywilejowanymi i posiadać uprawnienia, które nie są standardowo przydzielane pracownikom.
W wielu opracowaniach traktujących o budowie modelu ról RBAC (czyli naszego słownika ról) opisywane są następujące metody analizowania danych:
- Bottom-Up Ta metoda polega na analizowaniu rzeczywistego użytkowania systemu przez użytkowników. Dane dotyczące tego, jak użytkownicy korzystają z systemu, jakie zasoby są dla nich dostępne i jak są wykorzystywane, są zbierane i analizowane. Następnie na podstawie tej analizy tworzone są role, które odzwierciedlają rzeczywiste wzorce użytkowania. Jest to podejście indukcyjne, które zaczyna się od szczegółowych danych operacyjnych i zmierza do ogólnych wniosków dotyczących ról i uprawnień.
- Top-Down W przeciwieństwie do metody bottom-up, podejście top-down zaczyna się od określenia polityk i wymagań biznesowych organizacji. Na tej podstawie określa się role i uprawnienia niezbędne do realizacji tych wymagań. Dopiero po zdefiniowaniu ról przystępuje się do analizy, jak te role powinny być implementowane w systemie. Jest to podejście dedukcyjne, które zaczyna się od ogólnych zasad i kieruje się ku szczegółowym implementacjom.
- Bottom-Up Top-Down To połączone podejście łączy w sobie elementy obu metod. Rozpoczyna się od analizy bottom-up, zbierając dane operacyjne, aby zrozumieć, jak system jest aktualnie wykorzystywany. Następnie wykorzystuje podejście top-down, aby dostosować wyniki analizy do ogólnych celów i polityk biznesowych organizacji. Ta metoda pozwala na tworzenie ról, które są zarówno dostosowane do realnych potrzeb użytkowników, jak i zgodne z celami organizacji.
- Top-Down Bottom-Up Jest to inna wersja połączonego podejścia, w którym najpierw stosuje się metodę top-down, aby ustalić ogólne ramy ról i uprawnień na podstawie polityk i celów organizacji. Następnie, w fazie bottom-up, analizuje się szczegółowe dane operacyjne, aby dostosować i doprecyzować te role tak, by pasowały do rzeczywistego użytkowania systemu.
Każda z tych metod ma swoje zalety i może być stosowana w zależności od specyfiki organizacji i dostępnych danych. Wybór odpowiedniej metody zależy od wielu czynników, w tym od stopnia dojrzałości procesów biznesowych, rodzaju i struktury organizacji, a także od dostępnych zasobów i technologii, przy czym praktycznie w każdej z nich bardzo dużym ułatwieniem jest korzystanie z odpowiedniego narzędzia, które znacznie ułatwia pracę – na przykład przez odpowiednio zwizualizowane raporty i zestawienia. o ile jesteście zainteresowani, jakie narzędzia mogą Was wspomóc w analizie uprawnień pod kątem wdrożenia modelu RBAC oraz jak zaplanować cały proces, zachęcamy do kontaktu z firmą ProLimes.
