Managed Identities vs. App-Registrierungen in Azure: Wichtigste Unterschiede und Best Practices

Von Mirko Peters · 2026-04-28

Wenn Sie heutzutage etwas Ernsthaftes in Azure entwickeln oder absichern, führt kein Weg daran vorbei, sich mit Managed Identities und App-Registrierungen auseinanderzusetzen. Es ist eine Grundvoraussetzung. Beide spielen eine zentrale Rolle beim Identitäts- und Zugriffsmanagement für Ihre Apps, Automatisierungen und Dienste. Wer jedoch nicht weiß, welches Modell wo passt, handelt sich unnötige Pr

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

Wenn Sie heutzutage etwas Ernsthaftes in Azure entwickeln oder absichern, müssen Sie sich unbedingt mit Managed Identities und App-Registrierungen auseinandersetzen. Es ist eine Grundvoraussetzung. Beide spielen eine zentrale Rolle beim Identitäts- und Zugriffsmanagement für Ihre Apps, Automatisierungen und Dienste. Wer jedoch nicht weiß, welches Modell wofür geeignet ist, handelt sich unnötige Probleme, Sicherheitslücken oder einen übermäßigen Aufwand für die Verwaltung von Geheimnissen ein.

Dieser Leitfaden erklärt, was Managed Identities und App-Registrierungen sind, wie sie mit Entra ID (früher Azure AD) zusammenarbeiten und warum die Wahl des richtigen Ansatzes für Ihre Sicherheitslage und den täglichen Betrieb wichtig ist. Sie erhalten klare Definitionen, praxisnahe Szenarien, Tipps für die Migration weg von Secrets sowie konkrete Empfehlungen für Fehlerbehebung und Governance. Ziel ist ein straffer, sicherer und effizienter Microsoft-Cloud-Betrieb, gerade weil Angriffe zunehmen und sich die Best Practices für Entra ID weiterentwickeln.

Managed Identities und App-Registrierungen im Überblick

Klären wir zunächst, was Managed Identities und App-Registrierungen in Azure und Entra ID tatsächlich leisten. Beide Mechanismen ermöglichen nicht-menschlichen Akteuren wie Apps, Skripten oder Automatisierungen, sich zu authentifizieren und auf Ressourcen in der Microsoft-Cloud zuzugreifen. Die Art und Weise, wie sie das tun, und die Probleme im Alltag, die sie lösen (oder verursachen), unterscheiden sich jedoch deutlich.

Managed Identities sind Azures Antwort auf die Authentifizierung ohne Geheimnisse. Anstatt sich mit App-Kennwörtern und Zertifikaten zu befassen, können Sie einer Azure-Ressource (etwa einer virtuellen Maschine, einem App Service oder einer Logic App) eine eigene Identität in Entra ID zuweisen. Azure verwaltet diese Identität automatisch: Sie wird erstellt, sobald die Ressource angelegt wird, und gelöscht, wenn Sie die Ressource entfernen. Vor allem aber müssen keine klassischen Geheimnisse ausgetauscht werden. Managed Identities gibt es in zwei Varianten: systemzugewiesen (eine pro Ressource, streng abgeschottet) und benutzerzugewiesen (über mehrere Ressourcen hinweg wiederverwendbar).

App-Registrierungen sind der klassische Ansatz. Wenn Sie eine App in Entra ID registrieren, entsteht ein Anwendungsobjekt, und Sie erhalten eine Client-ID. Optional können Sie Geheimnisse oder Zertifikate für die Authentifizierung hinterlegen. Wenn Ihre App sich bei Microsoft-Diensten anmelden, auf die Graph API zugreifen oder außerhalb von Azure bzw. für mehr als eine Ressource arbeiten muss, werden Sie in der Regel eine App-Registrierung verwenden. Dafür sind Sie jedoch selbst verantwortlich: Sie müssen Geheimnisse, Sicherheit und Lebenszyklus steuern, was einige Kompromisse mit sich bringt.

Die Wahl des richtigen Werkzeugs ist nicht nur eine technische Entscheidung, sondern auch eine Risikoabwägung. Geheimnisse sind attraktive Ziele für Angreifer, während Managed Identities ohne Geheimnisse ganze Klassen von Schwachstellen ausschließen. Wenn Sie nachvollziehen möchten, warum das so wichtig ist, lesen Sie diesen ausführlichen Beitrag zu Missbrauch der OAuth-Zustimmung in Entra ID. Angreifer wissen, wie sie sich in Umgebungen festsetzen, in denen die Grundlagen nicht stimmen. Deshalb ist die richtige Identitätsstrategie der erste Schritt.

Zentrale Unterschiede: Lebenszyklus, Sicherheit und Azure-Integration

Hier trifft Theorie auf Praxis. Managed Identities und App-Registrierungen geben Apps oder Skripten beide eine digitale „Namensmarke“, mit der sie auf Ressourcen zugreifen können. Wie Sie diese Marke erhalten, pflegen und später wieder aufräumen, unterscheidet sich jedoch erheblich.

Managed Identities sind so nah an „einrichten und vergessen“, wie es in der Cloud nur geht. Sie erstellen eine Azure-Ressource, fordern eine Managed Identity an, und schon ist alles erledigt: Azure legt die Identität für Sie an, bindet sie in Entra ID ein und hält die Verbindung im Hintergrund synchron. Löschen Sie die Ressource, verschwindet auch die Identität. Es fällt keinerlei Geheimnisverwaltung an, Kennwörter müssen nicht rotiert werden, und Sicherheitsteams können ruhiger schlafen.

App-Registrierungen erfordern deutlich mehr Aufwand. Sie legen die App-Registrierung manuell in Entra ID an, verwalten ihre Client-ID und erzeugen Geheimnisse oder Zertifikate für die Authentifizierung. Mit der Zeit laufen diese Geheimnisse ab oder können abfließen, und Sie müssen selbst prüfen, welche Apps sie verwenden. Geheimnisse rotieren, ablaufende Anmeldeinformationen im Blick behalten und verwaiste Registrierungen aufräumen ist eine Aufgabe für sich. Deshalb fragen Sicherheitsteams immer wieder nach einer Automatisierung des Lebenszyklus.

Bei der Sicherheit ist der Unterschied eindeutig: Verwaltete Identitäten nutzen eine geheimnislose Authentifizierung, die an Azure-Ressourcen gebunden ist, während App-Registrierungen auf statische Geheimnisse oder Zertifikate setzen. Deshalb werden verwaltete Identitäten überall dort bevorzugt, wo Geheimnisse ein Risiko darstellen oder Automatisierung im Mittelpunkt steht.

Diese Unterschiede bei Lebenszyklus und Sicherheit haben weitreichende Folgen für Automatisierung, Compliance und die Absicherung Ihrer Cloud-Umgebungen. Wenn Sie nachvollziehen möchten, wie Governance-Richtlinien und Kontrollen mit Identitätswildwuchs und Sicherheitsabweichungen zusammenhängen, lesen Sie diesen Leitfaden zur Azure-Governance-Strategie. Er ist Pflichtlektüre für alle, die für große, wachsende Azure-Umgebungen verantwortlich sind.

Dienstprinzipale, RBAC-Rollen und Microsoft Graph-Berechtigungen

Schauen wir uns das nun etwas genauer an. Verwaltete Identitäten und App-Registrierungen nutzen im Hintergrund beide Dienstprinzipale in Entra ID. Ein Dienstprinzipal ist die eigentliche, funktionierende Identität, die Entra ID kennt. Ob er aus einer verwalteten Identität oder aus einer App-Registrierung stammt: Dieses Objekt erhält Berechtigungen und Zugriff in Ihrem Mandanten.

Bei App-Registrierungen erstellt Entra für jede neue App einen entsprechenden Dienstprinzipal in jedem Mandanten, dem Sie die App zuweisen. Mit dieser Identität vergeben Sie Azure-RBAC-Rollen wie Contributor oder Reader und gewähren Graph-API-Berechtigungen, ob delegiert oder auf Anwendungsebene.

Verwaltete Identitäten unterscheiden sich etwas, basieren aber auf denselben Grundlagen. Wenn Sie für eine Azure-Ressource eine verwaltete Identität aktivieren, erstellt Entra einen Dienstprinzipal mit einem speziellen Zweck, der mit der Ressource entsteht und mit ihr endet. Anschließend weisen Sie dieser Identität RBAC-Rollen direkt zu, etwa Key Vault Reader. Die Ressource erhält im Hintergrund Tokenzugriff. Es sind keine Codeänderungen nötig, und es kursieren keine Geheimnisse herum.

Beim Vergeben von Berechtigungen zeigt sich, worauf es wirklich ankommt. Beide Modelle nutzen Azure RBAC für den Zugriff auf Ressourcenebene, bei den Graph-Berechtigungen unterscheidet sich die Vorgehensweise jedoch. Bei App-Registrierungen genehmigen Sie den Graph-API-Zugriff über eine ausdrückliche Zustimmung oder eine Administratorgenehmigung. Verwaltete Identitäten können Anwendungsberechtigungen für Graph ohne interaktive Anmeldung erhalten. Damit eignen sie sich ideal für Automatisierungen, die Benutzerdaten abrufen, Sicherheit prüfen oder Workflows auslösen.

Die Zugriffszuweisung und Compliance-Überwachung dieser Identitäten ist allerdings nicht einfach „einrichten und vergessen“. Eine strikte RBAC-Rollenzuweisung, regelmäßige Audits und Tools wie Microsoft Defender for Cloud helfen Ihnen, den Überblick zu behalten, zu sehen, wer was tut, Fehlkonfigurationen aufzuspüren und Abweichungen so gering wie möglich zu halten. Möchten Sie tiefer in die Identitäts-Governance einsteigen? Dann lesen Sie diesen Leitfaden zur Azure-Enterprise-Governance oder diese Erklärung zur Compliance-Überwachung in Microsoft Defender for Cloud mit praktischen Tipps für kontinuierliche Sicherheit.

Die richtige Wahl treffen: Szenarien, Migration und Governance

Dieser Hintergrund ist wichtig, doch die meisten Teams wollen vor allem wissen: Wann verwenden Sie verwaltete Identitäten und wann App-Registrierungen? Und wie migrieren oder steuern Sie diese Identitäten, damit bei wachsender Umgebung nichts aus dem Ruder läuft?

Verwaltete Identitäten spielen ihre Stärken bei Workloads aus, die direkt in Azure laufen und nur Zugriff innerhalb desselben Mandanten benötigen, etwa VMs, die Skripte ausführen, App Services, die mit Key Vault kommunizieren, oder Logic Apps, die Microsoft Graph abfragen. Die Sicherheit ist besser, die Einrichtung geht schneller, und es fällt weniger Geheimnisverwaltung an. Wenn Sie jedoch SaaS-, Multi-Tenant-Lösungen oder Hybridszenarien betreiben, etwa lokale Anwendungen, die auf Cloud-APIs zugreifen, sind App-Registrierungen dank ihrer Flexibilität und breiteren Kompatibilität weiterhin die erste Wahl.

Die Migration von App-Registrierungen zu verwalteten Identitäten ist ein viel diskutiertes Thema. Der Prozess beginnt mit einer Bereitschaftsbewertung: Welche Workloads lassen sich tatsächlich umstellen, und welche Abhängigkeiten oder Einschränkungen bestehen? Bei Anwendungen, die bereits auf App-Registrierungen basieren, sollten Sie schrittweise vorgehen, gründlich testen und Rückfallpläne bereithalten, um Ausfallzeiten und Überraschungen bei der Authentifizierung zu vermeiden.

Hybride und Multi-Cloud-Umgebungen erfordern etwas Kreativität. Manchmal müssen Sie beide Modelle gemeinsam nutzen – eine Vorgehensweise, die als Hybrididentität bezeichnet wird. Entscheidend ist, Geheimnisse auf ein Minimum zu reduzieren, Berechtigungen zu begrenzen und klar zu dokumentieren, welche Identität welche Aufgabe übernimmt. Und ja, regelmäßige Überprüfungen sind unverzichtbar, um veraltete oder verwaiste Identitäten aufzuspüren, die verborgene Risiken verursachen.

Starke Governance-Richtlinien fügen die gesamte Strategie zusammen. Azure Policy, Privileged Identity Management und regelmäßige Compliance-Prüfungen helfen Ihnen, das Least-Privilege-Prinzip durchzusetzen, Abweichungen frühzeitig zu erkennen und die Umgebung am Zero-Trust-Modell auszurichten. Für einen realistischen Blick auf Dienstkonten im Vergleich zu echten Workload-Identitäten (und warum veraltete Ansätze nicht ausreichen) lohnt sich diese Analyse zu Risiken nicht-menschlicher Identitäten und Microsoft Entra Workload Identities. Sie möchten einen umfassenden Überblick über die Grundlagen der Governance? Die Ressource Strategie für Enterprise-Governance enthält zahlreiche bewährte Vorgehensweisen.