Implementieren eines Zero Trust-Netzwerks für Webanwendungen mithilfe von Azure Firewall und Azure Application Gateway

In diesem Artikel wird beschrieben, wie Zero Trust-Sicherheit für Web-Apps implementiert wird, um die Überprüfung und End-to-End-Verschlüsselung zu ermöglichen. Das Zero Trust-Modell enthält viele andere Konzepte, z. B. die kontinuierliche Identitätsüberprüfung und die Minimierung der Größe der impliziten Vertrauensbereiche.

Dieser Artikel konzentriert sich auf die Verschlüsselungs- und Inspektionskomponente einer Zero Trust-Architektur für eingehenden Datenverkehr aus dem öffentlichen Internet. Weitere Informationen zu anderen Aspekten der sicheren Bereitstellung Ihrer Anwendung, z. B. Authentifizierung und Autorisierung, finden Sie in der Zero Trust-Dokumentation. Im Beispiel in diesem Artikel wird ein mehrschichtiger Ansatz verwendet. Bei einem mehrschichtigen Ansatz besteht die Netzwerksicherheit aus einer der Ebenen des Zero Trust-Modells. Auf dieser Ebene werden Pakete von Netzwerkappliances überprüft, um sicherzustellen, dass die Anwendungen nur legitimer Datenverkehr erreicht.

In der Regel werden verschiedene Aspekte von Netzwerkpaketen durch verschiedene Arten von Netzwerkappliances untersucht:

• Web Application Firewalls suchen nach Mustern, die auf einen Angriff auf die Webanwendungsebene hindeuten.

• Firewalls der nächsten Generation können auch nach generischen Bedrohungen suchen.

Diese Architektur konzentriert sich auf ein gängiges Muster zur Maximierung der Sicherheit, bei dem Azure Application Gateway Datenverkehr prüft und verarbeitet, bevor sie Azure Firewall Premium erreicht. In einigen Szenarien können Sie verschiedene Arten von Netzwerksicherheitsgeräten kombinieren, um den Schutz zu erhöhen. Weitere Informationen finden Sie unter Azure Firewall and Application Gateway für virtuelle Netzwerke.

Architektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

In dieser Architektur wird das TLS-Protokoll (Transport Layer Security) verwendet, um Datenverkehr bei jedem Schritt zu verschlüsseln.

1. Ein Client sendet Pakete an Application Gateway (ein Lastenausgleichsmodul). Sie wird mit der optionalen Ergänzung der Azure-Webanwendungsfirewall ausgeführt.

2. Von Application Gateway werden die Pakete entschlüsselt und auf Bedrohungen für Webanwendungen untersucht. Wenn keine Bedrohungen gefunden werden, verwendet sie Zero Trust-Prinzipien, um die Pakete zu verschlüsseln. Anschließend werden sie freigegeben.

3. Azure Firewall Premium führt die folgenden Sicherheitsprüfungen aus:

   • DIE TLS-Inspektion entschlüsselt und untersucht die Pakete.
   • IDPS-Funktionen (Intrusion Detection and Prevention System) überprüfen die Pakete auf böswillige Absichten.

4. Wenn die Pakete die Tests bestehen, werden von Azure Firewall Premium die folgenden Schritte ausgeführt:

   • Es verschlüsselt die Pakete.
   • Er verwendet einen DNS-Dienst (Domain Name System), um den virtuellen Computer (VM) der Anwendung zu ermitteln.
   • Sie leitet die Pakete an den virtuellen Anwendungscomputer weiter.

Die Integrität des Datenverkehrs wird in dieser Architektur durch verschiedene Untersuchungsengines sichergestellt:

• Die Azure-Webanwendungsfirewall verwendet Regeln, um Angriffe auf der Webebene zu verhindern. Beispiele für Angriffe sind die Einschleusung von SQL-Befehlen sowie Cross-Site Scripting. Weitere Informationen zu Regeln und zum Open Worldwide Application Security Project (OWASP) Core Rule Set (CRS) finden Sie unter Webanwendungsfirewall CRS-Regelgruppen und -regeln.

• Von Azure Firewall Premium werden generische Regeln zur Angriffserkennung und -verhinderung verwendet. Diese Regeln helfen dabei, schädliche Dateien und andere auf Webanwendungen ausgerichtete Bedrohungen zu identifizieren.

Diese Architektur unterstützt die folgenden Arten von Netzwerkdesigns, die in diesem Artikel erläutert werden:

• Herkömmliche Hub-and-Spoke-Netzwerke
• Netzwerke mit Azure Virtual WAN als Plattform
• Netzwerke mit Azure Route Server zur Vereinfachung des dynamischen Routings

Azure Firewall Premium und Namensauflösung

Wenn Azure Firewall Premium auf böswilligen Datenverkehr überprüft, wird überprüft, ob der HTTP-Hostheader mit der Paket-IP-Adresse und dem TCP-Port (Transmission Control Protocol) übereinstimmt. Angenommen, von Application Gateway werden Webpakete an die IP-Adresse 172.16.1.4 und den TCP-Port 443 gesendet. Der Wert des HTTP-Hostheaders muss in diese IP-Adresse aufgelöst werden.

HTTP-Hostheader enthalten in der Regel keine IP-Adressen. Stattdessen enthalten die Header Namen, die dem digitalen Zertifikat des Servers entsprechen. In diesem Fall wird der Hostheadername durch Azure Firewall Premium per DNS in eine IP-Adresse aufgelöst. Das Netzwerkdesign bestimmt, welche DNS-Lösung am besten funktioniert.

Digitale Zertifikate

Das folgende Diagramm zeigt die allgemeinen Namen (CNs) und Zertifizierungsstellen (CAs), die von den TLS-Sitzungen und Zertifikaten dieser Architektur verwendet werden.

Azure Firewall generiert dynamisch eigene Zertifikate. Diese Funktion ist einer der Hauptgründe, warum sie hinter dem Anwendungsgateway platziert wird. Andernfalls wird der Anwendungsclient mit selbst generierten Zertifikaten konfrontiert, die als Sicherheitsrisiko gekennzeichnet sind.

TLS-Verbindungen

Diese Architektur enthält drei unterschiedliche TLS-Verbindungen. Digitale Zertifikate validieren jedes einzelne.

Von Clients zu Application Gateway

In Application Gateway stellen Sie das digitale Zertifikat bereit, das Clients präsentiert wird. Ein solches Zertifikat wird in der Regel durch eine bekannte Zertifizierungsstelle wie DigiCert oder Let's Encrypt ausgestellt. Dieser Mechanismus unterscheidet sich grundlegend davon, wie azure Firewall digitale Zertifikate dynamisch aus einer selbstsignierten oder internen Public Key-Infrastruktur-Zertifizierungsstelle generiert.

Von Application Gateway zu Azure Firewall Premium

Von Azure Firewall Premium werden dynamisch Zertifikate generiert, um TLS-Datenverkehr zu entschlüsseln und zu untersuchen. Außerdem präsentiert sich Azure Firewall Premium gegenüber Application Gateway als Webserver. Die von Azure Firewall Premium generierten Zertifikate werden von einer privaten Zertifizierungsstelle signiert. Weitere Informationen finden Sie unter Azure Firewall Premium-Zertifikate. Diese Zertifikate müssen von Application Gateway überprüft werden. Die von Azure Firewall Premium verwendete Stammzertifizierungsstelle muss in den HTTP-Einstellungen der Anwendung konfiguriert werden.

Von Azure Firewall Premium zum Webserver

Von Azure Firewall Premium wird eine TLS-Sitzung mit dem Zielwebserver eingerichtet. Von Azure Firewall Premium wird überprüft, ob die TLS-Pakete des Webservers von einer bekannten Zertifizierungsstelle signiert werden.

Komponentenrollen

Zertifikate werden von Application Gateway und Azure Firewall Premium unterschiedlich behandelt, da sich ihre Rollen unterscheiden:

• Application Gateway ist ein Reverse-Webproxy. Er fängt HTTP- und HTTPS-Anforderungen ab, um Webserver vor schädlichen Clients zu schützen. Sie deklarieren jeden geschützten Server, der sich im Back-End-Pool von Application Gateway befindet, mit der zugehörigen IP-Adresse oder dem vollqualifizierten Domänennamen. Legitime Clients sollten auf jede Anwendung zugreifen können. Daher konfigurieren Sie das Anwendungsgateway mit einem digitalen Zertifikat, das von einer öffentlichen Zertifizierungsstelle signiert wird. Verwenden Sie eine Zertifizierungsstelle, die jeder TLS-Client akzeptiert.

• Azure Firewall Premium ist ein Weiterleitungswebproxy (oder einfach ein Webproxy). Er fängt von den geschützten Clients übermittelte TLS-Aufrufe ab, um Clients vor schädlichen Webservern zu schützen. Wenn ein geschützter Client eine HTTP-Anforderung sendet, führt der Forward-Proxy den Identitätswechsel durch, indem er den Zielwebserver imitiert und digitale Zertifikate generiert, die dem Client präsentiert werden. Von Azure Firewall Premium wird eine private Zertifizierungsstelle verwendet, die die dynamisch generierten Zertifikate signiert. Sie konfigurieren die geschützten Clients so, dass sie dieser privaten Zertifizierungsstelle vertrauen. In dieser Architektur werden von Azure Firewall Premium Anforderungen geschützt, die von Application Gateway an den Webserver gesendet werden. Application Gateway vertraut der privaten Zertifizierungsstelle, die von Azure Firewall Premium verwendet wird.

Routing und Weiterleitung von Datenverkehr

Das Routing unterscheidet sich geringfügig je nach Topologie des Netzwerkentwurfs. In den folgenden Abschnitten werden Beispiele für Hub- und Speichen-, Virtuelle WAN- und Routingservertopologien beschrieben. Alle Topologien haben die folgenden Aspekte gemeinsam:

• Das Anwendungsgateway dient immer als Proxy. Azure Firewall Premium dient auch als Proxy, wenn sie für die TLS-Inspektion konfiguriert ist. Das Anwendungsgateway beendet die TLS-Sitzungen von Clients, und neue TLS-Sitzungen werden in Richtung Azure Firewall erstellt. Azure Firewall empfängt und beendet die TLS-Sitzungen, die vom Anwendungsgateway stammen, und erstellt neue TLS-Sitzungen in Richtung der Workloads. Dieser Prozess wirkt sich auf die IDPS-Konfiguration von Azure Firewall Premium aus. Weitere Informationen finden Sie unter IDPS und privaten IP-Adressen.

• Die Workload sieht Verbindungen, die von der IP-Adresse des Azure Firewall-Subnetzes kommen. Die ursprüngliche Client-IP-Adresse wird im HTTP-Header beibehalten, den X-Forwarded-For das Anwendungsgateway einfügt. Azure Firewall unterstützt auch das Einfügen der Quellclient-IP-Adresse in den X-Forwarded-For Header. In diesem Szenario ist die IP-Adresse des Quellclients die IP-Adresse des Anwendungsgateways.

• Der Datenverkehr vom Anwendungsgateway zur Workload wird in der Regel mithilfe von Azure-Routingmechanismen an die Azure-Firewall gesendet. Zu diesen Mechanismen gehören benutzerdefinierte Routen (User-Defined Routes, UDRs), die im Subnetz des Anwendungsgateways konfiguriert sind, oder Routen, die Virtual WAN oder Route Server einspeisen. Die explizite Definition der privaten IP-Adresse von Azure Firewall im Back-End-Pool des Anwendungsgateways ist möglich, es wird jedoch nicht empfohlen, dies zu tun, da einige der systemeigenen Funktionen des Anwendungsgateways entfernt werden, wie z. B. Lastenausgleich und Sitzungstreue.

In den folgenden Abschnitten werden einige der am häufigsten verwendeten Topologien beschrieben, die Sie mit Azure Firewall und Application Gateway verwenden können.

Hub-Spoke-Topologie

Ein Hub- und Spoke-Design stellt in der Regel gemeinsam genutzte Netzwerkkomponenten im virtuellen Hubnetzwerk und anwendungsspezifische Komponenten in den Speichen bereit. In den meisten Systemen ist Azure Firewall Premium eine gemeinsam genutzte Ressource. Die Azure-Webanwendungsfirewall kann ein freigegebenes Netzwerkgerät oder eine anwendungsspezifische Komponente sein. Es ist eine bewährte Methode, den Application Gateway als Anwendungskomponente zu behandeln und ihn aus den folgenden Gründen in einem virtuellen Netzwerk bereitzustellen:

• Es kann schwierig sein, Probleme bei der Fehlerbehebung von Azure Web Application Firewall-Warnmeldungen zu beheben. Im Allgemeinen müssen Sie im Detail mit der Anwendung vertraut sein, um die Legitimität der Nachrichten, durch die diese Alarme ausgelöst werden, beurteilen zu können.

• Wenn Sie Das Anwendungsgateway als freigegebene Ressource behandeln, überschreiten Sie möglicherweise die Anwendungsgateway-Grenzwerte.

• Wenn Sie Application Gateway im Hub bereitstellen, kommt es möglicherweise zu Problemen mit der rollenbasierten Zugriffssteuerung. Diese Situation kann auftreten, wenn Teams verschiedene Anwendungen verwalten, aber dieselbe Instanz des Anwendungsgateways verwenden. Jedes Team hat dann Zugriff auf die gesamte Anwendungsgateway-Konfiguration.

In herkömmlichen Hub- und Spoke-Architekturen bieten DNS private Zonen eine einfache Möglichkeit, DNS zu verwenden:

1. Konfigurieren Sie eine private DNS-Zone.
2. Verknüpfen Sie die Zone mit dem virtuellen Netzwerk, das Azure Firewall Premium enthält.
3. Stellen Sie sicher, dass ein Datensatz für den Wert existiert, den Application Gateway für den Datenverkehr und für Zustandsprüfungen verwendet.

Das folgende Diagramm zeigt den Paketfluss für ein Szenario, in dem sich Application Gateway in einem virtuellen Spoke-Netzwerk befindet. In diesem Fall stellt ein Client eine Verbindung über das öffentliche Internet her.

1. Ein Client übermittelt eine Anforderung an einen Webserver.

2. Die Clientpakete werden von Application Gateway abgefangen und überprüft. Wenn die Pakete die Überprüfung bestehen, sendet das Anwendungsgateway die Pakete an die Back-End-VM. Wenn die Pakete Azure erreichen, leitet ein UDR im Anwendungsgateway-Subnetz sie an Azure Firewall Premium weiter.

3. Von Azure Firewall Premium werden Sicherheitsüberprüfungen für die Pakete durchgeführt. Nach erfolgreichem Test werden die Pakete von Azure Firewall Premium an den virtuellen Anwendungscomputer weitergeleitet.

4. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf das Anwendungsgateway fest. Durch eine UDR im VM-Subnetz werden die Pakete an Azure Firewall Premium umgeleitet.

5. Von Azure Firewall Premium werden die Pakete an Application Gateway weitergeleitet.

6. Von Application Gateway wird eine Antwort an den Client gesendet.

Datenverkehr kann anstatt aus dem öffentlichen Internet auch aus einem lokalen Netzwerk stammen. Der Datenverkehr fließt entweder über ein standortbasiertes virtuelles privates Netzwerk (VPN) oder über Azure ExpressRoute. In diesem Szenario erreicht der Datenverkehr zunächst ein Gateway für virtuelle Netzwerke im Hub. Der Rest des Netzwerkflusses entspricht dem vorherigen Diagramm.

1. Ein lokaler Client stellt eine Verbindung mit dem Gateway für virtuelle Netzwerke her.

2. Das Virtuelle Netzwerkgateway leitet die Clientpakete an das Anwendungsgateway weiter.

3. Die Pakete werden von Application Gateway überprüft. Nach erfolgreicher Überprüfung werden sie durch eine UDR im Application Gateway-Subnetz an Azure Firewall Premium weitergeleitet.

4. Von Azure Firewall Premium werden Sicherheitsüberprüfungen für die Pakete durchgeführt. Nach erfolgreichem Test werden die Pakete von Azure Firewall Premium an den virtuellen Anwendungscomputer weitergeleitet.

5. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf Application Gateway fest. Durch eine UDR im VM-Subnetz werden die Pakete an Azure Firewall Premium umgeleitet.

6. Von Azure Firewall Premium werden die Pakete an Application Gateway weitergeleitet.

7. Von Application Gateway werden die Pakete an das Gateway für virtuelle Netzwerke gesendet.

8. Das Virtuelle Netzwerkgateway antwortt auf den Client.

Virtual WAN-Topologie

In dieser Architektur kann auch der Netzwerkdienst Virtual WAN verwendet werden. Diese Komponente bietet viele Vorteile. So werden beispielsweise in virtuellen Spoke-Netzwerken keine benutzerseitig verwalteten UDRs mehr benötigt. Stattdessen können statische Routen in Routingtabellen für virtuelle Hubs definiert werden. Diese Routen sind dann in der Programmierung jedes virtuellen Netzwerks enthalten, das Sie mit dem Hub verbinden.

Wenn Sie Virtual WAN als Netzwerkplattform verwenden, ergeben sich zwei Hauptunterschiede:

• Es ist nicht möglich, private DNS-Zonen mit einem virtuellen Hub zu verknüpfen, da virtuelle Hubs von Microsoft verwaltet werden. Als Abonnementbesitzer sind Sie nicht berechtigt, private DNS-Zonen zu verknüpfen. Daher können Sie dem sicheren Hub, der Azure Firewall Premium enthält, keine private DNS-Zone zuordnen.

  Verwenden Sie stattdessen DNS-Server, um die DNS-Auflösung für Azure Firewall Premium zu implementieren:

  • Konfigurieren Sie die Azure Firewall-DNS-Einstellungen für die Verwendung von benutzerdefinierten DNS-Servern.

  • Stellen Sie die Server in einem virtuellen Netzwerk mit gemeinsam genutzten Diensten bereit, das Sie mit dem virtuellen WAN verbinden.

  • Verknüpfen Sie eine private DNS-Zone mit dem virtuellen Netzwerk mit gemeinsam genutzten Diensten. Von den DNS-Servern können dann die Namen aufgelöst werden, die von Application Gateway in HTTP-Hostheadern verwendet werden. Weitere Informationen finden Sie unter DNS-Einstellungen für Azure Firewall.

• Virtual WAN kann nur zum Programmieren von Routen in einem Spoke verwendet werden, wenn das Präfix kürzer (weniger spezifisch) als das Präfix des virtuellen Netzwerks ist. Beispielsweise hat das Speichen-Virtualnetzwerk in den vorherigen Diagrammen das Präfix 172.16.0.0/16. In diesem Fall kann Virtual WAN keine Route einfügen, die mit dem Präfix () des virtuellen Netzwerks (172.16.0.0/16) oder eines der Subnetze (172.16.0.0/24, 172.16.1.0/24) übereinstimmt. Mit anderen Worten: Virtuelles WAN kann keinen Datenverkehr zwischen zwei Subnetzen leiten, die sich im selben virtuellen Netzwerk befinden.

  Diese Einschränkung wird deutlich, wenn sich Das Anwendungsgateway und der Zielwebserver im selben virtuellen Netzwerk befinden. Virtuelles WAN kann den Datenverkehr zwischen Application Gateway und dem Webserver nicht dazu zwingen, über die Azure Firewall Premium geleitet zu werden. Eine Umgehung ist das manuelle Konfigurieren von UDRs im Anwendungsgateway und Webserver-Subnetzen.

Das folgende Diagramm zeigt den Paketfluss in einer Architektur, die virtual WAN verwendet. In diesem Szenario stammt der Zugriff auf das Anwendungsgateway von einem lokalen Netzwerk. Eine Standort-zu-Standort-VPN- oder ExpressRoute-Instanz verbindet dieses Netzwerk mit virtual WAN. Der internetbasierte Zugriff folgt einem ähnlichen Pfad.

1. Ein lokaler Client stellt eine Verbindung mit dem VPN-Gateway bereit.

2. Das VPN-Gateway leitet die Clientpakete an das Anwendungsgateway weiter.

3. Die Pakete werden von Application Gateway überprüft. Nach erfolgreicher Überprüfung werden sie durch das Application Gateway-Subnetz an Azure Firewall Premium weitergeleitet.

4. Von Azure Firewall Premium wird die DNS-Auflösung von einem DNS-Server im virtuellen Netzwerk mit gemeinsam genutzten Diensten angefordert.

5. Der DNS-Server reagiert auf die Auflösungsanforderung.

6. Von Azure Firewall Premium werden Sicherheitsüberprüfungen für die Pakete durchgeführt. Nach erfolgreichem Test werden die Pakete von Azure Firewall Premium an den virtuellen Anwendungscomputer weitergeleitet.

7. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf Application Gateway fest. Das Anwendungssubnetz leitet die Pakete zu Azure Firewall Premium um.

8. Von Azure Firewall Premium werden die Pakete an Application Gateway weitergeleitet.

9. Das Anwendungsgateway sendet die Pakete an das VPN-Gateway.

10. Das VPN-Gateway antwortt auf den Client.

Wenn Sie diesen Entwurf verwenden, müssen Sie möglicherweise das Routing ändern, das der Hub für die Spoke-Virtuellen Netzwerke angibt. Insbesondere unterstützt Application Gateway v2 nur eine 0.0.0.0/0 Route, die auf das Internet verweist. Routen mit dieser Adresse, die nicht auf das Internet verweisen, unterbrechen die Konnektivität, die Microsoft für die Verwaltung des Application Gateway benötigt. Wenn Ihr virtueller Hub eine 0.0.0.0/0 Route angibt, verhindern Sie, dass diese Route an das Anwendungsgateway-Subnetz weitergegeben wird, indem Sie eine der folgenden Schritte ausführen:

• Erstellen Sie eine Routing-Tabelle mit einer Route für 0.0.0.0/0 und einem Next-Hop-Typ von Internet. Ordnen Sie diese Route dem Subnetz zu, in dem Sie Application Gateway bereitstellen.

• Wenn Sie Application Gateway in einem dedizierten Spoke bereitstellen, deaktivieren Sie die Weitergabe der Standardroute in den Einstellungen für die VNet-Verbindung.

Route Server-Topologie

Route Server bietet eine weitere Möglichkeit zum automatischen Einfügen von Routen in Speichen. Verwenden Sie diese Funktion, um den verwaltungstechnischen Aufwand der Verwaltung von Routentabellen zu vermeiden. Route Server kombiniert die Virtual WAN-Variante mit der Hub-and-Spoke-Variante:

• Sie können route Server verwenden, um virtuelle Hubnetzwerke zu verwalten. Dadurch können Sie das virtuelle Hubnetzwerk mit einer privaten DNS-Zone verknüpfen.

• Bei IP-Adresspräfixen unterliegt Route Server der gleichen Einschränkung wie Virtual WAN. Routen können nur in einen Spoke eingefügt werden, wenn das Präfix kürzer (weniger spezifisch) als das Präfix des virtuellen Netzwerks ist. Aufgrund dieser Einschränkung müssen sich Application Gateway und der Zielwebserver in unterschiedlichen virtuellen Netzwerken befinden.

Das folgende Diagramm zeigt den Paketfluss, wenn das dynamische Routing durch Route Server vereinfacht wird. Berücksichtigen Sie die folgenden Punkte:

• Das Gerät, von dem die Routen eingefügt werden, muss diese aktuell über das Border Gateway Protocol (BGP) senden. Dies ist eine Vorgabe von Route Server. Azure Firewall Premium unterstützt BGP nicht. Verwenden Sie stattdessen eine nicht von Microsoft stammende Netzwerk-Virtual Appliance (NVA).

• Die Funktionen der NVA im Hub bestimmen, ob für Ihre Implementierung DNS erforderlich ist.

1. Ein lokaler Client stellt eine Verbindung mit dem Gateway für virtuelle Netzwerke her.

2. Das Virtuelle Netzwerkgateway leitet die Clientpakete an das Anwendungsgateway weiter.

3. Die Pakete werden von Application Gateway überprüft. Wenn sie die Prüfung bestehen, leitet das Application Gateway-Subnetz die Pakete an einen Back-End-Computer weiter. Route Server fügt eine Route in das Anwendungsgateway-Subnetz ein, das den Datenverkehr an eine NVA weiterleitet.

4. Das NVA-Subnetz fordert eine DNS-Auflösung von einem DNS-Server im virtuellen Netzwerk für gemeinsame Dienste an.

5. Der DNS-Server reagiert auf die Auflösungsanforderung.

6. Von der NVA werden Sicherheitsüberprüfungen für die Pakete durchgeführt. Nach erfolgreichem Test werden die Pakete von der NVA an den virtuellen Anwendungscomputer weitergeleitet.

7. Die VM der Anwendung antwortet und setzt die Ziel-IP-Adresse auf das Application Gateway. Route Server fügt eine Route in das VM-Subnetz ein, die die Pakete an die NVA umleitet.

8. Von der NVA werden die Pakete an Application Gateway weitergeleitet.

9. Von Application Gateway werden die Pakete an das Gateway für virtuelle Netzwerke gesendet.

10. Das Virtuelle Netzwerkgateway antwortt auf den Client.

Wie bei virtual WAN müssen Sie möglicherweise das Routing ändern, wenn Sie Route Server verwenden. Wenn Sie die 0.0.0.0/0 Route bewerben, wird sie möglicherweise an das Subnetz des Anwendungsgateways weitergegeben. Diese Route wird von Application Gateway aber nicht unterstützt. Konfigurieren Sie in diesem Fall eine Routingtabelle für das Application Gateway-Subnetz. Fügen Sie in diese Tabelle eine Route für 0.0.0.0/0 und einen Next-Hop-Typ von Internet ein.

IDPS und private IP-Adressen

Azure Firewall Premium entscheidet, welche IDPS-Regeln basierend auf den Quell- und Ziel-IP-Adressen der Pakete angewendet werden sollen. Standardmäßig behandelt Azure Firewall private IP-Adressen in den RFC 1918-Bereichen (10.0.0.0/8, 192.168.0.0/16und ) und 172.16.0.0/12RFC 6598-Bereich (100.64.0.0/10) als intern. Wenn Sie also Anwendungsgateway in einem Subnetz in einem dieser Bereiche bereitstellen, berücksichtigt Azure Firewall Premium den Datenverkehr zwischen Dem Anwendungsgateway und der Workload als intern. Daher werden nur IDPS-Signaturen verwendet, die markiert sind, auf internen Datenverkehr oder auf jeglichen Datenverkehr angewendet zu werden. IDPS-Signaturen, die für eingehenden oder ausgehenden Datenverkehr angewendet werden sollen, werden nicht auf den Datenverkehr zwischen Dem Anwendungsgateway und der Workload angewendet. Weitere Informationen finden Sie unter Azure Firewall IDPS-Regeln.

Die einfachste Möglichkeit, die Anwendung von IDPS-Regeln für eingehende Signaturen auf den Datenverkehr zwischen Application Gateway und dem Workload zu erzwingen, besteht darin, Application Gateway in einem Subnetz zu platzieren, das ein Präfix außerhalb der privaten Bereiche verwendet. Sie müssen nicht unbedingt öffentliche IP-Adressen für dieses Subnetz verwenden. Stattdessen können Sie die IP-Adressen anpassen, die Azure Firewall Premium als intern für IDPS behandelt. Wenn Ihre Organisation beispielsweise den 100.64.0.0/10 Bereich nicht verwendet, können Sie diesen Bereich aus der Liste der internen Präfixe für IDPS beseitigen und das Anwendungsgateway in einem Subnetz bereitstellen, das mit einer IP-Adresse in 100.64.0.0/10konfiguriert ist. Weitere Informationen finden Sie in den privaten IPDS-Bereichen von Azure Firewall Premium.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Jose Moreno | Principal Customer Engineer

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Sichere Netzwerke mit Zero Trust
• Virtuelles Routing von Netzwerkverkehr
• Funktionsweise eines Application Gateways

Verwandte Ressourcen

• Implementieren eines sicheren Hybridnetzwerks
• Hub-Spoke-Netzwerktopologie in Azure
• Hub-Spoke-Netzwerktopologie, die virtuelles WAN verwendet