W pierwszej części naszej serii o historii zarządzania dostępem pisaliśmy, iż LDAP uporządkował sposób przechowywania i wyszukiwania informacji o użytkownikach. W drugiej opowiedzieliśmy, jak Active Directory połączyło katalog z uwierzytelnianiem i zarządzaniem środowiskiem firmowym. Później systemy IDM zaczęły zarządzać cyklem życia kont, a IGA dołożyło kontrolę nad tym, kto powinien mieć dostęp i kto za niego odpowiada. W ostatniej części serii opisaliśmy, jak okazało się, iż podobnej kontroli potrzebują już nie tylko ludzie, ale również aplikacje, workload identities i agenci AI.
Dlaczego samo zalogowanie się użytkownika przestało wystarczać?
Pozostał jeszcze jeden problem, mający coraz większe znaczenie w ostatnich latach. Co zrobić, o ile dostęp był prawidłowy w chwili logowania, ale kilka minut później sytuacja się zmieniła?
Czy kiedyś wystarczało sprawdzić użytkownika jednokrotnie?
W czasach NetWare czy pierwszych sieci Microsoft środowisko było stosunkowo przewidywalne. Użytkownik przychodził do biura, uruchamiał komputer i logował się do sieci. Administrator określał, do których katalogów, drukarek czy aplikacji ma dostęp. o ile należało odebrać uprawnienie, zmieniało się członkostwo w grupie, uprawnienia do zasobu albo wyłączało konto. Active Directory znacząco usprawniło ten model. Kerberos pozwalał po jednym logowaniu korzystać z kolejnych zasobów bez ciągłego wpisywania hasła. W firmowej sieci, gdzie użytkownik, komputer i serwery znajdowały się zwykle pod kontrolą jednej organizacji, takie podejście przez lata sprawdzało się bardzo dobrze.
Chmura ponownie zmieniła warunki gry. Użytkownik może dziś rano zalogować się z firmowego laptopa w biurze, godzinę później korzystać z aplikacji przez telefon, a po południu pracować z hotelowego Wi-Fi. Sama informacja, iż kilka godzin wcześniej pomyślnie przeszedł logowanie, przestała wystarczać do podjęcia wszystkich kolejnych decyzji o dostępie.
Co zmienił Conditional Access?
W tradycyjnym modelu duże znaczenie miała sama obecność użytkownika w firmowej sieci. W chmurze granica sieci przestała być tak użyteczna. Potrzebne były dodatkowe informacje: kto się loguje, z jakiego urządzenia, skąd pochodzi połączenie i jaki jest poziom ryzyka. W Microsoft Entra tę rolę pełni Conditional Access. Microsoft określa go jako silnik polityk Zero Trust, wykorzystujący różne sygnały do podejmowania decyzji o dostępie. Polityka może na przykład wymagać dodatkowego uwierzytelnienia, gdy użytkownik próbuje uzyskać dostęp do określonej aplikacji. Pod uwagę mogą być brane między innymi użytkownik lub grupa, lokalizacja IP, urządzenie czy informacje o ryzyku.
To istotna zmiana w porównaniu z prostym pytaniem: „Czy hasło jest poprawne?”. Coraz częściej adekwatne pytanie brzmi: „Czy w tych konkretnych warunkach powinniśmy pozwolić tej tożsamości korzystać z tego zasobu?”. Tyle iż choćby ta decyzja jest podejmowana w określonym momencie.
Co dzieje się po wydaniu tokenu?
W aplikacjach chmurowych użytkownik nie przesyła swojego hasła przy każdym odczycie poczty czy otwarciu dokumentu. Po uwierzytelnieniu otrzymuje token, którym aplikacja posługuje się przy dostępie do zasobów. To wygodne (i konieczne), ale prowadzi do pewnego dysonansu. Token może przez cały czas być ważny, mimo iż stan użytkownika od chwili jego wydania już się zmienił. Administrator wyłącza konto pracownika. Hasło zostaje zresetowane po wykryciu incydentu. System bezpieczeństwa oznacza użytkownika jako wysokiego ryzyka. Zmienia się lokalizacja połączenia. Czy trzeba czekać, aż dotychczasowy token po prostu wygaśnie? Właśnie z tego powodu pojawiło się Continuous Access Evaluation, czyli CAE.
Na czym polega Continuous Access Evaluation?
CAE pozwala obsługującym ten mechanizm usługom reagować na wybrane zdarzenia związane z tożsamością bez czekania na naturalne wygaśnięcie tokenu. Microsoft wskazuje między innymi wyłączenie lub usunięcie konta, zmianę albo reset hasła, manualne odwołanie tokenów oraz wykrycie wysokiego ryzyka użytkownika. W obsługiwanych scenariuszach reakcja może nastąpić w czasie zbliżonym do rzeczywistego. Różnica jest zasadnicza. Wcześniej decyzja o dostępie była mocno związana z momentem uwierzytelnienia i terminem ważności otrzymanego poświadczenia. CAE umożliwia ponowną reakcję, kiedy istotna informacja zmieni się już podczas aktywnej sesji. Nie oznacza to oczywiście, iż każda operacja użytkownika jest bez przerwy sprawdzana od początku. CAE działa dla określonych zdarzeń, polityk i obsługujących ten mechanizm usług. To jednak dobry przykład tego, jak zmieniło się podejście do kontroli dostępu.
Czy ciągła ocena dotyczy tylko użytkowników?
Tu pojawia się bezpośrednie połączenie z poprzednią częścią tej serii. Skoro aplikacja albo service principal posiada własną tożsamość i może uzyskać dostęp do danych, również jego sytuacja może zmienić się po wydaniu tokenu. W 2026 roku Microsoft udostępnia Continuous Access Evaluation także dla workload identities. Mechanizm obejmuje service principals i może wymuszać polityki lokalizacji oraz ryzyka, a także reagować na zdarzenia powodujące odwołanie tokenu. Nie wszystkie rodzaje workload identities są jednak w tej chwili obsługiwane – dokumentacja Microsoftu wskazuje na przykład, iż CAE dla workload identities nie obejmuje jeszcze managed identities.
Conditional Access również wychodzi poza klasyczne konto użytkownika. Aktualna dokumentacja Microsoft Entra wymienia możliwość kierowania polityk do użytkowników, grup oraz – w wersji preview – agentów. To dobrze pokazuje kierunek zmian. Kontrola dostępu podąża za tym samym rozszerzeniem, które wcześniej nastąpiło w Identity Governance.
Co zmieniło się przez trzydzieści lat?
Na początku problem był prosty – jak uporządkować informacje o użytkownikach rozsiane po różnych serwerach? LDAP dał wspólny sposób pracy z katalogiem. Active Directory połączyło katalog z logowaniem i zarządzaniem komputerami. IDM zautomatyzowało tworzenie kont w wielu systemach, a IGA pozwoliło kontrolować, kto powinien mieć dostęp i kto podjął o tym decyzję. Później okazało się, iż tożsamość nie musi należeć do człowieka. Te same pytania trzeba było zadać w odniesieniu do aplikacji, workload identities i agentów AI. Dzisiaj dochodzi jeszcze jedno.
Nie wystarczy już ustalenie, kto lub co może uzyskać dostęp. Trzeba również brać pod uwagę, czy decyzja podjęta podczas logowania po upływie czasu przez cały czas jest zasadna.
Od NetWare 3.12 do Continuous Access Evaluation droga była długa, ale problem pozostał zaskakująco podobny. Administrator przez cały czas musi wiedzieć, kto lub co korzysta z firmowych zasobów, dlaczego ma do nich dostęp i czy ten dostęp przez cały czas powinien obowiązywać.
I na tym chyba najlepiej zakończyć tę historię. Przynajmniej do czasu, gdy pojawi się kolejny rodzaj tożsamości, którym trzeba będzie zacząć zarządzać…
