Kto jest kim w systemie IGA?

Obecnie praktycznie każda mniejsza lub większa organizacja po osiągnięciu pewnej skali musi wprowadzić rozwiązania, które pozwolą jej uruchomić lub usprawnić procesy związane z zarządzaniem uprawnieniami. Jest to wprost wymuszone przez zjawiska transformacji cyfrowej i coraz większe wykorzystanie systemów informatycznych do realizacji procesów firmy. W dzisiejszych czasach ludzie pracują z informacjami przetwarzanymi w systemach informatycznych i udostępnianych przez różne usługi cyfrowe. Przy takim trybie pracy nie można ignorować braku fizycznej kontroli dostępu do danych i zasobów: wdrażanie kontroli dostępu jest ważniejsze niż kiedykolwiek, zwłaszcza że miejsce pracy nie musi już być fizyczną lokalizacją, ponieważ biura zamieniły się w globalne, wirtualne miejsca pracy, w których przetwarzanie zadań opiera się na chmurze. Patrząc na te zmiany, trzeba podkreślić fakt, że mechanizmy kontroli muszą ulec zmianie. Obecnie zmiany te są realizowane za pomocą systemów zarządzania tożsamością i dostępem.

W systemach tych nadzór nad tym, kto, dlaczego, w jakim zakresie i do czego powinien mieć dostęp, przekazana jest w ręce przedstawicieli różnych zaineresowanych stron (stakeholders jest świetnym angielskim słowem, które ogólnie nazywa te zainteresowane strony – my w dalszej części artykułu będziemy używać słowa właściciel). Niestety jest tak wielu interesariuszy, każdy z własnymi zadaniami, odpowiedzialnościami i upoważnieniami, że pojawia się pytanie: kto może podjąć decyzję o kontroli dostępu? Kto może przyznać autoryzację lub przydzielić rolę z uprawnieniami innej osobie? I byłoby świetnie, gdyby odpowiedź na pytanie, dlaczego jakieś uprawnienia mają być nadane lub zostały nadane dla konkretnego pracownika, była łatwa i intuicyjna dla osoby, która odpowiada za proces nadania lub ich przeglądu. I byłoby świetnie, gdyby każda taka osoba odpowiedzialna za te zadania znała swoje miejsce i rolę w takich procesach. Zapytajcie kogoś, kto potencjalnie jest właścicielem jakiegoś zasobu, co myśli o tym, że ciąży na nim pewna odpowiedzialność i czy chętnie się na nią zgadza?

Jakie typy interesariuszy możemy zdefiniować w kontekście systemu IGA?

Różne grupy interesariuszy odpowiedzialne za procesy zatwierdzania uprawnień oraz rozliczane z akcji podejmowanych w tych procesach mogą być zdefiniowane w każdym przedsiębiorstwie. Bardzo ciekawą charakterystykę możemy znaleźć w opracowaniu Identifying the stakeholders in Access Governance, gdzie wymieniono  następujące kategorie (nie zawsze występują w komplecie w różnych organizacjach):

• Line Manager – czyli po prostu bezpośredni przełożony pracownika. W dużym uproszczeniu, to on odpowiada za przypisanie określonych obowiązków do poszczególnych pracowników, decydując o tym, kto i co powinien robić na określonym stanowisku. Natomiast trzeba podkreślić, że jego decyzje powinny być zgodne z wymaganiami właściciela procesu biznesowego, który oczekuje odpowiednich kwalifikacji od osób realizujących powierzone im czynności. Specyficznym przykładem są kontraktorzy czy inni pracownicy zewnętrzni, którzy nie mają określonego bezpośredniego przełożonego na podstawie struktury biznesowej organizacji. Dla takich tożsamości osobą rozliczaną z przydzielanych im dostępów będzie wyznaczony opiekun umowy, a osobą odpowiedzialną za przydzielenie uprawnień właściciel danego systemu informatycznego.
• Właściciel procesu – właściciele procesu biznesowego (Process Owners) nie biorą zwykle udziału w zadaniach związanych z przydzieleniem uprawnień, ale są odpowiedzialni za zdefiniowanie samego procesu, jego kroków, danych wejściowych i wyjściowych oraz kryteriów jakościowych i reguł stosowania procesu w organizacji. Do ich zadań należy określenie zakresu kompetencji pracowników do realizacji poszczególnych kroków procesu oraz przekazanie tej informacji do bezpośrednich przełożonych pracowników w celu zapewnienia prawidłowego i świadomego przyporządkowania osób do poszczególnych zadań w procesie. Właściciel biznesowy procesu odpowiada również za zdefiniowanie matrycy rozdzielenia obowiązków (reguły SOD – Segregation of Duties), czyli określa, jakie czynności mogą być wykonywane, a jakie nie mogą, w połączniu z określonym zestawem uprawnień pracownika. Trzeba dodać, że sam proces biznesowy może wymagać korzystania z więcej niż jednego systemu, aplikacji oraz może być wykorzystywany przez różne działy, jednostki organizacyjne w przedsiębiorstwie. Jakość i efektywność procesu biznesowego to główne czynniki decyzyjne dla właściciela procesu biznesowego.
• Właściciel systemu – często zwany jego administratorem, to rola, która związana jest z odpowiedzialnością za wdrożenie systemu, jego prawidłowe działanie, oraz zapewnienie dostępności serwisów wymaganych do prawidłowego funkcjonowania systemu. To właściciel systemu steruje cyklem życia systemu dbając o jego aktualność i zarządzając jego zmianami, ponadto utrzymuje on jego budżet i zapewnia ciągłość działania. W procesach zarządzania uprawnieniami właściciel systemu zapewnia prawidłową implementację modelu uprawnień, która umożliwia realizację wymagań związanych z zarządzaniem uprawnieniami i rolami w organizacji, oraz monitoruje prawidłowość przypisanych uprawnień i wykorzystanie licencji. Podobnie jak w przypadku właściciela procesu, jeden system może być wykorzystywany przez różne procesy w obrębie różnych jednostek organizacyjnych. Przy podejmowaniu decyzji związanych z samym systemem głównym czynnikiem uwzględnianym przez właściciela systemu są koszty.
• Właściciel danych – jest odpowiedzialny „tylko” za zapewnienie odpowiedniego dostępu do repozytorium, zasobu, w którym przechowywane są dane, za które odpowiada. Jego rolą jest nadzorowanie prawidłowej realizacji reguł dostępu do danych, zgodnych zarówno ,z regulacjami zewnętrznymi (np. GDPR), jak i wewnętrznymi (polityka bezpieczeństwa firmy), oraz monitorowanie przepływu danych pomiędzy systemami i procesami biznesowymi. To na co głównie zwraca uwagę właściciel danych, to zgodność z regulacjami.
• CIO, CTO – Chief Information Officer, czyli po polsku dyrektor IT, oraz Chief Technology Officer – czyli dyrektor techniczny – to role często spotykane w różnych organizacjach, którym z punktu widzenia zarządzania dostępem przypisuje się niekiedy odpowiedzialność za zarządzanie dostępem do systemów. Nie jest to jednak dobra praktyka, ponieważ osoby na tych stanowiskach, a szerzej mówiąc działy IT, nie posiadają pełnej wiedzy, kto i do czego powinien mieć dostęp w firmie. IT dostarcza narzędzi dla procesów, utrzymuje repozytoria danych, realizuje czynności związane z zarządzaniem systemami, ale nie jest nigdy tą jednostką organizacyjną, której pracownicy mają pełną wiedzę niezbędną do zapewnienia pełnej rozliczalności z przypisanych uprawnień do pracowników.

Jak to praktycznie wygląda we wdrożeniach systemów IGA?

W jednym z wcześniejszych opracowań zajmowaliśmy się definiowaniem takich pojęć jak rola czy standard RBAC (Co to jest RBAC? Porównanie RBAC z ABAC) – wiemy, że zarządzanie uprawnieniami z ich użyciem pozwala znacząco uprościć cały proces na przykład dla bezpośredniego przełożonego (Line Manager), który przydziela jedną, odpowiednią rolę dla swojego podwładnego zamiast wielu pojedynczych uprawnień z wielu różnych systemów czy aplikacji. I z drugiej strony odebranie roli powoduje, że wszystkie uprawnienia i dostępy z nią związane są automatycznie odebrane pracownikowi. W praktyce to właśnie osoby na stanowiskach kierowniczych (Line Managers) poszczególnych jednostek organizacyjnych, przy wsparciu właścicieli systemów (System Owners), biorą udział w definiowaniu ról biznesowych (jak odbywa się cały proces, opiszemy w jednym z kolejnych artykułów). Bazując na naszym doświadczeniu wdrażania systemów IGA w wielu różnych organizacjach, to główne te dwa rodzaje właścicieli biorą udział zarówno w procesach przydzielania uprawnień, jak i ich okresowego weryfikowania (Uwagi na temat przeglądu uprawnień). Niestety większość zadań związanych z zarządzaniem uprawnieniami jest delegowana tylko do tych dwóch grup właścicieli, przykładowo nawet przy definiowaniu reguł SOD, zamiast właściciela procesu (Process Owner) angażowany jest administrator systemu (System Owner), który nie zawsze ma pełen obraz, jakie uprawnienia nie powinny był łączone, tym bardziej że sam proces, dla którego definiujemy zasady SOD, może był obsługiwane przez różne systemy (a co za tym idzie różnych właścicieli systemów) i może dotyczyć różnych jednostek (zarządzanych przez różnych kierowników).

Dlatego też żeby pokryć wymagania każdego właściciela, organizacje muszą  ich zidentyfikować i zaangażować do poszczególnych etapów projektowania i wdrażania systemów IGA (Identity Governance and Administration). Jeżeli jesteście zainteresowani możliwościami oferowanymi przez różne rozwiązania ze świata IGA, które mogą Wam pomóc w rozwiązaniu problemów związanych z zarządzaniem uprawnieniami, zapraszamy do kontaktu z firmą ProLimes.