Verwaltete Identität für kennwortlose Authentifizierung

Traditionell verbinden sich Anwendungen mit Azure-Diensten wie Storage oder Key Vault über Verbindungszeichenfolgen oder API-Schlüssel, die in Konfigurationsdateien oder Umgebungsvariablen gespeichert werden. Diese Anmeldeinformationen können versehentlich in die Quellcodeverwaltung übernommen, in Protokollen offengelegt oder bei einem Sicherheitsvorfall gestohlen werden. Managed Identity macht es überflüssig, dass Anwendungen überhaupt Anmeldeinformationen speichern. Stattdessen stellt Azure selbst im Namen der Ressource ein Token aus und erneuert es, während die Anwendung Azure zur Laufzeit einfach nach dem aktuellen Token fragt.

Eine Managed Identity ist ein automatisch verwalteter service principal in Microsoft Entra ID, der mit einer Azure-Ressource (z. B. einer VM, einem App Service oder einer Function App) verknüpft ist. Die Azure-Plattform erstellt und verwaltet die Anmeldeinformationen der Identität und erneuert sie regelmäßig, sodass Ihr Code niemals ein Kennwort oder Geheimnis verarbeitet. Anwendungen, die auf der Ressource ausgeführt werden, rufen den Endpunkt des Azure Instance Metadata Service (IMDS) unter http://169.254.169.254 auf, um ein kurzlebiges OAuth-Token zu erhalten, das sie anschließend bei Azure-Diensten vorlegen.

Es gibt zwei Arten verwalteter Identitäten: System-assigned ist an eine einzelne Azure-Ressource gebunden. Sie wird erstellt, wenn Sie sie für die Ressource aktivieren, und automatisch gelöscht, wenn die Ressource gelöscht wird. User-assigned ist eine unabhängige Entra ID-Identität, die Sie separat erstellen und anschließend einer oder mehreren Azure-Ressourcen zuordnen. Benutzerseitig zugewiesene Identitäten sind nützlich, wenn mehrere Dienste (z. B. mehrere Function Apps) dieselbe Identität und dieselben RBAC-Berechtigungen gemeinsam verwenden müssen, da dadurch doppelte Rollenzuweisungen vermieden werden.

Nachdem Sie eine Managed Identity aktiviert haben, müssen Sie ihr RBAC-Berechtigungen für die betreffende Azure-Ressource gewähren. Um beispielsweise einem App Service das Lesen von Blobs zu erlauben, weisen Sie der Managed Identity des App Service für das Speicherkonto die Rolle Storage Blob Data Reader zu. RBAC-Zuweisungen folgen dem Prinzip der geringsten Berechtigung. Gewähren Sie nur die mindestens erforderlichen Berechtigungen. Weisen Sie einer Managed Identity niemals Owner oder Contributor zu, sofern dies nicht unbedingt erforderlich ist.

Das Azure SDK stellt eine Klasse namens DefaultAzureCredential bereit, die automatisch mehrere Authentifizierungsmethoden in einer festgelegten Reihenfolge ausprobiert: Umgebungsvariablen, Workload Identity, Managed Identity, Azure CLI, Visual Studio und weitere. Wenn Ihre Anwendung in Azure ausgeführt wird (App Service, VM, Function App), verwendet DefaultAzureCredential automatisch die Managed Identity, ohne dass Codeänderungen erforderlich sind. Lokal authentifizieren sich Entwickler über ihre Azure CLI-Sitzung. Diese einzelne Anmeldeinformationsklasse funktioniert in allen Umgebungen ohne bedingte Logik.

Ein gängiges Muster besteht darin, über eine Managed Identity zur Laufzeit auf Geheimnisse in Azure Key Vault zuzugreifen. Anstatt ein Datenbankkennwort in den Anwendungseinstellungen zu speichern, legen Sie es in Key Vault ab und weisen der Managed Identity der Anwendung für diesen Tresor die Rolle Key Vault Secrets User zu. Beim Start ruft die Anwendung das Geheimnis mithilfe von DefaultAzureCredential aus Key Vault ab. Dadurch werden Geheimnisse niemals im Code, in Konfigurationsdateien oder in Umgebungsvariablen gespeichert. Sie existieren ausschließlich in Key Vault und werden nur vorübergehend abgerufen.

Azure SQL Database unterstützt die Entra ID-Authentifizierung. Das bedeutet, dass sich eine Managed Identity ohne Benutzername und Kennwort bei SQL authentifizieren kann. Aktivieren Sie dazu zunächst einen Entra ID-Administrator auf dem SQL-Server. Führen Sie anschließend in der Zieldatenbank eine CREATE USER-Anweisung für den Anzeigenamen der Managed Identity aus und gewähren Sie ihr die passende Datenbankrolle. Die Anwendung stellt mithilfe des Azure SDKs und DefaultAzureCredential eine Verbindung her und verwendet dabei ein auf https://database.windows.net/ begrenztes Zugriffstoken, vollständig ohne Kennwort.

In Azure Kubernetes Service können einzelne Pods mithilfe von Workload Identity (dem Nachfolger von AAD Pod Identity) Managed-Identity-Token abrufen. Sie erstellen eine benutzerseitig zugewiesene Managed Identity, föderieren sie mit dem AKS-OIDC-Aussteller, annotieren das Kubernetes-Dienstkonto, und der Azure Workload Identity-WebHook injiziert die erforderlichen Umgebungsvariablen, damit DefaultAzureCredential des Pods ein Token abrufen kann. Dadurch wird die kennwortlose Authentifizierung auf containerisierte Microservices erweitert, ohne Geheimnisse in Kubernetes-Secrets-Objekten zu speichern.

Obwohl die Anmeldeinformationen einer Managed Identity für Entwickler unsichtbar sind, werden alle Ereignisse zur Tokenausstellung und zum Ressourcenzugriff protokolliert. Entra ID-Anmeldeprotokolle erfassen jede Tokenanforderung einer Managed Identity, einschließlich der aufgerufenen Ressource, des Zeitpunkts und des Erfolgs der Anforderung. Aktivitätsprotokolle von Azure Storage und Überwachungsprotokolle von Key Vault erfassen die konkreten Vorgänge, die mit dem Token ausgeführt wurden. Diese Protokolle sind für Sicherheitsüberprüfungen und Untersuchungen von Sicherheitsvorfällen im Zusammenhang mit Managed Identities unerlässlich.

Wenn Ihre Anwendung derzeit Verbindungszeichenfolgen oder API-Schlüssel verwendet, migrieren Sie in drei Schritten zu Managed Identity: Schritt 1 – Aktivieren Sie eine Managed Identity für die Compute-Ressource. Schritt 2 – Weisen Sie der Identität für jeden Zieldienst die passenden RBAC-Rollen zu. Schritt 3 – Aktualisieren Sie den Anwendungscode so, dass er anstelle der Verbindungszeichenfolge DefaultAzureCredential verwendet. Entfernen Sie die Verbindungszeichenfolge aus der App Service-Konfiguration und aus Key Vault, sobald die Migration überprüft wurde. Diese Migration lässt sich in modernen Azure SDK-Anwendungen in der Regel mit geringfügigen Codeänderungen durchführen.

Managed Identity bietet gegenüber der authentifizierungsbasierten Verwendung von Anmeldeinformationen vier wesentliche Sicherheitsvorteile: Keine Speicherung von Anmeldeinformationen – Es gibt nichts zu stehlen oder versehentlich zu übernehmen. Automatische Erneuerung – Azure erneuert die zugrunde liegenden Zertifikate ohne Ausfallzeit. Begrenzte Berechtigungen – Identitäten erhalten nur die benötigten RBAC-Rollen gemäß dem Prinzip der geringsten Berechtigung. Vollständiger Überwachungspfad – Alle Zugriffsversuche werden in Entra ID und den Überwachungsprotokollen des aufgerufenen Dienstes protokolliert. Für jede neue Integration eines Azure-Dienstes sollte Managed Identity der standardmäßige Authentifizierungsansatz sein.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion zu Microsoft Azure Fundamentals (AZ-900).

In dieser Lektion haben Sie Folgendes gelernt: Eine verwaltete Identität macht gespeicherte Anmeldeinformationen überflüssig, indem sie Azure-Ressourcen eine automatisch verwaltete Entra ID-Identität zuweist. DefaultAzureCredential im Azure SDK verwendet in Azure transparent die verwaltete Identität und lokal die Anmeldeinformationen der Entwicklung. RBAC-Rollenzuweisungen bei den Zieldiensten steuern, worauf die Identität zugreifen kann. Als Nächstes sehen wir uns Azure Service Bus für die entkoppelte Nachrichtenübermittlung zwischen Anwendungskomponenten an.