Entra Workload ID: Welche Identitäten lizenzieren?

Eine Automatisierungsanwendung darf über Microsoft Graph Unternehmensdaten lesen. Der Administrator nimmt sie in eine durch bedingten Zugriff geschützte Gruppe auf und erwartet, dass sie sich nur noch aus dem Firmennetz verbindet. Die Anwendung meldet sich trotzdem von anderen Standorten an. Die Ursache muss keine Benutzerausnahme sein: Die Anwendung verwendet eine eigene Identität, und eine der Gruppe zugewiesene Richtlinie wird für ihren Dienstprinzipal nicht erzwungen.

Bei Microsoft Entra Workload ID Premium richtet sich der Lizenzumfang nach den Identitäten, die Premiumfunktionen nutzen. Das Produkt ist nicht in üblichen Premiumplänen für Benutzer enthalten; Lizenzen werden den einzelnen Identitäten nicht wie Beschäftigten zugewiesen. Prüfen Sie zuerst, ob die gewählte Funktion den Identitätstyp unterstützt. Eine zusätzliche Lizenz macht eine nicht unterstützte Anwendung nicht zu einem unterstützten Richtlinienziel.

Dieser Artikel behandelt Anwendungsidentitäten in einem Entra-Unternehmensmandanten. Lizenzierung, Umfang von Conditional Access, ID Protection und kontinuierliche Zugriffsauswertung wurden am 20. Oktober 2026 anhand der Microsoft-Dokumentation geprüft. Die vorgeschlagene Erfassung und das Zahlenmodell sind eigene Entscheidungshilfen, keine Ergebnisse eines Sicherheitsaudits bei einem bestimmten Unternehmen.

Entscheidend ist die sich anmeldende Identität

Die Übersicht zu Workloadidentitäten unterscheidet Anwendungen, Dienstprinzipale und verwaltete Identitäten. Eine App-Registrierung beschreibt die Anwendung; der Dienstprinzipal bildet ihre Identität in einem bestimmten Verzeichnis ab. Eine verwaltete Identität wird für den jeweiligen Dienst verwaltet. Behandeln Sie diese Begriffe bei der Inventur nicht automatisch als drei getrennt kostenpflichtige Lizenzen.

Eine Anwendung im Namen einer angemeldeten Person unterscheidet sich von eigenständigen Aufrufen mit eigenen Anwendungsberechtigungen. Ein als normaler Benutzer angelegtes Dienstkonto bleibt wiederum eine Benutzeridentität. Die Bezeichnung „Roboter“ ändert seinen Typ nicht.

Erfassen Sie für jeden Datenfluss, wer das Token anfordert, welche Ressource angesprochen wird und ob delegierte Benutzer- oder Anwendungsberechtigungen verwendet werden. Eine eigene Single-Tenant-Anwendung kann Microsoft Graph aufrufen. Dass Microsoft das Ziel-API betreibt, macht den Client nicht zu einer von diesem Schutz ausgeschlossenen Microsoft-Anwendung. Entscheidend ist hier der sich anmeldende Client-Dienstprinzipal.

Drei Funktionen mit unterschiedlichen Grenzen

„Schutz von Maschinenidentitäten“ beschreibt den Bestellumfang zu ungenau. Die Workload-ID-FAQ und die Funktionsanleitungen unterscheiden bedingten Zugriff, Risikoerkennung und Zugriffsüberprüfungen.

ID Protection für Workloadidentitäten präzisiert den Umfang der Risikoerkennung. Ein sichtbares Risiko bei einer mandantenfähigen Anwendung belegt nicht, dass dieselbe Blockierungsrichtlinie wie für die eigene Single-Tenant-Automatisierung möglich ist.

Verwaltete Identitäten sind dennoch nicht von sämtlichen Governance-Werkzeugen ausgeschlossen. Die FAQ beschreibt ausdrücklich Überprüfungen von Dienstprinzipalen mit privilegierten Rollenzuweisungen, einschließlich verwalteter Identitäten. Dafür sind Workload ID Premium für die überprüften Identitäten und Entra ID P2 für die Prüfer zu berücksichtigen. Daraus folgt keine Unterstützung verwalteter Identitäten in Conditional Access.

Eine freischaltende Lizenz deckt nicht den Mandanten ab

Die Lizenzierungs-FAQ nennt zwei Aussagen gleichzeitig: Workloadidentitäten erhalten keine einzelne Lizenzzuweisung, und eine Lizenz im Mandanten kann die Funktionen technisch für alle freischalten. Zugleich verlangt Microsoft die erforderliche Anzahl an Lizenzen für Identitäten, die Premiumfunktionen nutzen. Die Verfügbarkeit im Portal ersetzt deshalb keine Bestandsaufnahme der Nutzungsrechte.

Planen Sie nicht automatisch für jeden Eintrag unter Enterprise applications eine Lizenz ein. Trennen Sie unterstützte Identitäten mit genutzten Premiumfunktionen, andere Identitäten und zusätzliche Zugriffsüberprüfungen. Mehrere Richtlinien für denselben Dienstprinzipal bedeuten für sich genommen nicht mehrere Workload-ID-Lizenzen für diese Identität.

Hypothetisches Beispiel: Ein Unternehmen erfasst 40 Workloadidentitäten und führt folgenden Umfang ein. Alle eingerechneten Funktionen werden für die betreffenden Identitäten unterstützt. Andere Produkte und Preise eines konkreten Angebots bleiben außerhalb dieses Modells.

Zählen Sie die sechs Identitäten mit zwei Funktionen nicht erneut: Das Ergebnis ist nicht 21. Ebenso reicht eine Lizenz nicht allein deshalb aus, weil sich im Portal sämtliche Richtlinien konfigurieren lassen. Auch 40 Lizenzen lassen sich ohne Prüfung des tatsächlichen Umfangs daraus nicht ableiten.

Werden die fünf verwalteten Identitäten später in eine unterstützte Premiumüberprüfung privilegierter Zuweisungen aufgenommen, ändert sich das Budget. Unter den Bedingungen der FAQ kommen fünf Workload-ID-Lizenzen hinzu; die P2-Rechte der Prüfer sind gesondert zu prüfen. Die Null in der Tabelle bedeutet ausschließlich, dass im ursprünglichen Modell keine Premiumfunktion genutzt wird. Sie erklärt nicht sämtliche Aktivitäten verwalteter Identitäten für kostenlos.

Die Richtlinie muss das richtige Objekt adressieren

Die Conditional-Access-Anleitung verlangt die direkte Auswahl von Dienstprinzipalen als Workloadidentitäten. Eine Gruppe, die den Prinzipal enthält, ersetzt diese Zuweisung nicht. Verwenden Sie die Object ID aus Enterprise applications, nicht die Object ID der Registrierung aus App registrations. Auch bei identischem Anzeigenamen sind dies verschiedene Objekte.

In der beschriebenen Blockierungsrichtlinie steht Block access als Grant-Aktion zur Verfügung. Planen Sie keine interaktive MFA als Lösung für eine unbeaufsichtigte Anwendung. Definieren Sie zunächst erlaubte und zu blockierende Anfragen und prüfen Sie dann die tatsächliche öffentliche Ausgangs-IP des Dienstes. Die IP des Administratornotebooks muss nicht der Cloud-Ausgangsadresse der Anwendung entsprechen.

Wechselnde Ausgangsadressen erfordern ein Betriebskonzept statt weiterer beliebiger Ausnahmen. Eine Freigabe für große Teile einer öffentlichen Cloud kann den beabsichtigten Schutz abschwächen. Prüfen Sie deshalb einen stabilen Ausgang, den tatsächlichen Betrieb und angemessen begrenzte Anwendungsberechtigungen vor der Aktivierung.

Tokenausstellung ist nicht jeder API-Aufruf

Conditional Access wird hier bei der Tokenanforderung des Dienstprinzipals ausgewertet. Eine erfolgreiche Richtlinienänderung bedeutet nicht, dass jedes bereits ausgestellte Token in jedem Dienst sofort unbrauchbar wird.

Continuous access evaluation für Workloadidentitäten hat zusätzliche Voraussetzungen: eine unterstützte Single-Tenant-Identität, einen Client mit deklarierter cp1-Fähigkeit und die Verarbeitung von Claims Challenges. Die aktuelle Dokumentation nennt Microsoft Graph als einzigen unterstützten Ressourcenanbieter dieses Workload-CAE-Szenarios. Verwaltete Identitäten und fremde mandantenfähige SaaS-Anwendungen gehören nicht dazu.

Testen Sie deshalb neue Token, Aufrufe mit bestehenden Token und die Clientreaktion auf eine erneute Prüfanforderung getrennt. Eine Automatisierung, die fehlgeschlagene Anfragen lediglich wiederholt, kann nach einer Sicherheitsänderung die Datenverarbeitung einstellen, obwohl der Server den Zugriff korrekt verweigert. Prüfen Sie auch den abgeschlossenen Arbeitsvorgang und eine kontrollierte Fehlermeldung.

Ein überprüfbares Einführungsverfahren

1. Clientidentitäten erfassen. Object ID des Dienstprinzipals, Anwendungstyp, Verantwortliche, Authentifizierungsmethode, Ziel-APIs und erforderliche Berechtigungen dokumentieren. Tatsächliche Benutzer-Dienstkonten unterscheiden.
2. Konkrete Funktion zuordnen. CA, Premium-Risikoberichte oder Überprüfung privilegierter Zugriffe. Je Identität zuerst Unterstützung, dann Lizenzumfang prüfen.
3. Einmalig begünstigte Identitäten zählen. Überschneidungen erfassen, damit derselbe Prinzipal nicht je Richtlinie erneut gezählt wird.
4. Begrenzten Report-only-Piloten starten. Direkte Auswahl, tatsächliche Ausgangs-IPs und Ergebnisse unter Service principal sign-ins prüfen. Dieser Modus bewertet Auswirkungen, blockiert aber nicht.
5. Erlaubte und unerlaubte Quellen testen. Zeitpunkt, Clientidentität, verwendete Richtlinie und Tokenausstellung erfassen. Anschließend Zugriff auf das Ziel-API kontrollieren.
6. Bestehende Token und gegebenenfalls CAE separat testen. Unterstützten Ressourcenanbieter, deklarierte Clientfähigkeit und Claims-Challenge-Verarbeitung prüfen.
7. Behebung und Rücknahme vorbereiten. Verantwortliche müssen Richtlinienblockierung, ungültige Anmeldedaten und gewöhnliche Dienstausfälle unterscheiden können. Eine Rücknahme darf keinen kompromittierten geheimen Schlüssel weiter in Gebrauch lassen.

Wenn bisher Beschäftigte und MFA im Vordergrund standen, prüfen Sie ergänzend den Lizenzumfang von benutzerbezogenem Conditional Access. Beide Bestandsaufnahmen gehören in dasselbe Sicherheitskonzept, verwenden aber andere Zähleinheiten und Unterstützungsgrenzen.