Entra Workload ID: které identity licencovat

Automatizační aplikace má oprávnění číst firemní data přes Microsoft Graph. Správce ji přidá do skupiny chráněné podmíněným přístupem a předpokládá, že se nyní připojí jen z firemní sítě. Přihlášení aplikace však probíhá dál i odjinud. Problém nemusí být ve výjimce pro uživatele: aplikace používá vlastní identitu a zásada přiřazená skupině se na její servisní principál nevynucuje.

Microsoft Entra Workload ID Premium se posuzuje podle identit využívajících prémiové funkce. Není součástí běžných prémiových uživatelských plánů a licence se jednotlivým identitám nepřiřazují jako zaměstnancům. Nejdřív přitom ověřte, zda vybraná funkce daný typ identity vůbec podporuje. Zakoupením další licence se z nepodporované aplikace nestane podporovaný cíl zásady.

Článek řeší aplikační identity ve firemním Entra tenantu. Licencování, rozsah Conditional Access, ID Protection a průběžného vyhodnocování přístupu jsme ověřili v dokumentaci Microsoftu 20. října 2026. Doporučená evidence a číselný model jsou vlastní návrh pro rozhodnutí, nikoli výsledky bezpečnostního auditu konkrétní firmy.

Rozhoduje přihlašující se identita

Přehled workload identit rozlišuje aplikace, servisní principály a managed identities. App registration popisuje aplikaci; servisní principál představuje její identitu v konkrétním adresáři. Managed identity je zvláštní typ identity spravovaný pro příslušnou službu. Tyto pojmy při inventuře nezaměňujte za tři automaticky samostatně placené licence.

Jiná situace je přístup aplikace jménem přihlášeného člověka a jiná samostatné volání s vlastními aplikačními oprávněními. U servisního účtu vytvořeného jako běžný uživatel zase stále pracujete s uživatelskou identitou. Název účtu typu „robot“ jeho druh nemění.

Pro každý datový tok zapište, kdo žádá o token, do jakého prostředku míří a zda používá uživatelské, nebo aplikační oprávnění. Vlastní single-tenant aplikace může volat Microsoft Graph; to, že cílové API provozuje Microsoft, z klienta nedělá Microsoft aplikaci vyloučenou z této ochrany. Rozhodující je zde přihlašující se klientský servisní principál.

Tři funkce mají různé hranice

Samotné označení „ochrana strojových identit“ je pro objednávku příliš široké. FAQ Workload ID a návody jednotlivých funkcí rozlišují podmíněný přístup, detekci rizika a revize oprávnění.

Rozsah rizikových detekcí upřesňuje ID Protection pro workload identity. To, že vidíte riziko určité multitenant aplikace, tedy neprokazuje možnost na ni nasadit stejnou blokovací zásadu jako na vlastní single-tenant automatizaci.

Managed identities přitom nejsou mimo všechny nástroje řízení. FAQ výslovně popisuje revize servisních principálů přiřazených privilegovaným rolím, včetně managed identities. Pro takovou revizi posuzujete Workload ID Premium na kontrolované identity a Entra ID P2 pro posuzovatele. Nelze z toho odvodit podporu managed identity v Conditional Access.

Jedna odemykací licence není pokrytí celého tenantu

Licenční FAQ uvádí dvě věci současně: licence se jednotlivým workload identitám nepřiřazují a jedna licence v tenantu může technicky odemknout funkce pro všechny. Zároveň požaduje potřebný počet licencí pro identity, které prémiové funkce využívají. Technická dostupnost nabídky proto není inventurou oprávnění.

Do rozpočtu nedávejte automaticky všechny záznamy v Enterprise applications. Oddělte podporované identity s použitými prémiovými funkcemi, ostatní identity a případné samostatné revize oprávnění. Ani několik zásad pro stejný principál bez dalšího neznamená několik Workload ID licencí pro tutéž identitu.

Hypotetický příklad: firma eviduje 40 workload identit a zavádí následující rozsah. Všechny započítané funkce jsou u příslušných identit podporované; nepočítáme zde jiné produkty ani cenu konkrétní nabídky.

Šest identit se dvěma funkcemi nepřičítejte podruhé: výsledek není 21. Současně nestačí jedna licence jen proto, že portál dovolí nastavit všechny zásady. A není důvod z tohoto návrhu odvozovat 40 licencí bez kontroly skutečného rozsahu.

Pokud následně zařadíte pět managed identities do podporované prémiové revize privilegovaných přiřazení, rozpočet se mění. Při splnění podmínek FAQ přibude pět Workload ID licencí a zvlášť ověříte P2 práva posuzovatelů. Nula v původní tabulce znamená pouze nepoužití prémiové funkce v daném modelu, nikoli obecnou bezplatnost každé činnosti managed identity.

Zásada musí mířit na správný objekt

Návod Conditional Access požaduje cílení přímo na servisní principály jako workload identity. Skupina obsahující principál tuto vazbu nenahradí. Pro identifikaci použijte Object ID z Enterprise applications, nikoli Object ID registrace z App registrations. Jde o různé objekty, i když mají stejný zobrazovaný název.

V popsané blokovací zásadě je dostupnou grant akcí Block access. Neplánujte interaktivní MFA jako řešení pro bezobslužnou aplikaci. Nejprve navrhněte, které požadavky mají být blokovány a které povoleny; potom ověřte skutečnou veřejnou IP výstupu služby. IP notebooku správce nemusí být IP cloudového běhu aplikace.

U proměnlivých výstupních adres potřebujete provozní návrh, ne další náhodnou výjimku. Omezení na rozsah, který zahrnuje velkou část veřejného cloudu, může zmenšit přínos zamýšlené ochrany. To je důvod ověřit stabilní výstup, skutečný způsob provozu a přiměřený rozsah oprávnění aplikace před zapnutím blokace.

Vydání tokenu není totéž co každé API volání

Conditional Access se zde vyhodnocuje při žádosti servisního principálu o token. Z úspěšné změny zásady nevyvozujte univerzální okamžité zastavení každého dříve vydaného tokenu ve všech službách.

Continuous access evaluation pro workload identity má další předpoklady: podporovanou single-tenant identitu, klienta deklarujícího schopnost cp1 a zpracování claims challenge. Aktuální dokumentace uvádí Microsoft Graph jako jediný podporovaný resource provider tohoto workload CAE scénáře. Managed identities a cizí multitenant SaaS do něj nespadají.

Při testu proto oddělte získání nového tokenu, volání s existujícím tokenem a reakci klienta na požadavek nového ověření. Pokud automatizace pouze opakuje neúspěšný požadavek, může po bezpečnostní změně přestat zpracovávat data, přestože server správně odmítá přístup. Ověřujte i dokončený pracovní výsledek a řízené hlášení chyby.

Ověřitelný postup zavedení

1. Sepište klientské identity. Object ID servisního principálu, druh aplikace, vlastníka, způsob ověření, cílová API a potřebná oprávnění. Odlište skutečný uživatelský servisní účet.
2. Přiřaďte konkrétní funkci. CA, prémiové rizikové reporty nebo revizi privilegií. Pro každou identitu nejdřív zkontrolujte podporu a teprve potom licenční rozsah.
3. Spočítejte unikátní příjemce prémiových funkcí. Zaznamenejte průniky, aby stejný principál nebyl započítán za každou zásadu znovu.
4. Založte omezený pilot v Report-only. Ověřte přímé cílení principálu, skutečné výstupní IP a výsledky v Service principal sign-ins. Tento režim vyhodnocuje dopad, neblokuje přístup.
5. Otestujte povolený i nepovolený zdroj. Zaznamenejte čas, klientskou identitu, použitou zásadu a vydání tokenu. Následně zkontrolujte přístup k cílovému API.
6. Samostatně otestujte existující token a CAE, pokud je používáte. Ověřte podporovaný resource provider, deklaraci schopnosti klienta a zvládnutí claims challenge.
7. Připravte nápravu a návrat. Vlastník aplikace má vědět, jak rozlišit blokaci, chybné přihlašovací údaje a běžnou nedostupnost služby. Návrat zásady nemá znamenat ponechání kompromitovaného tajného klíče.

Pokud jste zatím řešili pouze zaměstnance a jejich MFA, pokračujte souběžně licenčním rozsahem uživatelského Conditional Access. Obě evidence patří do stejného bezpečnostního návrhu, ale používají jiné jednotky a hranice podpory.