W zarządzaniu tożsamością i dostępem często koncentrujemy się na procesach: wnioskowaniu o uprawnienia, zatwierdzaniu, tworzeniu kont i nadawaniu im uprawnień, okresowych przeglądach oraz odbieraniu dostępu po zmianie roli lub odejściu pracownika. Na poziomie procedur wszystko może wyglądać poprawnie. Problem zaczyna się wtedy, gdy zadamy proste pytanie: „Czy naprawdę widzimy wszystkie konta, jakie istnieją w aplikacjach?”.

Autor: 6 min czytania

Kwestia ta jest ważniejsza, niż mogłoby się wydawać. Organizacje przez lata wdrażały aplikacje biznesowe, narzędzia dostępne jako oprogramowanie w formie usługi, systemy wewnętrzne, integracje techniczne oraz, co bardzo istotne, tworzyły lokalne konta administratorów lub użytkowników o podwyższonych uprawnieniach w aplikacjach. W organizacjach, które korzystają z Entra ID, może być tak, że część z nich została podłączona do centralnego dostawcy tożsamości, część korzysta z automatycznego nadawania kont przez standard SCIM (System for Cross-domain Identity Management), część obsługuje wyłącznie jednokrotne logowanie, a część nigdy nie została objęta spójnym procesem zarządzania tożsamością.

Efekt jest łatwy do przewidzenia – w aplikacjach mogą istnieć konta, których nie ma już w katalogu użytkowników, które nie mają właściciela albo które zostały utworzone poza oficjalnym procesem.

Microsoft dobrze uchwycił ten problem w artykule „You can’t govern what you can’t see: Closing the identity visibility gap for apps”, opublikowanym na Microsoft Tech Community. Opisano w nim lukę widoczności kont aplikacyjnych oraz funkcję Odkrywanie kont (Account Discovery) w Microsoft Entra ID Governance. Jej celem jest odnajdywanie istniejących kont w aplikacjach docelowych, dopasowywanie ich do użytkowników w Microsoft Entra ID oraz klasyfikowanie jako kont lokalnych, nieprzypisanych lub przypisanych.

Jest to bardzo praktyczne narzędzie. Jeżeli konto istnieje w aplikacji, ale nie ma odpowiadającej mu tożsamości w Microsoft Entra ID, może to oznaczać byłego pracownika, konto techniczne, konto współdzielone, błąd jakości danych albo użytkownika utworzonego poza standardowym procesem. Jeżeli konto pasuje do użytkownika w katalogu, ale użytkownik nie jest przypisany do aplikacji firmowej, mamy inny problem – dostęp istnieje, ale nie jest zarządzany zgodnie z regułami zarządzania uprawnieniami organizacji.

I tutaj pojawia się sedno sprawy – zarządzanie dostępem nie zaczyna się od formularza wniosku ani od akceptacji przełożonego. Zaczyna się od inwentaryzacji. Nie można rzetelnie wykonać przeglądu dostępów, jeśli recenzent widzi tylko konta znane katalogowi centralnemu. Nie sposób również skutecznie odebrać dostępu po odejściu pracownika, jeżeli aplikacja przez lata pozwalała tworzyć konta lokalne poza głównym systemem tożsamości. Nie da się też mówić o zasadzie najmniejszych uprawnień, skoro część dostępów pozostaje poza zasięgiem systemu zarządzania uprawnieniami, jest niewidoczna dla właścicieli i procesów zarządzania cyklem życia tożsamości.

Czy to oznacza, że tylko Microsoft Entra ID pozwala rozwiązać ten problem?

Nie. Sam problem nie jest unikalny dla Microsoftu. W klasycznym podejściu do zarządzania tożsamością i dostępem podobne wyzwania rozwiązuje się przez pobieranie danych o kontach z systemów docelowych, korelację tych kont z główną tożsamością użytkownika, wykrywanie kont osieroconych oraz okresowe kampanie przeglądu (atestacji) uprawnień. Dojrzałe platformy tej klasy od lat próbują odpowiadać na pytanie: „Kto ma dostęp, do czego, na jakiej podstawie i czy nadal powinien go mieć?”.

Różnica polega raczej na miejscu, w którym Microsoft próbuje osadzić tę funkcję. Odkrywanie kont pojawia się bezpośrednio w Microsoft Entra ID Governance i jest powiązane z zarządzaniem aplikacjami firmowymi oraz procesem automatycznego tworzenia kont. To ważne, bo skraca drogę od wykrycia problemu do działania. Konto można sklasyfikować, powiązać z użytkownikiem, przypisać do aplikacji albo potraktować jako konto lokalne lub potencjalnie osierocone.

W praktyce pytanie nie brzmi więc: „Czy tylko Entra może to zrobić?”. Pytanie brzmi: „Gdzie w mojej architekturze powinna znajdować się prawda o kontach aplikacyjnych?”.

Jeżeli organizacja używa Microsoft Entra ID jako centralnego systemu tożsamości, korzysta z aplikacji firmowych, automatycznego tworzenia kont, pakietów dostępu, przeglądów dostępów i kontroli dostępu uprzywilejowanego, naturalne jest, że chce widzieć konta aplikacyjne właśnie tam. Jeśli jednak ma niezależną platformę zarządzania tożsamością, wiele katalogów, złożone systemy lokalne albo aplikacje nieobsługujące nowoczesnych standardów, Account Discovery w Entra będzie tylko jednym z elementów większego obrazu.

Co powinniśmy zapamiętać w kontekście Account Discovery w Entra ID?

Najważniejszy wniosek jest prosty – niewidoczne konta nie znikają dlatego, że nie ma ich w katalogu. One nadal mogą istnieć, logować się, przechowywać dane, posiadać role i generować ryzyko.

Nowoczesne zarządzanie tożsamością i dostępem musi zatem wyjść poza kontrolę tego, co sami nadaliśmy, i zacząć regularnie sprawdzać, co naprawdę istnieje w aplikacjach.

Bo dostęp, którego nie widać, nadal jest dostępem. A dostęp bez właściciela, uzasadnienia i cyklu życia to nie wyjątek administracyjny – to ryzyko.