W przypadku przejęcia konta użytkownika administrator ma do dyspozycji kilka utartych schematów reakcji: może zablokować logowanie, zresetować poświadczenia albo unieważnić sesje. Z aplikacjami sytuacja jest mniej intuicyjna. Załóżmy, iż aplikacja zarejestrowana w Microsoft Entra ID korzysta z Service Principal i posiada application permissions do Microsoft Graph. Napastnik zdobywa jej sekret, pozyskuje access token i zaczyna wywoływać Graph API. Administrator wykrywa incydent, usuwa skompromitowane poświadczenie i wyłącza Service Principal. Czy token wystawiony przed tą operacją również przestaje działać?
Czy można zablokować token, który nie wygasł?
To ważne pytanie, ponieważ usunięcie sekretu zatrzymuje możliwość zdobywania kolejnych tokenów przy użyciu tego poświadczenia, ale nie zmienia automatycznie czasu ważności tokenu, który został już wydany. Standardowe access tokeny platformy Microsoft identity mają domyślnie zmienny czas życia, zwykle od 60 do 90 minut, ze średnią około 75 minut. Microsoft opisuje ten mechanizm w dokumentacji Access tokens in the Microsoft identity platform. W praktyce oznacza to potencjalne okno pomiędzy reakcją administratora a naturalnym wygaśnięciem tokenu. Continuous Access Evaluation, czyli CAE, pozwala ograniczyć zależność bezpieczeństwa od samego czasu życia access tokenu.
Co zmienia CAE dla workload identities?
25 sierpnia 2026 r. Microsoft opublikował materiał „Instant revocation of service principal bearer tokens with CAE”, poświęcony właśnie możliwości odcięcia bearer tokenu Service Principal jeszcze przed zakończeniem jego czasu życia: Instant revocation of service principal bearer tokens with CAE – Microsoft Entra Blog. Sam mechanizm CAE dla workload identities nie jest jednak funkcją wprowadzoną dopiero w sierpniu. Nowy materiał Microsoftu zwraca uwagę przede wszystkim na jego praktyczne znaczenie podczas incydentu dotyczącego tożsamości aplikacyjnej.
W obsługiwanym scenariuszu aplikacja deklaruje przy żądaniu tokenu zdolność cp1, informując Entra ID, iż potrafi obsłużyć claims challenge. Microsoft Entra może wtedy wystawić CAE-enabled access token dla workload identity. Co ciekawe, taki token może żyć choćby do 24 godzin, czyli znacznie dłużej niż standardowy access token. Nie oznacza to jednak doby gwarantowanego dostępu. Microsoft Graph może uwzględniać zdarzenia odwołania oraz zmiany obsługiwanych polityk Conditional Access jeszcze przed wygaśnięciem tokenu. Szczegóły działania, łącznie z przepływem cp1, Microsoft opisuje w dokumentacji Continuous access evaluation for workload identities.
Jeśli Service Principal zostanie wyłączony lub usunięty albo Microsoft Entra ID Protection wykryje dla niego wysokie ryzyko, Microsoft Graph może odrzucić niewygasły token. Klient obsługujący CAE powinien wtedy wystąpić o nowy token, a Entra ID ponownie oceni warunki dostępu.
Dlaczego ma to znaczenie dla Service Principals?
Service Principals należą do grupy workload identities, czyli tożsamości używanych przez aplikacje i usługi zamiast ludzi. W wielu środowiskach mają dostęp do poczty, plików, katalogu, procesów administracyjnych czy danych wykorzystywanych przez systemy AI. Często działają bez interaktywnego logowania oraz MFA. Microsoft zwraca uwagę, iż workload identities mają inną charakterystykę niż konta użytkowników – nie mogą wykonać MFA, często nie mają formalnego procesu lifecycle management i mogą wymagać przechowywania credentiali. To sprawia, iż ich zabezpieczenie wymaga innego podejścia: Conditional Access for workload identities – Microsoft Learn.
Z punktu widzenia Incident Response znaczenie CAE jest bardzo konkretne. Administrator nie powinien sprawdzać wyłącznie, czy udało się usunąć skompromitowany sekret albo wyłączyć obiekt. Powinien również wiedzieć, co stanie się z tokenami pozyskanymi przed reakcją. Dla aplikacji prawidłowo obsługującej CAE i komunikującej się z Microsoft Graph wyłączenie Service Principal może stać się mechanizmem szybkiego odcięcia aktywnego dostępu, a nie jedynie sposobem na uniemożliwienie pozyskania następnego tokenu.
Czy CAE działa dla wszystkich Service Principal?
Tutaj pojawia się ograniczenie, którego nie można zignorować. CAE dla workload identities nie obejmuje w tej chwili wszystkich aplikacji korzystających z Entra ID. Microsoft wspiera single-tenant Service Principals dla aplikacji line-of-business zarejestrowanych w danym tenantcie. Poza zakresem pozostają aplikacje multitenant, third-party SaaS oraz Managed Identities. Jedynym wspieranym w tej chwili resource providerem jest Microsoft Graph, a aplikacja musi jawnie zadeklarować cp1. Bez tego nie otrzyma CAE-enabled tokenu ani claims challenge.
CAE może również wymuszać w czasie rzeczywistym obsługiwane polityki Conditional Access dla workload identities oparte na lokalizacji i ryzyku. Do tworzenia lub modyfikowania polityk Conditional Access skierowanych do Service Principals Microsoft wymaga licencji Workload Identities Premium. Nie należy więc utożsamiać samego CAE z pełnym zakresem Conditional Access dla workload identities – są to mechanizmy powiązane, ale mają własne wymagania i ograniczenia. Aktualny zakres polityk Microsoft dokumentuje tutaj: Microsoft Entra Conditional Access for workload identities.
Nie zmienia to podstawowych zasad zabezpieczania aplikacji. Tam, gdzie architektura na to pozwala, warto przede wszystkim ograniczać wykorzystanie przechowywanych sekretów. Dla workloadów działających na platformach pozwalających ustanowić relację zaufania alternatywą jest workload identity federation, dzięki której aplikacja może uzyskać token Microsoft Entra na podstawie tokenu zewnętrznego dostawcy tożsamości bez konieczności utrzymywania klasycznego sekretu. Mechanizm i obsługiwane scenariusze opisuje dokumentacja Workload Identity Federation – Microsoft Learn. Do tego dochodzą minimalizacja application permissions, monitoring Service Principal sign-ins, Entra ID Protection oraz Conditional Access for workload identities.
Czy istotny token zawsze oznacza istotny dostęp?
Najciekawszym elementem CAE jest zmiana sposobu podejmowania decyzji o dostępie. W tradycyjnym podejściu duże znaczenie ma to, jak długo token pozostaje ważny. W modelu CAE resource provider może uwzględnić krytyczne zdarzenie dotyczące tożsamości i odrzucić token jeszcze przed osiągnięciem czasu jego wygaśnięcia. To właśnie ten scenariusz Microsoft wskazuje dziś jako sposób na instant revocation of service principal bearer tokens.
Dla zespołów odpowiedzialnych za Microsoft Entra ID oznacza to również zmianę sposobu testowania procedur awaryjnych. Warto sprawdzać nie tylko, czy potrafimy zablokować Service Principal, ale także czy aplikacja deklaruje cp1, czy wykorzystywany zasób obsługuje CAE oraz czy wcześniej wystawiony token rzeczywiście przestaje zapewniać dostęp po wystąpieniu zdarzenia odwołania. Dopiero taki test pokazuje, czy w przypadku przejęcia workload identity organizacja potrafi przerwać aktywny dostęp aplikacji, a nie tylko uniemożliwić jej kolejne uwierzytelnienie.
