Organisation der Firewallregeln¶
Wie du die Firewallregel-Dateien so organisierst, dass sich jede Regel einem Workload zuordnen lässt, Konflikte selten sind und ein stillgelegter Workload seine Regeln mitnimmt. Diese Seite liefert die Design-Überlegungen und die Dateistruktur. Die Details zu Namen, Prioritäten, IP Groups, Limits und sicheren Änderungen stehen in den Richtlinien für Firewallregeln und IP Groups. Das Dateiformat und das Vorgehen stehen in Firewallregeln.
Das Problem¶
Regeln, die nach Technologie organisiert sind (zum Beispiel eine Collection AllowDatabase pro Region), werden mit jedem neuen Workload
schwerer zu verwalten:
- du kannst nicht erkennen, welche Regeln zu welchem Workload gehören,
- Regeln überlappen oder kollidieren über Workloads hinweg,
- wenn ein Workload stillgelegt wird, weiß niemand, welche Regeln zu entfernen sind,
- die zusätzliche Dimension der Regionen verschlimmert es.
Leitlinie: nach Workload organisieren¶
Gruppiere Regeln rund um den Workload und seinen Zweck, nicht rund um eine Technologie. Diese Arten von Dateien decken alles ab:
| Art der Datei | Inhalt | Wo |
|---|---|---|
| Regeln der Plattforminfrastruktur | Nur die Kernregeln, die das Plattform-Team verwaltet: Updates des Betriebssystems, grundlegendes Monitoring, Plattform-Diagnose, DNS, Build-Agents. Siehe Basisregeln der Plattform. | Globaler Ordner, eine Datei |
| Dateien für funktionale Anforderungen | Eine Datei pro funktionaler Anforderung, die für viele Workloads gilt. Jede entspricht einer Designentscheidung, zum Beispiel Standardports für private endpoints in dev und test oder Zugriff für Build-Agents. | Globaler Ordner, benannt nach der Anforderung |
| Regionale gemeinsame Regeln | Regeln, die für eine Region spezifisch sind und für mehrere Workloads gelten. Beschränke sie auf Fälle mit einem echten regionalen Unterschied. | Region-Ordner, mit der Region im Dateinamen |
| Workload-Dateien | Alle Regeln eines Workloads. Alle Umgebungen (dev, tst, acc, prd) sind getrennte Rule Collections in derselben Datei, mit einem Standard-Collection-Namen, der die Umgebung enthält. | Globaler Ordner oder Region-Ordner, wenn ein regionaler Unterschied real ist (Failover, Datenresidenz) |
Benenne Regeln so, dass sie den Verkehrsfluss und den Grund zeigen, zum Beispiel <action><workload>_<reason>_<environment>
(AllowApp1_FromJumpHost_ToDb_tst), und behalte die Umgebung im Namen der Collection.
Globale und regionale Dateien¶
In MCP werden die globalen und die regionalen Dateien zusammengeführt, und eine regionale Datei mit demselben Dateinamen wie eine globale Datei ersetzt diese in dieser Region (Firewallregeln). Nimm die Region in den Namen regionsspezifischer Dateien auf, damit sie eine globale Datei nicht versehentlich überdecken, und nutze die Ersetzung nur absichtlich.
Konsistenz über Regionen hinweg¶
Wenn sich Regionen gegenseitig absichern (zum Beispiel mit einer Aktiv/Standby-Verbindung zu On-Premises), sollten in beiden dieselben Regeln existieren. Ein Failover scheitert dann nicht an einer Regel, die nur in einer Region existiert. Unterschiede zwischen Regionen brauchen einen Grund. Das kostet beim Hinzufügen von Regeln einen Review-Schritt, beseitigt aber eine ganze Klasse von Failover-Problemen.
Prioritäten¶
Reserviere pro Art von Datei einen Bereich von Prioritäten der Rule Collection Groups, damit zwei Teams nie dieselbe Nummer brauchen. Ein Beispiel, entsprechend den obigen Dateiarten:
| Bereich | Verwendung |
|---|---|
| 100 - 199 | Regeln der Plattforminfrastruktur |
| 200 - 299 | Globale Dateien für funktionale Anforderungen |
| 300 - 499 | Regionale gemeinsame Regeln |
| 500 - 5000 | Workload-Dateien, mit einem Block pro Workload |
Ein zweites gebräuchliches Schema teilt Workloads in Bereiche für Produktion und Nicht-Produktion auf, mit einem Block pro Workload
(Beispielschema). Wähle eines, schreibe es auf und lass Lücken. Verwende nicht die Priorität
8999, die die Plattform reserviert.
Regeln am Ziel¶
Lege eine Regel in der Datei des Ziel-Workloads ab und beschreibe eingehenden Verkehr (On-Premises und das Internet sind die Ausnahmen: Sie haben keine Workload-Datei). Die firewall wird gemeinsam genutzt. Könnte Workload B eine Regel hinzufügen, die B den Zugriff auf Workload A erlaubt, wäre A ohne die Freigabe von A erreichbar, und die Reihenfolge der Auswertung würde entscheiden, wer gewinnt. Mit Regeln am Ziel entscheidet A, wer eintreten darf. Wie die Anfragen aufgeteilt werden, steht in So stellst du eine Anfrage.
Basisregeln der Plattform¶
Das Plattform-Team besitzt einen globalen Regelsatz, von dem alle Workloads abhängen. Er enthält typischerweise:
| Kategorie | Beispiele |
|---|---|
| Namensauflösung und Verzeichnis | DNS zu On-Premises-Servern, Ports des Verzeichnisdienstes |
| Updates | Update-Services des Betriebssystems, Update-FQDN-Tags, Automation-Endpoints |
| Monitoring | Endpoints von Azure Monitor und Application Insights, Diagnose |
| Zeit | Zeitsynchronisation |
| Pipelines | Endpoints, die gehostete und selbst gehostete Agents brauchen (Quellcode-Hosts, Paket-Registries, Tool-Downloads) |
| Management | Bastion zu SSH und RDP in den Workload-Bereichen |
Halte diese getrennt von den Workload-Dateien, damit das Entfernen eines Workloads sie nie berührt.
Workload-Teams Änderungen vorschlagen lassen¶
Teams können Lesezugriff auf das Repository der Firewallregeln bekommen, damit sie sehen, welche Regeln für sie gelten und ob die firewall die Ursache eines Problems ist. Sie dürfen auch pull requests öffnen für die Datei ihres eigenen Workloads. Das verkürzt die Durchlaufzeit: Ein pull request ist leichter zu validieren als der Text eines Tickets, den jemand interpretieren muss.
Halte diese Bedingungen ein:
- das Plattform-Team (und, wo dein Prozess es verlangt, der Security Officer) genehmigt und deployt weiterhin,
- das Ticket oder der Change-Eintrag bleibt Pflicht,
- pull requests sind pro Team erlaubt, nachdem das Team gezeigt hat, dass es die Regeln, Git und die firewall kennt.
Siehe Review von pull requests, was der Reviewer prüft.
Konsequenzen¶
Positiv:
- eine klare Verbindung zwischen Regeln und Workloads,
- einfachere Fehlersuche, wenn die Konnektivität ausfällt,
- ein einfacher Prozess zur Stilllegung: Lösche die Datei des Workloads,
- weniger verwaiste Regeln,
- konsistente Namen und weniger Prioritätskonflikte.
Negativ oder zu beachten:
- jede regionale Regel braucht eine Begründung,
- regionsspezifische Adressen und Ressourcen sind schwerer zu handhaben,
- die Konsistenz der Regionen braucht einen zusätzlichen Review,
- die Struktur hält nur, wenn das Team sie beim Wachsen der Plattform einhält.