Microsoft Entra Workload Identities absichern: Service Principals, Managed Identities und KI-Agenten kontrollieren

Ein KI-Agent liest Dokumente aus SharePoint, ruft ein Sprachmodell auf und legt das Ergebnis in einer Datenbank ab. Die Anwendung funktioniert, der Fachbereich ist zufrieden. Doch wer prüft, mit welcher Identität der Agent arbeitet, welche Berechtigungen diese Identität besitzt und ob ein ehemaliger Entwickler noch einen geheimen Schlüssel kennt? Genau an solchen Stellen entstehen in Microsoft-Cloud-Umgebungen Risiken, die im Alltag leicht übersehen werden.

Workload Identities sind nicht-menschliche Identitäten für Anwendungen, Automatisierungen, Skripte, CI/CD-Pipelines und Cloud-Dienste. In Microsoft Entra ID treten sie häufig als App-Registrierungen, Service Principals oder Managed Identities auf. Sie benötigen Zugriffe auf APIs, Datenbanken, Speicher, Microsoft 365 und Azure-Ressourcen. Weil sie im Hintergrund arbeiten, fallen übermäßige Rechte oder abgelaufene Geheimnisse oft erst auf, wenn ein Prozess ausfällt oder ein Sicherheitsvorfall untersucht werden muss.

Bei uns empfehlen wir deshalb, Workload Identities wie besonders privilegierte technische Konten zu behandeln: mit klarer Verantwortung, minimalen Rechten, sicheren Anmeldeverfahren und regelmäßiger Kontrolle.

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

App-Registrierung, Service Principal und Managed Identity unterscheiden

Die Begriffe werden im Projektalltag oft vermischt. Für eine saubere Verwaltung musst du die Unterschiede kennen.

Eine App-Registrierung beschreibt eine Anwendung in Microsoft Entra ID. Dort hinterlegst du beispielsweise Umleitungs-URIs, Zertifikate, geheime Schlüssel, API-Berechtigungen und die Kennung der Anwendung. Die Registrierung ist damit die Definition der Anwendung.

Der Service Principal ist die konkrete Sicherheitsidentität dieser Anwendung in einem Mandanten. Erst über den Service Principal erhält die Anwendung Rollen, Zugriffe und eine Anmeldemöglichkeit. Registriert ein Hersteller seine Anwendung in seinem eigenen Mandanten, kann in deinem Mandanten dennoch ein Service Principal entstehen, sobald du der Anwendung zustimmst.

Managed Identities sind von Azure verwaltete Identitäten für Azure-Ressourcen. Eine Azure Function, ein virtueller Server oder eine Logic App kann damit beispielsweise auf Key Vault, Azure Storage oder Azure SQL zugreifen, ohne dass du ein Kennwort oder Client Secret im Anwendungscode speichern musst.

Identität	Typischer Einsatz	Wichtiger Sicherheitsaspekt
App-Registrierung	Eigene Anwendung, API oder Integrationslösung	Besitz, Berechtigungen und Anmeldeinformationen pflegen
Service Principal	Sicherheitsobjekt einer Anwendung im Mandanten	Rollen und tatsächliche Nutzung überwachen
Systemseitig zugewiesene Managed Identity	Eine einzelne Azure-Ressource	Wird mit der Ressource erstellt und gelöscht
Benutzerseitig zugewiesene Managed Identity	Mehrere Azure-Ressourcen oder kontrollierter Wechsel	Eindeutigen Zweck und verantwortliches Team dokumentieren

Für viele Azure-Workloads ist eine Managed Identity der bessere Standard. Sie reduziert das Risiko langlebiger Geheimnisse deutlich. Das bedeutet aber nicht, dass sie automatisch sicher ist: Auch eine Managed Identity kann zu viele Rollen erhalten oder nach einem Projektende unbemerkt weiterbestehen.

Zuerst inventarisieren, dann bereinigen

Bevor du Berechtigungen reduzierst, brauchst du eine verlässliche Übersicht. Starte in Microsoft Entra ID mit den Bereichen für App-Registrierungen und Unternehmensanwendungen. Ergänze diese Sicht um Azure-Ressourcen mit systemseitig oder benutzerseitig zugewiesenen Managed Identities.

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

• Technischer Name und verständliche Beschreibung des Zwecks
• Fachlich verantwortliche Person und technisch verantwortliches Team
• Zugehörige Anwendung, Azure-Ressource oder Automatisierung
• Verwendete Anmeldeart, etwa Zertifikat, geheimer Schlüssel oder Managed Identity
• Erteilte API-Berechtigungen und Azure-Rollenzuweisungen
• Ressourcen, auf die tatsächlich zugegriffen wird
• Letzte Anmeldung oder letzte nachweisbare Nutzung
• Ablaufdaten von Zertifikaten und geheimen Schlüsseln
• Geplantes Prüfdatum und Verfahren für die Außerbetriebnahme

Eine Liste allein löst noch kein Problem. Entscheidend ist, dass jedes Objekt einen verantwortlichen Besitzer hat. Ein Eintrag wie „IT“ oder „Cloud-Team“ reicht nicht aus, wenn niemand bei einer Warnung entscheiden kann, ob eine Berechtigung weiterhin erforderlich ist.

Gerade bei älteren Integrationen findest du häufig Service Principals ohne klaren Zweck, Testanwendungen mit produktiven Rechten oder mehrere nahezu identische Registrierungen. Solche Funde solltest du nicht vorschnell löschen. Prüfe zunächst Anmeldeprotokolle, Abhängigkeiten und geplante Jobs. Anschließend kannst du ungenutzte Identitäten kontrolliert deaktivieren und nach einer Beobachtungsphase entfernen.

Managed Identities als Standard für Azure-Workloads einsetzen

Ein Client Secret in einer Konfigurationsdatei, einer Pipeline-Variable oder einem Skript ist ein vermeidbares Risiko. Secrets können kopiert, versehentlich eingecheckt, zu lange verwendet oder ohne Auswirkungstest rotiert werden. Wenn ein Azure-Dienst auf andere Azure-Dienste zugreifen soll, prüfe deshalb zuerst den Einsatz einer Managed Identity.

Ein praxisnahes Beispiel: Eine Azure Function soll Dateien aus einem Storage Account lesen und Ergebnisse in einer Azure SQL-Datenbank ablegen. Statt einer App-Registrierung mit Client Secret weist du der Function eine Managed Identity zu. Danach vergibst du auf Storage und Datenbank nur die jeweils benötigten Rechte für diese Identität.

Dabei gilt:

• Vergib Rollen auf möglichst enger Ebene, etwa auf einer Ressource oder Ressourcengruppe statt auf dem gesamten Abonnement.
• Nutze Rollen mit Leserechten, wenn keine Schreibrechte erforderlich sind.
• Prüfe bei Datenzugriffen, ob eine datenbezogene Rolle genügt, statt Verwaltungsrechte zu vergeben.
• Dokumentiere bei benutzerseitig zugewiesenen Managed Identities, welche Workloads sie verwenden dürfen.
• Entferne Rollenzuweisungen, bevor du eine nicht mehr benötigte Identität löschst.

Für Zugriffe aus externen Build-Systemen oder anderen Clouds kann Workload Identity Federation eine sinnvolle Alternative zu langlebigen Secrets sein. Dabei wird ein vertrauenswürdiger Token eines externen Identitätsanbieters gegen einen kurzlebigen Entra-Token ausgetauscht. Auch hier brauchst du eine präzise Vertrauenskonfiguration: Organisation, Repository, Branch oder Umgebung sollten so eng wie möglich eingeschränkt sein.

Least Privilege bei APIs, Microsoft 365 und Azure durchsetzen

Viele problematische Berechtigungen entstehen aus Bequemlichkeit. Eine Anwendung benötigt Zugriff auf eine kleine Menge von Daten, erhält aber vorsorglich weitreichende Microsoft-Graph-Berechtigungen oder eine umfangreiche Azure-Rolle. Das beschleunigt den ersten Test, vergrößert aber die Angriffsfläche dauerhaft.

Unterscheide insbesondere zwischen delegierten Berechtigungen und Anwendungsberechtigungen. Delegierte Berechtigungen arbeiten im Kontext eines angemeldeten Benutzers. Anwendungsberechtigungen erlauben der Anwendung, unabhängig von einem Benutzer zu handeln. Für Hintergrunddienste und KI-Agenten sind häufig Anwendungsberechtigungen nötig, sie verdienen deshalb besondere Prüfung.

Gehe bei jeder neuen Berechtigung in vier Schritten vor:

1. Beschreibe den konkreten Geschäftsvorgang, etwa „Rechnungen aus Postfach X lesen“.
2. Ermittle die kleinste passende API-Berechtigung oder Azure-Rolle.
3. Begrenze den Ressourcenumfang zusätzlich, wenn der Dienst dies unterstützt.
4. Teste den Vorgang mit der eingeschränkten Identität und dokumentiere das Ergebnis.

Ein KI-Agent benötigt beispielsweise nicht automatisch Zugriff auf alle SharePoint-Websites, alle Postfächer oder sämtliche Datenbanken. Lege zunächst fest, welche Wissensquellen er nutzen darf, welche Aktionen er ausführen kann und welche Daten niemals an ein Modell oder externes Tool gelangen dürfen. Für die sichere Anbindung von Agenten an Werkzeuge und Datenquellen ist auch unser Beitrag MCP-Server sicher entwickeln: KI-Agenten kontrolliert an Tools und Daten anbinden hilfreich.

Wenn du KI-Lösungen auf Azure konzipierst, gehören Identität und Berechtigung von Beginn an in die Architektur. Der Artikel Azure AI Foundry lernen: RAG-Anwendungen und KI-Agenten sicher entwickeln zeigt, warum RAG-Anwendungen nicht nur technisch, sondern auch beim Datenzugriff sauber geplant werden müssen.

Lebenszyklus verbindlich steuern

Eine sichere Workload Identity braucht einen definierten Anfang und ein definiertes Ende. Richte einen schlanken Prozess ein, der bei jeder neuen Anwendung dieselben Fragen beantwortet:

• Wer beantragt die Identität und wer übernimmt die Verantwortung?
• Welche Daten und Systeme werden benötigt?
• Welche Berechtigungen sind beantragt, wer genehmigt sie?
• Warum ist keine Managed Identity möglich?
• Welche Anmeldeinformationen werden verwendet und wann laufen sie ab?
• Wie wird die Nutzung überwacht?
• Was geschieht bei Projektende, Anbieterwechsel oder Abschaltung?

Lege für Zertifikate und Secrets rechtzeitig Erinnerungen an. Eine Rotation darf nicht erst beginnen, wenn die Anwendung bereits ausgefallen ist. Idealerweise unterstützt die Anwendung parallele Anmeldeinformationen für einen kontrollierten Wechsel: Neues Zertifikat hinterlegen, Funktion testen, altes Zertifikat widerrufen und die Änderung nachvollziehbar festhalten.

Service Principals ohne Besitzer sind ein Warnsignal. Ebenso kritisch sind Anwendungsregistrierungen, bei denen einzelne Mitarbeitende als alleinige Besitzer eingetragen sind. Hinterlege mindestens verantwortliche Rollen oder Teams und überprüfe diese Zuordnung regelmäßig. Grundsätze für wiederkehrende Prüfungen und Verantwortlichkeiten findest du auch in unserem Beitrag Microsoft Entra ID Governance einführen: Access Reviews und Joiner-Mover-Leaver automatisieren.

Anmeldungen, Änderungen und Auffälligkeiten überwachen

Die wichtigste Frage nach der Einrichtung lautet: Tut die Identität wirklich nur das, was sie soll? Nutze dafür Anmeldeprotokolle in Microsoft Entra ID, Audit-Protokolle für Änderungen an Anwendungen und Service Principals sowie die Protokolle der jeweiligen Zielressource.

Achte besonders auf diese Signale:

• Neue oder unerwartete Zertifikate und geheime Schlüssel
• Änderungen an Besitzern, Umleitungs-URIs oder Berechtigungen
• Neue administrative Einwilligungen für API-Berechtigungen
• Anmeldungen nach langer Inaktivität
• Fehlgeschlagene Anmeldungen in ungewöhnlicher Häufung
• Rollenzuweisungen mit weitreichendem Umfang
• Zugriffe auf Ressourcen, die nicht zum dokumentierten Zweck passen

Verknüpfe diese Ereignisse mit deinem bestehenden Security Monitoring. Für Teams mit Security Operations ist es sinnvoll, Regeln für Änderungen an privilegierten Anwendungen und verdächtige Dienstanmeldungen aufzubauen. Ergänzend lohnt sich der Blick auf Microsoft Sentinel und Defender XDR lernen: SIEM für den SOC-Alltag.

Bedingte Zugriffsrichtlinien können zusätzlich helfen, Risiken bei Workload Identities zu begrenzen. Prüfe jedoch genau, welche Identitätstypen, Bedingungen und Lizenzvoraussetzungen in deiner Umgebung unterstützt werden. Eine Richtlinie ersetzt keine minimalen Rechte und keine sorgfältige Bereinigung.

Mit einem kleinen Kontrollrhythmus starten

Du musst nicht zuerst jede Altanwendung perfekt erfassen. Beginne mit den Identitäten, die Zugriff auf sensible Daten, produktive Azure-Abonnements, Microsoft 365 oder KI-gestützte Prozesse haben. Prüfe diese monatlich oder in einem für deine Umgebung passenden festen Rhythmus. Danach arbeitest du dich zu weniger kritischen Integrationen vor.

Passende Seminare zu Microsoft Entra, Azure, Security und Cloud-Administration findest du bei uns auf cmt.de. Entscheidend bleibt jedoch die Umsetzung im eigenen Betrieb: Jede technische Identität braucht einen klaren Zweck, einen Verantwortlichen, überprüfbare Berechtigungen und ein geplantes Ende.