W poprzednich częściach tej serii pokazaliśmy, jak LDAP uporządkował przechowywanie informacji o użytkownikach, a Active Directory połączyło katalog z uwierzytelnianiem i zarządzaniem środowiskiem Windows. W sieci firmowej użytkownik mógł zalogować się do domeny i korzystać z wielu zasobów bez konieczności ponownego podawania hasła. Z punktu widzenia administratora był to ogromny postęp. Pozostawał jednak problem, którego ani katalog, ani mechanizm logowania nie rozwiązywały – kto właściwie powinien otrzymać dostęp do poszczególnych systemów i danych?

Autor: 7 min czytania

Kiedy zarządzanie dostępem było proste

W czasach NetWare 3.12 czy niewielkich sieci Microsoft zarządzanie dostępem miało często bardzo praktyczny charakter. Administrator znał większość użytkowników, wiedział, kto pracuje w księgowości, a kto w magazynie, a także, kto powinien korzystać z określonego katalogu lub drukarki. Przy kilkudziesięciu osobach i kilku serwerach można było nad tym zapanować nawet wtedy, gdy część informacji o uprawnieniach znajdowała się głównie w pamięci administratora.

Rozwój usług katalogowych znacznie ułatwił tę pracę. W Active Directory można było tworzyć grupy, przypisywać do nich użytkowników i za ich pomocą nadawać dostęp do zasobów. Problem w tym, że infrastruktura firmowa szybko przestała składać się wyłącznie z serwerów plików, drukarek i stacji roboczych podłączonych do jednej domeny.

Co zmieniły aplikacje biznesowe?

W firmach zaczęło przybywać systemów finansowych, kadrowych, ERP, CRM, baz danych i aplikacji pisanych na zamówienie. Nie wszystkie korzystały z Active Directory. Wiele posiadało własną bazę użytkowników, własny sposób logowania i własny model uprawnień. Nowy pracownik potrzebował więc coraz częściej nie jednego, lecz kilku lub kilkunastu kont. Jedno powstawało w domenie, kolejne w systemie finansowym, następne w aplikacji kadrowej czy systemie sprzedażowym. Dopóki firma była niewielka, można było obsługiwać to wszystko ręcznie. W dużych organizacjach liczba takich operacji rosła bardzo szybko.

Jeszcze większy problem pojawiał się przy zmianie stanowiska. Pracownik przechodzący z zakupów do sprzedaży otrzymywał dostęp do nowych aplikacji, ale stare uprawnienia nie zawsze były odbierane. Przy odejściu z firmy konto w domenie można było wyłączyć od razu, lecz lokalne konto w aplikacji uruchomionej kilka lat wcześniej mogło nadal istnieć.

Pojawienie się systemów IDM

Odpowiedzią na ten problem były systemy Identity Management, określane skrótem IDM. Ich zadaniem nie było zastąpienie katalogu, lecz połączenie informacji o użytkowniku znajdujących się w wielu różnych systemach.

Na przełomie wieków dużego znaczenia nabrały rozwiązania typu metadirectory oraz automatyczny provisioning. Novell rozwijał między innymi DirXML, który później stał się podstawą Novell Identity Manager. Microsoft w 2003 roku wprowadził Microsoft Identity Integration Server 2003, łączący mechanizmy metadirectory i provisioningu użytkowników. A jeszcze wcześniej powstawały takie rozwiązania jak ActiveEntry, z którego wywodzi się One Identity Manager. Pomysł był prosty. Jeżeli informacja o zatrudnieniu pracownika pojawia się w systemie HR, może ona automatycznie uruchomić utworzenie konta w katalogu i kolejnych aplikacjach. Zmiana nazwiska, działu czy stanowiska może zostać przekazana dalej, a zakończenie zatrudnienia może spowodować blokadę lub usunięcie odpowiednich kont.

W ten sposób zarządzanie tożsamością zaczęło obejmować cały cykl życia pracownika, a nie tylko samo założenie konta.

Czy automatyzacja rozwiązała problem dostępu?

Nie do końca. IDM potrafił bardzo dobrze odpowiedzieć na pytanie, jak utworzyć konto w systemie i jak przekazać do niego odpowiednie dane. Nadal jednak ktoś musiał zdecydować, jakie uprawnienia powinien otrzymać użytkownik. Administrator mógł wiedzieć, jak dodać pracownika do odpowiedniej grupy albo przypisać mu rolę w aplikacji finansowej, nie musiał jednak wiedzieć, czy konkretny pracownik powinien mieć możliwość zatwierdzania płatności albo wgląd w dane wszystkich oddziałów firmy.

Podobny problem pojawiał się po kilku latach. Dostęp nadany przy wdrożeniu projektu lub podczas pracy na poprzednim stanowisku mógł pozostać aktywny, mimo że użytkownik już go nie potrzebował. Automatyzacja przyspieszała więc nadawanie dostępu, ale nikt nie oceniał, czy decyzja o jego przyznaniu była właściwa.

Kto powinien decydować o dostępie?

Wraz z rozwojem systemów IDM coraz wyraźniej widać było, że nie wszystkie decyzje mogą pozostać po stronie działu IT. O dostępie do danych finansowych powinien decydować ktoś, kto odpowiada za ten obszar. Podobnie w przypadku systemu kadrowego, sprzedażowego czy produkcyjnego. Do procesu zaczęli więc włączać się przełożeni, właściciele aplikacji oraz właściciele danych. Pojawiła się potrzeba rejestrowania nie tylko samego uprawnienia, ale również informacji o tym, kto o nie wystąpił, kto zaakceptował i kiedy powinno zostać ponownie zweryfikowane.

Coraz większe znaczenie miały także wymagania audytowe. Nie wystarczało już stwierdzenie, że użytkownik należy do określonej grupy. Trzeba było umieć wyjaśnić, dlaczego do niej należy i kto podjął taką decyzję.

Jak z IDM powstało Identity Governance?

Właśnie w tym miejscu rozwiązania Identity Management zaczęły ewoluować w kierunku Identity Governance and Administration, czyli IGA. Do mechanizmów synchronizacji i provisioningu doszły procesy związane z wnioskowaniem o dostęp, jego zatwierdzaniem, okresowym przeglądem oraz kontrolą konfliktujących uprawnień (SoD czyli Segregation of Duties). W systemach IGA pojawiły się recertyfikacje, role biznesowe, workflow akceptacyjne oraz zasady Segregation of Duties. Chodziło już nie tylko o to, aby konto zostało utworzone lub usunięte we właściwym momencie. Równie ważne stało się wykazanie, dlaczego użytkownik posiada określony dostęp i czy nadal powinien go mieć.

Tę samą logikę można dziś znaleźć w usługach Microsoft Entra ID Governance, gdzie zarządzanie cyklem życia użytkownika jest uzupełnione między innymi przez Entitlement Management oraz Access Reviews (Microsoft Learn).

Co właściwie zmieniło IGA?

Największa zmiana nie dotyczyła technologii, lecz odpowiedzialności. W prostych sieciach administrator często sam wiedział, komu nadać dostęp. Systemy IDM zautomatyzowały wykonywanie tych operacji w wielu aplikacjach. IGA dołożyło do tego mechanizmy pozwalające ustalić, kto powinien podjąć decyzję i jak później tę decyzję zweryfikować. W ten sposób zarządzanie tożsamością przestało sprowadzać się do tworzenia i usuwania kont. Zaczęło obejmować również uzasadnienie oraz kontrolę dostępu przez cały okres jego obowiązywania.

Przez lata wszystkie te mechanizmy budowano przede wszystkim wokół pracowników. Dzisiaj sytuacja zaczyna się jednak zmieniać. Coraz więcej dostępów należy nie do ludzi, lecz do aplikacji, service principals, workload identities i automatyzacji. Do tej grupy dołączają właśnie agenci AI. W kolejnym artykule przyjrzymy się, jak zmienia to sposób myślenia o zarządzaniu tożsamością.