Firewallregeln brauchen zentrale Verwaltung? Erstelle eine Firewall Policy

Die CloudTrips-Firewall prüft bereits den ausgehenden Anwendungsverkehr, ihre Konfiguration gehört aber noch direkt zu dieser einen Firewall. Dieselben Regeln auf jeder Firewall separat zu wiederholen, würde Änderungen langsam und inkonsistent machen.

Verschiebe die Regeln in Azure Firewall Policy, eine separate Ressource, die zentral verwaltet und einer oder mehreren Azure Firewalls zugeordnet werden kann. Die Policy definiert, welcher Datenverkehr zugelassen oder verweigert wird; die Firewall bleibt der Dienst, der den Datenverkehr verarbeitet.

Dieser Trip baut auf Netzwerk braucht Firewall-Inspektion? Erstelle Azure Firewall auf. Behalte dessen Standard-Firewall, öffentliche IP, AzureFirewallSubnet, Standardroute, private Test-VM und Bastion-Verbindung. Wenn du sie gelöscht hast, wiederhole den Trip bis Default Deny überprüfen.

Der vorherige Test lieferte HTTP-Status 470, weil keine Regel www.microsoft.com erlaubte. Dieses Ergebnis ist die Ausgangsbasis für diesen Trip.

Migriere die Firewall zu einer Policy

Öffne afw-cloudtrips-test-weu. Wähle auf Overview die Option Migrate to firewall policy.

Die Migration erstellt aus der aktuellen klassischen Konfiguration eine Firewall Policy der Stufe Standard und ordnet sie der Firewall zu. Die vorhandene Firewall besitzt keine benutzerdefinierten Regeln. Die neue Policy beginnt deshalb mit demselben Default-Deny-Verhalten. Das Portal zeigt den erzeugten Policynamen; notiere ihn, denn diese Ressource wird im nächsten Schritt bearbeitet.

Wähle Review + create und danach Create. Warte, bis die Migration abgeschlossen ist und der Bereitstellungsstatus der Firewall wieder Succeeded lautet.

Das Regelmodell lautet:

Firewall Policy
└── Rule collection group
    └── Rule collection
        └── Rule

Eine Collection Group steuert die grobe Verarbeitungsreihenfolge. Eine Collection gruppiert Regeln mit einer Priorität und einer Aktion wie Allow. Eine einzelne Regel definiert Quelle, Protokoll, Port und Ziel.

Erlaube ein genehmigtes Webziel

Öffne über die Firewall-Übersicht die verknüpfte Firewall Policy. Wähle unter Settings > Rules die Optionen Application rules > Add a rule collection.

Application Rules prüfen HTTP- und HTTPS-Ziele anhand ihres Fully Qualified Domain Name (FQDN), beispielsweise www.microsoft.com. Konfiguriere:

Rule collection name: Allow-Approved-Web
Priority: 200
Rule collection action: Allow
Rule collection type: Application
Rule collection group: DefaultApplicationRuleCollectionGroup

Rule name: Allow-Microsoft-Web
Source type: IP address
Source: 10.20.1.0/24
Protocol:port: HTTP:80, HTTPS:443
Destination type: FQDN
Destination: www.microsoft.com

Falls das Portal bereits die Standardgruppe für Application Rules ausgewählt hat, behalte diese Auswahl. Wähle Add und warte, bis die Policyaktualisierung abgeschlossen ist.

Die Quelle ist der gesamte Adressbereich von snet-app und nicht nur die eine private IP der aktuellen VM. Eine Ersatz-VM im selben Subnetz erhält deshalb dieselbe ausgehende Regel. Datenverkehr ohne passende Allow-Regel bleibt verweigert.

Weise Allow und Default Deny nach

Starte vm-cloudtrips-bastion-test-weu, falls sie freigegeben ist. Verbinde dich über Connect > Bastion und führe aus:

curl --connect-timeout 10 -I http://www.microsoft.com
curl --connect-timeout 10 -I http://www.google.com

Die Microsoft-Anfrage sollte jetzt eine normale Webantwort wie 200, 301 oder 302 liefern, weil die Application Rule ihren FQDN erlaubt. Die Google-Anfrage sollte die Firewall-Blockantwort HTTP/1.1 470 status code 470 zurückgeben, weil keine Regel dieses Ziel erlaubt.

Die Route bestimmt weiterhin, wohin der Datenverkehr gesendet wird. Die zentral verwaltete Firewall Policy bestimmt jetzt, was passieren darf. Eine Änderung dieser Policy aktualisiert jede zugeordnete Firewall, statt dieselbe Regel auf jeder Firewall separat zu ändern.

Fortfahren oder bereinigen

Die nächsten Trips konfigurieren Firewall DNAT, führen das Upgrade für Premium TLS Inspection durch und aktivieren IDPS. Wenn du damit fortfährst, lösche das Lab nicht. Gib die VM zwischen den Tests frei, aber behalte:

afw-cloudtrips-test-weu
Die zugeordnete Firewall Policy
pip-cloudtrips-afw-test-weu
AzureFirewallSubnet
rt-cloudtrips-app-test-weu und Default-To-Azure-Firewall
vnet-cloudtrips-test-weu und snet-app
Bastion
Test-VM, NIC und Datenträger

Starte die VM erneut, wenn ein späterer Trip sie benötigt. Azure Firewall bleibt während der Bereitstellung kostenpflichtig. Führe die drei Firewall-Trips daher nach Möglichkeit in derselben Lab-Sitzung aus.

Wenn du die Firewall-Labs beendest, lösche zuerst Default-To-Azure-Firewall aus rt-cloudtrips-app-test-weu. Lösche danach diese Ressourcen:

afw-cloudtrips-test-weu
Die auf der Firewall-Übersicht angezeigte Firewall Policy
pip-cloudtrips-afw-test-weu
AzureFirewallSubnet
vm-cloudtrips-bastion-test-weu und Datenträger/NIC

Das vorherige Löschen der Standardroute verhindert, dass snet-app einen Next Hop behält, der nicht mehr existiert. Behalte VNet, Anwendungssubnetz, NSG und Routentabelle für spätere Networking-Trips.