Zero Trust-Netzwerk für Webanwendungen mit Azure Firewall und Application Gateway

In diesem Leitfaden wird eine Strategie für die Implementierung von Zero-Trust-Sicherheit für Web-Apps zur Untersuchung und Verschlüsselung beschrieben. Das Zero-Trust-Paradigma umfasst viele andere Konzepte wie die ständige Überprüfung der Identität der Akteure oder die Verringerung der Größe der impliziten Vertrauensbereiche auf ein Minimum. Dieser Artikel bezieht sich auf die Verschlüsselungs- und Untersuchungskomponente einer Zero-Trust-Architektur für eingehenden Datenverkehr aus dem öffentlichen Internet. Weitere Aspekte der sicheren Bereitstellung Ihrer Anwendung, z. B. die Authentifizierung, finden Sie in anderen Zero-Trust-Dokumenten. Für die Zwecke dieses Artikels funktioniert ein Ansatz mit mehreren Ebenen am besten, bei dem die Netzwerksicherheit eine der Ebenen des Zero-Trust-Modells bildet. 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.

In bestimmten Situationen können verschiedene Arten von Netzwerksicherheitsappliances miteinander kombiniert werden, um den Schutz zu erhöhen. In der separaten Anleitung Firewall und Application Gateway für virtuelle Netzwerke werden Entwurfsmuster für die Strukturierung der verschiedenen Appliances beschrieben. In diesem Dokument konzentrieren wir uns auf ein allgemeines Muster für maximale Sicherheit, bei dem Azure Application Gateway vor Azure Firewall Premium agiert. Dieses Muster wird im folgenden Diagramm veranschaulicht:

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.

• Ein Client sendet Pakete an Application Gateway (ein Lastenausgleichsmodul). Application Gateway wird mit der optionalen Ergänzung Azure Web Application Firewall ausgeführt.

• Von Application Gateway werden die Pakete entschlüsselt und auf Bedrohungen für Webanwendungen untersucht. Werden keine Bedrohungen gefunden, werden die Pakete unter Verwendung von Zero-Trust-Prinzipien verschlüsselt. Anschließend werden sie freigegeben.

• Von Azure Firewall Premium werden Sicherheitsüberprüfungen durchgeführt:

  • Bei der TLS-Überprüfung (Transport Layer Security) werden die Pakete entschlüsselt und untersucht.
  • Mithilfe von IDPS-Features (Intrusion Detection and Protection System) werden die Pakete auf schädliche Absichten untersucht.

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

  • Verschlüsseln der Pakete
  • Bestimmen des virtuellen Anwendungscomputers mithilfe eines DNS-Diensts (Domain Name System)
  • Weiterleiten der Pakete an den virtuellen Anwendungscomputer

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

• Von Web Application Firewall werden Regeln verwendet, um Angriffe auf Webebene zu verhindern. Beispiele für Angriffe sind die Einschleusung von SQL-Befehlen sowie Cross-Site Scripting. Weitere Informationen zu Regeln und zum OWASP-Kernregelsatz (Open Web Application Security Project) finden Sie unter CRS-Regelgruppen und -Regeln der Web Application Firewall.
• 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 verschiedene Arten von Netzwerkentwürfen, 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

Bei der Überprüfung auf schädlichen Datenverkehr wird von Azure Firewall Premium überprüft, ob der HTTP-Hostheader der Paket-IP-Adresse und dem TCP-Port entspricht. 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. Welche DNS-Lösung am besten funktioniert, hängt vom Netzwerkentwurf ab, wie in späteren Abschnitten beschrieben.

Digitale Zertifikate

Das folgende Diagramm zeigt die allgemeinen Namen (Common Names, CNs) und Zertifizierungsstellen (Certificate Authorities, CAs), die von den TLS-Sitzungen und -Zertifikaten der Architektur verwendet werden:

TLS-Verbindungen

Diese Architektur enthält drei unterschiedliche TLS-Verbindungen. Sie werden jeweils durch digitale Zertifikate validiert:

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.

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. Application Gateway wird daher mit einem digitalen Zertifikat konfiguriert, das von einer öffentlichen Zertifizierungsstelle signiert wurde. Verwenden Sie eine Zertifizierungsstelle, die von jedem TLS-Client akzeptiert wird.
• 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, generiert der Weiterleitungsproxy digitale Zertifikate und präsentiert sie dem Client, um die Identität des Zielwebservers anzunehmen. 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 je nach Topologie Ihres Netzwerkentwurfs geringfügig. In den folgenden Abschnitten werden die Einzelheiten der Beispiele für Hub- und Spoke-, Virtual WAN- und Routenservertopologie erläutert. Es gibt jedoch einige Aspekte, die für alle Topologien gelten:

• Azure Application Gateway verhält sich immer als Proxy. Azure Firewall Premium verhält sich ebenfalls so, wenn es für die TLS-Inspektion konfiguriert ist: Die TLS-Sitzungen von Clients werden von Application Gateway beendet, und neue TLS-Sitzungen werden in Richtung Azure Firewall aufgebaut. Azure Firewall empfängt und beendet die TLS-Sitzungen, die von Application Gateway stammen, und erstellt neue TLS-Sitzungen für die Workloads. Diese Tatsache hat Auswirkungen auf die IDPS-Konfiguration von Azure Firewall Premium, Abschnitte weiter unten enthalten weitere Details dazu.
• Die Workload sieht Verbindungen, die von der Subnetz-IP-Adresse der Azure-Firewall eingehen. Die ursprüngliche Client-IP-Adresse wird im X-Forwarded-For HTTP-Header beibehalten, der vom Application Gateway eingefügt wird.
• Datenverkehr vom Application Gateway zur Workload wird in der Regel mithilfe von Azure-Routingmechanismen an die Azure-Firewall gesendet, entweder mit benutzerdefinierten Routen, die im Subnetz des Application Gateway konfiguriert sind, oder mit Routen, die von Azure Virtual WAN oder Azure Route Server eingefügt werden. Obwohl die explizite Definition der privaten IP-Adresse der Azure Firewall im Back-End-Pool des Application Gateway möglich ist, wird es technisch nicht empfohlen, da einige der Funktionen der Azure Firewall, wie Lastenausgleich und Bindung, entfernt werden.

In den folgenden Abschnitten werden einige der am häufigsten verwendeten Topologien für Azure Firewall und Application Gateway ausführlich beschrieben.

Hub-Spoke-Topologie

Bei einem Hub-and-Spoke-Entwurf werden in der Regel gemeinsam genutzte Netzwerkkomponenten im virtuellen Hubnetzwerk und anwendungsspezifische Komponenten in den Spokes bereitgestellt. In den meisten Systemen ist Azure Firewall Premium eine gemeinsam genutzte Ressource. Web Application Firewall kann dagegen ein gemeinsam genutztes Netzwerkgerät oder eine anwendungsspezifische Komponente sein. Aus den folgenden Gründen empfiehlt es sich üblicherweise, Application Gateway als Anwendungskomponente zu behandeln und in einem virtuellen Spoke-Netzwerk bereitzustellen:

• Probleme im Zusammenhang mit Web Application Firewall-Warnungen lassen sich mitunter nur schwer behandeln. 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 Application Gateway als gemeinsam genutzte Ressource behandeln, werden unter Umständen Application Gateway-Grenzwerte überschritten.
• Wenn Sie Application Gateway im Hub bereitstellen, kommt es möglicherweise zu Problemen mit der rollenbasierten Zugriffssteuerung. Dieser Fall kann eintreten, wenn Teams verschiedene Anwendungen verwalten, aber die gleiche Instanz von Application Gateway verwenden. Jedes Team hat dann Zugriff auf die gesamte Application Gateway-Konfiguration.

Bei herkömmlichen Hub-and-Spoke-Architekturen bieten private DNS-Zonen eine einfache Möglichkeit zur Verwendung von DNS:

• Konfigurieren Sie eine private DNS-Zone.
• Verknüpfen Sie die Zone mit dem virtuellen Netzwerk, das Azure Firewall Premium enthält.
• Stellen Sie sicher, dass ein A-Eintrag für den Wert vorhanden ist, der von Application Gateway für Datenverkehr und für Integritätsprüfungen verwendet wird.

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, wird das Paket von Application Gateway an die Back-End-VM gesendet. Wenn das Paket Azure erreicht, werden die Pakete durch eine benutzerdefinierte Route (User-Defined Route, UDR) im Application Gateway-Subnetz an Azure Firewall Premium weitergeleitet.
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 Application Gateway 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 wird entweder über ein Site-to-Site-VPN (virtuelles privates Netzwerk) oder über ExpressRoute übermittelt. In diesem Szenario erreicht der Datenverkehr zunächst ein Gateway für virtuelle Netzwerke im Hub. Der restliche Netzwerkfluss entspricht dem Netzwerkfluss aus dem vorherigen Fall.

1. Ein lokaler Client stellt eine Verbindung mit dem Gateway für virtuelle Netzwerke her.
2. Vom Gateway werden die Clientpakete an Application Gateway weitergeleitet.
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. Vom Gateway wird eine Antwort an den Client gesendet.

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 zum Verknüpfen privater DNS-Zonen berechtigt. 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 DNS-Einstellungen für Azure Firewall für die Verwendung benutzerdefinierter DNS-Server.
  • 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. Im obigen Diagramm hat das Spoke-VNet beispielsweise das Präfix 172.16.0.0/16: In diesem Fall könnte Virtual WAN keine Route einschleusen, die dem VNet-Präfix (172.16.0.0/16) oder einem der Subnetze (172.16.0.0/24, 172.16.1.0/24) entspricht. Mit anderen Worten: Virtual WAN kann keinen Datenverkehr zwischen zwei Subnetzen anziehen, die sich im selben VNet befinden. Diese Einschränkung wird deutlich, wenn sich Application Gateway und der Zielwebserver im selben virtuellen Netzwerk befinden: Virtual WAN kann nicht erzwingen, dass der Datenverkehr zwischen Application Gateway und dem Webserver über Azure Firewall Premium geleitet wird. (Eine Problemumgehung wäre die manuelle Konfiguration von benutzerdefinierten Routen (UDR) in den Subnetzen von Application Gateway und Webserver.)

Das folgende Diagramm zeigt den Paketfluss in einem Szenario mit Virtual WAN. In diesem Fall erfolgt der Zugriff auf Application Gateway über ein lokales Netzwerk. Das Netzwerk ist per Site-to-Site-VPN oder ExpressRoute mit Virtual WAN verbunden. Der Zugriff über das Internet läuft ähnlich ab.

1. Ein lokaler Client stellt eine Verbindung mit dem VPN her.
2. Vom VPN werden die Clientpakete an Application Gateway weitergeleitet.
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. Durch das Anwendungssubnetz werden die Pakete an Azure Firewall Premium umgeleitet.
8. Von Azure Firewall Premium werden die Pakete an Application Gateway weitergeleitet.
9. Von Application Gateway werden die Pakete an das VPN gesendet.
10. Vom VPN wird eine Antwort an den Client gesendet.

Bei diesem Entwurf müssen Sie möglicherweise das Routing ändern, das vom Hub für die virtuellen Spoke-Netzwerke angekündigt wird. Von Application Gateway v2 wird insbesondere nur eine Route vom Typ 0.0.0.0/0 mit Verweis auf das Internet unterstützt. Routen mit dieser Adresse, die nicht auf das Internet verweisen, unterbrechen die Konnektivität, die Microsoft für die Verwaltung von Application Gateway benötigt. Falls von Ihrem virtuellen Hub eine Route vom Typ 0.0.0.0/0 angekündigt wird, gehen Sie wie folgt vor, um zu verhindern, dass diese Route an das Application Gateway-Subnetz weitergegeben wird:

• Erstellen Sie eine Routingtabelle mit einer Route für 0.0.0.0/0 und mit Internet als Typ des nächsten Hops. 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 ist eine weitere Möglichkeit zum automatischen Einfügen von Routen in Spokes. Mit dieser Funktion vermeiden Sie zusätzlichen Verwaltungsaufwand für Routingtabellen. Route Server kombiniert die Virtual WAN-Variante mit der Hub-and-Spoke-Variante:

• Bei Verwendung von Route Server verwalten Kunden virtuelle Hubnetzwerke. 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. Beachten Sie Folgendes:

• 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. Da BGP von Azure Firewall Premium nicht unterstützt wird, muss stattdessen eine virtuelle Netzwerkappliance (Network Virtual Appliance, NVA) eines Drittanbieters verwendet werden.
• 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. Vom Gateway werden die Clientpakete an Application Gateway weitergeleitet.
3. Die Pakete werden von Application Gateway überprüft. Nach erfolgreicher Überprüfung werden die Pakete durch das Application Gateway-Subnetz an einen Back-End-Computer weitergeleitet. Eine Route im Application Gateway-Subnetz, die vom Routenserver eingefügt wird, leitet den Datenverkehr an eine NVA weiter.
4. 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.
5. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf Application Gateway fest. Eine Route, die vom Routenserver in das VM-Subnetz eingefügt wird, leitet die Pakete an die NVA um.
6. Von der NVA werden die Pakete an Application Gateway weitergeleitet.
7. Von Application Gateway werden die Pakete an das Gateway für virtuelle Netzwerke gesendet.
8. Vom Gateway wird eine Antwort an den Client gesendet.

Genau wie bei Virtual WAN muss möglicherweise das Routing geändert werden, wenn Sie Route Server verwenden. Wenn Sie die Route 0.0.0.0/0 ankündigen, wird sie möglicherweise an das Application Gateway-Subnetz weitergegeben. Diese Route wird von Application Gateway aber nicht unterstützt. Konfigurieren Sie in diesem Fall eine Routingtabelle für das Application Gateway-Subnetz. Schließen Sie eine Route für 0.0.0.0/0 und mit Internet als Typ des nächsten Hops in dieser Tabelle ein.

IDPS und private IP-Adressen

Wie in Azure Firewall IDPS-Regeln erläutert, entscheidet Azure Firewall Premium, welche IDPS-Regeln je nach Quell- und Ziel-IP-Adressen der Pakete angewendet werden sollen. Azure Firewall behandelt private IP-Adressen in den RFC 1918-Bereichen (10.0.0.0/8, 192.168.0.0/16 und 172.16.0.0/12) und im RFC 6598-Bereich (100.64.0.0/10) standardmäßig als intern. Wenn das Application Gateway daher wie in den Diagrammen in diesem Artikel in einem Subnetz in einem dieser Bereiche bereitgestellt wird (172.16.0.0/24 in den Beispielen oben), berücksichtigt Azure Firewall Premium den Datenverkehr zwischen dem Application Gateway und der Workload als intern, und es werden nur IDPS-Signaturen verwendet, die auf internen Datenverkehr oder auf jeden Datenverkehr angewendet werden. IDPS-Signaturen, die für eingehenden oder ausgehenden Datenverkehr angewendet werden sollen, werden nicht auf den Datenverkehr zwischen dem Application Gateway und der Workload angewendet.

Die einfachste Möglichkeit zum Erzwingen von IDPS-Regeln für eingehende Signaturen, die auf den Datenverkehr zwischen dem Application Gateway und der Workload angewendet werden, besteht darin, das Application Gateway in einem Subnetz mit einem Präfix außerhalb der privaten Bereiche zu platzieren. Sie müssen nicht unbedingt öffentliche IP-Adressen für dieses Subnetz verwenden, sondern sie können stattdessen 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 entfernen (weitere Informationen hierzu finden Sie unter Private IPDS-Bereiche für Azure Firewall Premium ) und Application Gateway in einem Subnetz bereitstellen, das mit einer IP-Adresse in 100.64.0.0/10 konfiguriert ist.

Beitragende

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

Hauptautor:

• Jose Moreno | Principal Customer Engineer

Nächste Schritte

• Schützen von Netzwerken mit Zero Trust
• Routing von Datenverkehr für virtuelle Netzwerke
• Funktionsweise von Anwendungsgateways

Zugehörige Ressourcen

• Sichern und Steuern von Workloads mit Segmentierung auf Netzwerkebene
• Implementieren eines sicheren Hybridnetzwerks
• Hub-Spoke-Netzwerktopologie in Azure
• Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN