Azure App Registrierungen, Enterprise Anwendungen und Managed Identities erklärt
Um die Verwirrung hinter App Registrations und Enterprise Applications aufzulösen, erkläre ich in diesem Beitrag die Unterschiede und Merkmale der jeweiligen Ressourcen.
Einführung
Azure App-Registrierungen sind ein grundlegender Bestandteil für die Absicherung und Verwaltung des Zugriffs auf Anwendungen in Azure Active Directory (heute Microsoft Entra ID). Sie ermöglichen es Anwendungen, Benutzer und Dienste sicher zu authentifizieren – unter Verwendung von branchenüblichen Authentifizierungsprotokollen wie OAuth 2.0 und OpenID Connect.
Wenn du neu bei Azure bist, hilft dir dieser Leitfaden dabei, App-Registrierungen, ihren Zweck und ihre Interaktion mit Azure Enterprise-Anwendungen und verwalteten Identitäten besser zu verstehen.
Was ist eine Azure App-Registrierung?
Eine App-Registrierung in Microsoft Entra ID (ehemals Azure Active Directory) ist die formale Identitätsdefinition deiner Anwendung innerhalb deines Azure-Tenants. Sie fungiert als digitale Identität der Anwendung und stellt die Konfiguration bereit, die für die sichere Authentifizierung und Autorisierung von Ressourcenzugriffen benötigt wird.
Mit einer App-Registrierung definierst du:
- welche Authentifizierungsprotokolle die App unterstützt (z. B. OAuth 2.0, OpenID Connect),
- welche Redirect-URIs erlaubt sind,
- welche API-Berechtigungen (Scopes) angefordert oder welche Rollen die App bereitstellen kann,
- die Client-Secrets zur Authentifizierung bei anderen App-Registrierungen,
- welche optionalen Claims ein zurückgegebenes Token enthalten soll.
Im Wesentlichen ist die App-Registrierung der Bauplan dafür, wie deine App mit den Microsoft-Identitätsdiensten interagiert.
Was ist eine Azure Enterprise Application?
Eine Enterprise-Anwendung ist die Service Principal-Instanz einer App-Registrierung innerhalb eines bestimmten Entra ID-Tenant. Sie stellt die tatsächlich im Einsatz befindliche Anwendung im Kontext deiner Organisation dar.
Wenn du eine neue App registrierst oder dich mit einer Drittanbieter-Anwendung (z. B. aus dem Azure Marketplace) verbindest, erstellt Azure automatisch eine Enterprise Application in deinem Tenant.
Enterprise Applications ermöglichen dir:
- Benutzer oder Gruppen der App zuzuweisen,
- Zugriffsrichtlinien, bedingten Zugriff und SSO (Single Sign-On) zu konfigurieren,
- Anmeldeprotokolle und App-Nutzung zu überwachen,
- sowie app-spezifische Einstellungen wie Einwilligungen und Bereitstellung zu verwalten.
Wie sind App-Registrierungen und Enterprise Applications miteinander verbunden?
In Microsoft Entra ID stellen App-Registrierungen und Enterprise Applications zwei eng verknüpfte, aber grundlegend verschiedene Identitätsobjekte dar. Obwohl sie denselben Ursprung haben, unterscheiden sich ihre Aufgaben im Unternehmenskontext deutlich.
Die App-Registrierung ist die maßgebliche Identitätsdefinition. Ein globales Objekt im Tenant, in dem die Anwendung entwickelt und veröffentlicht wird. Sie legt fest, wie sich die App authentifiziert, auf welche Ressourcen sie zugreifen kann und wie sie sich gegenüber Identity Provider präsentiert.
Im Gegensatz dazu ist die Enterprise Application die lokale Projektion dieser App im jeweiligen Tenant. Ein Service Principal, der als Ausführungskontext der Anwendung innerhalb eines bestimmten Tenants fungiert. Er ermöglicht Richtlinien zur Laufzeit, Benutzer- und Gruppenzuweisungen, bedingte Zugriffsrichtlinien, Anmeldeüberwachung und Integration in das Berechtigungsmanagement. Diese Unterscheidung ist besonders wichtig in Multi-Tenant-Szenarien, bei delegierten Berechtigungsmodellen.
| App-Registrierung | Enterprise Application (Service Principal) |
|---|---|
| Application Object im Tenant | Service Principal-Objekt als eine lokale Instanz der Anwendung in einem bestimmten Entra ID-Tenant |
| Definiert Identitätsmetadaten: Redirect-URIs, App-Secrets/Zertifikate, Rollen, API-Scopes, Token-Konfiguration usw. | Steuert wie und wer Zugriff hat und wie Berechtigungen durchgesetzt werden |
| Existiert einmal pro Anwendung, in einem einzigen Tenant | Existiert einmal pro Tenant, kann aber in vielen Tenants auftauchen. Besitzt eine 1:n-Beziehung zur App-Registrierung |
| Kann nicht direkt Benutzern oder Gruppen zugewiesen werden | Wird für Rollenvergabe, Gruppen-/Benutzerzugriff, Bedingten Zugriff und Berechtigungsmanagement verwendet |
| Unterstützt Multi-Tenant-Publishing: Externe Tenants erhalten eigene Enterprise App nach Einwilligung | Repräsentiert die Anwendung innerhalb der Enterprise-Anwendungen jedes Tenants |
| Wird von Entwicklern, DevOps und App-Architekten verwendet, um Authentifizierungs- und Autorisierungsverhalten zu definieren | Wird von Security-Teams genutzt, um die App im produktiven Betrieb, im lokalen Tenant, zu steuern |
Terraform-Resource: azuread_application | Terraform-Resource: azuread_service_principal |
Du kannst keine Enterprise Application ohne App-Registrierung haben. Die App-Registrierung ist die Definition der App-Eigenschaften, während die Enterprise Application das ist, was tatsächlich in deinem Tenant zugewiesen, überwacht und verwaltet werden kann.
Auswirkungen auf System- und User-Assigned Managed Identities
Egal ob du deine Anwendung in App Services, Azure Functions, AKS-Workloads oder virtuellen Maschinen bereitstellst – deine Compute-Ressourcen müssen sich oft sicher authentifizieren, mit anderen Diensten integrieren oder eigene APIs bereitstellen. All diese Szenarien erfordern eine zugrundeliegende Identität, die in Entra ID durch Managed Identities dargestellt wird.
Viele Azure-Compute-Dienste (App Services, VMs, Functions usw.) unterstützen Managed Identities. Im Hintergrund sind diese Identitäten Enterprise Applications (Service Principals).
Wenn du system-assigned Managed Identities verwendest, musst du keine eigene App-Registrierung erstellen, da Azure dies für dich übernimmt. Wenn du jedoch eine user-assigned Managed Identity verwendest, musst du eine App-Registrierung anlegen.
Während beide Typen eine Enterprise Application (Service Principal) in Microsoft Entra ID erstellen, wird eine App-Registrierung nur explizit für user-assigned Identitäten erstellt. System-assigned Identitäten hingegen werden vollständig von Azure verwaltet und zeigen keine App-Registrierung im Tenant an.
Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen user- und system-assigned Managed Identities zusammen:
| System-Assigned Managed Identity | User-Assigned Managed Identity | |
|---|---|---|
| Erstellung | Automatisch beim Bereitstellen der Ressource. | Manuell erstellt und einer oder mehreren Ressourcen zugewiesen. |
| Lebenszyklus | An den Lebenszyklus der Azure-Ressource gebunden. | Unabhängig von einer Ressource. |
| Entra ID Objekt(e) | Nur ein Service Principal (Enterprise Application). | Sowohl eine App-Registrierung als auch ein Service Principal. |
| Sichtbarkeit in Entra ID | Sichtbar unter Enterprise-Anwendungen. | Sichtbar unter App-Registrierungen und Enterprise-Anwendungen. |
| Ressourcenumfang | Eine eindeutige Identität pro Ressource. | Wiederverwendbar über mehrere Ressourcen hinweg. |
| Verantwortung für Verwaltung | Vollständig durch Azure verwaltet. | Vollständig vom Benutzer verwaltet. |
| Zuweisung an Ressourcen | Implizit an die erstellende Ressource gebunden. | Manuell Ressourcen zugewiesen. |
| Benennung | Name wird automatisch auf Basis der Ressource generiert. | Benutzerdefinierter Name. |
| Überwachung & Anmeldeprotokolle | Nur Service Principal-Aktivität wird dokumentiert. | Sowohl App-Registrierung als auch Service Principal Aktivität wird dokumentiert. |
Der Hauptgrund für den Einsatz von Managed Identities ist die Möglichkeit, spezifische Azure-Rollen und Berechtigungen nach dem Prinzip der geringsten Berechtigung zu vergeben. So wird sichergestellt, dass Anwendungen oder Dienste nur auf die Ressourcen zugreifen, die sie wirklich benötigen – was die Angriffsfläche reduziert und die allgemeine Sicherheitslage verbessert.
In diesem Zusammenhang spielt Azure Role-Based Access Control (RBAC) eine zentrale Rolle. RBAC ermöglicht die granulare Verwaltung von Zugriffsrechten für Azure-Ressourcen durch die Zuweisung von Rollen an Benutzer, Gruppen und Service Principals (wie Managed Identities). Durch die Kombination von Managed Identities mit RBAC kannst du klare Grenzen definieren, was ein Dienst tun darf – und das ohne das manuelle Verwalten von Geheimnissen oder Zugangsdaten.
Fazit
Das Verständnis von Azure App-Registrierungen ist entscheidend für die Absicherung von Anwendungen in Azure. Durch den Einsatz von Terraform können Organisationen die Bereitstellung sicherer Authentifizierungsmechanismen automatisieren – was Skalierbarkeit, hohe Leistung und minimale Sicherheitsrisiken gewährleistet. Die Umsetzung von Best Practices wie Managed Identity und API-Berechtigungskontrollen erhöht die Sicherheit zusätzlich und reduziert gleichzeitig den Betriebsaufwand.
Hilfreiche Links für weiterführende Recherchen
- Unterschiede zwischen App Registrations und Enterprise Applications
- https://medium.com/@shoaib.alam/part-4-oauth-2-0-pkce-flow-with-azure-ad-cc225c0ed9f6
- https://www.emilyvanputten.com/the-difference-between-azuread-app-registrations-and-enterprise-applications-explained/
- https://learn.microsoft.com/en-us/answers/questions/270680/app-registration-vs-enterprise-applications
- App Registrations
- Anwendungsbeispiele: