Richtlijnen voor firewallregels en IP-groepen¶

Het runbook Firewallregels legt uit hoe je een regel toevoegt, wijzigt of verwijdert: de bestanden, de JSON en de pipeline. Deze pagina legt uit hoe je regels en IP-groepen ontwerpt, zodat de configuratie leesbaar blijft, binnen de Azure-limieten blijft en door meer dan één team kan worden beheerd.

Firewallregels zijn code. Maak of wijzig regels niet in de portal: de volgende deployment van de firewall policy overschrijft alles wat niet via de configuratierepository is gemaakt.

De structuur van de bestanden en de controles van de config tests liggen vast in het platform. De naamgevings- en nummeringsschema's op deze pagina zijn conventies. Twee klantplatformen gebruiken andere. Kies één schema voor jouw platform, leg het vast en pas het consistent toe. Waar deze pagina getallen noemt, zijn het voorbeelden.

Hoe Azure Firewall regels organiseert¶

Een firewall policy bevat rule collection groups (RCG). Een RCG bevat rule collections. Een rule collection bevat regels.

Niveau	Wat het is	Priority
Rule collection group	De eerste eenheid die de firewall verwerkt. Eén JSON-bestand in de configuratierepository.	100 (als eerste verwerkt) tot 65000. Moet uniek zijn in de policy.
Rule collection	Heeft één type (DNAT, network of application) en één actie (`Allow` of `Deny`).	Uniek binnen de RCG.
Regel	Matcht bron, bestemming, poort en protocol.	Geen priority.

De firewall weigert alles wat geen regel toestaat. Gebruik Allow in vrijwel elke collection. Gebruik Deny alleen voor specifieke securitybehoeften.

Verwerkingsvolgorde. Azure Firewall verwerkt de RCG's op volgorde van priority, laagste nummer eerst. Binnen één RCG verwerkt hij eerst de DNAT-collections, dan de network-collections en dan de application-collections, elk op collection-priority. Daarom eist de config test dat de laagste NAT-priority lager is dan de laagste network-priority, en die weer lager dan de laagste application-priority. Zie de rule processing logic van Microsoft.

Regeltypen:

Type	Gebruik het voor
DNAT	Inkomend verkeer naar een publiek IP van de firewall, vertaald naar een privéadres. Zie DNAT-regels.
Network	Laag 3 en 4: IP-adressen, poorten, protocollen. Inkomend, uitgaand en verkeer tussen spokes.
Application	Laag 7: FQDN's en HTTP-, HTTPS- of SQL-protocollen, vooral voor uitgaand verkeer.

Network-regels hebben minder resources nodig dan application-regels. Gebruik een network-regel als je geen FQDN-matching nodig hebt.

Welk type? Gebruik een application-regel wanneer de aanvraag alleen HTTP (80), HTTPS (443) of SQL-verkeer bevat en de bestemming een FQDN is. Gebruik in alle andere gevallen een network-regel. Het runbook bevat de checklist: Application- of network-regel.

Laat regels niet overlappen. De eerste match beslist, en een deny die als eerste matcht verbergt de allow die daarna komt. Een network-regel die HTTPS naar een FQDN weigert, wint van een application-regel die dezelfde FQDN toestaat, als die eerst wordt verwerkt. Controleer nieuwe regels tegen bestaande, vooral over collection groups heen.

Azure-limieten om rekening mee te houden¶

Deze limieten gelden voor een firewall policy op het moment van schrijven. Controleer de Azure Firewall-limieten van Microsoft voor de actuele aantallen.

Limiet	Waarde
Rule collection groups per policy	90
Grootte van één rule collection group	2 MB
Unieke IP-groepen per policy	600
Adressen of prefixes in één IP-groep	5.000

Plan hiermee rekening. Een groot platform met veel workloads kan 90 RCG's bereiken. Maak geen RCG alleen om regels visueel te ordenen. Gebruik daarvoor rule collections.

Wanneer maak je een nieuwe rule collection group¶

Maak een aparte RCG wanneer:

de regels een andere prioriteitsklasse nodig hebben (platformregels, productieworkloads, niet-productieworkloads);
een ander team eigenaar is, zodat elk team in een eigen bestand werkt;
ze een andere levenscyclus hebben, bijvoorbeeld tijdelijke regels voor een project;
een logische scheiding vereist is, bijvoorbeeld een securityzone of een compliancegrens;
de RCG dicht bij de limiet van 2 MB komt.

Maak geen nieuwe RCG wanneer de regels in een bestaande collection passen, wanneer een collection-priority volstaat, of wanneer het platform al dicht bij 90 RCG's zit.

Organiseer de configuratie rond workloads¶

Organiseer regels per workload, niet per technologie. Een rule collection group met de naam AllowDatabase mengt het verkeer van veel workloads. Niemand weet welke regel bij welke workload hoort, regels conflicteren of herhalen zich, en niemand weet wat er weg moet als een workload wordt opgeheven. Eén RCG-bestand per workload (of per workload en omgevingstype) lost dit op.

Een typische indeling binnen firewall_rule_configuration/ (submappen zijn toegestaan, zie Firewallregels):

firewall_rule_configuration/
├── 0.platform/        Rules the platform team manages: DNS, updates, monitoring, managed VMs
├── 1.global/          Rules of the customer that apply to every workload
├── <workload-a>/      One folder per workload
│   ├── <workload-a>-prod.json
│   └── <workload-a>-non-prod.json
└── <workload-b>/

Enkele punten bij deze indeling:

Globale en regionale bestanden. Zet een regel in de globale map wanneer die voor elke regio geldt, bijvoorbeeld DNS: dat moet overal werken. Zet hem alleen in een regiomap wanneer er een echte regionale reden is, zoals een failover- of residency-eis, of wanneer hij twee spokes in één regio verbindt. Een regionaal bestand met dezelfde naam als een globaal bestand vervangt dat in die regio. Houd regels consistent tussen regio's die elkaar back-uppen.
Productie en niet-productie gescheiden. Gebruik aparte RCG's (of minimaal aparte collections) voor productie- en niet-productieverkeer van een workload, zodat productiedata niet per ongeluk naar een niet-productieomgeving kan stromen. Sta geen verkeer tussen de twee toe.
Intern en internet gescheiden. Houd interne regels en internetregels in aparte collections. Internetverkeer is de grotere dreiging en verdient een eigen review.
Verbreed een regel niet voor één bron. Heeft maar één van meerdere bron-IP-groepen toegang nodig tot een bestemming, voeg die bestemming dan niet toe aan de bestaande regel of collection: daarmee open je hem ook voor de andere groepen. Voeg een aparte regel toe.
Eén eigenaar per bestand. Het team dat eigenaar van de workload is, is eigenaar van het bestand. Voor verkeer tussen twee workloads staat de regel in het bestand van de bestemmingsworkload (wie vraagt welke regel aan).

Priorities¶

Azure vereist een unieke RCG-priority per policy. De config test controleert alleen de uniciteit binnen één firewall_rule_configuration-map, dus controleer globale bestanden tegen regionale bestanden zelf ook. Gebruik 8999 niet: het platform gebruikt die priority voor de RCG van de deployment agents wanneer deployment_agents_private_network_range is ingesteld.

Geef elke eigenaar een bereik, zodat teams niet botsen en priorities laten zien waar een regel voor dient. Laat gaten open (bijvoorbeeld stappen van 10), zodat je later regels kunt invoegen.

Voorbeeld van een prioriteitsschema

Dit is een voorbeeld. Pas het aan en documenteer je eigen schema.

Doel	RCG-priorityrange
Regels beheerd door het platformteam	1000-1099
Globale regels van de klant	1100-1199
Productieworkloads	2000-2999
Niet-productieworkloads	3000-5999
Gereserveerd	6000-9999

Binnen de productie- en niet-productiebereiken krijgt elke workload een eigen subbereik (bijvoorbeeld 20 nummers). Het productiebereik en het niet-productiebereik van een workload gebruiken dezelfde offset (2100-2119 en 3100-3119), waardoor de paren makkelijk te vinden zijn.

Collection-priorities hoeven alleen uniek te zijn binnen de RCG en mogen in andere RCG's terugkomen. Houd in elk bestand dezelfde tussenruimte aan.

Naamgeving¶

Namen zijn identifiers in Azure en Terraform-keys. Kies namen die zeggen van wie een regel is en wat hij toestaat. Gebruik alleen kleine letters, cijfers en koppeltekens (of underscores), houd ze kort, en vermijd namen als rule1, misc, temp-all of allow-all. De config test accepteert het patroon ^[a-zA-Z0-9][a-zA-Z0-9._-]*[a-zA-Z0-9_]$ voor namen van collections en regels.

Object	Patroon (voorbeeld)	Voorbeelden
RCG	`<workload>-<project or service>-<environment type>`. Beheerd door het platform: `<owner>-global-<description>`.	`app1-prod`, `app1-reporting-non-prod`, `platform-global-dns`
Rule collection	Een vaste naam per type, of een naam die type en omgeving toont	`NetworkRules`, `ApplicationRules`
Regel	`<source>-to-<destination>`, met extra detail waar nodig	`app1-vm-to-servicebus`, `appgw-to-app1-web`, `onprem-sql-to-app1-sql`
IP-groep	`ipgrp-<description>` (globaal), `ipgrp-<workload>-<description>-<environment>` (workload). Een alternatief dat laat zien waar de adressen staan: `ipgrp-<onprem or azure>-<workload>-<environment>-<use>`.	`ipgrp-hub`, `ipgrp-app1-web-prod`, `ipgrp-onprem-dns`

De RCG-naam moet uniek zijn over alle bestanden van een regio, omdat het de Azure-naam en de Terraform-key is. Een RCG hernoemen vernietigt hem en maakt hem opnieuw aan (zie Een bestaande regel wijzigen of verwijderen).

Regels goed ontwerpen¶

Gebruik de meest specifieke bestemming. In volgorde van voorkeur: een FQDN, een enkel IP-adres, een IP-groep, een subnet. Geef de voorkeur aan de smalste scope die werkt.
Internetbestemmingen als FQDN's, niet als IP-adressen. Publieke services (updates van het besturingssysteem, API's van leveranciers) en applicaties van derden kunnen van adres veranderen. Een regel op een adres matcht dan zonder waarschuwing niet meer. Een FQDN of een FQDN- tag blijft werken.
Gebruik IP-groepen voor adressets die door meer dan één regel worden gebruikt of die vaak veranderen (zie hieronder).
Gebruik service tags voor Azure-services in network-regels (bijvoorbeeld AzureBackup, AzureMonitor). Microsoft onderhoudt de adresbereiken, en dit presteert beter dan FQDN's.
Gebruik FQDN-tags voor Microsoft-services in application-regels (bijvoorbeeld WindowsUpdate). De lijst met ondersteunde waarden staat in het runbook Firewallregels.
Eén brontype en één bestemmingstype per regel. Gebruik source_addresses of source_ip_groups, en destination_addresses, destination_ip_groups of destination_fqdns. Splits in twee regels als je beide nodig hebt. De config test dwingt dit af.
Consolideer. Combineer regels met dezelfde bron, bestemming en actie, en noem meerdere poorten in één regel (["80", "443"]) in plaats van één regel per poort.
Least privilege. Noem de exacte poorten en protocollen. Vermijd * als bron of bestemming en vermijd het protocol Any. Gebruik wildcard-FQDN's (*.example.com) met zorg.
Standaard versleutelde protocollen. Veel organisaties staan alleen versleutelde protocollen toe en eisen een extra goedkeuring voor onversleutelde.
Verwijder wat niet meer wordt gebruikt. Azure Firewall Policy Analytics helpt om ongebruikte regels te vinden en de volgorde van regels af te stellen.

Een expliciete deny-regel¶

Voeg alleen een Deny-collection toe voor een specifieke securitybehoefte, bijvoorbeeld om een gevoelig subnet van het internet af te schermen. Geef de deny-collection een lager priority-nummer dan de allow-regels die hij moet overrulen, zet hem in een RCG die eigendom is van het platform, en zorg dat die regel door security wordt gereviewd.

IP-groepen¶

Een IP-groep is een benoemde set adressen en bereiken. Regels verwijzen er met de naam naar. Het runbook met de stappen en de JSON is IP-groepen. Als een subnet verandert, werk je één bestand bij en volgt elke regel die de groep gebruikt. De naam vertelt de lezer ook wat de adressen zijn, en het is makkelijk te zien welke netwerken een regel opent.

Wanneer gebruik je een IP-groep¶

Meerdere regels gebruiken dezelfde set adressen.
De adressen zijn gedeelde infrastructuur waar veel workloads naar verwijzen (hubnetwerken, identiteitsservers, managementnetwerken, het subnet van de Application Gateway).
De adressen veranderen regelmatig.
De set heeft één logisch doel (de werkstations van één workload in productie, de Databricks-subnets van één workload).
Het is een workload of spoke. Een goede gewoonte is om elke nieuwe spoke vanaf het begin een IP-groep voor zijn adresbereik te geven, zodat latere regels ernaar kunnen verwijzen. Controleer voordat je een nieuwe regel toevoegt of een bestaande regel met hetzelfde doel het nieuwe adres via de groep kan krijgen.

Wanneer gebruik je geen IP-groep¶

De adressen worden door slechts één regel gebruikt. Zet ze inline.
De regel is tijdelijk of een eenmalige test.
De regelset is heel klein.
De adressen zijn niet gerelateerd. Meng geen ongerelateerde subnets in één groep.

Waar de bestanden staan en hoe ze eruitzien¶

IP-groepbestanden staan in ip_groups/ (zie Firewallregels). Eén bestand bevat één IP-groep. Gebruik dezelfde mapstructuur als voor de regels: globale groepen in een platform- of globale map, workloadgroepen in een map per workload, en de bestandsnaam gelijk aan de groepsnaam. Een groep die de naamconventie niet volgt, kan in een aparte map "uncategorized" wachten totdat hij is hernoemd.

{
  "ip_group": {
    "name": "ipgrp-app1-web-prod",
    "cidrs": ["10.20.4.0/26"]
  }
}

Schrijf een enkele host als /32. Het schema accepteert een kaal IPv4-adres en een adres met een prefixlengte van /0 tot /32. Gebruik één stijl binnen een groep en valideer het bestand (Bewerk de JSON-bestanden met schema-ondersteuning).

Een IP-groep in twee stappen hernoemen of verwijderen¶

Een regel die verwijst naar een groep die niet meer bestaat, laat de deployment mislukken. Hernoem of verwijder een groep nooit in dezelfde wijziging waarin je de regels bijwerkt.

Hernoemen:

Voeg een nieuw bestand toe met de nieuwe naam en dezelfde adressen. Werk elke regel bij naar de nieuwe naam. Deploy.
Als dat in elke omgeving is gedeployd, verwijder je het oude bestand. Deploy opnieuw.

Verwijderen:

Verwijder alle verwijzingen uit de regels. Deploy.
Verwijder het bestand. Deploy opnieuw.

Firewallwijzigingen veilig doorvoeren¶

Eén RCG-wijziging per pull request. Een update van een firewall policy duurt enkele minuten, en Azure ondersteunt geen parallelle updates van dezelfde policy. Kleine pull requests zijn makkelijker te reviewen, toe te passen en terug te draaien.
Toevoegen, verifiëren, verwijderen. Als een regel een andere vervangt, voeg dan eerst de nieuwe regel toe, controleer dat het verkeer werkt, en verwijder de oude regel in een aparte pull request. Verwijder een regel nooit voordat de vervanger is bevestigd. Toevoegen en verwijderen combineren in één pull request kan een storing veroorzaken.
Wijzig elke omgevingsmap die het nodig heeft. De mappen voor canary en prod zijn gescheiden. Voer dezelfde wijziging in beide door (eerst canary), tenzij de regel maar voor één geldt.
Draai de config tests voordat je pusht (De tests lokaal draaien).
Controleer het plan. Alleen de firewall layer mag wijzigingen tonen, en alleen voor de RCG die je hebt aangeraakt.

Als een grote wijziging een time-out krijgt¶

Meerdere rule collection groups in één wijziging kunnen langer duren dan de apply-time-out, omdat Azure de updates in de wachtrij zet. Wanneer de run wordt afgebroken, kunnen sommige collections in Azure bestaan maar niet in de Terraform state. De volgende run mislukt dan omdat de resource al bestaat.

Vernietig en maak productieregels niet opnieuw aan om een state-mismatch op te lossen

Het vernietigen van de collections die al bestaan onderbreekt het verkeer zolang het herstel duurt. Gebruik terraform import voor de resources die in Azure bestaan maar niet in de state. Beter nog, voorkom het: als een canary-run al time-outs laat zien, ga dan niet door naar productie. Splits de wijziging in kleinere pull requests, en pas nieuwe regels toe voordat je de regels verwijdert die ze vervangen.

De firewalllogs lezen¶

Firewall diagnostics kunnen logs naar een Log Analytics workspace sturen. De tabellen die je het meest gebruikt zijn:

Tabel	Inhoud
`AZFWApplicationRule`	Matches van application-regels
`AZFWNetworkRule`	Matches van network-regels
`AZFWNatRule`	Matches van DNAT-regels
`AZFWDnsQuery`	DNS-queries die door de DNS proxy worden afgehandeld
`AZFWFlowTrace`, `AZFWFatFlow`	Flow traces en de grootste flows
`AZFWIdpsSignature`	Signatures voor intrusion detection (Premium)

Er zijn ook aggregatietabellen (AZFWApplicationRuleAggregation, AZFWNetworkRuleAggregation, AZFWNatRuleAggregation). Geef de mensen die regels troubleshooten leestoegang tot deze tabellen en tot de firewallresource, en niet tot de hele workspace. Controleer welke tabellen jouw diagnostic settings vullen.