Freigeben über

Azure Firewall and Application Gateway für virtuelle Netzwerke

Azure Application Gateway
Azure Firewall
Azure Front Door
Azure Virtual Network
Azure Web Application Firewall

Um Azure-Anwendungsworkloads zu sichern, verwenden Sie Schutzmaßnahmen wie Authentifizierung und Verschlüsselung in den Anwendungen selbst. Sie können den virtuellen Netzwerken, die die Anwendungen hosten, Sicherheitsebenen hinzufügen. Diese Sicherheitsebenen schützen die eingehenden Flüsse der Anwendung vor unbeabsichtigter Verwendung. Sie beschränken auch ausgehende Flüsse im Internet auf nur die Endpunkte, die Ihre Anwendung benötigt. In diesem Artikel werden Azure Virtual Network Sicherheitsdienste wie Azure DDoS Protection, Azure Firewall und Azure Application Gateway beschrieben. Außerdem wird beschrieben, wann Sie die einzelnen Dienst- und Netzwerkentwurfsoptionen verwenden, die sie kombinieren.

  • DDoS Protectionin Kombination mit bewährten Methoden für den Anwendungsentwurf bietet erweiterte DDoS-Entschärfungsfeatures, die die Abwehr von DDoS-Angriffen verbessern. Sie sollten den DDoS-Schutz für jedes virtuelle Umkreisnetzwerk aktivieren.

  • Azure Firewall ist eine verwaltete Firewall der nächsten Generation, die Netzwerkadressübersetzung (NAT) Funktionen bereitstellt. Azure Firewall filtert Pakete basierend auf IP-Adressen und TCP-Ports (Transmission Control Protocol) oder UDP-Ports (User Datagram Protocol). Der Datenverkehr kann mithilfe anwendungsbasierter Attribute wie HTTP(S) und SQL gefiltert werden. Azure Firewall wendet auch Die Microsoft-Bedrohungserkennung an, um böswillige IP-Adressen zu identifizieren. Weitere Informationen finden Sie in Azure Firewall-Dokumentation.

  • Azure Firewall Premium- umfasst alle Funktionen von Azure Firewall Standard, zusätzlich zu Features wie TLS-Inspektion (Transport Layer Security) und Intrusion Detection and Prevention System (IDPS).

  • Anwendungsgateway- ist ein verwalteter Webdatenverkehr-Lastenausgleichsmodul und HTTP(S) vollständiger Reverseproxy, der ssl-Verschlüsselung und Entschlüsselung (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 Azure-Webanwendungsfirewall, um Den Webdatenverkehr zu prüfen und Angriffe auf der HTTP-Ebene zu erkennen. Weitere Informationen finden Sie in Anwendungsgateway-Dokumentation.

  • Webanwendungsfirewall ist eine optionale Ergänzung zum Anwendungsgateway. Er prüft HTTP-Anforderungen und verhindert Angriffe auf Webebene, z. B. SQL-Einfügung und websiteübergreifendes Skripting. Weitere Informationen finden Sie in Dokumentation zur Webanwendungsfirewall.

Diese Azure-Dienste ergänzen sich gegenseitig. Je nach Ihren Anforderungen eignet sich die Verwendung eines Diensts möglicherweise besser für Ihre Workloads. Sie können diese Dienste jedoch zusammen verwenden, um einen optimalen Schutz sowohl auf netzwerk- als auch auf Anwendungsebenen zu ermöglichen. Verwenden Sie die folgende Entscheidungsstruktur und die Beispiele in diesem Artikel, um die beste Sicherheitsoption für das virtuelle Netzwerk Ihrer Anwendung auszuwählen.

Die Azure-Firewall und das Anwendungsgateway verwenden unterschiedliche Technologien, um verschiedene Arten von Datenflüssen zu schützen.

Anwendungsfluss Kann nach Azure Firewall gefiltert werden Kann von der Webanwendungsfirewall auf dem Anwendungsgateway gefiltert werden
HTTP(S)-Datenverkehr von lokalem oder Internet zu Azure (eingehend) Ja Ja
HTTP(S)-Datenverkehr von Azure zu lokalem oder Internet (ausgehend) Ja Nein
Nicht-HTTP(S)-Datenverkehr (eingehend oder ausgehend) Ja Nein

Der Entwurf kann je nach den benötigten Netzwerkflüssen für jede Anwendung variieren. Das folgende Diagramm enthält eine vereinfachte Entscheidungsstruktur, mit der Sie den empfohlenen Ansatz für Ihre Anwendung auswählen können. Diese Auswahl hängt davon ab, ob die Anwendung über HTTP(S) oder ein anderes Protokoll veröffentlicht wird.

Diagramm, das die Sicherheitsentscheidungsstruktur des virtuellen Netzwerks zeigt.

In diesem Artikel werden die allgemein empfohlenen Designs im Flussdiagramm und Designs beschrieben, die für weniger häufige Szenarien geeignet sind:

  • Azure Firewall nur: Verwenden Sie dieses Design, wenn keine Webanwendungen im virtuellen Netzwerk vorhanden sind. Sie steuert sowohl eingehenden Datenverkehr an die Anwendungen als auch ausgehenden Datenverkehr.

  • Anwendungsgateway nur: Verwenden Sie dieses Design, wenn sich nur Webanwendungen im virtuellen Netzwerk befinden und Netzwerksicherheitsgruppen (NSGs) ausreichende Ausgabefilter bereitstellen. Azure Firewall bietet Funktionen, die verschiedene Angriffsszenarien verhindern können, z. B. Datenexfiltration und IDPS. Daher wird das Design "Nur Anwendungsgateway" in der Regel nicht empfohlen, daher ist es nicht im vorherigen Flussdiagramm enthalten.

  • Azure Firewall and Application Gateway parallel: Verwenden Sie dieses Design, wenn Sie möchten, dass DAS Anwendungsgateway HTTP(S)-Anwendungen vor Webangriffen und azure Firewall schützt, um alle anderen Workloads zu schützen und ausgehenden Datenverkehr zu filtern. Die Azure-Firewall und das Anwendungsgateway parallel sind ein gängiges Design.

  • Anwendungsgateway vor azure Firewall: Verwenden Sie dieses Design, wenn Azure Firewall den gesamten Datenverkehr, die Webanwendungsfirewall zum Schutz des Webdatenverkehrs und die Anwendung zum Identifizieren der Quell-IP-Adresse des Clients überprüfen soll. Mit azure Firewall Premium und TLS-Inspektion unterstützt dieses Design auch das End-to-End-SSL-Szenario.

  • Azure Firewall vor dem Anwendungsgateway: Verwenden Sie dieses Design, wenn Azure Firewall Den Datenverkehr prüfen und filtern soll, bevor es das Anwendungsgateway erreicht. Da der HTTPS-Datenverkehr von Azure Firewall nicht entschlüsselt wird, ist die zusätzliche Funktionalität des Anwendungsgateways eingeschränkt. Dieses Szenario ist im vorherigen Flussdiagramm nicht dokumentiert.

Variationen dieser grundlegenden Designs werden weiter unten in diesem Artikel beschrieben und umfassen:

Sie können weitere Reverseproxydienste wie ein Azure API Management Gateway oder Azure Front Doorhinzufügen. Oder Sie können die Azure-Ressourcen durch nicht von Microsoft Netzwerk virtual appliances (NVAs)ersetzen.

Anmerkung

In den folgenden Szenarien wird ein virtueller Azure-Computer (VM) als Beispiel für eine Webanwendungsworkload verwendet. Diese Szenarien gelten auch für andere Workloadtypen, z. B. Container oder Azure Web Apps. Berücksichtigen Sie bei Setups, die private Endpunkte enthalten, die Empfehlungen in Azure Firewall-Szenarien, um den Datenverkehr zu prüfen, der an einen privaten Endpunktbestimmt ist.

Nur-Azure-Firewall-Design

Wenn keine webbasierten Workloads im virtuellen Netzwerk vorhanden sind, die von der Webanwendungsfirewall profitieren können, können Sie das Design "Nur Azure Firewall" verwenden. Das Design in diesem Beispiel ist einfach, aber Sie können den Paketfluss überprüfen, um komplexere Designs besser zu verstehen. In diesem Design werden alle eingehenden Datenverkehr über benutzerdefinierte Routen (UDRs) für Verbindungen von lokalen oder anderen virtuellen Azure-Netzwerken an die Azure-Firewall gesendet. Sie wird an die öffentliche IP-Adresse der Azure Firewall für Verbindungen aus dem öffentlichen Internet adressiert, wie im folgenden Diagramm dargestellt. UDRs leiten ausgehenden Datenverkehr von virtuellen Azure-Netzwerken zu Azure Firewall, wie im folgenden Dialogfeld dargestellt.

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

Fluss Durchläuft die Anwendungsgateway-/Webanwendungsfirewall Durchläuft die Azure Firewall
HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Nicht verfügbar Ja
HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nicht verfügbar Ja
Nicht-HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Nicht verfügbar Ja
Nicht-HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nicht verfügbar Ja

Azure Firewall prüft keinen eingehenden HTTP(S)-Datenverkehr. Sie kann jedoch Layer 3- und Layer 4-Regeln und vollqualifizierte Domänennamen (FQDN)-basierte Anwendungsregeln anwenden. Azure Firewall prüft ausgehenden HTTP(S)-Datenverkehr, abhängig von der Azure-Firewallebene und ob Sie die TLS-Inspektion konfigurieren:

  • Azure Firewall Standard prüft nur Layer 3- und Layer 4-Attribute von Paketen in Netzwerkregeln und dem Host-HTTP-Header in Anwendungsregeln.

  • Azure Firewall Premium fügt Funktionen hinzu, z. B. das Überprüfen anderer HTTP-Header (z. B. des Benutzer-Agents) und die Aktivierung der TLS-Inspektion für eine tiefere Paketanalyse. Azure Firewall ist jedoch nicht mit der Webanwendungsfirewall identisch. Wenn Sie über Webworkloads in Ihrem virtuellen Netzwerk verfügen, empfiehlt es sich, die Webanwendungsfirewall zu verwenden.

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 höhere Verfügbarkeit und Skalierbarkeit gibt es mehrere Anwendungsinstanzen hinter einem Lastenausgleich. In diesem Design prüft Azure Firewall eingehende Verbindungen aus dem öffentlichen Internet und ausgehende Verbindungen von der Subnetz-VM der Anwendung mithilfe der UDR.

  • In diesem Beispiel stellt Azure Firewall automatisch mehrere Instanzen mit der Front-End-IP-Adresse 192.168.100.4 und internen Adressen innerhalb des Bereichs 192.168.100.0/26bereit. Normalerweise sind diese Instanzen für den Azure-Administrator nicht sichtbar. Es kann jedoch hilfreich sein, sie zu beheben, um Netzwerkprobleme zu beheben.

  • 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 verwendet standardmäßig keine NAT-Quelle.

Architektur

Das folgende Diagramm zeigt den Datenverkehrsfluss und geht davon aus, dass die INSTANZ-IP-Adresse 192.168.100.7ist.

Diagramm, das das design

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 IP-Adresse der Azure Firewall wird an eine Back-End-Instanz der Firewall verteilt, die in diesem Beispiel 192.168.100.7 ist. Die DNST-Regel (Destination Network Address Translation, Zielnetzwerkadressenübersetzung) die Ziel-IP-Adresse in die Anwendungs-IP-Adresse innerhalb des virtuellen Netzwerks übersetzt. Azure Firewall implementiert auch SNAT(Source Network Address Translation) für das Paket, wenn es DNAT verwendet. 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 antwortet auf die Anwendungsanforderung, die sowohl die Quell- als auch die Ziel-IP-Adressen umkehrt. Für den eingehenden Fluss ist kein UDR erforderlich, da es sich bei der Quell-IP um die Azure Firewall-IP-Adresse handelt. Das UDR im Diagramm für 0.0.0.0/0 dient für ausgehende Verbindungen, um sicherzustellen, dass Pakete mit dem öffentlichen Internet über die Azure Firewall gehen.

    • Quell-IP-Adresse: 192.168.1.4
    • Ziel-IP-Adresse: 192.168.100.7

  4. Azure Firewall macht die SNAT- und DNAT-Vorgänge rückgängig und liefert die Antwort auf den Client.

    • Quell-IP-Adresse: AzFwPIP
    • Ziel-IP-Adresse: ClientPIP

Design "Nur Anwendungsgateway"

Dieser Entwurf beschreibt das Szenario, in dem nur Webanwendungen im virtuellen Netzwerk vorhanden sind, und das Prüfen ausgehender Datenverkehr mit NSGs reicht aus, um ausgehende Flüsse im Internet zu schützen.

Anmerkung

Wir empfehlen diesen Entwurf nicht, da die Verwendung der Azure-Firewall zum Steuern ausgehender Flüsse anstelle der ausschließlichen Verwendung von NSGs dazu beiträgt, Angriffsszenarien wie Datenexfiltration zu verhindern. Mit der Azure Firewall können Sie sicherstellen, dass Ihre Workloads nur Daten an eine genehmigte Liste von URLs senden. Außerdem werden NSGs nur auf Ebene 3 und Ebene 4 ausgeführt und unterstützen keine FQDNs.

Der Hauptunterschied zum vorherigen Entwurf der Azure Firewall besteht darin, dass das Anwendungsgateway nicht als Routinggerät mit NAT dient. Stattdessen fungiert sie als vollständiger Reverseanwendungsproxy. Dieser Ansatz bedeutet, dass das Anwendungsgateway die Websitzung vom Client beendet und eine separate Sitzung mit einem seiner Back-End-Server herstellt. Eingehende HTTP(S)-Verbindungen aus dem Internet werden an die öffentliche IP-Adresse des Anwendungsgateways gesendet, und Verbindungen von Azure oder lokal verwenden die private IP-Adresse des Gateways. Der Rückgabedatenverkehr von den Azure-VMs folgt dem standardmäßigen virtuellen Netzwerkrouting zurück an das Anwendungsgateway. Weitere Informationen finden Sie weiter unten in diesem Artikel im Paket.For more information, see the packet walk later in this article. Ausgehende Internetflüsse von Azure-VMs gehen direkt ins Internet.

In der folgenden Tabelle werden Datenverkehrsflüsse zusammengefasst.

Fluss Durchläuft die Anwendungsgateway-/Webanwendungsfirewall Durchläuft die Azure Firewall
HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Ja Nicht verfügbar
HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Nicht verfügbar
Nicht-HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Nein Nicht verfügbar
Nicht-HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Nicht verfügbar

Architektur

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

Diagramm, das ein Nur-Anwendungsgateway-Design zeigt.

Arbeitsablauf

  1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse des Anwendungsgateways.

    • Quell-IP-Adresse: ClientPIP
    • Ziel-IP-Adresse: AppGwPIP

  2. Die Anforderung an die öffentliche IP-Adresse des Anwendungsgateways wird an eine Back-End-Instanz des Gateways verteilt, die in diesem Beispiel 192.168.200.7 ist. 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 IP-Adresse des ursprünglichen Clients ein.

    • Quell-IP-Adresse, die die private IP-Adresse der Anwendungsgatewayinstanz ist: 192.168.200.7
    • Ziel-IP-Adresse: 192.168.1.4
    • X-Forwarded-For Kopfzeile: ClientPIP

  3. Der virtuelle Computer antwortet auf die Anwendungsanforderung und kehrt sowohl die Quell- als auch die Ziel-IP-Adressen zurück. Der virtuelle Computer kann das Anwendungsgateway erreichen, daher ist kein UDR erforderlich.

    • Quell-IP-Adresse: 192.168.1.4
    • Ziel-IP-Adresse: 192.168.200.7

  4. Die Anwendungsgateway-Instanz antwortt auf den Client.

    • Quell-IP-Adresse: AppGwPIP
    • Ziel-IP-Adresse: ClientPIP

Das 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.

  • In diesem Beispiel ist die IP-Adresse 192.168.200.7 eine der Instanzen, die vom Anwendungsgatewaydienst automatisch bereitgestellt werden. Sie verfügt über die interne, private Front-End-IP-Adresse 192.168.200.4. Diese einzelnen Instanzen sind normalerweise für den Azure-Administrator unsichtbar. Das Notieren des Unterschieds kann jedoch hilfreich sein, z. B. wenn Sie Netzwerkprobleme beheben.

  • 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 IP-Adresse auf die private IP-Adresse des Anwendungsgateways zugreift.

Anmerkung

Weitere Informationen zum X-Forwarded-For Header und zum Beibehalten des Hostnamens für eine Anforderung finden Sie unter Beibehalten des ursprünglichen HTTP-Hosts.

Azure Firewall und Anwendungsgateway im parallelen Entwurf

Aufgrund ihrer Einfachheit und Flexibilität ist es häufig am besten, Anwendungsgateway und Azure Firewall parallel auszuführen.

Implementieren Sie diesen Entwurf, wenn web- und nicht-web-Workloads im virtuellen Netzwerk vorhanden sind. Die Webanwendungsfirewall im Anwendungsgateway schützt eingehenden Datenverkehr zu den Webworkloads. Azure Firewall prüft eingehenden Datenverkehr für die anderen Anwendungen. 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 gesendet werden. HTTP(S)-Verbindungen von Azure oder lokal sollten an ihre private IP-Adresse gesendet werden. Standardmäßiges virtuelles Netzwerkrouting sendet die Pakete vom Anwendungsgateway an die Ziel-VMs und von den Ziel-VMs zurück an das Anwendungsgateway. Weitere Informationen finden Sie weiter unten in diesem Artikel im Paket.For more information, see the packet walk later in this article.

Bei eingehenden Nicht-HTTP(S)-Verbindungen sollte der Datenverkehr auf die öffentliche IP-Adresse der Azure Firewall abzielen, wenn sie aus dem öffentlichen Internet stammt. Datenverkehr sollte über azure Firewall von UDRs gesendet werden, wenn er von anderen virtuellen Azure-Netzwerken oder lokalen Netzwerken stammt. Alle ausgehenden Flüsse von Azure-VMs werden von UDRs an azure Firewall weitergeleitet.

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

Fluss Durchläuft die Anwendungsgateway-/Webanwendungsfirewall Durchläuft die Azure Firewall
HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Ja Nein
HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Ja
Nicht-HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Nein Ja
Nicht-HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Ja

Dieses Design bietet wesentlich genauere Ausgangsfilterung als ausschließlich die Verwendung von NSGs. Wenn Anwendungen beispielsweise eine Verbindung mit einem bestimmten Azure Storage-Konto benötigen, können Sie FQDN-basierte Filter verwenden. Bei FQDN-basierten Filtern senden Anwendungen keine Daten an nicht autorisierte Speicherkonten. Wenn Sie nur NSGs verwenden, können Sie dieses Szenario nicht verhindern. Dieser Entwurf wird häufig verwendet, wenn ausgehender Datenverkehr FQDN-basierte Filterung erfordert. Ein Szenario ist, wenn Sie den Ausgehenden Datenverkehr von einem AKS-Clustereinschränken.

Architekturen

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

Diagramm, das den Eingangsfluss mit dem Anwendungsgateway und der Azure-Firewall parallel anzeigt.

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.

Diagramm, das den Ausgangsfluss mit dem Anwendungsgateway und der Azure-Firewall parallel anzeigt.

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

Anwendungsgateway vor dem Azure Firewall-Design

Dieses Design wird in Zero-Trust-Netzwerk für Webanwendungen mit Azure Firewall und Application Gatewayausführlicher erläutert. Dieser Artikel konzentriert sich auf den Vergleich mit den anderen Designoptionen. In dieser Topologie durchläuft eingehender Webdatenverkehr sowohl die Azure-Firewall als auch die Webanwendungsfirewall. Die Webanwendungsfirewall bietet Schutz auf Webanwendungsebene. Azure Firewall dient als zentraler Protokollierungs- und Kontrollpunkt und prüft den Datenverkehr zwischen dem Anwendungsgateway und den Back-End-Servern. In diesem Design sitzen Anwendungsgateway und Azure Firewall nicht parallel, sondern sitzen vor dem anderen.

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

Dieses Design eignet sich für Anwendungen, die eingehende Clientquell-IP-Adressen identifizieren müssen. Beispielsweise kann es verwendet werden, um geolocationspezifische Inhalte oder für die Protokollierung zu bedienen. Das Anwendungsgateway vor dem Azure Firewall-Design erfasst die QUELL-IP-Adresse des eingehenden Pakets im X-Forwarded-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 gesendet werden. HTTP(S)-Verbindungen von Azure oder lokal sollten an ihre private IP-Adresse gesendet werden. Vom Anwendungsgateway stellen UDRs sicher, dass die Pakete über die Azure-Firewall weitergeleitet werden. Weitere Informationen finden Sie weiter unten in diesem Artikel im Paket.For more information, see the packet walk later in this article.

Bei eingehenden Nicht-HTTP(S)-Verbindungen sollte der Datenverkehr auf die öffentliche IP-Adresse der Azure Firewall abzielen, wenn sie aus dem öffentlichen Internet stammt. Datenverkehr sollte über azure Firewall von UDRs gesendet werden, wenn er von anderen virtuellen Azure-Netzwerken oder lokalen Netzwerken stammt. Alle ausgehenden Flüsse von Azure-VMs werden von UDRs an azure Firewall weitergeleitet.

Ein wichtiger Aspekt dieses Designs ist, dass Azure Firewall Premium Datenverkehr mit einer Quell-IP-Adresse aus dem Subnetz des Anwendungsgateways sieht. 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/12oder 100.64.0.0/10), behandelt Azure Firewall Premium den Datenverkehr vom Anwendungsgateway als intern und wendet keine IDPS-Regeln für eingehenden Datenverkehr an. Daher wird empfohlen, die privaten IDPS-Präfixe in der Azure Firewall-Richtlinie zu ändern. Diese Änderung stellt sicher, dass das Anwendungsgateway-Subnetz nicht als interne Quelle betrachtet wird, wodurch eingehende und ausgehende IDPS-Signaturen auf den Datenverkehr angewendet werden können. Weitere Informationen zu Azure Firewall IDPS-Regelbeschreibungen und privaten IP-Präfixen für IDPS finden Sie in Azure Firewall IDPS-Regeln.

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

Fluss Durchläuft die Anwendungsgateway-/Webanwendungsfirewall Durchläuft die Azure Firewall
HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Ja Ja
HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Ja
Nicht-HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Nein Ja
Nicht-HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Ja

Bei Webdatenverkehr von lokal oder aus dem Internet zu Azure prüft die Azure Firewall Flüsse, die die Webanwendungsfirewall zulässt. Je nachdem, ob das Anwendungsgateway Back-End-Datenverkehr verschlüsselt, der Datenverkehr vom Anwendungsgateway zu den Anwendungsservern ist, können verschiedene Szenarien auftreten:

  • Das Anwendungsgateway verschlüsselt datenverkehr, indem er nullbasierte Prinzipien wie End-to-End-TLS-Verschlüsselungbefolgt, und Azure Firewall empfängt verschlüsselten Datenverkehr. Azure Firewall Standard kann weiterhin Überprüfungsregeln anwenden, z. B. Layer 3- und 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.

  • Wenn das Anwendungsgateway unverschlüsselten Datenverkehr an die Anwendungsserver sendet, sieht die Azure-Firewall eingehenden Datenverkehr in klarem Text. DIE TLS-Inspektion ist in der Azure-Firewall nicht erforderlich.

  • Wenn IDPS in der Azure-Firewall aktiviert ist, wird überprüft, ob der HTTP-Hostheader der Ziel-IP-Adresse entspricht. Um diese Überprüfung durchzuführen, benötigt sie die Namensauflösung für den FQDN, der im Hostheader angegeben ist. Diese Namensauflösung kann mithilfe privater Azure DNS-Zonen und der standardmäßigen Azure Firewall DNS-Einstellungenausgeführt werden. Sie kann auch mit benutzerdefinierten DNS-Servern erreicht werden, die in den Azure Firewall-Einstellungen konfiguriert werden müssen. Wenn Sie keinen Administratorzugriff auf das virtuelle Netzwerk haben, in dem Azure Firewall bereitgestellt wird, ist die letztere Methode Ihre einzige Option. Ein Beispiel hierfür sind Azure Firewall-Instanzen, die in mit Azure Virtual WAN gesicherten Hubs bereitgestellt werden.

Architektur

Für den Rest der Flüsse, die eingehenden Nicht-HTTP(S)-Datenverkehr und alle ausgehenden Datenverkehr umfassen, stellt Azure Firewall IDPS-Inspektion und TLS-Inspektion bereit, sofern geeignet. Außerdem werden FQDN-basierte Filterung in Netzwerkregeln basierend auf DNS bereitgestellt.

Diagramm, das das Anwendungsgateway vor dem Azure Firewall-Design zeigt.

Arbeitsablauf

Der Netzwerkdatenverkehr aus dem öffentlichen Internet folgt diesem Fluss:

  1. Der Client startet die Verbindung mit der öffentlichen IP-Adresse des Anwendungsgateways.

    • Quell-IP-Adresse: ClientPIP
    • Ziel-IP-Adresse: AppGwPIP

  2. Die Anforderung an die öffentliche IP-Adresse des Anwendungsgateways wird an eine Back-End-Instanz des Gateways verteilt, die in diesem Beispiel 192.168.200.7 ist. 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 und behält die Ziel-IP-Adresse an die Webanwendung bei.

    • Quell-IP-Adresse, die die private IP-Adresse der Anwendungsgatewayinstanz ist: 192.168.200.7
    • Ziel-IP-Adresse: 192.168.1.4
    • X-Forwarded-For Kopfzeile: ClientPIP

  3. Azure Firewall wendet SNAT nicht auf den Datenverkehr an, da der Datenverkehr an eine private IP-Adresse wechselt. Er leitet den Datenverkehr an den virtuellen Anwendungscomputer weiter, wenn regeln dies zulassen. Weitere Informationen finden Sie unter Azure Firewall SNAT – private Adressbereiche. Wenn der Datenverkehr jedoch auf eine Anwendungsregel in der Firewall trifft, sieht die Workload die Quell-IP-Adresse der spezifischen Firewallinstanz, die das Paket verarbeitet hat, da azure Firewall die Verbindung proxiest.

    • Quell-IP-Adresse, wenn der Datenverkehr von einer Azure Firewall-Netzwerkregel zulässig ist und die private IP-Adresse einer der Anwendungsgatewayinstanzen ist: 192.168.200.7
    • Quell-IP-Adresse, wenn der Datenverkehr von einer Azure Firewall-Anwendungsregel zulässig ist und die private IP-Adresse einer der Azure Firewall-Instanzen ist: 192.168.100.7
    • Ziel-IP-Adresse: 192.168.1.4
    • X-Forwarded-For Kopfzeile: ClientPIP

  4. Der virtuelle Computer antwortet auf die Anforderung, wodurch sowohl die Quell- als auch die Ziel-IP-Adressen umgekehrt werden. Der UDR, um 192.168.200.0/24 erfasst das an das Anwendungsgateway gesendete Paket, leitet es an azure Firewall um und behält die Ziel-IP-Adresse in Richtung des Anwendungsgateways bei.

    • Quell-IP-Adresse: 192.168.1.4
    • Ziel-IP-Adresse: 192.168.200.7

  5. Auch hier wendet Azure Firewall SNAT nicht auf den Datenverkehr an, da er an eine private IP-Adresse wechselt und den Datenverkehr an das Anwendungsgateway weiterleitet.

    • Quell-IP-Adresse: 192.168.1.4
    • Ziel-IP-Adresse: 192.168.200.7

  6. Die Anwendungsgateway-Instanz antwortt 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, die vom UDR definiert 0.0.0.0/0 definiert werden.

Als Variante dieses Designs können Sie private DNAT in azure Firewall so konfigurieren, dass die Anwendungsauslastung die IP-Adressen der Azure Firewall-Instanzen als Quelle sieht und keine UDRs erforderlich sind. Die Quell-IP-Adresse der Anwendungsclients wird bereits im X-Forwarded-For HTTP-Header vom Anwendungsgateway beibehalten. Wenn also Azure Firewall DNAT auf den Datenverkehr anwendet, gehen keine Informationen verloren. Weitere Informationen finden Sie unter Filtern eingehender Internet- oder Intranetdatenverkehr mit Azure Firewall Policy DNAT mithilfe des Azure-Portals.

Azure Firewall vor dem Anwendungsgateway-Design

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. Es gibt drei Modi, in denen Sie theoretisch Azure Firewall konfigurieren können:

  • Azure Firewall mit DNAT-Regeln: Azure Firewall vertauscht nur IP-Adressen auf der IP-Adressebene, verarbeitet jedoch nicht die Nutzlast. Daher ändert sie keines der HTTP-Header.

  • Azure Firewall mit deaktivierten Anwendungsregeln und TLS-Inspektion: Azure Firewall kann den SNI-Header in TLS betrachten, entschlüsselt sie jedoch nicht. Eine neue TCP-Verbindung wird von der Firewall zum nächsten Hop erstellt. In diesem Beispiel ist es das Anwendungsgateway.

  • Azure Firewall mit aktivierten Anwendungsregeln und TLS-Inspektion: Azure Firewall sucht in den Paketinhalt und entschlüsselt sie. Sie dient als HTTP-Proxy und kann die HTTP-Header X-Forwarded-For festlegen, um die IP-Adresse beizubehalten. Es stellt dem Client jedoch ein selbst generiertes Zertifikat dar. Bei internetbasierten Anwendungen ist die Verwendung eines selbst generierten Zertifikats keine Option, da eine Sicherheitswarnung von ihrem Browser an die Anwendungsclients gesendet wird.

In den ersten beiden Optionen, bei denen es sich um die einzigen gültigen Optionen für internetbasierte Anwendungen handelt, wendet Azure Firewall SNAT auf den eingehenden Datenverkehr an, ohne den X-Forwarded-For-Header festzulegen. Daher kann die Anwendung die ursprüngliche IP-Adresse der HTTP-Anforderungen nicht sehen. Bei administrativen Aufgaben wie der Problembehandlung können Sie die tatsächliche Client-IP-Adresse für eine bestimmte Verbindung abrufen, indem Sie sie mit den SNAT-Protokollen der Azure Firewall korrelieren.

Die Vorteile dieses Szenarios sind eingeschränkt, da azure Firewall nur verschlüsselten Datenverkehr sieht, der an das Anwendungsgateway geht, es sei denn, Sie verwenden TLS-Inspektion und präsentieren selbst generierte Zertifikate für die Clients. Dieses Szenario ist in der Regel nur für interne Anwendungen möglich. Es kann jedoch Szenarien geben, in denen dieses Design bevorzugt wird. Ein Szenario ist, wenn eine andere Webanwendungsfirewall weiter oben im Netzwerk vorhanden ist (z. B. mit Azure Front Door), die die ursprüngliche Quell-IP im X-Forwarded-For HTTP-Header erfassen kann. Möglicherweise bevorzugen Sie diesen Entwurf auch, wenn viele öffentliche IP-Adressen erforderlich sind, da das Anwendungsgateway eine einzelne IP-Adresse unterstützt.

HTTP(S) eingehende Flüsse aus dem öffentlichen Internet sollten auf die öffentliche IP-Adresse der Azure Firewall abzielen. Azure Firewall erbt und SNAT die Pakete an die private IP-Adresse des Anwendungsgateways. Von anderen virtuellen Azure-Netzwerken oder lokalen Netzwerken sollte DER HTTP(S)-Datenverkehr an die private IP-Adresse des Anwendungsgateways gesendet und über azure Firewall mit UDRs weitergeleitet werden. Standardmäßiges virtuelles Netzwerkrouting stellt sicher, dass der Rückgabedatenverkehr von den Azure-VMs zum Anwendungsgateway und vom Anwendungsgateway zu Azure Firewall zurückgeht, wenn DNAT-Regeln verwendet wurden. Verwenden Sie UDRs im Subnetz des Anwendungsgateways für den Datenverkehr von der lokalen Bereitstellung oder azure. Weitere Informationen finden Sie weiter unten in diesem Artikel im Paket.For more information, see the packet walk later in this article. 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.

Fluss Durchläuft die Anwendungsgateway-/Webanwendungsfirewall Durchläuft die Azure Firewall
HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Ja Ja
HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Ja
Nicht-HTTP(S)-Datenverkehr aus dem Internet oder lokal zu Azure Nein Ja
Nicht-HTTP(S)-Datenverkehr von Azure zum Internet oder lokal Nein Ja

Bei eingehendem HTTP(S)-Datenverkehr entschlüsselt Azure Firewall normalerweise keinen Datenverkehr. Stattdessen werden IDPS-Richtlinien angewendet, die keine TLS-Überprüfung erfordern, z. B. IP-adressbasierte Filterung oder verwendung von HTTP-Headern.

Architektur

Die Anwendung kann die ursprüngliche Quell-IP-Adresse des Webdatenverkehrs nicht sehen. Azure Firewall wendet SNAT auf die Pakete an, 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.

Diagramm, das das Anwendungsgateway nach azure Firewall anzeigt.

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 IP-Adresse der Azure Firewall wird an eine Back-End-Instanz der Firewall verteilt, die in diesem Beispiel 192.168.100.7 ist. Azure Firewall wendet DNAT auf den Webport an, in der Regel TCP 443, auf die private IP-Adresse der Application Gateway-Instanz. Azure Firewall wendet auch SNAT an, wenn Sie DNAT ausführen. Weitere Informationen finden Sie unter bekannten Problemender Azure-Firewall.

    • Quell-IP-Adresse, die die private IP-Adresse der Azure Firewall-Instanz ist: 192.168.100.7
    • Ziel-IP-Adresse: 192.168.200.4

  3. Das Anwendungsgateway richtet eine neue Sitzung zwischen der Instanz ein, die die Verbindung verarbeitet, und einem der Back-End-Server. Die ursprüngliche IP-Adresse des Clients befindet sich nicht im Paket.

    • Quell-IP-Adresse, die die private IP-Adresse der Anwendungsgatewayinstanz ist: 192.168.200.7
    • Ziel-IP-Adresse: 192.168.1.4
    • X-Forwarded-For Kopfzeile: 192.168.100.7

  4. Der virtuelle Computer antwortet auf das Anwendungsgateway, das sowohl die Quell- als auch die Ziel-IP-Adressen umkehrt:

    • 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. Azure Firewall sieht die interne IP-Adresse des Anwendungsgateways, .4, als Quell-IP-Adresse, auch wenn die Verbindung von einer bestimmten Anwendungsgateway-Instanz wie .7stammt.

    • Quell-IP-Adresse: 192.168.200.4
    • Ziel-IP-Adresse: 192.168.100.7

  6. Azure Firewall macht SNAT und DNAT rückgängig und beantwortet den Client.

    • Quell-IP-Adresse: AzFwPIP
    • Ziel-IP-Adresse: ClientPIP

Das Anwendungsgateway benötigt eine öffentliche IP-Adresse, damit Microsoft sie verwalten kann, auch wenn keine Listener für Anwendungen konfiguriert sind.

Anmerkung

Eine Standardroute zu 0.0.0.0/0 im Anwendungsgateway-Subnetz, das auf Azure Firewall verweist, wird nicht unterstützt, da dadurch der Datenverkehr auf der Kontrollebene unterbrochen wird, den das Anwendungsgateway für die ordnungsgemäße Funktion benötigt.

Lokale Clients

Im vorherigen Design werden alle eingehenden Anwendungsclients aus dem öffentlichen Internet angezeigt. 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.

  • Die Webanwendungsfirewall verwendet die private IP-Adresse des Anwendungsgateways.

  • Azure Firewall unterstützt DNAT für private IP-Adressen nicht. Daher müssen Sie UDRs verwenden, um eingehenden Datenverkehr von vpn- oder ExpressRoute-Gateways an Azure Firewall zu senden.

  • Stellen Sie sicher, dass Sie erzwungenen Tunneling- für Anwendungsgateway- und für 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, die auf das lokale Netzwerk verweist, da sie den Steuerungsverkehr umbricht. Für das Anwendungsgateway muss die Standardroute auf das öffentliche Internet verweisen.

Architektur

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

Diagramm, das ein Hybriddesign mit einem VPN oder einem ExpressRoute-Gateway zeigt.

Auch wenn sich alle Clients lokal oder in Azure befinden, müssen anwendungsgateway und Azure Firewall beide öffentliche IP-Adressen haben. Diese öffentlichen IP-Adressen ermöglichen Es Microsoft, die Dienste zu verwalten.

Hub-and-Spoke-Topologie

Die Designs in diesem Artikel gelten für eine Hub-and-Spoke- Topologie. Gemeinsam genutzte Ressourcen in einem zentralen virtuellen Hubnetzwerk stellen eine Verbindung mit Anwendungen in separaten virtuellen Netzwerken über virtuelle Netzwerk-Peerings her.

Architektur

Diagramm, das ein Hybriddesign mit einem VPN- und Expressroute-Gateway und einer Hub-and-Spoke-Topologie zeigt.

  • Azure Firewall wird im virtuellen Netzwerk des zentralen Hubs bereitgestellt. Das vorherige Diagramm zeigt, wie Anwendungsgateway im Hub bereitgestellt wird. Anwendungsteams verwalten häufig Komponenten wie Anwendungsgateways oder API-Verwaltungsgateways. In diesem Szenario werden diese Komponenten in den virtuellen Speichennetzwerken bereitgestellt.

  • Achten Sie besonders auf UDRs in den Speichennetzwerken. Wenn ein Anwendungsserver in einer Speichendatenverkehr von einer bestimmten Azure Firewall-Instanz empfängt, z. B. die 192.168.100.7 IP-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 vorherigen Diagrammen), können Rückgabepakete auf einer anderen Azure Firewall-Instanz enden. Diese Situation verursacht ein asymmetrisches Routing. Wenn Sie UDRs in den virtuellen Speichennetzwerken haben, stellen Sie sicher, dass Der Datenverkehr an gemeinsame Dienste im Hub über die Azure-Firewall gesendet wird. Diese UDRs enthalten nicht das Präfix des Azure Firewall-Subnetzes.

  • Die vorherige Empfehlung gilt gleichermaßen für das Anwendungsgateway-Subnetz und alle anderen NVAs oder Reverseproxys, die im virtuellen Hubnetzwerk bereitgestellt werden können.

  • 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 virtuellen Netzwerk und nicht über virtuelle Netzwerk-Peerings gültig. Weitere Informationen zu UDRs und nächsten Hoptypen finden Sie unter Routing des virtuellen Netzwerks.

Asymmetrisches Routing

Das folgende Diagramm zeigt, wie ein Speichen SNAT-Datenverkehr zurück an den Azure-Lastenausgleich von Azure Firewall sendet. Diese Einrichtung verursacht ein asymmetrisches Routing.

Diagramm, das asymmetrisches Routing in einer Hub-and-Spoke-Topologie zeigt.

Um dieses Problem zu lösen, definieren Sie UDRs in der Speichen ohne das Azure Firewall-Subnetz und nur mit den Subnetzen, in denen sich die gemeinsamen Dienste befinden. Im vorherigen Diagramm sollte der richtige UDR in der Speichen nur 192.168.1.0/24enthalten. Er sollte nicht den gesamten Bereich 192.168.0.0/16enthalten, der rot markiert ist.

Integration in andere Azure-Produkte

Sie können Azure Firewall und 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. Die INTEGRATION des API-Verwaltungsgateways wirkt sich nicht wesentlich auf die Designs aus. 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.

AKS

Für Workloads, die auf einem AKS-Cluster ausgeführt werden, können Sie das Anwendungsgateway unabhängig vom Cluster bereitstellen. Sie können ihn auch in den AKS-Cluster integrieren, indem Sie den Application Gateway Ingress Controllerverwenden. Wenn Sie bestimmte Objekte auf Kubernetes-Ebenen konfigurieren, z. B. Dienste und Eingänge, passt sich das Anwendungsgateway automatisch an, ohne zusätzliche manuelle Schritte zu benötigen.

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 die IP-Adresse. Weitere Informationen finden Sie unter Einschränken des Netzwerkdatenverkehrs mit azure Firewall in AKS.

Wenn Sie Anwendungsgateway und Azure Firewall kombinieren, um einen AKS-Cluster zu schützen, ist es am besten, die parallele Entwurfsoption zu verwenden. Anwendungsgateway mit Webanwendungsfirewall verarbeitet eingehende Verbindungsanforderungen an Webanwendungen im Cluster. Azure Firewall erlaubt nur explizit zulässige ausgehende Verbindungen. Weitere Informationen zur parallelen Entwurfsoption finden Sie unter Baseline-Architektur für einen AKS-Cluster.

Azure Front Door – der Dienst für Web-Traffic-Management

Azure Front Door verfügt über Funktionen, die sich mit dem Anwendungsgateway in mehreren Bereichen überschneiden. Beide Dienste bieten Webanwendungsfirewalling, SSL-Offloading und URL-basiertes Routing. Ein wichtiger Unterschied besteht jedoch darin, dass das Anwendungsgateway in einem virtuellen Netzwerk arbeitet, Azure Front Door ein globaler, dezentraler Dienst ist.

Sie können das Design des virtuellen Netzwerks manchmal vereinfachen, indem Sie das Anwendungsgateway durch eine dezentrale Azure Front Door ersetzen. Die meisten in diesem Artikel beschriebenen Designs gelten weiterhin, mit Ausnahme der Option, azure Firewall vor Azure Front Door zu platzieren.

Ein Szenario besteht darin, die Azure Firewall vor dem Anwendungsgateway in Ihrem virtuellen Netzwerk zu verwenden. Das Anwendungsgateway fügt den X-Forwarded-For Header mit der IP-Adresse der Firewallinstanz ein, 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 die Azure Firewall erreicht. Sie können Ihren Ursprung auch mit azure Private Link in Azure Front Door Premium 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 NVAs

Microsoft-Produkte sind nicht die einzige Wahl, webanwendungsfirewall oder Firewallfunktionen der nächsten Generation in Azure zu implementieren. Eine vielzahl von Microsoft-Partnern bieten NVAs. Die Konzepte und Designs sind im Wesentlichen identisch mit diesem Artikel, aber es gibt einige wichtige Überlegungen:

  • Partner-NVAs für Firewalls der nächsten Generation bieten möglicherweise mehr Kontrolle und Flexibilität für NAT-Konfigurationen, die von Azure Firewall nicht unterstützt werden. Beispiele hierfür sind DNAT von lokal oder DNAT aus dem Internet ohne SNAT.

  • Azure-verwaltete NVAs wie Anwendungsgateway und Azure Firewall reduzieren 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 aktiven und automatische Skalierung Setups, sodass diese Appliances keinen Engpass für Anwendungen darstellen, die im virtuellen Netzwerk ausgeführt werden.

Beitragende

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

Hauptautor:

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

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

Erkunden Sie verwandte Architekturen: