Announcements, Azure Firewall, Networking
Azure Firewall-Tunnelerzwingung und SQL-FQDN-Filterung sind jetzt allgemein verfügbar
Posted on
4 min read
Zwei neue wichtige Features sind jetzt in Azure Firewall allgemein verfügbar: Tunnelerzwingung und SQL-FQDN-Filterung. Außerdem wurde der Grenzwert für mehrere öffentliche IP-Adressen für die Ziel-Netzwerkadressübersetzung (DNAT) und die Quell-Netzwerkadressübersetzung (SNAT) von 100 auf 250 erhöht.
Azure Firewall ist ein cloudnatives Firewall-as-a-Service-Angebot (FWaaS), mit dem Sie Ihren gesamten Datenverkehr mithilfe eines DevOps-Ansatzes zentral verwalten und protokollieren können. Der Dienst unterstützt Filterregeln sowohl auf Anwendungs- als auch auf Netzwerkebene und ist in den Microsoft Threat Intelligence-Feed integriert, um bekannte schädliche IP-Adressen oder Domänen herauszufiltern. Azure Firewall ist dank integrierter automatischer Skalierung hochverfügbar.
Unterstützung für Tunnelerzwingung ist jetzt allgemein verfügbar
Mithilfe der Tunnelerzwingung können Sie den gesamten Internetdatenverkehr von Azure Firewall an Ihre lokale Firewall umleiten oder zur weiteren Untersuchung auf einem virtuellen Netzwerkgerät (Network Virtual Appliance, NVA) in der Nähe verketten. Sie aktivieren die Tunnelerzwingung auf einer Firewall beim Erstellen einer neuen Firewall. Zurzeit ist es nicht möglich, eine vorhandene Firewallbereitstellung auf den Tunnelerzwingungsmodus umzustellen.
Zur Unterstützung der Tunnelerzwingung wird der Datenverkehr der Dienstverwaltung von dem der Kunden getrennt. Ein zusätzliches dediziertes Subnetz namens „AzureFirewallManagementSubnet“ wird benötigt. Dabei muss dessen eigene zugeordnete öffentliche IP-Adresse verwendet werden. Die einzige in diesem Subnetz erlaubte Route ist eine Standardroute zum Internet, und die BGP-Routenverteilung (Border Gateway Protocol) muss deaktiviert sein.
Bei dieser Konfiguration kann „AzureFirewallSubnet“ jetzt Routen zu jeder lokalen Firewall oder NVA enthalten, um den Datenverkehr zu verarbeiten, bevor dieser an das Internet weitergeleitet wird. Sie können diese Routen auch über BGP in „AzureFirewallSubnet“ veröffentlichen, wenn die BGP-Routenverteilung in diesem Subnetz aktiviert ist.
Abbildung 1. Azure Firewall im Tunnelerzwingungsmodus
Vermeiden von SNAT bei Tunnelerzwingung
Azure Firewall unterstützt automatische SNAT (Source Network Address Translation, Quell-Netzwerkadressenübersetzung) für den gesamten ausgehenden Datenverkehr zu öffentlichen IP-Adressen. Azure Firewall bietet keine Quellnetzwerkadressenübersetzung, wenn die Ziel-IP-Adresse ein privater IP-Adressbereich gemäß IANA RFC 1918 ist. Diese Logik ist ideal für direkt ausgehenden Datenverkehr zum Internet. Wenn die Tunnelerzwingung aktiviert ist, wird der Datenverkehr zum Internet jedoch per SNAT an eine der privaten IP-Adressen der Firewall in AzureFirewallSubnet gesendet, sodass die Quelle vor der lokalen Firewall verborgen wird. Sie können Azure Firewall so konfigurieren, dass unabhängig von der Ziel-IP-Adresse keine SNAT verwendet wird, indem Sie 0.0.0.0/0 als privaten IP-Adressbereich hinzufügen. Beachten Sie, dass Azure Firewall bei dieser Konfiguration keine Daten direkt an das Internet senden kann. Weitere Informationen finden Sie unter SNAT für private IP-Adressbereiche in Azure Firewall..
Abbildung 2: Azure Firewall-Konfiguration mit Präfixen für private IP-Adressen, um SNAT zu vermeiden
Routing an öffentliche PaaS und Office 365
Die Azure Firewall-Tunnelerzwingung ermöglicht es zwar, den gesamten Internetdatenverkehr an Ihre lokale Firewall oder eine NVA in der Nähe weiterzuleiten, dies ist jedoch nicht immer erwünscht. Beispielsweise ist es wahrscheinlich besser, Daten direkt an eine öffentliche PaaS (Platform-as-a-Service) oder Office 365 auszugeben. Dazu können Sie Benutzerdefinierte Routen (UDR) für bestimmte Ziele dem AzureFirewallSubnet mit „Internet“ als Typ des nächsten Hops hinzufügen. Da diese Definition spezifischer als die Standardroute ist, hat sie Vorrang. Weitere Informationen finden Sie unter Azure-IP-Bereiche und -Diensttags und Office 365-IP-Adressen.
Als alternativen Ansatz für direkten ausgehenden Datenverkehr zu einer öffentlichen PaaS können Sie Dienstendpunkte im virtuellen Netzwerk (VNet) für das AzureFirewallSubnet aktivieren. Diese Endpunkte erweitern den privaten Adressraum und Ihres virtuellen Netzwerks die Identität über eine direkte Verbindung auf die Azure PaaS-Dienste. Wenn diese Option aktiviert ist, werden automatisch bestimmte Routen zu den entsprechenden-Diensten erstellt. Mithilfe von Dienstendpunkten können Sie Ihre kritischen Azure-Dienstressourcen auf Ihr VNet beschränken und so schützen. Der Datenverkehr aus Ihrem VNet an den Azure-Dienst verbleibt immer im Backbonenetzwerk von Microsoft Azure.
Beachten Sie, dass Sie bei dieser Konfiguration 0.0.0.0/0 nicht wie oben beschrieben als Präfix für private IP-Adressen hinzufügen können, Sie können jedoch trotzdem benutzerdefinierte Bereiche hinzufügen, für die kein SNAT verwendet werden sollen.
Schließlich ist es auch möglich, einen privaten Azure-Endpunkt zu verwenden, um eine private und sichere Verbindung mit öffentlichen PaaS herzustellen, die von Azure Private Link unterstützt werden. Diese Verbindungen umgehen jedoch ihre Standardroute zu Azure Firewall, wie in dieser Dokumentation beschrieben. Wenn Sie der gesamte Datenverkehr Ihre Firewall passieren muss, können Sie in allen Clientsubnetzen eine UDR mit der IP-Adresse des privaten Endpunkts und dem Suffix „/32“ als Ziel und Azure-Firewall als nächsten Hop hinzufügen. Hinweis: Damit diese Konfiguration funktioniert und der Antwortdatenverkehr von Ihrem privaten Endpunkt ebenfalls die Firewall passiert, müssen Sie als privaten IP-Adressbereich immer SNAT verwenden, indem Sie 255.255.255.255/32 angeben.
Abbildung 3: Eine UDR für einen privaten Speicherendpunkt, die auf die Firewall als nächsten Hop verweist
SQL-FQDN-Filterung ist jetzt allgemein verfügbar
Sie können jetzt SQL-FQDNs in Azure Firewall-Anwendungsregeln konfigurieren. So können Sie den Zugriff aus Ihrem VNet auf die angegebenen SQL Server-Instanzen beschränken. Sie können Datenverkehr von Ihren VNets zu einer Azure SQL-Datenbank, zu einem Azure SQL Data Warehouse, zu verwalteten Azure SQL-Instanzen oder zu in Ihren VNets bereitgestellten SQL-IaaS-Instanzen filtern.
Die SQL-FQDN-Filterung wird derzeit nur im Proxymodus unterstützt (Port 1433). Wenn Sie nicht standardmäßige Ports für SQL-IaaS-Datenverkehr (Infrastructure-as-a-Service) verwenden, können Sie diese Ports in den Firewallanwendungsregeln konfigurieren.
Wenn Sie SQL im Standardumleitungsmodus verwenden, können Sie trotzdem zur Filterung des Zugriffs das SQL-Diensttag im Rahmen von Netzwerkregeln verwenden. Die Unterstützung für Umleitungsmodi in Anwendungsregeln ist in Planung.
Abbildung 4: SQL-FQDN-Filterung in Azure Firewall-Anwendungsregeln
Erhöhung des Grenzwerts für mehrere öffentliche IP-Adressen
Sie können jetzt bis zu 250 öffentliche IP-Adressen für DNAT und SNAT mit Azure Firewall verwenden.
- DNAT: Sie können mehrere Standardportinstanzen auf Ihre Back-End-Server übersetzen. Wenn Sie beispielsweise über zwei öffentliche IP-Adressen verfügen, können Sie den TCP-Port 3389 (RDP) für beide IP-Adressen übersetzen.
- SNAT: Für ausgehende SNAT-Verbindungen stehen zusätzliche Ports zur Verfügung, was die Wahrscheinlichkeit einer Überlastung des SNAT-Ports verringert. Derzeit wählt Azure Firewall die öffentliche IP-Quelladresse für eine Verbindung nach dem Zufallsprinzip aus. Wenn Sie in Ihrem Netzwerk über eine nachgeschaltete Filterung verfügen, müssen Sie alle öffentlichen IP-Adressen zulassen, die Ihrer Firewall zugeordnet sind. Verwenden Sie ggf. ein Präfix für öffentliche IP-Adressen, um diese Konfiguration zu vereinfachen.
Weitere Informationen finden Sie unter Bereitstellen einer Azure Firewall mit mehreren öffentlichen IP-Adressen.
Nächste Schritte
Weitere Informationen zu den behandelten Themen finden Sie hier: