Firewall und Application Gateway für virtuelle Netzwerke

Zum Schützen von Azure-Anwendungsworkloads sollten Sie Schutzmaßnahmen wie die Authentifizierung und Verschlüsselung in den Anwendungen selbst verwenden. Außerdem können Sie den virtuellen Netzwerken (VNets), in denen die Anwendungen gehostet werden, Sicherheitsebenen hinzufügen. Diese Sicherheitsebenen schützen die eingehenden Datenflüsse der Anwendung vor unbeabsichtigter Nutzung. Sie beschränken außerdem ausgehende Datenflüsse an das Internet ausschließlich auf die Endpunkte, die für Ihre Anwendung erforderlich sind. In diesem Artikel werden Azure Virtual Network-Sicherheitsdienste wie Azure DDoS Protection, Azure Firewall und Azure Application Gateway beschrieben. Außerdem wird erläutert, in welchen Fällen einer dieser Dienste verwendet werden sollte, und es werden Netzwerkentwürfe vorgestellt, bei denen zwei Dienste kombiniert werden.

• 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.
• Azure Firewall ist eine verwaltete Firewall der nächsten Generation, die Netzwerkadressenübersetzung (NAT) bietet. In Azure Firewall basiert Paketfiltern auf IP-Adressen (Internet Protocol) sowie TCP/UDP-Ports (Transmission Control Protocol/User Datagram Protocol) oder auf anwendungsbasierten HTTP(S)- oder SQL-Attributen. Zudem ermittelt Azure Firewall per Microsoft Threat Intelligence schädliche IP-Adressen. Weitere Informationen finden Sie in der Dokumentation zu Azure Firewall.
• Azure Firewall Premium enthält alle Funktionen von Azure Firewall Standard und zusätzliche Features wie TLS-Überprüfung und IDPS (Intrusion Detection and Protection System).
• Azure Application Gateway ist ein verwalteter Netzwerkdatenverkehr-Lastenausgleich und vollständiger HTTP(S)-Reverseproxy, mit dem die SSL-Verschlüsselung und -Entschlüsselung (Secure Socket Layer) durchgeführt werden kann. Das Anwendungsgateway behält die ursprüngliche Client-IP-Adresse in einem X-Forwarded-For-HTTP-Header. Application Gateway verwendet auch Web Application Firewall, um Webdatenverkehr zu überprüfen und Angriffe auf der HTTP-Ebene zu erkennen. Weitere Informationen finden Sie in der Dokumentation zu Application Gateway.
• Azure Web Application Firewall (WAF) ist ein optionaler Zusatz für Azure Application Gateway. Dieser Dienst ermöglicht die Überprüfung von HTTP-Anforderungen und verhindert schädliche Angriffe auf der Webebene, z. B. Einschleusung von SQL-Befehlen oder Cross-Site Scripting. Weitere Informationen finden Sie in der Dokumentation zu Web Application Firewall.

Diese Azure-Dienste ergänzen einander. Es kann sein, dass einer dieser Dienste Ihre Anforderungen besser erfüllt. Sie können sie aber auch gemeinsam nutzen, um sowohl auf der Netzwerk- als auch der Anwendungsschicht für optimalen Schutz zu sorgen. Orientieren Sie sich an der folgenden Entscheidungsstruktur und den Beispielen in diesem Artikel, um die beste Sicherheitsoption für das virtuelle Netzwerk Ihrer Anwendung zu bestimmen.

Für Azure Firewall und Azure Application Gateway werden verschiedene Technologien genutzt, und es wird die Absicherung unterschiedlicher Datenflüsse unterstützt:

Je nach den Netzwerkdatenflüssen, die für eine Anwendung erforderlich sind, kann sich das Design von Anwendung zu Anwendung unterscheiden. Das folgende Diagramm enthält eine vereinfachte Entscheidungsstruktur, die als Hilfe bei der Ermittlung des empfohlenen Ansatzes für eine Anwendung dienen kann. Die Entscheidung richtet sich danach, ob die Anwendung über HTTP(S) oder ein anderes Protokoll veröffentlicht wird:

In diesem Artikel werden die häufig empfohlenen Designs aus dem Flussdiagramm und noch weitere Designs für weniger häufige Szenarien beschrieben:

• Nur Azure Firewall: Wird verwendet, wenn im virtuellen Netzwerk keine Webanwendungen vorhanden sind. Hierbei wird sowohl der eingehende Datenverkehr für die Anwendungen als auch der ausgehende Datenverkehr kontrolliert.
• Nur Application Gateway: Wird verwendet, wenn nur Webanwendungen im virtuellen Netzwerk vorhanden sind und Netzwerksicherheitsgruppen (NSGs) eine ausreichende Filterung der Ausgabe sicherstellen. Die von Azure Firewall bereitgestellten Funktionen können viele Angriffsszenarien verhindern (z. B. Datenexfiltration, IDPS usw.). Aus diesem Grund wird das Szenario "Application Gateway allein" in der Regel nicht empfohlen und ist daher nicht dokumentiert und nicht im obigen Flussdiagramm enthalten.
• Azure Firewall und Application Gateway parallel: Dies ist eines der am häufigsten gewählten Designs. Verwenden Sie diese Kombination, wenn Sie mit Azure Application Gateway HTTP(S)-Anwendungen vor Angriffen aus dem Web schützen möchten und Azure Firewall alle übrigen Workloads schützen und ausgehenden Datenverkehr filtern soll.
• Application Gateway vor Azure Firewall: Wird verwendet, wenn Azure Firewall den gesamten Datenverkehr untersuchen und WAF den Webdatenverkehr schützen soll und der Anwendung die Quell-IP-Adresse des Clients bekannt sein soll. Mit Azure Firewall Premium und TLS-Überprüfung unterstützt dieses Design auch das End-to-End-SSL-Szenario.
• Azure Firewall vor Application Gateway: Wird verwendet, wenn der Datenverkehr von der Azure Firewall-Instanz überprüft und gefiltert werden soll, bevor er Application Gateway erreicht. Da HTTPS-Datenverkehr von der Azure Firewall-Instanz nicht entschlüsselt wird, ist die Funktionalität, die Application Gateway hiermit hinzugefügt wird, begrenzt. Dieses Szenario ist im obigen Flussdiagramm nicht dokumentiert.

Im letzten Teil dieses Artikels werden Varianten der obigen grundlegenden Designs beschrieben. Die Varianten lauten wie folgt:

• Lokale Anwendungsclients
• Hub-and-Spoke-Netzwerke
• Implementierungen von Azure Kubernetes Service (AKS)

Sie können noch andere Reverseproxydienste hinzufügen, z. B. ein API Management-Gateway oder Azure Front Door. Alternativ können Sie die Azure-Ressourcen auch durch virtuelle Netzwerkgeräte von Drittanbietern ersetzen.

Nur Azure Firewall

Wenn keine webbasierten Workloads im virtuellen Netzwerk vorhanden sind, die von WAF profitieren können, können Sie ausschließlich Azure Firewall verwenden. Das Design in einem solchen Szenario ist einfach, aber das Überprüfen des Paketflusses trägt dazu bei, komplexere Designs zu verstehen. In diesem Entwurf wird der gesamte eingehende Datenverkehr über benutzerdefinierte Routen (User-Defined Routes, UDRs) für Verbindungen von lokalen oder anderen Azure-VNets an Azure Firewall gesendet. Für Verbindungen aus dem öffentlichen Internet wird er an die öffentliche IP-Adresse von Azure Firewall adressiert, wie im folgenden Diagramm gezeigt. Ausgehender Datenverkehr aus Azure-VNets wird über UDRs an die Firewall gesendet, wie im folgenden Dialogfeld gezeigt.

In der folgenden Tabelle sind die Datenverkehrsflüsse für dieses Szenario zusammengefasst:

Eingehender HTTP(S)-Datenverkehr wird von Azure Firewall nicht untersucht. Es können aber Layer 3- und Layer 4-Regeln und FQDN-basierte Anwendungsregeln angewendet werden. Azure Firewall überprüft ausgehenden HTTP(S)-Datenverkehr je nach Azure Firewall-Tarif und in Abhängigkeit davon, ob Sie die TLS-Überprüfung konfigurieren:

• Bei Azure Firewall Standard werden nur die Layer 3- und Layer 4-Attribute der Pakete in Netzwerkregeln und die Host-HTTP-Header in Anwendungsregeln überprüft.
• Bei Azure Firewall Premium sind zusätzlich noch weitere Funktionen vorhanden, z. B. die Überprüfung anderer HTTP-Header (z. B. Benutzer-Agent) und die TLS-Überprüfung zur Durchführung einer eingehenderen Paketanalyse. Azure Firewall ist nicht das Gleiche wie eine Web Application Firewall-Instanz. Wenn Sie in Ihrem virtuellen Netzwerk über Webworkloads verfügen, wird die Verwendung von WAF dringend empfohlen.

Im folgenden Beispiel eines Paketflusses wird veranschaulicht, wie ein Client aus dem öffentlichen Internet auf eine VM-gehostete Anwendung zugreift. Die Abbildung enthält aus Gründen der Einfachheit nur eine VM. Für eine höhere Verfügbarkeit und Skalierbarkeit müssten Sie hinter einem Lastenausgleich über mehrere Anwendungsinstanzen verfügen. Bei diesem Design untersucht Azure Firewall sowohl eingehende Verbindungen aus dem öffentlichen Internet als auch ausgehende Verbindungen von der VM im Anwendungssubnetz mithilfe der UDR.

• Der Azure Firewall-Dienst stellt im Hintergrund mehrere Instanzen bereit – in diesem Fall mit der Front-End-IP-Adresse 192.168.100.4 und internen Adressen aus dem Bereich 192.168.100.0/26. Diese einzelnen Instanzen sind für den Azure-Administrator normalerweise nicht sichtbar. Es kann aber hilfreich sein, den Unterschied zu kennen, z. B. bei der Behandlung von Netzwerkproblemen.
• Wenn Datenverkehr aus einem lokalen virtuellen privaten Netzwerk (VPN) oder von einem Azure ExpressRoute-Gateway und nicht aus dem Internet stammt, startet der Client die Verbindung mit der IP-Adresse der VM. Die Verbindung mit der IP-Adresse der Firewall wird nicht gestartet, und von der Firewall wird standardmäßig kein NAT-Vorgang für die Quelle durchgeführt.

Aufbau

Das folgende Diagramm zeigt den Datenverkehrsfluss unter der Annahme, dass die IP-Adresse der Instanz 192.168.100.7 lautet.

Workflow

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse von Azure Firewall:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AzFwPIP
2. Die Anforderung an die öffentliche IP-Adresse von Azure Firewall wird an eine Back-End-Instanz der Firewall verteilt, in diesem Fall 192.168.100.7. Die Regel für Ziel-NATs (DNAT) von Azure Firewall übersetzt die Ziel-IP-Adresse in die Anwendungs-IP-Adresse im virtuellen Netzwerk. Azure Firewall wendet auch eine Regel für Quell-NATs (SNATs) auf das Paket an, wenn der DNAT-Vorgang durchgeführt wird. Weitere Informationen finden Sie unter Azure Firewall – Bekannte Probleme. Die VM erkennt die folgenden IP-Adressen im eingehenden Paket:
   • Quell-IP-Adresse: 192.168.100.7
   • Ziel-IP-Adresse: 192.168.1.4
3. Die VM beantwortet die Anwendungsanforderung und kehrt dabei Quell- und Ziel-IP-Adresse um. Der eingehende Datenfluss erfordert keine benutzerdefinierte Route (UDR) , da die Quell-IP-Adresse die IP-Adresse der Azure Firewall-Instanz ist. Die UDR im Diagramm für 0.0.0.0/0 ist für ausgehende Verbindungen bestimmt, damit sichergestellt ist, dass Pakete für das öffentliche Internet Azure Firewall durchlaufen.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.100.7
4. Schließlich macht Azure Firewall die SNAT- und DNAT-Vorgänge rückgängig und sendet die Antwort an den Client:
   • Quell-IP-Adresse: AzFwPIP
   • Ziel-IP-Adresse: ClientPIP

Nur Application Gateway

Dieses Design ist für einen Fall geeignet, bei dem im virtuellen Netzwerk nur Webanwendungen vorhanden sind und die Untersuchung des ausgehenden Datenverkehrs mit NSGs ausreicht, um ausgehende Datenflüsse ins Internet zu schützen.

Der Hauptunterschied zum vorherigen Design mit alleiniger Nutzung von Azure Firewall besteht darin, dass die Application Gateway-Instanz nicht als Routinggerät mit Netzwerkadressenübersetzung fungiert. Sie verhält sich wie ein vollständiger Reverseproxy für Anwendungen. Dies bedeutet, dass die Application Gateway-Instanz die Websitzung vom Client beendet und eine separate Sitzung mit einem seiner Back-End-Server einrichtet. Eingehende HTTP(S)-Verbindungen aus dem Internet müssen an die öffentliche IP-Adresse von Application Gateway gesendet werden, Verbindungen von Azure oder lokale Verbindungen an die private IP-Adresse des Gateways. Rückläufiger Datenverkehr von den Azure-VMs befolgt das VNet-Standardrouting zurück zum Application Gateway (weitere Informationen finden Sie unten im Paketfluss). Ausgehende Internetflows von Azure-VMs werden direkt ins Internet übertragen.

In der folgenden Tabelle sind die Datenverkehrsflüsse zusammengefasst:

Aufbau

Im folgenden Beispiel eines Paketflusses wird veranschaulicht, wie ein Client aus dem öffentlichen Internet auf die VM-gehostete Anwendung zugreift.

Workflow

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse der Azure Application Gateway-Instanz:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AppGwPIP
2. Die Anforderung an die öffentliche IP-Adresse von Application Gateway IP wird an eine Back-End-Instanz des Gateways verteilt, in diesem Fall 192.168.200.7. Die Application Gateway-Instanz, die die Anforderung empfängt, beendet die Verbindung vom Client und stellt eine neue Verbindung mit einem der Back-Ends her. Das Back-End erkennt die Application Gateway-Instanz als Quell-IP-Adresse. Die Application Gateway-Instanz fügt einen X-Forwarded-For-HTTP-Header mit der ursprünglichen Client-IP-Adresse ein.
   • Quell-IP-Adresse: 192.168.200.7 (die private IP-Adresse der Application Gateway-Instanz)
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: ClientPIP
3. Die VM beantwortet die Anwendungsanforderung und kehrt dabei Quell- und Ziel-IP-Adresse um. Der VM ist bereits bekannt, wie die Application Gateway-Instanz erreicht werden kann, daher ist keine UDR erforderlich.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
4. Schließlich antwortet die Application Gateway-Instanz dem Client:
   • Quell-IP-Adresse: AppGwPIP
   • Ziel-IP-Adresse: ClientPIP

Azure Application Gateway fügt den Paket-HTTP-Headern Metadaten hinzu, z. B. den X-Forwarded-For-Header mit der IP-Adresse des ursprünglichen Clients. Einige Anwendungsserver benötigen die IP-Adresse des Quellclients, um geolocationspezifische Inhalte zu verarbeiten, oder zu Protokollierungszwecken. Weitere Informationen finden Sie unter Funktionsweise von Application Gateway.

• Die IP-Adresse 192.168.200.7 ist einer der Fälle, bei dem eine Bereitstellung im Hintergrund durch den Azure Application Gateway-Dienst erfolgt, hier mit der privaten Front-End-IP-Adresse 192.168.200.4. Diese einzelnen Instanzen sind für den Azure-Administrator normalerweise nicht sichtbar. Es kann aber hilfreich sein, den Unterschied zu kennen, z. B. bei der Behandlung von Netzwerkproblemen.

• Der Datenfluss ist ähnlich, wenn der Weg für den Client aus einem lokalen Netzwerk über ein VPN- oder ExpressRoute-Gateway verläuft. Der Unterschied besteht darin, dass der Client nicht auf die öffentliche Adresse, sondern auf die private IP-Adresse der Application Gateway-Instanz zugreift.

Firewall und Application Gateway parallel

Aufgrund seiner Einfachheit und Flexibilität ist das Szenario mit paralleler Ausführung von Application Gateway und Azure Firewall häufig am besten geeignet.

Implementieren Sie dieses Design, wenn im virtuellen Netzwerk sowohl Webworkloads als auch Nicht-Web-Workloads vorhanden sind. Azure WAF in Azure Application Gateway schützt eingehenden Datenverkehr für die Webworkloads, und Azure Firewall prüft eingehenden Datenverkehr für die anderen Anwendungen. Mit der Azure Firewall sind ausgehende Datenflüsse beider Workloadtypen abgedeckt.

Eingehende HTTP(S)-Verbindungen aus dem Internet sollten an die öffentliche IP-Adresse des Application Gateways gesendet werden, HTTP(S)-Verbindungen von Azure oder lokale HTTP(S)-Verbindungen an seine private IP-Adresse. Das VNet-Standardrouting sendet die Pakete vom Application Gateway an die Ziel-VMs sowie von den Ziel-VMs zurück an das Application Gateway (weitere Informationen finden Sie unten im Paketfluss). Bei eingehenden Nicht-HTTP(S)-Verbindungen sollte der Datenverkehr auf die öffentliche IP-Adresse der Azure Firewall abzielen (wenn er aus dem öffentlichen Internet kommt), oder er wird mittels UDRs über die Azure Firewall gesendet (wenn er aus anderen Azure-VNets oder lokalen Netzwerken kommt). Alle ausgehenden Datenflüsse von Azure-VMs werden mittels UDRs an die Azure Firewall weitergeleitet.

In der folgenden Tabelle sind die Datenverkehrsflüsse für dieses Szenario zusammengefasst:

Dieses Design ermöglicht bei der Filterung in ausgehender Richtung eine deutlich höhere Granularität als bei NSGs. Falls Anwendungen beispielsweise Konnektivität mit einem bestimmten Azure Storage-Konto benötigen, können Sie FQDN-basierte Filter verwenden. FQDN steht für „Fully Qualified Domain Name“ (Vollqualifizierter Domänenname). Bei FQDN-basierten Filtern senden Anwendungen keine Daten an nicht autorisierte Speicherkonten. Wenn nur NSGs genutzt werden, kann dies nicht verhindert werden. Dieses Design wird häufig genutzt, wenn für ausgehenden Datenverkehr die FQDN-basierte Filterung erforderlich ist. Ein Beispiel für diese Situation ist das Beschränken des ausgehenden Datenverkehrs aus einem Azure Kubernetes Service-Cluster.

Architekturen

Im folgenden Diagramm wird der Datenverkehrsfluss für eingehende HTTP(S)-Verbindungen von einem externen Client veranschaulicht:

Im folgenden Diagramm ist der Datenverkehrsfluss für ausgehende Verbindungen von den Netzwerk-VMs ins Internet dargestellt. Ein Beispiel ist die Verbindungsherstellung mit Back-End-Systemen oder das Abrufen von Betriebssystemupdates:

Die Schritte des Paketflusses für jeden Dienst sind identisch mit denen für die obigen eigenständigen Designoptionen.

Application Gateway vor Firewall

Dieses Design wird im Zero-Trust-Netzwerk für Webanwendungen mit Azure Firewall und Application Gateway genauer erläutert. Diese Dokument konzentriert sich auf den Vergleich mit anderen Designoptionen. In dieser Topologie wird der eingehende Webdatenverkehr sowohl über die Azure Firewall als auch über WAF geleitet. Die WAF sorgt für den Schutz auf der Webanwendungsebene. Azure Firewall fungiert als zentraler Protokollierungs- und Kontrollpunkt und untersucht den Datenverkehr zwischen der Application Gateway-Instanz und den Back-End-Servern. Application Gateway und Azure Firewall sind nicht parallel angeordnet, sondern einander nachgelagert.

Bei Azure Firewall Premium kann dieses Design End-to-End-Szenarien unterstützen, bei denen die Azure Firewall die TLS-Überprüfung anwendet, um den IDPS-Vorgang für den verschlüsselten Datenverkehr zwischen dem Application Gateway und dem Web-Back-End durchzuführen.

Dieses Design eignet sich für Anwendungen, denen die Quell-IP-Adressen für eingehender Clientdatenströme bekannt sein müssen, beispielsweise für die Verarbeitung geolocationspezifischer Inhalte oder für die Protokollierung. Bei der Vorschaltung von Application Gateway vor Azure Firewall wird die Quell-IP-Adresse des eingehenden Pakets im X-Forwarded-For-Header erfasst, damit der Webserver die ursprüngliche IP-Adresse in diesem Header sehen kann. Weitere Informationen finden Sie unter Funktionsweise von Application Gateway.

Eingehende HTTP(S)-Verbindungen aus dem Internet müssen an die öffentliche IP-Adresse des Application Gateways gesendet werden, HTTP(S)-Verbindungen von Azure oder lokale HTTP(S)-Verbindungen an die private IP-Adresse. Vom Application Gateway ausgehend stellen UDRs sicher, dass die Pakete über die Azure Firewall geroutet werden (weitere Informationen finden Sie unten im Paketfluss). Bei eingehenden Nicht-HTTP(S)-Verbindungen sollte der Datenverkehr auf die öffentliche IP-Adresse der Azure Firewall abzielen (wenn er aus dem öffentlichen Internet kommt), oder er wird mittels UDRs über die Azure Firewall gesendet (wenn er aus anderen Azure-VNets oder lokalen Netzwerken kommt). Alle ausgehenden Datenflüsse von Azure-VMs werden mittels UDRs an die Azure Firewall weitergeleitet.

Ein wichtiger Hinweis zu diesem Design: Azure Firewall Premium sieht Datenverkehr mit einer Quell-IP-Adresse aus dem Application Gateway-Subnetz. Wenn dieses Subnetz mit einer privaten IP-Adresse konfiguriert ist (in 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 oder 100.64.0.0/10), behandelt Azure Firewall Premium den Datenverkehr vom Application Gateway als intern und wendet keine IDPS-Regeln für den eingehenden Datenverkehr an. Weitere Informationen zu Azure Firewall IDPS-Regelrichtungen und privaten IP-Präfixen für IDPS finden Sie unter Azure Firewall IDPS-Regeln. Daher wird empfohlen, die privaten IDPS-Präfixe in der Azure Firewall-Richtlinie so zu ändern, dass das Application Gateway-Subnetz nicht als interne Quelle betrachtet wird, um eingehende und ausgehende IDPS-Signaturen auf den Datenverkehr anzuwenden.

In der folgenden Tabelle sind die Datenverkehrsflüsse für dieses Szenario zusammengefasst:

Für den Webdatenverkehr aus der lokalen Umgebung oder dem Internet zu Azure werden von der Azure Firewall-Instanz die Datenflüsse untersucht, die von der WAF bereits zugelassen wurden. Sie verfügen über unterschiedliche potenzielle Szenarien. Dies hängt davon ab, ob Back-End-Datenverkehr (von Application Gateway zu den Anwendungsservern) von Application Gateway verschlüsselt wird:

1. Application Gateway verschlüsselt Datenverkehr gemäß den Zero-Trust-Prinzipien (End-to-End-TLS-Verschlüsselung), und die Azure Firewall-Instanz empfängt verschlüsselten Datenverkehr. Von Azure Firewall Standard können trotzdem Überprüfungsregeln angewendet werden, z. B. Layer 3- und Layer 4-Filterung in Netzwerkregeln, oder die FQDN-Filterung in Anwendungsregeln, indem der TLS-Header für die Servernamensanzeige (Server Name Indication, SNI) genutzt wird. Bei Azure Firewall Premium ist die Transparenz dank TLS-Überprüfung höher, z. B. aufgrund der URL-basierten Filterung.
2. Wenn von Application Gateway unverschlüsselter Datenverkehr an die Anwendungsserver gesendet wird, wird eingehender Datenverkehr für die Azure Firewall-Instanz als Klartext angezeigt. Die TLS-Überprüfung ist auf der Azure Firewall-Instanz nicht erforderlich.
3. Wenn IDPS in der Azure Firewall aktiviert ist, überprüft die Funktion, ob der HTTP-Hostheader mit der Ziel-IP übereinstimmt. Zu diesem Zweck ist eine Namensauflösung für den FQDN erforderlich, der im Hostheader angegeben ist. Diese Namensauflösung kann erreicht werden, indem Azure DNS Private Zones und die DNS-Standardeinstellungen von Azure Firewall mit Azure DNS verwendet werden. Eine andere Möglichkeit ist die Nutzung von benutzerdefinierten DNS-Servern, die in den Azure Firewall-Einstellungen konfiguriert werden müssen. (Weitere Informationen finden Sie unter DNS-Einstellungen für Azure Firewall.) Wenn kein Administratorzugriff auf das virtuelle Netzwerk besteht, in dem die Azure Firewall bereitgestellt wird, ist letztere Methode die einzige Option. Ein Beispiel hierfür ist die Bereitstellung von Azure Firewall auf sicheren Virtual WAN-Hubs.

Aufbau

Für die restlichen Datenflüsse (eingehender Nicht-HTTP(S)-Datenverkehr und jeglicher ausgehender Datenverkehr) werden von der Azure Firewall-Instanz die IDPS- und TLS-Überprüfungen bereitgestellt, wo dies erforderlich ist. Darüber hinaus ist hierbei auch die FQDN-basierte Filterung in Netzwerkregeln gemäß dem DNS möglich.

Workflow

Netzwerkdatenverkehr aus dem öffentlichen Internet folgt diesem Fluss:

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse der Azure Application Gateway-Instanz:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AppGwPIP
2. Die Anforderung an die öffentliche IP-Adresse von Application Gateway IP wird an eine Back-End-Instanz des Gateways verteilt, in diesem Fall 192.168.200.7. Die Application Gateway-Instanz beendet die Verbindung vom Client und stellt eine neue Verbindung mit einem der Back-Ends her. Die UDR zu 192.168.1.0/24 im Application Gateway-Subnetz leitet das Paket zu Azure Firewall weiter und behält die Ziel-IP-Adresse zur Webanwendung bei:
   • Quell-IP-Adresse: 192.168.200.7 (private IP-Adresse der Application Gateway-Instanz)
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: ClientPIP
3. Von der Azure Firewall-Instanz wird kein SNAT-Vorgang für den Datenverkehr durchgeführt, weil dieser an eine private IP-Adresse fließt. Der Datenverkehr wird an die Anwendungs-VM weitergeleitet, wenn die Regeln dies zulassen. Weitere Informationen finden Sie unter Azure Firewall – SNAT. Wenn der Datenverkehr jedoch auf eine Anwendungsregel in der Firewall trifft, wird in der Workload die Quell-IP-Adresse der spezifischen Firewallinstanz angezeigt, die das Paket verarbeitet hat, da die Azure Firewall die Verbindung weiterleitet:
   • Quell-IP-Adresse, wenn der Datenverkehr von einer Azure Firewall-Netzwerkregel zugelassen ist: 192.168.200.7 (die private IP-Adresse von einer der Application Gateway-Instanzen).
   • Quell-IP-Adresse, wenn der Datenverkehr von einer Azure Firewall-Anwendungsregel zugelassen ist: 192.168.100.7 (die private IP-Adresse von einer der Azure Firewall-Instanzen).
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: ClientPIP
4. Die VM beantwortet die Anforderung und kehrt dabei Quell- und Ziel-IP-Adresse um. Die UDR zu 192.168.200.0/24 erfasst das an Application Gateway zurückgesendete Paket und leitet es an Azure Firewall um, dabei wird die Ziel-IP-Adresse zu Application Gateway beibehalten.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
5. Auch hier führt Azure Firewall keine SNAT-Verarbeitung des Datenverkehrs aus, da dieser an eine private IP-Adresse gesendet wird, und der Datenverkehr wird an Application Gateway weitergeleitet.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
6. Schließlich antwortet die Application Gateway-Instanz dem Client:
   • Quell-IP-Adresse: AppGwPIP
   • Ziel-IP-Adresse: ClientPIP

Ausgehende Datenflüsse von den VMs zum öffentlichen Internet durchlaufen Azure Firewall, wie von der UDR zu 0.0.0.0/0definiert.

Application Gateway hinter Firewall

In diesem Design kann Azure Firewall bösartigen Datenverkehr filtern und verwerfen, bevor dieser Application Gateway erreicht. Beispielsweise können Features wie die auf Threat Intelligence basierende Filterung angewendet werden. Ein weiterer Vorteil ist, dass die Anwendung unabhängig vom Protokoll dieselbe öffentliche IP-Adresse für eingehenden und ausgehenden Datenverkehr erhält. Von Azure Firewall wird jedoch die SNAT für eingehenden Datenverkehr verwendet. Daher ist die ursprüngliche IP-Adresse der HTTP-Anforderungen für die Anwendung nicht sichtbar. Aus Verwaltungssicht (etwa zu Problembehandlungszwecken) können Sie die tatsächliche Client-IP-Adresse für eine bestimmte Verbindung ermitteln, indem Sie sie mit den SNAT-Protokollen von Azure Firewall korrelieren.

Der Nutzen dieses Szenarios hat seine Grenzen, da die Azure Firewall nur den verschlüsselten Datenverkehr sieht, der an die Application Gateway-Instanz fließt. Es kann Szenarien geben, in denen dieses Design zu bevorzugen ist. Ein Beispiel wäre, wenn sich weiter vorn im Netzwerk eine andere WAF befindet (etwa Azure Front Door), die ggf. die ursprüngliche Quell-IP-Adresse im HTTP-Header X-Forwarded-For erfassen kann. Das Design kann auch genutzt werden, wenn viele öffentliche IP-Adressen benötigt werden.

Eingehende HTTP(S)-Datenflüsse aus dem öffentlichen Internet sollten an die öffentliche IP-Adresse der Azure Firewall gerichtet sein, und die Azure Firewall übersetzt die Zielnetzwerkadressen der Pakete per DNAT (und SNAT) in die private IP-Adresse der Application Gateway-Instanz. Aus anderen Azure-VNets oder lokalen Netzwerken sollte HTTP(S)-Datenverkehr an die private IP-Adresse von Application Gateway gesendet und mittels UDRs über Azure Firewall weitergeleitet werden. Beim VNet-Standardrouting wird sichergestellt, dass rückläufiger Datenverkehr von den virtuellen Azure-Computer zurück an das Application Gateway geht und vom Application Gateway an die Azure Firewall, wenn DNAT-Regeln verwendet wurden. Für lokalen Datenverkehr oder Datenverkehr von Azure sollten im Application Gateway-Subnetz UDRs verwendet werden (weitere Informationen finden Sie unten im Paketfluss). Jeder von den Azure-VMs ausgehende Datenverkehr in das Internet wird mittels UDRs über die Azure Firewall gesendet.

In der folgenden Tabelle sind die Datenverkehrsflüsse für dieses Szenario zusammengefasst:

Für eingehenden HTTP(S)-Datenverkehr wird von der Azure Firewall-Instanz normalerweise keine Entschlüsselung durchgeführt. Stattdessen werden IDPS-Richtlinien angewendet, für die keine TLS-Überprüfung erforderlich ist, z. B. IP-basierte Filterung oder Nutzung von HTTP-Headern.

Aufbau

Die Anwendung kann die ursprüngliche Quell-IP-Adresse des Webdatenverkehrs nicht sehen. Von Azure Firewall wird eine SNAT-Verarbeitung der Pakete durchgeführt, wenn diese in das virtuelle Netzwerk gelangen. Verwenden Sie Azure Front Door vor der Firewall, um dieses Problem zu vermeiden. Azure Front Door fügt die IP-Adresse des Clients vor dem Eintritt in das virtuelle Azure-Netzwerk als HTTP-Header ein.

Workflow

Netzwerkdatenverkehr aus dem öffentlichen Internet folgt diesem Fluss:

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse von Azure Firewall:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AzFWPIP
2. Die Anforderung an die öffentliche IP-Adresse von Azure Firewall wird an eine Back-End-Instanz der Firewall verteilt, in diesem Fall 192.168.100.7. Azure Firewall führt die DNAT-Verarbeitung des Webports (im Allgemeinen ist dies TCP 443) zur privaten IP-Adresse der Application Gateway-Instanz durch. Azure Firewall führt bei der DNAT-Verarbeitung auch die SNAT-Verarbeitung durch. Weitere Informationen finden Sie unter Azure Firewall – Bekannte Probleme.
   • Quell-IP-Adresse: 192.168.100.7 (die private IP-Adresse der Azure Firewall-Instanz)
   • Ziel-IP-Adresse: 192.168.200.4
3. Application Gateway-Instanz startet eine neue Sitzung zwischen der Instanz, die die Verbindung verarbeitet und einem der Backendserver her. Die ursprüngliche IP-Adresse des Clients ist nicht im Paket enthalten:
   • Quell-IP-Adresse: 192.168.200.7 (die private IP-Adresse der Application Gateway-Instanz)
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: 192.168.100.7
4. Die VM sendet eine Antwort an Application Gateway und kehrt dabei Quell- und Ziel-IP-Adresse um.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
5. Application Gateway antwortet auf die SNAT-verarbeitete Quell-IP-Adresse der Azure Firewall-Instanz. Selbst wenn die Verbindung von einer bestimmten Application Gateway-Instanz wie .7 stammt, sieht Azure Firewall die interne IP-Adresse von Application Gateway .4 als die Quell-IP-Adresse:
   • Quell-IP-Adresse: 192.168.200.4
   • Ziel-IP-Adresse: 192.168.100.7
6. Schließlich macht Azure Firewall SNAT und DNAT rückgängig und antwortet dem Client:
   • Quell-IP-Adresse: AzFwPIP
   • Ziel-IP-Adresse: ClientPIP

Auch wenn für Application Gateway keine Listener für Anwendungen konfiguriert sind, wird immer noch eine öffentliche IP-Adresse benötigt, damit sie von Microsoft verwaltet werden kann.

Lokale Clients

In den vorherigen Designs werden durchgängig Anwendungsclients aus dem öffentlichen Internet veranschaulicht. Lokale Netzwerke greifen ebenfalls auf Anwendungen zu. Die meisten obigen Informationen und Datenverkehrsflüsse sind identisch mit denen für Internetclients, es gibt jedoch einige wichtige Unterschiede:

• Ein VPN-Gateway oder ExpressRoute-Gateway befindet sich vor Azure Firewall oder Application Gateway.
• WAF verwendet die private IP-Adresse von Application Gateway.
• Azure Firewall unterstützt keine DNAT-Verarbeitung für private IP-Adressen. Daher müssen Sie UDRs verwenden, um eingehenden Datenverkehr vom VPN- oder ExpressRoute-Gateway an Azure Firewall zu senden.
• Überprüfen Sie unbedingt Einschränkungen in Bezug auf erzwungenes Tunneln für Azure Application Gateway und für Azure Firewall. Selbst wenn Ihre Workload keine ausgehende Konnektivität zum öffentlichen Internet benötigt, können Sie keine Standardroute wie 0.0.0.0/0 für Application Gateway einfügen, die auf das lokale Netzwerk zeigt; andernfalls unterbrechen Sie den Steuerungsdatenverkehr. Für Azure Application Gateway muss die Standardroute auf das öffentliche Internet zeigen.

Aufbau

Im folgenden Diagramm ist das parallele Design mit Azure Application Gateway und Azure Firewall dargestellt. Anwendungsclients stammen aus einem lokalen Netzwerk, das per VPN oder ExpressRoute mit Azure verbunden ist:

Auch wenn alle Clients lokal oder in Azure angeordnet sind, müssen Azure Application Gateway und Azure Firewall jeweils über öffentliche IP-Adressen verfügen. Mit den öffentlichen IP-Adressen kann Microsoft die Dienste verwalten.

Hub-Spoke-Topologie

Die Designs in diesem Artikel gelten weiterhin für eine Hub-and-Spoke-Topologie. Freigegebene Ressourcen in einem virtuellen Netzwerk des zentralen Hubs stellen eine Verbindung mit Anwendungen in separaten virtuellen Spoke-Netzwerken über VNET-Peerings her.

Aufbau

Überlegungen

Wichtige Überlegungen für diese Topologie:

• Die Azure Firewall-Instanz wird im virtuellen Netzwerk des zentralen Hubs bereitgestellt. Das obige Diagramm zeigt, wie Application Gateway im Hub bereitgestellt wird. Komponenten wie Azure Application Gateway-Instanzen oder Azure API Management-Gateways werden aber häufig von Anwendungsteams verwaltet. In diesem Fall werden diese Komponenten in den virtuellen Spoke-Netzwerken bereitgestellt.
• Achten Sie vor allem auf UDRs in den Spokenetzwerken: Wenn ein Anwendungsserver auf einem Spoke Datenverkehr von einer bestimmten Azure Firewall-Instanz (wie etwa von der Adresse 192.168.100.7 in den obigen Beispielen) empfängt, muss er Datenverkehr zurück an genau diese Instanz senden. Wenn eine UDR im Spoke den nächsten Hop für an den Hub adressierten Datenverkehr an die Azure Firewall-IP-Adresse (192.168.100.4 in den obigen Abbildungen) sendet, gelangen Rückpakete möglicherweise zu einer anderen Azure Firewall-Instanz, was ein asymmetrisches Routing zur Folge hätte. Beachten Sie Folgendes: Wenn Sie über UDRs in den Spoke-VNets verfügen, um Datenverkehr über die Azure Firewall-Instanz an freigegebene Dienste auf dem Hub zu senden, dürfen Sie darin nicht das Präfix des Azure Firewall-Subnetzes einfügen.
• Obige Empfehlung gilt gleichermaßen für das Application Gateway-Subnetz und jegliche weiteren virtuellen Netzwerkgeräte oder Reverseproxys, die möglicherweise im Hub-VNet bereitgestellt werden.
• Sie können den nächsten Hop für die Application Gateway- oder Azure Firewall-Subnetze nicht über statische Routen mit Virtual Network als Typ des nächstes Hops festlegen. Dieser Typ des nächsten Hops ist nur im lokalen VNET und nicht übergreifend für VNET-Peerings gültig. Weitere Informationen zu benutzerdefinierten Routen und zu Typen des nächsten Hops finden Sie unter Routing von Datenverkehr für virtuelle Netzwerke.

Asymmetrisches Routing

Im Diagramm unten ist dargestellt, wie ein Spoke Datenverkehr, für den der SNAT-Vorgang durchgeführt wurde, zurück an den ALB einer Azure Firewall-Instanz sendet. Dieses Setup führt zum asymmetrischen Routing:

Definieren Sie zum Beheben dieses Problems UDRs auf dem Spoke ohne das Azure Firewall-Subnetz, sondern nur mit den Subnetzen, in denen sich die gemeinsamen Dienste befinden. Im Beispiel sollte der richtige UDR auf dem Spoke nur 192.168.1.0/24 enthalten. Er sollte nicht den gesamten 192.168.0.0/16-Bereich (rot markiert) enthalten.

Integration mit anderen Azure-Produkten

Sie können Azure Firewall und Azure Application Gateway mit anderen Azure-Produkten und -Diensten integrieren.

API Management-Gateway

Integrieren Sie Reverseproxydienste wie API Management-Gateway in die obigen Designs, um Funktionen wie API-Drosselung oder Authentifizierungsproxy bereitzustellen. Das Integrieren eines API Management-Gateways bewirkt keine große Änderung der Designs. Der Hauptunterschied besteht darin, dass anstelle des einzelnen Application Gateway-Reverseproxys nun zwei hintereinander verkettete Reverseproxys vorhanden sind.

Weitere Informationen finden Sie im Design Guide to integrate API Management and Application Gateway in a virtual network (Entwurfshandbuch zum Integrieren von API Management und Application Gateway in einem virtuellen Netzwerk) und im Anwendungsmuster API-Gateways für Microservices.

Azure Kubernetes Service

Für Workloads, die in einem AKS-Cluster ausgeführt werden, können Sie Azure Application Gateway unabhängig vom Cluster bereitstellen. Alternativ können Sie auch die Integration in den AKS-Cluster durchführen, indem Sie den Azure Application Gateway-Eingangsdatencontroller verwenden. Beim Konfigurieren bestimmter Objekte auf den Kubernetes-Ebenen (z. B. Dienste und Eingangsressourcen) wird Application Gateway automatisch angepasst, ohne dass zusätzliche manuelle Schritte erforderlich sind.

Azure Firewall spielt eine wichtige Rolle bei der AKS-Clustersicherheit. Mit diesem Dienst verfügen Sie über die erforderliche Funktionalität zum Filtern von ausgehendem Datenverkehr des AKS-Clusters anhand des FQDN, und nicht nur anhand der IP-Adresse. Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS).

Wenn Sie für den Schutz eines AKS-Clusters sowohl Application Gateway als auch Azure Firewall nutzen, empfiehlt es sich, das parallele Design zu verwenden. Von der Application Gateway-Instanz mit WAF werden eingehende Verbindungsanforderungen für Webanwendungen im Cluster verarbeitet. Bei Azure Firewall sind nur explizit zugelassene ausgehende Verbindungen erlaubt. Ein Beispiel für die parallele Entwurfsoption finden Sie unter Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service).

Azure Front Door

Der Funktionsumfang von Azure Front Door überlappt sich teilweise mit der von Azure Application Gateway. Beide Dienste bieten beispielsweise Firewalls für Webanwendungen, SSL-Abladung und URL-basiertes Routing. Ein Hauptunterschied besteht darin, dass sich Azure Application Gateway in einem virtuellen Netzwerk befindet, Azure Front Door hingegen ein globaler, dezentralisierter Dienst ist.

Sie können in einigen Situationen das Design des virtuellen Netzwerks vereinfachen, indem Sie Application Gateway durch eine dezentralisierte Azure Front Door-Instanz ersetzen. Die meisten hier beschriebenen Designs bleiben gültig, mit Ausnahme der Option für die Anordnung von Azure Firewall vor der Azure Front Door-Instanz.

Ein interessanter Anwendungsfall ist die Verwendung von Azure Firewall vor Application Gateway in Ihrem virtuellen Netzwerk. Wie bereits beschrieben, enthält der X-Forwarded-For-Header, der von Application Gateway eingefügt wird, die IP-Adresse der Firewallinstanz, und nicht die IP-Adresse des Clients. Zur Problemumgehung können Sie Azure Front Door vor der Firewall verwenden, um die IP-Adresse des Clients als X-Forwarded-For-Header einzufügen, bevor der Datenverkehr in das virtuelle Azure-Netzwerk gelangt und auf die Azure Firewall trifft. Eine zweite Option ist das Schützen des Ursprungs mit Private Link in Azure Front Door Premium.

Weitere Informationen zu den Unterschieden zwischen den beiden Diensten sowie zu den Fällen, in denen sie jeweils verwendet werden, finden Sie unter Häufig gestellte Fragen zu Azure Front Door.

Andere virtuelle Netzwerkgeräte

Microsoft-Produkte sind nicht die einzige Möglichkeit, Web Application Firewall oder Firewall-Funktionen der nächsten Generation in Azure zu implementieren. Viele Microsoft-Partner bieten virtuelle Netzwerkgeräte (NVAs). Die Konzepte und Entwürfe entsprechen im Wesentlichen denen in diesem Artikel, einige wichtige Aspekte sind jedoch zu beachten:

• Partner-NVAs für Firewalls der nächsten Generation verfügen unter Umständen über bessere Kontrollmöglichkeiten und mehr Flexibilität für NAT-Konfigurationen, die von Azure Firewall nicht unterstützt werden. Beispiele hierfür sind DNAT aus der lokalen Umgebung oder DNAT aus dem Internet ohne SNAT.
• Von Azure verwaltete NVAs (z. B. Application Gateway und Azure Firewall) verringern die Komplexität gegenüber NVAs, bei denen Benutzer die Skalierbarkeit und Resilienz über eine größere Zahl von Geräten verwalten müssen.
• Nutzen Sie bei der Verwendung von NVAs in Azure Aktiv-aktiv-Setups und Setups mit automatischer Skalierung, damit diese Geräte keinen Engpass für im virtuellen Netzwerk ausgeführte Anwendungen darstellen.

Beitragende

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

Hauptautor:

• Jose Moreno | Principal Customer Engineer

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

• Was ist Azure Application Gateway?
• Was ist Azure Firewall?
• Was ist Azure Front Door?
• Azure Kubernetes Service
• Was ist Azure Virtual Network?
• Was ist Azure Web Application Firewall?

Zugehörige Ressourcen

Erkunden Sie die verwandten Architekturen:

• Implementieren eines sicheren Hybridnetzwerks
• Sicher verwaltete Webanwendungen
• Schützen Ihres Microsoft Teams-Kanalbots und Ihrer Web-App hinter einer Firewall
• Consumer-Health-Portal in Azure
• Sicherheitsüberlegungen zu höchst sensiblen IaaS-Apps in Azure
• Mehrinstanzenfähige SaaS-Anwendungen in Azure
• Bereitstellung einer Unternehmens-App per App Service-Umgebung
• Hochverfügbare App-Bereitstellung in einer App Service-Umgebung
• Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)