Een aanvraag voor een firewallregel afhandelen¶

Operatorrunbook voor de standaardwijzigingen Nieuwe firewallregels toevoegen en Firewallregels wijzigen. Het brengt je van een aanvraag in het ticketsysteem naar een pull request die klaar is voor review. Het formaat van de bestanden, de velden en de pipeline staan bij Firewallregels. De review staat in Review van een pull request voor firewallregels, de deployment in Deployment van firewallregels.

Als de aanvrager al een pull request heeft gemaakt

Een workload team dat toegang heeft tot de configuratierepository kan de wijziging zelf voorbereiden (Firewallregels en IP groups voor workload teams). Dan bestaat de configuratiewijziging al. Ga door naar De pull request valideren en begin daarna met de review.

1. Controleer of de aanvraag compleet is¶

Er zijn twee soorten aanvragen: een nieuwe regel en een wijziging van een bestaande regel. Begin niet voordat de velden compleet zijn. Een ontbrekend veld gaat terug naar de aanvrager.

Veld	Nieuwe regel	Bestaande regel	Opmerkingen
Naam van de workload of spoke	ja	ja	Gebruik het om het bestand en de eigenaar te vinden.
Onderbouwing	ja	ja
Omgeving	ja	ja	Productie, niet-productie of de platformomgevingen.
Regelnaam		ja	De sleutel van de regel in het bestand.
Protocollen	ja	ja	Network: `TCP`, `UDP`, `ICMP`, `Any`. Application: `Http`, `Https`, `Mssql` met een poort.
Poorten	ja	ja
Bron	ja	ja	Adressen of IP groups. Slechts één van beide typen.
Bestemming	ja	ja	Adressen, IP groups of FQDN's (network rule), FQDN's of FQDN tags (application rule). Slechts één type per regel.
Beschrijving en integratie	ja		Waarvoor de regel dient, en met welke andere workload of on-premises systeem hij verbindt.

Twee brontypen zijn in deze configuratie niet mogelijk: een FQDN als bron en een service tag als bron. Vraag de aanvrager om het bronadresbereik of een IP group. FQDN tags worden alleen in application rules gebruikt.

Is een veld onduidelijk, vraag het dan aan de aanvrager of aan de eigenaar van het platformontwerp. Begin niet voordat de aanvraag compleet is.

2. Maak een branch¶

Maak een branch vanaf main in de configuratierepository en neem het ticketnummer op, zoals in Veilig een wijziging doorvoeren: change/<ticket-id>-firewall-<workload>. Haal de branch naar je machine.

3. Bepaal waar de regel komt¶

Globaal of regionaal. Een globale regel is in elke regio actief. Een regionale regel alleen in de regio van de map. DNS- regels zijn globaal. Een regel tussen twee spokes in één regio is regionaal. Kun je het niet bepalen, vraag het dan. Zie Globale of regionale regel.

Welk bestand. Regels staan in één bestand per rule collection group. De bestanden zijn georganiseerd per workload en omgevingstype, bijvoorbeeld weu/<workload>/<workload>-prod.json, of per service, bijvoorbeeld een bestand voor de Bastion-regels (De configuratie rond workloads organiseren). Gebruik het bestaande bestand van de workload als dat er is.

Bestaat de rule collection group nog niet, maak dan in beide mappen van de platformomgevingen (canary en prod) een map voor de workload en daarin een bestand. Geef het een prioriteit die nog niet in gebruik is en binnen het bereik van de eigenaar valt (Prioriteiten). Neem de volgende vrije waarde. Controleer de bestaande bestanden en, bij twijfel, de firewall policy in de Azure-portal, want de config-test vergelijkt prioriteiten alleen binnen één map.

4. Kies het regeltype en de objecten¶

Vraag	Antwoord
Is het verkeer alleen HTTP, HTTPS of SQL (`Mssql`), en is de bestemming een FQDN?	Gebruik een application rule.
Al het andere (andere poorten, IP-bestemmingen, intern verkeer)	Gebruik een network rule.
Bestaat er al een regel met hetzelfde doel?	Controleer of je een adres kunt toevoegen aan de IP group die de regel gebruikt, in plaats van een nieuwe regel toe te voegen.
Moet de regel maar voor één van meerdere IP groups gelden?	Voeg geen bestemmingen toe aan een bestaande collection die meerdere groepen bedient. Voeg een aparte regel toe.
Staat de bestemming op internet?	Gebruik een FQDN of een FQDN tag, geen IP-adres.

Gebruik een IP group voor de bron of bestemming zodra dezelfde set adressen in meer dan één regel voorkomt. Elke spoke of workload hoort vanaf het begin een IP group te hebben. Bestaande groepen vind je in de mappen ip_groups van de platform- omgeving (en regio). Maak een ontbrekende groep eerst aan, of in dezelfde pull request (IP groups).

5. Bewerk het bestand¶

Nieuwe regel: voeg een sleutel toe aan de map rules van de juiste collection. Een collection heeft één type en één actie. Vul maar één brontype en één bestemmingstype in, en laat de andere lijsten leeg ([]). Kopieer de structuur uit JSON van een rule collection group.
Bestaande regel: zoek de regel op naam in het bestand en wijzig de velden die in de aanvraag staan. Behoud de naam.
Doe dezelfde wijziging in canary en prod.
Als de nieuwe regel een andere vervangt, voeg dan nu de nieuwe regel toe en verwijder de oude in een latere pull request. Verwijder de oude regel nooit in dezelfde wijziging (Firewallwijzigingen veilig doorvoeren).
Valideer de JSON met het schema in je editor (De JSON-bestanden bewerken met schema-ondersteuning). De prioriteit vraagt alleen aandacht als je een nieuw bestand maakt: de config-tests controleren die.

6. Open en valideer de pull request¶

Commit met een bericht dat zegt wat je hebt gewijzigd en voor wie, en push de branch.
Open een pull request naar main. Titel en beschrijving: de workload, het verkeer (van waar, naar waar, welke poort) en de reden. Koppel het ticket, en zoek het ticket op titel als je tool een andere identifier gebruikt.
Stel auto-complete in zoals beschreven in Review van pull requests: los het work item niet op na het mergen, en verwijder de bronbranch.
De validatiepipeline start. Open de checks van de pull request en lees het resultaat. Faalt hij, los dan de oorzaak op in je branch en push opnieuw. De pipeline draait dan vanzelf opnieuw.
Is de pipeline groen, vraag dan een tweede engineer om de review.

7. Na de review¶

Deploy zoals beschreven in Deployment van firewallregels, eerst canary.

Probleemoplossing¶

Controle	Wat het je vertelt
Prioriteiten van rule collection groups en collections	Ze mogen niet botsen. Een botsing laat de deployment normaal falen, maar controleer het toch.
Regels die overlappen	De eerste match beslist. Een network rule die een poort naar een FQDN weigert, verbergt een application rule die hem toestaat.
De bestemming is een IP-adres voor een internetservice	Het adres kan veranderen en de regel gaat niet meer matchen. Gebruik de FQDN.
Andere filterlagen	NSG's, ASG's en instellingen van de netwerkinterface kunnen het verkeer blokkeren nadat de firewall het toestaat.

Meer problemen en hun oorzaken staan in Veelvoorkomende problemen.