In vielen Tenants, die ich mir anschaue, sind Workload-Identitäten ein Flickenteppich aus alten App-Registrierungen, verstreuten Client Secrets und kaum dokumentierten Service Principals. Das überrascht mich nicht, denn Microsoft hat die Funktionen rund um Workload-Identitäten in Entra ID (früher Azure AD) in den letzten Jahren zügig ausgebaut. Admins und Entwickler müssen deshalb oft nachbessern, Altlasten ausmisten und sich in neue Möglichkeiten einarbeiten. Weil Angriffe auf privilegierte App-Identitäten zunehmen, lohnt es sich gerade jetzt, genauer hinzusehen.

Workload-Identitäten gehören Anwendungen und nicht Menschen

Unter „Workload-Identitäten“ versteht Entra ID alle Identitäten, die Anwendungen oder Automatisierungen nutzen und eben nicht Menschen. Dazu zählen klassische App-Registrierungen und Service Principals, aber auch Managed Identities, die Azure-Ressourcen direkt mitbringen. Microsoft hat das Thema inzwischen an einer Stelle gebündelt; der offizielle Artikel zu Workload-Identitäten gibt einen soliden Überblick über die einzelnen Typen.

Der wichtigste Unterschied zeigt sich meist bei der Verwaltung. App-Registrierungen und Service Principals sind sehr flexibel, aber auch fehleranfällig, vor allem im Umgang mit Geheimnissen. Managed Identities dagegen sind „cloud-native“, Azure verwaltet sie selbst. Sie kommen in zwei Varianten: system-assigned, gebunden an eine einzelne Ressource, und user-assigned, die sich mehreren Ressourcen zuordnen lassen. Für typische Automatisierungen in Azure fährt man mit Managed Identities in der Regel besser.

Client Secrets sind im Grunde nur lange Passwörter

Immer noch stoße ich auf App-Registrierungen mit uralten Client Secrets, die nie rotiert oder sogar offen weitergegeben wurden. Ein solches Secret ist nichts anderes als ein langes Passwort, und entsprechend schnell taucht es in Skripten, Code-Repos oder auch in Teams-Chats auf. Wer es in die Finger bekommt, kann im Namen der Anwendung alles tun, was ihre Berechtigungen hergeben. Richtig gefährlich wird es, wenn das Secret zu einer App mit „Application“-Rechten auf den gesamten Microsoft Graph gehört. Dann führt ein gestohlenes Secret geradewegs zu hochsensiblen Daten.

Zertifikate sind eine brauchbare Alternative, weil sie sich automatisch rotieren lassen und nicht so leicht versehentlich nach außen gelangen. Noch besser ist Workload Identity Federation, zum Beispiel für GitHub Actions. Hier muss niemand mehr ein Secret oder Zertifikat von Hand pflegen, weil die Authentifizierung über einen vertrauenswürdigen Identitätsanbieter läuft. Microsoft beschreibt das Prinzip verständlich im Leitfaden zu Workload Identity Federation. Die Anwendung, etwa ein GitHub-Workflow, belegt per Token, dass sie legitim ist, und bekommt im Gegenzug einen zeitlich begrenzten Zugriff.

Praxis-Tipp: Secrets regelmäßig rotieren und in Azure Key Vault ablegen. Wo immer es geht, ist der Umstieg auf Managed Identities oder Federation aber die bessere Lösung. Er verkleinert die Angriffsfläche spürbar und spart obendrein Wartungsaufwand.

System-assigned Identities verschwinden mit ihrer Ressource

In Azure-Projekten sollte man sich bewusst zwischen system-assigned und user-assigned Managed Identities entscheiden. Eine system-assigned Identity ist fest an eine Ressource gekoppelt und wird automatisch entfernt, sobald jemand die Ressource löscht. So wuchern die Identitäten nicht unkontrolliert („Identity Sprawl“). User-assigned Identities sind flexibler, weil man sie mehreren Ressourcen zuordnen kann. Das erleichtert das Berechtigungsmanagement, verleitet aber auch dazu, Rechte zu großzügig zu streuen. Ich greife deshalb meist zu system-assigned, außer mehrere Dienste sollen ganz bewusst dieselbe Identität verwenden.

Das folgende Diagramm zeigt, wie sich die einzelnen Typen von Workload-Identitäten in Entra ID zueinander verhalten:

flowchart TD
  appreg["App Registrierung"] --> sp["Service Principal"]
  managedsys["Managed Identity (system-assigned)"] --> sp
  manageduser["Managed Identity (user-assigned)"] --> sp
  federation["Identity Federation"] --> sp
  sp --> msgraph["Microsoft Graph Zugriff"]

Abbildung: Die verschiedenen Workload-Identitäten in Entra ID und ihr Weg zum Graph-Zugriff.

Am Diagramm sieht man gut, dass jeder Identitätstyp am Ende als Service Principal in Entra ID landet. Worauf es ankommt, ist, für jede Anwendung von Anfang an den passenden Typ zu wählen und seinen Lebenszyklus im Griff zu behalten.

Auch Anwendungen brauchen nur die Rechte, die sie wirklich nutzen

Ein Fehler, der mir oft begegnet: Anwendungen bekommen Application Permissions für Microsoft Graph, die weit über ihren Bedarf hinausgehen. „Directory.ReadWrite.All“ für einen simplen Provisionierungsjob ist leider keine Seltenheit. Man sollte daher genau prüfen, welche Rechte tatsächlich gebraucht werden, und den Rest entziehen. Application Permissions lassen sich inzwischen recht bequem verwalten, im Entra-Portal ebenso wie automatisiert per PowerShell. Mit diesem Befehl finden Sie zum Beispiel alle App-Registrierungen mit Directory-Rechten im Tenant:

Get-MgServicePrincipal -Filter "AppRoles/any(ar:ar.Value eq 'Directory.ReadWrite.All')"

Solche Auswertungen bringen schnell ans Licht, wo die faulen Eier liegen. Vor allem bei übernommenen Projekten sollte man sie regelmäßig durchführen.

Conditional Access greift jetzt auch für Workload-Identitäten

In den vergangenen Monaten hat Microsoft eine Funktion ausgerollt, auf die ich lange gewartet habe: Conditional-Access-Richtlinien für Workload-Identitäten (Workload Identities Premium). Damit kann man die Zugriffe bestimmter Apps etwa auf festgelegte IP-Adressen beschränken oder riskantes Verhalten blockieren. Angenehm ist, dass die Richtlinien auf den Service Principal der Anwendung wirken, also ganz ähnlich wie bei Benutzerkonten. Die Funktion ist noch jung und nicht in jedem Tenant gleich im Einsatz. Die ersten Erfahrungen zeigen aber, dass sie Missbrauch spürbar erschwert, zum Beispiel wenn ein Secret kompromittiert wurde.

Allerdings muss man ein wenig umdenken, und dieser Unterschied ist wichtig. Bei Menschen stützen sich die Bedingungen meist auf Standort, Gerät und Risiko. Bei Workload-Identitäten zählt eher der Kontext, also wie und von wo die Anwendung den Dienst aufruft. Die Umstellung kostet anfangs etwas Arbeit, bringt für die Sicherheit aber eine Menge.

Weniger selbst verwaltete Identitäten bedeuten weniger Ärger

Ich habe immer wieder erlebt: Je weniger selbst verwaltete App-Identitäten, Secrets und Zertifikate im Tenant herumgeistern, desto weniger Kopfschmerzen hat man auf Dauer. Wo es möglich ist, setze ich auf Managed Identities, bevorzugt system-assigned. In DevOps-Szenarien wie GitHub Actions ist Federation inzwischen das Mittel der Wahl. Application Permissions gehören regelmäßig auf den Prüfstand, ganz nach dem Grundsatz „so wenig wie möglich, so viel wie nötig“. Wer jetzt aufräumt, hat später deutlich weniger Stress und muss bei der Cloud-Sicherheit nicht länger raten.