Anwendungsidentität und Zugriffsverwaltung

In diesem Artikel werden Überlegungen und Empfehlungen beschrieben, mit denen Anwendungsbesitzer und Entwickler die Identitäts- und Zugriffsverwaltung für cloudeigene Anwendungen entwerfen können.

Wenn Ihr Team cloudeigene Anwendungen migriert oder erstellt, müssen Sie die Authentifizierungs- und Zugriffsanforderungen für die Anwendungen berücksichtigen. Diese Anforderungen bestimmen, wie Benutzer sich bei Anwendungen authentifizieren und wie sich Anwendungsressourcen gegenseitig authentifizieren, z. B. wenn eine Webanwendung auf eine SQL-Datenbank zugreift.

Im Designbereich "Plattformautomatisierung" und "DevOps" empfehlen wir, dass Ihr Anwendungsteam Workloads auf Abonnementverkauf umwandelt. Im Rahmen des Abonnementverkaufsprozesses muss Ihr Anwendungsteam Identitäts- und Zugriffsanforderungen für das Plattformteam bereitstellen, damit sie die entsprechenden Abonnements erstellen können. Anwendungsbesitzer sind für die Identitäts- und Zugriffsverwaltung einzelner Anwendungen verantwortlich. Sie sollten ihre Anwendung mithilfe der zentralen Dienste verwalten, die das Plattformteam bereitstellt.

Entwurfsüberlegungen

Um das Risiko eines nicht autorisierten Zugriffs auf Ihre Anwendungen zu verringern, integrieren Sie die folgenden Überlegungen in Ihr Design.

• Es gibt mehrere Authentifizierungs- und Autorisierungsstandards, z. B. OAuth 2.0, OpenID Connect, JSON-Webtoken (JWTs) und SAML (Security Assertion Markup Language). Bestimmen Sie, welche Authentifizierungs- und Autorisierungsstandards für Ihre Anwendung verwendet werden sollen.

• Wenn Sie eine Anwendungslandzone vom Plattformteam anfordern, können Sie sicherstellen, dass sie die entsprechenden Abonnements erstellen, indem Sie sie die folgenden Fragen stellen:

  • Wie authentifizieren sich Endbenutzer bei der Anwendung und greifen auf sie zu?

  • Wer benötigt rollenbasierte Zugriffssteuerungsberechtigungen (RBAC) für Ressourcen und Dienste, die von der Anwendung verwendet werden?

  • Decken vorhandene integrierte Rollen die RBAC-Zugriffsanforderungen sowohl für den Zugriff auf die Steuerungsebene als auch für den Datenebenenzugriff ab, oder müssen Sie neue benutzerdefinierte Rollen erstellen?

  • Hat das Plattformteam Compliancerichtlinien implementiert, die probleme mit der Anwendung verursachen könnten?

  • Welche Anwendungskomponenten müssen miteinander kommunizieren?

  • Gibt es Anforderungen für den Zugriff auf die freigegebenen Ressourcen, z. B. Microsoft Entra Domain Services, die in der Plattform-Zielzone bereitgestellt werden?

Azure Key Vault und verwaltete Identitäten

• Sicherheitsverletzungen öffentlicher Cloudressourcen stammen häufig aus durchleckten Anmeldeinformationen, die in Code oder anderen Text eingebettet sind. Sie können verwaltete Identitäten und Key Vault verwenden, um programmgesteuerten Zugriff zu implementieren und das Risiko des Diebstahls von Anmeldeinformationen zu verringern.

• Wenn Ihre Anwendung oder Arbeitsauslastung einen Dienst zum sicheren Speichern von Anmeldeinformationen benötigt, können Sie Key Vault verwenden, um geheime Schlüssel, 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 Verwenden von verwalteten Identitäten für Azure-Ressourcen auf einem virtuellen Computer zum Abrufen eines Zugriffstokens.

• Verwaltete Identitäten stellen einen automatisch verwalteten Identitätsprinzipal bereit, den Anwendungen und Ressourcen verwenden, wenn sie eine Verbindung mit Ressourcen herstellen, die die Microsoft Entra ID-Authentifizierung unterstützen. Anwendungen können verwaltete Identitäten verwenden, um Microsoft Entra-ID-Token abzurufen, ohne Anmeldeinformationen verwalten zu müssen.

  • Sie können vom System zugewiesene oder vom Benutzer zugewiesene verwaltete Identitäten verwenden.

  • Es ist einfach zu verwechseln, wie Dienstprinzipale und verwaltete Identitäten auf Azure-Ressourcen zugreifen. Informationen zum Unterschied zwischen den beiden Finden Sie unter Demystifizieren von Dienstprinzipalen – verwaltete Identitäten.

  • Verwenden Sie nach Möglichkeit verwaltete Identitäten, um die Authentifizierung zu unterstützen, anstatt Dienstprinzipale und Microsoft Entra ID-App-Registrierungen zu verwenden. Sie müssen über die Rollen "Anwendungsadministrator" oder "Anwendungsentwickler RBAC" verfügen, um Dienstprinzipale und App-Registrierungen zu erstellen. Diese privilegierten Rollen werden in der Regel dem Plattformteam oder identitätsteam zugewiesen. Verwenden Sie verwaltete Identitäten, um die Notwendigkeit des Plattformteams zu vermeiden, Dienstprinzipale und App-Registrierungen für Ihr Anwendungsteam zu erstellen.

  • Sie können verwaltete Identitäten verwenden, um sich bei jedem Dienst zu authentifizieren, der die Microsoft Entra-Authentifizierung unterstützt. Nicht alle Dienste unterstützen jedoch verwaltete Identitäten für den Zugriff auf andere Dienste. Für einige Dienste kann es erforderlich sein, Anmeldeinformationen zu speichern. Sie sollten Anmeldeinformationen sicher speichern, die Freigabe von Anmeldeinformationen für andere Dienste vermeiden und dem Prinzip der geringsten Berechtigungen folgen. Weitere Informationen finden Sie unter Azure-Dienste, die verwaltete Identitäten verwenden können, um auf andere Dienste zuzugreifen.

  • Sie können verwaltete Identitäten mit virtuellen Azure-Computern (VMs) verwenden, um sich bei jedem Dienst zu authentifizieren, der die Microsoft Entra ID-Authentifizierung unterstützt. Weitere Informationen finden Sie unter Verwenden von verwalteten Identitäten für Azure-Ressourcen auf einem virtuellen Computer zum Abrufen eines Zugriffstokens.

  • Es gibt Einschränkungen beim Verschieben von Ressourcen mit verwalteten Identitäten zwischen Abonnements und Regionen. So können Sie beispielsweise Ressourcen aus Gründen der Datenhoheit zwischen Abonnements oder Regionen für eine Fusion, einen Erwerb oder eine Rückführung von Ressourcen verschieben.

    Wenn eine Azure-Ressource über vom Benutzer zugewiesene oder vom System zugewiesene Identitäten verfügt, können Sie die Ressource nicht in ein anderes Azure-Abonnement oder eine andere Region ü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 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, werden verwaltete Identitäten nicht beibehalten. Sie müssen die Ressource verschieben und dann die verwalteten Identitäten manuell neu erstellen.

  • Ähnlich wie benutzerbasierte RBAC-Rollenzuweisungen folgen Sie dem Prinzip der geringsten Berechtigung , wenn Sie einer Ressource einen verwalteten Identitätszugriff gewähren.

Externe Benutzer

Sie können Szenarien auswerten, die das Einrichten externer Benutzer, Kunden oder Partner umfassen, damit sie auf Ressourcen zugreifen können. Ermitteln Sie, ob diese Szenarien Microsoft Entra B2B - oder Azure Active Directory B2C-Konfigurationen (Azure AD B2C) umfassen. Weitere Informationen finden Sie unter Übersicht über die externe Microsoft Entra-ID.

Designempfehlungen

Berücksichtigen Sie beim Entwerfen der Identitäts- und Zugriffsverwaltung Ihrer Anwendungen die folgenden Empfehlungen.

OpenID Connect

Wenn Ihr Anwendungsteam fortlaufende Integrations- und Kontinuierliche Übermittlungspipelinen (CI/CD) verwendet, um Anwendungen programmgesteuert bereitzustellen, konfigurieren Sie die OpenID Connect-Authentifizierung für Ihre Azure-Dienste. OpenID Connect verwendet ein temporäres, anmeldeinformationsfreies Token, um sich bei Azure-Diensten zu authentifizieren. Weitere Informationen finden Sie unter Workload Identity Federation.

Wenn OpenID Connect nicht unterstützt wird, erstellen Sie einen Dienstprinzipal, und weisen Sie die erforderlichen Berechtigungen zu, um die Bereitstellung von Infrastruktur- oder Anwendungscode zuzulassen. Weitere Informationen finden Sie im Schulungsmodul, authentifizieren Sie Ihre Azure-Bereitstellungspipeline mithilfe von Dienstprinzipalen.

Attributbasierte Zugriffssteuerung

Um den Zugriff weiter einzuschränken und nicht autorisierten Zugriff auf Daten zu verhindern, verwenden Sie die attributbasierte Zugriffssteuerung (ABAC), die 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 Azure-Computer zu steuern. Verwenden Sie Microsoft Entra-ID anstelle der lokalen Authentifizierung, um Zugriff auf virtuelle Computer zu ermöglichen, und nutzen Sie den bedingten Zugriff von Microsoft Entra, die Überwachungsprotokollierung und die mehrstufige Microsoft Entra-Authentifizierung (MFA). Diese Konfiguration reduziert das Risiko, dass Angreifer unsichere lokale Authentifizierungsdienste ausnutzen. Weitere Informationen finden Sie unter Anmelden bei einem virtuellen Linux-Computer in Azure mithilfe von Microsoft Entra ID und OpenSSH und Anmelden bei einem virtuellen Windows-Computer in Azure unter Verwendung der Microsoft Entra-ID einschließlich kennwortfreier Kennwörter.

Microsoft Identity-Plattform

• Wenn Entwickler eine cloudeigene Anwendung erstellen, sollten sie die Microsoft Identity Platform für Entwickler als Identitätsanbieter für ihre Anwendungen verwenden. Die Microsoft Identity Platform bietet einen standardkonformen OpenID Connect-Authentifizierungsdienst, mit dem Entwickler mehrere 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 für bewährte Methoden und Empfehlungen der Microsoft Identity Platform bietet Anleitungen zur effektiven Integration der Anwendung in die Microsoft Identity Platform.

Verwaltete Identitäten

• Um den Zugriff zwischen Azure-Ressourcen zu ermöglichen, die keine Anmeldeinformationen verwenden müssen, verwenden Sie verwaltete Identitäten.

• Sie sollten keine Anmeldeinformationen oder verwalteten Identitäten für verschiedene Umgebungen oder Anwendungen freigeben. Verwenden Sie z. B. keine Identitäten für Produktionsressourcen und auch in Entwicklungs-/Testressourcen, auch für dieselbe Anwendung. Erstellen Sie separate Anmeldeinformationen für jede Instanz einer Anwendung, um die Wahrscheinlichkeit einer kompromittierten Testinstanz zu verringern, die sich auf Produktionsdaten auswirkt. Separate Anmeldeinformationen erleichtern das Widerrufen von Zugriffsrechten, wenn sie nicht mehr benötigt werden.

• Wenn es eine Anforderung gibt, verwaltete Identitäten im großen Maßstab zu verwenden, verwenden Sie eine vom Benutzer zugewiesene verwaltete Identität für jeden Ressourcentyp in den einzelnen Regionen. Dieser Ansatz verhindert einen Wechsel bei Identitäten. Der Azure Monitor-Agent erfordert beispielsweise 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 Benutzern zugewiesene verwaltete Identitäten einmal erstellen und für mehrere virtuelle Computer freigeben. Verwenden Sie Azure-Richtlinie , um diese Empfehlung zu implementieren.

Schlüsselspeicher (Key Vault)

• Sie können Key Vault verwenden, um die geheimen Schlüssel, Schlüssel, Zertifikate zu verwalten, die von Anwendungen verwendet werden.

  • Verwenden Sie RBAC, um den Zugriff auf geheime Schlüssel (Datenebene) und für den administrativen Zugriff (Kontrollebene) zu verwalten.

  • Verwenden Sie verwaltete Identitäten, um den Anwendungszugriff auf Key Vault zu steuern.

• Sie sollten separate Schlüsseltresore für jede Anwendungsumgebung (Entwicklung, Testumgebung, Produktion) in jeder Region verwenden. Verwenden Sie RBAC, um den Zugriff auf geheime Schlüssel, Schlüssel und Zertifikate (Datenebenenvorgänge) und den Zugriff auf Key Vault (Kontrollebene) zu verwalten. Stellen Sie Schlüsseltresore in den Anwendungslandezonen bereit, die Anwendungsgeheimnisse enthalten.

Microsoft Entra-Anwendungsproxy

• Um remote über die Microsoft Entra-ID auf Anwendungen zuzugreifen, die die lokale Authentifizierung verwenden, verwenden Sie den Microsoft Entra-Anwendungsproxy. Der Microsoft Entra-Anwendungsproxy bietet sicheren Remotezugriff auf lokale Webanwendungen, einschließlich Anwendungen, die ältere Authentifizierungsprotokolle verwenden. Nach der einmaligen Anmeldung bei Microsoft Entra-ID können Benutzer über eine externe URL oder ein internes Anwendungsportal auf Cloud- und lokale Anwendungen zugreifen.

  • Sie können den Microsoft Entra-Anwendungsproxy als einzelne Instanz in einem Microsoft Entra ID-Mandanten bereitstellen. Für die Konfiguration ist mindestens die Privilegierte Microsoft Entra-ID-Rolle des Anwendungsadministrators erforderlich. Wenn Ihre Organisation die Abonnementdemokratisierung als Rollenzuweisungsmodell verwendet, verfügen Anwendungsbesitzer möglicherweise nicht über die erforderlichen Berechtigungen zum Konfigurieren des Microsoft Entra-Anwendungsproxys. In diesem Fall sollte das Plattformteam den Microsoft Entra-Anwendungsproxy für den Anwendungsbesitzer konfigurieren.

  • Wenn Sie CI/CD-Bereitstellungspipelinen mit ausreichenden Berechtigungen verwenden, können Anwendungsbesitzer den Microsoft Entra-Anwendungsproxy mithilfe der Microsoft Graph-API konfigurieren.

• Wenn die Anwendung ältere Protokolle verwendet, z. B. Kerberos, stellen Sie sicher, dass die Anwendungslandzone über netzwerkkonnektivität mit Domänencontrollern im Microsoft Identity Platform-Abonnement verfügt.

Nächste Schritte

Ressourcenorganisation