💼 Management Samenvatting
Azure Firewall Policies vormen een krachtige oplossing voor het gecentraliseerd beheren en configureren van Azure Firewall-instances binnen complexe Azure-omgevingen van Nederlandse overheidsorganisaties. In tegenstelling tot het individueel configureren van elke Azure Firewall, maken Firewall Policies het mogelijk om beveiligingsregels, threat intelligence-instellingen, DNS-configuraties en andere firewallparameters centraal te definiëren en vervolgens toe te passen op meerdere firewalls tegelijk. Deze gecentraliseerde aanpak is essentieel voor organisaties met hub-spoke netwerkarchitecturen, meerdere Azure-regio's, of complexe netwerkbeveiligingsvereisten, omdat het consistentie waarborgt, beheer vereenvoudigt en compliance-vereisten op schaal kan worden geïmplementeerd.
✓ Azure Virtual Networks
✓ Azure Firewall Manager
✓ Hub-Spoke Architecturen
Zonder gecentraliseerd beheer via Azure Firewall Policies lopen organisaties het risico op inconsistente firewallconfiguraties tussen verschillende netwerken, regio's of omgevingen. Dit kan leiden tot aanzienlijke beveiligingsrisico's: verschillende firewalls kunnen verschillende beveiligingsniveaus hebben, waardoor sommige workloads beter beschermd zijn dan andere, configuratiefouten kunnen zich herhalen in meerdere firewalls, en het beheren en updaten van firewallregels wordt tijdrovend en foutgevoelig wanneer dit handmatig per firewall moet gebeuren. Daarnaast kunnen compliance-vereisten moeilijk worden geborgd wanneer elke firewall individueel wordt geconfigureerd, omdat er geen garantie is dat alle firewalls dezelfde beveiligingsstandaarden volgen. Voor Nederlandse overheidsorganisaties die moeten voldoen aan BIO, NIS2 en ISO 27001 is dit onacceptabel: deze frameworks vereisen consistente beveiligingsmaatregelen op schaal, gecentraliseerd beheer van beveiligingsconfiguraties, en de mogelijkheid om snel te reageren op nieuwe bedreigingen door beveiligingsregels centraal bij te werken. Zonder Firewall Policies kunnen organisaties tijdens audits niet aantonen dat hun netwerkbeveiliging consistent en gecentraliseerd wordt beheerd, wat kan leiden tot negatieve auditbevindingen en compliance-schendingen.
Connection:
Connect-AzAccountRequired Modules: Az.Network, Az.Resources, Az.Accounts
Implementatie
Dit artikel beschrijft een gestructureerde aanpak voor het implementeren en beheren van Azure Firewall Policies binnen de Nederlandse Baseline voor Veilige Cloud. De implementatie omvat vier hoofdcomponenten. Ten eerste policy-ontwerp en architectuur: het definiëren van een hiërarchische policy-structuur met parent policies voor organisatiebrede standaarden en child policies voor omgevingsspecifieke configuraties, het bepalen van welke regels en instellingen op welk niveau moeten worden gedefinieerd, en het ontwerpen van een naming convention en organisatiestructuur voor policies. Ten tweede policy-implementatie: het creëren van parent policies met basisbeveiligingsregels en threat intelligence-instellingen, het creëren van child policies die parent policies overerven en omgevingsspecifieke regels toevoegen, en het toepassen van policies op Azure Firewall-instances via Azure Firewall Manager of direct via de Azure Portal. Ten derde rule management: het beheren van netwerkregels, applicatieregels en NAT-regels binnen policies, het implementeren van rule collections met correcte prioritering, en het gebruik van rule collection groups voor logische groepering en beheer. Ten vierde monitoring en compliance: het configureren van logging en monitoring voor policies, het genereren van compliance-rapportages die aantonen hoe policies worden gebruikt om compliance-vereisten in te vullen, en het implementeren van processen voor regelmatige review en update van policies. Het bijbehorende PowerShell-script automatiseert het creëren en beheren van Firewall Policies, het toepassen van policies op firewalls, en het genereren van compliance-rapportages voor auditdoeleinden.
Policy-ontwerp en architectuur
Het ontwerpen van een effectieve Azure Firewall Policy-architectuur begint met het begrijpen van de hiërarchische structuur die Azure Firewall Policies ondersteunen. Azure Firewall Policies ondersteunen parent-child relaties, waarbij child policies regels en instellingen kunnen overerven van parent policies en daarnaast omgevingsspecifieke configuraties kunnen toevoegen. Deze hiërarchische aanpak maakt het mogelijk om organisatiebrede beveiligingsstandaarden te definiëren in parent policies, terwijl specifieke omgevingen zoals productie, test of development hun eigen child policies kunnen hebben die de parent policy overerven en aanvullen met omgevingsspecifieke regels. Voor Nederlandse overheidsorganisaties is het aanbevolen om een parent policy te creëren die basisbeveiligingsregels bevat die voor alle omgevingen gelden, zoals threat intelligence met modus 'Deny', logging naar een centrale Log Analytics-workspace, en basis netwerkregels die algemeen kwaadaardig verkeer blokkeren.
Naast de hiërarchische structuur moet worden bepaald welke regels en instellingen op welk niveau moeten worden gedefinieerd. Organisatiebrede regels die voor alle omgevingen gelden, zoals het blokkeren van bekende kwaadaardige IP-adressen via threat intelligence, het loggen van alle firewallverkeer, en basis netwerkregels voor algemene beveiliging, moeten worden gedefinieerd in de parent policy. Omgevingsspecifieke regels die alleen voor bepaalde omgevingen gelden, zoals toegang tot specifieke applicaties in productieomgevingen, testomgevingen die toegang nodig hebben tot externe testservices, of development-omgevingen met minder restrictieve regels, moeten worden gedefinieerd in child policies. Deze scheiding zorgt ervoor dat organisatiebrede standaarden consistent worden toegepast, terwijl flexibiliteit wordt behouden voor omgevingsspecifieke behoeften.
Een belangrijk aspect van policy-ontwerp is het definiëren van een naming convention en organisatiestructuur voor policies. Policies moeten duidelijke, beschrijvende namen hebben die aangeven wat hun doel is en op welke omgevingen zij van toepassing zijn, zoals 'Org-Wide-Firewall-Policy-Production' voor een productie parent policy of 'Hub-Network-Firewall-Policy' voor een policy specifiek voor hub-netwerken. Daarnaast moeten policies worden georganiseerd in resourcegroepen die logisch zijn gestructureerd, bijvoorbeeld een resourcegroep 'rg-firewall-policies' die alle firewall policies bevat, of gescheiden resourcegroepen per omgeving. Tags moeten worden gebruikt om aanvullende metadata toe te voegen, zoals omgeving (productie, test, development), eigenaar, compliance-frameworks (BIO, NIS2, ISO 27001), en laatste reviewdatum. Deze organisatiestructuur maakt het gemakkelijker om policies te vinden, te beheren en te documenteren voor auditdoeleinden.
Gebruik PowerShell-script azure-firewall-policies.ps1 (functie Invoke-Monitoring) – Controleert of Azure Firewall Policies correct zijn geconfigureerd en toegepast op firewalls.
Policy-implementatie en toepassing
De implementatie van Azure Firewall Policies begint met het creëren van een parent policy die organisatiebrede beveiligingsstandaarden definieert. Deze parent policy moet onder meer bevatten: threat intelligence-configuratie met modus 'Deny' voor productieomgevingen, DNS-proxy configuratie indien van toepassing, basis netwerkregels die algemeen kwaadaardig verkeer blokkeren, en logging-configuratie die alle firewallverkeer naar een centrale Log Analytics-workspace stuurt. De parent policy moet worden geconfigureerd met een duidelijke naam, beschrijving en tags die aangeven dat dit een organisatiebrede standaard is. Het is belangrijk om te realiseren dat parent policies zelf geen regels hoeven te bevatten die specifiek zijn voor individuele applicaties of workloads; in plaats daarvan moeten zij algemene beveiligingsstandaarden definiëren die door alle omgevingen worden gevolgd.
Na het creëren van de parent policy moeten child policies worden gecreëerd die de parent policy overerven en omgevingsspecifieke regels toevoegen. Child policies kunnen worden gecreëerd voor verschillende omgevingen (productie, test, development), verschillende netwerksegmenten (hub-netwerken, spoke-netwerken, DMZ-netwerken), of verschillende workloads (webapplicaties, databases, API-services). Elke child policy moet expliciet worden gekoppeld aan de parent policy via de parent policy property, waardoor alle regels en instellingen van de parent policy automatisch worden overgeërfd. Vervolgens kunnen omgevingsspecifieke regels worden toegevoegd aan de child policy, zoals toegang tot specifieke applicaties, netwerkregels voor specifieke workloads, of NAT-regels voor specifieke services. Het is belangrijk om te realiseren dat child policies de parent policy kunnen aanvullen maar niet kunnen overschrijven: als een parent policy een regel bevat die verkeer blokkeert, kan een child policy deze regel niet verwijderen of wijzigen. Dit waarborgt dat organisatiebrede beveiligingsstandaarden altijd worden gehandhaafd, zelfs wanneer omgevingsspecifieke configuraties worden toegevoegd.
Na het creëren van policies moeten deze worden toegepast op Azure Firewall-instances. Policies kunnen worden toegepast via Azure Firewall Manager, wat de aanbevolen aanpak is voor gecentraliseerd beheer, of direct via de Azure Portal of PowerShell. Azure Firewall Manager biedt een centrale interface voor het beheren van alle firewall policies en het toepassen van policies op firewalls, en maakt het mogelijk om policies te koppelen aan hub-netwerken in hub-spoke architecturen. Wanneer een policy wordt toegepast op een firewall, worden alle regels en instellingen uit de policy (inclusief overgeërfde regels van parent policies) automatisch toegepast op de firewall. Het is mogelijk om meerdere policies toe te passen op dezelfde firewall, waarbij policies worden geëvalueerd in volgorde van prioriteit. Het is belangrijk om te verifiëren dat policies correct zijn toegepast door de firewallconfiguratie te controleren en te valideren dat verwachte regels aanwezig zijn en correct werken.
Voor hub-spoke netwerkarchitecturen is het aanbevolen om policies toe te passen op hub-netwerken via Azure Firewall Manager, waardoor alle verkeer dat door het hub-netwerk wordt gerouteerd automatisch wordt gefilterd volgens de policy-regels. Spoke-netwerken kunnen worden gekoppeld aan het hub-netwerk via Virtual Network peering, en route tables kunnen worden geconfigureerd om verkeer van spoke-netwerken via het hub-netwerk te routeren, waardoor de firewall policy automatisch wordt toegepast op alle verkeer. Deze aanpak waarborgt consistente netwerkbeveiliging voor alle workloads in de hub-spoke architectuur, terwijl beheer wordt vereenvoudigd omdat policies centraal worden beheerd en automatisch worden toegepast op alle verkeer dat door het hub-netwerk wordt gerouteerd.
Rule management en configuratie
Het beheren van firewallregels binnen Azure Firewall Policies vereist een gestructureerde aanpak voor het organiseren en prioriteren van regels. Azure Firewall Policies ondersteunen drie typen regels: netwerkregels voor IP- en poortgebaseerde filtering, applicatieregels voor FQDN-gebaseerde filtering, en NAT-regels voor het vertalen van inkomend verkeer. Regels moeten worden georganiseerd in rule collections, waarbij elke collection een logische groep van gerelateerde regels bevat, zoals 'Allow-Outbound-HTTP' voor uitgaand HTTP-verkeer of 'Block-Malicious-IPs' voor het blokkeren van bekende kwaadaardige IP-adressen. Rule collections moeten worden geconfigureerd met een prioriteit, waarbij lagere prioriteitsnummers hogere prioriteit hebben, zodat regels worden geëvalueerd in de juiste volgorde. Het is belangrijk om te realiseren dat Azure Firewall regels evalueert in volgorde van prioriteit en stopt zodra een regel matcht, waardoor de volgorde van regels cruciaal is voor correcte werking.
Rule collection groups bieden een extra niveau van organisatie door rule collections logisch te groeperen. Rule collection groups kunnen worden gebruikt om regels te organiseren per functie (bijvoorbeeld 'Network-Security-Rules' en 'Application-Access-Rules'), per omgeving (bijvoorbeeld 'Production-Rules' en 'Test-Rules'), of per compliance-framework (bijvoorbeeld 'BIO-Compliance-Rules' en 'NIS2-Compliance-Rules'). Elke rule collection group kan meerdere rule collections bevatten, en rule collections binnen een group worden geëvalueerd in volgorde van prioriteit. Deze organisatiestructuur maakt het gemakkelijker om regels te vinden, te beheren en te documenteren, en maakt het mogelijk om grote aantallen regels gestructureerd te organiseren zonder dat de policy onoverzichtelijk wordt.
Bij het configureren van regels moet het principe van least privilege worden gevolgd: alleen verkeer dat expliciet is toegestaan moet kunnen passeren, terwijl alle ander verkeer standaard moet worden geblokkeerd. Regels moeten zo specifiek mogelijk zijn, waarbij brede regels die bijvoorbeeld alle verkeer naar alle IP-adressen toestaan worden vermeden. In plaats daarvan moeten regels specifieke bron- en doel-IP-adressen, poorten en protocollen specificeren. Voor applicatieregels moeten specifieke FQDN's worden gebruikt in plaats van wildcards waar mogelijk, en moeten regels worden geconfigureerd met specifieke protocollen en poorten. NAT-regels moeten worden gebruikt voor het vertalen van inkomend verkeer naar interne services, waarbij externe IP-adressen en poorten worden gemapt naar interne IP-adressen en poorten. Het is belangrijk om regelmatig regels te reviewen en te optimaliseren om te waarborgen dat zij up-to-date blijven en voldoen aan veranderende bedrijfsbehoeften en beveiligingsvereisten.
Voor Nederlandse overheidsorganisaties moeten regels worden geconfigureerd met aandacht voor compliance-vereisten. Regels moeten worden gedocumenteerd met duidelijke beschrijvingen die aangeven waarom de regel nodig is, welke workloads of services worden beschermd, en hoe de regel bijdraagt aan compliance-vereisten. Tags moeten worden gebruikt om regels te koppelen aan specifieke compliance-frameworks, zoals BIO controls of NIS2 artikelen. Regelmatige reviews moeten worden uitgevoerd om te waarborgen dat regels correct zijn geconfigureerd, niet verouderd zijn, en voldoen aan huidige beveiligingsvereisten. Deze reviews moeten worden gedocumenteerd en gerapporteerd aan security- en risicocomités, en bevindingen moeten worden vertaald naar concrete verbeteracties met eigenaren en deadlines.
Gebruik PowerShell-script azure-firewall-policies.ps1 (functie Invoke-Remediation) – Genereert aanbevelingen voor het verbeteren van Azure Firewall Policy-configuraties.
Monitoring en compliance
Monitoring en logging zijn cruciaal voor effectief beheer van Azure Firewall Policies en voor het waarborgen van compliance. Azure Firewall Policies moeten worden geconfigureerd met diagnostische instellingen die logs naar een centrale Log Analytics-workspace sturen, zodat alle netwerkverkeer kan worden geanalyseerd en gemonitord. Er moeten verschillende logcategorieën worden ingeschakeld: Application Rule logs voor verkeer dat wordt geëvalueerd tegen applicatieregels, Network Rule logs voor verkeer dat wordt geëvalueerd tegen netwerkregels, Threat Intelligence logs voor verkeer dat wordt geblokkeerd door threat intelligence, en DNS Proxy logs voor DNS-verzoeken wanneer DNS-proxy is ingeschakeld. Daarnaast moeten alertregels worden geconfigureerd die waarschuwingen genereren bij ongebruikelijke activiteiten, zoals plotselinge toename van geblokkeerd verkeer, herhaalde pogingen tot toegang tot bekende kwaadaardige domeinen, of wijzigingen aan policy-configuraties. Retentiebeleid voor logs moet worden gecontroleerd om te waarborgen dat logs worden bewaard voor de vereiste periode volgens compliance-vereisten (typisch 7 jaar voor Nederlandse overheidsorganisaties volgens BIO).
Voor compliance-doeleinden moeten regelmatige rapportages worden gegenereerd die aantonen hoe Azure Firewall Policies worden gebruikt om compliance-vereisten in te vullen. Deze rapportages moeten onder meer bevatten: een overzicht van alle policies met hun configuratie en toepassing, een beoordeling van compliance per framework met specifieke verwijzingen naar controls en artikelen, identificatie van afwijkingen en tekortkomingen met concrete aanbevelingen voor verbetering, en een overzicht van logging en monitoring die aantonen hoe beveiligingsgebeurtenissen worden gedetecteerd en gereageerd. Het bijbehorende PowerShell-script kan worden gebruikt om technische compliance-rapportages te genereren die kunnen worden gebruikt als onderdeel van auditdocumentatie. Deze rapportages moeten regelmatig worden gegenereerd en gedeeld met interne audit-teams, compliance-officers en externe auditors om transparantie te bieden en vertrouwen op te bouwen in de beveiligingsmaatregelen.
Een belangrijk aspect van compliance is het documenteren van policy-configuraties en het rechtvaardigen van regels. Policies moeten worden gedocumenteerd met duidelijke beschrijvingen die aangeven wat hun doel is, welke omgevingen of workloads worden beschermd, en hoe zij bijdragen aan compliance-vereisten. Regels moeten worden gedocumenteerd met beschrijvingen die aangeven waarom de regel nodig is, welke workloads of services worden beschermd, en hoe de regel bijdraagt aan beveiligingsdoelstellingen. Deze documentatie moet worden bijgewerkt wanneer policies of regels worden gewijzigd, en moet worden bewaard voor auditdoeleinden. Daarnaast moeten processen worden geïmplementeerd voor het reviewen en goedkeuren van policy-wijzigingen, waarbij wijzigingen worden gedocumenteerd, gereviewd door security-teams, en goedgekeurd door verantwoordelijke personen voordat zij worden geïmplementeerd.
Voor auditdoeleinden is het belangrijk om compliance-rapportages te genereren die aantonen hoe Azure Firewall Policies voldoen aan relevante frameworks. Deze rapportages moeten objectief en verifieerbaar zijn, en moeten onder meer bevatten: een overzicht van alle policies met hun hiërarchische structuur en toepassing, een beoordeling van compliance per framework met specifieke verwijzingen naar controls en artikelen, identificatie van afwijkingen en tekortkomingen met concrete aanbevelingen voor verbetering, en een overzicht van documentatie en processen die aantonen hoe compliance wordt geborgd. Deze rapportages moeten regelmatig worden gegenereerd en gedeeld met interne audit-teams, compliance-officers en externe auditors om transparantie te bieden en vertrouwen op te bouwen in de beveiligingsmaatregelen. Het bijbehorende PowerShell-script automatiseert het genereren van deze rapportages, waardoor het proces efficiënt en reproduceerbaar wordt.
Compliance & Frameworks
- CIS M365: Control 6.4, 6.5 (L1/L2) - Implementeer Azure Firewall Policies voor gecentraliseerd beheer van netwerkbeveiliging in lijn met de CIS Azure Foundations Benchmark.
- BIO: 13.01, 14.02 - Gecentraliseerd beheer van netwerkfiltering en logging voor internetgerichte diensten binnen de Baseline Informatiebeveiliging Overheid.
- ISO 27001:2022: A.8.20, A.8.33 - Gecentraliseerd beheer van netwerkbeveiliging en monitoring van beveiligingsgebeurtenissen in het kader van een Information Security Management System.
- NIS2: Artikel - Gecentraliseerde technische en organisatorische maatregelen voor risicobeheersing, inclusief netwerkbeveiliging en detectie van beveiligingsincidenten.
Automation
Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).
Risico zonder implementatie
Management Samenvatting
Azure Firewall Policies bieden gecentraliseerd beheer van Azure Firewall-configuraties, waardoor consistente beveiliging op schaal wordt gewaarborgd en beheer wordt vereenvoudigd. Door hiërarchische policies te implementeren met parent policies voor organisatiebrede standaarden en child policies voor omgevingsspecifieke configuraties, kunnen organisaties beveiligingsregels centraal definiëren en toepassen op meerdere firewalls. Het bijbehorende PowerShell-script automatiseert het creëren en beheren van policies en genereert compliance-rapportages voor auditdoeleinden. De benodigde inspanning is beperkt (circa 24 uur initiële implementatie), terwijl de risicoreductie, beheerefficiëntie en auditbaarheid aanzienlijk zijn.
- Implementatietijd: 24 uur
- FTE required: 0.2 FTE