Zum Inhalt

Firewallregeln und IP groups für workload-Teams

Traffic, der deinen spoke verlässt, in ihn hineingeht oder zu einem anderen spoke fließt, läuft über die zentrale Firewall, und die Firewall blockiert alles, was keine Regel erlaubt. Diese Seite hilft dir, eine Regel anzufragen oder, wenn deine Plattform es erlaubt, die Änderung selbst als pull request vorzubereiten. Was du anfragen musst, wer genehmigen muss und welchen Regeltyp du wählst, steht bereits unter So stellst du eine Anfrage. Die Designregeln, denen das Plattform-Team folgt, stehen in den Richtlinien für Firewallregeln und IP groups. Diese Seite wiederholt sie nicht. Sie zeigt die Dateien und die Schritte aus deiner Sicht.

Wähle deinen Weg

Weg Du machst Das Plattform-Team macht
Anfrage Fülle in einem Ticket die Anfragefelder unter So stellst du eine Anfrage aus. Bearbeitet die Dateien, lässt die Änderung reviewen und deployt sie.
Pull request Bearbeite die Dateien selbst, öffne einen pull request und verknüpfe ihn mit einem Ticket. Reviewt, merged und deployt. Du schließt deinen eigenen pull request nie selbst ab.

Für den Weg über den pull request brauchst du Zugriff auf das Konfigurations-Repository. Frag dein Plattform-Team, ob er für dich offen ist (So stellst du eine Anfrage). Jede Regel braucht trotzdem ein Ticket: Das Ticket ist der Änderungsnachweis und enthält die Genehmigungen.

Bevor du anfängst

  1. Kenne den Traffic. Quelle (dein spoke oder subnet), Ziel (FQDN, Adresse, service tag), Port und Protokoll sowie warum du ihn brauchst. Bei Zielen im Internet suchst du den FQDN. Die IP-Adresse eines öffentlichen Dienstes kann sich ändern.
  2. Wisse, wer genehmigt. Der Owner des Ziels genehmigt Regeln zwischen workloads. Security prüft viele andere Regeln. Siehe Wer welche Regel beantragt und Was die Prüfung üblicherweise kontrolliert.
  3. Prüfe, was es schon gibt. Möglicherweise deckt eine Regel deinen Traffic bereits ab. Sieh in den Dateien deines workloads im Konfigurations-Repository nach.

Die Dateien in Kürze

Was Wo Eine Datei ist
Firewallregeln firewall_rule_configuration/ (global) oder <region>/firewall_rule_configuration/ (eine Region) Eine rule collection group
IP groups ip_groups/ (global) oder <region>/ip_groups/ (eine Region) Eine IP group

Jede Plattform-Umgebung hat eigene Ordner (canary und prod). Eine Änderung gehört in beide, zuerst canary. Dein Nicht-Produktions- und dein Produktions-Traffic sind meist getrennte rule collection groups, damit Produktionsdaten nicht in die Nicht-Produktion fließen können.

Eine Firewallregel vorbereiten

1. Finde oder erstelle die Datei deines workloads

Regeln sind pro workload organisiert. Verwende die Datei deines workloads und Umgebungstyps. Gibt es keine, nennt dir das Plattform-Team den Ordner und den Prioritätsbereich. Wähle die Priorität nicht ohne Rücksprache selbst: Prioritäten müssen eindeutig sein und im Bereich des Owners liegen.

2. Schreibe die Regel

Eine rule collection group hat drei maps: NAT-, network- und application-rule-collections. Alle drei müssen vorhanden sein, auch wenn sie leer sind. Hier ist eine Regel in einer network-collection und eine in einer application-collection:

{
  "rule_collection_group": {
    "name": "app1-prod",
    "priority": 2100,
    "nat_rule_collections": {},
    "network_rule_collections": {
      "NetworkRules": {
        "priority": 110,
        "action": "Allow",
        "rules": {
          "app1-vm-to-servicebus": {
            "protocols": ["TCP"],
            "source_addresses": [],
            "source_ip_groups": ["ipgrp-app1-web-prod"],
            "destination_addresses": [],
            "destination_ip_groups": [],
            "destination_fqdns": ["<namespace>.servicebus.windows.net"],
            "destination_ports": ["443"]
          }
        }
      }
    },
    "application_rule_collections": {
      "ApplicationRules": {
        "priority": 120,
        "action": "Allow",
        "rules": {
          "app1-to-vendor-api": {
            "protocols": ["Https:443"],
            "source_addresses": [],
            "source_ip_groups": ["ipgrp-app1-web-prod"],
            "destination_fqdns": ["api.vendor.example"],
            "destination_fqdn_tags": []
          }
        }
      }
    }
  }
}

Die Zahlen und Namen sind Beispiele. Verwende die, die dir dein Plattform-Team gibt.

Faustregeln:

  • Application rule für HTTP-, HTTPS- und SQL-Traffic zu einem FQDN. Network rule für alles andere. Die Checkliste steht unter Application oder network rule.
  • Ein Quelltyp und ein Zieltyp pro Regel. Verwende als Quelle entweder Adressen oder IP groups und als Ziel entweder Adressen, IP groups oder FQDNs. Lass die anderen Listen leer.
  • Exakte Ports, keine Wildcards. Frage nicht ohne Grund nach *, nach Any oder nach weiten Bereichen.
  • FQDN statt IP-Adresse bei Zielen im Internet.
  • Ein einzelnes Ticket und ein einzelner pull request pro rule collection group. Kombiniere keine unzusammenhängenden Änderungen.
  • Um eine Regel zu ersetzen, füge zuerst die neue Regel hinzu und bitte danach um das Entfernen der alten.

Alle Eigenschaften, die erlaubten Werte und die Limits stehen unter JSON der rule collection group.

3. Verwende IP groups für Adressmengen

Wenn mehr als eine Regel dieselbe Menge von Adressen verwendet, lege sie in einer IP group ab und verweise per Namen darauf (unten).

4. Prüfe die Datei

Verwende einen Editor, der die JSON-Schemas kennt. Er schlägt die Eigenschaften vor, listet die erlaubten Werte auf und unterstreicht Fehler (JSON-Dateien mit Schema-Unterstützung bearbeiten). Wenn du kannst, führe auch die config tests des Repositorys aus (Die Tests lokal ausführen).

5. Öffne den pull request

  • Branch-Name und Titel so, wie es dein Plattform-Team vereinbart hat, zum Beispiel [APP1] Add firewall rules - Service Bus connectivity.
  • Beschreibung: der Traffic (von wo, wohin, welcher Port und welches Protokoll), der Grund, die Umgebungen und das Ticket.
  • Mache dieselbe Änderung im Ordner canary und im Ordner prod.
  • Warte auf die Checks der pipeline und behebe, was sie melden.
  • Schließe den pull request nicht selbst ab. Das Plattform-Team reviewt ihn mit der Checkliste für Firewallregeln.

IP groups

Eine IP group ist eine benannte Menge von Adressen und Bereichen. Regeln verweisen per Namen darauf, sodass du die Adressen an einer Stelle änderst.

Wann du eine verwendest und wann nicht, steht unter IP groups. Kurz gesagt: Verwende eine für eine Menge, die mehrere Regeln nutzen, die sich regelmäßig ändert oder die einen klaren Zweck hat (die Webserver eines workloads in Produktion). Lege keine für die Adressen einer einzelnen Regel an.

Die Datei ist klein:

{
  "ip_group": {
    "name": "ipgrp-app1-web-prod",
    "cidrs": ["10.20.4.0/26"]
  }
}
  • name: eindeutig und im Namensschema deiner Plattform. Er sagt, was die Adressen sind.
  • cidrs: IPv4-Adressen oder -Bereiche (ein einzelner Host als /32).
  • Mische keine unzusammenhängenden subnets in einer Gruppe und füge keine Adressen hinzu, die für den Zweck nicht vereinbart sind.
  • Lege die Gruppe im selben pull request an wie die Regeln, die sie verwenden, oder davor.
  • Um die Adressen einer Gruppe zu ändern, bearbeite die Datei. Jede Regel, die sie verwendet, folgt automatisch, sag also im pull request, welche Regeln betroffen sind.
  • Um eine Gruppe umzubenennen oder zu entfernen, bitte das Plattform-Team, es in zwei Schritten zu tun: zuerst die Regeln, dann die Gruppe.

Das Operator-Runbook ist IP groups.

Nach dem Merge

  1. Das Plattform-Team deployt auf canary, prüft das Ergebnis und deployt in Produktion. Du wirst über das Ticket informiert (Wie es weitergeht).
  2. Teste den Traffic aus deinem workload, zum Beispiel mit curl oder Test-NetConnection <destination> -Port <port>.
  3. Wenn es nicht funktioniert, prüfe Folgendes, bevor du um Hilfe bittest: Die Regel existiert in der Firewall-policy, die NSG deines subnets erlaubt den Traffic, der Name wird aufgelöst und das Ziel akzeptiert die Verbindung. Das Plattform-Team kann sich die Firewall-Logs für deine Quelle und dein Ziel ansehen (Die Firewall-Logs lesen).
  4. Sag dem Plattform-Team Bescheid, wann das Ticket geschlossen werden kann.

Das solltest du nicht tun

  • Firewallregeln im Portal ändern. Das nächste Deployment überschreibt sie.
  • Eine Regel anfragen, die du noch nicht brauchst. Wenn der Zugriff temporär ist, sag das im Ticket und nenne das Enddatum, damit die Regel entfernt werden kann.
  • Regeln verwenden, um Produktion und Nicht-Produktion zu verbinden.