Managed Identity in Azure einfach erklärt

Eine Managed Identity, auf Deutsch verwaltete Identität, ermöglicht Azure-Ressourcen die sichere Authentifizierung gegenüber anderen Diensten. Anwendungen benötigen dafür keine dauerhaft gespeicherten Passwörter, Zertifikate oder Anwendungsschlüssel.

Azure verwaltet die zugrunde liegende Identität und stellt bei Bedarf ein zeitlich begrenztes Zugriffstoken aus. Welche Ressourcen und Funktionen die Anwendung nutzen darf, wird anschließend über Rollen und Berechtigungen geregelt.

Was ist eine Managed Identity?

Eine Managed Identity ist eine digitale Identität für eine Anwendung, einen Dienst oder eine Azure-Ressource. Sie gehört zur Gruppe der sogenannten Workload-Identitäten und wird nicht von einer natürlichen Person verwendet.

Managed Identities können beispielsweise für folgende Azure-Ressourcen aktiviert werden:

• virtuelle Maschinen
• Azure App Service
• Azure Functions
• Logic Apps
• Automation Accounts
• bestimmte Daten- und Integrationsdienste

Die Anwendung kann sich anschließend gegenüber Diensten authentifizieren, die Microsoft Entra ID unterstützen.

Wie funktioniert eine Managed Identity?

Eine Azure-Ressource erhält eine verwaltete Identität in Microsoft Entra ID. Benötigt die darauf ausgeführte Anwendung Zugriff auf einen anderen Dienst, fordert sie ein Zugriffstoken für diese Zielressource an.

Der Ablauf besteht vereinfacht aus folgenden Schritten:

1. Für die Anwendung oder Azure-Ressource wird eine Managed Identity aktiviert.
2. Die Identität erhält Berechtigungen auf der benötigten Zielressource.
3. Die Anwendung fordert ein Zugriffstoken von Azure an.
4. Das Token wird an den Zieldienst übermittelt.
5. Der Zieldienst prüft Identität und Berechtigungen.
6. Der Zugriff wird erlaubt oder abgelehnt.

Im Anwendungscode müssen dafür keine dauerhaften Zugangsdaten hinterlegt werden.

Welche Arten von Managed Identities gibt es?

Azure unterscheidet zwei grundlegende Varianten.

System-assigned Managed Identity

Eine systemseitig zugewiesene Managed Identity ist direkt mit einer bestimmten Azure-Ressource verbunden.

Wird beispielsweise eine virtuelle Maschine gelöscht, wird auch ihre Managed Identity entfernt. Diese Variante eignet sich, wenn die Identität ausschließlich von einer einzelnen Ressource benötigt wird.

Vorteile sind:

• einfache Aktivierung
• eindeutige Zuordnung zu einer Ressource
• gemeinsamer Lebenszyklus von Ressource und Identität

Wird die Ressource neu erstellt, entsteht allerdings eine neue Identität. Vorherige Berechtigungen müssen dann erneut zugewiesen werden.

User-assigned Managed Identity

Eine benutzerseitig zugewiesene Managed Identity wird als eigenständige Azure-Ressource angelegt.

Sie kann mehreren unterstützten Azure-Ressourcen zugewiesen werden und bleibt bestehen, wenn eine davon gelöscht wird.

Diese Variante eignet sich beispielsweise für:

• mehrere Anwendungen mit denselben Berechtigungen
• wiederkehrende Bereitstellungen
• automatisierte Infrastruktur
• getrennte Lebenszyklen von Anwendung und Identität
• Umgebungen mit austauschbaren Rechenressourcen

Gemeinsam verwendete Identitäten können die Verwaltung vereinfachen. Sie erschweren jedoch unter Umständen die Zuordnung einzelner Aktivitäten zu einer bestimmten Anwendung.

Managed Identity und RBAC

Die Managed Identity weist nach, wer auf eine Ressource zugreifen möchte. Sie bestimmt jedoch nicht automatisch, was erlaubt ist.

Die Berechtigungen werden häufig über Azure Role-Based Access Control, kurz Azure RBAC, vergeben.

Eine Identität kann beispielsweise folgende Rollen erhalten:

• Leserechte auf einen Storage Account
• Zugriff auf bestimmte Key-Vault-Inhalte
• Schreibrechte auf eine Datenressource
• Berechtigungen zur Verwaltung ausgewählter Azure-Ressourcen

Einige Dienste verwenden zusätzlich eigene Berechtigungsmodelle. Deshalb muss für jede Zielressource geprüft werden, welche Form der Autorisierung unterstützt wird.

Unterschied zwischen Managed Identity und Service Principal

Ein Service Principal ist eine Identität, die eine Anwendung in einem Microsoft-Entra-Mandanten repräsentiert. Für klassische Service Principals müssen häufig Zertifikate, Secrets oder föderierte Anmeldedaten eingerichtet werden.

Eine Managed Identity ist technisch eine besondere Art von Service Principal, deren Zugangsdaten von Azure verwaltet werden.

Dadurch entfällt insbesondere:

• das Speichern von Secrets
• die manuelle Rotation von Anwendungsschlüsseln
• die Verteilung von Zugangsdaten an Anwendungen
• die Überwachung ablaufender Kennwörter oder Zertifikate

Managed Identities sind jedoch an unterstützte Azure-Szenarien gebunden. Für Anwendungen außerhalb von Azure kann beispielsweise Workload Identity Federation geeigneter sein.

Typische Anwendungsfälle

Managed Identities werden häufig für die Kommunikation zwischen Azure-Diensten eingesetzt.

Beispiele sind:

• Eine Azure Function liest ein Zertifikat aus Azure Key Vault.
• Ein App Service greift auf Daten in Azure Storage zu.
• Eine virtuelle Maschine schreibt Protokolle in einen Azure-Dienst.
• Eine Logic App ruft eine geschützte Azure-Ressource auf.
• Ein Automatisierungsdienst verwaltet ausgewählte Cloud-Ressourcen.

Dabei ersetzt die Managed Identity die Zugangsdaten der aufrufenden Anwendung. Ein in Key Vault gespeichertes Datenbankpasswort bleibt beispielsweise weiterhin ein Secret – die Anwendung benötigt jedoch kein zusätzliches Secret, um auf den Key Vault zuzugreifen.

Managed Identity in Kubernetes und CI/CD

Für Anwendungen in Azure Kubernetes Service wird in der Regel Microsoft Entra Workload ID verwendet. Dabei wird ein Kubernetes-Servicekonto über eine föderierte Vertrauensstellung mit einer Identität in Microsoft Entra ID verbunden.

Auch bei extern betriebenen CI/CD-Plattformen wie GitHub Actions ist Workload Identity Federation häufig geeigneter als ein gespeichertes Client Secret.

Eine Managed Identity kann direkt genutzt werden, wenn der Build-Agent oder die Automatisierung auf einer unterstützten Azure-Ressource ausgeführt wird.

Welche Vorteile bieten Managed Identities?

Zu den wichtigsten Vorteilen gehören:

• keine dauerhaften Zugangsdaten im Quellcode
• weniger Secrets in Konfigurationsdateien
• keine manuelle Rotation von Identitätsnachweisen
• einfache Integration mit Azure-Diensten
• automatisierbare Bereitstellung
• Unterstützung des Least-Privilege-Prinzips
• geringeres Risiko versehentlich veröffentlichter Schlüssel

Managed Identities unterstützen damit cloud-native und automatisierte Betriebsmodelle.

Welche Grenzen und Risiken gibt es?

Managed Identities lösen nicht alle Sicherheitsprobleme.

Zu beachten ist:

• Nicht jeder Dienst unterstützt Microsoft-Entra-Authentifizierung.
• Berechtigungen müssen weiterhin korrekt vergeben werden.
• Zu weitreichende Rollen erhöhen das Schadenspotenzial.
• Wer eine Azure-Ressource kompromittiert, kann möglicherweise deren Identität missbrauchen.
• Gemeinsam genutzte Identitäten erschweren teilweise die Nachvollziehbarkeit.
• Rollenänderungen können eine gewisse Zeit benötigen, bis sie wirksam sind.

Managed Identities sollten deshalb mit minimalen Berechtigungen, Netzwerkbeschränkungen, Protokollierung und regelmäßigen Zugriffsprüfungen kombiniert werden.

Fazit

Eine Managed Identity ermöglicht Azure-Anwendungen die Authentifizierung gegenüber anderen Diensten, ohne dauerhaft gespeicherte Passwörter, Zertifikate oder Anwendungsschlüssel zu benötigen.

Azure verwaltet die Identität und die benötigten Anmeldeinformationen. Unternehmen bleiben jedoch dafür verantwortlich, passende Rollen zu vergeben, Zugriffe zu überwachen und Berechtigungen auf das notwendige Minimum zu begrenzen.