Entra ID Workload Identity: Was sie kann und was nicht

Definition

Entra ID Workload Identity bezeichnet Identitäten in Microsoft Entra ID, die non-human Workloads (z. B. Anwendungen, Services, Automationen) für Authentication und Access auf Ressourcen verwenden. Sie ist kein Benutzerkonto und kein Ersatz für Rollen- und Governance-Design, sondern ein kontrollierter Weg, Workloads als Service Principal oder Managed Identity zu betreiben.

Einleitung

Wenn Apps, Kubernetes-Workloads oder API-Integrationen Zugriff auf Azure- und Microsoft-Cloud-Resources brauchen, landen viele Teams schnell bei Secrets, statischen Credentials oder breit vergebenen Permissions. Entra ID Workload Identity räumt genau dort auf: klare Principals, klare Role-Assignments, weniger Secret-Handling und bessere Nachvollziehbarkeit in Sign-in Logs. Das reduziert Risiko, spart Betriebszeit und macht Audits einfacher.

Abgrenzung zu Benutzer-Identitäten

Benutzer-Identitäten sind human identities: eine Person meldet sich an, bekommt Zugriff, und Aktionen müssen eindeutig einer Person zuordenbar sein. Workload identities sind für Workloads: Eine application oder ein Dienst authentifiziert sich, erhält Tokens, und greift automatisiert auf eine resource zu.

• Benutzer: interaktiv, oft mit MFA und Conditional Access für Menschen.
• Workload: automatisiert, benötigt stabilen Zugriff mit minimalen permissions.
• Wichtig: Workloads dürfen nicht „mit Benutzerkonto“ laufen, weil Ownership, Reviews und Credential-Rotation sonst unklar werden.

Typische Architektur- und Deploy-Pattern

In Entra ID entstehen Workload-Identitäten meist als App Registration (Application object) plus Service Principal im tenant; in Azure gibt es zusätzlich Managed Identities. Welches Pattern passt, hängt davon ab, wo der Workload läuft und wie Credentials vermieden werden.

Azure-Resources: Managed Identities

Für Azure-Ressourcen (z. B. Automation, Compute, App-Workloads) sind Managed Identities oft der einfachste Weg: Der Principal wird von der Plattform verwaltet, credentials müssen nicht in Code oder Config verteilt werden, und Role Assignments können eng am Ziel (scope) gesetzt werden.

Kubernetes: Workload Identity Federation

Für Kubernetes (z. B. AKS) ist Workload Identity Federation ein gängiges Muster: Der Pod nutzt eine federated identity (OIDC-basiert) und bekommt Tokens, ohne dass ein secret im Cluster gespeichert werden muss. Das senkt das Risiko durch abgegriffene Secrets und reduziert Credential-Rotation als Daueraufgabe.

API-Integrationen: Service Principal mit klaren Permissions

Für API-Zugriffe (z. B. Microsoft Graph API) wird häufig ein Service Principal genutzt. Entscheidend ist, permissions so klein wie möglich zu halten, Admin-Consent streng zu steuern und Assignments nachvollziehbar zu dokumentieren.

Sicherheits-Best-Practices: Least Privilege, Policies, Logging

Der größte Gewinn entsteht nicht durch das reine Anlegen von identities, sondern durch Betrieb: sauber assigned permissions, klare policies und belastbares Monitoring. Das schützt nicht nur, sondern senkt Aufwand, weil du weniger „Fehler suchen“ musst, wenn etwas schiefgeht.

• Least Privilege: Rollen (Azure RBAC und App-Permissions) so eng wie möglich wählen, scope begrenzen, keine Default-Überrechte.
• Policies: Guardrails über Azure Policy und klare Standards für App Registration, credential-Laufzeiten und erlaubte resource types.
• Logging & Auditing: Sign-in logs, Änderungen an App-Objects, Role-Assignment-Änderungen und Token-Nutzung aktiv überwachen.

Access Reviews sind für viele Umgebungen der Hebel, um Berechtigungen nicht nur zu vergeben, sondern regelmäßig zu reviewen. Dadurch werden verwaiste principals und überholte Assignments sichtbar, bevor sie zum Problem werden.

Governance, Lifecycle-Management und Ownership

Workloads leben länger als Projekte. Ohne Lifecycle-Management wachsen principals, credentials und role assignments unkontrolliert, und niemand kann „owner“ und Zweck sicher benennen. Governance heißt hier: Verantwortlichkeit, Prozess und klare Nachweise.

• Ownership: Jede workload identity hat einen technischen owner (Betrieb) und einen fachlichen owner (Zweck/Anforderung).
• Lifecycle: Provisioning mit Standard, regelmäßige reviews, Deprovisioning bei Stilllegung.
• Privileged Zugriff: Wenn privileged roles nötig sind, muss das begründet, zeitlich begrenzt und überwacht werden (z. B. über PIM-Prozesse).

Mini-Story: Ein Team betreibt einen Job, der Daten in Azure schreibt. Über Jahre wird „kurz“ eine zusätzliche permission vergeben, dann noch eine. Nach einem Incident kann niemand sagen, welche identities das wirklich nutzen. Mit sauberer Ownership und Reviews wird aus „wir hoffen, es passt“ ein nachvollziehbarer Zugriffspfad.

Lizenzierung und Lizenz-Management-Überblick

Für einige Funktionen rund um Microsoft Entra Workload ID gibt es Premium-Features (z. B. erweiterte Governance- und Sicherheitsfunktionen). Wichtig für die Kostenfrage: Nicht jede workload identity braucht automatisch Premium-Lizenzen; relevant ist, welche Funktionen du nutzen willst und welche identities dafür in scope sind.

Für den Betrieb heißt das: Erst Anforderungen (z. B. Reviews, Risk/Schutz, Policies) festlegen, dann Lizenzbedarf ableiten und dokumentieren. So bleibt die license-Diskussion sachlich: „Welche Controls bringen messbaren Nutzen?“ statt „wir buchen vorsorglich alles“.

Implementierung: pragmatische Schritte vom Onboarding bis Monitoring

Eine sinnvolle Einführung ist weniger ein Projekt und mehr ein Standardablauf. Ziel ist, dass neue workloads schnell provisioned werden können, ohne Sicherheit und Nachvollziehbarkeit zu opfern.

• Onboarding: Inventar der Workloads, benötigte resources, benötigte Roles/Permissions, Abhängigkeiten (tenant, subscriptions, namespaces).
• Provisioning: Pattern wählen (Managed Identity oder Workload Identity Federation), Role Assignment mit minimalem scope, credential-Strategie festlegen.
• Monitoring: Sign-in logs und Änderungen an principals überwachen, Reviews terminieren, KPIs definieren (z. B. Anzahl verwaister identities, überbreite permissions, fehlende owner).

Messbarkeit: Erfolg zeigt sich nicht nur in „weniger Incidents“, sondern in weniger Secret-Rotation, weniger Berechtigungs-Ausnahmen und schnellerer Analyse, wer wann auf welche resource zugegriffen hat.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung wird sinnvoll, wenn mehrere Teams Workloads provisionen, Kubernetes und Cloud-Resources parallel laufen oder Privileged-Themen (z. B. breite Admin-Consents, hohe Rechte) aufkommen. Dann braucht es einheitliche Standards, laufende Reviews und ein Monitoring, das nicht nur Daten sammelt, sondern auch konsequent bearbeitet.

Typische Einwände sind Kosten und Komplexität. In der Praxis sind die größten Kostentreiber nicht die Lizenzen, sondern ungeplante Arbeit durch unklare permissions, nicht gereviewte Assignments und aufwendige Incident-Analyse ohne saubere Logs.