Firewallregeln (hinzufügen, ändern, entfernen)¶

Standardänderungen: Neue Firewallregeln hinzufügen und Firewallregeln ändern in den zentralen Azure Firewall(s).

Auswirkung: rule collection groups und IP groups in der Hub-Firewall-Policy jeder Region werden erstellt, aktualisiert oder gelöscht. Nur der firewall layer ändert sich. Traffic wird erlaubt oder abgelehnt, sobald das Apply abgeschlossen ist.

Zu Benennung, Prioritätsbereichen, Regeleigentum und der Praxis mit IP groups siehe die Richtlinien für Firewallregeln und IP groups. Für die Prüfung eines pull requests siehe Prüfung von pull requests und die Runbooks Eine Anfrage für eine Firewallregel bearbeiten, Review eines pull requests für Firewallregeln und Deployment von Firewallregeln. IP groups haben ein eigenes Runbook: IP groups. Workload-Teams, die den pull request selbst vorbereiten, beginnen mit Firewallregeln und IP groups für Workload-Teams.

Anfragefelder¶

Anfragefeld	Wo es hingehört	Hinweise
Workload Name	Namen von rule collection group / collection / rule	Verwende ihn in den Namen, damit Regeln nachvollziehbar bleiben, z. B. RCG `App1`, Regel `Allow-App1-Sql`.
Spoke	pull request-Beschreibung	Der Spoke, für den die Regel gedacht ist. Hilft, den Source-Bereich und den Eigentümer zu finden.
Begründung	pull request / Change-Eintrag
Beschreibung und Integration	pull request-Beschreibung	Wofür die Regel verwendet wird und mit welchen anderen Workloads oder On-Premises-Systemen sie verbindet.
Regelname	Regel-Key in der `rules`-Map	Benenne die Regel so, dass der Verkehr klar ist, z. B. `app1-vm-to-servicebus`.
Regeltyp (application oder network)	in welche Collection-Map die Regel gehört	Wenn der Anfragende es nicht weiß, entscheide mit der Checkliste unten.
Umgebung	Plattformumgebung (`canary` / `prod`) und Region-Ordner
Source IP	`source_addresses` (IPs/CIDRs) oder `source_ip_groups` (IP-group-Namen)	Nur ein Source-Typ pro Regel (Konfigurationstest).
Source FQDN	nicht unterstützt	Azure-Firewall-Regeln in dieser Konfiguration können nicht auf einen Source-FQDN matchen. Frage stattdessen nach dem Source-IP-Bereich oder einer IP group.
Destination IP	Network rule: `destination_addresses` (IP/CIDR/Service Tag) oder `destination_ip_groups`	Ein Destination-Typ pro Regel.
Destination FQDN	Network rule `destination_fqdns` oder Application rule `destination_fqdns`	Verwende für HTTP/HTTPS/MSSQL eine Application rule. Network rules mit FQDNs benötigen DNS proxy in der Firewall-Policy (`firewall_policy_dns.proxy_enabled`).
Protocol	Network: `TCP`, `UDP`, `ICMP`, `Any`. Application: `Http:<port>`, `Https:<port>`, `Mssql:<port>`
Port	Network: `destination_ports`. Application: Teil von `protocols`
Kommentare

Wo die Dateien liegen¶

Die Speicherorte werden in <env-folder>/<region>/firewall.auto.tfvars festgelegt:

firewall_rule_collection_global_file_location = "firewall_rule_configuration"            # all regions
firewall_rule_collection_file_location        = "weu/firewall_rule_configuration"        # this region
firewall_rule_collection_file_filter          = "/**/*.json"

ip_group_global_json_file_relative_path = "ip_groups/"        # optional, all regions
ip_group_json_file_relative_path        = "weu/ip_groups/"    # this region
ip_group_json_file_pattern              = "/**/*.json"

use_new_fwp_rulecollectiongroup_naming         = true
use_multiregion_fwp_rulecollectiongroup_naming = true
use_new_ip_group_naming                        = true

Pfade sind relativ zum <env-folder> (siehe Wie relative Pfade in tfvars aufgelöst werden). Unterordner sind erlaubt (/**/*.json), zum Beispiel weu/firewall_rule_configuration/0.Platform/.

Globale und regionale Dateien (infra/deploy/firewall/locals.tf, nur wenn use_multiregion_fwp_rulecollectiongroup_naming = true):

Jede Region deployt ihre regionalen Dateien plus die globalen Dateien.
Eine regionale Datei mit demselben Dateinamen wie eine globale Datei ersetzt die globale in dieser Region.

IP groups folgen derselben Merge-Regel, sobald ip_group_global_json_file_relative_path gesetzt ist, unabhängig vom Wert des Naming-Flags.

Behalte die Ordnernamen firewall_rule_configuration und ip_groups bei. Die Konfigurationstests finden Regeldateien und IP groups anhand dieser Ordnernamen.

JSON der rule collection group¶

Eine Datei ist eine rule collection group (RCG). Alle drei Collection-Maps müssen vorhanden sein. Verwende {}, wenn eine Map leer ist.

{
  "rule_collection_group": {
    "name": "App1",
    "priority": 400,
    "nat_rule_collections": {},
    "network_rule_collections": {
      "App1-Network": {
        "priority": 410,
        "action": "Allow",
        "rules": {
          "Allow-App1-to-Sql": {
            "protocols": ["TCP"],
            "source_addresses": [],
            "source_ip_groups": ["ipgrp-app1"],
            "destination_addresses": [],
            "destination_ip_groups": ["ipgrp-sql-servers"],
            "destination_fqdns": [],
            "destination_ports": ["1433"]
          }
        }
      }
    },
    "application_rule_collections": {
      "App1-Application": {
        "priority": 420,
        "action": "Allow",
        "rules": {
          "Allow-App1-to-Vendor-Api": {
            "protocols": ["Https:443"],
            "source_addresses": [],
            "source_ip_groups": ["ipgrp-app1"],
            "destination_fqdns": ["api.vendor.example"],
            "destination_fqdn_tags": []
          }
        }
      }
    }
  }
}

Jeder Key im Beispiel ist erforderlich, auch wenn er ein leeres Array ist. Das Terraform-Modul liest jeden Key direkt (infra/modules/rule_collection_group/main.tf). Das Schema ist src/Xebia.Mcp/Files/json/firewallschema.json.

Ebene	Feld	Regeln
RCG	`name`	Eindeutig über alle Dateien, die in die Region deployt werden (global + regional). Er ist der Azure-Name und der Terraform-Key.
RCG	`priority`	100–65000 (Azure) und eindeutig pro `firewall_rule_configuration`-Ordner (Konfigurationstest). Halte sie auch zwischen dem globalen und dem regionalen Satz eindeutig. Verwende nicht `8999`: Die Plattform erstellt die RCG `rcg-platform-agent-…` mit dieser Priorität, wenn `deployment_agents_private_network_range` gesetzt ist.
Collection	Map-Key	Der Name der Collection. Muster `^[a-zA-Z0-9][a-zA-Z0-9._-]*[a-zA-Z0-9_]$`.
Collection	`priority`	In einer RCG gilt: niedrigste NAT-Priorität < niedrigste Network-Priorität < niedrigste Application-Priorität (Konfigurationstest).
Collection	`action`	Network/Application: `Allow` oder `Deny`. NAT: `Dnat`.
Regel	Map-Key	Der Name der Regel, gleiches Muster.
Network rule	`protocols`, `source_addresses`, `source_ip_groups`, `destination_addresses`, `destination_ip_groups`, `destination_fqdns`, `destination_ports`	Ein Source-Typ und ein Destination-Typ pro Regel.
Application rule	`protocols`, `source_addresses`, `source_ip_groups`, `destination_fqdns`, `destination_fqdn_tags`	Werte für `destination_fqdn_tags`: `AppServiceEnvironment`, `AzureBackup`, `AzureKubernetesService`, `HDInsight`, `MicrosoftActiveProtectionService`, `WindowsDiagnostics`, `WindowsUpdate`, `WindowsVirtualDesktop`, `Internet`. Target URLs, Web Categories und TLS Inspection werden vom Modul nicht unterstützt.
NAT rule	`protocols`, `destination_address`, `destination_ports`, `source_addresses`, `source_ip_groups`, `translated_address`, `translated_fqdn`, `translated_port`	Füge `translated_fqdn` ein (darf `null` sein).

IP-group-Referenzen (source_ip_groups, destination_ip_groups): Verwende den Namen der IP group. Terraform löst auch eine vollständige Ressourcen-ID Microsoft.Network/ipGroups auf, aber der Konfigurationstest der Pipeline akzeptiert nur Namen, die in einem ip_groups-Ordner definiert sind, sodass eine Ressourcen-ID den Lauf fehlschlagen lässt. Die Terraform-check-Blöcke für unbekannte Referenzen erzeugen nur Warnungen, daher ist der Konfigurationstest deine eigentliche Absicherung.

JSON der IP group¶

Das vollständige Runbook für IP groups mit Benennung und Validierung ist IP groups.

{
  "ip_group": {
    "name": "ipgrp-app1",
    "cidrs": ["10.20.4.0/24"]
  }
}

name muss in der Umgebung eindeutig sein. Er ist der Azure-Name und die Referenz, die in Regeln verwendet wird.
IP groups werden in der Connectivity-resource group rg-<company>-connectivity-<env>-<region>-001 erstellt.

Application oder network rule¶

Wenn die Anfrage nicht sagt, welchen Regeltyp du verwenden sollst, beantworte zwei Fragen:

Enthält die Anfrage nur die Ports 80 (HTTP) und 443 (HTTPS) oder 1433 über das Protokoll Mssql?
Ist das Ziel ein FQDN (oder ein FQDN tag)?

Wenn beide Antworten ja sind, verwende eine application rule. Andernfalls verwende eine network rule. Die Gründe erklärt der Abschnitt Regeltyp und Ziel wählen. In einer application rule hat protocols die Form Http:<port>, Https:<port> oder Mssql:<port>.

Global oder regional¶

Eine globale Regel ist in jeder Region und jedem hub aktiv. Eine regionale Regel nur in einer Region. Entscheide nach dem Inhalt:

DNS-Regeln sollen überall funktionieren: global.
Eine Regel zwischen zwei Spokes in einer einzelnen Region: regional.
Wenn Regionen sich gegenseitig absichern, halte die Regeln beider Regionen gleich.

Wenn du dich nicht entscheiden kannst, frag den Verantwortlichen für das Plattform-Design. Eine Regel im falschen Ordner fehlt entweder in einer Region oder ist in einer Region offen, die sie nicht braucht.

Regel hinzufügen¶

Erfasse die Anfragefelder. Bevorzuge IP groups gegenüber literalen Adressen. Sie sind wiederverwendbar und halten Regeln lesbar.
Erstelle oder erweitere bei Bedarf eine IP-group-Datei in <region>/ip_groups/ (oder im globalen ip_groups/).
Füge entweder eine Regel zu einer bestehenden Collection in der RCG-Datei des zuständigen Workloads hinzu oder erstelle eine neue RCG-Datei mit einer unbenutzten Priorität. Bei Verkehr zwischen zwei Workloads ist der Eigentümer der Ziel-Workload (wer welche Regel beantragt).
Führe dieselbe Änderung im Ordner jeder Plattform-Umgebung durch, die sie bekommen soll (canary und prod sind getrennte Ordner), und wende sie zuerst auf canary an.
Validiere lokal (pwsh ./dev/dev.ps1 -Action Test mit MCP_CONFIG, das auf deine mcp.json zeigt, siehe Tests lokal ausführen) und öffne dann einen pull request.
Führe hub aus. Nur der firewall layer sollte Änderungen zeigen: azurerm_firewall_policy_rule_collection_group und/oder azurerm_ip_group hinzugefügt oder aktualisiert.
Apply. Der firewall layer wird mit -parallelism=1 angewendet (ADR-0009), große Änderungen dauern daher mehrere Minuten. Beschränke jeden pull request auf eine rule collection group, damit eine Änderung klein genug bleibt, um sie anzuwenden und zurückzurollen (siehe Wenn eine große Änderung in ein Timeout läuft).

Bestehende Regel ändern oder entfernen¶

Ändern: Bearbeite die Regel direkt. Die RCG wird in place aktualisiert. Azure ersetzt ihren gesamten Regelsatz in einer Operation.
Regel entfernen: Lösche den Regel-Key aus der rules-Map.
Ganze RCG entfernen: Lösche die Datei. Der Plan zeigt, dass die RCG zerstört wird.
RCG umbenennen (name): Das ist ein destroy + create, weil der Name der Terraform-Key ist. Für einen Moment ist keine Regel dieser Gruppe aktiv.

DNAT-Regeln für eingehenden Verkehr¶

Eine DNAT-Regel lässt einen Client aus dem Internet ein privates Ziel über eine öffentliche IP-Adresse der firewall erreichen. Die firewall übersetzt Zieladresse und Port. Verwende sie nur für spezielle Fälle und mit einer kurzen Liste von Quelladressen. Ein typischer Fall ist eine externe Partei, die Dateien per SFTP in ein Storage Account hochladen muss, das nur einen private endpoint hat (siehe die Nutzer-Seite Eingehendes SFTP zu einem Storage Account).

Das Muster ist:

client -> <firewall public IP> : <custom port> -> DNAT -> <storage account FQDN> : 22

Lege die DNAT-Collection in die Map nat_rule_collections einer RCG. Ihre Action ist Dnat.

{
  "rule_collection_group": {
    "name": "sftp-inbound",
    "priority": 200,
    "nat_rule_collections": {
      "AllowSftpNatToStorage": {
        "priority": 110,
        "action": "Dnat",
        "rules": {
          "AllowSftpNatToApp1Prd": {
            "protocols": ["TCP"],
            "source_addresses": ["203.0.113.10"],
            "source_ip_groups": [],
            "destination_address": "<firewall public IP>",
            "destination_ports": ["<custom port>"],
            "translated_address": null,
            "translated_port": "22",
            "translated_fqdn": "<storage account>.blob.core.windows.net"
          }
        }
      }
    },
    "network_rule_collections": {},
    "application_rule_collections": {}
  }
}

source_addresses oder source_ip_groups: die externe Partei, die die Sitzung startet. Verwende feste, spezifische Adressen.
destination_address: die öffentliche IP-Adresse der firewall, mit der sich die Partei verbindet. Jede Region hat ihre eigene firewall und ihre eigene öffentliche IP-Adresse, wähle also die Region und verwende diese Adresse.
destination_ports: ein eindeutiger eigener Port für dieses Ziel, niemals 22. Führe ein Register der vergebenen Ports, damit zwei Storage Accounts nie denselben Port bekommen.
translated_fqdn und translated_port: der FQDN des private endpoints und der Port, an den die firewall weiterleitet. translated_address ist null, wenn du den FQDN verwendest.

Füge die Regel in jedem Ordner einer Plattform-Umgebung hinzu, der sie haben soll, und prüfe sie mit der Security. Die Regel ist dem Internet ausgesetzt, setze daher auch ein Review-Datum und entferne sie, wenn der Austausch endet. Die firewall-Logs zeigen DNAT-Treffer in AZFWNatRule.

Prüfen¶

Azure portal → Firewall Policies → afwp-<company>-connectivity-<env>-<region>-001 → Rule collections: Die RCG, Collection und Regel sind vorhanden.
Teste den Datenfluss von der Quelle aus, zum Beispiel mit Test-NetConnection <dest> -Port <port> oder curl.
Firewall-Logs: Frage im Log Analytics Workspace nach AZFWNetworkRule- / AZFWApplicationRule-Einträgen ab, die zu Quelle und Ziel passen. Dafür müssen die Firewall-Diagnoseeinstellungen auf Log Analytics aktiviert sein. Die Log-Tabellen sind unter Die firewall-Logs lesen aufgelistet.

Rollback¶

Mache den pull request rückgängig und führe hub erneut aus.

Häufige Probleme¶

Symptom	Ursache
Konfigurationstest `Referenced IP Group '<x>' should exist`	Falscher Name, eine Ressourcen-ID statt eines Namens, oder die IP-group-Datei liegt nicht in einem Ordner namens `ip_groups`.
Konfigurationstest `Priority <n> already used`	Zwei RCG-Dateien im selben Ordner verwenden dieselbe Priorität.
Konfigurationstest `Only one source type allowed per rule`	Sowohl `source_addresses` als auch `source_ip_groups` sind gefüllt.
Plan will alle RCGs zerstören	Falscher `firewall_rule_collection_file_location`, oder die Naming-Flags wurden geändert. Stoppe und korrigiere den Pfad.
`409 AnotherOperationInProgress`	Parallele Updates an der Firewall-Policy. Erneut ausführen. Der layer wird bereits mit `-parallelism=1` angewendet.
Apply schlägt fehl, weil eine rule collection group bereits existiert	Ein früherer Lauf wurde abgebrochen (zum Beispiel durch ein Timeout), nachdem Azure die Gruppe erstellt hatte, aber bevor der state gespeichert wurde. Importiere die bestehende Gruppe in den state. Zerstöre sie in Produktion nicht. Siehe Wenn eine große Änderung in ein Timeout läuft.
Eine IP group lässt sich nicht umbenennen oder entfernen	Eine Regel verweist noch auf sie. Entferne oder verschiebe zuerst die Verweise und deploye, ändere die Gruppe dann in einem zweiten pull request.
Die Regel ist deployt, aber der Verkehr schlägt trotzdem fehl	Siehe Wenn der Verkehr trotzdem fehlschlägt.

Wenn der Verkehr trotzdem fehlschlägt¶

Prüfe diese Punkte in dieser Reihenfolge:

Prioritäten. Eine Collection oder RCG mit niedrigerer Nummer wird zuerst verarbeitet. Das Deployment lehnt kollidierende Prioritäten normalerweise ab, aber prüfe es trotzdem.
Überlappende Regeln. Der erste Treffer entscheidet, spätere Regeln werden nicht mehr ausgewertet. Eine network rule, die Port 443 zu einem FQDN verweigert, gewinnt gegen eine application rule, die HTTPS zu demselben FQDN erlaubt, wenn sie zuerst verarbeitet wird: In derselben Gruppe kommen network rules vor application rules, und eine Gruppe mit niedrigerer Prioritätsnummer kommt vor anderen Gruppen.
IP-Adresse statt FQDN. Verwende für Ziele im Internet (Updates, Hersteller-APIs, Anwendungen Dritter) FQDNs. Die Adresse eines Dienstes von Dritten kann sich ändern, und dann trifft die Regel stillschweigend nicht mehr.
Andere Ebenen. Network security groups, application security groups und Einstellungen an der Netzwerkschnittstelle filtern den Verkehr ebenfalls. Prüfe die NSG des Quell- und des Ziel-Subnets und die Route Table.
Namensauflösung. FQDN-Regeln in network rules brauchen den DNS proxy der Firewall-Policy (firewall_policy_dns.proxy_enabled). Prüfe zuerst die Namensauflösung (Incident Management).
Manuelle Regeln. Eine Regel, die jemand im portal angelegt hat, wird vom nächsten Deployment überschrieben. Ändere die Firewall nicht im portal.