W poprzednich częściach tej serii opowiadaliśmy, jak zarządzanie tożsamością rozwijało się razem z firmową informatyką. LDAP uporządkował informacje o użytkownikach, Active Directory połączyło katalog z uwierzytelnianiem i zarządzaniem środowiskiem, a systemy IDM oraz IGA zajęły się cyklem życia kont i kontrolą dostępu. Przez większość tego czasu w centrum znajdował się człowiek. Pracownik przychodził do firmy, otrzymywał konto i uprawnienia, zmieniał stanowisko, a po jego odejściu dostęp należało odebrać.

Autor: 6 min czytania

Choć dzisiaj ten model nadal obowiązuje, użytkownik nie jest już jedynym posiadaczem cyfrowej tożsamości. Do firmowych zasobów logują się aplikacje, skrypty, usługi, procesy automatyzacji, maszyny wirtualne i systemy CI/CD. Do tej bogatej grupy dołączają teraz agenci AI.

Czy za każdym kontem stał kiedyś człowiek?

Nie. Konta techniczne są znacznie starsze niż chmura. Administratorzy środowisk Windows od lat tworzyli konta dla usług, aplikacji czy automatycznie wykonywanych zadań. W starszych systemach podobne potrzeby pojawiały się wszędzie tam, gdzie program musiał dostać się do zasobu bez udziału zalogowanego użytkownika.

Przez długi czas nie traktowano tego jako osobnej kategorii zarządzania tożsamością. Konto techniczne zakładał administrator aplikacji, nadawał mu odpowiednie prawa i przekazywał dane konfiguracyjne osobie odpowiedzialnej za system. Jeżeli wszystko działało, do takiego konta często przez lata nie było potrzeby wracać. Problem pojawiał się później. Czy wiadomo jeszcze, do czego służy konto? Kto jest jego właścicielem? Czy aplikacja nadal działa? Czy przyznane pięć lat temu uprawnienia są nadal potrzebne?

Są to pytania bardzo podobne do tych, które wcześniej doprowadziły do rozwoju Identity Governance dla użytkowników.

Czy aplikacja potrzebuje Identity Governance?

Samo zastąpienie hasła lepszym mechanizmem uwierzytelniania nie rozwiązuje problemu dostępu. Jeżeli aplikacja posiada własną tożsamość, trzeba odpowiedzieć na te same pytania, które wcześniej zadawaliśmy w odniesieniu do pracownika. Kto jest właścicielem tej tożsamości? Dlaczego ma dostęp do danych? Jakie uprawnienia są jej rzeczywiście potrzebne? Kiedy należy je odebrać?

W przypadku workload identities dochodzi jeszcze jedna istotna różnica. Aplikacja nie odbierze telefonu z prośbą o potwierdzenie logowania i nie wykona MFA tak jak użytkownik. Microsoft zwraca również uwagę, że takie tożsamości często nie mają formalnie zdefiniowanego cyklu życia, a w części przypadków korzystają z przechowywanych sekretów lub innych poświadczeń. Utrudnia to ich kontrolę i zwiększa znaczenie właściwego zarządzania dostępem. Identity Governance zaczyna więc obejmować nie tylko ludzi, ale również oprogramowanie.

Co zmieniają agenci AI?

Agent AI nie jest po prostu kolejnym skryptem uruchamianym według harmonogramu. Może wykonać kilka kolejnych czynności, korzystać z różnych narzędzi i sięgać do wielu źródeł danych w zależności od zadania, które ma wykonać. Jeżeli agent ma odczytać wiadomość, sprawdzić dane klienta, przygotować dokument i zapisać wynik w innym systemie, potrzebuje odpowiedniego dostępu do każdego z tych zasobów. Problem nie dotyczy więc tylko tego, czy agent potrafi się uwierzytelnić. Trzeba również wiedzieć, pod jaką tożsamością działa i jakie prawa zostały jej przyznane.

Microsoft rozwija ten obszar w ramach Microsoft Entra Agent ID, czyli mechanizmu rozszerzającego zarządzanie tożsamością Entra na agentów AI. Agent otrzymuje własną tożsamość, którą można uwierzytelniać, chronić i objąć mechanizmami governance. To dość wyraźny sygnał, w jakim kierunku zaczyna zmierzać IAM.

Kto odpowiada za dostęp agenta?

To pytanie okazuje się ważniejsze niż sama technologia.

Microsoft Entra Agent ID wprowadza między innymi pojęcie sponsora agenta. Sponsor jest człowiekiem odpowiedzialnym za decyzje dotyczące cyklu życia i dostępu konkretnego agent identity. Może oceniać potrzebę dalszego działania agenta, występować w jego imieniu o dostęp czy uzasadniać biznesową potrzebę przyznania określonych praw.

Do agent identities można również stosować mechanizmy znane już z IGA. Microsoft Entra ID Governance pozwala między innymi korzystać z access packages, określać proces zatwierdzania dostępu oraz nadawać go na ograniczony czas. Po upływie ustalonego okresu dostęp może wygasnąć, jeżeli nie zostanie ponownie przedłużony.

Trudno nie zauważyć podobieństwa do problemów opisanych w poprzednim artykule. Zmienił się obiekt, którym zarządzamy, ale zasady pozostały bardzo podobne.

Czy historia rzeczywiście zatacza koło?

W czasach NetWare największym wyzwaniem było uporządkowanie informacji o użytkownikach. Później Active Directory pomogło zarządzać nimi w ramach firmowej infrastruktury. IDM połączyło konta rozsiane po wielu systemach, a IGA dodało odpowiedzialność za decyzje dotyczące dostępu. Teraz podobny proces zaczyna obejmować tożsamości niebędące ludźmi. Service principal, managed identity czy agent AI również mogą otrzymać zbyt duże uprawnienia. Być może zostaną one aktywne po zakończeniu projektu. Agent może nie mieć właściciela albo korzystać z dostępu przyznanego kilka lat wcześniej. Dlatego współczesne Identity Governance coraz mniej przypomina zarządzanie wyłącznie „użytkownikami”. Przedmiotem zarządzania staje się każda tożsamość, która może uzyskać dostęp do firmowych zasobów.

Od użytkownika przy terminalu NetWare do samodzielnie działającego agenta AI minęło ponad trzydzieści lat. Pytanie, z którym mierzy się administrator, pozostało jednak bardzo podobne – kto lub co ma dostęp, dlaczego go posiada i kto za ten dostęp odpowiada?