Verfügbarmachen von Azure Spring Apps über einen Reverseproxy

Wenn Sie Ihre Apps oder Microservices in Azure Spring Apps hosten, möchten Sie sie wahrscheinlich nicht immer direkt im Internet veröffentlichen. Möglicherweise möchten Sie sie stattdessen über einen Reverseproxy verfügbar machen. Mit diesem Ansatz können Sie einen Dienst vor Ihren Apps platzieren. Der Dienst kann übergreifende Funktionen wie WAF-Funktionen (Web Application Firewall) zur Sicherung Ihrer Anwendungen, Lastenausgleich, Routing, Anforderungsfilterung und Ratenbegrenzung definieren.

Wenn Sie einen gemeinsamen Reverseproxydienst wie Azure Application Gateway oder Azure Front Door vor Azure Spring Apps bereitstellen, sollten Sie sicherstellen, dass Ihre Apps nur über den Reverseproxy erreichbar sind. Diese Sicherheitsmaßnahme verhindert, dass böswillige Benutzer die WAF oder Drosselungsgrenzwerte umgehen können.

Azure DDoS Protection, kombiniert mit bewährten Methoden für den Anwendungsentwurf, bietet erweiterte Features zur DDoS-Risikominderung, um besser vor DDoS-Angriffen zu schützen. Sie sollten Azure DDOS Protection in allen virtuellen Umkreisnetzwerken aktivieren.

In diesem Artikel wird beschrieben, wie Zugriffseinschränkungen erzwungen werden, damit in Azure Spring Apps gehostete Anwendungen nur über einen Reverseproxydienst zugänglich sind. Die empfohlene Methode zum Erzwingen dieser Einschränkungen hängt davon ab, wie Sie Ihre Azure Spring Apps-Instanz bereitstellen und welchen Reverseproxy Sie verwenden. Je nachdem, ob die Bereitstellung innerhalb oder außerhalb eines virtuellen Netzwerks erfolgt, sind unterschiedliche Punkte zu berücksichtigen. Dieser Artikel enthält Informationen zu vier Szenarien.

• Bereitstellen von Azure Spring Apps innerhalb eines virtuellen Netzwerks und privater Zugriff auf Ihre Apps innerhalb des Netzwerks.

  • Sie besitzen die Kontrolle über das VNet, in dem Ihre Apps ausgeführt werden. Verwenden nativer Azure-Netzwerkfeatures wie Netzwerksicherheitsgruppen (NSGs), um den Zugriff zu sperren und nur Ihren Reverseproxy zuzulassen.

  • Sie können Ihre Apps mithilfe von Azure Application Gateway öffentlich im Internet verfügbar machen und dann entsprechende Zugriffseinschränkungen anwenden, um sie zu sperren. Dieser Ansatz wird in Szenario 1 weiter unten in diesem Artikel beschrieben.

  • Sie können Azure Front Door nicht direkt verwenden, da der Dienst die Azure Spring Apps-Instanz in Ihrem privaten VNet nicht erreichen kann. Azure Front Door kann nur über eine öffentliche IP-Adresse oder über Dienste, die einen privaten Endpunkt verwenden, eine Verbindung mit Back-Ends herstellen. Wenn Sie über eine Bereitstellung von Azure Spring Apps in mehreren Regionen verfügen und einen globalen Lastenausgleich benötigen, können Sie Ihre Azure Spring Apps-Instanzen dennoch über Application Gateway verfügbar machen. Um dieses Szenario zu erreichen, platzieren Sie Azure Front Door vor Application Gateway. Dieser Ansatz wird in Szenario 2 weiter unten in diesem Artikel beschrieben.

• Bereitstellen von Azure Spring Apps außerhalb eines virtuellen Netzwerks und Veröffentlichen Ihrer Apps direkt im Internet, wenn Sie ihnen einen Endpunkt zuweisen.

  • Sie besitzen keine Kontrolle über das Netzwerk und können den Zugriff nicht über NSGs einschränken. Damit nur der Reverseproxy Zugriff auf Ihre Apps erhält, ist ein Ansatz innerhalb von Azure Spring Apps selbst erforderlich.

  • Da Ihre Anwendungen öffentlich erreichbar sind, können Sie Application Gateway oder Azure Front Door als Reverseproxy verwenden. Der Ansatz mit Application Gateway wird weiter unten in diesem Artikel in Szenario 3 beschrieben. Der Ansatz mit Azure Front Door wird weiter unten in diesem Artikel in Szenario 4 beschrieben.

  • Sie können bei Bedarf eine Kombination aus beiden Ansätzen verwenden. Wenn Sie Application Gateway und Azure Front Door verwenden, wenden Sie dieselben Zugriffsbeschränkungen zwischen den beiden Reverseproxys wie in Szenario 2 an.

Szenariovergleich

Die folgende Tabelle enthält einen kurzen Vergleich der vier Reverseproxy-Konfigurationsszenarien für Azure Spring Apps. Ausführliche Informationen zu jedem Szenario finden Sie im entsprechenden Abschnitt dieses Artikels.

Bereitstellung in Ihrem virtuellen Netzwerk

Wenn Azure Spring Apps in einem virtuellen Netzwerk bereitgestellt wird, werden zwei Subnetze verwendet:

• Ein Dienstlaufzeitsubnetz, das die relevanten Netzwerkressourcen enthält
• Ein Apps-Subnetz, das Ihren Code hostet

Da das Dienstlaufzeitsubnetz den Lastenausgleich enthält, über den Sie eine Verbindung mit den Apps herstellen, können Sie eine NSG für dieses Subnetz definieren, damit nur Datenverkehr von Ihrem Reverseproxy zugelassen wird. Wenn den gesamten anderen Datenverkehr blockieren, kann niemand im VNet auf Ihre Apps zugreifen, ohne den Reverseproxy zu verwenden.

Jede App, die Sie über Ihren Reverseproxy bereitstellen möchten, sollte einen zugewiesenen Endpunkt aufweisen, damit der Reverseproxy die App im virtuellen Netzwerk erreichen kann. Außerdem sollten Sie für jede App auch die von ihr verwendeten benutzerdefinierten Domänen zuordnen, damit Sie nicht den HTTP-Header Host im Reverseproxy überschreiben müssen, sondern den ursprünglichen Hostnamen beibehalten können. Diese Methode vermeidet Probleme wie fehlerhafte Cookies oder nicht ordnungsgemäß funktionierende Umleitungs-URLs. Weitere Informationen finden Sie unter Beibehalten von Hostnamen.

Szenario 1: Verwenden von Application Gateway als Reverseproxy

Szenario 1 beschreibt, wie Sie Ihre Apps mithilfe von Application Gateway öffentlich im Internet zugänglich machen und dann die entsprechenden Zugriffsbeschränkungen zum Sperren anwenden.

Die folgende Abbildung zeigt die Architektur für Szenario 1:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Wenn Application Gateway sich vor Ihrer Azure Spring Apps-Instanz befindet, verwenden Sie den zugewiesenen Endpunkt der Spring Cloud Gateway-App als Back-End-Pool. Ein Beispielendpunkt ist myspringcloudservice-myapp.private.azuremicroservices.io. Der Endpunkt wird in eine private IP-Adresse im Dienstlaufzeitsubnetz aufgelöst. Um den Zugriff einzuschränken, können Sie daher eine NSG im Subnetz der Dienstruntime mit den folgenden Sicherheitsregeln für eingehenden Datenverkehr platzieren (und der Verweigerungsregel die niedrigste Priorität zuweisen):

Die Konfiguration von Szenario 1 stellt sicher, dass das Subnetz der Dienstlaufzeit nur Datenverkehr aus den folgenden Quellen zulässt:

• Aus dem dedizierten Application Gateway-Subnetz
• Aus dem Apps-Subnetz (bidirektionale Kommunikation zwischen den beiden Azure Spring Apps-Subnetzen erforderlich)
• Von Azure Load Balancer (eine allgemeine Azure-Plattformanforderung)

Sämtlicher anderer Datenverkehr wird blockiert.

Szenario 2: Verwenden von Azure Front Door und Application Gateway als Reverseproxy

Wie bereits erwähnt, können Sie Azure Front Door nicht direkt vor Azure Spring Apps platzieren, da der Dienst nicht auf Ihr privates VNet zugreifen kann. (Azure Front Door Standard oder Premium kann eine Verbindung mit privaten Endpunkten in einem virtuellen Netzwerk herstellen, aber Azure Spring Apps bietet derzeit keine Unterstützung für private Endpunkte.) Wenn Sie Azure Front Door dennoch verwenden möchten, z. B. um globalen Lastenausgleich zwischen mehreren Instanzen von Azure Spring Apps in verschiedenen Azure-Regionen zu erreichen, können Sie Ihre Apps weiterhin über Application Gateway bereitstellen. Um dieses Szenario zu erreichen, platzieren Sie Azure Front Door vor Application Gateway.

Die folgende Abbildung zeigt die Architektur für Szenario 2:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Konfiguration von Szenario 2 implementiert Zugriffsbeschränkungen zwischen Application Gateway und Azure Spring Apps auf die gleiche Weise wie Szenario 1. Sie platzieren eine NSG im Subnetz der Dienstlaufzeit mit den entsprechenden Regeln.

In Szenario 2 müssen Sie auch sicherstellen, dass Application Gateway Datenverkehr akzeptiert, der nur von Ihrer Azure Front Door-Instanz stammt. In der Dokumentation zu Azure Front Door wird erläutert, wie Sie den Zugriff auf ein Back-End sperren, um nur Azure Front Door-Datenverkehr zuzulassen. Wenn das Back-End Application Gateway ist, können Sie diese Einschränkung wie folgt implementieren:

• Erstellen Sie im Application Gateway-Subnetz eine NSG, die nur Datenverkehr mit dem Diensttag AzureFrontDoor.Backend zulässt (ausschließlich Azure Front Door besitzt Zugriff auf Application Gateway). Achten Sie darauf, auch die anderen erforderlichen Diensttags hinzuzufügen, wie in den NSG-Einschränkungen für Application Gateway beschrieben.
• Erstellen Sie eine benutzerdefinierte WAF-Regel in Application Gateway, die überprüft, ob der HTTP-Header X-Azure-FDID die spezifische ID Ihrer Azure Front Door-Instanz enthält. Diese Methode verhindert, dass Azure Front Door-Instanzen anderer Organisationen, die dieselben IP-Adressbereiche verwenden, Ihre Application Gateway-Instanz erreichen können.

Bereitstellung außerhalb Ihres virtuellen Netzwerks

Wenn Sie Azure Spring Apps außerhalb eines VNet bereitstellen, können Sie keine nativen Azure-Netzwerkfeatures verwenden, da Sie das Netzwerk nicht selbst steuern. Stattdessen müssen Sie die erforderlichen Zugriffseinschränkungen auf die Apps selbst anwenden, damit nur Datenverkehr vom Reverseproxy zugelassen wird. Bei sehr vielen Apps kann dieser Ansatz die Komplexität erhöhen, und es besteht das Risiko, dass nicht jede App richtig konfiguriert werden kann.

Verwenden von Spring Cloud Gateway zum Verfügbarmachen und Schützen Ihrer Apps

Um den Entwicklern einzelner Anwendungen die Verantwortung für die Zugriffssteuerung abzunehmen, können Sie mithilfe von Spring Cloud Gateway übergreifende Beschränkungen anwenden. Spring Cloud Gateway ist ein häufig verwendetes Spring-Projekt, das Sie wie jede andere App in Azure Spring Apps bereitstellen können. Mithilfe von Spring Cloud Gateway können Sie Ihre eigenen Anwendungen innerhalb der Azure Spring Apps-Instanz privat halten und sicherstellen, dass nur über die freigegebene Spring Cloud Gateway-App darauf zugegriffen werden kann. Anschließend konfigurieren Sie diese App über Routenprädikate, die ein integriertes Feature von Spring Cloud Gateway sind, mit den erforderlichen Zugriffseinschränkungen. Routenprädikate können verschiedene Attribute der eingehenden HTTP-Anforderung verwenden, um zu bestimmen, ob die Anforderung an die Back-End-Anwendung weitergeleitet oder abgelehnt werden soll. Das Prädikat kann Attribute wie die Client-IP-Adresse, die Anforderungsmethode oder den Pfad, HTTP-Header usw. verwenden.

Dieses Muster wird häufig verwendet. Für die Zwecke dieses Artikels wird davon ausgegangen, dass Sie Ihre Anwendungen über Spring Cloud Gateway verfügbar machen. Wir erwarten, dass Sie die Routenprädikate verwenden, um die notwendigen Zugriffsbeschränkungen festzulegen, damit nur Anforderungen vom Reverseproxy zugelassen werden. Selbst wenn Sie nicht Spring Cloud Gateway verwenden, gelten die gleichen allgemeinen Prinzipien. Sie müssen jedoch eigene Funktionen zum Filtern von Anforderungen in Ihren Apps erstellen, die auf demselben HTTP-Header X-Forwarded-For beruhen, der weiter oben in diesem Artikel erläutert wird.

Die Beschreibung der Funktionsweise von Spring Cloud Gateway würden den Rahmen dieses Artikels sprengen. Es handelt sich um einen äußerst flexiblen Dienst, den Sie über Code oder die Konfiguration anpassen können. Der Einfachheit halber wird in diesem Artikel nur der rein konfigurationsgesteuerte Ansatz beschrieben, der keine Codeänderungen erfordert. Sie können diesen Ansatz implementieren, indem Sie die herkömmliche Datei application.properties oder application.yml in die bereitgestellte Spring Cloud Gateway-App einfügen. Sie können die Implementierung dieses Ansatzes auch mit Config Server in Azure Spring Apps erreichen, wodurch diese Konfigurationsdatei in ein Git-Repository ausgelagert wird. In den folgenden Beispielen implementieren wir den application.yml-Ansatz mit YAML-Syntax, aber die entsprechende application.properties-Syntax funktioniert auch.

Weiterleiten von Anforderungen an Ihre Anwendungen

Wenn Ihrer App in Azure Spring Apps kein Endpunkt zugewiesen oder keine benutzerdefinierte Domäne konfiguriert wurde, ist sie von außen nicht erreichbar. Wenn sich eine App selbst bei der Spring Cloud Service Registry registriert, kann Spring Cloud Gateway die App entdecken und dann mit Routingregeln Datenverkehr an die richtige Ziel-App weiterleiten.

Daher ist die einzige App, der in der App ein Endpunkt in Azure Spring Apps zugewiesen werden muss, Ihre Spring Cloud Gateway-App. Über diesen Endpunkt ist sie extern erreichbar. Sie sollten den anderen Apps keinen Endpunkt zuweisen. Andernfalls können die Apps direkt und nicht über Spring Cloud Gateway erreicht werden, wodurch wiederum der Reverseproxy umgangen werden kann.

Eine einfache Möglichkeit, alle registrierten Apps über Spring Cloud Gateway verfügbar zu machen, ist die Verwendung des DiscoveryClient-Routendefinitionslocators wie folgt:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

Alternativ können Sie bestimmte Apps selektiv über Spring Cloud Gateway verfügbar machen, indem Sie App-spezifische Routen definieren:

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

Sowohl mit dem Ermittlungslocator als auch mit expliziten Routendefinitionen können Sie Routenprädikate verwenden, um ungültige Anforderungen abzulehnen. In diesem Fall verwenden Sie diese Funktion, um Anforderungen zu blockieren, die nicht vom erwarteten Reverseproxy vor Azure Spring Apps stammen.

Einschränken des Zugriffs mit dem X-Forwarded-For-HTTP-Header

Wenn Sie eine App in Azure Spring Apps bereitstellen, stellt der HTTP-Client oder Reverseproxy keine direkte Verbindung mit der App her. Der Netzwerkdatenverkehr durchläuft zuerst einen internen Eingangsdatencontroller.

Aufgrund des zusätzlichen Diensts ist die IP-Adresse des direkten Netzwerkclients immer eine interne Azure Spring Apps-Komponente. Die IP-Adresse ist niemals der logische Client wie der Reverseproxy, von dem Sie erwarten, dass er Ihre App aufruft. Sie können die Client-IP-Adresse nicht für Zugriffseinschränkungen verwenden. Auch können Sie das integrierte Routenprädikat RemoteAddr von Spring Cloud Gateway nicht für die Anforderungsfilterung verwenden, da es standardmäßig die Client-IP-Adresse verwendet.

Glücklicherweise fügt Azure Spring Apps immer die IP-Adresse des logischen Clients dem HTTP-Header X-Forwarded-For der Anforderung an Ihre App hinzu. Der letzte Wert (ganz rechts) des Headers X-Forwarded-For enthält immer die IP-Adresse des logischen Clients.

Um Anforderungen basierend auf dem X-Forwarded-For-Header zu filtern, können Sie das integrierte XForwarded Remote Addr-Routenprädikat verwenden. Mit diesem Prädikat können Sie eine Liste der IP-Adressen oder IP-Bereiche Ihres Reverseproxys konfigurieren, die als äußerster rechter Wert zulässig sind.

Konfigurieren Ihrer App zum Verwenden des richtigen Hostnamens und der richtigen Anforderungs-URL

Wenn Sie Spring Cloud Gateway verwenden, müssen Sie einen wichtigen Faktor berücksichtigen. Spring Cloud Gateway legt den HTTP-Header Host für die ausgehende Anforderung auf die interne IP-Adresse Ihrer App-Instanz fest, beispielsweise auf Host: 10.2.1.15:1025. Der für Ihren Anwendungscode verfügbare Hostname der Anforderung ist nicht mehr der ursprüngliche Hostname der Anforderung, die vom Browser gesendet wurde (z. B. contoso.com). In einigen Fällen kann dieses Ergebnis zu Problemen führen, z. B. zu fehlerhaften Cookies oder Umleitungs-URLs, die nicht ordnungsgemäß funktionieren. Weitere Informationen zu diesen Problemen und zum Konfigurieren eines Reverseproxydiensts wie Application Gateway oder Azure Front Door, um sie zu vermeiden, finden Sie unter Beibehalten von Hostnamen.

Spring Cloud Gateway gibt den ursprünglichen Hostnamen im Forwarded-Header an. Außerdem werden andere Header wie X-Forwarded-Port, X-Forwarded-Proto und X-Forwarded-Prefix festgelegt, damit Ihre Anwendung sie verwenden kann, um die ursprüngliche Anforderungs-URL zu rekonstruieren. In Spring Framework-Anwendungen können Sie diese Konfiguration automatisch erreichen, indem Sie die Einstellung server.forward-headers-strategy in Ihren Anwendungseigenschaften auf FRAMEWORK festlegen. (Legen Sie diesen Wert nicht auf NATIVE fest. Andernfalls werden andere Header verwendet, die den erforderlichen X-Forwarded-Prefix-Header nicht berücksichtigen.) Weitere Informationen finden Sie unter Ausführung hinter einem Front-End-Proxyserver. Bei dieser Konfiguration berücksichtigt die HttpServletRequest.getRequestURL-Methode alle diese Header und gibt die genaue Anforderungs-URL zurück, die vom Browser gesendet wurde.

Szenario 3: Verwenden von Application Gateway mit Spring Cloud Gateway

Szenario 3 beschreibt, wie sie Application Gateway als Reverseproxy für öffentlich erreichbare Apps über einen Spring Cloud Gateway-Endpunkt verwenden.

Die folgende Abbildung zeigt die Architektur für Szenario 3:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Wenn Application Gateway sich vor Ihrer Azure Spring Apps-Instanz befindet, verwenden Sie den zugewiesenen Endpunkt der Spring Cloud Gateway-App als Back-End-Pool. Ein Beispielendpunkt ist myspringcloudservice-mygateway.azuremicroservices.io. Da die Azure Spring Apps-Bereitstellung außerhalb eines virtuellen Netzwerks erfolgt, wird diese URL in eine öffentliche IP-Adresse aufgelöst. Wenn der Back-End-Pool ein öffentlicher Endpunkt ist, verwendet Application Gateway die öffentliche IP-Adresse des Front-Ends, um den Back-End-Dienst zu erreichen.

Um zuzulassen, dass nur Anforderungen von Ihrer Application Gateway-Instanz Spring Cloud Gateway erreichen, können Sie das XForwarded Remote Addr-Routenprädikat konfigurieren. Konfigurieren Sie das Prädikat so, dass nur Anforderungen von der dedizierten öffentlichen IP-Adresse Ihrer Application Gateway-Instanz zugelassen werden, wie im folgenden Beispiel gezeigt:

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

Szenario 4: Verwenden von Azure Front Door mit Spring Cloud Gateway

Szenario 4 beschreibt, wie sie Azure Front Door als Reverseproxy für öffentlich erreichbare Apps über einen Spring Cloud Gateway-Endpunkt verwenden.

Die folgende Abbildung zeigt die Architektur für Szenario 4:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ähnlich wie bei Szenario 3 verwendet diese Konfiguration die öffentliche URL der Spring Cloud Gateway-App als Back-End-Pool oder Ursprung in Azure Front Door. Ein Beispielendpunkt ist https://myspringcloudservice-mygateway.azuremicroservices.io.

Da Azure Front Door ein globaler Dienst mit vielen Edgestandorten ist, verwendet er viele IP-Adressen für die Kommunikation mit seinem Back-End-Pool. In der Dokumentation zu Azure Front Door wird beschrieben, wie Sie den Zugriff auf ein Back-End sperren, um nur Azure Front Door-Datenverkehr zuzulassen. In diesem Szenario verwalten Sie jedoch nicht das Azure-Netzwerk, in dem Ihre Apps bereitgestellt werden. Leider können Sie nicht das Diensttag AzureFrontDoor.Backend verwenden, um eine vollständige Liste der ausgehenden Azure Front Door-IP-Adressen abzurufen, die garantiert auf dem neuesten Stand sind. Stattdessen müssen Sie Azure-IP-Adressbereiche und Diensttags herunterladen, den Abschnitt AzureFrontDoor.Backend suchen und alle IP-Adressbereiche aus dem Array addressPrefixes in die Konfiguration des XForwarded Remote Addr-Routenprädikats kopieren.

Da die Azure Front Door-IP-Adressbereiche auch von anderen Organisationen verwendet werden, müssen Sie darüber hinaus sicherstellen, dass Sie den Zugriff auf Ihre spezifische Azure Front Door-Instanz beschränken. Verwenden Sie dazu den HTTP-Header X-Azure-FDID, der Ihre eindeutige Front Door ID enthält. Sie können den Zugriff einschränken, indem Sie das Header-Routenprädikat verwenden, das nur Anforderungen zulässt, wenn ein festgelegter HTTP-Header einen bestimmten Wert aufweist.

In diesem Szenario könnte Ihre Spring Cloud Gateway-Routenprädikatkonfiguration wie im folgenden Beispiel aussehen:

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

Beitragende

Microsoft pflegt diesen Inhalt. Der folgende Mitwirkende hat den ursprünglichen Inhalt entwickelt.

Hauptautor:

• Jelle Druyts | Principal Customer Engineer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Azure Spring Apps-Referenzarchitektur
• Kundenzuständigkeiten für die Ausführung von Azure Spring Apps in virtuellen Azure-Netzwerken

Zugehörige Ressourcen

• Beibehaltung des Hostnamens
• Optionen für den Lastenausgleich
• Architekturstil für Microservices