Wie Managed Identities in Azure fest codierte Kennwörter überflüssig machen

Von Mirko Peters · 2026-08-13

Willkommen zurück im Begleitblog zu unserem Podcast! Wenn Sie seit einiger Zeit Anwendungen entwickeln, sind Sie wahrscheinlich schon auf das altbekannte Problem gestoßen, wie Sie Ihren Code mit einer Datenbank, einer API oder einem Cloud-Speicherkonto verbinden. Früher haben Entwickler dieses Problem gelöst, indem sie eine Verbindungszeichenfolge, ein Datenbankkennwort oder einen Clientschlüssel

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Begleitblog zu unserem Podcast! Wenn Sie seit einiger Zeit Anwendungen entwickeln, sind Sie wahrscheinlich schon auf das altbekannte Problem gestoßen, wie Sie Ihren Code mit einer Datenbank, einer API oder einem Cloud-Speicherkonto verbinden. Früher haben Entwickler dieses Problem gelöst, indem sie eine Verbindungszeichenfolge, ein Datenbankkennwort oder einen Clientschlüssel direkt in eine Konfigurationsdatei, eine Umgebungsvariable oder, noch schlimmer, fest im Quellcode des Repositorys hinterlegt haben. Solange die Anwendung dieses Geheimnis lesen konnte, konnte sie sich authentifizieren und ihre Aufgabe erledigen. Doch was passiert, wenn dieser Code versehentlich in einem öffentlichen GitHub-Repository landet? Was passiert, wenn ein verärgerter Mitarbeiter das Unternehmen verlässt oder ein Angreifer Lesezugriff auf Ihre Anwendungseinstellungen erlangt? Dann ist Ihre gesamte Infrastruktur sofort kompromittiert. In der modernen Cloud-Architektur ist dieses Risiko nicht mehr akzeptabel. Heute tauchen wir tief in die Frage ein, wie Managed Identities in Microsoft Azure den Bedarf an fest codierten Kennwörtern vollständig beseitigen und statische Geheimnisse durch dynamische, kurzlebige Zugriffstoken ersetzen.

Einführung in Cloudsicherheit und fest codierte Geheimnisse

Das traditionelle perimeterbasierte Sicherheitsmodell beruhte stark auf der Annahme, dass man nach dem Zugang zum Unternehmensnetzwerk vertrauenswürdig ist. Innerhalb dieses Perimeters kommunizierten Anwendungen über statische Dienstkonten, fest codierte Kennwörter und langlebige Token, die selten oder nie abliefen. Gelang es einem Angreifer, den Perimeter zu durchbrechen, hatte er Zugriff auf einen Schatz an statischen Anmeldeinformationen, die unbegrenzt wiederverwendet werden konnten.

Cloud Computing hat diesen Perimeter vollständig aufgelöst. Unsere Workloads erstrecken sich heute über Multi-Cloud-Umgebungen, lokale Rechenzentren, SaaS-Plattformen und verteilte Serverless-Funktionen. In dieser neuen Welt muss die Sicherheit der Identität des Workloads selbst folgen. Fest codierte Geheimnisse sind tickende Zeitbomben. Sie werden nicht automatisch rotiert, sind äußerst schwer zu prüfen und lassen bei einer Offenlegung keinen Spielraum für Fehler. Um echte Zero-Trust-Sicherheit zu erreichen, müssen wir Anmeldeinformationen vollständig vom Quellcode entkoppeln. Wir brauchen einen Authentifizierungsmechanismus, mit dem Anwendungen nachweisen können, wer sie sind, ohne jemals ein Kennwort kennen oder speichern zu müssen.

Benutzeridentitäten vs. Workloadidentitäten in Entra ID verstehen

Um zu verstehen, wie sich die Cloudsicherheit entwickelt hat, müssen wir zunächst betrachten, wie Microsoft Entra ID die Entitäten verwaltet, die auf unsere Systeme zugreifen. Grundsätzlich unterteilt Microsoft Entra ID Identitäten in zwei Hauptkategorien: Benutzeridentitäten und Workloadidentitäten.

Benutzeridentitäten repräsentieren Menschen – Mitarbeitende, Partner, Auftragnehmer und Kunden. Menschen interagieren dynamisch mit Systemen und authentifizieren sich mit Methoden, die auf Personen zugeschnitten sind, etwa Kennwörter, Windows Hello for Business, FIDO2-Sicherheitsschlüssel und Multifaktor-Authentifizierung. Menschen vergessen Kennwörter, fallen Phishing-Angriffen zum Opfer und benötigen administrative Kennwortzurücksetzungen.

Workloadidentitäten dagegen repräsentieren Software. Dazu gehören Anwendungen, Hintergrunddienste, Automatisierungsskripte, Azure Functions, Logic Apps, DevOps-Bereitstellungspipelines und KI-Agenten. Workloads trinken keinen Kaffee, sie klicken nicht auf Phishing-E-Mails und können keine interaktive Multifaktor-Authentifizierungsabfrage auf einem Smartphone abschließen. Sie müssen nicht interaktiv, programmatisch und kontinuierlich authentifiziert werden. Eine Workloadidentität wie eine Benutzeridentität zu behandeln und ihr ein statisches Kennwort zuzuweisen, zählt zu den häufigsten Fallstricken in der Cloud-Architektur. Workloadidentitäten benötigen eigene, spezialisierte Governance-Modelle, Lebenszyklusverwaltung und automatisierte Authentifizierungsabläufe.

App-Registrierungen, Dienstprinzipale und Managed Identities im Detail

Wenn Sie sich schon einmal mit der Konfiguration von Anwendungen in Microsoft Entra ID beschäftigt haben, sind Sie sicherlich auf drei Begriffe gestoßen, die häufig für Verwirrung sorgen: App-Registrierungen, Dienstprinzipale und Managed Identities. Schauen wir sie uns der Reihe nach einfach an.

Eine Application Registration ist die globale Definition bzw. der Bauplan Ihrer Anwendung. Wenn Sie eine Anwendung in Microsoft Entra ID registrieren, legen Sie ihre globale Identität im gesamten Multi-Tenant-Ökosystem fest. Hier definieren Sie, welche Berechtigungen die Anwendung voraussichtlich benötigt, welche Authentifizierungsendpunkte sie verwendet und welche URIs ihr zugeordnet sind. Betrachten Sie die Application Registration als die Vorlage für einen Reisepass.

Ein Service Principal ist die lokale Instanz dieser Anwendung innerhalb eines bestimmten Mandanten. Ist eine Anwendung mandantenübergreifend (Multi-Tenant), gibt es eine Application Registration im Mandanten des Herausgebers, aber für jeden einzelnen Kundenmandanten, in dem sie bereitgestellt und zugestimmt wurde, einen eigenen Service Principal. Im Service Principal weisen Administratoren Berechtigungen tatsächlich zu, wenden Richtlinien für bedingten Zugriff an und steuern, wer lokal auf die Anwendung zugreifen darf. Betrachten Sie den Service Principal als den tatsächlichen, abgestempelten Reisepass, mit dem Sie in ein bestimmtes Land einreisen.

Eine Managed Identity geht dieses Konzept einen Schritt weiter, und zwar speziell für Ressourcen, die in Microsoft Azure laufen. Statt dass ein Entwickler manuell eine Application Registration anlegt, ein Clientgeheimnis generiert, dieses Geheimnis in einer Umgebungsvariable speichert und Code schreibt, der den Lebenszyklus der Authentifizierung verwaltet, übernimmt Azure den gesamten Prozess im Hintergrund. Azure erstellt, verwaltet und rotiert die zugrunde liegenden Anmeldeinformationen automatisch für Sie. Der Entwickler weist die Azure-Ressource lediglich an, ihre Managed Identity zu verwenden, und Azure erledigt den Rest.

Wie Managed Identities Passwörter und fest codierte Anmeldeinformationen überflüssig machen

Der Vorteil von Managed Identities liegt darin, dass sie den Authentifizierungsvorgang grundlegend verändern. Wenn Sie eine Managed Identity für eine Azure-Ressource verwenden, etwa einen Azure App Service, eine virtuelle Maschine oder eine Azure Function, werden in Ihrem Code oder in den Konfigurationseinstellungen buchstäblich kein Passwort, kein Geheimnis und kein Zertifikat gespeichert.

Benötigt Ihre Anwendung Zugriff auf eine geschützte Ressource, etwa eine Datenbank oder eine API, sucht sie kein gespeichertes Passwort heraus. Stattdessen sendet die Anwendung einen lokalen Aufruf an den Azure Instance Metadata Service (IMDS)-Endpunkt, der nur innerhalb der jeweiligen Azure-Ressource sicher erreichbar ist. Die zugrunde liegende Plattform der Azure-Ressource fordert im Auftrag der Anwendung direkt bei Microsoft Entra ID ein kurzlebiges JSON Web Token (JWT) an.

Microsoft Entra ID überprüft die Identität der Azure-Ressource, stellt ein kryptografisch signiertes Zugriffstoken mit einer sehr kurzen Gültigkeitsdauer (in der Regel etwa eine Stunde) aus und gibt es an die Anwendung zurück. Die Anwendung nutzt dieses Token anschließend, um sich beim Zieldienst zu authentifizieren. Da das Token schnell abläuft, ist das Zeitfenster für einen Angriff außerordentlich klein, selbst wenn ein Angreifer es abfangen sollte. Da zudem kein statisches Passwort im Code hinterlegt ist, gibt es für Entwickler nichts, was sie versehentlich in einem öffentlichen Repository preisgeben könnten.

Azure Key Vault und kurzlebige Zugriffstoken kombinieren

Managed Identities machen Anwendungspasswörter überflüssig. Dennoch stellt sich die Frage, wie Anwendungen mit Geheimnissen umgehen, die tatsächlich extern sind, etwa API-Schlüssel für Drittanbieterdienste, die keine Microsoft Entra-Authentifizierung unterstützen. Hier kommt Azure Key Vault ins Spiel, das eng mit Managed Identities zusammenarbeitet.

Anstatt einen API-Schlüssel eines Drittanbieters fest in den Quellcode einzutragen, speichern Sie diesen Schlüssel sicher in Azure Key Vault. Anschließend erteilen Sie der Managed Identity Ihrer Azure-Ressource die Berechtigung, Geheimnisse aus diesem Key Vault zu lesen, und zwar über Azure Role-Based Access Control (RBAC) oder über Zugriffsrichtlinien für Key Vault.

Beim Start greift die Anwendung mithilfe ihrer Managed Identity auf Azure Key Vault zu, ruft den benötigten API-Schlüssel des Drittanbieters dynamisch im Arbeitsspeicher ab und verwendet ihn. Zu keinem Zeitpunkt werden Anmeldeinformationen im Quellcode offengelegt. Die Anwendung nutzt einen sicheren, identitätsbasierten Mechanismus, um ein Geheimnis abzurufen, statt sich auf eine fest hinterlegte Zeichenfolge in einer Konfigurationsdatei zu verlassen.

Workload-Identitäten mit dem Prinzip der minimalen Berechtigungen und Governance absichern

Der Verzicht auf fest codierte Passwörter ist ein enormer Sicherheitsgewinn, doch Managed Identities lassen sich nicht nach dem Motto „einrichten und vergessen“ betreiben. Workload-Identitäten benötigen eine solide Governance, genauso wie menschliche Benutzerkonten.

Zuallererst müssen Sie das Prinzip der minimalen Berechtigungen konsequent einhalten. Vergeben Sie keine weitreichenden Mitwirkenden-Rollen (Contributor) oder übermäßigen Microsoft Graph-Berechtigungen an eine Workload-Identität, nur um Dinge schnell zum Laufen zu bringen. Benötigt ein Hintergrundskript lediglich das Lesen von Elementen aus einem bestimmten Azure Storage-Container, erhält es Zugriff als Storage Blob Data Reader auf genau diesen Container – nicht mehr. Wird diese Workload-Identität jemals kompromittiert, bleibt der mögliche Schaden minimal.

Zweitens sollten Sie Ihre Workload-Identitäten kontinuierlich überwachen und prüfen. Unternehmen erstellen häufig Dienstprinzipale und verwaltete Identitäten für Proof-of-Concept-Projekte, Automatisierungsskripte und temporäre Integrationen und lassen sie anschließend mit hohen Berechtigungen dauerhaft bestehen. Führen Sie regelmäßige Sicherheitsüberprüfungen durch, um verwaiste Dienstprinzipale, ungenutzte Automatisierungskonten und veraltete Anmeldeinformationen zu identifizieren. Funktionen wie Microsoft Entra ID Protection sowie eine solide Protokollierung über Azure Monitor sorgen dafür, dass Sie jederzeit vollständig nachvollziehen können, wann und wie Ihre Workload-Identitäten auf Ihre Umgebung zugreifen.

Die richtige Identitätsstrategie für jede Cloud-Workload wählen

Angesichts der vielen Optionen im Microsoft-Identitätsökosystem stellt sich die Frage: Wie wählen Sie die passende Authentifizierungsstrategie für Ihre konkrete Workload? Die Entscheidung hängt in der Regel davon ab, wo Ihre Anwendung läuft und wie sie aufgebaut ist.

Läuft Ihr Code innerhalb von Microsoft Azure – ob auf Azure App Services, Azure Functions, virtuellen Computern, Container Instances oder Azure Kubernetes Service –, sollte Ihre erste Wahl immer eine verwaltete Identität sein. Sie können zwischen einer systemseitig zugewiesenen verwalteten Identität wählen, deren Lebenszyklus in einer 1:1-Beziehung direkt an die Azure-Ressource gebunden ist, oder einer benutzerseitig zugewiesenen verwalteten Identität, die unabhängig erstellt und über mehrere Azure-Ressourcen hinweg zugewiesen werden kann, was die Verwaltung erleichtert.

Läuft Ihre Anwendung außerhalb von Azure – etwa auf lokalen Servern, in AWS oder als Teil einer CI/CD-Pipeline in GitHub Actions –, stehen von Azure-Infrastruktur gehostete verwaltete Identitäten nicht zur Verfügung. In diesen Szenarien sollten Sie die Workload-Identitätsföderation nutzen. Sie ermöglicht externen Plattformen, Token direkt mit Microsoft Entra ID über eine OpenID-Connect-(OIDC-)Vertrauensstellung auszutauschen. Dadurch entfällt vollständig die Notwendigkeit, langlebige Clientgeheimnisse zu verwalten, zu rotieren oder zu speichern.

Für klassische, individuell entwickelte Unternehmensanwendungen, die eine Clientauthentifizierung benötigen und bei denen weder verwaltete Identitäten noch Föderation infrage kommen, sollten Sie schließlich sorgfältig verwaltete Zertifikate immer langlebigen Clientgeheimnissen vorziehen. Durch die Kombination von Microsoft Entra Workload-Identitäten, Azure Key Vault, Zero-Trust-Prinzipien und Zugriff nach dem Prinzip der minimalen Berechtigungen kann Ihre Organisation fest eingebettete Passwörter vollständig beseitigen und eine bemerkenswert widerstandsfähige Cloud-Architektur aufbauen.

Fazit und nächste Schritte für moderne Cloud-Sicherheit

Fest codierte Passwörter und statische Verbindungszeichenfolgen sind Relikte einer überholten Ära der IT-Sicherheit. Mit Microsoft Entra Workload-Identitäten und Azure verwalteten Identitäten können wir die Risiken eingebetteter Anmeldeinformationen vollständig ausschalten, unsere Quellcode-Repositorys vor versehentlichen Datenlecks schützen und einen strikten Zugriff nach dem Prinzip der minimalen Berechtigungen über alle cloudnativen Anwendungen hinweg durchsetzen. Kurzlebige Zugriffstoken sorgen dafür, dass selbst ein abgefangenes Token nur so kurz gültig ist, dass kein nachhaltiger Schaden entsteht. Damit verschiebt sich unsere Sicherheitslage grundlegend von reaktiver Abwehr hin zu proaktivem Schutz.

Um noch tiefer in dieses Thema einzusteigen und praktische Umsetzungstipps aus der Praxis zu hören, schauen Sie sich unbedingt die passende Podcast-Episode an: Entra Workload Identities - Simply Explained. Hören Sie rein, wenn wir diese Konzepte noch genauer erläutern, damit Sie Ihre Azure- und Microsoft 365-Umgebungen wie ein Profi absichern!