Eine Anwendung kann in Azure auf Datenbanken, Speicher, Key Vault oder andere Dienste zugreifen, ohne dass Zugangsschlüssel im Quellcode liegen. Genau dafür wurde Azure Managed Identity entwickelt: Die von Azure verwaltete Identität übernimmt die Anmeldung gegenüber unterstützten Ressourcen, während Microsoft Entra ID, früher Azure Active Directory, die Tokens ausstellt. Ich zeige, wie das Verfahren im Hosting funktioniert, wann eine system- oder benutzerzugewiesene Identität sinnvoll ist und worauf es in DevOps-Pipelines wirklich ankommt.
Die wichtigsten Entscheidungen auf einen Blick
- Keine Secrets im Code bedeutet weniger Rotationsaufwand und eine kleinere Angriffsfläche.
- Systemzugewiesene Identitäten passen zu einzelnen, eng an eine Ressource gebundenen Anwendungen.
- Benutzerzugewiesene Identitäten lassen sich unabhängig von einer Ressource verwalten und mehrfach einsetzen.
- Die Identität allein gewährt keinen Zugriff. Entscheidend sind Azure RBAC oder die Berechtigungen des jeweiligen Zieldienstes.
- Für externe oder gehostete Build-Agenten ist meist Workload Identity Federation die passendere Lösung.
Was Azure Managed Identity im Hosting wirklich leistet
Das Grundproblem ist schnell erklärt. Eine Web-App muss ein Geheimnis aus Azure Key Vault lesen, ein Hintergrunddienst soll Dateien in Blob Storage speichern oder eine VM benötigt Zugriff auf eine Datenbank. Ohne verwaltete Identität landet dafür häufig ein Client-Secret, Zertifikat oder Storage-Key in einer Pipeline, einer Konfigurationsdatei oder einer geheimen Variable.
Bei einer verwalteten Identität erhält die Azure-Ressource ein eigenes Dienstkonto in Microsoft Entra ID. Die Anwendung fordert bei Bedarf ein kurzlebiges Zugriffstoken an und verwendet es gegenüber einem Dienst, der die Entra-Authentifizierung unterstützt. Ein fest hinterlegtes Passwort muss dabei weder erstellt noch regelmäßig ausgetauscht werden.
Wichtig ist die Trennung zwischen Authentifizierung und Autorisierung. Die Identität beweist, wer die Anwendung ist. Erst eine zugewiesene Rolle wie „Storage Blob Data Reader“ oder „Key Vault Secrets User“ entscheidet, was sie tatsächlich tun darf. Genau an dieser Stelle passieren in Projekten die meisten Fehlkonfigurationen.
Das Verfahren ist für viele Azure-Dienste verfügbar, aber nicht für jede Ressource und nicht für jede Zugriffsmethode. Ein Dienst muss Microsoft Entra-Token akzeptieren, und die Anwendung muss den passenden Datenzugriff verwenden. Ein Storage-Key wird durch eine Managed Identity nicht automatisch ersetzt, wenn der verwendete Code weiterhin ausschließlich mit Shared Keys arbeitet.
Systemzugewiesen oder benutzerzugewiesen
Azure bietet zwei Varianten. Die Wahl hängt vor allem davon ab, ob die Identität an genau eine Ressource gekoppelt sein soll oder über mehrere Instanzen hinweg dieselbe Rolle übernehmen muss.
| Merkmal | Systemzugewiesen | Benutzerzugewiesen |
|---|---|---|
| Lebenszyklus | Wird mit der Azure-Ressource erstellt und gelöscht | Unabhängig von den verbundenen Ressourcen |
| Verwendung | Eine Identität für eine Ressource | Eine Identität für mehrere Ressourcen |
| Verwaltung | Sehr einfach, wenig zusätzlicher Bestand | Mehr Kontrolle, aber eigener Lebenszyklus |
| Typischer Einsatz | Einzelne App Service-App oder VM | Mehrere App-Instanzen, Container oder getrennte Umgebungen |
Wann die systemzugewiesene Variante reicht
Für eine einzelne produktive Web-App ist sie oft die pragmatischste Wahl. Wird die App gelöscht, verschwindet auch ihre Identität samt Berechtigungsbeziehungen. Das verhindert, dass verwaiste Dienstkonten jahrelang Zugriff auf Ressourcen behalten.
Ich verwende diese Variante gern bei kleinen bis mittleren Deployments, bei denen die Anwendung und ihre Identität bewusst eins zu eins gekoppelt sind. Für eine isolierte App Service-App, Function App oder VM entsteht dadurch kaum zusätzlicher Verwaltungsaufwand.
Wann eine benutzerzugewiesene Identität besser passt
Eine benutzerzugewiesene Identität wird als eigene Azure-Ressource angelegt und anschließend mehreren Anwendungen zugewiesen. Das ist besonders nützlich, wenn mehrere Instanzen dieselben Berechtigungen brauchen oder eine Identität beim Austausch einer App- oder Container-Instanz erhalten bleiben soll.
Der Preis für diese Flexibilität ist ein zusätzlicher Lebenszyklus. Wird eine benutzerzugewiesene Identität nicht mehr benötigt, muss sie ausdrücklich entfernt werden. Außerdem darf ihre Reichweite nicht unbemerkt wachsen, nur weil immer mehr Ressourcen an sie gekoppelt werden.
Für viele wiederverwendbare Hosting- und Plattformmuster ist die benutzerzugewiesene Variante die sauberere Architektur. Für eine einzelne Anwendung ohne besondere Skalierungs- oder Austauschlogik bleibt die systemzugewiesene Identität meist übersichtlicher.
So gelangt die Anwendung sicher an ihre Ressourcen
Der technische Ablauf besteht aus vier klaren Schritten. Die Anwendung läuft auf einer Azure-Ressource mit aktivierter Identität, fordert ein Token für den gewünschten Dienst an, Microsoft Entra ID prüft die Identität und der Zieldienst entscheidet anhand der zugewiesenen Berechtigungen über den Zugriff.
- Identität aktivieren, etwa für eine App Service-App.
- Rolle am Zielsystem vergeben, zum Beispiel Leserechte auf einem Storage-Konto.
- Im Code einen Entra-fähigen Client oder ein passendes SDK verwenden.
- Den Zugriff mit einer minimalen Berechtigung testen und protokollieren.
Eine typische Einrichtung für eine Web-App kann mit Azure CLI so aussehen:
az webapp identity assign \
--resource-group rg-produktiv \
--name meine-webapp
az role assignment create \
--assignee-object-id \
--assignee-principal-type ServicePrincipal \
--role "Key Vault Secrets User" \
--scope /subscriptions//resourceGroups/rg-produktiv/providers/Microsoft.KeyVault/vaults/kv-produktiv Die konkrete Rolle hängt vom Dienst und vom Zugriff ab. Für Blob Storage ist beispielsweise eine Datenebenenrolle erforderlich. Eine allgemeine Rolle wie Contributor auf Ressourcengruppenebene ist dafür meistens viel zu weit gefasst und sollte nicht als bequeme Abkürzung verwendet werden.
Beispiel mit einem Azure-SDK
In modernen Anwendungen ist eine Default-Credential-Kette praktisch, weil sie lokal mit einer Entwickleranmeldung und in Azure automatisch mit der verwalteten Identität arbeiten kann. Ein vereinfachtes .NET-Beispiel für Key Vault sieht so aus:
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
var credential = new DefaultAzureCredential();
var client = new SecretClient(
new Uri("https://kv-produktiv.vault.azure.net/"),
credential);
KeyVaultSecret secret = await client.GetSecretAsync("Datenbankpasswort");Im lokalen Umfeld sollte die Entwickleridentität nur auf eine Testumgebung zugreifen. In Azure übernimmt die Plattform die Identität. Dadurch bleibt derselbe Anwendungscode verwendbar, während keine Produktionsgeheimnisse in Konfigurationsdateien wandern.
Bei App Service, Functions und Container Apps lohnt es sich außerdem, die Identität explizit auszuwählen, wenn mehrere Identitäten an derselben Ressource hängen. Sonst kann der Code zwar erfolgreich ein Token beziehen, aber für die falsche Identität.
Managed Identities in DevOps und CI/CD
Im Hosting läuft die Anwendung selbst in Azure. In einer Pipeline ist die Situation anders: Der Build-Agent muss sich zunächst gegenüber Azure anmelden, um Ressourcen bereitzustellen oder ein Deployment auszuführen. Ein Azure DevOps-Agent auf einer Azure-VM kann eine verwaltete Identität nutzen, ein Microsoft-hosted Agent besitzt dagegen nicht automatisch die Identität Ihrer Subscription.
Für Azure DevOps ist deshalb Workload Identity Federation oft die bessere Wahl. Dabei vertraut Azure auf ein kurzlebiges OIDC-Token der Pipeline. Es gibt kein dauerhaftes Client-Secret und keinen Personal Access Token, der in Variablen oder Service Connections gepflegt werden muss.
Ein sinnvolles Setup sieht so aus:
- Eine benutzerzugewiesene Identität oder eine Entra-Anwendung für die Pipeline anlegen.
- In Azure DevOps eine Azure Resource Manager Service Connection mit föderierten Anmeldedaten konfigurieren.
- Nur die notwendigen Rollen für die Zielressourcen vergeben.
- Deployment und Rollback mit einer Testressourcengruppe prüfen.
- Die Service Connection auf bestimmte Pipelines und Projekte beschränken.
Die Pipeline sollte nicht pauschal über die gesamte Subscription schreiben dürfen, wenn sie nur eine App Service-App aktualisiert. Für getrennte Umgebungen verwende ich bevorzugt separate Identitäten für Entwicklung, Staging und Produktion. So wird ein Fehler in einer Testpipeline nicht automatisch zu einem Produktionsrisiko.
Ein häufiger Irrtum besteht darin, die Managed Identity der laufenden Anwendung für den gesamten Deployment-Prozess zu verwenden. Das vermischt zwei Verantwortlichkeiten. Die Runtime-Identität liest beispielsweise Secrets oder schreibt Logs, während die Deployment-Identität Infrastruktur ändern darf. Diese Rollen sollten getrennt bleiben.
Sicherheitsregeln und typische Fehler
Der größte Sicherheitsgewinn entsteht nicht allein durch das Weglassen von Secrets. Entscheidend ist, welche Berechtigungen die Identität bekommt und wer diese Identität an eine Ressource anhängen darf. Wer eine stark privilegierte Identität an eine ausnutzbare Web-App bindet, verlagert das Risiko nur an eine andere Stelle.
Least Privilege konsequent umsetzen
Vergebe immer die kleinste passende Rolle auf der kleinsten sinnvollen Ebene. Eine App, die ein Secret aus Key Vault lesen muss, benötigt keine Schreibrechte auf dem Tresor. Ein Dienst, der Blob-Dateien nur auflistet, sollte nicht automatisch Dateien löschen oder neue Container anlegen dürfen.
Besonders kritisch ist die Berechtigung, eine Identität anderen Azure-Ressourcen zuzuweisen. Wer diese Möglichkeit besitzt, kann unter Umständen eine privilegierte Identität an eine eigene Ressource hängen und deren Rechte indirekt nutzen. Diese „Identity Assignment“-Berechtigung gehört deshalb nur in die Hände von Plattform- oder Deployment-Administratoren.
Lesen Sie auch: IP-Adresse verstehen - IPv4, IPv6 und private Netze
Die häufigsten Ursachen für Fehler
- Keine Rolle am Zielsystem wurde vergeben oder sie gilt für die falsche Ressource.
- Die Anwendung nutzt weiterhin einen Storage-Key, obwohl Entra-Zugriff konfiguriert wurde.
- Bei einer benutzerzugewiesenen Identität wird im Code die falsche Client-ID verwendet.
- Der Zielservice unterstützt die gewünschte Entra-Authentifizierung nicht oder verlangt zusätzlich eine lokale Konfiguration.
- Die Änderung der Berechtigungen ist noch nicht überall wirksam.
Nach einer Rollenänderung kann die Auswertung verzögert reagieren. In einzelnen Azure-Szenarien sind Wartezeiten von bis zu rund 24 Stunden dokumentiert, besonders wenn Berechtigungen über Gruppen oder Rollenmitgliedschaften wirken. Für Tests sollte daher nicht nur sofort nach dem Speichern geprüft werden, sondern auch mit einem frischen Token und einer klaren Warte- beziehungsweise Rollback-Strategie.
Für die Fehlersuche prüfe ich zuerst die Identität der laufenden Ressource, danach die zugewiesene Rolle und erst dann Netzwerkregeln oder SDK-Code. Diese Reihenfolge spart Zeit, weil ein fehlendes „Reader“- oder „Secrets User“-Recht wesentlich häufiger die Ursache ist als ein defekter Token-Endpunkt.
Wann die Lösung passt und wann eine Alternative sinnvoller ist
Verwaltete Identitäten sind besonders stark, wenn eine Anwendung innerhalb von Azure läuft und auf Azure-Dienste mit Entra-Unterstützung zugreift. Sie reduzieren Geheimnisse, vereinfachen Rotation und passen gut zu App Service, Functions, VMs, Container Apps und vielen Plattformdiensten.
Sie sind aber kein universeller Ersatz für jede Form der Maschinenanmeldung. Ein externer Server, ein lokaler Kubernetes-Cluster oder ein GitHub-Workflow läuft nicht automatisch unter einer Azure-Ressourcenidentität. In solchen Fällen kommen Workload Identity Federation, eine passende Service Connection oder ein sorgfältig verwalteter Service Principal infrage.
| Szenario | Passender Ansatz | Warum |
|---|---|---|
| App Service greift auf Key Vault zu | Managed Identity | Azure kann die Identität direkt an die App binden |
| Azure-VM ruft Storage-Daten ab | Managed Identity | Kein Storage-Key im Betriebssystem oder Code nötig |
| Microsoft-hosted Azure-DevOps-Agent | Workload Identity Federation | Der Agent besitzt keine eigene Identität in Ihrer Subscription |
| On-Premises-Server ohne Azure-Laufzeit | Federation oder Service Principal | Die Ressource kann keine Azure Managed Identity bereitstellen |
Die Identität selbst verursacht normalerweise keine separaten Zusatzkosten. Kosten entstehen durch die genutzten Azure-Dienste, etwa Key Vault, Storage, Datenbanken, Netzwerk oder Log Analytics. Für die Architekturentscheidung ist daher nicht der Preis der Identität ausschlaggebend, sondern die Unterstützung des Zieldienstes und die Qualität des Berechtigungsmodells.
Eine belastbare Regel für die nächste Azure-Architektur
Ich würde bei jeder neuen Azure-Anwendung zuerst prüfen, ob sie ohne dauerhaftes Secret auskommt. Wenn die Anwendung in Azure läuft, der Zielservice Entra-Authentifizierung unterstützt und die Berechtigungen sauber begrenzt werden können, ist eine verwaltete Identität meistens der vernünftige Standard.
Für eine einzelne Ressource genügt oft die systemzugewiesene Variante. Sobald mehrere Anwendungen dieselbe Berechtigungslogik benötigen oder unabhängig voneinander ersetzt werden sollen, bietet sich eine benutzerzugewiesene Identität an. In CI/CD-Pipelines sollte die Laufzeitidentität von der Deployment-Identität getrennt und bei externen Agents möglichst eine föderierte, kurzlebige Anmeldung verwendet werden.
Der wichtigste Praxistest lautet deshalb nicht „Funktioniert der Login?“, sondern „Kann diese Identität genau das tun, was sie muss, und nichts darüber hinaus?“. Wer diese Frage bei jeder Rollenvergabe beantwortet, bekommt ein sichereres Hosting, weniger Secret-Rotation und eine deutlich wartbarere DevOps-Umgebung.
