Richtlinien für Firewallregeln und IP groups¶

Das Runbook Firewallregeln erklärt, wie du eine Regel hinzufügst, änderst oder entfernst: die Dateien, das JSON und die pipeline. Diese Seite erklärt, wie du Regeln und IP groups entwirfst, damit die Konfiguration lesbar bleibt, innerhalb der Azure-Limits bleibt und von mehr als einem Team bearbeitet werden kann.

Firewallregeln sind Code. Erstelle oder ändere keine Regeln im Portal: Das nächste Deployment der firewall policy überschreibt alles, was nicht über das Konfigurations-Repository gemacht wurde.

Die Struktur der Dateien und die Prüfungen der config tests sind von der Plattform vorgegeben. Die Namens- und Nummerierungsschemata auf dieser Seite sind Konventionen. Zwei Kundenplattformen verwenden unterschiedliche. Wähle ein Schema für deine Plattform, schreibe es auf und wende es konsequent an. Wo diese Seite Zahlen nennt, sind sie Beispiele.

Wie Azure Firewall Regeln organisiert¶

Eine firewall policy enthält rule collection groups (RCG). Eine RCG enthält rule collections. Eine rule collection enthält Regeln.

Ebene	Was es ist	Priorität
Rule collection group	Die erste Einheit, die die firewall verarbeitet. Eine JSON-Datei im Konfigurations-Repository.	100 (wird zuerst verarbeitet) bis 65000. Muss in der policy eindeutig sein.
Rule collection	Hat einen Typ (DNAT, Network oder Application) und eine Aktion (`Allow` oder `Deny`).	Eindeutig innerhalb ihrer RCG.
Regel	Passt auf Quelle, Ziel, Port und Protokoll.	Keine Priorität.

Die firewall verweigert alles, was keine Regel erlaubt. Verwende Allow in fast jeder Collection. Verwende Deny nur für bestimmte Security-Anforderungen.

Verarbeitungsreihenfolge. Azure Firewall verarbeitet die RCGs in der Reihenfolge ihrer Priorität, die niedrigste Zahl zuerst. Innerhalb einer RCG verarbeitet sie zuerst die DNAT-Collections, dann die Network-Collections, dann die Application-Collections, jeweils nach Collection-Priorität. Deshalb verlangt der config test, dass die niedrigste NAT-Priorität niedriger ist als die niedrigste Network-Priorität und diese niedriger als die niedrigste Application-Priorität. Siehe die Regelverarbeitungslogik von Microsoft.

Regeltypen:

Typ	Verwende ihn für
DNAT	Eingehenden Verkehr zu einer öffentlichen IP der firewall, übersetzt auf eine private Adresse. Siehe DNAT-Regeln.
Network	Layer 3 und 4: IP-Adressen, Ports, Protokolle. Eingehend, ausgehend und Verkehr zwischen Spokes.
Application	Layer 7: FQDNs und die Protokolle HTTP, HTTPS oder SQL, hauptsächlich für ausgehenden Verkehr.

Network-Regeln brauchen weniger Ressourcen als Application-Regeln. Verwende eine Network-Regel, wenn du kein FQDN-Matching brauchst.

Welcher Typ? Verwende eine Application-Regel, wenn die Anfrage nur HTTP- (80), HTTPS- (443) oder SQL-Verkehr enthält und das Ziel ein FQDN ist. Verwende in jedem anderen Fall eine Network-Regel. Das Runbook hat die Checkliste: Application- oder Network-Regel.

Lass Regeln sich nicht überlappen. Der erste Treffer entscheidet, und ein Deny, das zuerst greift, verdeckt das Allow, das danach kommt. Eine Network- Regel, die HTTPS zu einem FQDN verweigert, gewinnt gegen eine Application-Regel, die denselben FQDN erlaubt, wenn sie zuerst verarbeitet wird. Prüfe neue Regeln gegen bestehende, besonders über Collection-Groups hinweg.

Azure-Limits, auf die du auslegen musst¶

Diese Limits gelten zum Zeitpunkt des Schreibens für eine firewall policy. Prüfe Microsofts Azure-Firewall-Limits für die aktuellen Zahlen.

Limit	Wert
Rule collection groups pro policy	90
Größe einer rule collection group	2 MB
Eindeutige IP groups pro policy	600
Adressen oder Präfixe in einer IP group	5.000

Plane mit diesen Werten. Eine große Plattform mit vielen Workloads kann 90 RCGs erreichen. Erstelle keine RCG nur, um Regeln optisch zu ordnen. Verwende dafür rule collections.

Wann du eine neue rule collection group anlegst¶

Lege eine separate RCG an, wenn:

die Regeln eine andere Prioritätsstufe brauchen (Plattformregeln, Produktions-Workloads, Nicht-Produktions-Workloads);
ein anderes Team sie verantwortet, sodass jedes Team in seiner eigenen Datei arbeitet;
sie einen anderen Lebenszyklus haben, zum Beispiel temporäre Regeln für ein Projekt;
eine logische Trennung nötig ist, zum Beispiel eine Security-Zone oder eine Compliance-Grenze;
die RCG nahe an die 2-MB-Grenze kommt.

Lege keine neue RCG an, wenn die Regeln in eine bestehende Collection passen, wenn eine Collection-Priorität genügt oder wenn die Plattform bereits nahe an 90 RCGs ist.

Die Konfiguration um Workloads herum organisieren¶

Organisiere Regeln pro Workload, nicht pro Technologie. Eine rule collection group namens AllowDatabase vermischt den Verkehr vieler Workloads. Niemand weiß, welche Regel zu welchem Workload gehört, Regeln widersprechen sich oder wiederholen sich, und niemand kann sagen, was entfernt werden muss, wenn ein Workload außer Betrieb genommen wird. Eine RCG-Datei pro Workload (oder pro Workload und Umgebungstyp) löst das.

Ein typisches Layout innerhalb von firewall_rule_configuration/ (Unterordner sind erlaubt, siehe Firewallregeln):

firewall_rule_configuration/
├── 0.platform/        Rules the platform team manages: DNS, updates, monitoring, managed VMs
├── 1.global/          Rules of the customer that apply to every workload
├── <workload-a>/      One folder per workload
│   ├── <workload-a>-prod.json
│   └── <workload-a>-non-prod.json
└── <workload-b>/

Einige Hinweise zu diesem Layout:

Globale und regionale Dateien. Lege eine Regel im globalen Ordner ab, wenn sie für jede Region gilt, zum Beispiel DNS: Es muss überall funktionieren. Lege sie nur dann in einem Regionsordner ab, wenn es einen echten regionalen Grund gibt, etwa Failover oder Anforderungen an den Datenstandort, oder wenn sie zwei Spokes in einer Region verbindet. Eine regionale Datei mit demselben Namen wie eine globale Datei ersetzt diese in dieser Region. Halte Regeln über Regionen hinweg konsistent, wenn die Regionen sich gegenseitig absichern.
Produktion und Nicht-Produktion getrennt. Verwende getrennte RCGs (oder mindestens getrennte Collections) für den Produktions- und Nicht-Produktions-Verkehr eines Workloads, damit Produktionsdaten nicht versehentlich in eine Nicht-Produktions-Umgebung fließen können. Erlaube keinen Verkehr zwischen beiden.
Intern und Internet getrennt. Halte interne Regeln und Internet-Regeln in getrennten Collections. Internetverkehr ist die höhere Bedrohung und verdient eine eigene Prüfung.
Keine Regel für eine einzelne Quelle aufweiten. Wenn nur eine von mehreren Quell-IP-groups Zugriff auf ein Ziel braucht, füge das Ziel nicht zur bestehenden Regel oder Collection hinzu: Das öffnet es auch für die anderen Gruppen. Lege eine separate Regel an.
Ein Owner pro Datei. Das Team, dem der Workload gehört, besitzt die Datei. Bei Verkehr zwischen zwei Workloads steht die Regel in der Datei des Ziel-Workloads (wer welche Regel anfragt).

Prioritäten¶

Azure verlangt pro policy eine eindeutige RCG-Priorität. Der config test prüft die Eindeutigkeit nur innerhalb eines firewall_rule_configuration-Ordners, prüfe also globale Dateien gegen regionale Dateien selbst. Verwende nicht 8999: Die Plattform nutzt diese Priorität für die RCG der Deployment-Agents, wenn deployment_agents_private_network_range gesetzt ist.

Gib jedem Owner einen Bereich, damit Teams nicht kollidieren und Prioritäten zeigen, wofür eine Regel da ist. Lass Lücken (zum Beispiel in Zehnerschritten), damit du später Regeln einfügen kannst.

Beispiel für ein Prioritätsschema

Das ist ein Beispiel. Passe es an und dokumentiere dein eigenes.

Zweck	RCG-Prioritätsbereich
Vom Plattform-Team verwaltete Regeln	1000-1099
Globale Regeln des Kunden	1100-1199
Produktions-Workloads	2000-2999
Nicht-Produktions-Workloads	3000-5999
Reserviert	6000-9999

Innerhalb der Produktions- und Nicht-Produktionsbereiche erhält jeder Workload einen eigenen Unterbereich (zum Beispiel 20 Nummern). Der Produktionsbereich und der Nicht-Produktionsbereich eines Workloads verwenden denselben Offset (2100-2119 und 3100-3119), sodass die Paare leicht zu finden sind.

Collection-Prioritäten müssen nur innerhalb der RCG eindeutig sein und können sich in anderen RCGs wiederholen. Behalte in jeder Datei denselben Abstand bei.

Namensgebung¶

Namen sind Bezeichner in Azure und Terraform-Keys. Wähle Namen, die sagen, wessen Regel es ist und was sie erlaubt. Verwende nur Kleinbuchstaben, Zahlen und Bindestriche (oder Unterstriche), halte sie kurz und vermeide Namen wie rule1, misc, temp-all oder allow-all. Der config test akzeptiert für Collection- und Regelnamen das Muster ^[a-zA-Z0-9][a-zA-Z0-9._-]*[a-zA-Z0-9_]$.

Objekt	Muster (Beispiel)	Beispiele
RCG	`<workload>-<project or service>-<environment type>`. Plattformeigen: `<owner>-global-<description>`.	`app1-prod`, `app1-reporting-non-prod`, `platform-global-dns`
Rule collection	Ein fester Name pro Typ oder ein Name, der Typ und Umgebung zeigt	`NetworkRules`, `ApplicationRules`
Regel	`<source>-to-<destination>`, mit zusätzlichem Detail, wenn nötig	`app1-vm-to-servicebus`, `appgw-to-app1-web`, `onprem-sql-to-app1-sql`
IP group	`ipgrp-<description>` (global), `ipgrp-<workload>-<description>-<environment>` (Workload). Eine Alternative, die zeigt, wo die Adressen liegen: `ipgrp-<onprem or azure>-<workload>-<environment>-<use>`.	`ipgrp-hub`, `ipgrp-app1-web-prod`, `ipgrp-onprem-dns`

Der RCG-Name muss über alle Dateien einer Region eindeutig sein, denn er ist der Azure-Name und der Terraform-Key. Das Umbenennen einer RCG zerstört sie und erstellt sie neu (siehe Eine bestehende Regel ändern oder entfernen).

Regeln gut entwerfen¶

Verwende das spezifischste Ziel. In der Reihenfolge der Präferenz: ein FQDN, eine einzelne IP-Adresse, eine IP group, ein Subnet. Bevorzuge den engsten Scope, der funktioniert.
Internet-Ziele als FQDNs, nicht als IP-Adressen. Öffentliche Dienste (Updates des Betriebssystems, APIs von Herstellern) und Anwendungen von Drittanbietern können ihre Adresse ändern. Eine Regel auf einer Adresse greift dann ohne Warnung nicht mehr. Ein FQDN oder ein FQDN-Tag funktioniert weiter.
Verwende IP groups für Adressmengen, die mehr als eine Regel nutzt oder die sich häufig ändern (siehe unten).
Verwende Service Tags für Azure-Dienste in Network-Regeln (zum Beispiel AzureBackup, AzureMonitor). Microsoft pflegt die Adressbereiche, und das performt besser als FQDNs.
Verwende FQDN-Tags für Microsoft-Dienste in Application-Regeln (zum Beispiel WindowsUpdate). Die Liste der unterstützten Werte steht im Runbook Firewallregeln.
Ein Quelltyp und ein Zieltyp pro Regel. Verwende entweder source_addresses oder source_ip_groups und entweder destination_addresses, destination_ip_groups oder destination_fqdns. Teile in zwei Regeln auf, wenn du beides brauchst. Der config test erzwingt das.
Konsolidieren. Fasse Regeln mit derselben Quelle, demselben Ziel und derselben Aktion zusammen und liste mehrere Ports in einer Regel (["80", "443"]), statt pro Port eine Regel anzulegen.
Least Privilege. Nenne die genauen Ports und Protokolle. Vermeide * als Quelle oder Ziel und vermeide das Protokoll Any. Verwende Wildcard-FQDNs (*.example.com) mit Bedacht.
Standardmäßig verschlüsselte Protokolle. Viele Organisationen erlauben nur verschlüsselte Protokolle und verlangen für unverschlüsselte eine zusätzliche Genehmigung.
Entferne, was nicht mehr genutzt wird. Azure Firewall Policy Analytics hilft, ungenutzte Regeln zu finden und die Reihenfolge der Regeln zu optimieren.

Eine explizite Deny-Regel¶

Füge eine Deny-Collection nur für eine bestimmte Security-Anforderung hinzu, zum Beispiel um ein sensibles Subnet vom Internet zu blockieren. Gib der Deny-Collection eine niedrigere Prioritätszahl als die Allow-Regeln, die sie überschreiben muss, lege sie in einer plattformeigenen RCG ab und sorge dafür, dass diese Regel von Security geprüft wird.

IP groups¶

Eine IP group ist eine benannte Menge von Adressen und Bereichen. Regeln verweisen über den Namen darauf. Das Runbook mit den Schritten und dem JSON ist IP groups. Ändert sich ein Subnet, aktualisierst du eine Datei, und jede Regel, die die Gruppe nutzt, folgt. Der Name sagt dem Leser außerdem, was die Adressen sind, und es ist leicht zu sehen, welche Netzwerke eine Regel öffnet.

Wann du eine IP group verwendest¶

Mehrere Regeln nutzen dieselbe Adressmenge.
Die Adressen sind gemeinsame Infrastruktur, auf die viele Workloads verweisen (hub-Netzwerke, Identity-Server, Management- Netzwerke, das Subnet des Application Gateways).
Die Adressen ändern sich regelmäßig.
Die Menge hat einen logischen Zweck (die Workstations eines Workloads in der Produktion, die Databricks-Subnets eines Workloads).
Es ist ein Workload oder Spoke. Eine gute Gewohnheit ist, jedem neuen Spoke von Anfang an eine IP group für seinen Adressbereich zu geben, damit spätere Regeln darauf verweisen können. Prüfe, bevor du eine neue Regel hinzufügst, ob eine bestehende Regel mit demselben Zweck die neue Adresse über die Gruppe bekommen kann.

Wann du keine IP group verwendest¶

Die Adressen werden von nur einer Regel genutzt. Lege sie inline ab.
Die Regel ist temporär oder ein einmaliger Test.
Das Regelwerk ist sehr klein.
Die Adressen haben nichts miteinander zu tun. Mische keine unzusammenhängenden Subnets in einer Gruppe.

Wo die Dateien liegen und wie sie aussehen¶

IP-group-Dateien liegen in ip_groups/ (siehe Firewallregeln). Eine Datei enthält eine IP group. Verwende dieselbe Ordnerstruktur wie für die Regeln: globale Gruppen in einem Plattform- oder globalen Ordner, Workload-Gruppen in einem Ordner pro Workload, und der Dateiname entspricht dem Gruppennamen. Eine Gruppe, die der Namenskonvention nicht folgt, kann in einem separaten Ordner „uncategorized“ warten, bis sie umbenannt ist.

{
  "ip_group": {
    "name": "ipgrp-app1-web-prod",
    "cidrs": ["10.20.4.0/26"]
  }
}

Schreibe einen einzelnen Host als /32. Das Schema akzeptiert eine einfache IPv4-Adresse und eine Adresse mit Präfixlänge von /0 bis /32. Verwende innerhalb einer Gruppe einen Stil und validiere die Datei (JSON-Dateien mit Schema-Unterstützung bearbeiten).

Eine IP group in zwei Schritten umbenennen oder entfernen¶

Eine Regel, die auf eine nicht mehr existierende Gruppe verweist, lässt das Deployment fehlschlagen. Benenne eine Gruppe nie in derselben Änderung um oder entferne sie, in der du die Regeln aktualisierst.

Umbenennen:

Füge eine neue Datei mit dem neuen Namen und denselben Adressen hinzu. Aktualisiere jede Regel auf den neuen Namen. Deploye.
Ist das in jeder Umgebung deployt, lösche die alte Datei. Deploye erneut.

Entfernen:

Entferne alle Verweise aus den Regeln. Deploye.
Lösche die Datei. Deploye erneut.

Firewall-Änderungen sicher durchführen¶

Eine RCG-Änderung pro pull request. Ein Update der firewall policy dauert mehrere Minuten, und Azure unterstützt keine parallelen Updates derselben policy. Kleine pull requests lassen sich leichter prüfen, anwenden und zurückrollen.
Hinzufügen, verifizieren, entfernen. Ersetzt eine Regel eine andere, füge zuerst die neue Regel hinzu, prüfe, dass der Verkehr funktioniert, und entferne die alte Regel in einem separaten pull request. Entferne nie eine Regel, bevor ihr Ersatz bestätigt ist. Hinzufügen und Entfernen in einem pull request zu kombinieren kann einen Ausfall verursachen.
Ändere jeden Umgebungsordner, der es braucht. Die Ordner canary und prod sind getrennt. Mache dieselbe Änderung in beiden (zuerst canary), es sei denn, die Regel gilt nur für einen.
Führe die config tests aus, bevor du pushst (Die Tests lokal ausführen).
Prüfe den Plan. Nur der layer firewall sollte Änderungen zeigen, und nur für die RCG, die du angefasst hast.

Wenn eine große Änderung in ein Time-out läuft¶

Mehrere rule collection groups in einer Änderung können länger dauern als das Apply-Time-out, weil Azure die Updates in eine Warteschlange stellt. Wird der Lauf abgebrochen, existieren manche Collections möglicherweise in Azure, aber nicht im Terraform state. Der nächste Lauf schlägt dann fehl, weil die Ressource bereits existiert.

Zerstöre und erstelle Produktionsregeln nicht neu, um eine state-Abweichung zu beheben

Das Zerstören der bereits vorhandenen Collections unterbricht den Verkehr, solange die Reparatur dauert. Verwende terraform import für die Ressourcen, die in Azure existieren, aber nicht im state. Besser noch, verhindere es: Zeigt ein canary-Lauf bereits Time-outs, mache nicht mit der Produktion weiter. Teile die Änderung in kleinere pull requests auf und wende neue Regeln an, bevor du die Regeln entfernst, die sie ersetzen.

Die firewall-Logs lesen¶

Die Diagnose der firewall kann Logs an einen Log-Analytics-Workspace senden. Die Tabellen, die du am häufigsten nutzt, sind:

Tabelle	Inhalt
`AZFWApplicationRule`	Treffer von Application-Regeln
`AZFWNetworkRule`	Treffer von Network-Regeln
`AZFWNatRule`	Treffer von DNAT-Regeln
`AZFWDnsQuery`	DNS-Anfragen, die der DNS-Proxy verarbeitet
`AZFWFlowTrace`, `AZFWFatFlow`	Flow Traces und die größten Flows
`AZFWIdpsSignature`	Signaturen der Intrusion Detection (Premium)

Es gibt außerdem Aggregationstabellen (AZFWApplicationRuleAggregation, AZFWNetworkRuleAggregation, AZFWNatRuleAggregation). Gib den Personen, die Regeln troubleshooten, Lesezugriff auf diese Tabellen und auf die firewall- Ressource, nicht auf den ganzen Workspace. Prüfe, welche Tabellen deine Diagnoseeinstellungen füllen.