Microsoft Entra Workload ID adressiert die Identitäten, die keine Menschen sind: Anwendungen, Dienste, Skripte und Container, die sich gegenüber anderen Systemen authentifizieren müssen.
Was ist Microsoft Entra Workload ID?
Eine Workload-Identität ist eine Identität, die Sie einer Software-Workload zuweisen, damit sich diese authentifizieren und auf andere Dienste und Ressourcen zugreifen kann. In Microsoft Entra sind das Applications, Service Principals und Managed Identities.
Microsoft begründet den Bedarf klar: Lösungen sind zunehmend auf nicht-menschliche Entitäten angewiesen, und deren Zahl wächst stark. Angreifer richten sich nach Beobachtung von Microsoft zunehmend gegen nicht-menschliche Identitäten. Anders als ein menschlicher Nutzer, der typischerweise eine Identität für viele Ressourcen verwendet, arbeitet eine Software-Workload oft mit mehreren Credentials, die sicher abgelegt werden müssen. Zudem ist schwer nachvollziehbar, wann eine Workload-Identität entstanden ist und wann sie entzogen werden sollte.
Die meisten Identity- und Access-Management-Lösungen am Markt konzentrieren sich laut Microsoft ausschließlich auf menschliche Identitäten. Microsoft Entra Workload ID schließt diese Lücke.
Kernfunktionen
- Conditional Access für Workload-Identitäten: Anwendung von Conditional-Access-Richtlinien auf Service Principals der eigenen Organisation
- Continuous Access Evaluation: Echtzeit-Durchsetzung von Standort- und Risikorichtlinien für Workload-Identitäten
- Microsoft Entra ID Protection: Erkennung von Risiken wie geleakten Credentials, Eindämmung von Bedrohungen und Risikoreduktion
- Managed Identities: Zugriff auf durch Microsoft Entra geschützte Ressourcen ohne Verwaltung von Secrets für Workloads auf Azure
- Workload Identity Federation: Zugriff ohne Secrets für Szenarien wie GitHub Actions, Kubernetes-Workloads und Compute-Plattformen außerhalb von Azure
- Access Reviews für Service Principals: Überprüfung von Service Principals und Anwendungen in privilegierten Verzeichnisrollen
- Custom Security Attributes: eigene Sicherheitsattribute für Anwendungen
Typische Anwendungsfälle
CI/CD-Pipelines ohne hinterlegte Secrets
Ein Service Principal ermöglicht das Deployment einer Web-App von GitHub nach Azure App Service; über Workload Identity Federation entfällt die Verwaltung eines Secrets.
Zugriff auf Azure-Ressourcen
Eine Managed Identity versorgt einen Dienst mit Zugriff auf Ressourcen wie Azure Key Vault oder Azure Storage, ohne dass Entwickler Credentials verwalten.
Delegierter Zugriff auf Microsoft Graph
Eine App ermöglicht einer Web-App den Zugriff auf Microsoft Graph auf Basis von Admin- oder Nutzereinwilligung, entweder im Namen des Nutzers oder im Namen der Anwendung.
Eindämmung kompromittierter Identitäten
Über ID Protection erkannte Risiken, etwa geleakte Credentials, lassen sich mit Conditional Access unmittelbar in Zugriffsentscheidungen überführen.
Rezertifizierung privilegierter Zugriffe
Access Reviews prüfen, welche Service Principals und Anwendungen privilegierten Verzeichnisrollen zugewiesen sind.
Vorteile
- Schutz für nicht-menschliche Identitäten, die klassische IAM-Lösungen häufig auslassen
- Adaptive Zugriffssteuerung für Service Principals statt statischer Berechtigungen
- Wegfall der Secret-Verwaltung über Managed Identities und Workload Identity Federation
- Echtzeitreaktion auf Risiken über Continuous Access Evaluation
- Rezertifizierbarkeit privilegierter Workload-Zugriffe über Access Reviews
Integration mit innFactory
Als indirekter Microsoft-CSP-Partner unterstützt innFactory Sie bei der Bestandsaufnahme Ihrer Workload-Identitäten, der Ablösung hinterlegter Secrets durch Managed Identities und Workload Identity Federation sowie beim Aufbau von Conditional-Access-Richtlinien für Service Principals.
Die Verankerung erfolgt üblicherweise im Rahmen der Plattform-Governance; unser Vorgehen beschreiben wir im Beitrag zu Azure Landing Zones.
Kontaktieren Sie uns für eine unverbindliche Beratung zur Absicherung von Workload-Identitäten.
Typische Anwendungsfälle
Technische Spezifikationen
Häufig gestellte Fragen
Was ist eine Workload-Identität?
Eine Workload-Identität ist eine Identität, die Sie einer Software-Workload zuweisen, etwa einer Anwendung, einem Dienst, einem Skript oder einem Container, damit sich diese authentifizieren und auf andere Dienste und Ressourcen zugreifen kann. In Microsoft Entra sind Workload-Identitäten Applications, Service Principals und Managed Identities.
Wie unterscheiden sich Application, Service Principal und Managed Identity?
Eine Application ist eine abstrakte Vorlage, definiert durch ihr Application-Objekt; sie ist die globale Repräsentation über alle Tenants hinweg. Ein Service Principal ist die lokale Instanz dieses globalen Objekts in einem konkreten Tenant und legt fest, was die App dort tatsächlich tun darf. Eine Managed Identity ist ein spezieller Service Principal, der die Verwaltung von Credentials durch Entwickler überflüssig macht.
Warum brauchen Workload-Identitäten eigenen Schutz?
Microsoft begründet das damit, dass Lösungen zunehmend auf nicht-menschliche Entitäten angewiesen sind und deren Zahl stark wächst. Anders als menschliche Nutzer arbeitet eine Software-Workload oft mit mehreren Credentials für verschiedene Ressourcen, die sicher gespeichert werden müssen. Zudem ist schwer nachvollziehbar, wann eine Workload-Identität erstellt wurde oder wann sie entzogen werden sollte.
Welche Schutzmechanismen bietet Entra Workload ID?
Microsoft nennt drei Bereiche: adaptive Richtlinien über Conditional Access für Workload-Identitäten und Continuous Access Evaluation, Erkennung kompromittierter Identitäten über Microsoft Entra ID Protection sowie vereinfachtes Lifecycle-Management über Managed Identities, Workload Identity Federation und Access Reviews für Service Principals in privilegierten Verzeichnisrollen.
Wie lassen sich Secrets in CI/CD-Pipelines vermeiden?
Über Workload Identity Federation. Microsoft nennt dafür ausdrücklich unterstützte Szenarien wie GitHub Actions, Workloads auf Kubernetes sowie Workloads auf Compute-Plattformen außerhalb von Azure. Für Workloads, die auf Azure laufen, bieten Managed Identities denselben Effekt.
Wie verhält sich Workload ID zu Entra Agent ID?
Microsoft ordnet KI-Agenten als eigene Kategorie von Maschinenidentitäten ein, weil sie dynamisch entscheiden und ihr Verhalten anpassen. Dafür stellt Microsoft Entra Agent ID eigene Agentenidentitäten bereit, mit erzwungener menschlicher Sponsorship, Lifecycle-Governance von der Bereitstellung bis zur Deaktivierung und zentraler Verwaltung über alle Agenteninstanzen eines Typs.
Hinweis: Alle Produktinformationen auf dieser Seite wurden sorgfältig zusammengestellt, sind jedoch ohne Gewähr und können veraltet oder unvollständig sein. Cloud-Services entwickeln sich schnell weiter — Funktionen, Preise, SLAs und Verfügbarkeit ändern sich laufend. Verbindliche und aktuelle Informationen finden Sie ausschließlich auf der offiziellen Produktseite von Azure (offizielle Dokumentation). Diese Seite stellt kein Angebot von Azure dar.
