Zum Inhalt

Eine Firewallregel-Anfrage bearbeiten

Operator-Runbook für die Standardänderungen Neue Firewallregeln hinzufügen und Firewallregeln ändern. Es führt dich von einer Anfrage im Ticketsystem zu einem pull request, der bereit für das Review ist. Das Format der Dateien, die Felder und die pipeline stehen unter Firewallregeln. Das Review steht in Review des Firewallregel-Pull-Requests, das Deployment in Firewallregel-Deployment.

Wenn der Anfragende bereits einen pull request erstellt hat

Ein workload-Team mit Zugriff auf das Konfigurations-Repository kann die Änderung selbst vorbereiten (Firewallregeln und IP groups für workload-Teams). Dann existiert die Konfigurationsänderung bereits. Springe zu Den pull request validieren und starte danach das Review.

1. Prüfen, ob die Anfrage vollständig ist

Es gibt zwei Arten von Anfragen: eine neue Regel und eine Änderung an einer bestehenden Regel. Fange erst an, wenn die Felder vollständig sind. Ein fehlendes Feld geht zurück an den Anfragenden.

Feld Neue Regel Bestehende Regel Hinweise
Workload-Name oder spoke ja ja Damit findest du die Datei und den Owner.
Begründung ja ja
Umgebung ja ja Produktion, Nicht-Produktion oder die Plattform-Umgebungen.
Regelname ja Der Key der Regel in der Datei.
Protokolle ja ja Network: TCP, UDP, ICMP, Any. Application: Http, Https, Mssql mit einem Port.
Ports ja ja
Quelle ja ja Adressen oder IP groups. Nur einer der beiden Typen.
Ziel ja ja Adressen, IP groups oder FQDNs (Network-Regel), FQDNs oder FQDN-Tags (Application-Regel). Nur ein Typ pro Regel.
Beschreibung und Integration ja Wofür die Regel ist und mit welchem anderen workload oder On-Premises-System sie verbindet.

Zwei Quelltypen sind in dieser Konfiguration nicht möglich: ein FQDN als Quelle und ein Service Tag als Quelle. Bitte den Anfragenden um den Quell-Adressbereich oder eine IP group. FQDN-Tags werden nur in Application-Regeln verwendet.

Wenn ein Feld unklar ist, frage den Anfragenden oder den Owner des Plattform-Designs. Fange nicht an, bevor die Anfrage vollständig ist.

2. Einen Branch erstellen

Erstelle im Konfigurations-Repository einen Branch von main und nimm die Ticketnummer auf, wie in Änderungen sicher durchführen: change/<ticket-id>-firewall-<workload>. Hole den Branch auf deinen Rechner.

3. Entscheiden, wohin die Regel gehört

Global oder regional. Eine globale Regel ist in jeder Region aktiv. Eine regionale Regel nur in der Region des Ordners. DNS- Regeln sind global. Eine Regel zwischen zwei spokes in einer Region ist regional. Wenn du dich nicht entscheiden kannst, frage nach. Siehe Globale oder regionale Regel.

Welche Datei. Die Regeln liegen in einer Datei pro Rule Collection Group. Die Dateien sind nach workload und Umgebungstyp organisiert, zum Beispiel weu/<workload>/<workload>-prod.json, oder nach Service, zum Beispiel eine Datei für die Bastion-Regeln (Die Konfiguration um workloads herum organisieren). Verwende die bestehende Datei des workloads, wenn es eine gibt.

Wenn die Rule Collection Group noch nicht existiert, erstelle einen Ordner für den workload in beiden Ordnern der Plattform-Umgebungen (canary und prod) und darin eine Datei. Gib ihr eine Priorität, die unbenutzt ist und im Bereich des Owners liegt (Prioritäten). Nimm den nächsten freien Wert. Prüfe die bestehenden Dateien und im Zweifel die Firewall Policy im Azure portal, weil der Config test Prioritäten nur innerhalb eines Ordners vergleicht.

4. Den Regeltyp und die Objekte wählen

Frage Antwort
Ist der Traffic nur HTTP, HTTPS oder SQL (Mssql), und ist das Ziel ein FQDN? Verwende eine Application-Regel.
Alles andere (andere Ports, IP-Ziele, interner Traffic) Verwende eine Network-Regel.
Existiert bereits eine Regel mit demselben Zweck? Prüfe, ob du der IP group, die die Regel verwendet, eine Adresse hinzufügen kannst, statt eine neue Regel anzulegen.
Soll die Regel nur für eine von mehreren IP groups gelten? Füge einer bestehenden Collection, die mehrere Gruppen bedient, keine Ziele hinzu. Lege eine separate Regel an.
Liegt das Ziel im Internet? Verwende einen FQDN oder ein FQDN-Tag, keine IP-Adresse.

Verwende eine IP group für Quelle oder Ziel, sobald dieselbe Adressmenge in mehr als einer Regel vorkommt. Jeder spoke oder workload sollte von Anfang an eine IP group haben. Bestehende Gruppen findest du in den Ordnern ip_groups der Plattform-Umgebung (und Region). Erstelle eine fehlende Gruppe zuerst oder im selben pull request (IP groups).

5. Die Datei bearbeiten

  • Neue Regel: Füge einen Key in die Map rules der richtigen Collection ein. Eine Collection hat einen Typ und eine Aktion. Fülle nur einen Quelltyp und einen Zieltyp aus und lasse die anderen Listen leer ([]). Kopiere die Struktur aus Rule Collection Group JSON.
  • Bestehende Regel: Finde die Regel anhand ihres Namens in der Datei und ändere die in der Anfrage genannten Felder. Behalte den Namen.
  • Mache dieselbe Änderung in canary und prod.
  • Wenn die neue Regel eine andere ersetzt, füge die neue Regel jetzt hinzu und entferne die alte in einem späteren pull request. Entferne die alte Regel nie in derselben Änderung (Firewall-Änderungen sicher durchführen).
  • Validiere die JSON mit dem Schema in deinem Editor (JSON-Dateien mit Schema-Unterstützung bearbeiten). Die Priorität braucht nur Aufmerksamkeit, wenn du eine neue Datei anlegst: Die Config tests prüfen sie.

6. Den pull request öffnen und validieren

  1. Committe mit einer Nachricht, die sagt, was du für wen geändert hast, und pushe den Branch.
  2. Öffne einen pull request nach main. Titel und Beschreibung: der workload, der Traffic (von wo, wohin, welcher Port) und der Grund. Verlinke das Ticket und suche das Ticket anhand seines Titels, wenn dein Tool eine andere Kennung verwendet.
  3. Setze Auto-Complete wie in Pull-request-Review beschrieben: Schließe das Work Item nach dem Merge nicht ab und lösche den Quell-Branch.
  4. Die Validierungs-pipeline startet. Öffne die Checks des pull requests und lies das Ergebnis. Wenn sie fehlschlägt, behebe die Ursache in deinem Branch und pushe erneut. Die pipeline läuft dann von selbst noch einmal.
  5. Wenn die pipeline grün ist, bitte einen zweiten Engineer um das Review.

7. Nach dem Review

Deploye wie in Firewallregel-Deployment beschrieben, zuerst canary.

Fehlersuche

Prüfung Was sie dir sagt
Prioritäten von Rule Collection Groups und Collections Sie dürfen nicht kollidieren. Eine Kollision lässt das Deployment normalerweise fehlschlagen, prüfe es aber trotzdem.
Regeln, die sich überlappen Der erste Treffer entscheidet. Eine Network-Regel, die einen Port zu einem FQDN verweigert, verdeckt eine Application-Regel, die ihn erlaubt.
Das Ziel ist eine IP-Adresse für einen Internet-Service Die Adresse kann sich ändern, und die Regel greift nicht mehr. Verwende den FQDN.
Andere Filterebenen NSGs, ASGs und Einstellungen der Netzwerkschnittstelle können den Traffic blockieren, nachdem die Firewall ihn erlaubt hat.

Weitere Probleme und ihre Ursachen stehen unter Häufige Probleme.