Ausgehender Internetzugriff: Steuern des ausgehenden Datenverkehrs aus Azure

In diesem Artikel wird erläutert, wie der ausgehende Internetzugriff aus Azure Virtual Networks gesteuert werden kann. Es vergleicht NAT-Gateway, Azure Firewall und kombinierte Ausgangsmuster, um Ihnen bei der Auswahl einer vorhersehbaren, sicheren Methode für Ihre Workloads zu helfen.

Inhalt dieses Artikels

Die Steuerung des ausgehenden Datenverkehrs bestimmt, wie Ihre Azure-Workloads das öffentliche Internet erreichen. Eine gut durchdachte Ausgangsstrategie bietet vorhersagbare öffentliche IP-Adressen, verhindert SNAT-Portausschöpfung und filtert optional ausgehende Verbindungen nach Ziel.

Note

In diesem Artikel geht es um ausgangsspezifische Konzepte. Vollständige Firewallabdeckung finden Sie unter Azure Firewall und Datenverkehrsüberprüfung.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn eine oder mehrere dieser Bedingungen gelten:

  • Ihre Workloads benötigen kontrollierten ausgehenden Zugriff auf das Internet für Updates, APIs oder externe Dienste.
  • Sie benötigen vorhersagbare öffentliche IP-Adressen für ausgehende Verbindungen.
  • Sie müssen die Erschöpfung der SNAT-Ports verhindern oder die ausgehende Konnektivität für Workloads mit vielen Verbindungen skalieren.
  • Sie müssen zwischen NAT-Gateway, Azure Firewall oder einem kombinierten Muster für die Steuerung und Inspektion des Ausgangs wählen.

Tip

Einem Szenariopfad folgen? Wählen Sie Ihr Szenario oben auf der Seite aus, um eine maßgeschneiderte Anleitung zu erhalten. Der folgende Kernleitfaden gilt für alle Leser.

Heben und Verschieben des Fokus: Ihre migrierten virtuellen Computer benötigen einen kontrollierten ausgehenden Internetzugriff. Zentralisieren Sie den gesamten ausgehenden Datenverkehr über die Hubfirewall, um einheitliche Sicherheitsrichtlinien für migrierte Workloads zu erzwingen.

Lesen Sie diesen Artikel, wenn Sie:

  • Stellen Sie Workloads bereit, die das Internet für Updates, API-Aufrufe oder Dienste von Drittanbietern erreichen müssen.
  • Möchten Sie ausgehende Steuerung über Azure Firewall im Hub-VNet zentralisieren.
  • Sie müssen den standardmäßigen ausgehenden Zugriff auf migrierte Workloads deaktivieren und durch eine explizite Ausgangsmethode ersetzen.
  • Erfordert eine feste, vorhersagbare öffentliche IP-Adresse für ausgehende Verbindungen.

Modernisierungsfokus: Alle Spoke-VNets leiten ausgehenden Datenverkehr über benutzerdefinierte Routen (UDR) durch die Hubfirewall. Dieses zentrale Ausgangsmodell ist integraler Bestandteil Ihrer Sicherheitsarchitektur, da es verhindert, dass App-Teams IT-verwaltete Sicherheitskontrollen umgehen.

Lesen Sie diesen Artikel, wenn Sie:

  • Es muss sichergestellt werden, dass alle Workloads in den Spokes (AKS, App Service, VMs) den ausgehenden Datenverkehr über die Hub-Firewall leiten.
  • UDR-basiertes Routing von jedem Spoke zum Azure Firewall im Hub für eine konsistente Eingangsrichtlinie.
  • Die Hubfirewall muss als SNAT für alle ausgehenden Verbindungen fungieren.
  • Sie müssen die Erschöpfung der SNAT-Ports für Workloads mit einer hohen Anzahl von Verbindungen verhindern.

Cloudübergreifender Fokus: Schließen Sie einen zentralen Ausgang ein, wenn für Ihr Zieldesign eine kontrollierte Internetausgangsrichtlinie erforderlich ist. Andernfalls durchläuft cross-Cloud-Datenverkehr den Transitpfad (Azure Firewall im sicheren virtuellen Hub) und benötigt keine separate Ausgangskonfiguration.

Lesen Sie diesen Artikel, wenn Sie:

  • Benötigen Sie eine Richtlinie für den zentralen Internetausgang in Ihrer Azure Landing Zone.
  • Sie möchten dieselbe Azure Firewall sowohl für die cloudübergreifende Transitinspektion als auch für die Internetausleitung nutzen.
  • Ersetzen Sie den standardmäßigen ausgehenden Zugriff, bevor er auslaufen wird.

Azure Dienste und Features

In der folgenden Tabelle werden die Dienste und Features beschrieben, die für den ausgehenden Internetzugriff in Azure virtuellen Netzwerken verfügbar sind.

Dienst oder Feature Was es bietet Wann wird es verwendet?
Standardmäßiger ausgehender Zugriff (eingestellt) Azure weist automatisch eine temporäre öffentliche IP für ausgehende Verbindungen zu. Die zugewiesene IP-Adresse ist nicht vorhersagbar und kann sich ohne Vorankündigung ändern. Verwenden Sie nicht für neue Bereitstellungen. Ersetzen Sie es durch ein NAT-Gateway oder Azure Firewall. Siehe Sicherheitsüberlegungen.
Azure NAT Gateway Verwalteter SNAT-Dienst mit festen, vorhersagbaren öffentlichen IPs. Stellt 64.512 SNAT-Ports pro öffentlicher IP bereit, bis zu 16 öffentliche IPs (insgesamt über 1 Millionen Ports). Keine Inhaltsfilterung. Workloads mit ausschließlich ausgehendem Datenverkehr, die eine feste ausgehende IP-Adresse benötigen, Anwendungen mit einer hohen Anzahl von Verbindungen und Szenarien, in denen die Erschöpfung von SNAT-Ports ein Risiko darstellt.
Azure Firewall Vollständige Layer-3–7-Überprüfung für ausgehenden Datenverkehr. FQDN-Filterung, URL-Filterung, Webkategorien und IDPS (Premium SKU). Zentralisierte Richtlinienverwaltung. Wenn Sie steuern müssen, mit welchen Zielen Ihre Ressourcen verbunden sind, nicht nur, dass sie über ausgehenden Zugriff verfügen.
NAT-Gateway + Azure Firewall NAT-Gateway behandelt die SNAT-Skalierung im Firewall-Subnetz. Azure Firewall behandelt Inspektion und Filterung. Es tritt kein Double NAT auf. Produktionsumgebungen, die sowohl skalierbaren ausgehenden Datenverkehr als auch inhaltsbasierte Filterung benötigen. Empfohlene Architektur für Unternehmensworkloads.
VM mit öffentlicher IP (ausgehend) Der virtuelle Computer verwendet eine eigene öffentliche IP-Adresse für ausgehenden Datenverkehr. Keine zentralisierte Kontrolle oder Filterung. Nicht in der Produktion verwenden. Kein zentrales Management, bei Skalierung unvorhersehbar und profitiert nicht von gemeinsam genutzten SNAT-Ressourcen.

Wie man auswählt

Diagramm mit drei ausgehenden Ausgangspfaden aus einem virtuellen Workload-Netzwerk über NAT-Gateway, Azure Firewall oder beides.

Steuern des ausgehenden Zugriffs

Verwenden Sie die folgende Tabelle, um eine Ausgehende Methode basierend auf Ihren Anforderungen auszuwählen.

Ihre Anforderung Empfohlener Ansatz Warum?
Nur feste ausgehende IP-Adresse, keine Filterung nötig NAT Gateway Stellt vorhersagbare öffentliche IPs mit automatischer SNAT-Portzuweisung bereit. Kein Inspektionsaufwand oder Filterkosten. Einfachste Produktionsfertige Option.
FQDN-Filterung, URL-Filterung oder Datenverkehrsüberprüfung Azure Firewall Filtert ausgehende Verbindungen nach Ziel-FQDN oder URL. Premium-SKU fügt IDPS und TLS-Inspektion für die erweiterte Bedrohungserkennung hinzu.
Feste ausgehende IP und Inhaltsfilterung NAT-Gateway + Azure Firewall DAS NAT-Gateway auf dem AzureFirewallSubnet bietet skalierbare SNAT. Die Firewall prüft den Datenverkehr vor dem Ausgang. Das Beste aus beiden Funktionen.
Verwenden Sie nicht für neue Bereitstellungen Standardmäßiger ausgehender Zugriff oder öffentliche IP-Adresse des virtuellen Computers Standardmäßiger ausgehender Zugriff wird eingestellt. Öffentliche VM-IPs bieten keine zentrale Steuerung. Beide eignen sich nicht für Produktionsworkloads.

NAT-Gateway im Vergleich zu Azure Firewall für den Ausgang

Verwenden Sie den folgenden Vergleich, um die Kompromisse zwischen NAT-Gateway und Azure Firewall zu verstehen, wenn sie unabhängig voneinander verwendet werden.

Fähigkeit NAT Gateway Azure Firewall
SNAT-Ports 64.512 pro öffentliche IP (bis zu 16 IPs, über 1 Millionen Insgesamt) 2.496 pro öffentliche IP pro Back-End-Instanz (max. 250 IPs)
Datenverkehrsfilterung Keine: übergibt den gesamten ausgehenden Datenverkehr. FQDN-Regeln, URL-Filterung, Webkategorien, Netzwerkregeln
IDPS- und TLS-Inspektion Nicht verfügbar Nur Premium-SKU
Throughput Zeilenrate für das Subnetz (keine veröffentlichte Obergrenze für SNAT) Bis zu 100 GBit/s (Premium), 30 GBit/s (Standard), 250 MBit/s (Einfach)
Kostenmodell Pro Stunde Ressource + pro GB verarbeitete Daten Pro Stunde Ressource + pro GB verarbeitete Daten (höhere Basiskosten)
Komplexität des Routings Direkte Zuordnung zu einem Subnetz, keine UDR erforderlich Erfordert UDR (0.0.0.0/0 → private IP der Firewall) für Workload-Subnetze
Anwendungsfall Ausgehende Verbindungen mit hohem Volume, für die feste IPs erforderlich sind Regulierte Umgebungen, die Egress-Filterung und Protokollierung erfordern

Routingpriorität für ausgehenden Datenverkehr

Azure wertet ausgehende Methoden in der folgenden Prioritätsreihenfolge aus. Methoden mit höherer Priorität überschreiben diejenigen mit niedrigerer Priorität im selben Subnetz:

  1. UDR zu einem virtuellen Gerät oder einem virtuellen Netzwerkgateway: setzt alle anderen ausgehenden Methoden außer Kraft, einschließlich NAT Gateway.
  2. NAT-Gateway: hat Vorrang vor öffentlichen IP-Adressen auf Instanzebene und Lastenausgleichsregeln für ausgehenden Datenverkehr.
  3. Öffentliche IP-Adresse auf Instanzebene auf dem virtuellen Computer.
  4. Load Balancer-Ausgangsregeln.
  5. Standardsystemroute zum Internet (Microsoft diese Option für neue Bereitstellungen eingestellt).

Important

Eine benutzerdefinierte Route (UDR) mit Ziel 0.0.0.0/0, die auf eine virtuelle Appliance (z. B. Azure Firewall) zeigt, setzt NAT-Gateway außer Kraft. Dieses Verhalten ist für die kombinierte NAT-Gateway + Firewall-Architektur vorgesehen. Der UDR für Workload-Subnetze erzwingt den Datenverkehr über die Firewall, während das NAT-Gateway im AzureFirewallSubnet die endgültigen Egress-IPs bereitstellt.

Kombinierte Architektur: NAT-Gateway + Azure Firewall

Das empfohlene Produktionsmuster für den Unternehmensausgang kombiniert beide Dienste:

  1. Workload-Subnetze verfügen über einen UDR, der 0.0.0.0/0 Datenverkehr an die private IP-Adresse Azure Firewall sendet.
  2. Azure Firewall überprüft und filtert den ausgehenden Datenverkehr mithilfe von Netzwerkregeln, Anwendungsregeln oder beidem.
  3. DAS NAT-Gateway ist mit AzureFirewallSubnet verknüpft und bietet skalierbare SNAT für die ausgehenden Verbindungen der Firewall.
  4. Es tritt keine doppelte NAT auf. Die Firewall sendet Datenverkehr über die private IP an das NAT-Gateway, und das NAT-Gateway wendet SNAT einmal mithilfe seiner öffentlichen IP-Adressen an.

Diese Architektur bietet Ihnen eine zentrale Inspektion mit skalierbarem SNAT. Das AzureFirewallSubnet benötigt keine zusätzlichen UDRs, da NAT-Gateway bei zugehörigen Verbindungen automatisch ausgehenden Internetdatenverkehr leitet.

Note

Das Standardmäßige NAT-Gateway ist eine Zonalressource und unterstützt keine zonenredundanten Bereitstellungen. Wenn Sie einen zonenredundanten Azure Firewall bereitstellen, verwenden Sie NAT-Gateway V2 (StandardV2 SKU) für zonenredundante SNAT. Standardmäßiges NAT-Gateway wird zu einem einzelnen Fehlerpunkt während eines zonalen Ausfalls, wenn er mit einer zonenredundanten Firewall gekoppelt wird. Weitere Informationen finden Sie unter NAT Gateway-SKUs.

Einführung in den Datenfluss

Die folgende Sequenz zeigt, wie eine einzelne ausgehende Anforderung über die kombinierte Architektur fließt:

  1. Ein virtueller Computer in einem Workload-Subnetz startet eine TCP-Verbindung mit einer externen API (z. B api.contoso.com:443. ).
  2. Der UDR des Subnetzes stimmt mit 0.0.0.0/0 überein und sendet das Paket an die Azure Firewall private IP.
  3. Azure Firewall wertet die Verbindung mit Anwendungsregeln und Netzwerkregeln aus. Wenn eine Anwendungsregel mit einem FQDN-Zulassungseintrag übereinstimmt, lässt die Firewall die Verbindung zu.
  4. Die Firewall sendet das zulässige Paket über eine eigene Schnittstelle im AzureFirewallSubnet.
  5. DAS NAT-Gateway, das dem AzureFirewallSubnet zugeordnet ist, führt SNAT aus. Sie übersetzt die private Quell-IP der Firewall in einen seiner öffentlichen IP-Adressen und weist einen SNAT-Port vom Pool zu.
  6. Die Antwort der externen API kehrt zur öffentlichen IP des NAT-Gateways zurück. NAT-Gateway führt eine Reverseübersetzung durch und liefert das Paket zurück an die Firewall.
  7. Die Firewall sendet die Antwort an den ursprünglichen virtuellen Computer über den vorhandenen Verbindungsstatus.

In diesem End-to-End-Flow prüft die Firewall den Datenverkehr genau einmal, und NAT-Gateway wendet SNAT genau einmal an, ohne doppelte NAT.

Überwachung und Diagnose

Überwachen Sie Ihre Ausgangsinfrastruktur, um Kapazitätsprobleme zu erkennen, bevor sie Sich auf Workloads auswirken:

  • NAT-Gatewaymetriken: Überwachen der Gesamtanzahl der SNAT-Verbindungen, der SNAT-Verbindungsanzahl (pro Zustand) und der Verfügbarkeit von Datenpfaden in Azure Monitor. Legen Sie Warnungen fest, wenn die SNAT-Portnutzung 80% der zugeordneten Kapazität überschreitet.
  • Azure Firewall Protokolle: Diagnoseeinstellungen zum Senden von Protokollen an Log Analytics aktivieren. Verwenden Sie die Protokollkategorien AzureFirewallApplicationRule und AzureFirewallNetworkRule , um zulässige und verweigerte ausgehende Verbindungen zu überwachen.
  • Verbindungsmonitor: Verwenden Sie Network Watcher Verbindungsmonitor zum Testen der End-to-End-Konnektivität von Workload-VMs zu externen Endpunkten. Verbindungsmonitor erkennt Latenzerhöhungen und Konnektivitätsfehler, die auf SNAT-Ausschöpfung oder Firewallfehler hinweisen können.
  • Firewallmetriken: Verfolgen Sie den Durchsatz, die Anzahl der Regeltreffer und die SNAT-Portauslastung, um Ihre Firewall-SKU bedarfsgerecht zu dimensionieren und stark frequentierte Regeln zu identifizieren.

Überlegungen zum Entwurf

Verwenden Sie Azure Firewall für alle ausgehenden Kommunikationen von migrierten Workloads. Mit diesem Ansatz erhalten Sie zentrale FQDN-Filterung, Protokollierung und Bedrohungserkennung von Tag 1:

  • Standardmäßiger ausgehender Zugriff deaktivieren: Bei neuen Bereitstellungen werden Subnetze standardmäßig privat (keine automatische ausgehende Bereitstellung) verwendet. Ersetzen Sie bei bestehenden VNets explizit den Standardausgang durch ausgehenden Datenverkehr über Azure Firewall, um zu vermeiden, dass Sie sich auf unvorhersehbare, unkontrollierte öffentliche IP-Adressen verlassen.
  • UDR in den Workload-Subnetzen: Erstellen Sie in jedem Spoke-Workload-Subnetz eine benutzerdefinierte Route (0.0.0.0/0 → private IP-Adresse der Azure Firewall). Diese Konfiguration erzwingt den gesamten internetgebundenen Datenverkehr über die Hubfirewall.
  • NAT-Gateway auf AzureFirewallSubnet: Ordnen Sie das NAT-Gateway dem Firewall-Subnetz für skalierbare SNAT zu. Diese Kombination bietet vorhersehbare Egress-IPs und vermeidet SNAT-Portausschöpfung.
  • Beginnen Sie mit allgemeinen Erlaubnisregeln und verschärfen Sie diese im Laufe der Zeit: Erlauben Sie während der Migration ausgehende Verbindungen zu den Zielen, die Ihre Anwendungen benötigen (Windows Update, Paket-Repositories, APIs von Drittanbietern). Sobald sich die Migration stabilisiert hat, die Firewall-Protokolle prüfen und auf bekannte FQDNs beschränken.

UDR-basiertes Routing von jedem Spoke zur Hub-Firewall ist die Grundlage Ihres Sicherheitsmodells für den ausgehenden Datenverkehr. App-Teams können von der IT verwalteten ausgehenden Steuerelemente nicht umgehen:

  • UDR in jedem Spoke-VNet: Jedes Spoke-Workload-Subnetz verfügt über eine Routentabelle mit 0.0.0.0/0 → Hub Azure Firewall private IP. Diese Konfiguration stellt sicher, dass der ausgehende Datenverkehr von AKS-Knoten, VNet-integrierten Subnetzen von App Service und VMs durch die Firewall geleitet wird.
  • Hubfirewall als SNAT: Azure Firewall führt Quell-NAT für alle ausgehenden Verbindungen aus. Alle Workloads in den Spokes nutzen die ausgehenden IP-Adressen der Firewall gemeinsam, was die Pflege der Zulassungsliste in Partner-Firewalls vereinfacht.
  • NAT-Gateway für SNAT-Skalierung: Ordnen Sie das NAT-Gateway dem AzureFirewallSubnet zu. Mit 16 öffentlichen IPs (über 1 Millionen SNAT-Ports) behandeln Sie Workloads mit hoher Verbindungsanzahl wie AKS-Clustern mit vielen Pods, die externe API-Aufrufe tätigen.
  • Anwendungsregeln für die FQDN-Steuerung: Verwenden Sie Anwendungsregeln der Azure Firewall, um ausgehenden Datenverkehr per FQDN einzuschränken. App-Teams beantragen FQDN-Freigabeeinträge über einen Change-Management-Prozess. Das Prinzip „Alles ist standardmäßig verboten“ verhindert die Exfiltration von Daten.

Azure Firewall im sicheren virtuellen Hub überprüft sowohl cloudübergreifenden Transitdatenverkehr als auch ausgehenden Internetdatenverkehr. Das Freigeben einer einzelnen Firewall für beide Pfade vereinfacht die Architektur:

  • Sichere Virtuelle Hub-Firewall für den Ausgang: Wenn Sie Virtual WAN mit einem sicheren Hub bereitstellen, verarbeitet Azure Firewall im Hub den Internetausgang für alle verbundenen VNets. Konfigurieren Sie die Richtlinie für das Routing von Internetdatenverkehr des sicheren Hubs, um 0.0.0.0/0 über die Firewall zu senden.
  • Der Ausgang und die cloudübergreifende Übertragung teilen die gleiche Firewall: Datenverkehr, der für das Internet bestimmt ist, und datenverkehr, der für AWS/Google Cloud über IPSec-Tunnel bestimmt ist, durchlaufen beide Azure Firewall zur Inspektion. Dieses Design bedeutet, dass Sie ein Regelwerk für alle ausgehenden Pfade beibehalten.
  • Zentralisieren Sie nur bei Bedarf: Wenn Ihr cloudübergreifendes Design keinen zentralen Internetzugang erfordert (zum Beispiel wenn Workloads nur zwischen Clouds kommunizieren), können Sie diese Konfiguration überspringen und sich allein auf die Firewall-Inspektion des cloudübergreifenden Transitverkehrs verlassen.

Voraussetzungen

Bevor Sie Kontrollen für ausgehenden Datenverkehr implementieren, vergewissern Sie sich, dass die folgenden Punkte erfüllt sind:

  • Ein virtuelles Netzwerk wird bereitgestellt mit auf Ihre Workloads abgestimmten Subnetzen. Informationen zum Subnetzentwurf finden Sie unter "Virtuelle Netzwerke und Subnetze ".
  • Sie verstehen benutzerdefinierte Routen (UDRs) und wie sie standardmäßiges Azure Routing außer Kraft setzen. Weitere Informationen finden Sie unter "Virtuelle Netzwerke und Subnetze für UDR-Konfigurationsdetails".
  • Ihr Firewall-Subnetz wird ordnungsgemäß angepasst, wenn Sie Azure Firewall verwenden. Das AzureFirewallSubnet erfordert mindestens /26 (64 Adressen).
  • Sie kennen Ihre SNAT-Skalierungsanforderungen. Berechnen Sie die maximale Anzahl gleichzeitiger ausgehender Verbindungen, um zu ermitteln, wie viele öffentliche IP-Adressen für das NAT-Gateway Sie benötigen (64.512 Ports pro IP).

Sicherheitsüberlegungen

Ersetzen des standardmäßigen ausgehenden Zugriffs

Standardmäßiger ausgehender Zugriff wird eingestellt. Für API-Versionen, die nach dem 31. März 2026 veröffentlicht werden, sind neue virtuelle Netzwerke standardmäßig mit privaten Subnetzen konfiguriert (kein automatischer ausgehender Datenverkehr). Vorhandene virtuelle Netzwerke sind nicht betroffen, aber Sie sollten zu einer expliziten ausgehenden Methode migrieren. Ausführliche Informationen finden Sie in der Standarddokumentation für ausgehenden Zugriff.

Note

Vorhandene virtuelle Netzwerke und VMs, die derzeit standardmäßigen ausgehenden Zugriff verwenden, funktionieren weiterhin. Die zugewiesene öffentliche IP ist jedoch nicht vorhersehbar, bietet keine Filterung und löst Azure Advisor Warnungen aus. Planen Sie unabhängig vom Zeitplan für die Außerbetriebnahme die Migration zu NAT Gateway oder Azure Firewall.

UDR-Routing für zentrale Firewallüberprüfung

Wenn Sie Azure Firewall für die Egresssteuerung verwenden, erstellen Sie auf jedem Workload-Subnetz eine UDR mit:

  • Ziel: 0.0.0.0/0
  • Typ des nächsten Hops: Virtuelles Gerät
  • Nächste Hopadresse: Azure Firewall private IP (z. B. 10.0.1.4)

Diese Konfiguration stellt sicher, dass der gesamte internetgebundene Datenverkehr von Workload-Subnetzen zur Überprüfung über die Firewall durchläuft. Ohne diese UDR umgeht der Datenverkehr die Firewall und verwendet direkt die im Subnetz konfigurierte ausgehende Methode.

SNAT-Portausschöpfung verhindern

Die SNAT-Portausschöpfung erfolgt, wenn eine Workload mehr gleichzeitige ausgehende Verbindungen öffnet, als der verfügbare Portbestand unterstützt. Symptome sind zeitweilige Verbindungstimeouts, TCP RST-Pakete für ausgehende Verbindungen und fehlgeschlagene HTTP-Anforderungen mit Socketfehlern. Anwendungsprotokolle zeigen die Fehler „Adresse wird bereits verwendet“ oder „angeforderte Adresse kann nicht zugewiesen werden“. Die Erschöpfung manifestiert sich in der Regel unter Last, wenn viele kurzlebige Verbindungen schnell zu derselben Ziel-IP und demselben Port geöffnet werden.

So verhindern Sie die Erschöpfung:

  • Verwenden Sie NAT-Gateway für Workloads mit hoher ausgehender Verbindungsanzahl. Jede öffentliche IP stellt 64.512 SNAT-Ports mit dynamischer Zuordnung über alle Ressourcen im Subnetz bereit.
  • Fügen Sie Ihrem NAT-Gateway öffentliche IPs hinzu, wenn die Überwachung die Portnutzung über 80%zeigt. Fügen Sie bis zu 16 öffentliche IPs hinzu.
  • Verwenden Sie das Verbindungspooling im Anwendungscode, um vorhandene Verbindungen wiederzuverwenden, anstatt neue Verbindungen für jede Anforderung zu öffnen.
  • Diversifizierung von Zielendpunkten nach Möglichkeit. Die SNAT-Portzuordnung erfolgt je Ziel-IP-/Port-Tupel, sodass die Verteilung des Datenverkehrs auf mehrere Ziel-IPs die Portauslastung verringert.
  • Reduzieren Sie Leerlauf-Timeouts, um Ports schneller wieder freizugeben. Das Standardmäßige Leerlauftimeout des NAT-Gateways beträgt 4 Minuten. Verringern Sie diesen Wert für Workloads, die viele kurzlebige Verbindungen erstellen.

Netzwerksicherheitsgruppen ergänzen die Kontrolle des ausgehenden Datenverkehrs

Netzwerksicherheitsgruppen (NSGs) und ausgehende Ausgangsmethoden dienen verschiedenen Zwecken und arbeiten zusammen. NSGs filtern Datenverkehr nach IP-Adresse und Port auf Subnetz- oder NIC-Ebene. NAT-Gateway und Azure Firewall steuern, wie der Datenverkehr das Internet erreicht. Verwenden Sie beide Ebenen für eine mehrschichtige Verteidigung. Anleitungen zum Entwurf von NSG finden Sie unter Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen .

Überlegungen zu Forced Tunneling

Der ausgehende Datenverkehr bei erzwungenem Tunneling über die lokale Infrastruktur kann Latenz verursachen und erhöht die Abhängigkeit von der lokalen Firewall. Ziehen Sie Azure Firewall für die Prüfung des ausgehenden Datenverkehrs in Betracht, wenn geringe Latenz wichtig ist. Wenn die Compliance die lokale Inspektion vorschreibt, testen Sie die End-to-End-Latenz von Workload-Subnetzen, und stellen Sie sicher, dass der lokale Pfad die Durchsatzanforderungen verarbeiten kann, ohne zu einem Engpass zu werden.

Datenexfiltration verhindert

Azure Firewall FQDN-Filterung verhindert die Datenexfiltration, indem ausgehende Verbindungen nur auf genehmigte Domänennamen beschränkt werden. Definieren Sie Anwendungsregeln, mit denen Datenverkehr zu bestimmten FQDNs (zum Beispiel *.blob.core.windows.net oder api.partner.com) zugelassen und alle anderen ausgehenden Verbindungen verweigert werden. Dieser Ansatz stellt sicher, dass kompromittierte Workloads keine Daten an vom Angreifer kontrollierte Endpunkte senden können.

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:

Konfigurieren Sie Ihre Hubfirewall: Richten Sie Azure Firewall für zentrale Ost-West-Inspektion und ausgehende Datenverkehrskontrolle ein.

Als Nächstes in Ihrer Modernisierungsreise:

Konfigurieren Sie Ihre Hubfirewall: Richten Sie Azure Firewall als SNAT/DNAT in Ihrem Hub ein, um den gesamten Datenverkehr zu bereinigen, bevor sie die App-Ebene erreicht.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Cloud-übergreifendes Monitoring einrichten: Cloud-übergreifende Umgebungen sind schwieriger bei der Fehlerbehebung. Richten Sie die Überwachung ein, bevor Sie live gehen.

  • Last updated on