Firewall und Anwendungsgateway für virtuelle Netzwerke

Um Azure-Anwendungsworkloads zu sichern, sollten Sie Schutzmaßnahmen wie Authentifizierung und Verschlüsselung in den Anwendungen selbst verwenden. Sie können auch Sicherheitsebenen zu den virtuellen Netzwerken (VNets) hinzufügen, die die Anwendungen hosten. Diese Sicherheitsebenen schützen die eingehenden Flüsse der Anwendung vor unbeabsichtigter Nutzung. Sie beschränken auch ausgehende Flüsse im Internet auf nur die Endpunkte, die Ihre Anwendung erfordert. In diesem Artikel werden Azure Virtual Network Sicherheitsdienste wie Azure DDoS Protection, Azure Firewall und Azure Application Gateway beschrieben, wann jeder Dienst verwendet werden soll, und Netzwerkentwurfsoptionen, die beide kombinieren.

• Azure DDoS Protection, kombiniert mit bewährten Methoden für den Anwendungsentwurf, bietet erweiterte DDoS-Entschärfungsfeatures, um mehr Schutz vor DDoS-Angriffen zu bieten. Sie sollten Azure DDOS Protection in jedem virtuellen Umkreisnetzwerk aktivieren.
• Azure Firewall ist eine verwaltete Firewall der nächsten Generation, die Netzwerkadressübersetzung (NAT)bietet. Azure Firewall basiert auf Paketfilterung auf IP-Adressen (Internet Protocol) und Tcp/UDP-Ports (Transmission Control Protocol) und User Datagram Protocol (TCP/UDP) oder auf anwendungsbasierten HTTP(S) oder SQL-Attributen. Azure Firewall wendet auch Die Microsoft-Bedrohungserkennung an, um böswillige IP-Adressen zu identifizieren. Weitere Informationen finden Sie in der Azure Firewall-Dokumentation.
• Azure Firewall Premium umfasst alle Funktionen von Azure Firewall Standard und andere Features, z. B. TLS-Inspektion und Intrusion Detection and Protection System (IDPS).
• Azure Application Gateway ist ein verwalteter Webdatenverkehr lastenausgleich und HTTP(S) vollständiger Reverseproxy, der ssl-Verschlüsselung und Entschlüsselung von Secure Socket Layer (Secure Socket Layer) durchführen kann. Das Anwendungsgateway behält die ursprüngliche Client-IP-Adresse in einem X-Forwarded-For HTTP-Header bei. Das Anwendungsgateway verwendet auch die Webanwendungsfirewall, um Den Webdatenverkehr zu prüfen und Angriffe auf der HTTP-Ebene zu erkennen. Weitere Informationen finden Sie in der dokumentation Application Gateway.
• Azure Web Application Firewall (WAF) ist eine optionale Ergänzung zum Azure-Anwendungsgateway. Es stellt eine Überprüfung von HTTP-Anforderungen bereit und verhindert böswillige Angriffe auf der Webebene, z. B. SQL Injection oder Cross-Site Scripting. Weitere Informationen finden Sie in der Dokumentation zur Webanwendungsfirewall.

Diese Azure-Dienste ergänzen sich. Eine oder die andere kann für Ihre Workloads am besten geeignet sein, oder Sie können sie zusammen für einen optimalen Schutz sowohl auf netzwerk- als auch auf Anwendungsebene verwenden. Verwenden Sie die folgende Entscheidungsstruktur und die Beispiele in diesem Artikel, um die beste Sicherheitsoption für das virtuelle Netzwerk Ihrer Anwendung zu ermitteln.

Azure Firewall und Azure Application Gateway verwenden unterschiedliche Technologien und unterstützen die Verbriefung verschiedener Flüsse:

Abhängig von den Netzwerkflüssen, die eine Anwendung erfordert, kann das Design je nach Anwendung unterschiedlich sein. Das folgende Diagramm bietet eine vereinfachte Entscheidungsstruktur, mit der der empfohlene Ansatz für eine Anwendung ausgewählt wird. Die Entscheidung hängt davon ab, ob die Anwendung über HTTP(S) oder ein anderes Protokoll veröffentlicht wird:

In diesem Artikel werden die allgemein empfohlenen Designs aus dem Flussdiagramm behandelt, und andere, die in weniger häufigen Szenarien anwendbar sind:

• Azure Firewall allein, wenn keine Webanwendungen im virtuellen Netzwerk vorhanden sind. Sie steuert sowohl eingehenden Datenverkehr an die Anwendungen als auch ausgehenden Datenverkehr.
• Anwendungsgateway allein, wenn sich nur Webanwendungen im virtuellen Netzwerk befinden, und Netzwerksicherheitsgruppen (NSGs) ausreichende Ausgabefilterung bereitstellen. Die von der Azure Firewall bereitgestellten Funktionen können viele Angriffsszenarien verhindern (z. B. Datenexfiltration, IDPS usw.). Aus diesem Grund wird das Anwendungsgateway-Szenario normalerweise nicht empfohlen und daher nicht dokumentiert und befindet sich nicht im obigen Flussdiagramm.
• Azure Firewall and Application Gateway parallel, das eines der gängigsten Designs ist. Verwenden Sie diese Kombination, wenn Sie möchten, dass Das Azure-Anwendungsgateway HTTP(S)-Anwendungen vor Webangriffen schützt, und Azure Firewall alle anderen Workloads schützen und ausgehenden Datenverkehr filtern.
• Anwendungsgateway vor azure Firewall, wenn Azure Firewall den gesamten Datenverkehr prüfen soll, WAF zum Schutz des Webdatenverkehrs und der Anwendung, um die Quell-IP-Adresse des Clients zu kennen. Mit azure Firewall Premium und TLS-Inspektion unterstützt dieses Design auch das End-to-End-SSL-Szenario.
• Azure Firewall vor dem Anwendungsgateway, wenn Azure Firewall Datenverkehr prüfen und filtern soll, bevor es das Anwendungsgateway erreicht. Da die Azure Firewall den HTTPS-Datenverkehr nicht entschlüsseln wird, ist die Funktionalität, die sie zum Anwendungsgateway hinzufügt, eingeschränkt. Dieses Szenario ist im obigen Flussdiagramm nicht dokumentiert.

Im letzten Teil dieses Artikels werden Variationen der vorherigen grundlegenden Designs beschrieben. Zu diesen Variationen gehören:

• lokalen Anwendungsclients.
• Hub- und Spoke-Netzwerke.
• Azure Kubernetes Service (AKS) Implementierungen.

Sie können weitere Reverseproxydienste wie ein API-Verwaltungsgateway Gateway oder Azure Front Door-hinzufügen. Alternativ können Sie die Azure-Ressourcen auch durch virtuelle Netzwerkgeräte von Drittanbieternersetzen.

Nur Azure Firewall

Wenn keine webbasierten Workloads im virtuellen Netzwerk vorhanden sind, die von WAF profitieren können, können Sie nur Azure Firewall verwenden. Das Design in diesem Fall ist einfach, aber das Überprüfen des Paketflusses hilft dabei, komplexere Designs zu verstehen. In diesem Design werden alle eingehenden Datenverkehr über benutzerdefinierte Routen (UDRs) für Verbindungen von lokalen oder anderen Azure-VNets an die Azure-Firewall gesendet. Sie wird an die öffentliche IP-Adresse der Azure-Firewall für Verbindungen aus dem öffentlichen Internet adressiert, wie das folgende Diagramm zeigt. Ausgehender Datenverkehr von Azure VNets wird über UDRs an die Firewall gesendet, wie im folgenden Dialogfeld dargestellt.

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

Azure Firewall prüft keinen eingehenden HTTP(S)-Datenverkehr. Es wird jedoch in der Lage sein, Layer 3 & Layer 4-Regeln und FQDN-basierte Anwendungsregeln anzuwenden. Azure Firewall prüft ausgehenden HTTP(S)-Datenverkehr je nach Azure Firewall-Ebene und ob Sie TLS-Inspektion konfigurieren:

• Azure Firewall Standard prüft nur Layer 3 & Layer 4-Attribute der Pakete in Netzwerkregeln und den Host-HTTP-Header in Anwendungsregeln.
• Azure Firewall Premium fügt Funktionen hinzu, z. B. das Überprüfen anderer HTTP-Header (z. B. der User-Agent) und die Aktivierung der TLS-Inspektion für eine tiefere Paketanalyse. Azure Firewall entspricht nicht einer Webanwendungsfirewall. Wenn Sie über Webworkloads in Ihrem virtuellen Netzwerk verfügen, wird die Verwendung von WAF dringend empfohlen.

Das folgende Paketexemplarbeispiel zeigt, wie ein Client über das öffentliche Internet auf eine vom virtuellen Computer gehostete Anwendung zugreift. Das Diagramm enthält nur einen virtuellen Computer aus Gründen der Einfachheit. Für eine höhere Verfügbarkeit und Skalierbarkeit verfügen Sie über mehrere Anwendungsinstanzen hinter einem Lastenausgleich. In diesem Design prüft Azure Firewall sowohl eingehende Verbindungen aus dem öffentlichen Internet als auch ausgehende Verbindungen von der Subnetz-VM der Anwendung mithilfe des UDR.

• Azure Firewall service deploys several instances under the covers, here with the front-end IP address 192.168.100.4 and internal addresses from the range 192.168.100.0/26. Diese einzelnen Instanzen sind normalerweise für den Azure-Administrator unsichtbar. Das Notieren des Unterschieds ist jedoch in einigen Fällen hilfreich, z. B. bei der Problembehandlung von Netzwerkproblemen.
• Wenn Datenverkehr von einem lokalen virtuellen privaten Netzwerk (VPN) oder Azure ExpressRoute Gateway anstelle des Internets stammt, startet der Client die Verbindung mit der IP-Adresse des virtuellen Computers. Die Verbindung mit der IP-Adresse der Firewall wird nicht gestartet, und die Firewall führt keine Quell-NAT pro Standard aus.

Architektur

Das folgende Diagramm zeigt den Datenverkehrsfluss, wenn die Instanz-IP-Adresse 192.168.100.7ist.

Arbeitsablauf

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse der Azure-Firewall:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AzFwPIP
2. Die Anforderung an die öffentliche AZURE Firewall-IP wird an eine Back-End-Instanz der Firewall verteilt, in diesem Fall 192.168.100.7. Die DNS-Regel (Destination NAT) Azure Firewall die Ziel-IP-Adresse in die Anwendungs-IP-Adresse innerhalb des virtuellen Netzwerks übersetzt. Die Azure Firewall Source NATs (SNATs) das Paket, wenn es DNAT tut. Weitere Informationen finden Sie unter bekannten Problemender Azure-Firewall. Der virtuelle Computer sieht die folgenden IP-Adressen im eingehenden Paket:
   • Quell-IP-Adresse: 192.168.100.7
   • Ziel-IP-Adresse: 192.168.1.4
3. Der virtuelle Computer antwortt auf die Anwendungsanforderung, das Umkehren der Quell- und Ziel-IP-Adressen. Für den eingehenden Fluss ist keine benutzerdefinierte Route (UDR)erforderlich, da es sich bei der Quell-IP um die IP-Adresse der Azure Firewall handelt. Der UDR im Diagramm für 0.0.0.0/0 ist für ausgehende Verbindungen vorgesehen, um sicherzustellen, dass Pakete mit dem öffentlichen Internet die 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 liefert die Antwort auf den Client:
   • Quell-IP-Adresse: AzFwPIP
   • Ziel-IP-Adresse: ClientPIP

Nur Anwendungsgateway

Dieser Entwurf deckt die Situation ab, in der nur Webanwendungen im virtuellen Netzwerk vorhanden sind und das Prüfen ausgehender Datenverkehr mit NSGs ausreicht, um ausgehende Flüsse im Internet zu schützen.

Der Hauptunterschied zum vorherigen Design mit nur der Azure-Firewall besteht darin, dass das Anwendungsgateway nicht als Routinggerät mit NAT fungiert. Es verhält sich als vollständiger Reverseanwendungsproxy. Das anwendungsgateway stoppt die Websitzung vom Client und richtet eine separate Sitzung mit einem seiner Back-End-Server ein. Eingehende HTTP(S)-Verbindungen aus dem Internet müssen an die öffentliche IP-Adresse des Anwendungsgateways, Verbindungen von Azure oder lokal zur privaten IP-Adresse des Gateways gesendet werden. Der Rückgabedatenverkehr von den Azure-VMs folgt dem standardmäßigen VNet-Routing zurück zum Anwendungsgateway (weitere Details finden Sie weiter unten im Paket). Ausgehende Internetflüsse von Azure-VMs gehen direkt ins Internet.

In der folgenden Tabelle sind Datenverkehrsflüsse zusammengefasst:

Architektur

Das folgende Paketexemplarbeispiel zeigt, wie ein Client über das öffentliche Internet auf die vom virtuellen Computer gehostete Anwendung zugreift.

Arbeitsablauf

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse des Azure-Anwendungsgateways:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AppGwPIP
2. Die Anforderung an die öffentliche IP des Anwendungsgateways 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 sieht die Application Gateway-Instanz als Quell-IP-Adresse. Das Anwendungsgateway 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 Anwendungsgatewayinstanz)
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: ClientPIP
3. Der virtuelle Computer antwortt auf die Anwendungsanforderung, das Umkehren der Quell- und Ziel-IP-Adressen. Der virtuelle Computer weiß bereits, wie das Anwendungsgateway erreicht werden kann, daher ist kein UDR erforderlich.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
4. Schließlich antwortt die Application Gateway-Instanz auf den Client:
   • Quell-IP-Adresse: AppGwPIP
   • Ziel-IP-Adresse: ClientPIP

Das Azure-Anwendungsgateway fügt Metadaten zu den Paket-HTTP-Headern hinzu, z. B. den X-Forwarded-For- Header, der die IP-Adresse des ursprünglichen Clients enthält. Einige Anwendungsserver benötigen die IP-Adresse des Quellclients, um geolocationspezifische Inhalte oder für die Protokollierung zu verwenden. Weitere Informationen finden Sie unter Funktionsweise eines Anwendungsgateways.

• Die IP-Adresse 192.168.200.7 ist eine der Instanzen, die der Azure-Anwendungsgatewaydienst unter den Deckeln bereitstellt, hier mit der internen, privaten Front-End-IP-Adresse 192.168.200.4. Diese einzelnen Instanzen sind normalerweise für den Azure-Administrator unsichtbar. Das Notieren des Unterschieds ist jedoch in einigen Fällen hilfreich, z. B. bei der Problembehandlung von Netzwerkproblemen.

• Der Fluss ist ähnlich, wenn der Client von einem lokalen Netzwerk über ein VPN- oder ExpressRoute-Gateway stammt. Der Unterschied besteht darin, dass der Client anstelle der öffentlichen Adresse auf die private IP-Adresse des Anwendungsgateways zugreift.

Firewall und Anwendungsgateway parallel

Aufgrund seiner Einfachheit und Flexibilität ist das Ausführen des Anwendungsgateways und der Azure-Firewall häufig das beste Szenario.

Implementieren Sie diesen Entwurf, wenn eine Mischung aus Web- und Nicht-Webworkloads im virtuellen Netzwerk vorhanden ist. Azure WAF im Azure-Anwendungsgateway schützt eingehenden Datenverkehr an die Webworkloads, und die Azure-Firewall prüft eingehenden Datenverkehr für die anderen Anwendungen. Die Azure Firewall deckt ausgehende Flüsse aus beiden Workloadtypen ab.

Eingehende HTTP(S)-Verbindungen aus dem Internet sollten an die öffentliche IP-Adresse des Anwendungsgateways, HTTP(S)-Verbindungen von Azure oder lokal an ihre private IP-Adresse gesendet werden. Das Standardmäßige VNet-Routing sendet die Pakete vom Anwendungsgateway an die Ziel-VMs sowie von den Ziel-VMs zurück an das Anwendungsgateway (weitere Details finden Sie weiter unten im Paket). Bei eingehenden Nicht-HTTP(S)-Verbindungen sollte der Datenverkehr auf die öffentliche IP-Adresse der Azure-Firewall ausgerichtet sein (wenn sie aus dem öffentlichen Internet stammen), oder sie wird über die Azure-Firewall von UDRs gesendet (wenn sie von anderen Azure VNets oder lokalen Netzwerken stammen). Alle ausgehenden Flüsse von Azure-VMs werden von UDRs an die Azure-Firewall weitergeleitet.

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

Dieses Design bietet wesentlich genauere Ausgangsfilterung als NSGs. Wenn Anwendungen beispielsweise eine Verbindung mit einem bestimmten Azure Storage-Konto benötigen, können Sie vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN)-basierten Filtern verwenden. Bei FQDN-basierten Filtern senden Anwendungen keine Daten an nicht autorisierte Speicherkonten. Dieses Szenario konnte nicht nur mithilfe von NSGs verhindert werden. Dieser Entwurf wird häufig verwendet, bei dem ausgehender Datenverkehr FQDN-basierte Filterung erfordert. Eine Beispielsituation ist, wenn das Einschränken des Ausgehenden Datenverkehrs von einem Azure Kubernetes Services-Cluster.

Architekturen

Das folgende Diagramm veranschaulicht den Datenverkehrsfluss für eingehende HTTP(S)-Verbindungen von einem externen Client:

Das folgende Diagramm veranschaulicht den Datenverkehrsfluss für ausgehende Verbindungen von den Netzwerk-VMs zum Internet. Ein Beispiel ist das Herstellen einer Verbindung mit Back-End-Systemen oder das Abrufen von Betriebssystemupdates:

Die Paketflussschritte für jeden Dienst sind identisch mit den vorherigen eigenständigen Entwurfsoptionen.

Anwendungsgateway vor der Firewall

Dieses Design wird in Zero-Trust-Netzwerk für Webanwendungen mit Azure Firewall and Application Gatewayausführlicher erläutert. Dieses Dokument konzentriert sich auf den Vergleich mit den anderen Entwurfsoptionen. In dieser Topologie durchläuft eingehender Webdatenverkehr sowohl azure Firewall als auch WAF. Der WAF bietet Schutz auf der Webanwendungsebene. Azure Firewall fungiert als zentraler Protokollierungs- und Kontrollpunkt und prüft den Datenverkehr zwischen dem Anwendungsgateway und den Back-End-Servern. Das Anwendungsgateway und die Azure-Firewall sitzen nicht parallel, sondern nacheinander.

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

Dieser Entwurf eignet sich für Anwendungen, die eingehende Clientquell-IP-Adressen kennen müssen, z. B. für geolocationspezifische Inhalte oder für die Protokollierung. Das Anwendungsgateway vor der Azure Firewall erfasst die Quell-IP-Adresse des eingehenden Pakets in der X-weiterleitunged-for--Header, sodass der Webserver die ursprüngliche IP-Adresse in diesem Header sehen kann. Weitere Informationen finden Sie unter Funktionsweise eines Anwendungsgateways.

Eingehende HTTP(S)-Verbindungen aus dem Internet müssen an die öffentliche IP-Adresse des Anwendungsgateways, HTTP(S)-Verbindungen von Azure oder lokal an die private IP-Adresse gesendet werden. Über das Anwendungsgateway-UDRs wird sichergestellt, dass die Pakete über die Azure-Firewall weitergeleitet werden (weitere Informationen finden Sie im Paket. Bei eingehenden Nicht-HTTP(S)-Verbindungen sollte der Datenverkehr auf die öffentliche IP-Adresse der Azure-Firewall ausgerichtet sein (wenn sie aus dem öffentlichen Internet stammen), oder sie wird über die Azure-Firewall von UDRs gesendet (wenn sie von anderen Azure VNets oder lokalen Netzwerken stammen). Alle ausgehenden Flüsse von Azure-VMs werden von UDRs an die Azure-Firewall weitergeleitet.

Ein wichtiger Hinweis auf diesen Entwurf ist, dass Azure Firewall Premium Datenverkehr mit einer Quell-IP-Adresse aus dem Subnetz des Anwendungsgateways anzeigt. Wenn dieses Subnetz mit einer privaten IP-Adresse (in 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 oder 100.64.0.0/10) konfiguriert ist, behandelt Azure Firewall Premium den Datenverkehr vom Anwendungsgateway als intern und wendet keine IDPS-Regeln für eingehenden Datenverkehr an. Weitere Informationen zu Azure Firewall IDPS-Regelbeschreibungen und privaten IP-Präfixen für IDPS finden Sie in Azure Firewall IDPS Rules. Daher wird empfohlen, die privaten IDPS-Präfixe in der Azure Firewall-Richtlinie so zu ändern, dass das Anwendungsgateway-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:

Bei Webdatenverkehr von lokal oder internet zu Azure überprüft die Azure-Firewall Flüsse, die der WAF bereits zugelassen hat. Je nachdem, ob das Anwendungsgateway Back-End-Datenverkehr verschlüsselt (Datenverkehr vom Anwendungsgateway zu den Anwendungsservern), haben Sie unterschiedliche potenzielle Szenarien:

1. Das Anwendungsgateway verschlüsselt Datenverkehr nach den Prinzipien der Nullvertrauensstellung (End-to-End-TLS-Verschlüsselung), und die Azure-Firewall erhält verschlüsselten Datenverkehr. Dennoch kann Azure Firewall Standard Prüfregeln anwenden, z. B. Layer 3 & Layer 4-Filterung in Netzwerkregeln oder FQDN-Filterung in Anwendungsregeln mithilfe des TLS Server Name Indication (SNI)-Headers. Azure Firewall Premium bietet eine tiefere Sichtbarkeit bei der TLS-Inspektion, z. B. URL-basierte Filterung.
2. Wenn das Anwendungsgateway unverschlüsselten Datenverkehr an die Anwendungsserver sendet, wird in der Azure-Firewall eingehender Datenverkehr im Klartext angezeigt. DIE TLS-Inspektion ist in der Azure-Firewall nicht erforderlich.
3. Wenn IDPS in der Azure-Firewall aktiviert ist, wird überprüft, ob der HTTP-Hostheader mit der Ziel-IP übereinstimmt. Zu diesem Zweck benötigt er eine Namensauflösung für den FQDN, der im Hostheader angegeben ist. Diese Namensauflösung kann mit Azure DNS Private Zones und den Standardmäßigen Azure Firewall DNS-Einstellungen mit Azure DNS erreicht werden. Sie kann auch mit benutzerdefinierten DNS-Servern erreicht werden, die in den Azure Firewall-Einstellungen konfiguriert werden müssen. (Weitere Informationen finden Sie unter Azure Firewall DNS Settings.) Wenn kein Administratorzugriff auf das virtuelle Netzwerk vorhanden ist, in dem die Azure-Firewall bereitgestellt wird, ist die letztere Methode die einzige Möglichkeit. Ein Beispiel hierfür ist, dass Azure Firewalls in virtual WAN Secured Hubs bereitgestellt werden.

Architektur

Für den Rest der Flüsse (eingehender Nicht-HTTP(S)-Datenverkehr und ausgehender Datenverkehr stellt die Azure Firewall ggf. IDPS-Inspektion und TLS-Inspektion bereit. Außerdem werden FQDN-basierte Filterung in Netzwerkregeln basierend auf DNS bereitgestellt.

Arbeitsablauf

Der Netzwerkdatenverkehr aus dem öffentlichen Internet folgt diesem Fluss:

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse des Azure-Anwendungsgateways:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AppGwPIP
2. Die Anforderung an die öffentliche IP des Anwendungsgateways wird an eine Back-End-Instanz des Gateways verteilt, in diesem Fall 192.168.200.7. Die Application Gateway-Instanz stoppt die Verbindung vom Client und stellt eine neue Verbindung mit einem der Back-Ends her. Der UDR zum 192.168.1.0/24 im Anwendungsgateway-Subnetz leitet das Paket an die Azure-Firewall weiter, wobei die Ziel-IP an die Webanwendung beibehalten wird:
   • Quell-IP-Adresse: 192.168.200.7 (private IP-Adresse der Anwendungsgatewayinstanz)
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: ClientPIP
3. Azure Firewall verwendet keinen SNAT-Datenverkehr, da der Datenverkehr zu einer privaten IP-Adresse wird. Er leitet den Datenverkehr an den virtuellen Anwendungscomputer weiter, wenn regeln dies zulassen. Weitere Informationen finden Sie unter Azure Firewall SNAT. Wenn der Datenverkehr jedoch auf eine Anwendungsregel in der Firewall trifft, wird die Quell-IP-Adresse der spezifischen Firewallinstanz angezeigt, die das Paket verarbeitet hat, da die Azure-Firewall die Verbindung proxyt:
   • Quell-IP-Adresse, wenn der Datenverkehr durch eine Azure Firewall-Netzwerkregel zulässig ist: 192.168.200.7 (die private IP-Adresse einer der Anwendungsgateway-Instanzen).
   • Quell-IP-Adresse, wenn der Datenverkehr durch eine Azure Firewall-Anwendungsregel zulässig ist: 192.168.100.7 (die private IP-Adresse einer der Azure Firewall-Instanzen).
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For-Header: ClientPIP
4. Der virtuelle Computer antwortt auf die Anforderung, das Umkehren der Quell- und Ziel-IP-Adressen. Der UDR, um 192.168.200.0/24 erfasst das an das Anwendungsgateway gesendete Paket und leitet es an die Azure Firewall um, während die Ziel-IP in Richtung des Anwendungsgateways beibehalten wird.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
5. Hier gibt die Azure Firewall nicht den Datenverkehr an, da sie an eine private IP-Adresse weitergeleitet wird und den Datenverkehr an das Anwendungsgateway weiterleitet.
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
6. Schließlich antwortt die Application Gateway-Instanz auf den Client:
   • Quell-IP-Adresse: AppGwPIP
   • Ziel-IP-Adresse: ClientPIP

Ausgehende Flüsse von den virtuellen Computern zum öffentlichen Internet durchlaufen die Azure Firewall, wie vom UDR definiert, um 0.0.0.0/0.

Anwendungsgateway nach der Firewall

Mit diesem Design kann Azure Firewall bösartigen Datenverkehr filtern und verwerfen, bevor es das Anwendungsgateway erreicht. Beispielsweise können Features wie die auf Bedrohungserkennung basierende Filterung angewendet werden. Ein weiterer Vorteil ist, dass die Anwendung unabhängig vom Protokoll die gleiche öffentliche IP-Adresse für eingehenden und ausgehenden Datenverkehr erhält. Azure Firewall SNATs jedoch den eingehenden Datenverkehr, sodass die Anwendung keine Sichtbarkeit für die ursprüngliche IP-Adresse der HTTP-Anforderungen hat. Aus Verwaltungsperspektive können Sie z. B. zur Problembehandlung die tatsächliche Client-IP für eine bestimmte Verbindung abrufen, indem Sie sie mit den SNAT-Protokollen der Azure-Firewall korrelieren.

In diesem Szenario gibt es einen begrenzten Vorteil, da in der Azure-Firewall nur verschlüsselter Datenverkehr zum Anwendungsgateway angezeigt wird. Es kann Szenarien geben, in denen dieses Design bevorzugt wird. Ein Fall ist, wenn eine andere WAF früher im Netzwerk ist (z. B. mit Azure Front Door), wodurch die ursprüngliche Quell-IP im X-Forwarded-For HTTP-Header erfasst werden kann. Oder das Design wird bevorzugt, wenn viele öffentliche IP-Adressen erforderlich sind.

HTTP(S) eingehende Flüsse aus dem öffentlichen Internet sollten auf die öffentliche IP-Adresse der Azure-Firewall abzielen, und die Azure Firewall erbt (und SNAT) die Pakete an die private IP-Adresse des Anwendungsgateways. Von anderen Azure VNets oder lokalen Netzwerken sollte DER HTTP(S)-Datenverkehr an die private IP des Anwendungsgateways gesendet und über die Azure-Firewall mit UDRs weitergeleitet werden. Standardmäßiges VNet-Routing stellt sicher, dass der Rückgabedatenverkehr von den Azure-VMs zurück zum Anwendungsgateway und vom Anwendungsgateway zur Azure-Firewall zurückgeht, wenn DNAT-Regeln verwendet wurden. Für Den Datenverkehr von lokalen oder Azure UDRs im Anwendungsgateway-Subnetz sollte verwendet werden (weitere Informationen finden Sie im Paket. Der gesamte ausgehende Datenverkehr von den Azure-VMs an das Internet wird über die Azure-Firewall von UDRs gesendet.

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

Bei eingehendem HTTP(S)-Datenverkehr würde die Azure-Firewall in der Regel keinen Datenverkehr entschlüsseln. Stattdessen würden IDPS-Richtlinien angewendet, die keine TLS-Überprüfung erfordern, z. B. IP-basierte Filterung oder verwendung von HTTP-Headern.

Architektur

Die Anwendung kann die ursprüngliche Quell-IP-Adresse des Webdatenverkehrs nicht sehen. die Azure Firewall SNATs die Pakete, sobald sie in das virtuelle Netzwerk gelangen. Um dieses Problem zu vermeiden, verwenden Sie Azure Front Door vor der Firewall. Azure Front Door fügt die IP-Adresse des Clients als HTTP-Header ein, bevor er das virtuelle Azure-Netzwerk eingibt.

Arbeitsablauf

Der Netzwerkdatenverkehr aus dem öffentlichen Internet folgt diesem Fluss:

1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse der Azure-Firewall:
   • Quell-IP-Adresse: ClientPIP
   • Ziel-IP-Adresse: AzFWPIP
2. Die Anforderung an die öffentliche AZURE Firewall-IP wird an eine Back-End-Instanz der Firewall verteilt, in diesem Fall 192.168.100.7. Die Azure Firewall DNATs den Webport, in der Regel TCP 443, an die private IP-Adresse der Application Gateway-Instanz. Azure Firewall auch SNATs beim Ausführen von DNAT. Weitere Informationen finden Sie unter bekannten Problemen der Azure-Firewall:
   • Quell-IP-Adresse: 192.168.100.7 (die private IP-Adresse der Azure Firewall-Instanz)
   • Ziel-IP-Adresse: 192.168.200.4
3. Das Anwendungsgateway richtet eine neue Sitzung zwischen der Instanz, die die Verbindung verarbeitet, und einem der Back-End-Server ein. Die ursprüngliche IP-Adresse des Clients befindet sich nicht im Paket:
   • Quell-IP-Adresse: 192.168.200.7 (die private IP-Adresse der Anwendungsgatewayinstanz)
   • Ziel-IP-Adresse: 192.168.1.4
   • X-Forwarded-For Kopfzeile: 192.168.100.7
4. Der virtuelle Computer antwortt auf das Anwendungsgateway, das Umkehren von Quell- und Ziel-IP-Adressen:
   • Quell-IP-Adresse: 192.168.1.4
   • Ziel-IP-Adresse: 192.168.200.7
5. Das Anwendungsgateway antwortet auf die SNAT-Quell-IP-Adresse der Azure Firewall-Instanz. Selbst wenn die Verbindung von einer bestimmten Anwendungsgatewayinstanz wie .7stammt, sieht Azure Firewall die interne IP-Adresse des Anwendungsgateways .4 als Quell-IP:
   • 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 beantwortet den Client:
   • Quell-IP-Adresse: AzFwPIP
   • Ziel-IP-Adresse: ClientPIP

Selbst wenn das Anwendungsgateway keine Listener für Anwendungen konfiguriert hat, benötigt es weiterhin eine öffentliche IP-Adresse, damit Microsoft sie verwalten kann.

Lokale Clients

Im vorherigen Design werden alle Anwendungsclients angezeigt, die aus dem öffentlichen Internet stammen. Lokale Netzwerke greifen auch auf Anwendungen zu. Die meisten der vorherigen Informationen und Datenverkehrsflüsse sind identisch mit Internetclients, aber es gibt einige wichtige Unterschiede:

• Ein VPN-Gateway oder ExpressRoute-Gateway befindet sich vor der Azure-Firewall oder dem Anwendungsgateway.
• WAF verwendet die private IP-Adresse des Anwendungsgateways.
• Azure Firewall unterstützt DNAT nicht für private IP-Adressen. Aus diesem Grund müssen Sie UDRs verwenden, um eingehenden Datenverkehr von den VPN- oder ExpressRoute-Gateways an azure Firewall zu senden.
• Stellen Sie sicher, dass Sie erzwungenen Tunneling- für das Azure-Anwendungsgateway und für die Azure Firewallüberprüfen. Auch wenn Ihre Workload keine ausgehende Verbindung mit dem öffentlichen Internet benötigt, können Sie keine Standardroute wie 0.0.0.0/0 für das Anwendungsgateway einfügen, das auf das lokale Netzwerk verweist, oder Sie unterbrechen den Steuerungsverkehr. Für das Azure-Anwendungsgateway muss die Standardroute auf das öffentliche Internet verweisen.

Architektur

Das folgende Diagramm zeigt das parallele Design von Azure Application Gateway und Azure Firewall. Anwendungsclients stammen aus einem lokalen Netzwerk, das über VPN oder ExpressRoute mit Azure verbunden ist:

Auch wenn sich alle Clients lokal oder in Azure befinden, müssen azure-Anwendungsgateway und Azure Firewall über öffentliche IP-Adressen verfügen. Die öffentlichen IP-Adressen ermöglichen Es Microsoft, die Dienste zu verwalten.

Hub- und Speichentopologie

Die Designs in diesem Artikel gelten weiterhin in einem Hub und einer Speichen- Topologie. Gemeinsam genutzte Ressourcen in einem zentralen virtuellen Hubnetzwerk stellen eine Verbindung mit Anwendungen in separaten virtuellen Netzwerken über virtuelle Netzwerk-Peerings her.

Architektur

Betrachtungen

Einige Überlegungen für diese Topologie umfassen:

• Die Azure Firewall wird im virtuellen Netzwerk des zentralen Hubs bereitgestellt. Das obige Diagramm zeigt die Vorgehensweise zum Bereitstellen des Anwendungsgateways im Hub. Anwendungsteams verwalten häufig Komponenten wie Azure-Anwendungsgateways oder Azure-API-Verwaltungsgateways. In diesem Fall werden diese Komponenten in den virtuellen Speichennetzwerken bereitgestellt.
• Achten Sie besonders auf UDRs in den Speichennetzwerken: Wenn ein Anwendungsserver in einem Speichendatenverkehr von einer bestimmten Azure Firewall-Instanz empfängt, wie die 192.168.100.7 Adresse in den vorherigen Beispielen, sollte der Rückgabedatenverkehr an dieselbe Instanz zurücksenden. Wenn ein UDR in der Speichen den nächsten Hop des Datenverkehrs festlegt, der an den Hub an die Azure Firewall-IP-Adresse adressiert ist (192.168.100.4 in den obigen Diagrammen), enden die Rückgabepakete möglicherweise auf einer anderen Azure Firewall-Instanz, was zu asymmetrischem Routing führt. Stellen Sie sicher, dass diese UDRs nicht das Präfix des Azure Firewall-Subnetzes enthalten, wenn Sie UDRs in den speichen-VNets haben, um Datenverkehr an gemeinsame Dienste im Hub über die Azure-Firewall zu senden.
• Die vorherige Empfehlung gilt gleichermaßen für das Anwendungsgateway-Subnetz und alle anderen virtuellen Netzwerkgeräte oder Reverseproxys, die möglicherweise im Hub-VNet bereitgestellt werden.
• Sie können den nächsten Hop für das Anwendungsgateway oder Azure Firewall-Subnetz nicht über statische Routen mit einem nächsten Hoptyp von Virtual Networkfestlegen. Dieser nächste Hoptyp ist nur im lokalen VNet gültig und nicht über VNet-Peerings hinweg. Weitere Informationen zu benutzerdefinierten Routen und nächsten Hoptypen finden Sie unter Routing virtueller Netzwerke.

Asymmetrisches Routing

Das folgende Diagramm zeigt, wie eine Speichen den SNATted-Datenverkehr zurück an die ALB einer Azure-Firewall sendet. Diese Einrichtung verursacht asymmetrisches Routing:

Um dieses Problem zu lösen, definieren Sie UDRs im Gesprochenen ohne das Azure Firewall-Subnetz, aber nur mit den Subnetzen, in denen sich die gemeinsamen Dienste befinden. Im Beispiel sollte der richtige UDR in der Speichen nur 192.168.1.0/24 enthalten. Sie sollte nicht die gesamte 192.168.0.0/16 enthalten, wie rot markiert.

Integration in andere Azure-Produkte

Sie können Azure Firewall und Azure-Anwendungsgateway in andere Azure-Produkte und -Dienste integrieren.

API-Verwaltungsgateway

Integrieren Sie Reverseproxydienste wie API Management Gateway in die vorherigen Designs, um Funktionen wie API-Drosselung oder Authentifizierungsproxy bereitzustellen. Durch die Integration eines API-Verwaltungsgateways werden die Designs nicht erheblich geändert. Der Hauptunterschied besteht darin, dass anstelle des einzelnen Anwendungsgateway-Reverseproxys zwei Reverseproxys miteinander verkettet sind.

Weitere Informationen finden Sie im Entwurfshandbuch zum Integrieren von API-Verwaltung und Anwendungsgateway in ein virtuelles Netzwerk und das Anwendungsmuster API-Gateways für Microservices.

Azure Kubernetes-Dienst

Für Workloads, die auf einem AKS-Cluster ausgeführt werden, können Sie Das Azure-Anwendungsgateway unabhängig vom Cluster bereitstellen. Oder Sie können es mit dem Azure Application Gateway Ingress Controllerin den AKS-Cluster integrieren. Beim Konfigurieren bestimmter Objekte auf Kubernetes-Ebenen (z. B. Dienste und Eingänge) passt sich das Anwendungsgateway automatisch an, ohne zusätzliche manuelle Schritte ausführen zu müssen.

Azure Firewall spielt eine wichtige Rolle bei der AKS-Clustersicherheit. Es bietet die erforderliche Funktionalität zum Filtern des Ausgehenden Datenverkehrs vom AKS-Cluster basierend auf FQDN, nicht nur der IP-Adresse. Weitere Informationen finden Sie unter Steuern des Ausgehenden Datenverkehrs für AKS-Clusterknoten.

Wenn Sie Anwendungsgateway und Azure Firewall kombinieren, um einen AKS-Cluster zu schützen, ist es am besten, die parallele Entwurfsoption zu verwenden. Das Anwendungsgateway mit WAF verarbeitet eingehende Verbindungsanforderungen an Webanwendungen im Cluster. Azure Firewall erlaubt nur explizit zulässige ausgehende Verbindungen. Ein Beispiel für die parallele Entwurfsoption finden Sie unter Basisplanarchitektur für einen Azure Kubernetes Service (AKS)-Cluster.

Azure Front Door

Azure Front Door Funktionalität überlappt teilweise mit dem Azure-Anwendungsgateway. Beispielsweise bieten beide Dienste Webanwendungsfirewalling, SSL-Offloading und URL-basiertes Routing. Ein Hauptunterschied besteht darin, dass Azure-Anwendungsgateway sich zwar in einem virtuellen Netzwerk befindet, aber Azure Front Door ein globaler, dezentraler Dienst ist.

Manchmal können Sie das Design des virtuellen Netzwerks vereinfachen, indem Sie das Anwendungsgateway durch eine dezentrale Azure Front Door ersetzen. Die meisten hier beschriebenen Designs bleiben gültig, mit Ausnahme der Option, Azure Firewall vor Azure Front Door zu platzieren.

Ein interessanter Anwendungsfall ist die Verwendung von Azure Firewall vor dem Anwendungsgateway in Ihrem virtuellen Netzwerk. Wie bereits beschrieben, enthält der vom Anwendungsgateway eingefügte X-Forwarded-For Header die IP-Adresse der Firewallinstanz, nicht die IP-Adresse des Clients. Eine Problemumgehung besteht darin, Azure Front Door vor der Firewall zu verwenden, um die IP-Adresse des Clients als X-Forwarded-For Header einzugeben, bevor der Datenverkehr in das virtuelle Netzwerk eintritt und auf die Azure-Firewall trifft. Eine zweite Option besteht darin, Ihren Ursprung mit privatem Link in Azure Front Door Premiumzu sichern.

Weitere Informationen zu den Unterschieden zwischen den beiden Diensten oder zu den einzelnen Diensten finden Sie unter Häufig gestellte Fragen zu Azure Front Door.

Andere virtuelle Netzwerkgeräte

Microsoft-Produkte sind nicht die einzige Wahl, webanwendungsfirewall oder Firewallfunktionen der nächsten Generation in Azure zu implementieren. Eine breite Palette von Microsoft-Partnern stellt virtuelle Netzwerkgeräte (VIRTUAL Appliances, NVAs) bereit. Die Konzepte und Designs sind im Wesentlichen identisch mit diesem Artikel, aber es gibt einige wichtige Überlegungen:

• Partner-NVAs für firewalling der nächsten Generation bieten möglicherweise mehr Kontrolle und Flexibilität für NAT-Konfigurationen, die von der Azure-Firewall nicht unterstützt werden. Beispiele hierfür sind DNAT von lokal oder DNAT aus dem Internet ohne SNAT.
• Azure-verwaltete NVAs (z. B. Anwendungsgateway und Azure Firewall) verringern die Komplexität im Vergleich zu NVAs, bei denen Benutzer Skalierbarkeit und Resilienz über viele Appliances hinweg bewältigen müssen.
• Wenn Sie NVAs in Azure verwenden, verwenden Sie aktiv aktive und automatische Skalierung Setups, sodass diese Appliances keine Engpässe für Anwendungen darstellen, die im virtuellen Netzwerk ausgeführt werden.

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautor:

• Jose Moreno | Principal Customer Engineer

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

• Was ist Das Azure-Anwendungsgateway?
• Was ist Azure Firewall?
• Was ist Azure Front Door?
• Azure Kubernetes Service-
• Was ist Azure Virtual Network?
• Was ist die Azure-Webanwendungsfirewall?

Verwandte Ressourcen

Erkunden Sie verwandte Architekturen:

• Implementieren eines sicheren Hybridnetzwerks
• sicher verwaltete Webanwendungen
• Sichern Ihres Microsoft Teams-Kanal-Bots und Ihrer Web-App hinter einer Firewall
• Sicherheitsüberlegungen für besonders sensible IaaS-Apps in Azure
• Mehrinstanzen-SaaS auf Azure
• Unternehmensbereitstellung mit App Services Environment
• Unternehmensbereitstellung mit hoher Verfügbarkeit mithilfe von App Services Environment
• Basisarchitektur für einen Azure Kubernetes Service (AKS)-Cluster