Menu dostępności

Identity i JML

Identity i JML, czyli o tożsamości w systemach zarządzania tożsamością

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, że 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 kluczowe 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, że 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, że „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 każdego 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ć, że 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, że 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), jeżeli 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ć, że 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. Właściwie 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, że prawidłowa implementacja procesów JML za pomocą 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.

Popularne

Koniec ery VPN? Jak sztuczna inteligencja zmienia krajobraz cyberzagrożeń i przyspiesza przejście do Zero Trust

Koniec ery VPN? Jak sztuczna inteligencja zmienia krajobraz cyberzagrożeń i przyspiesza przejście do Zero Trust

Przez ponad dwie dekady sieci VPN (Virtual Private Network) stanowiły podstawowy mechanizm zapewniający bezpieczny dostęp zdalny do zasobów przedsiębiorstw. W czasach, gdy większość pracowników wykonywa...
Accenture potwierdza wyciek danych

Accenture potwierdza wyciek danych

Accenture, obecny również w Polsce gigant usług profesjonalnych, potwierdziło naruszenie bezpieczeństwa danych po tym, jak haker przyznał się do kradzieży kodu źródłowego firmy. Accenture to przedsi...
FIFA i Broken Access Control. Jak konto bez uprawnień uzyskało dostęp do systemów Mistrzostw Świata 2026

FIFA i Broken Access Control. Jak konto bez uprawnień uzyskało dostęp do systemów Mistrzostw Świata 2026

16 czerwca, czyli zaledwie pięć dni po rozpoczęciu Mistrzostw Świata 2026, badaczka cyberbezpieczeństwa działająca pod pseudonimem „BobDaHacker” opisała na swoim blogu lukę odkrytą w systemach FIFA. Według...
Masowa kampania password spray wymierzona w Azure CLI

Masowa kampania password spray wymierzona w Azure CLI

Cyberprzestępcy prowadzą zakrojoną na szeroką skalę kampanię password spray, wymierzoną w środowiska Microsoft 365 za pośrednictwem Azure CLI, o czym informuje Huntress – firma zajmująca się cyberbezpiec...
External MFA w Microsoft Entra ID – koniec Custom Controls

External MFA w Microsoft Entra ID – koniec Custom Controls

MFA, czyli uwierzytelnianie wieloskładnikowe, opiera się na prostej zasadzie: samo hasło nie wystarcza. Po wpisaniu loginu i hasła użytkownik musi jeszcze potwierdzić swoją tożsamość drugim składniki...