We wcześniejszych artykułach staraliśmy się przybliżyć znaczenie takich pojęć, jak PAM, AM, IDM czy IGA (możesz o nich przeczytać tutaj). Każdy z tych systemów w pewnym zakresie swojego działania zakłada możliwość wykorzystania zarządzania uprawnieniami poprzez automatyzację procesów oraz metod używanych do przypisywania uprawnień do tożsamości (identity), przy czym zakładamy, iż obiekty takie jak konta (np. konta AD czy bazodanowe) są również reprezentacją uprawnienia przypisanego do tożsamości człowieka lub maszyny (person identity, machine identity). Słowo „tożsamość” ma tutaj najważniejsze znaczenie, ponieważ modele takie jak Zero-Trust czy Identity-First Security skupiają się na definiowaniu zaleceń bezpieczeństwa w oparciu o tożsamość, a nie pojedyncze konta osoby czy maszyny. Definicji tożsamości można by przytaczać wiele, ale do tego artykułu powinien nam wystarczyć opis zamieszczony w kolejnym akapicie.
Jak rozumiemy tożsamość?
Jako tożsamość rozumiemy byt elektroniczny określający kim lub czym taka jednostka jest oraz jakie czynności może w organizacji wykonywać czy do jakich danych mieć dostęp. Zwykle tożsamość opisana jest zestawem atrybutów, takich jak imię, nazwisko, numer kadrowy oraz inne dane organizacyjne (w przypadku tożsamości człowieka), lub nazwę logowania i opis usługi, z jaką jest skojarzone (w przypadku tożsamości maszyn). Nie ma tutaj jednej zasady określającej, jakie zestawy atrybutów mogą opisywać tożsamość, i każda organizacja używa w tym celu własnych reguł. Miejscem, w którym przechowujemy informacje o tożsamości, jest właśnie system IAM\IGA, a jedną z głównych korzyści, jakie niesie za sobą posiadanie w swojej organizacji systemu tej klasy jest fakt, iż daje on nam możliwość wejrzenia w to, jakie uprawnienia posiada tożsamość, a nie konto – ponieważ pracownik może takich kont mieć wiele, a reprezentowany jest zwykle przez jeden obiekt tożsamości.
Jak powstaje obiekt tożsamości? Jakie procesy są za to odpowiedzialne?
Procesy związane z cyklem życia tożsamości (Identity Lifecycle Management – ILM) to procesy określające, w jaki sposób tożsamość jest tworzona i zarządzana – zarówno w kontekście tożsamości osób, jak i maszyn, oraz tego, jakie uprawnienia są przydzielane lub odbierane tożsamości w kontekście zdarzeń takich jak jej utworzenie (Joiner), zmiana (Mover) oraz wyłączenie (Leaver). Możemy te pojęcia objaśnić w sposób następujący:
- Joiner – proces wyzwalany dla zdarzenia pojawienia się nowej tożsamości w systemie IAM\IGA, którego skutkiem jest utworzenie obiektu tożsamości oraz przypisanie jej podstawowego, minimalnego zestawu uprawnień (np. konta AD i skrzynki pocztowej). Wyzwalaczem może być zdarzenie związane z zatrudnieniem nowej osoby (czyli wprowadzeniem kompletu danych o nowo zatrudnionym pracowniku do systemu kadrowo-płacowego) lub powołanie obiektu nowej tożsamości maszyny (np. wniosek o utworzenie nowego konta serwisowego z poziomu systemu IAM\IGA). W procesie tym powstaje obiekt tożsamości, dla którego określone są wartości atrybutów ją opisujących oraz dla którego może być utworzone konto użytkownika (np. w katalogu Active Directory). Wartości atrybutów skorelowane są z wartościami atrybutów tożsamości, dla której konto zostało utworzone.
- Mover – proces uruchamiany w przypadku zmiany wartości wybranego atrybutu lub zestawu atrybutów (najczęściej organizacyjnych – np. departamentu, stanowiska), który ma zapewnić zachowanie zestawu uprawnień niezbędnego do wykonywania swoich obowiązków na danym stanowisku. Oprócz zmiany wartości atrybutów proces ten powinien również zapewnić odebranie uprawnień, które były przypisane do tożsamości dla poprzedniej roli pełnionej w organizacji i nadanie tych, które niezbędne są dla nowej roli pracownika. Z procesem tym często związane są procesy przeglądu uprawnień, pozwalające na potwierdzenie, iż „stare” uprawnienie dla tożsamości pracownika w danej roli organizacyjnej nie powinny być już przypisane do tej tożsamości.
- Leaver – gdy okres zatrudnienia kończy się, wszystkie konta skojarzone z tożsamością danej osoby powinny być zablokowane, najlepiej automatycznie. Oczywiście jest to minimalny zakres czynności, który powinien być realizowany dla tego procesu – można go rozbudować o wyłączenie dostępu do sieci VPN, uruchomienie procesu zablokowania korzystania z firmowych urządzeń mobilnych i tak dalej. W przypadku tożsamości maszyn możemy mówić np. o automatycznym wyłączeniu kont technicznych skojarzonych z daną aplikacją w momencie jej dezaktywacji w organizacji.
Opisane powyżej trzy rodzaje zdarzeń są jednoznacznie powiązane z procesami, które im odpowiadają. Bardzo często dla opisu jednej z podstawowych funkcjonalności systemu IAM\IGA używamy skrótu JML (Joiner-Mover-Leaver). Oczywiście są to ogólne opisy i dla wszystkich przedsiębiorstwa, które wdraża lub ma już wdrożony system zarządzania tożsamością i uprawnieniami, szczegółowa ich implementacja może być różna. Nie można również zapominać, iż oprócz procesów JML mogą być uruchomione procesy związane z ponownym zatrudnieniem pracownika, z archiwizacją tożsamości czy z realizacją dyrektywy GDPR. Zbiór tych procesów planowany jest już w pierwszych etapach projektu IAM i może oczywiście ulegać zmianie w trakcie życia systemu IAM w firmie. Są one bardzo ważne z punktu widzenia zarządzania uprawnieniami pracownika czy maszyny, ponieważ odzwierciedlają stan tożsamości w kontekście jej relacji z organizacją, a co za tym idzie – zestawu uprawnień i dostępów, jakie z tej relacji powinny wynikać.
Jednym z istotnych zagadnień, które wymaga szczegółowej analizy przy projektowaniu systemu IAM, jest określenie zaufanego źródła tożsamości. W przypadku pracowników takim źródłem jest najczęściej system kadrowy, jeden lub kilka w zależności od struktury organizacji (np. firmy posiadającej oddziały w różnych krajach). Dla tożsamości kontraktorów źródłem może być sam system IAM, gdzie rejestrowanie nowych tożsamości kontraktorów odbywa się poprzez określony formularz i podlega procesowi akceptacji. Podobnie można wnioskować o tożsamości maszyn dla kont serwisowych. Istotne jest to, iż zaufane źródło tożsamości jest autorytatywnym źródłem wartości atrybutów, na podstawie których wyzwalane są zdarzenia związane z cyklem życia tożsamości. Przykładem może być atrybut określający datę zwolnienia pracownika (lub ważności tożsamości maszyny), o ile data zostanie osiągnięta, to dla tożsamości uruchamiany jest proces Leaver, którego skutkiem będzie odebranie powiązanych z tożsamością uprawnień. Warto nadmienić, iż różne atrybuty tożsamości mogą mieć różne zaufane źródła danych – np. informacja o numerze telefonu służbowego może pochodzić z innego systemu niż system HR, a informacja o adresie e-mail może być pobierana z systemu pocztowego. adekwatnie zaprojektowany model danych tożsamości powinien zawierać kompletny zestaw atrybutów wymagany nie tylko do opisania tożsamości, ale niezbędny do prawidłowego wyzwalania procesów JML.
Na koniec parę słów o tym, iż prawidłowa implementacja procesów JML dzięki systemów IAM w przedsiębiorstwie pozwala nie tylko na znaczące zwiększenie poziomu bezpieczeństwa (poprzez redukcję nadmiernych przywilejów czy wyłączenie kont zwolnionych pracowników), ale również odciążenie działów IT od manualnych operacji na kontach pracowników.
W kolejnym artykule postaramy się opisać, w jaki sposób może odbywać się zarządzanie uprawnieniami tożsamości w kontekście procesów JML z optymalnym wykorzystaniem dostępnych mechanizmów zarządzania przez role.
Jeżeli jesteś zainteresowany tym, jak w praktyce może wyglądać implementacja zarządzania uprawnieniami w systemie IAM\IGA, zachęcamy do kontaktu z firmą Prolimes.
