Workload Identities in Microsoft Entra ID absichern: Service Principals, Managed Identities und Secrets kontrollieren

Ein fehlgeschlagener nächtlicher Deployment-Job fällt oft sofort auf. Weitaus gefährlicher ist ein erfolgreicher Job, der mit einem längst vergessenen Service Principal läuft, globale Rechte besitzt und ein Secret verwendet, das seit Jahren nicht gewechselt wurde. Solche nicht-menschlichen Identitäten sind für Cloud-Anwendungen, Automatisierung, Infrastruktur und CI/CD unverzichtbar. Gerade weil sich niemand interaktiv mit ihnen anmeldet, geraten sie jedoch leicht aus dem Blick.

In Microsoft Entra ID werden diese Identitäten häufig unter dem Begriff „Workload Identities“ zusammengefasst. Dazu gehören vor allem Service Principals, Managed Identities und Anwendungen mit föderierten Anmeldeinformationen. Sie benötigen Zugriffe auf Azure-Ressourcen, Microsoft Graph, Datenbanken, Key Vaults, APIs oder SaaS-Dienste. Die zentrale Aufgabe besteht darin, Automatisierung zuverlässig zu ermöglichen, ohne dauerhaft überprivilegierte und schwer kontrollierbare Zugänge zu schaffen.

Infografik zu Workload Identities in Microsoft Entra ID absichern: Service Principals, Managed Identities und Secrets kontrollieren (KI-generiert).

Warum Workload Identities ein hohes Risiko darstellen

Menschliche Konten unterliegen meist klaren Prozessen: Eintritt, Rollenwechsel, MFA, Offboarding und regelmäßige Prüfungen. Bei Anwendungen ist das oft anders. Ein Projektteam erstellt eine App-Registrierung für einen Proof of Concept, hinterlegt ein Client Secret in einer Pipeline und vergibt großzügige Berechtigungen, damit die Integration schnell funktioniert. Monate später nutzt niemand die Anwendung mehr bewusst, aber ihre Identität bleibt aktiv.

Angreifer interessieren sich besonders für diese Konten, weil sie einige Vorteile bieten können:

• Sie besitzen oft Rechte für viele Ressourcen oder Mandantenbereiche.
• Ihre Secrets stehen möglicherweise in Skripten, Build-Variablen, Konfigurationsdateien oder Quellcode-Repositories.
• Sie lösen keine MFA-Abfrage aus, sofern eine klassische Secret- oder Zertifikatsanmeldung verwendet wird.
• Ihre Aktivitäten wirken zunächst wie reguläre technische Prozesse.
• Sie bleiben nach Personalwechseln häufig bestehen, weil Zuständigkeiten fehlen.

Dabei ist ein Service Principal nicht automatisch unsicher. Entscheidend sind Lebenszyklus, Berechtigungsmodell, Anmeldeverfahren und Überwachung. Für die Grundbegriffe und typische Angriffswege rund um Identitäten lohnt sich auch unser Beitrag zu Kerberoasting und der Absicherung von Servicekonten in Active Directory. Die technische Umgebung unterscheidet sich, das Grundproblem ist jedoch ähnlich: Ein Dienstkonto darf nicht mehr Rechte und eine längere Lebensdauer erhalten, als sein Zweck erfordert.

Service Principal, Managed Identity und App-Registrierung unterscheiden

Für sichere Entscheidungen musst du die Begriffe sauber trennen. Eine App-Registrierung beschreibt in Entra ID die Anwendung und ihre Konfiguration. Dort definierst du beispielsweise Umleitungs-URLs, Anmeldeinformationen, API-Berechtigungen und föderierte Anmeldeinformationen.

Der Service Principal ist die konkrete Instanz dieser Anwendung in einem Mandanten. Über ihn erhält die Anwendung Rechte, Rollen und Zuweisungen. Eine einzelne App-Registrierung kann in mehreren Mandanten Service Principals besitzen. Für die tägliche Sicherheitsarbeit ist meist der Service Principal entscheidend, weil hier tatsächliche Berechtigungen und Anmeldungen sichtbar werden.

Managed Identities sind speziell für Azure-Ressourcen gedachte Identitäten. Azure verwaltet ihre Anmeldeinformationen, sodass Teams kein Secret selbst erzeugen, verteilen oder rotieren müssen. Es gibt zwei verbreitete Varianten:

Typ	Geeignet für	Wichtige Eigenschaft
Systemseitig zugewiesene Managed Identity	Eine einzelne Azure-Ressource, etwa eine VM, Function App oder Logic App	Die Identität ist an den Lebenszyklus der Ressource gebunden
Benutzerseitig zugewiesene Managed Identity	Mehrere Ressourcen oder kontrollierte Wiederverwendung	Die Identität lebt unabhängig von einzelnen Ressourcen weiter

Wenn eine Azure-Workload auf Azure-Ressourcen zugreifen muss, ist eine Managed Identity in vielen Fällen die bessere Wahl. Sie reduziert das Risiko langlebiger Secrets erheblich. Wiederverwendbare benutzerseitig zugewiesene Identitäten brauchen allerdings klare Eigentümer und eine dokumentierte Zweckbindung, damit sie nicht zu einem neuen Sammelkonto mit zu vielen Rechten werden.

Zuerst inventarisieren: Welche Identitäten gibt es überhaupt?

Ohne vollständige Bestandsaufnahme ist jede Härtung zufällig. Erstelle deshalb ein zentrales Verzeichnis aller App-Registrierungen, Enterprise Applications, Managed Identities und föderierten Anmeldeinformationen. Ergänze nicht nur technische Daten, sondern auch fachliche Verantwortung.

Für jede Workload Identity sollten mindestens folgende Informationen vorliegen:

• Anzeigename, Objekt-ID und Application-ID
• Zweck, Anwendung und zugehörige Umgebung
• Fachlicher Eigentümer und technischer Ansprechpartner
• Erstellungsdatum und Datum der letzten Nutzung
• Zugewiesene Azure-Rollen und Ressourcenumfänge
• Microsoft-Graph- und weitere API-Berechtigungen
• Art der Anmeldung, etwa Managed Identity, Zertifikat, Secret oder Workload Identity Federation
• Ablaufdatum von Secrets und Zertifikaten
• Abhängige Pipelines, Anwendungen oder Automatisierungen
• Stilllegungsdatum oder regelmäßiger Prüftermin

Prüfe insbesondere Identitäten ohne Eigentümer, Anwendungen mit unklarer Beschreibung und Service Principals ohne erkennbare Anmeldung über einen längeren Zeitraum. „Ungenutzt“ bedeutet dabei nicht automatisch „gefahrlos löschbar“. Manche Jobs laufen nur monatlich, quartalsweise oder im Notfall. Kläre daher erst den Zweck und dokumentiere ihn, bevor du deaktivierst oder entfernst.

Auch externe Zusammenarbeit kann zusätzliche Anwendungsidentitäten und Berechtigungen mit sich bringen. Wie du Zugriffe über Mandantengrenzen kontrollierter gestaltest, erläutern wir im Beitrag Microsoft Entra ID Gastzugriffe absichern.

Minimal berechtigen statt globale Rechte vergeben

Eine Workload Identity benötigt keine „bequemen“ Rechte, sondern exakt die Rechte für eine klar definierte Aufgabe. Das klingt selbstverständlich, scheitert in der Praxis aber häufig an Zeitdruck und unübersichtlichen Berechtigungsmodellen.

Unterscheide mindestens drei Ebenen:

• Azure-Rollen steuern Zugriffe auf Azure-Ressourcen und Managementaktionen.
• API-Berechtigungen steuern den Zugriff auf Dienste wie Microsoft Graph.
• Anwendungsinterne Rollen und Berechtigungen steuern, was eine Identität in der jeweiligen Anwendung tun darf.

Für Azure-Ressourcen gilt: Weise Rollen möglichst auf der niedrigsten sinnvollen Ebene zu. Wenn eine Anwendung nur auf einen Storage Account zugreifen muss, braucht sie keine Rolle auf Managementgruppen-, Abonnement- oder Ressourcengruppenebene. Prüfe außerdem, ob eine lesende Rolle genügt oder ob Schreib-, Lösch- oder Verwaltungsrechte wirklich erforderlich sind.

Bei Microsoft Graph ist besondere Vorsicht geboten. Anwendungsberechtigungen wirken ohne angemeldeten Benutzer und können sehr weitreichend sein. Dokumentiere bei jeder Berechtigung, welche Funktion sie benötigt und welche Daten oder Objekte sie dadurch erreichen kann. Breite Rechte wie vollständiger Lesezugriff auf Verzeichnisse, Postfächer oder Dateien sollten eine explizite Sicherheitsfreigabe erfordern.

Für Webanwendungen gilt zusätzlich: Technische Authentifizierung ersetzt keine fachliche Autorisierung. Eine API muss prüfen, ob die aufrufende Anwendung genau auf das angefragte Objekt zugreifen darf. Typische Fehler und Testansätze findest du in unserem Ratgeber BOLA und IDOR in REST-APIs erkennen und verhindern.

Geheimnislose Anmeldung bevorzugen

Ein Client Secret ist einfach einzurichten, aber schwer dauerhaft sicher zu betreiben. Es kann kopiert, versehentlich protokolliert, in Repositories eingecheckt oder aus CI/CD-Systemen ausgelesen werden. Bevorzuge daher Anmeldeverfahren, bei denen kein dauerhaftes Geheimnis in einer Anwendung oder Pipeline liegt.

Die sinnvolle Reihenfolge ist häufig:

1. Managed Identity für Workloads auf Azure-Ressourcen einsetzen.
2. Workload Identity Federation für externe CI/CD-Systeme und unterstützte Plattformen nutzen.
3. Zertifikatsbasierte Anmeldung einsetzen, wenn Managed Identity oder Föderation nicht möglich sind.
4. Client Secrets nur verwenden, wenn es technisch notwendig ist, und dann streng kontrollieren.

Bei Workload Identity Federation vertraut Entra ID einem kurzlebigen Token eines externen Identitätsanbieters. Eine Pipeline kann sich so ohne gespeichertes Client Secret anmelden. Entscheidend ist eine enge Konfiguration: Begrenze Repository, Branch oder Umgebung so präzise wie möglich. Eine Vertrauensbeziehung für jedes beliebige Projekt oder jeden Branch öffnet unnötige Wege in deine Cloud-Umgebung.

Wenn Secrets unvermeidbar sind, speichere sie in einem dafür vorgesehenen Secrets-Management-System, nicht in Quellcode, Wiki-Seiten oder lokalen Konfigurationsdateien. Lege Ablaufdaten fest, überwache bevorstehende Abläufe und entferne alte Anmeldeinformationen nach einem kontrollierten Wechsel. Mehrere parallel gültige Secrets können Rotation erleichtern, dürfen aber nicht dauerhaft als vergessene Ausweichzugänge bestehen bleiben.

Bei automatisierten Builds gehört das auch in die Supply-Chain-Absicherung. Konkrete Maßnahmen für Berechtigungen, Tokens und Secrets in Pipelines beschreiben wir in GitHub Actions sicher konfigurieren.

Nutzung überwachen und Auffälligkeiten untersuchen

Workload Identities brauchen ein eigenes Monitoring. Prüfe Anmeldeprotokolle für Service Principals, Audit-Protokolle für Änderungen an App-Registrierungen und Enterprise Applications sowie Azure-Aktivitätsprotokolle für Aktionen auf Ressourcenebene. Diese Quellen beantworten unterschiedliche Fragen:

• Welcher Service Principal hat sich wann und von wo angemeldet?
• Wurde ein Secret, Zertifikat oder eine föderierte Anmeldeinformation hinzugefügt?
• Wurden API-Berechtigungen geändert oder Administratorzustimmungen erteilt?
• Welche Azure-Rollen wurden zugewiesen, entfernt oder erweitert?
• Welche Verwaltungsaktionen führte die Identität tatsächlich aus?

Definiere Alarme für Ereignisse, die selten und sicherheitsrelevant sind. Dazu gehören neue Anmeldeinformationen, Änderungen an Besitzern, neu erteilte privilegierte API-Berechtigungen, Anmeldungen aus unerwarteten Umgebungen und die erstmalige Nutzung lange inaktiver Identitäten. Wichtig ist der Kontext: Ein neuer Pipeline-Run ist nicht automatisch ein Sicherheitsvorfall, aber eine neue Secret-Erstellung außerhalb eines Change-Prozesses ist untersuchungswürdig.

Gute Protokollierung hilft nur, wenn Verantwortlichkeiten feststehen. Lege deshalb fest, wer Alarme bewertet, wie technische Teams eingebunden werden und welche Schritte bei Verdacht erfolgen. Grundlegende Hinweise zur sinnvollen Erkennungskette findest du auch in unserem Beitrag Angriffe früh erkennen: Logging und Monitoring.

Regelmäßige Kontrolle als fester Betriebsprozess

Die Absicherung endet nicht nach einem einmaligen Aufräumprojekt. Plane wiederkehrende Prüfungen für Berechtigungen, Eigentümer, Anmeldeverfahren und Nutzung. Besonders nach Projektabschlüssen, Migrationen und Änderungen an CI/CD-Plattformen entstehen verwaiste Identitäten.

Eine praxistaugliche Kontrollliste lautet:

• Jede Workload Identity besitzt einen fachlichen und technischen Eigentümer.
• Jede Berechtigung ist einem dokumentierten Zweck zugeordnet.
• Managed Identities oder föderierte Anmeldung ersetzen Secrets, wo dies möglich ist.
• Secrets und Zertifikate haben definierte Ablaufdaten und einen Rotationsprozess.
• Unbenutzte Identitäten werden nach Prüfung deaktiviert oder entfernt.
• Änderungen an Berechtigungen und Credentials werden protokolliert und überwacht.
• Notfallprozesse für das Sperren einer kompromittierten Identität sind getestet.

Passende Seminare und Termine zur Absicherung von Cloud-Identitäten, Berechtigungen und Sicherheitsprozessen findest du bei uns auf cmt.de.