Azure Firewall und Verkehrskontrolle

Azure Firewall ist ein verwalteter, cloudeigener Netzwerksicherheitsdienst, der zentralisierte Datenverkehrsüberprüfung und Filterung für Ihre Azure virtuellen Netzwerke bereitstellt. Im Gegensatz zu Netzwerksicherheitsgruppen, die auf Schicht 4 arbeiten, prüft Azure Firewall den Datenverkehr auf den Schichten 3 bis 7. Diese Funktion ermöglicht vollqualifizierte Domänennamen (FQDN)-Filterung, Bedrohungserkennung, Angriffserkennung und -prävention (IDPS) und TLS-Inspektion. Sie stellen Azure Firewall in einem dedizierten Subnetz innerhalb Ihres virtuellen Hubnetzwerks bereit und leiten Datenverkehr von Spoke-Workloads zur Überprüfung über die Firewall, bevor er sein Ziel erreicht.

In diesem Artikel wird erläutert, wie Sie die richtige Azure Firewall SKU auswählen, die Firewall in einer Hub-Spoke-Topologie positionieren, Regeltypen konfigurieren und in ergänzende Dienste wie NAT-Gateway und Routingserver integrieren. Azure Firewall ist einer von drei zentralen Azure-Netzwerksicherheitsdiensten, neben Azure DDoS Protection und Azure Web Application Firewall.

Inhalt dieses Artikels

Dieser Artikel behandelt die zentrale Netzwerkverkehrsinspektion mittels der Azure Firewall. Sie erfahren mehr über:

  • Auswahl der SKU-Ebene basierend auf Sicherheitsanforderungen und Workloadempfindlichkeit.
  • Platzierung des Hubs und Muster für benutzerdefinierte Routen (UDR), die den Datenverkehr durch die Firewall erzwingen.
  • Regelverarbeitungslogik für DNAT-, Netzwerk- und Anwendungsregeln.
  • Erzwungenes Tunneling für Umgebungen, die eine On-Premises-Inspektion erfordern.
  • TLS-Inspektions- und IDPS-Funktionen in der Premium-Stufe.
  • Integration mit NAT-Gateway für SNAT-Portskalierung und Routingserver für BGP-basiertes Routing.

Wer diesen Artikel benötigt

Stellen Sie Azure Firewall bereit, wenn Ihre Workloads eine oder mehrere der folgenden Funktionen erfordern:

  • Zentrale Kontrolle des ausgehenden Datenverkehrs: Sie müssen einschränken, auf welche externen FQDNs und URLs Ihre Workloads zugreifen können, zusätzlich zu dem, was IP-basierte NSG-Regeln ermöglichen.
  • Ost-West-Inspektion: Der Datenverkehr zwischen virtuellen Spoke-Netzwerken muss einen zustandsbehafteten Inspektionspunkt durchlaufen, bevor die Firewall dies zulässt.
  • Durch Compliance-Vorgaben vorgeschriebene Protokollierung: Regulierungsrahmen erfordern vollständige Layer-7-Transparenz über zulässige und abgelehnte Verbindungen mit Granularität auf FQDN-Ebene.
  • Bedrohungsschutz: Sie benötigen signaturbasierte Angriffserkennung und -prävention, um böswillige Datenverkehrsmuster zu identifizieren, einschließlich Befehls- und Kontrollrückrufe, Exploit-Versuche und lateraler Bewegungen.
  • TLS-Inspektion: Sie müssen verschlüsselten Datenverkehr (HTTPS) auf Bedrohungen entschlüsseln und prüfen, bevor sie Workloads erreicht oder das Netzwerk verlässt.

Organisationen, die nur layer 4-Paketfilterung ohne FQDN-Sensibilisierung benötigen, sollten NSGs und ASGs als einfachere, kostengünstigere Alternative in Betracht ziehen.

Lift-and-Shift-Fokus: Übersetzen Sie Ihre lokale Firewallregelbasis in eine Azure Firewall-Richtlinie. Beginnen Sie mit Netzwerkregeln für Nicht-HTTP/S-Datenverkehr und Anwendungsregeln für FQDN-basierte Filterung. Beginnen Sie mit allgemeinen Zulassungsrichtlinien während der Migration, und engeren Regeln, nachdem Sie Azure Firewall Protokolle überprüft haben.

Modernisieren Sie den Fokus: Verwenden Sie Azure Firewall als zentralen SNAT- und DNAT-Punkt im Hub. Überprüfen Sie den Datenverkehr zwischen Anwendungsspeichen und zwischen Speichen und dem Internet, verwenden Sie Anwendungsregeln und FQDN-Tags für AKS und Azure PaaS-Ausgang, und planen Sie TLS-Inspektionen, bei denen Anwendungsebenen sensiblen Datenverkehr austauschen.

Cloudübergreifender Fokus: Stellen Sie Azure Firewall in einem gesicherten virtuellen Hub bereit, um den cloudübergreifenden Transitdatenverkehr zu prüfen. Konfigurieren Sie Netzwerkregeln für IPSec-Tunneldatenverkehr von AWS oder Google Cloud, und verwenden Sie IDPS, um auf anomale Datenverkehrsmuster zwischen verbundenen Clouds zu achten.

Azure Firewall – SKU-Tarife

Azure Firewall ist in drei SKU-Ebenen verfügbar. Jede Ebene baut auf den Funktionen der vorherigen Ebene auf.

Fähigkeit Basic Standard Premium
Zustandsorientierte Paketprüfung ✔ ✔ ✔
FQDN-Filterung (ausgehend) ✔ ✔ ✔
Netzwerkregeln (IP, Port, Protokoll) ✔ ✔ ✔
Anwendungsregeln (FQDN, URL) ✔ ✔ ✔
NAT-Regeln (DNAT) ✔ ✔ ✔
Bedrohungsinformationsfilterung Nur Warnung ✔ (Warnung + Verweigern) ✔ (Warnung + Verweigern)
DNS-Proxy ✗ ✔ ✔
Webkategorien ✗ ✔ ✔
IDPS (Angriffserkennung und -prävention) ✗ ✗ ✔
TLS-Überprüfung ✗ ✗ ✔
URL-Filterung (vollständiger Pfad) ✗ ✗ ✔
Expliziter Proxy ✗ ✔ ✔
Verfügbarkeit der Region Begrenzte Regionen Alle Regionen Alle Regionen
Am besten geeignet für: Entwicklung/Test, kleine Workloads Standardproduktion Hochsicherheits- und complianceorientiert

So wählen Sie Ihre SKU aus

Verwenden Sie die folgenden Entscheidungskriterien:

  • Wählen Sie "Einfach " aus, wenn Sie Entwicklungs-/Testumgebungen oder kleine Workloads haben, die FQDN-basierte Ausgangsfilterung ohne Bedrohungserkennungsfilterung (Verweigerungsmodus) oder erweiterte Inspektion benötigen. Die Basis-SKU umfasst Threat Intelligence im reinen Warnmodus, unterstützt jedoch weder den Blockierungsmodus noch DNS-Proxy oder Webkategorien. Die Basis-SKU erfordert ein dediziertes AzureFirewallManagementSubnet (/26 mindestens) zusammen mit dem AzureFirewallSubnet und ist nur in bestimmten Regionen verfügbar.
  • Wählen Sie "Standard für Produktionsworkloads" aus, die auf Bedrohungsintelligenz basierende Filterung, DNS-Proxy für die FQDN-Regelauflösung, Webkategoriefilterung und zentralisierte Richtlinienverwaltung über Azure Firewall Manager benötigen. Standard bietet die vollständige zustandsorientierte Inspektions-Engine mit Threat-Intelligence-Feeds, die Verbindungen zu bekannten schädlichen IP-Adressen und Domänen blockieren.
  • Wählen Sie Premium aus, wenn behördliche oder Sicherheitsanforderungen TLS-Überprüfung von verschlüsseltem Datenverkehr, signaturbasierten IDPS mit kontinuierlich aktualisierten Regeln (über 67.000 Signaturen in mehr als 50 Kategorien, aktualisiert in Echtzeit) oder vollständige URL-Pfadfilterung über FQDN hinaus mandatiert werden. Premium ist für Branchen wie Finanzdienstleistungen, Gesundheitswesen und Behörden erforderlich, bei denen verschlüsselte Datenverkehrsüberprüfungen obligatorisch sind.

Note

Führen Sie ein Upgrade von Standard auf Premium durch, ohne die Firewall erneut bereitzustellen. Für die Herabstufung von Premium auf Standard ist eine erneute Bereitstellung erforderlich.

Hubplatzierung und UDR-Routingmuster

Stellen Sie Azure Firewall in einem dedizierten Subnetz bereit, das genau AzureFirewallSubnet innerhalb Ihres virtuellen Hubnetzwerks benannt ist. Dieses Subnetz erfordert eine Mindestgröße von /26 (59 verwendbare IP-Adressen).

Routingarchitektur

Diagramm einer Hub-Spoke-Topologie, in der der Datenverkehr der Spoke-Subnetze über Azure Firewall im virtuellen Hubnetzwerk geleitet wird, bevor er das Internet oder andere Spoke-Netzwerke erreicht.

In einer Hub-Spoke-Topologie leiten Spoke-Workload-Subnetze den Datenverkehr nicht direkt an das Internet oder an andere Spokes weiter. Stattdessen setzen UDRs in jedem Spoke-Subnetz die Standardroute (0.0.0.0/0) auf die private IP-Adresse der Azure Firewall fest. Dieses Muster stellt sicher, dass der gesamte Datenverkehr, sowohl nord-süd (internetgebunden) als auch Ost-West (Speichen-zu-Speichen), zur Überprüfung durch die Firewall durchläuft.

UDR-Konfigurationsmuster:

Routingtabelle (angewandt auf) Adresspräfix Typ des nächsten Sprungs Adresse des nächsten Hops
Spoke-Subnetz A 0.0.0.0/0 Virtuelles Gerät Azure Firewall mit einer privaten IP-Adresse
Spoke-Subnetz A 10.1.0.0/16 (anderer Spoke) Virtuelles Gerät Azure Firewall mit einer privaten IP-Adresse
Spoke-Subnetz B 0.0.0.0/0 Virtuelles Gerät Azure Firewall mit einer privaten IP-Adresse
Spoke-Subnetz B 10.0.0.0/16 (anderer Spoke) Virtuelles Gerät Azure Firewall mit einer privaten IP-Adresse

Das AzureFirewallSubnet selbst erfordert in den meisten Szenarien keine UDRs, da die Firewall Systemrouten verwendet, um Spoke-Netzwerke über das Peering virtueller Netzwerke zu erreichen. Wenn Sie eine Integration mit Azure Route Server durchführen, lernt das Firewallsubnetz Routen über BGP. Dieser Ansatz entfernt die Notwendigkeit manueller Routenwartung, wenn Ihr Netzwerk wächst.

Tip

Azure Virtual Network Manager kann die Konfiguration von Routentabellen automatisieren, sodass Azure Firewall als nächster Hop verwendet wird, wodurch die manuelle UDR-Verwaltung in vielen Spoke-Abonnements reduziert wird.

Subnetzanforderungen

Subnet Mindestgröße Purpose Hinweise
AzureFirewallSubnet /26 Hostet Azure Firewall-Instanzen Muss genau benannt werden AzureFirewallSubnet
AzureFirewallManagementSubnet /26 Verwaltungsdatenverkehr (nur einfache SKU) Erforderlich für die Basic SKU; optional für erzwungenes Tunneling in anderen SKUs

Weitere Informationen zum Entwurf des virtuellen Hubnetzwerks und zur Subnetzplanung finden Sie unter Hub-Spoke-Topologie.

Regeltypen und Verarbeitungslogik

Azure Firewall verarbeitet Regeln mithilfe von Azure Firewall-Richtlinien. Regeln werden in Regelauflistungen organisiert, die in Regelsammlungsgruppen gruppiert werden. Die Firewall wertet Regeln in der folgenden Prioritätsreihenfolge aus:

  1. DNAT-Regeln (Destination Network Address Translation): Zuerst verarbeitet. Übersetzen Sie eingehenden Datenverkehr von einer öffentlichen IP in eine private IP hinter der Firewall.
  2. Netzwerkregeln: Als Zweites verarbeitet. Zulassen oder Verweigern des Datenverkehrs basierend auf Quell-IP, Ziel-IP, Port und Protokoll (Layer 3/4).
  3. Anwendungsregeln: Zuletzt verarbeitet. Ausgehenden Datenverkehr basierend auf FQDN, URL oder Webkategorie zulassen oder verweigern (Ebene 7).

Innerhalb jedes Regeltyps werden Regelsammlungsgruppen nach Priorität ausgewertet (niedrigste Zahl = höchste Priorität). Innerhalb einer Gruppe werden Regelsammlungen nach Priorität ausgewertet. Die erste übereinstimmende Regel bestimmt die Aktion (Zulassen oder Verweigern) und beendet die weitere Auswertung.

DNAT-Regeln

Verwenden Sie DNAT-Regeln, um interne Dienste über die öffentliche IP-Adresse der Firewall zu veröffentlichen. Die Firewall übersetzt die Zieladresse von der öffentlichen IP in die private IP des Back-End-Diensts. Zu den gängigen Szenarien gehören:

  • Verfügbarmachen eines internen Webservers über die öffentliche IP der Firewall am Port 443
  • Bereitstellen des kontrollierten RDP- oder SSH-Zugriffs auf ein Sprungfeld, ohne dem virtuellen Computer eine öffentliche IP zuzuweisen
  • Veröffentlichen von Nicht-HTTP/S-Diensten, die eingehenden Zugriff über das Internet erfordern
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

Mit DNAT-Regeln wird implizit eine entsprechende Netzwerkregel hinzugefügt, um den übersetzten Datenverkehr zuzulassen. Sobald eine DNAT-Regel übereinstimmt, wird der Datenverkehr übersetzt und ohne weitere Netzwerkregelverarbeitung zugelassen. Zur Sicherheit beschränken Sie die IP-Quelladresse in Ihren DNAT-Regeln auf bestimmte Internetquellen, anstatt Wildcards zu verwenden.

Netzwerkregeln

Netzwerkregeln filtern Datenverkehr auf Layer 3 und Layer 4. Verwenden Sie Netzwerkregeln, wenn Sie Datenverkehr basierend auf Quell-IP-Adresse, Ziel-IP-Adresse, Zielport und Protokoll zulassen oder verweigern müssen. Netzwerkregeln nehmen keine FQDN-Auflösung vor. Sie funktionieren streng auf IP-Adressen. Zu den gängigen Anwendungsfällen gehören:

  • Zulassen der Spoke-zu-Spoke-Kommunikation für bestimmte Ports (z. B. SQL Server auf TCP 1433).
  • Zulassen von NTP (UDP 123) für bestimmte Zeitserver.
  • Blockieren des Datenverkehrs an bekannte schädliche IP-Bereiche mithilfe von Verweigerungsregeln.
  • IcMP für die Netzwerkdiagnose zwischen bestimmten Subnetzen zulassen.

Netzwerkregeln unterstützen TCP-, UDP-, ICMP- und Any-Protokolltypen. Sie können IP-Adressen, IP-Bereiche, Diensttags und IP-Gruppen als Quelle und Ziel angeben.

Anwendungsregeln

Anwendungsregeln filtern ausgehenden HTTP/S- und MSSQL-Datenverkehr basierend auf FQDNs, URLs und Webkategorien. Anwendungsregeln setzen die DNS-Proxyfunktion für die FQDN-Auflösung voraus. Verwenden Sie Anwendungsregeln in folgenden Fällen:

  • Sie müssen den Zugriff auf bestimmte FQDNs zulassen (z. B. *.microsoft.com oder storage.blob.core.windows.net).
  • Sie möchten nach URL-Pfad filtern (nur Premium-SKU), z. B. zulassengithub.com/myorg/*, aber andere GitHub Pfade blockieren.
  • Sie müssen ganze Webkategorien zulassen oder blockieren (z. B. "Entwicklertools" zulassen und "Glücksspiele blockieren").

Anwendungsregeln stellen FQDN-Tags für allgemeine Azure-Dienste (z. B. Windows Update, Azure Backup und HDInsight) bereit, die die Regelerstellung vereinfachen, indem sie die erforderlichen FQDNs in ein einzelnes Tag gruppieren.

Important

Wenn Sie den DNS-Proxy auf Azure Firewall aktivieren, fungiert die Firewall als DNS-Resolver für Workloads. Konfigurieren Sie die DNS-Einstellungen Ihres virtuellen Netzwerks so, dass sie auf die private IP der Firewall verweisen, damit FQDN-basierte Regeln korrekt aufgelöst werden. Details zur DNS-Architektur finden Sie unter DNS-Sicherheit und Auflösung privater Namen.

SNAT-Verhalten

Standardmäßig wendet Azure Firewall SNAT (Source Network Address Translation) auf ausgehenden Datenverkehr an, der für öffentliche IP-Adressen bestimmt ist. Die Firewall verwendet keinen SNAT-Datenverkehr, wenn es sich bei dem Ziel um einen privaten IP-Bereich (RFC 1918) oder einen freigegebenen Adressraum (RFC 6598) handelt. Die Firewall übersetzt die Quell-IP von internetgebundenen Verbindungen in eine seiner öffentlichen IP-Adressen. Jede öffentliche IP stellt 2.496 SNAT-Ports pro Back-End-Instanz bereit.

Für Workloads mit hohen Raten ausgehender Verbindungen integrieren Sie sie mit dem NAT Gateway, um auf 64.512 Ports pro öffentlicher IP-Adresse zu skalieren (bis zu 16 öffentliche IP-Adressen, insgesamt etwa eine Million SNAT-Ports).

Wenn Sie das NAT-Gateway dem AzureFirewallSubnetzuordnen, verwendet der gesamte ausgehende Internetdatenverkehr automatisch die öffentlichen IP-Adressen des NAT-Gateways. Die Firewall prüft weiterhin Datenverkehr, aber NAT-Gateway verarbeitet die SNAT-Übersetzung. Es tritt kein Double NAT auf.

Note

NAT-Gateway mit zonenredundanten Azure Firewall erfordert die SKU des StandardV2-NAT-Gateways. NAT-Gateway wird in Virtual WAN gesicherten Hubarchitekturen nicht unterstützt.

Firewall-Manager und Richtlinienvererbung

Azure Firewall Manager bietet eine zentrale Sicherheitsrichtlinie und Routenverwaltung über mehrere Azure Firewall Instanzen hinweg. Wichtige Funktionen sind:

  • Richtlinienhierarchie: Erstellen Sie eine Basisrichtlinie (übergeordnete Richtlinie) mit organisationsweiten Regeln, und erlauben Sie untergeordneten Teams, untergeordnete Richtlinien zu erstellen, die vom übergeordneten Element erben. Übergeordnete Regeln haben unabhängig von untergeordneten Prioritätswerten immer Vorrang.
  • Regionsübergreifende Verwaltung: Eine Firewallrichtlinie ist eine globale Ressource, die Sie Firewalls in einer beliebigen Region oder einem Abonnement zuordnen können.
  • Multi-Firewall-Governance: Wenden Sie einen konsistenten Sicherheitsstatus über Hubfirewalls in verschiedenen Regionen oder über gesicherte Virtual WAN Hubs an.

NAT-Regeln sind firewallspezifisch und werden nicht von übergeordneten Richtlinien geerbt. Der Modus „Bedrohungserkennung“ wird geerbt, kann jedoch nur mit einem strengeren Modus in untergeordneten Richtlinien außer Kraft gesetzt werden. Eine Richtlinie ohne oder mit einer (1) Firewall-Zuordnung ist ohne zusätzliche Kosten inbegriffen. Zusätzliche Zuordnungen verursachen Abrechnungen.

Erzwungenes Tunneln

In einigen behördlichen Umgebungen muss der gesamte internetgebundene Datenverkehr zuerst über einen lokalen Inspektionspunkt geleitet werden, bevor er das Internet erreicht. Azure Firewall unterstützt erzwungene Tunneling, um diese Anforderung zu erfüllen.

Wenn Sie die erzwungene Tunnelung aktivieren:

  • Der AzureFirewallManagementSubnet Firewall-Verwaltungsdatenverkehr wird direkt ins Internet übertragen. Dieses Subnetz muss über eine Route zu 0.0.0.0/0 verfügen, deren nächster Hop das Internet ist. Sie können den Verwaltungsdatenverkehr nicht über eine On-Premises-Inspektion erzwingen.
  • Das AzureFirewallSubnet leitet für das Internet bestimmten Workload-Datenverkehr über ExpressRoute oder VPN Gateway an eine lokale Firewall oder eine virtuelle Netzwerkappliance (NVA) eines Drittanbieters weiter.
  • DNAT-Regeln werden im Erzwungenen Tunnelmodus nicht unterstützt, da eingehender Datenverkehr die öffentliche IP-Adresse der Firewall nicht direkt erreichen kann.
  • Die Firewall erfordert keine öffentliche IP auf der AzureFirewallSubnet, wenn Sie Forced Tunneling konfigurieren, da der gesamte ausgehende Datenverkehr über den lokalen Netzwerkpfad geleitet wird.

Verwenden Sie erzwungenes Tunneln, wenn Compliance-Mandate eine lokale Sichtbarkeit des gesamten internetgebundenen Datenverkehrs erfordern oder wenn Sie Azure Firewall mit einem vorhandenen lokalen Sicherheitsstapel verketten müssen. Häufige Szenarien umfassen Finanzdienstleistungsumgebungen, die datenaufbewahrungsrechtlichen Vorschriften unterliegen, und Regierungsnetzwerke mit zentralisierten Internet-Breakout-Anforderungen.

Important

Im Forced-Tunneling-Modus benötigt die AzureFirewallManagementSubnet eine eigene öffentliche IP-Adresse und eine UDR mit 0.0.0.0/0, die als nächsten Hop auf das Internet verweist. Diese Konfiguration stellt sicher, dass Azure den Verwaltungskanal an die Firewall halten kann.

TLS-Inspektion (Premium)

Azure Firewall Premium fängt ausgehende HTTPS-Verbindungen ab, entschlüsselt den Datenverkehr, prüft ihn anhand von IDPS-Signaturen und Anwendungsregeln und verschlüsselt sie dann erneut und leitet ihn weiter. Für diesen Vorgang ist ein in Azure Key Vault gespeichertes Zwischen-CA-Zertifikat erforderlich.

Zertifikatanforderungen

Anforderung Spezifikation
Bescheinigungstyp Intermediäre Zertifizierungsstelle
Schlüsselgröße Mindestens 2048 Bit RSA
CA-Kennzeichnung WAHR
Schlüsselverwendung KeyCertSign
Gültigkeit Mindestens 1 Jahr nach vorne
Storage Azure Key Vault (muss exportierbar sein)

Die Firewall verwendet das Zwischenzertifikat einer Zertifizierungsstelle, um für abgefangene Verbindungen dynamisch Serverzertifikate zu generieren. Endbenutzerbrowser und -anwendungen müssen der Stammzertifizierungsstelle oder Zwischenzertifizierungsstelle der Organisation in ihrem Zertifikatspeicher vertrauen, um Vertrauenswarnungen zu vermeiden.

IDPS

Die Premium-SKU enthält ein vollständig verwaltetes IDPS-Modul mit über 67.000 Regeln in 50 Kategorien. Signaturen werden kontinuierlich mit täglich veröffentlichten 20 bis 40 neuen Regeln aktualisiert. IDPS arbeitet in zwei Modi:

  • Warnungsmodus: Protokolliert Signatur-Übereinstimmungen, ohne Datenverkehr zu blockieren. Wird während der ersten Bereitstellung und Optimierung verwendet.
  • Warnungs- und Verweigerungsmodus: Protokolliert und blockiert datenverkehr, der IDPS-Signaturen entspricht. Nach der Optimierung in Produktion verwenden.

IDPS-Kategorien decken Schadsoftwarebefehle und -kontrolle, Phishing, Trojaner, Botnets, Exploit Kits, Sicherheitsrisiken und SCADA/ICS-Protokolle ab.

Caution

DIE TLS-Inspektion führt zu Latenz und hat Auswirkungen auf den Datenschutz. Stellen Sie sicher, dass die Rechtlichen und Complianceteams Ihrer Organisation die Überprüfung des verschlüsselten Datenverkehrs genehmigen. Schließen Sie sensible Kategorien (Gesundheitswesen, Banking) nach Bedarf mithilfe von Umgehungsregeln aus.

AKS-Egressfilterung

Wenn Azure Kubernetes Service (AKS) Cluster einen kontrollierten Ausgang erfordern, stellt Azure Firewall FQDN-basierte ausgehende Filterung für Clusterknoten bereit. Ohne Ausgangsfilter können AKS-Knoten einen beliebigen Internetendpunkt erreichen, wodurch die Angriffsfläche für Supply Chain- und Datenexfiltrationsangriffe erhöht wird.

So implementieren Sie dieses Muster:

  1. AKS mit auf outboundType gesetztem userDefinedRouting und einer benutzerdefinierten Routingtabelle für das Knotensubnetz bereitstellen.
  2. Legen Sie die Standardroute (0.0.0.0/0) auf die Azure Firewall private IP fest.
  3. Erstellen Sie Anwendungsregeln in der Firewallrichtlinie, die die erforderlichen AKS-FQDNs (Containerregistrierungen, API-Serverendpunkte, Microsoft Paketrepositorys) zulassen.
  4. Erstellen Sie Netzwerkregeln für erforderliche Nicht-HTTP/S-Endpunkte (NTP, DNS, Tunnelkonnektivität).

Dieses Muster bietet Sicherheitsteams Einblicke in die Und Kontrolle darüber, welche externen Endpunkte AKS-Knoten erreichen können, während der Cluster ordnungsgemäß funktioniert. Die erforderlichen FQDNs unterscheiden sich je nach AKS-Funktionsumfang. Cluster, die GPU-Knoten, Azure Monitor oder Azure Policy verwenden, erfordern zusätzliche Einträge in der Zulassungsliste.

Ausführliche FQDN-Anforderungen und Regelbeispiele finden Sie unter Verwenden von Azure Firewall zum Schützen von AKS-Bereitstellungen.

Note

Die AKS-Ausgangsfilterung mit Azure Firewall erfordert eine sorgfältige Koordination zwischen Plattform- und Anwendungsteams. Fehlende FQDN-Regeln verursachen Fehler bei der Pod-Planung und beim Pullen von Images. Beginnen Sie mit einer offenen Richtlinie und verschärfen Sie diese, nachdem Sie Datenverkehrsmusters in den Firewall-Protokollen beobachtet haben.

Überlegungen zum Entwurf

Schwerpunkt beim Lift-and-Shift-Firewall-Design

  • Übersetzen Sie lokale Firewallregeln in Azure Firewall Richtlinie: Verwenden Sie Netzwerkregeln für Nicht-HTTP/S-Protokolle und Anwendungsregeln für HTTP/S- oder MSSQL-Ziele, die FQDN-Filterung benötigen.
  • Beginnen Sie mit allgemeinen Zulassungsregeln, die Ihren aktuellen Sicherheitsstatus spiegeln, und straffen Sie sie nach der Migration, indem Sie Azure Firewall Protokolle verwenden, um die erforderlichen Ziele und Ports zu identifizieren.
  • Verwenden Sie IP-Gruppen, um Quell- und Zielzonen zu modellieren, damit die Regelwartung Ihren vorhandenen Segmentierungsgrenzen folgt.
  • Aktivieren Sie Diagnoseeinstellungen am ersten Tag, damit Sie Azure Datenverkehrsmuster mit Ihrem lokalen Basisplan vergleichen können, bevor Sie den Zugriff einschränken.

Fokus auf die Modernisierung des Firewall-Designs

  • Verwenden Sie die Hubfirewall als zentralen SNAT- und DNAT-Punkt für Anwendungs-Spokes, sodass die Eingangs- und Ausgangsrichtlinie im IT-verwalteten Hub verbleibt.
  • Aktivieren Sie Azure Firewall Premium, wenn die Ost-West-TLS-Inspektion oder die Produktions-IDPS-Erzwingung zwischen Anwendungsebenen erforderlich ist.
  • Verwenden Sie FQDN-Tags und Anwendungsregeln, um AKS- und Azure PaaS-Abhängigkeiten zuzulassen, ohne große Ziel-IP-Listen beizubehalten.
  • Überprüfen Sie die DNAT-Anforderungen im Zusammenhang mit dem Design Ihrer Front Door bzw. Ihres Application Gateway, damit eingehender Datenverkehr die Backend-Spoke-Netzwerke nur über zugelassene Prüfpfade erreicht.

Designfokus der cloudübergreifenden Firewall

  • Stellen Sie Azure Firewall in einem gesicherten virtuellen Hub bereit, wenn Azure der Transitpunkt für Niederlassungen, Azure und andere Cloudnetzwerke ist.
  • Verwenden Sie Netzwerkregeln, um den IPsec-Tunnelverkehr von AWS Transit Gateway, AWS Virtual Private Gateways oder Google Cloud VPN-Attachments zu prüfen, sobald die Routen in Azure eintreffen.
  • Aktivieren Sie IDPS, um anomale Ost-West- und cloudübergreifende Datenverkehrsmuster zu erkennen, die auf laterale Bewegungen zwischen Cloudumgebungen hinweisen können.
  • Aktivieren Sie die Bedrohungserkennungsfilterung, um bekannte schädliche Ziele in allen verbundenen Clouds mit einer einzigen Richtlinienoberfläche zu blockieren.

Voraussetzungen

Bevor Sie Azure Firewall bereitstellen:

  • AzureFirewallSubnet: Ihr virtuelles Hubnetzwerk muss ein dediziertes Subnetz AzureFirewallSubnet mit einer Mindestgröße von /26 enthalten. Informationen zur Subnetzplanung finden Sie unter "Virtuelles Netzwerk und Subnetzdesign ".
  • Hub-Spoke- oder Virtual WAN topologie: Stellen Sie Azure Firewall in einem zentralen Hub bereit, der Datenverkehr von Speichennetzwerken leitet. Siehe Hub-Spoke-Topologie oder Virtual WAN für Topologieoptionen.
  • IP-Adressplan: Reservieren Sie den Adressraum für das Firewall-Subnetz, das Verwaltungssubnetz (bei Verwendung von erzwungenen Tunneling) und alle öffentlichen IP-Adressen. Siehe IP-Adressplanung.
  • Azure Firewall Manager: Verwenden Sie Azure Firewall Manager, wenn Sie eine Richtlinienhierarchie benötigen, die Basisregeln für mehrere Firewallinstanzen gemeinsam verwendet.
  • Log Analytics Arbeitsbereich: Erstellen Sie einen Arbeitsbereich für Firewall-Diagnoseprotokolle vor der Bereitstellung, damit Sie datenverkehrs- und problembehandlungsregeln vom ersten Tag an überwachen können.

Sicherheitsüberlegungen

  • Protokollierung: Aktivieren Sie Diagnoseeinstellungen, um Azure Firewall Protokolle an einen Log Analytics Arbeitsbereich zu senden. Strukturierte Protokolle bieten Einblicke auf FQDN-Ebene in jede zulässige und verweigerte Verbindung, die Überwachung und forensische Analyse unterstützt.
  • Verfügbarkeit: Stellen Sie Azure Firewall in allen Verfügbarkeitszonen bereit, um die Verfügbarkeits-SLA zu maximieren. Aktuelle SLA-Prozentsätze finden Sie unter SLA für Azure Firewall.
  • Layered Defense: Azure Firewall ergänzt, ersetzt aber keine NSGs. Wenden Sie NSGs auf subnetz- und NIC-Ebene für die Mikrosegmentierung an. Verwenden Sie die Firewall für zentrale Richtlinien-, Bedrohungserkennungs- und Layer 7-Inspektionen.
  • Prüfen Sie nur, was nötig ist: Jeden Datenverkehr durch die Firewall zu zwingen, einschließlich interner Schichten einer Anwendung wie Web-zu-App und App-zu-Datenbank, erhöht die Latenz und die Verarbeitungskosten pro Gigabyte. Verwenden Sie NSGs und ASGs für Ost-West-Datenverkehr zwischen vertrauenswürdigen Ebenen, und reservieren Sie Firewall-Inspektion für Datenverkehr, der eine Vertrauensgrenze überschreitet: internetgebunden, cross-spoke, hybrid oder cross-cloud. Dieser Ansatz hält die Firewall auf den Datenverkehr konzentriert, der von der Inspektion profitiert und unnötige Kosten vermeidet.
  • DDoS-Schutz: Schützen Sie öffentliche IPs, die mit Azure Firewall verbunden sind, mithilfe von Azure DDoS Protection. Siehe DDoS-Schutz.
  • ExpressRoute-Datenverkehr: Wenn Sie ExpressRoute verwenden, konfigurieren Sie UDRs, um privaten Peeringdatenverkehr über Azure Firewall zur Überprüfung von Hybriddatenverkehrsflüssen zu leiten.

Weitere Informationen

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Richten Sie die Überwachung für Ihr migriertes Netzwerk ein: Überprüfen Sie die Konnektivität und Leistung mit Network Watcher, nachdem Sie Ihre Firewall konfiguriert haben.

Als Nächstes in Ihrer Modernisierungsreise:

Schützen Sie Ihre Webanwendungen mit WAF: Fügen Sie Web Application Firewall auf Front Door oder Anwendungsgateway für Ihre kundenorientierten Web-Apps hinzu.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Cloudübergreifendes Monitoring einrichten: Cloudübergreifende Umgebungen sind operativ schwieriger zu beheben. Die Überwachung ist unerlässlich, nicht optional.

  • Last updated on