💼 Management Samenvatting
Azure Firewall vormt een essentiële beveiligingslaag voor Azure Virtual Networks en hybride cloudomgevingen van Nederlandse overheidsorganisaties. Als volledig beheerde, stateful firewall-as-a-service biedt Azure Firewall geavanceerde netwerkfiltering, threat intelligence-integratie, FQDN-filtering en NAT-capaciteiten die organisaties in staat stellen om consistente beveiligingscontroles af te dwingen over alle netwerkverkeer binnen en tussen cloudomgevingen. In tegenstelling tot traditionele netwerkbeveiligingsgroepen die werken op Layer 3 en 4, biedt Azure Firewall diepgaande inspectie op applicatieniveau, waardoor organisaties kunnen beschermen tegen moderne bedreigingen zoals malware, ransomware en geavanceerde persistent threats (APT's) die via netwerkverkeer worden verspreid.
✓ Azure Virtual Networks
✓ Hybride netwerken
Zonder een goed geconfigureerde Azure Firewall zijn Azure Virtual Networks en workloads direct blootgesteld aan ongefilterd netwerkverkeer van en naar internet, andere cloudomgevingen en on-premises netwerken. Dit creëert aanzienlijke beveiligingsrisico's: kwaadaardige verkeer kan vrijelijk binnenkomen via uitgaande verbindingen naar gecompromitteerde websites of command-and-control servers, waardoor malware en ransomware zich kunnen verspreiden naar andere systemen binnen het netwerk. Zonder gecentraliseerde netwerkfiltering ontstaat versnippering van beveiligingsbeleid waarbij verschillende teams verschillende regels en configuraties toepassen, wat leidt tot inconsistente beveiligingsniveaus en compliance-hiaten. Het ontbreken van threat intelligence-integratie betekent dat organisaties niet profiteren van real-time updates over bekende kwaadaardige IP-adressen en domeinen, waardoor zij achterlopen op nieuwe dreigingen. Daarnaast ontbreekt zonder Azure Firewall vaak centraal zicht op netwerkverkeer: logging is verspreid over verschillende services, waardoor het moeilijk wordt om netwerkaanvallen te detecteren, te analyseren en te reageren. Voor Nederlandse overheidsorganisaties die moeten voldoen aan BIO, NIS2 en ISO 27001 is dit onacceptabel: deze frameworks vereisen expliciete netwerkbeveiligingscontroles, gecentraliseerde logging en monitoring, en aantoonbare maatregelen tegen bekende bedreigingen. Azure Firewall biedt deze capaciteiten in één volledig beheerde service die automatisch schaalt met de behoeften van de organisatie.
Connection:
Connect-AzAccountRequired Modules: Az.Network, Az.Resources, Az.Accounts
Implementatie
Dit artikel beschrijft hoe organisaties binnen de Nederlandse Baseline voor Veilige Cloud Azure Firewall implementeren en configureren als robuuste, centraal beheerde netwerkbeveiligingslaag. De focus ligt op vier hoofdcomponenten. Ten eerste architectuur en ontwerp: het kiezen tussen Standard en Premium tier, het ontwerpen van subnetconfiguraties, het plannen van IP-adresruimte en het integreren van Azure Firewall in bestaande netwerkarchitecturen zoals hub-spoke topologieën of mesh-netwerken. Ten tweede basisconfiguratie en implementatie: het maken van Azure Firewall-resources, het configureren van netwerkregels voor IP- en poortgebaseerde filtering, het instellen van applicatieregels voor FQDN-filtering en het configureren van NAT-regels voor inkomend verkeer. Ten derde geavanceerde functies: het activeren van threat intelligence-feeds, het configureren van DNS-proxy, het implementeren van TLS-inspectie (Premium tier) en het integreren met Azure Monitor en Log Analytics voor uitgebreide logging en monitoring. Ten vierde operationalisatie en governance: het opzetten van change management-processen, het definiëren van verantwoordelijkheden, het implementeren van periodieke reviews en het borgen van compliance met relevante frameworks. Het bijbehorende PowerShell-script inventariseert alle Azure Firewall-implementaties in een abonnement, controleert of firewalls correct zijn geconfigureerd met logging, threat intelligence en passende regels, en identificeert ontbrekende of verouderde configuraties die beveiligingsrisico's kunnen vormen.
Architectuur en planning van Azure Firewall
Een effectieve implementatie van Azure Firewall begint bij een doordacht architectuurontwerp dat aansluit bij de netwerkbehoeften, beveiligingsvereisten en compliance-verplichtingen van de organisatie. In plaats van Azure Firewall ad-hoc toe te voegen aan bestaande netwerken, is het essentieel om vanuit een referentiearchitectuur te werken waarin netwerkverkeer logisch wordt gerouteerd en gefilterd. Voor Nederlandse overheidsorganisaties zijn er verschillende architectuurpatronen mogelijk: een hub-spoke topologie waarbij Azure Firewall centraal in een hub Virtual Network wordt geplaatst en alle verkeer van en naar spoke-netwerken via deze firewall wordt gerouteerd, een gedistribueerde aanpak waarbij meerdere Azure Firewall-instances worden geïmplementeerd per regio of per workload-categorie, of een hybride model waarbij Azure Firewall wordt gecombineerd met on-premises firewalls voor end-to-end beveiliging. De keuze hangt af van factoren zoals de schaal van de omgeving, de geografische spreiding, de kostenoverwegingen en de gewenste mate van centralisatie versus decentralisatie van beveiligingscontroles.
Een kritieke architectuurkeuze betreft de selectie tussen Azure Firewall Standard en Premium tier. De Standard tier biedt basis firewall-functionaliteiten inclusief stateful packet inspection, netwerk- en applicatieregels, FQDN-filtering, threat intelligence-feeds en basis logging. Deze tier is geschikt voor de meeste workloads en biedt een kosteneffectieve oplossing voor organisaties die geen geavanceerde functies zoals TLS-inspectie of URL-filtering nodig hebben. De Premium tier voegt hieraan toe: TLS-inspectie voor diepgaande analyse van versleuteld verkeer, geavanceerde URL-filtering met categoriegebaseerde filtering, webcategorisatie voor betere zichtbaarheid en controle, en geavanceerde intrusion detection en prevention system (IDPS) capaciteiten. Voor organisaties die werken met gevoelige data, strikte compliance-vereisten of geavanceerde bedreigingsdetectie nodig hebben, is de Premium tier aanbevolen. De kostenverschillen zijn aanzienlijk: Standard tier kost ongeveer €1,25 per uur (circa €900 per maand) plus dataverkeer, terwijl Premium tier aanzienlijk duurder is maar extra beveiligingslagen biedt. Organisaties moeten een kosten-batenanalyse uitvoeren waarbij de extra beveiligingswaarde wordt afgewogen tegen de hogere operationele kosten.
Subnetconfiguratie vormt een fundamenteel onderdeel van de Azure Firewall-architectuur. Azure Firewall vereist een dedicated subnet genaamd AzureFirewallSubnet met een minimale grootte van /26 (64 IP-adressen) voor Standard tier en /25 (128 IP-adressen) voor Premium tier. Dit subnet mag geen andere resources bevatten en moet worden geplaatst in een Virtual Network dat voldoende adresruimte heeft voor zowel de firewall als andere benodigde subnets. Bij het plannen van IP-adresruimte moeten organisaties rekening houden met toekomstige groei: het is verstandig om ruimte te reserveren voor uitbreiding, failover-scenario's en mogelijke migraties. Het subnet moet worden geconfigureerd zonder een route table die verkeer omleidt, omdat Azure Firewall zijn eigen routing-logica heeft. Voor hub-spoke topologieën wordt het AzureFirewallSubnet typisch geplaatst in het hub Virtual Network, terwijl voor gedistribueerde architecturen elk Virtual Network dat een firewall nodig heeft zijn eigen dedicated subnet vereist.
Netwerkroutering is een complex maar essentieel aspect van Azure Firewall-architectuur. Om ervoor te zorgen dat verkeer daadwerkelijk door de firewall wordt gerouteerd, moeten User Defined Routes (UDR's) worden geconfigureerd die verkeer naar de firewall sturen. Voor uitgaand verkeer moeten route tabellen worden gekoppeld aan subnetten waar workloads draaien, met een default route (0.0.0.0/0) die naar het private IP-adres van Azure Firewall wijst. Voor inkomend verkeer via NAT-regels moet verkeer naar het publieke IP-adres van de firewall worden gerouteerd, waarna de firewall het verkeer vertaalt naar interne resources. Het is cruciaal om te voorkomen dat workloads directe routes naar internet hebben die de firewall omzeilen: alle verkeer moet geforceerd worden via de firewall om consistente beveiligingscontroles te garanderen. Voor hybride scenario's waarbij Azure Firewall wordt gecombineerd met on-premises netwerken via VPN of ExpressRoute, moeten route tabellen zorgvuldig worden geconfigureerd om ervoor te zorgen dat verkeer tussen on-premises en Azure correct wordt gefilterd zonder routing loops te creëren.
Beschikbaarheid en schaalbaarheid zijn belangrijke overwegingen in de architectuur. Azure Firewall biedt ingebouwde high availability via zone-redundantie wanneer de firewall wordt geïmplementeerd in regio's die beschikbaarheidszones ondersteunen. Voor kritieke workloads moeten organisaties zone-redundante configuraties gebruiken om bescherming te bieden tegen datacenter-uitval. Autoscaling is beschikbaar voor Azure Firewall, waardoor de service automatisch kan schalen op basis van verkeersvolume. Organisaties moeten echter rekening houden met de implicaties van schaling: tijdens piekperioden kunnen extra kosten ontstaan, en er kunnen korte vertragingen optreden tijdens schaaloperaties. Voor voorspelbare workloads kan het zinvol zijn om de minimale capaciteit te configureren om kosten te beheersen, terwijl voor variabele workloads autoscaling de voorkeur heeft om te zorgen voor voldoende capaciteit tijdens piekperioden zonder overprovisioning tijdens rustige perioden.
Implementatie en basisconfiguratie
De implementatie van Azure Firewall begint met het voorbereiden van de benodigde infrastructuurcomponenten. Allereerst moet een Virtual Network worden geconfigureerd met voldoende adresruimte voor het AzureFirewallSubnet en andere benodigde subnets. Het subnet moet worden aangemaakt met de exacte naam 'AzureFirewallSubnet' en een minimale grootte van /26 voor Standard tier of /25 voor Premium tier. Vervolgens moet een publiek IP-adres worden gereserveerd voor de firewall: dit IP-adres wordt gebruikt voor uitgaand verkeer en voor inkomend verkeer via NAT-regels. Het is aanbevolen om een statisch publiek IP-adres te gebruiken in plaats van een dynamisch adres, omdat dit zorgt voor consistentie in firewallregels en omdat sommige externe services mogelijk IP-adresgebaseerde whitelisting vereisen. Voor zone-redundante configuraties moeten meerdere publieke IP-adressen worden geconfigureerd, één per beschikbaarheidszone.
Na de infrastructuurvoorbereiding kan de Azure Firewall-resource zelf worden aangemaakt. Tijdens het aanmaken moeten verschillende configuratie-opties worden gekozen: de resourcegroep en locatie waar de firewall wordt geïmplementeerd, de firewall-naam die beschrijvend moet zijn en de organisatie-standaarden volgt, de tier-selectie (Standard of Premium), en de koppeling aan het voorbereide Virtual Network en AzureFirewallSubnet. Voor Premium tier moeten aanvullende configuraties worden gekozen zoals de activering van TLS-inspectie en de selectie van certificaten voor certificaatvalidatie. Na het aanmaken duurt het enkele minuten voordat de firewall volledig is geïmplementeerd en operationeel is. Gedurende deze tijd wordt de firewall geïnitialiseerd, worden netwerkverbindingen geconfigureerd en worden de benodigde resources gealloceerd.
Firewallregels vormen het hart van de beveiligingsconfiguratie en moeten zorgvuldig worden ontworpen en geïmplementeerd. Azure Firewall ondersteunt drie typen regels: netwerkregels voor IP- en poortgebaseerde filtering, applicatieregels voor FQDN-gebaseerde filtering op Layer 7, en NAT-regels voor het vertalen van inkomend verkeer naar interne resources. Netwerkregels worden gebruikt om verkeer te filteren op basis van bron- en doel-IP-adressen en poorten, wat geschikt is voor protocollen zoals TCP en UDP waar geen applicatielaag-inspectie nodig is. Applicatieregels werken op FQDN-niveau en kunnen worden gebruikt om toegang tot specifieke websites of services toe te staan of te weigeren, wat nuttig is voor het controleren van uitgaand webverkeer. NAT-regels vertalen inkomend verkeer van het publieke IP-adres van de firewall naar interne private IP-adressen en poorten, waardoor services veilig kunnen worden blootgesteld aan internet zonder directe publieke IP-adressen op workloads. Regels worden georganiseerd in rule collections met een prioriteit: regels met een lagere prioriteitswaarde worden eerst geëvalueerd, en zodra een regel matcht wordt verdere evaluatie gestopt. Deze prioritering is cruciaal voor de correcte werking van de firewall en moet zorgvuldig worden gepland.
Threat intelligence-integratie is een krachtige functie die Azure Firewall in staat stelt om automatisch verkeer te blokkeren dat afkomstig is van bekende kwaadaardige IP-adressen en domeinen. Deze integratie maakt gebruik van Microsoft Threat Intelligence-feeds die continu worden bijgewerkt met informatie over nieuwe bedreigingen. Wanneer threat intelligence is ingeschakeld, worden alle verkeer automatisch gecontroleerd tegen deze feeds, en verkeer dat matcht met bekende bedreigingen wordt automatisch geblokkeerd en gelogd. Deze functie is standaard beschikbaar in zowel Standard als Premium tier en moet altijd worden ingeschakeld voor productieomgevingen. Organisaties kunnen kiezen tussen twee modi: Alert-modus waarbij bedreigingen worden gelogd maar niet geblokkeerd (nuttig voor testing), en Deny-modus waarbij bedreigingen daadwerkelijk worden geblokkeerd (aanbevolen voor productie). De threat intelligence-feeds worden automatisch bijgewerkt door Microsoft, waardoor organisaties profiteren van de nieuwste dreigingsinformatie zonder handmatige interventie.
Gebruik PowerShell-script azure-firewall-deployment.ps1 (functie Invoke-Monitoring) – Voert een monitoringcontrole uit op Azure Firewall-implementaties om te bepalen of firewalls correct zijn geconfigureerd met logging, threat intelligence en passende regels..
Geavanceerde functies en optimalisatie
Azure Firewall Premium biedt geavanceerde functies die organisaties in staat stellen om dieper inzicht te krijgen in netwerkverkeer en geavanceerde bedreigingen te detecteren en te blokkeren. TLS-inspectie is een van de meest krachtige functies van Premium tier: het stelt de firewall in staat om versleuteld HTTPS-verkeer te ontsleutelen, te inspecteren en opnieuw te versleutelen voordat het naar de bestemming wordt doorgestuurd. Dit maakt het mogelijk om kwaadaardige payloads te detecteren die anders verborgen zouden blijven in versleuteld verkeer, zoals malware-downloads, command-and-control communicatie en data exfiltration. TLS-inspectie vereist certificaatbeheer: de firewall moet worden geconfigureerd met certificaten die worden gebruikt om verkeer te ontsleutelen, en client-applicaties moeten worden geconfigureerd om deze certificaten te vertrouwen. Dit kan complex zijn in omgevingen met veel verschillende applicaties en vereist zorgvuldige planning en testing om te voorkomen dat legitiem verkeer wordt geblokkeerd. Voor Nederlandse overheidsorganisaties kan TLS-inspectie compliance-uitdagingen opleveren met betrekking tot privacy en gegevensbescherming, en moet daarom worden geëvalueerd in het licht van AVG-vereisten en interne privacybeleid.
URL-filtering en webcategorisatie zijn aanvullende Premium tier-functies die organisaties in staat stellen om verkeer te filteren op basis van websitecategorieën in plaats van alleen specifieke FQDN's. Met URL-filtering kunnen organisaties bijvoorbeeld alle verkeer naar sociale media, streamingdiensten of gaming-websites blokkeren, ongeacht de specifieke domeinnamen. Webcategorisatie biedt inzicht in welke categorieën websites worden bezocht, wat nuttig is voor compliance-monitoring en gebruikersgedraganalyse. Deze functies maken gebruik van Microsoft's webcategorisatiedatabase die continu wordt bijgewerkt met nieuwe websites en categorieën. Organisaties kunnen custom policies configureren die verschillende acties definiëren voor verschillende categorieën: bijvoorbeeld Allow voor zakelijke productiviteitstools, Block voor malware en phishing-sites, en Alert voor entertainment-categorieën. Deze granulariteit stelt organisaties in staat om een balans te vinden tussen beveiliging, productiviteit en gebruikerservaring.
DNS-proxy configuratie is een functie die beschikbaar is in zowel Standard als Premium tier en die organisaties in staat stelt om DNS-verzoeken te centraliseren en te monitoren via Azure Firewall. Wanneer DNS-proxy is ingeschakeld, worden alle DNS-verzoeken van workloads in het Virtual Network gerouteerd via de firewall, waardoor de firewall DNS-verzoeken kan loggen, filteren en analyseren. Dit is nuttig voor het detecteren van kwaadaardige domeinen, het blokkeren van toegang tot bekende malware-domeinen, en het verkrijgen van inzicht in welke externe services worden benaderd. DNS-proxy kan worden geconfigureerd met custom DNS-servers, waardoor organisaties kunnen kiezen welke DNS-resolvers worden gebruikt. Voor organisaties die werken met gevoelige data kan het zinvol zijn om interne DNS-servers te gebruiken in plaats van publieke DNS-resolvers zoals Google DNS of Cloudflare DNS, om te voorkomen dat DNS-verzoeken worden blootgesteld aan externe partijen.
Logging en monitoring zijn essentieel voor effectief beheer en security operations. Azure Firewall integreert naadloos met Azure Monitor en Log Analytics, waardoor organisaties gedetailleerde logs kunnen verzamelen van alle netwerkverkeer dat door de firewall wordt verwerkt. Er zijn verschillende logcategorieën beschikbaar: Application Rule logs bevatten informatie over verkeer dat wordt geëvalueerd tegen applicatieregels, Network Rule logs bevatten informatie over verkeer dat wordt geëvalueerd tegen netwerkregels, Threat Intelligence logs bevatten informatie over verkeer dat wordt geblokkeerd door threat intelligence-feeds, en DNS Proxy logs bevatten informatie over DNS-verzoeken wanneer DNS-proxy is ingeschakeld. Deze logs kunnen worden gebruikt om Kusto-query's te maken die inzicht geven in verkeerspatronen, bedreigingen, en compliance-status. Organisaties moeten ervoor zorgen dat diagnostische instellingen correct zijn geconfigureerd om logs naar een centrale Log Analytics-workspace te sturen, en moeten retentiebeleid instellen die voldoen aan compliance-vereisten (typisch 7 jaar voor Nederlandse overheidsorganisaties volgens BIO). 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 afwijkingen in verkeerspatronen die kunnen wijzen op een aanval.
Gebruik PowerShell-script azure-firewall-deployment.ps1 (functie Invoke-Remediation) – Genereert een gedetailleerd overzicht van Azure Firewall-configuraties en identificeert ontbrekende of suboptimale instellingen die moeten worden aangepast..
Beheer, governance en compliance
Effectief beheer van Azure Firewall vereist duidelijke governance-structuren, gedefinieerde processen en continue monitoring. Organisaties moeten vastleggen wie verantwoordelijk is voor het dagelijks beheer van Azure Firewall, wie firewallregels mag toevoegen of wijzigen, en hoe wijzigingen worden gecontroleerd en goedgekeurd. Role-Based Access Control (RBAC) in Azure moet worden gebruikt om toegang te beperken tot alleen die personen en rollen die daadwerkelijk firewallbeheer nodig hebben. Het is aanbevolen om verschillende rollen te definiëren: firewallbeheerders die volledige controle hebben over firewallconfiguraties, regelbeheerders die regels kunnen toevoegen en wijzigen maar geen fundamentele configuraties kunnen aanpassen, en lezers die alleen monitoring en rapportage kunnen uitvoeren. Just-in-Time-toegang via Azure Privileged Identity Management kan worden gebruikt om beheeracties te beperken in tijd en scope, waardoor het risico van misbruik wordt verminderd.
Change management is cruciaal voor het voorkomen van configuratiefouten en het borgen van compliance. Alle wijzigingen aan firewallregels moeten worden gedocumenteerd met informatie over wie de wijziging heeft aangevraagd, waarom de wijziging nodig is, welke risico's zijn geëvalueerd, en wie de wijziging heeft goedgekeurd. Voor productieomgevingen moeten wijzigingen eerst worden getest in een niet-productieomgeving om te verifiëren dat de wijzigingen werken zoals bedoeld en geen onbedoelde gevolgen hebben. Wijzigingen moeten worden gepland tijdens onderhoudsvensters wanneer mogelijk, en er moeten rollback-plannen zijn voor het geval een wijziging problemen veroorzaakt. Azure Firewall biedt de mogelijkheid om rule collections te versieren, wat nuttig is voor het testen van nieuwe regels voordat ze volledig worden geactiveerd. Organisaties moeten een changelog bijhouden waarin alle wijzigingen worden vastgelegd, inclusief datum, tijd, persoon, reden en impact, voor auditdoeleinden en troubleshooting.
Periodieke reviews en audits zijn essentieel om te waarborgen dat firewallconfiguraties up-to-date blijven en aansluiten bij veranderende bedrijfsbehoeften en beveiligingsvereisten. Organisaties moeten minimaal kwartaalgewijs een review uitvoeren van alle firewallregels om te verifiëren dat regels nog steeds nodig zijn, correct zijn geconfigureerd, en voldoen aan het principe van least privilege. Tijdens deze reviews moeten ongebruikte regels worden geïdentificeerd en verwijderd, brede regels moeten worden aangescherpt waar mogelijk, en nieuwe bedrijfsvereisten moeten worden geëvalueerd voor nieuwe regels. Daarnaast moeten threat intelligence-feeds worden gecontroleerd om te verifiëren dat ze actief zijn en correct werken, moeten logging-configuraties worden gecontroleerd om te waarborgen dat alle benodigde logs worden verzameld, en moeten performance-metrics worden geanalyseerd om te identificeren of de firewall voldoende capaciteit heeft. Deze reviews moeten worden gedocumenteerd en gerapporteerd aan security- en risicocomités, en bevindingen moeten worden vertaald naar concrete verbeteracties met eigenaren en deadlines.
Compliance met relevante frameworks zoals BIO, ISO 27001 en NIS2 vereist dat organisaties kunnen aantonen dat Azure Firewall correct is geconfigureerd en effectief werkt. Tijdens audits moeten organisaties kunnen laten zien: dat alle kritieke netwerkverkeer wordt gefilterd via Azure Firewall, dat threat intelligence is ingeschakeld en actief bedreigingen blokkeert, dat logging correct is geconfigureerd en logs worden bewaard volgens de vereiste retentietermijnen, dat firewallregels regelmatig worden gereviewd en bijgewerkt, en dat er processen zijn voor incidentdetectie en -respons op basis van firewall-logs. Het bijbehorende PowerShell-script kan worden gebruikt om compliance-rapportages te genereren die aantonen welke firewalls zijn geïmplementeerd, hoe ze zijn geconfigureerd, en of ze voldoen aan de gestelde eisen. 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.
Compliance, auditing en verantwoording
Azure Firewall-implementatie raakt direct aan meerdere compliancekaders waar Nederlandse overheidsorganisaties aan gebonden zijn. Vanuit de Baseline Informatiebeveiliging Overheid (BIO) geldt dat netwerkverkeer moet worden gefilterd en gemonitord om ongeautoriseerde toegang en kwaadaardige activiteiten te voorkomen. Control 13.01 vereist expliciet dat organisaties netwerkfiltering implementeren, en Azure Firewall vormt een belangrijk onderdeel van het bewijs dat deze vereiste wordt nageleefd. Tijdens BIO-audits wordt niet alleen gekeken naar het bestaan van een firewall, maar vooral naar de kwaliteit van de configuratie, de wijze van beheer, de monitoringresultaten en de aansluiting op incidentresponsprocessen. Organisaties moeten kunnen aantonen dat threat intelligence is ingeschakeld, dat logs worden bewaard voor de vereiste 7-jarige periode, en dat regelmatige reviews plaatsvinden om te waarborgen dat configuraties up-to-date blijven.
ISO 27001:2022 legt in control A.8.20 nadruk op netwerkbeveiliging en vereist dat organisaties netwerkbeveiligingscontroles implementeren om te beschermen tegen bedreigingen. Azure Firewall voldoet aan deze vereiste door geavanceerde firewallfunctionaliteiten te bieden, inclusief stateful packet inspection, threat intelligence-integratie en gedetailleerde logging. De implementatie moet onderdeel zijn van een breder Information Security Management System (ISMS) waarin beleid, procedures, rollen en verantwoordelijkheden zijn gedocumenteerd. Organisaties moeten kunnen aantonen dat de keuze voor Azure Firewall voortkomt uit een risicoafweging, dat firewallregels zijn gebaseerd op bedrijfsvereisten en beveiligingsbeleid, en dat er processen zijn voor het beoordelen en bijwerken van configuraties. Auditors zullen willen zien dat uitzonderingen en custom rules niet ad-hoc worden toegevoegd, maar dat elke wijziging een eigenaar, motivatie en goedkeuringsproces heeft.
De Network and Information Systems Directive 2 (NIS2) stelt in artikel 21 specifieke eisen aan netwerkbeveiliging en monitoring voor essentiële en belangrijke entiteiten. Deze richtlijn vereist dat organisaties passende en evenredige technische en organisatorische maatregelen nemen om beveiligingsrisico's te beheren, inclusief maatregelen voor netwerkbeveiliging, detectie en incidentrespons. Azure Firewall voldoet aan deze vereiste door geavanceerde netwerkbeveiliging te bieden met threat intelligence-integratie, automatische updates van dreigingsinformatie en gedetailleerde logging van alle netwerkactiviteiten. Organisaties moeten kunnen aantonen dat incidentresponsprocedures correct zijn gedocumenteerd, dat beveiligingsincidenten tijdig worden gedetecteerd via firewall-logs en alerts, en dat incidenten worden gemeld aan de relevante autoriteiten volgens de vereiste meldplichten. Het bijbehorende PowerShell-script kan worden gebruikt om compliance-rapportages te genereren die aantonen hoe NIS2-vereisten worden ingevuld.
Voor verantwoording richting bestuur en politiek is het belangrijk dat de complexiteit van Azure Firewall wordt vertaald naar begrijpelijke stuurinformatie. Bestuurders hoeven niet te weten welke individuele firewallregels actief zijn, maar wel of alle kritieke netwerkverkeer wordt gefilterd, hoeveel bedreigingen worden gedetecteerd en geblokkeerd, of er recente incidenten zijn geweest die door de firewall zijn tegengehouden, en welke rest-risico's nog geaccepteerd worden. Deze informatie kan worden samengevat in periodieke rapportages en dashboards die onderdeel zijn van de bredere rapportagelijn over cyberweerbaarheid. Voor Nederlandse overheidsorganisaties draagt dit bij aan transparante verantwoording richting gemeenteraad, Provinciale Staten, Tweede Kamer of toezichthouders en ondersteunt het bij het onderbouwen van investeringen in verdere versterking van digitale weerbaarheid.
Compliance & Frameworks
- CIS M365: Control 6.4, 6.5 (L1/L2) - Implementeer Azure Firewall voor gecentraliseerde netwerkbeveiliging en borg netwerkfiltering in lijn met de CIS Azure Foundations Benchmark.
- BIO: 13.01, 14.02 - Netwerkfiltering en logging voor internetgerichte diensten binnen de Baseline Informatiebeveiliging Overheid.
- ISO 27001:2022: A.8.20, A.8.33 - Netwerkbeveiliging en monitoring van beveiligingsgebeurtenissen in het kader van een Information Security Management System.
- NIS2: Artikel - 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 vormt een verplichte beveiligingslaag voor Azure Virtual Networks binnen de Nederlandse Baseline voor Veilige Cloud. Door een gestandaardiseerde architectuur, moderne firewallconfiguratie met threat intelligence en strakke integratie met Azure Monitor en Log Analytics te implementeren, worden netwerkaanvallen vroegtijdig gedetecteerd en geblokkeerd en wordt een rijk beeld van dreigingen opgebouwd. Het bijbehorende PowerShell-script inventariseert automatisch welke Azure Firewall-implementaties aanwezig zijn, hoe ze zijn geconfigureerd en of ze voldoen aan de gestelde eisen, zodat hiaten snel zichtbaar worden. De benodigde inspanning is beperkt (circa 44 uur initiële implementatie), terwijl de risicoreductie en auditbaarheid aanzienlijk zijn voor alle netwerkgebaseerde diensten in Azure.
- Implementatietijd: 44 uur
- FTE required: 0.25 FTE