Bearbeiten

Beschränken der Kommunikation zwischen Diensten

Azure
Microsoft Entra ID
Azure App Service

In diesem Beispielszenario wird die Kommunikation zwischen zwei Azure-Back-End-Diensten sowohl auf der Anwendungs- als auch auf der Netzwerkebene eingeschränkt. Die Kommunikation kann nur zwischen Diensten erfolgen, die dies explizit gestatten, wobei das Prinzip der geringsten Rechte gilt. In diesem Beispiel wird Azure App Service zum Hosten der Dienste verwendet, aber Sie können ähnliche Verfahren für Azure Functions-Apps verwenden.

Kommunikationseinschränkungen zwischen Diensten sind nur ein Teil einer allgemeinen Sicherheitsstrategie, die auf sorgfältiger Planung, Bedrohungsmodellierung und dem Security Development Lifecycle basiert. Die allgemeine Sicherheitsplanung sollte Geschäfts-, Compliance-, gesetzliche und andere nicht funktionale Anforderungen einbeziehen.

Mögliche Anwendungsfälle

Während sich das aktuelle Szenario auf Netzwerkeinschränkungen konzentriert, verfolgen viele Unternehmen inzwischen ein Zero-Trust-Sicherheitsmodell, das von einer Sicherheitsverletzung ausgeht, weshalb die Netzwerkebene von untergeordneter Bedeutung ist.

Aufbau

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

Das Diagramm zeigt die eingeschränkte Kommunikation von Dienst A zu Dienst B. Die tokenbasierte Autorisierung schränkt den Zugriff auf der Anwendungsebene ein, und die Dienstendpunkte beschränken den Zugriff auf der Netzwerkebene.

Tokenbasierte Autorisierung

Eine mit OpenID Connect (OIDC) kompatible Bibliothek wie die Microsoft Authentication Library (MSAL) unterstützt diesen tokenbasierten Flow von Clientanmeldeinformationen. Weitere Informationen finden Sie im Szenario: Daemon-App zum Aufrufen von Web-APIs und in der Beispielanwendung für das Daemonszenario.

  1. Sowohl Dienst A als auch Dienst B registrieren sich in Microsoft Entra ID. Dienst A verfügt über Clientanmeldeinformationen entweder in Form eines gemeinsamen Geheimnisses oder eines Zertifikats.
  2. Dienst A kann seine eigenen Clientanmeldeinformationen verwenden, um ein Zugriffstoken für Dienst B anzufordern.
  3. Microsoft Entra ID stellt ein Zugriffstoken mit einer Dienst B-Zielgruppe oder einem aud-Anspruch („audience“) bereit.
  4. Dienst A fügt das Token als Bearertoken in den HTTP-Autorisierungsheader einer Anforderung an Dienst B ein, entsprechend der Verwendungsspezifikation für OAuth 2.0-Bearertoken.
  5. Dienst B überprüft das Token, um sicherzustellen, dass der aud-Anspruch mit der Anwendung von Dienst B übereinstimmt.

Dienst B verwendet eine der folgenden Methoden, um sicherzustellen, dass nur speziell zugelassene Clients, in diesem Fall Dienst A, Zugriff erhalten können:

  • Überprüfen Sie den „appid“-Anspruch für das Token. Dienst B kann den appid-Anspruch des Tokens überprüfen, der angibt, welche bei Microsoft Entra registrierte Anwendung das Token angefordert hat. Dienst B prüft den Anspruch explizit anhand einer Liste bekannten Aufrufer für die Zugriffssteuerung.

  • Überprüfen auf Rollen im Token In ähnlicher Weise kann Dienst B eine Überprüfung auf bestimmte Rollen durchführen, die im eingehenden Token beansprucht werden, um sicherzustellen, dass Dienst A über explizite Zugriffsberechtigungen verfügt.

  • Erfordern der Benutzerzuweisung Alternativ können Besitzer*innen oder Administrator*innen von Dienst B Microsoft Entra ID so konfigurieren, dass eine Benutzerzuweisung erforderlich ist, sodass nur Anwendungen, die über explizite Berechtigungen für die Anwendung von Dienst B verfügen, ein Token für Dienst B erhalten können. Dienst B muss dann keine Überprüfung auf bestimmte Rollen durchführen, es sei denn, die Geschäftslogik erfordert dies.

    So richten Sie eine Benutzerzuweisungsanforderung für den Zugriff auf Dienst B ein

    1. Aktivieren Sie die Benutzerzuweisung in Microsoft Entra ID für Dienst B.
    2. Machen Sie mindestens eine App-Rolle für Dienst B verfügbar, für die Dienst A eine Berechtigung anfordern kann. Die AllowedMemberTypes für diese Rolle müssen Application einbeziehen.
    3. Fordern Sie die App-Berechtigung für Dienst A für die verfügbar gemachte Rolle von Dienst B an.
      1. Wählen Sie im Abschnitt API-Berechtigungen der App-Registrierung von Dienst A die Option Berechtigung hinzufügen und dann die Dienst B-Anwendung aus der Liste aus.
      2. Wählen Sie auf dem Bildschirm API-Berechtigungen anfordern die Option Anwendungsberechtigungen aus, da diese Back-End-Anwendung ohne einen angemeldeten Benutzer ausgeführt wird. Wählen Sie die verfügbar gemachte Rolle von Dienst B und dann Berechtigungen hinzufügen aus.
    4. Erteilen Sie die Administratoreinwilligung für die Anwendungsberechtigungsanforderung von Dienst A. Nur ein Besitzer oder Administrator von Dienst B kann der Berechtigungsanforderung von Dienst A zustimmen.

Dienstendpunkte

Die untere Hälfte des Architekturdiagramms zeigt, wie die dienstübergreifende Kommunikation auf der Netzwerkebene eingeschränkt werden kann:

  1. Die Web-App von Dienst A verwendet die regionale VNet-Integration, um die gesamte ausgehende Kommunikation über eine private IP-Adresse innerhalb des IP-Bereichs des Integrationssubnetzes zu leiten.
  2. Dienst B verfügt über Dienstendpunkte, die eingehende Kommunikation nur von Web-Apps im Integrationssubnetz von Dienst B zulassen.

Weitere Informationen finden Sie unter Einrichten von Azure App Service-Zugriffseinschränkungen.

Komponenten

Dieses Szenario verwendet die folgenden Azure-Dienste:

  • Azure App Service hostet Dienst A und Dienst B und ermöglicht Autoskalierung und Hochverfügbarkeit, ohne eine Infrastruktur verwalten zu müssen.
  • Microsoft Entra ID ist der cloudbasierte Identitäts- und Zugriffsverwaltungsdienst, der Dienste authentifiziert und eine auf OAuth 2.0-Token basierte Autorisierung ermöglicht.
  • Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. Azure Virtual Network lässt Ressourcen wie Azure Virtual Machines (VMs) sicher miteinander, mit dem Internet und mit lokalen Netzwerken kommunizieren.
  • Azure-Dienstendpunkte bieten eine sichere und direkte Konnektivität zu Azure-Diensten über eine optimierte Route im Azure-Backbone-Netzwerk und gestatten den Zugriff nur aus dem Bereich der privaten Quell-IPs im Integrationssubnetz.
  • Microsoft Authentication Library (MSAL) ist eine OIDC-kompatible Bibliothek, mit der ein Dienst Zugriffstoken von Microsoft Entra ID mithilfe eines Clientanmeldeinformationsflows abrufen kann.

Alternativen

Es gibt mehrere Alternativen zum Beispielszenario.

Verwaltete Identität

Anstatt sich als Anwendung bei Microsoft Entra ID zu registrieren, könnte Dienst A eine verwaltete Identität verwenden, um ein Zugriffstoken abzurufen. Die verwaltete Identität befreit Operatoren von der Verwaltung von Anmeldeinformationen für eine App-Registrierung.

Mit einer verwalteten Identität kann Dienst A zwar ein Token abrufen, aber sie stellt keine Microsoft Entra-App-Registrierung bereit. Damit andere Dienste ein Zugriffstoken für Dienst A selbst anfordern können, erfordert Dienst A weiterhin eine Microsoft Entra-App-Registrierung.

Sie können einer App-Rolle keine verwaltete Identität über das Azure-Portal zuweisen, sondern nur über die Azure PowerShell-Befehlszeile. Weitere Informationen finden Sie unter Zuweisen des Zugriffs einer verwalteten Identität auf eine Anwendungsrolle mithilfe von PowerShell.

Azure-Funktionen

Sie können die Dienste in Azure Functions anstelle von App Service hosten. Um den Zugriff auf der Netzwerkebene mithilfe der regionalen VNet-Integration einzuschränken, müssen Sie die Funktions-Apps in einem App Service-Plan oder einem Premium-Plan hosten. Weitere Informationen finden Sie unter Netzwerkoptionen von Azure Functions.

In App Service integrierte Authentifizierung und Autorisierung

Bei diesem Szenario wird der Autorisierungscode mit dem Rest der Geschäftslogik zusammengestellt, indem die Tokenüberprüfung als Teil des Anwendungscodes durchgeführt wird. In App Service integrierte Authentifizierung und Autorisierung oder Easy Auth (einfache Authentifizierung) kann auch eine grundlegende Tokenüberprüfung durchführen, bevor eine Anforderung an einen Dienst gesendet wird. Der Dienst verlässt sich dann auf die Hostinginfrastruktur, um nicht autorisierte Anforderungen zurückzuweisen.

Um die Authentifizierung und Autorisierung von App Service zu konfigurieren, legen Sie das Autorisierungsverhalten auf Mit Microsoft Entra ID anmelden fest. Diese Einstellung überprüft Token und beschränkt den Zugriff nur auf gültige Token.

Der Nachteil bei der Verwendung von Easy Auth (einfache Authentifizierung) ist, dass der Dienst den Authentifizierungs- und Autorisierungsschutz verliert, wenn er verschoben wird. Während die App Service-Authentifizierung und -Autorisierung für einfache Szenarien funktioniert, sollten komplexe Autorisierungsanforderungen eine Logik innerhalb des Anwendungscodes verwenden.

Dienstendpunkte und private Endpunkte

In diesem Szenario werden eher Dienstendpunkte als private Endpunkte verwendet, da nur Dienstendpunkte den Zugriff auf eine Web-App von einem bestimmten Subnetz aus einschränken können. Das Filtern des eingehenden Datenverkehrs auf privaten Endpunkten wird nicht durch Netzwerksicherheitsgruppen (NSGs) oder mithilfe von App Service-Zugriffsbeschränkungen unterstützt. Jeder Dienst mit „Sichtverbindung“ im Netzwerk kann mit dem privaten Endpunkt einer Webanwendung kommunizieren. Dies schränkt die Nützlichkeit privater Endpunkte zum Sperren des Datenverkehrs auf der Netzwerkebene ein.

Überlegungen

  • Die regionale VNet-Integration von App Service bietet ein einzelnes Integrationssubnetz für jeden App Service-Plan. Alle Web-Apps für denselben Plan werden in dasselbe Subnetz integriert und teilen sich denselben Satz an privaten ausgehenden IP-Adressen. Die empfangenden Dienste können nicht unterscheiden, von welcher Web-App der Datenverkehr stammt. Wenn Sie die ursprüngliche Web-App identifizieren müssen, müssen Sie die Web-Apps in separaten App Service-Plänen bereitstellen, jede mit eigenem Integrationssubnetz.

  • Jede Workerinstanz in einem App Service-Plan belegt eine eigene private IP-Adresse innerhalb des Integrationssubnetzes. Um die Skalierung zu planen, stellen Sie sicher, dass das Integrationssubnetz groß genug ist, um die erwartete Skalierung zu ermöglichen.

Kostenoptimierung

Die Preise für dieses Szenario hängen von Ihrer spezifischen Infrastruktur und Ihren Anforderungen ab. Microsoft Entra ID verfügt über Free- bis Premium-Tarife für verschiedene Anforderungen. Die Kosten für Azure App Service oder andere Hosts hängen von Ihren spezifischen Skalierungs- und Sicherheitsanforderungen ab, wie in Alternativen und Überlegungen beschrieben.

Informationen zum Berechnen der Kosten für Ihr Szenario finden Sie im Azure-Preisrechner.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Nächste Schritte