Azures verborgene Operatoren: Ein Bedrohungsmodell für verwaltete Identitäten auf Plattformebene

In diesem Beitrag werden wir einen Azure-Identitätstyp untersuchen, benennen, definieren und einem Bedrohungsmodell unterziehen, der still und leise in jedem Kunden-Tenant im Hintergrund läuft – nie unter einem einzigen Namen dokumentiert, nie in Ihrem Besitz und für Sie nie vollständig sichtbar. Falls jemand aus dem Azure-Team den offiziellen Begriff für diese Identitäten klarstellen möchte, stehe ich gerne per Direktnachricht zur Verfügung.

Einführung

Wenn Sicherheitsteams über verwaltete Identitäten in Azure nachdenken, denken sie an diejenigen, die sie selbst erstellen: eine vom System zugewiesene Identität auf einer virtuellen Maschine oder eine benutzerdefinierte verwaltete Identität, die einem App Service zugeordnet ist. Diese werden vom Kunden verwaltet – Sie erstellen sie, benennen sie, weisen ihnen Rollen zu und löschen sie.

Es gibt jedoch noch eine weitere Kategorie von verwalteten Identitäten, die Sie nicht erstellt haben, in Ihrem Portal nicht sehen können und über die Sie keine Kontrolle haben. Dabei handelt es sich um Identitäten, die Azure selbst erstellt, um die Plattform in Ihrem Auftrag zu betreiben.

Ich nenne diese „Platform-Level Managed Identities“ (PLMIs).

Was sie sind

Von der Plattform verwaltete Identitäten sind Identitäten, die von Azure verwaltet werden. Sie verwenden denselben Token-Pfad, dieselben Metadaten-Endpunkte und dasselbe RBAC-Modell wie alle anderen verwalteten Identitäten, doch unterscheiden sich ihre Eigentumsverhältnisse und ihr Lebenszyklus grundlegend von den systemzugewiesenen oder benutzerzugewiesenen verwalteten Identitäten, an die wir alle gewöhnt sind:

Diese Identitäten werden Azure-Ressourcenanbietern zugewiesen, also den Backend-Diensten, aus denen Azure besteht. Wenn Sie beispielsweise eine API-Verbindung oder eine Logik-App bereitstellen, ist es die Identität auf Plattformebene, die im Hintergrund arbeitet und in Ihrem Namen Aktionen ausführt, um die Funktionalität des Dienstes zu gewährleisten.

Das Problem der Namensgebung

Es gibt keinen einheitlichen, öffentlich verwendeten Begriff für diese Identitäten. In der Dokumentation des gesamten Microsoft-Ökosystems wurden sie jedoch unterschiedlich bezeichnet:

• Plattformidentitäten oder Plattform-MSIs – ein Sammelbegriff, der intern für Identitäten verwendet wird, die Azure selbst gehören
• Identitäten von Ressourcenanbietern – z. B. die von Microsoft.ApiManagement oder Microsoft.Logic verwendete Identität
• Eigenverwaltete Identitäten
• Dienstidentitäten oder Dienst-MSIs – ein Oberbegriff für Identitäten, die von Azure-Diensten verwendet werden
• „Backend-Identität“ oder „Backend-Prinzipal“ – in internen Tools verwendete Terminologie
• Intern verwaltete Identitäten (Internal MSI)

⚠️ Was sie NICHT sind: Auf Plattformebene verwaltete Identitäten sollten nicht mit First-Party-Service-Principals (auch als Microsoft First-Party-Anwendungen oder FPSPs bezeichnet) verwechselt werden. FPSPs sind die Identitäten, die ich im Whitepaper „Vergleich von CSP-verwalteten Maschinenidentitäten“ – diese befinden sich in Entra ID als Unternehmensanwendungen (z. B. SharePoint Online, Microsoft Teams) und sind in Ihrem Mandanten sichtbar. Verwaltete Identitäten auf Plattformebene sind eine völlig separate Kategorie.

Wenn Sie bei Azure arbeiten und eine eindeutige Antwort darauf haben, wie diese Begriffe lauten sollten, melden Sie sich bitte bei uns. 

Wie man einen erkennt

Da plattformverwaltete Identitäten (PLMI) im Microsoft-Mandanten und nicht in Ihrem eigenen Mandanten liegen, sehen Sie lediglich einen RBAC-Protokolleintrag, der darauf hinweist, dass der Prinzipal von außerhalb Ihres Mandanten stammt. Der folgende Protokolleintrag ist ein Beispiel aus einem Azure-Mandanten, das eine PLMI in Aktion zeigt (mit unkenntlich gemachten identifizierbaren Informationen):

An object ID that returns no result when you run az ad sp show --id <objectId> is a strong indicator that you are looking at a Platform-Level Managed Identity.

Wesentliche architektonische Merkmale

Ein kurzer Überblick über diese Architektur:

• Interner Microsoft-Mandant: Die MI auf Plattformebene befindet sich in Microsofts eigenem internen Mandanten.
• Kundenmandant: Der Kunde verwaltet die nachgelagerten Ressourcen (z. B. Key Vault, Speicher).
• Vom Kunden zugewiesene RBAC: Entscheidend ist, dass im Gegensatz zu den entsprechenden Funktionen bei AWS und GCP die RBAC-Berechtigung, die dem PLMI den Zugriff auf die Ressource ermöglicht, vom Kunden innerhalb seines eigenen Mandanten zugewiesen wird.
• Mandantenübergreifender Zugriff: Das PLMI nutzt diese vom Kunden zugewiesenen Berechtigungen, um mandantenübergreifende Aktionen durchzuführen.

Zwei wesentliche Merkmale unterscheiden diese von kundenverwalteten Identitäten:

1. Mandantenfähigkeit: Eine einzige, auf Plattformebene verwaltete Identität für einen bestimmten Ressourcenanbieter wird für den Betrieb über alle Kundenmandanten hinweg verwendet. Es handelt sich um einen globalen Akteur, nicht um einen kundenbezogenen.
2. Vollständig von CSP verwaltet: Die Identität selbst befindet sich in der Microsoft-eigenen Umgebung. Kunden können sie nicht direkt bearbeiten, einschränken oder auch nur auflisten.

Hier liegt der grundlegende Widerspruch: Diese Identitäten sind hochprivilegierte globale Akteure. Da sie außerhalb Ihres Umfelds existieren, besteht die einzige direkte Kontrolle, die Sie über sie haben, in den RBAC-Berechtigungen, die Sie ihnen zuweisen. Wie wir jedoch noch sehen werden, sind diese Zuweisungen in der Regel erforderlich, um PaaS-Funktionalitäten zu ermöglichen. Die einzige Möglichkeit, sich dem zu entziehen, besteht oft schlichtweg darin, einen Dienst gar nicht erst zu nutzen.

Was kann schiefgehen?

Die oben beschriebene Architektur führt zu einer bestimmten Art von Sicherheitslücke: einem „Cross-Tenant Confused Deputy“.

Ein „Confused Deputy Attack“ liegt vor, wenn ein mächtiger Vermittler – ein Dienst oder Prozess, der im Namen mehrerer Auftraggeber handelt – dazu verleitet wird, seine eigenen Berechtigungen zu nutzen, um eine Aktion im Namen einer nicht autorisierten Partei auszuführen. Ist der Vermittler mandantenfähig, erstreckt sich die Tragweite dieser Verwirrung über Organisationsgrenzen hinweg.

Fallstudie: Die Binary Security API – Eine Untersuchung der Verbindungen

Im März 2025 veröffentlichten Forscher von Binary Security Erkenntnisse, die das konkreteste öffentlich dokumentierte Beispiel für den Missbrauch einer auf Plattformebene verwalteten Identität als „Confused Deputy“ darstellen.

Hintergrund: Was sind API-Verbindungen?

API-Verbindungen sind Azure-Ressourcen, die häufig automatisch erstellt werden, wenn Sie einer Logic App eine Aktion hinzufügen. Wenn Sie eine Logic App so konfigurieren, dass sie eine Aktion für Sie ausführt, beispielsweise das Abrufen eines Geheimnisses aus einem Key Vault, wird in Ihrem Abonnement eine API-Verbindungsressource erstellt, die den Authentifizierungskontext für diesen Backend-Dienst speichert. Die API-Verbindung ist es, die die Berechtigung für den Zugriff auf Ihren Key Vault enthält – und nutzt.

Hinter den Kulissen wird diese API-Verbindung von einer auf Plattformebene verwalteten Identität betrieben, die zum Microsoft.Web-Ressourcenanbieter gehört. Als die Verbindung von demjenigen autorisiert wurde, der die Logic App eingerichtet hat, erforderte diese Autorisierung eine RBAC-Berechtigung für diese Identität auf Plattformebene für die Backend-Ressource.

Die Schwachstelle

Zwar schien es sinnvoll, dass die Administration RBAC-Berechtigungen für das Microsoft.Web-PLMI erteilen musste, doch entdeckte Binary Security eine Path-Traversal-Sicherheitslücke im endpoint/extensions/proxy/{action} des APIM-Dienstes. Diese Schwachstelle ermöglichte es jedem, der über „Reader“-Zugriff auf das Abonnement verfügte, diesen Deputy zu nutzen, um auf die KeyVault-Geheimnisse, die SQL-Instanz oder die externen Verbindungen BELIEBIGER Mandanten zuzugreifen – ganz gleich, wofür der Zugriff in Microsoft.Web konfiguriert war.

Was einem Angreifer in die Hände fiel:

Backend-Ressource

Zugriff über API-Verbindungs-Proxy

Azure Key Vault

Alle Geheimnisse auflisten; Geheimniswerte abrufen

Azure SQL-Datenbank

Datenbanken, Datensätze und Tabellen auflisten; Tabellenzeilen lesen

Jira

Projekte, Benutzer und Probleme auflisten; Problemdetails anzeigen

Salesforce

Kundendaten, Kontaktdaten

Azure Defender ATP

Warnmeldungen, Vorfälle und Untersuchungsdaten

Azure-Speicher-Blobs

Inhalt des Blobs

Im Jira-Beispiel entdeckte Binary Security zudem eine SSRF-Schwachstelle: Der Header „X-Request-Jirainstance“ wurde nicht validiert, sodass ein Angreifer Anfragen auf einen von ihm kontrollierten Server umleiten und das in der Verbindung gespeicherte Jira-API-Token abgreifen konnte.

Das Angriffsmuster

Hier ist eine Übersicht über den Ablauf des Angriffs:

• Schritt 1: Ein Angreifer (der lediglich über Lesezugriff auf das Abonnement des Opfers verfügt) sendet eine GET-Anfrage an den endpoint der Verbindung und nutzt dabei eine Path-Traversal-Nutzlast („../../../“), um den vorgesehenen API-Gültigkeitsbereich zu umgehen.
• Schritt 2: Azure Resource Manager (ARM) prüft, ob der Angreifer über Leserechte verfügt. Da es sich um eine GET-Anfrage handelt, gibt ARM die Antwort „✅ Ja – wird fortgesetzt“.
• Schritt 3: ARM leitet den Aufruf an die MI auf Plattformebene weiter, um die Backend-API aufzurufen.
• Schritt 4: Die MI auf Plattformebene überprüft ihre eigenen RBAC-Berechtigungen für den Key Vault. Da ihr bei der Verbindungsherstellung Zugriff gewährt wurde, fährt sie fort.
• Schritt 5: Der MI auf Plattformebene ruft das Geheimnis aus dem Key Vault ab und gibt es an ARM zurück, das es an den Angreifer weiterleitet.

‍

Warum dies ein mandantenübergreifender verwirrter Stellvertreter ist

Während der obige Ablauf zeigt, wie es als „verwirrter Stellvertreter“ fungiert, liegt die eigentliche Schwere der Sicherheitslücke in ihren mandantenübergreifenden Auswirkungen. Da die PLMI ein globaler Akteur ist, endpoint ein Angreifer in einem völlig anderen Mandanten, der einen exponierten endpoint entdeckt, die Berechtigungen der PLMI nutzen, um Mandantengrenzen zu überschreiten. Der „Confused Deputy“ – die auf Plattformebene verwaltete Identität – verfügte über legitime Berechtigungen für mehrere Kunden. Er wurde dazu verleitet, diese Berechtigungen im Namen einer nicht autorisierten Partei aus einem anderen Mandanten auszuüben, wodurch es sich um ein mandantenübergreifendes Problem handelte und nicht nur um eine lokale Privilegienerweiterung.

Was unternehmen wir dagegen?

Im Gegensatz zu AWS – wo Kunden sowohl die Möglichkeit als auch die Verantwortung haben, Bedingungsschlüssel zu Ressourcenrichtlinien hinzuzufügen, um „Confused-Deputy“-Angriffe einzudämmen – haben Azure-Kunden keine Kontrolle über mandantenübergreifende Auswirkungen. Sie haben jedoch Kontrolle über „Confused-Deputy“-Risiken innerhalb eines Mandanten, da RBAC-Berechtigungen für PLMIs nicht automatisch zugewiesen werden; ein Administrator muss sie zuweisen. Aber wenn man kritisch darüber nachdenkt: Wie gut ist eine Kontrollmaßnahme, wenn man, um sie zu nutzen (indem man keine RBAC-Berechtigung zuweist), einfach die Servicefunktionalität nicht nutzen darf? Darüber hinaus liegt die Verantwortung für echte mandantenübergreifende Schutzmaßnahmen vollständig bei Microsoft.

Dies entspricht dem Muster, das bei Google Cloud Agents zu beobachten ist: Da der Anbieter die Identität kontrolliert, muss er auch die Verantwortung für die Sicherheit ihrer Nutzung tragen. Das Fehlen einer kundenseitigen Kontrollmöglichkeit ist kein Mangel an Werkzeugen – vielmehr übernimmt der Anbieter damit die Verantwortung für die Sicherheit.

Maßnahme 1: Durchsetzung der Service-Level-Pfade (auf Anbieterseite)

Speziell im Fall des API-Managements bestand die vorgesehene Abhilfemaßnahme in einem Swagger-/OpenAPI-Dokument, das einschränkte, welche Pfade über den API-Connection-Proxy aufgerufen werden durften. Die Plattformidentität rief nur Backend-Pfade auf, die im Swagger-Dokument als gültig deklariert waren.

Dies ist im Prinzip eine Sicherheitsmaßnahme: Die Aktionen, an die der PLMI gerichtet werden kann, werden eingeschränkt, unabhängig davon, wer die Anfrage stellt.

Das Problem: Binary Security stellte fest, dass diese Swagger-Validierung anfällig für Path-Traversal war. Durch Manipulation des Pfads konnte ein Angreifer den festgelegten Bereich umgehen und beliebige Backend-Endpunkte erreichen. Microsoft behob diesen Fehler stillschweigend – die Kunden wurden unwissentlich durch einen Patch geschützt, von dem sie nicht einmal wussten, dass er nötig war.

Grundsätzlich ist diese Art der Durchsetzung auf Pfadebene nicht auf alle Azure-Dienste anwendbar. Es handelt sich um eine Steuerung, die spezifisch für die Art und Weise ist, wie der APIM-Dienst API-Verbindungsanfragen verarbeitet. Andere Ressourcenanbieter, die verwaltete Identitäten auf Plattformebene verwenden, verfügen nicht über entsprechende Steuerungsmöglichkeiten.

Abhilfemaßnahme 2: RBAC-Autorisierung bei der Verbindungsherstellung (in der Verantwortung des Kunden)

Die zweite Schutzmaßnahme liegt – wenn auch nur indirekt – im Einflussbereich des Kunden: der Genehmigungsschritt beim Erstellen einer API-Verbindung.

Wenn ein Logic App-Entwickler eine API-Verbindung zu einem Key Vault erstellt, muss er (oder eine Person mit entsprechenden Zugriffsrechten) die Verbindung autorisieren. Dieser Autorisierungsschritt führt zu einer RBAC-Berechtigung für die verwaltete Identität auf Plattformebene für die Backend-Ressource.

Dies ist der einzige relevante Kontrollpunkt im Ablauf:

Diese Genehmigungsstufe ist zwar wichtig, aber nicht in dem Maße, wie Microsoft vielleicht annimmt. Wenn Sie diese Schutzmaßnahme nutzen (indem Sie keine RBAC-Berechtigungen zuweisen), entscheiden Sie sich faktisch dafür, den Dienst nicht zu nutzen. Sicher, im strengsten Sinne ist es eine Abhilfemaßnahme (haben Sie anfälligen Code? Löschen Sie die App!). Sich jedoch ausschließlich darauf zu verlassen, bedeutet, dass es keine kundenseitigen Kontrollen gibt, um zu verhindern, dass ein böswilliger Mandant über eine global gültige PLMI auf Ihre Ressourcen zugreift, sobald diese Berechtigungen zur Aktivierung der PaaS-Funktionalität erteilt wurden.

Maßnahme 3: Verlinkung per Referenz (auf der Anbieterseite)

Azure verfügt über eine zusätzliche Überprüfung der Steuerungsebene, die als „Link by Reference“-Kontrolle fungiert. Diese Kontrolle mindert den Missbrauch von PLMI in gewissem Maße, indem sie sicherstellt, dass ein Aufrufer, der während einer ARM-Bereitstellung auf eine nachgelagerte Ressource verweist, tatsächlich über entsprechende Berechtigungen für diese Ressource verfügt.

Wenn Sie beispielsweise versuchen, eine Azure Monitor-Einstellung für die automatische Skalierung zu erstellen, die auf ein Virtual Machine Scale Set (VMSS) abzielt, überprüft ARM, ob Sie über die Berechtigung „Microsoft.Compute/virtualMachineScaleSets/Write“ für das VMSS verfügen. Ist dies nicht der Fall, schlägt die Bereitstellung mit dem Fehler „LinkedAuthorizationFailed“ fehl, noch bevor die Plattformidentität überhaupt zum Einsatz kommt.

Warum war diese Schutzmaßnahme im API Management-/Logic Apps-Dienst nicht vorhanden? Weil die Steuerung „Link by Reference“ in der Regel von Azure Resource Manager (ARM) bei der Erstellung oder Aktualisierung einer Ressource auf der Steuerungsebene erzwungen wird. Die APIM-Sicherheitslücke betraf einen endpoint des Datenebenen-Proxys endpoint /extensions/proxy/{action}), der eine Zielressourcen-URI dynamisch akzeptierte und die Anfrage sofort weiterleitete. Da der endpoint außerhalb des standardmäßigen ARM-Ressourcenerstellungsablaufs endpoint und keine eigenständige Überprüfung der verknüpften Ressource für den weitergeleiteten Pfad durchführte, wurde die Plattformidentität aufgerufen, ohne die Berechtigung des Aufrufers auf der Zielseite zu validieren.

Fehlende Kundensteuerelemente

Die entscheidende Kontrollmaßnahme, die Azure bei „Platform-Level Managed Identities“ fehlt, ist jede Form einer präventiven Kontrolle auf Kundenseite, um Probleme mit „Confused Deputy“-Szenarien zwischen Mandanten zu verhindern. AWS verfügt über eine solche Kontrolle durch Bedingungsschlüssel in Ressourcenrichtlinien, und Google Cloud dieses Problem dadurch gemindert, dass es überhaupt keine globalen Dienstidentitäten gibt. Was Microsoft übersehen hat, ist, dass globale Akteure mit weitreichenden Berechtigungen von Natur aus die Möglichkeit haben, Ressourcen über Organisationsgrenzen hinweg zu missbrauchen. In solchen Szenarien müssen cloud präventive Kontrollen direkt in die Hände ihrer Kunden legen und ihnen die Gewissheit geben, dass sie solche Missbräuche – den ultimativen Vertrauensbruch gegenüber ihren Kunden – wirksam verhindern können.

Die in diesem Beitrag dargelegten Forschungsergebnisse stützen sich auf die Veröffentlichung zu „Binary Security API Connections“ (März 2025), dem Whitepaper „Comparing CSP-Managed Machine Identities“ (Vectra AI, Oktober 2025) sowie auf eigene Forschungsergebnisse, die auf der RSA Conference 2026 vorgestellt wurden.

📣 Eine Anmerkung an das Azure-Team: Falls ihr auf eine verbindliche Dokumentation zu verwalteten Identitäten auf Plattformebene verweisen könnt – einschließlich der kanonischen Namensgebung oder der Richtlinienkontrolloberfläche –, würde ich mich sehr über eine Korrektur freuen.

‍