Microsoft Entra CAE pre identity aplikácií: čo overiť pred zapnutím

Firemná aplikácia sa k dátam často neprihlasuje ako človek. Používa vlastnú identitu aplikácie, v Microsoft Entra označovanú ako service principal, a získava prístupový token. Bežný problém nastáva po zistení kompromitácie: administrátor identitu zakáže, no už vydaný bearer token môže zostať použiteľný do konca svojej platnosti.

Microsoft 25. augusta 2026 upozornil na podporu okamžitého vyhodnotenia zrušenia tokenov service principalov pomocou Continuous Access Evaluation, skrátene CAE. Nejde o univerzálny vypínač pre každú integráciu. Aktuálna dokumentácia obmedzuje riešenie na single-tenant service principaly vlastných line-of-business aplikácií, ktoré pristupujú k Microsoft Graphu a v požiadavke deklarujú schopnosť spracovať claims challenge.

Čo sa zmenilo a prečo je to dôležité

Bez CAE klient typicky opakovane používa token, kým nevyprší. Pri CAE môže podporovaný resource provider vyhodnotiť udalosť zrušenia aj pred expiráciou tokenu. Microsoft uvádza tri podporované udalosti pre workload identity: zakázanie service principalu, jeho odstránenie a detekciu vysokého rizika pre service principal. Microsoft Graph potom token odmietne odpoveďou 401 s claims challenge a klient musí požiadať Microsoft Entra o nové vyhodnotenie.

Prínos je konkrétny: ak tím pri incidente zakáže identitu aplikácie, podporovaný prístup k Microsoft Graphu nemusí čakať na prirodzenú expiráciu už vydaného tokenu. CAE-enabled tokeny pre workload identity môžu mať podľa dokumentácie platnosť až 24 hodín; priebežné vyhodnocovanie je preto súčasťou bezpečnostného modelu, nie doplnok k dlhej platnosti.

To však nenahrádza inventár aplikácií, obmedzené oprávnenia ani ochranu credentialov. CAE rieši vybranú časť reakcie po udalosti. Pri návrhu kybernetickej bezpečnosti firemných identít treba stále vedieť, ktoré aplikácie majú aké Graph oprávnenia, kde sú uložené tajomstvá alebo certifikáty a kto môže service principal deaktivovať.

Ako CAE pre workload identity funguje

1. Aplikácia požiada Microsoft Entra ID o token a v claims parametri deklaruje klientsku schopnosť cp1.
2. Microsoft Entra vyhodnotí príslušné pravidlá Conditional Access a vydá CAE-enabled token pre Microsoft Graph.
3. Aplikácia predloží token Microsoft Graphu. Graph ho priebežne posudzuje voči podporovaným udalostiam zrušenia a zmenám pravidiel.
4. Pri podporovanej udalosti Graph vráti odpoveď 401 s claims challenge.
5. Klient musí challenge spracovať, obísť svoju tokenovú cache a požiadať o nový token. Microsoft Entra podmienky vyhodnotí znova.

Samotné pridanie cp1 preto nestačí. Aplikácia musí korektne spracovať odpoveď 401 a claims challenge; inak sa po odmietnutí tokenu iba pokazí integrácia. Pre vlastnú aplikáciu je to vývojová a testovacia úloha, ktorú je vhodné zahrnúť do správy a rozvoja firemných integrácií.

Podporovaný rozsah je zatiaľ úzky

• Resource provider: aktuálne iba Microsoft Graph.
• Identity: single-tenant service principal registrovaný vo vlastnom tenantovi.
• Mimo rozsahu: managed identity, multitenant aplikácie a third-party SaaS.
• Pravidlá: CAE v reálnom čase vyhodnocuje podporované location a risk politiky pre workload identity.
• Priradenie politiky: skupinové priradenie pravidla service principalu sa neuplatní; politika musí cieliť priamo na workload identity.

Na vytváranie alebo úpravu Conditional Access politík pre service principaly Microsoft vyžaduje licencie Workload Identities Premium a minimálne rolu Conditional Access Administrator. Administrátor by mal pred nasadením overiť aktuálne podmienky konkrétneho tenantu a licenčného programu.

CAE je prínosné iba v podporovanom reťazci: správny service principal, Microsoft Graph, klient s cp1, spracovanie claims challenge a priamo zacielené pravidlá.

Praktický test pred produkčným nasadením

1. Vyberte neprodukčnú single-tenant aplikáciu s minimálnymi Graph oprávneniami a zdokumentujte jej service principal.
2. Overte, že použitá autentifikačná knižnica vie deklarovať cp1 a spracovať claims challenge podľa dokumentácie Microsoftu.
3. Nastavte testovaciu Conditional Access politiku najprv v režime, ktorý nezasiahne produkčné identity, a skontrolujte licencie aj priamy scope.
4. Vykonajte kontrolovaný test zakázania service principalu. Aplikácia má dostať 401 challenge a nesmie pokračovať so starým tokenom.
5. V Entra admin centre otvorte Service principal sign-ins a skontrolujte pole Continuous access evaluation, výsledok prihlásenia a použitú politiku.
6. Otestujte obnovu: znovu povoľte identitu iba podľa schváleného incidentného postupu a potvrďte, že aplikácia žiada nový token.

Test nemá prebiehať na kritickej integrácii bez rollbacku. Zakázanie alebo odstránenie service principalu môže prerušiť automatizáciu, synchronizáciu alebo reportovanie. Pri nejasnom vlastníctve najprv zmapujte závislosti a až potom skúšajte reakciu.

Čo má firma skontrolovať teraz

• zoznam aplikácií a service principalov s vlastníkom, účelom a poslednou aktivitou;
• Graph application permissions a administrátorské súhlasy podľa princípu najmenších oprávnení;
• platnosť certifikátov, umiestnenie tajomstiev a plán ich rotácie;
• podporu cp1, claims challenge a bezpečného retry mechanizmu v klientovi;
• priame priradenie Conditional Access pravidiel a licenčné predpoklady;
• logy service principal sign-ins, alerty a autorizovaný postup na deaktiváciu identity.

Rozumný prvý krok nie je zapnúť CAE všade. Je ním inventár workload identít a jeden kontrolovaný pilot. Yenwa môže pri autorizovanom audite spojiť vývojovú kontrolu integrácie, Graph oprávnenia, Conditional Access, logovanie a incidentný postup do testovateľného plánu bez neplánovaného zásahu do produkcie.