Anwendungsidentitäts- und Zugriffsverwaltung
Dieser Artikel beschreibt Überlegungen und Empfehlungen, die Anwendungsbesitzer*innen und Entwickler*innen bei der Gestaltung der Identitäts- und Zugriffsverwaltung für Cloud-native Anwendungen nutzen können.
Wenn Ihr Team Cloud-native Anwendungen migriert oder erstellt, müssen Sie die Authentifizierungs- und Zugriffsanforderungen für die Anwendungen berücksichtigen. Diese Anforderungen bestimmen, wie sich die Benutzenden bei den Anwendungen authentifizieren und wie sich die Ressourcen der Anwendungen untereinander authentifizieren, z. B. wenn eine Webanwendung auf eine SQL-Datenbank zugreift.
Im Bereich Plattformautomatisierung und DevOps-Design empfehlen wir, dass Ihr Anwendungsteam Workloads auf Abonnement-Verkauf umstellt. Im Rahmen des Abonnement-Verkaufsprozesses muss Ihr Anwendungsteam dem Plattformteam Identitäts- und Zugriffsanforderungen zur Verfügung stellen, damit es die entsprechenden Abonnements erstellen kann. Die Anwendungsbesitzenden sind für das Identitäts- und Zugriffsmanagement der einzelnen Anwendungen verantwortlich. Sie sollten Ihre Anwendung mit Hilfe der zentralen Dienste verwalten, die das Plattformteam bereitstellt.
Überlegungen zum Entwurf
Um das Risiko eines unbefugten Zugriffs auf Ihre Anwendungen zu verringern, sollten Sie die folgenden Überlegungen in Ihr Design einbeziehen.
Es gibt verschiedene Authentifizierungs- und Autorisierungsstandards, wie OAuth 2.0, OpenID Connect, JSON Web Token (JWTs) und SAML (Security Assertion Markup Language). Bestimmen Sie, welche Authentifizierungs- und Autorisierungsstandards Sie für Ihre Anwendung verwenden möchten.
Wenn Sie eine Plattform-Landing-Zone beim Plattformteam anfordern, können Sie sicherstellen, dass das Team die entsprechenden Abonnements erstellt, indem Sie ihm die folgenden Fragen stellen:
Wie werden sich die Benutzer*innen bei der Anwendung authentifizieren und auf sie zugreifen?
Wer benötigt RBAC-Berechtigungen (rollenbasierte Zugriffssteuerung) für Ressourcen und Dienste, die die Anwendung nutzt?
Decken die vorhandenen integrierten Rollen die RBAC-Zugriffsanforderungen sowohl für den Zugriff auf die Steuerungsebene als auch auf die Datenebene ab, oder müssen Sie neue angepasste Rollen erstellen?
Hat das Plattform-Team Richtlinien zur Compliance implementiert, die zu Problemen mit der Anwendung führen könnten?
Welche Anwendungskomponenten müssen miteinander kommunizieren?
Gibt es Anforderungen für den Zugriff auf die gemeinsam genutzten Ressourcen, wie z. B. Microsoft Entra Domain Services, die in der Plattform-Landing-Zone bereitgestellt werden?
Azure Key Vault und verwaltete Identitäten
Sicherheitsverletzungen bei Public Cloud-Ressourcen gehen häufig auf geleakte Anmeldeinformationen zurück, die in Code oder anderen Text eingebettet sind. Mit verwalteten Identitäten und Key Vault können Sie einen programmgesteuerten Zugriff implementieren und so das Risiko des Diebstahls von Anmeldeinformationen verringern.
Wenn Ihre Anwendung oder Ihr Workload einen Dienst benötigt, um Anmeldeinformationen sicher zu speichern, können Sie Key Vault verwenden, um Secrets, Schlüssel und Zertifikate zu verwalten.
Um Anmeldeinformationen in Ihrem Code zu vermeiden, können Sie verwaltete Identitäten mit Azure VMs verwenden, um sich bei jedem Dienst zu authentifizieren, der die Microsoft Entra ID-Authentifizierung unterstützt. Weitere Informationen finden Sie unter Verwaltete Identitäten für Azure Ressourcen auf einer VM verwenden, um ein Token für den Zugriff zu erwerben.
Verwaltete Identitäten bieten ein automatisch verwaltetes Identitätsprinzipal, das Anwendungen und Ressourcen verwenden, wenn sie sich mit Ressourcen verbinden, die die Microsoft Entra ID-Authentifizierung unterstützen. Anwendungen können verwaltete Identitäten verwenden, um Microsoft Entra ID-Token zu erhalten, ohne Anmeldeinformationen verwalten zu müssen.
Sie können entweder system- oder benutzerseitig zugewiesene verwaltete Identitäten verwenden.
Es kann schnell zu Verwechslungen kommen, wie Dienstprinzipale und verwaltete Identitäten auf Azure-Ressourcen zugreifen. Um den Unterschied zwischen den beiden zu verstehen, lesen Sie Dienstprinzipale erklärt: Verwaltete Identitäten.
Wenn möglich, verwenden Sie verwaltete Identitäten zur Unterstützung der Authentifizierung, anstatt Dienstprinzipale und Microsoft Entra ID-App-Registrierungen zu verwenden. Sie müssen über die RBAC-Rollen Anwendungsadministrator*in oder Anwendungsentwickler*in verfügen, um Dienstprinzipale und App-Registrierungen erstellen zu können. Diese privilegierten Rollen werden normalerweise dem Plattformteam oder dem Identitätsteam zugewiesen. Verwenden Sie verwaltete Identitäten, damit das Plattformteam keine Dienstprinzipale und App-Registrierungen für Ihr Anwendungsteam erstellen muss.
Sie können die „Verwaltete Identität“ verwenden, um sich bei einem Dienst zu authentifizieren, der die Microsoft Entra-Authentifizierung unterstützt. Allerdings unterstützen nicht alle Dienste verwaltete Identitäten für den Zugriff auf andere Dienste. Bei einigen Diensten kann es erforderlich sein, Anmeldeinformationen zu speichern. Sie sollten Anmeldeinformationen sicher speichern, die gemeinsame Nutzung von Anmeldeinformationen mit anderen Diensten vermeiden und das Prinzip der geringsten Privilegien befolgen. Weitere Informationen finden Sie unter Azure-Dienste, die verwaltete Identitäten für den Zugriff auf andere Dienste verwenden können.
Sie können verwaltete Identitäten mit virtuellen Maschinen (VMs) von Azure verwenden, um sich bei jedem Dienst zu authentifizieren, der die Microsoft Entra ID-Authentifizierung unterstützt. Weitere Informationen finden Sie unter Verwaltete Identitäten für Azure Ressourcen auf einer VM verwenden, um ein Token für den Zugriff zu erwerben.
Es gibt Einschränkungen beim Verschieben von Ressourcen mit verwalteten Identitäten zwischen Abonnements und Regionen. Sie können beispielsweise Ressourcen aus Gründen der Datenhoheit zwischen Abonnements oder Regionen verschieben, wenn Sie eine Fusion, eine Übernahme oder eine Rückführung von Ressourcen durchführen.
Wenn eine Azure-Ressource über von Benutzenden zugewiesene oder vom System zugewiesene Identitäten verfügt, können Sie die Ressource nicht in ein anderes Abonnement oder eine andere Region von Azure übertragen. Sie müssen die verwalteten Identitäten löschen, bevor Sie die Ressource verschieben. Nach der Verschiebung müssen Sie die verwalteten Identitäten neu erstellen und sie der Ressource zuweisen. Weitere Informationen finden Sie unter Verschieben von Ressourcen in eine neue Ressourcengruppe oder ein neues Abonnement.
Wenn Sie ein Abonnement von einem Verzeichnis in ein anderes verschieben, bleiben die verwalteten Identitäten nicht erhalten. Sie müssen die Ressource verschieben und dann manuell die verwalteten Identitäten neu erstellen.
Ähnlich wie bei RBAC-Rollenzuweisungen für Benutzende befolgen Sie das Prinzip der geringsten Privilegien, wenn Sie einer verwalteten Identität Zugriff auf eine Ressource gewähren.
Externe Benutzer
Sie können Szenarien bewerten, bei denen es darum geht, externe Benutzende, Kund*innen oder Partner*innen so einzurichten, dass diese auf Ressourcen zugreifen können. Bestimmen Sie, ob diese Szenarien Microsoft Entra B2B oder Azure Active Directory B2C (Azure AD B2C) Konfigurationen beinhalten. Weitere Informationen finden Sie unter Übersicht über Microsoft Entra External ID.
Entwurfsempfehlungen
Beachten Sie die folgenden Empfehlungen, wenn Sie das Identitäts- und Zugriffsmanagement Ihrer Anwendungen gestalten.
OpenID Connect
Wenn Ihr Anwendungsteam kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) Pipelines verwendet, um Anwendungen programmgesteuert bereitzustellen, konfigurieren Sie die OpenID Connect-Authentifizierung für Ihre Azure Services. OpenID Connect verwendet ein temporäres Token ohne Anmeldeinformationen, um sich bei Azure Services zu authentifizieren. Weitere Informationen finden Sie unter Workload-Identitätsverbund.
Wenn OpenID Connect nicht unterstützt wird, erstellen Sie ein Dienstprinzipal und weisen Sie die erforderlichen Berechtigungen zu, um die Bereitstellung von Infrastruktur- oder Anwendungscode zuzulassen. Weitere Informationen finden Sie im Training Authentifizieren Ihrer Azure-Pipeline zur Bereitstellung mit Dienstprinzipalen.
Attributbasierte Zugriffssteuerung
Um den Zugriff weiter einzuschränken und den unbefugten Zugriff auf Daten zu verhindern, verwenden Sie die attributbasierte Zugriffssteuerung (ABAC), sofern dies unterstützt wird, z. B. mit Azure Blob Storage.
Zugriff auf virtuelle Computer
Verwenden Sie nach Möglichkeit Microsoft Entra ID-Identitäten, um den Zugriff auf virtuelle Maschinen in Azure zu kontrollieren. Verwenden Sie Microsoft Entra ID anstelle einer lokalen Authentifizierung, um den Zugriff auf virtuelle Maschinen zu ermöglichen, und nutzen Sie dabei die Vorteile von Microsoft Entra Conditional Access, Audit-Log-Dateien und Microsoft Entra Multi-Faktor-Authentifizierung (MFA). Diese Konfiguration verringert das Risiko, dass Angreifer*innen unsichere lokale Authentifizierungsdienste ausnutzen. Weitere Informationen finden Sie unter Mit Microsoft Entra ID und OpenSSH in einer virtuellen Maschine von Linux in Azure anmelden und Mit Microsoft Entra ID und ohne Passwort in einer virtuellen Maschine von Windows in Azure anmelden.
Microsoft Identity Platform
Wenn Entwickler*innen eine Cloud-native Anwendung erstellen, sollten sie die Microsoft Identitätsplattform für Entwickler*innen als Identitätsanbieter für ihre Anwendungen verwenden. Die Microsoft Identitätsplattform bietet einen OpenID Connect standardkonformen Authentifizierungsdienst, mit dem Entwickler*innen verschiedene Identitätstypen authentifizieren können, darunter:
Über Microsoft Entra ID bereitgestellte Geschäfts-, Schul- oder Unikonten
Persönliche Microsoft-Konten (Skype, Xbox, Outlook.com)
Soziale oder lokale Konten, unter Verwendung von Microsoft Entra ID
Die Checkliste Bewährte Verfahren und Empfehlungen für die Microsoft-Identitätsplattform enthält Anleitungen zur effektiven Integration der Anwendung mit der Microsoft-Identitätsplattform.
Verwaltete Identitäten
Verwenden Sie verwaltete Identitäten, um den Zugriff auf Azure-Ressourcen zu ermöglichen, für die keine Anmeldeinformationen erforderlich sind.
Sie sollten Anmeldeinformationen oder verwaltete Identitäten nicht für verschiedene Umgebungen oder Anwendungen freigeben. Verwenden Sie beispielsweise keine Identitäten für Produktionsressourcen und auch nicht in Entwicklungs-/Testressourcen, auch nicht für dieselbe Anwendung. Erstellen Sie separate Anmeldeinformationen für jede Instanz einer Anwendung, um die Wahrscheinlichkeit zu verringern, dass eine kompromittierte Testinstanz Auswirkungen auf die Produktionsdaten hat. Getrennte Anmeldeinformationen machen es auch einfacher, Anmeldeinformationen zu widerrufen, wenn sie nicht mehr benötigt werden.
Wenn es erforderlich ist, verwaltete Identitäten in großem Umfang zu nutzen, verwenden Sie eine von Benutzenden zugewiesene verwaltete Identität für jeden Ressourcentyp in jeder Region. Dieser Ansatz verhindert ein Abwandern von Identitäten. Der Azure Monitor Agent benötigt zum Beispiel eine verwaltete Identität auf überwachten Azure VMs, was dazu führen kann, dass Microsoft Entra ID eine beträchtliche Anzahl von Identitäten erstellt (und löscht). Sie können von Benutzenden zugewiesene verwaltete Identitäten einmal erstellen und sie für mehrere VMs freigeben. Verwenden Sie Azure Policy, um diese Empfehlung zu implementieren.
Schlüsseltresor
Sie können Key Vault verwenden, um die Secrets, Schlüssel und Zertifikate zu verwalten, die Anwendungen verwenden.
Um den Zugriff auf Secrets (Datenebene) und für den administrativen Zugriff (Steuerungsebene) zu verwalten, verwenden Sie RBAC.
Um den Zugriff von Anwendungen auf Key Vault zu kontrollieren, verwenden Sie verwaltete Identitäten.
Sie sollten für jede Anwendungsumgebung (Entwicklung, Pre-Production, Produktion) in jeder Region separate Schlüsselspeicher verwenden. Verwenden Sie RBAC, um den Zugriff auf Secrets, Schlüssel und Zertifikate (Vorgänge auf der Datenebene) und den Zugriff auf Key Vault (Steuerungsebene) zu verwalten. Stellen Sie Schlüsselspeicher mit Anwendungs-Secrets in den Landing-Zones der Anwendungen bereit.
Microsoft Entra-Anwendungsproxy
Für den Remote-Zugriff auf Anwendungen mit lokaler Authentifizierung über Microsoft Entra ID verwenden Sie Microsoft Entra Application Proxy. Microsoft Entra Application Proxy bietet einen sicheren Remote-Zugriff auf lokale Webanwendungen, einschließlich Anwendungen, die ältere Authentifizierungsprotokolle verwenden. Nach einem Single Sign-on bei Microsoft Entra ID können die Benutzenden sowohl auf Cloud- als auch auf lokale Anwendungen über eine externe URL oder ein internes Anwendungsportal zugreifen.
Sie können Microsoft Entra Application Proxy als einzelne Instanz in einem Microsoft Entra ID-Mandanten bereitstellen. Für die Konfiguration benötigen Sie mindestens die privilegierte Microsoft Entra ID-Rolle Anwendungsadministrator*in. Wenn Ihre Organisation die Abonnement-Demokratisierung als Rollenzuweisungsmodell verwendet, verfügen die Anwendungsbesitzenden möglicherweise nicht über die erforderlichen Berechtigungen, um Microsoft Entra Application Proxy zu konfigurieren. In diesem Fall sollte das Plattformteam Microsoft Entra Application Proxy für den Anwendungsbesitzenden konfigurieren.
Wenn Sie CI/CD-Pipelines zur Bereitstellung verwenden und über ausreichende Berechtigungen verfügen, können die Anwendungsbesitzenden Microsoft Entra Proxy mit Hilfe der Microsoft Graph-API konfigurieren.
Wenn die Anwendung veraltete Protokolle wie Kerberos verwendet, stellen Sie sicher, dass die Landing-Zone der Anwendung über eine Networking-Verbindung zu den Domänencontrollern im Abonnement der Microsoft-Identitätsplattform verfügt.