L1/L2 BIO 13.01 ISO A.8.20 CIS 6.3, 6.4, 6.15

Azure Network Security Groups: Fundament Voor Netwerkbeveiliging

📅 2025-01-15
•
⏱️ 30 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Azure Network Security Groups (NSG's) vormen het fundament van netwerkbeveiliging binnen Azure Virtual Networks en zijn essentieel voor het implementeren van een verdedigingsstrategie in meerdere lagen. Als stateful firewalls op netwerkniveau bieden NSG's gedetailleerde controle over inkomend en uitgaand verkeer naar Azure-resources zoals virtuele machines, subnetten en netwerkinterfaces. In tegenstelling tot traditionele hardware firewalls werken NSG's als gedistribueerde beveiligingscontroles die direct zijn geïntegreerd in de Azure-netwerkinfrastructuur, waardoor organisaties granulair verkeer kunnen filteren op basis van bron- en doel-IP-adressen, poorten, protocollen en service tags. Voor Nederlandse overheidsorganisaties die moeten voldoen aan BIO, NIS2 en ISO 27001 vormen NSG's een verplichte beveiligingslaag die voorkomt dat ongeautoriseerd verkeer kritieke workloads bereikt en die laterale beweging van aanvallers binnen netwerken beperkt.

Aanbeveling
IMPLEMENTEER NETWORK SECURITY GROUPS VOOR ALLE KRITIEKE NETWERKRESOURCES
Risico zonder
High
Risk Score
9/10
Implementatie
56u (tech: 40u)
Van toepassing op:
✓ Azure Virtual Networks
✓ Azure Subnets
✓ Network Interfaces
✓ Hybride netwerken

Zonder correct geconfigureerde Network Security Groups zijn Azure-resources direct blootgesteld aan ongefilterd netwerkverkeer, wat aanzienlijke beveiligingsrisico's creëert. Virtuele machines kunnen worden benaderd vanaf ongeautoriseerde bronnen, gevoelige data kan worden blootgesteld via onbeveiligde poorten, en aanvallers kunnen laterale beweging uitvoeren tussen subnetten zonder detectie. Het ontbreken van NSG's betekent dat organisaties geen granulair controle hebben over welke services toegankelijk zijn, welke IP-adressen verbindingen mogen maken, en welke protocollen zijn toegestaan. Dit schendt fundamentele beveiligingsprincipes zoals least privilege en defense in depth, waardoor organisaties kwetsbaar zijn voor ransomware-aanvallen, data exfiltration, en ongeautoriseerde toegang tot kritieke systemen. Voor Nederlandse overheidsorganisaties die moeten voldoen aan compliance-frameworks zoals BIO norm 13.01 (netwerkbeveiliging), ISO 27001:2022 controle A.8.20 (netwerkbeveiliging) en NIS2 artikel 21 (technische maatregelen) is het ontbreken van NSG's onacceptabel: deze frameworks vereisen expliciete netwerkfiltering, logging van netwerkactiviteiten en aantoonbare maatregelen tegen netwerkgebaseerde bedreigingen. Tijdens audits zal het ontbreken van NSG's worden gezien als een structurele tekortkoming in de technische beveiligingsmaatregelen die kan leiden tot negatieve auditbevindingen en mogelijke boetes.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Network, Az.Resources, Az.Accounts

Implementatie

Dit artikel beschrijft hoe organisaties binnen de Nederlandse Baseline voor Veilige Cloud Network Security Groups implementeren en configureren als fundamentele netwerkbeveiligingslaag. De focus ligt op vijf hoofdcomponenten. Ten eerste architectuur en ontwerp: het begrijpen van hoe NSG's werken binnen Azure Virtual Networks, het plannen van NSG-structuren voor verschillende workloads, het ontwerpen van regelprioriteiten en het integreren van NSG's in bestaande netwerkarchitecturen zoals hub-spoke topologieën. Ten tweede basisconfiguratie en implementatie: het maken van NSG-resources, het configureren van inkomende en uitgaande beveiligingsregels, het gebruik van service tags en application security groups voor vereenvoudigd beheer, en het koppelen van NSG's aan subnetten en netwerkinterfaces. Ten derde geavanceerde functies: het implementeren van NSG Flow Logs voor netwerkzichtbaarheid, het gebruik van Azure Policy voor consistente NSG-configuraties, het configureren van diagnostische instellingen voor logging en monitoring, en het integreren met Azure Monitor en Log Analytics voor uitgebreide netwerkanalyse. Ten vierde beveiligingsbest practices: het toepassen van het principe van least privilege, het implementeren van default deny-regels, het regelmatig reviewen en optimaliseren van NSG-regels, en het voorkomen van overbrede regels die beveiligingsrisico's introduceren. Ten vijfde operationalisatie en governance: het opzetten van change management-processen voor NSG-wijzigingen, het definiëren van verantwoordelijkheden, het implementeren van periodieke reviews en het borgen van compliance met relevante frameworks. Het bijbehorende PowerShell-script inventariseert alle NSG's in een abonnement, controleert of NSG's correct zijn geconfigureerd met passende regels en logging, en identificeert ontbrekende of suboptimale configuraties die beveiligingsrisico's kunnen vormen.

Architectuur en fundamenten van Network Security Groups

Network Security Groups vormen een fundamenteel onderdeel van de Azure-netwerkbeveiligingsarchitectuur en werken als stateful, gedistribueerde firewalls die netwerkverkeer filteren op basis van gedefinieerde regels. In tegenstelling tot traditionele perimeter firewalls die op een centraal punt worden geplaatst, worden NSG's geïmplementeerd als software-defined netwerkbeveiligingscontroles die direct zijn geïntegreerd in de Azure-netwerkinfrastructuur. Deze architectuur biedt verschillende voordelen: NSG's kunnen worden gekoppeld aan subnetten voor netwerksegmentatie, aan netwerkinterfaces voor granulair verkeersfiltering op VM-niveau, of aan beide voor gelaagde beveiliging. Wanneer een NSG is gekoppeld aan een subnet, worden alle resources binnen dat subnet beschermd door dezelfde set regels, wat zorgt voor consistente beveiliging en vereenvoudigd beheer. Wanneer een NSG is gekoppeld aan een specifieke netwerkinterface, kan die interface unieke beveiligingsregels hebben die verschillen van de subnet-NSG, wat flexibiliteit biedt voor workloads met specifieke beveiligingsvereisten.

De evaluatie van NSG-regels volgt een strikte prioriteitsvolgorde die cruciaal is voor het begrijpen van hoe verkeer wordt gefilterd. Elke regel heeft een prioriteitsnummer tussen 100 en 4096, waarbij lagere nummers een hogere prioriteit hebben en eerder worden geëvalueerd. Azure evalueert regels in oplopende volgorde van prioriteit, en zodra een regel matcht wordt verdere evaluatie gestopt en wordt de actie van die regel (Allow of Deny) toegepast. Deze prioritering is essentieel voor de correcte werking van NSG's: organisaties moeten zorgvuldig prioriteiten toewijzen om te voorkomen dat brede regels specifiekere regels overschrijven, of dat deny-regels per ongeluk allow-regels blokkeren. Binnen elke prioriteit worden regels georganiseerd in categorieën: eerst worden alle inkomende regels geëvalueerd, daarna alle uitgaande regels. Binnen elke categorie worden eerst expliciete regels geëvalueerd, en als geen regel matcht worden de standaardregels toegepast. De standaardregels zijn altijd actief en kunnen niet worden verwijderd: ze staan alle uitgaande verkeer toe, staan alle inkomende verkeer binnen het Virtual Network toe, staan inkomende verkeer van Azure Load Balancer toe, en blokkeren al het andere inkomende verkeer. Deze standaardregels vormen een basislaag van beveiliging, maar organisaties moeten expliciete regels toevoegen om specifieke services en workloads te beveiligen.

Service tags vormen een krachtige functie die het beheer van NSG-regels aanzienlijk vereenvoudigt door groepen van IP-adressen te representeren die door Microsoft worden beheerd. In plaats van individuele IP-adressen of CIDR-blokken te specificeren, kunnen organisaties service tags gebruiken zoals VirtualNetwork (alle IP-adressen binnen het Virtual Network), AzureLoadBalancer (Azure Load Balancer), Internet (alle publieke IP-adressen), of specifieke Azure-services zoals Storage, Sql, of KeyVault. Deze service tags worden automatisch bijgewerkt door Microsoft wanneer IP-adressen van services wijzigen, waardoor organisaties niet handmatig IP-adresbereiken hoeven bij te werken. Dit is vooral waardevol voor services die regelmatig van IP-adres wijzigen of die IP-adressen gebruiken in meerdere regio's. Service tags verminderen ook de complexiteit van NSG-regels en maken het gemakkelijker om regels te begrijpen en te onderhouden. Voor Nederlandse overheidsorganisaties die werken met Azure Government of Azure China kunnen specifieke service tags beschikbaar zijn die verschillen van commerciële Azure-regio's, en organisaties moeten ervoor zorgen dat ze de juiste service tags gebruiken voor hun omgeving.

Application Security Groups (ASG's) bieden een alternatieve manier om NSG-regels te definiëren op basis van applicatie- of workload-identiteit in plaats van IP-adressen. In plaats van regels te definiëren die specifieke IP-adressen of subnetten targeten, kunnen organisaties netwerkinterfaces toewijzen aan Application Security Groups en vervolgens NSG-regels definiëren die deze ASG's als bron of doel gebruiken. Dit maakt het mogelijk om beveiligingsregels te definiëren op basis van de rol of functie van een workload, ongeacht waar die workload zich bevindt in het netwerk. Bijvoorbeeld, een organisatie kan een ASG maken genaamd 'WebServers' en alle netwerkinterfaces van web servers toewijzen aan deze ASG. Vervolgens kunnen NSG-regels worden gedefinieerd die verkeer van de 'WebServers' ASG naar de 'DatabaseServers' ASG toestaan, zonder dat specifieke IP-adressen hoeven te worden gekend. Deze aanpak maakt netwerkbeveiliging meer schaalbaar en onderhoudbaar, vooral in dynamische omgevingen waar workloads regelmatig worden verplaatst of waar IP-adressen kunnen wijzigen. ASG's werken alleen binnen hetzelfde Virtual Network en kunnen niet worden gebruikt voor verkeer tussen verschillende Virtual Networks of voor verkeer van en naar internet.

De integratie van NSG's in netwerkarchitecturen vereist zorgvuldige planning om te voorkomen dat beveiligingsregels conflicteren of dat verkeer onbedoeld wordt geblokkeerd. In hub-spoke topologieën worden NSG's typisch geïmplementeerd op zowel hub- als spoke-subnetten, waarbij hub-NSG's worden geconfigureerd voor gedeelde services en spoke-NSG's worden geconfigureerd voor workloadspecifieke vereisten. Voor hybride netwerken waarbij Azure Virtual Networks zijn verbonden met on-premises netwerken via VPN of ExpressRoute, moeten NSG-regels rekening houden met on-premises IP-adresbereiken en moeten organisaties ervoor zorgen dat legitiem verkeer tussen on-premises en Azure niet wordt geblokkeerd. Het is belangrijk om te begrijpen dat NSG's alleen verkeer filteren dat door Azure-netwerken gaat: verkeer dat via ExpressRoute of VPN gaat wordt gefilterd door NSG's, maar verkeer dat via Azure Firewall of andere netwerk virtuele appliances gaat wordt eerst door die appliances gefilterd voordat het NSG's bereikt. Organisaties moeten hun netwerkarchitectuur documenteren en duidelijk maken waar NSG's worden toegepast en hoe ze samenwerken met andere beveiligingscontroles zoals Azure Firewall, Network Virtual Appliances en on-premises firewalls.

Implementatie en configuratie van Network Security Groups

De implementatie van Network Security Groups begint met het maken van de NSG-resource zelf, wat kan worden gedaan via Azure Portal, Azure CLI, PowerShell of Infrastructure as Code-tools zoals ARM-templates of Terraform. Tijdens het aanmaken moeten organisaties een beschrijvende naam kiezen die de functie of het doel van de NSG duidelijk maakt, bijvoorbeeld 'nsg-web-tier' voor web servers of 'nsg-database-tier' voor database servers. Deze naamgevingsconventies zijn belangrijk voor beheerbaarheid en maken het gemakkelijker om te begrijpen welke NSG's welke workloads beschermen. De NSG wordt aangemaakt in een resourcegroep en regio, en kan vervolgens worden gekoppeld aan subnetten of netwerkinterfaces binnen die regio. Het is aanbevolen om NSG's te organiseren in resourcegroepen die logisch zijn gegroepeerd, bijvoorbeeld een resourcegroep voor netwerkbeveiliging of resourcegroepen per workload of omgeving (productie, test, ontwikkeling).

Na het aanmaken van de NSG moeten beveiligingsregels worden geconfigureerd die definiëren welke verkeer is toegestaan of geblokkeerd. Elke regel bevat verschillende componenten: een naam die de regel beschrijft, een prioriteit die de evaluatievolgorde bepaalt, een bron of bronbereik (bijvoorbeeld een IP-adres, CIDR-blok, service tag of application security group), een doel of doelbereik, een protocol (TCP, UDP, ICMP of Any), een bronpoort of poortbereik, een doelpoort of poortbereik, en een actie (Allow of Deny). Het is cruciaal om regels te ontwerpen volgens het principe van least privilege: alleen het minimale verkeer dat nodig is voor de werking van workloads moet worden toegestaan, en al het andere verkeer moet expliciet worden geblokkeerd. Organisaties moeten beginnen met deny-all regels en vervolgens specifieke allow-regels toevoegen voor legitiem verkeer. Dit is veiliger dan te beginnen met allow-all en vervolgens deny-regels toe te voegen, omdat het risico op het per ongeluk toestaan van ongeautoriseerd verkeer wordt geminimaliseerd.

Voor inkomend verkeer moeten organisaties specifieke regels definiëren voor services die toegankelijk moeten zijn, zoals HTTP (poort 80) en HTTPS (poort 443) voor web servers, RDP (poort 3389) of SSH (poort 22) voor beheer, of aangepaste poorten voor applicatiespecifieke services. Het is belangrijk om te voorkomen dat brede regels worden gebruikt die verkeer van 'Internet' toestaan naar alle poorten, omdat dit aanzienlijke beveiligingsrisico's introduceert. In plaats daarvan moeten organisaties specifieke bron-IP-adressen of IP-bereiken gebruiken wanneer mogelijk, bijvoorbeeld alleen verkeer toestaan van beheerders-IP-adressen voor RDP of SSH. Voor uitgaand verkeer moeten organisaties overwegen welke externe services workloads nodig hebben: bijvoorbeeld toegang tot Azure Storage, Azure SQL Database, of publieke API's. Uitgaand verkeer naar internet moet worden beperkt tot alleen wat nodig is, en organisaties moeten overwegen om uitgaand verkeer te blokkeren naar bekende kwaadaardige IP-adressen of landen waar geen zakelijke relaties zijn. Het gebruik van service tags voor uitgaand verkeer naar Azure-services is aanbevolen omdat dit zorgt voor automatische updates wanneer IP-adressen wijzigen.

Het koppelen van NSG's aan subnetten of netwerkinterfaces kan worden gedaan tijdens het aanmaken van de subnet of interface, of later via wijziging van de configuratie. Wanneer een NSG wordt gekoppeld aan een subnet, worden alle netwerkinterfaces binnen dat subnet automatisch beschermd door de NSG-regels, tenzij een specifieke netwerkinterface zijn eigen NSG heeft die de subnet-NSG overschrijft. Wanneer zowel een subnet-NSG als een interface-NSG zijn geconfigureerd, worden beide sets regels geëvalueerd: verkeer moet door beide NSG's worden toegestaan om te worden doorgestuurd. Dit biedt gelaagde beveiliging maar kan ook complexiteit introduceren, en organisaties moeten ervoor zorgen dat regels in beide NSG's compatibel zijn en niet conflicteren. Het is aanbevolen om te beginnen met subnet-NSG's voor consistente beveiliging en alleen interface-NSG's toe te voegen wanneer specifieke workloads unieke beveiligingsvereisten hebben die niet kunnen worden geadresseerd op subnetniveau.

Gebruik PowerShell-script network-security-groups.ps1 (functie Invoke-Monitoring) – Voert een monitoringcontrole uit op Network Security Groups om te bepalen of NSG's correct zijn geconfigureerd met passende regels, logging en best practices..

Geavanceerde functies en optimalisatie

NSG Flow Logs vormen een krachtige functie die organisaties in staat stelt om gedetailleerde informatie te verzamelen over al het verkeer dat door Network Security Groups wordt gecontroleerd. Flow logs verzamelen metadata over netwerkverkeer inclusief bron- en doel-IP-adressen, poorten, protocollen, verkeersbeslissingen (toegestaan of geweigerd) en bytes overgedragen. Deze logs worden opgeslagen in Azure Storage voor langetermijnarchivering en kunnen optioneel worden doorgestuurd naar Log Analytics Workspace voor real-time analyse en query's. Flow logs zijn essentieel voor beveiligingsmonitoring omdat ze organisaties in staat stellen om netwerkaanvallen te detecteren, laterale beweging te identificeren, en forensische onderzoeken uit te voeren na een incident. Zonder flow logs hebben beveiligingsteams geen inzicht in wat er gebeurt op het netwerk, wat het detecteren en reageren op bedreigingen aanzienlijk bemoeilijkt. Voor Nederlandse overheidsorganisaties die moeten voldoen aan compliance-vereisten zoals BIO norm 12.04 (logging) en ISO 27001:2022 controle A.8.15 (logging) zijn flow logs verplicht, en organisaties moeten ervoor zorgen dat logs worden bewaard voor de vereiste retentietermijnen (typisch 7 jaar voor Nederlandse overheidsorganisaties).

Azure Policy kan worden gebruikt om consistente NSG-configuraties af te dwingen en te voorkomen dat niet-compliant configuraties worden geïmplementeerd. Organisaties kunnen policies definiëren die vereisen dat alle subnetten een NSG hebben, dat NSG's specifieke regels bevatten (bijvoorbeeld default deny-regels), of dat NSG Flow Logs zijn ingeschakeld. Deze policies kunnen worden toegepast op abonnements- of management group-niveau om ervoor te zorgen dat alle resources binnen de scope voldoen aan de gestelde eisen. Azure Policy biedt ook de mogelijkheid om automatische remediatie uit te voeren wanneer niet-compliant configuraties worden gedetecteerd, bijvoorbeeld door automatisch een NSG te koppelen aan een subnet dat geen NSG heeft. Deze geautomatiseerde aanpak vermindert de werklast voor IT-teams en zorgt voor consistente beveiliging, zelfs wanneer er frequente wijzigingen zijn aan de cloudomgeving. Organisaties moeten echter voorzichtig zijn met automatische remediatie en moeten ervoor zorgen dat remediatie-acties worden getest en goedgekeurd voordat ze worden geactiveerd in productieomgevingen.

Traffic Analytics is een geavanceerde functie die flow log data analyseert en inzicht biedt in netwerkverkeerspatronen, bedreigingen en optimalisatiemogelijkheden. Traffic Analytics gebruikt machine learning om afwijkende verkeerspatronen te detecteren, zoals ongebruikelijke verbindingen, data exfiltration pogingen, of communicatie met bekende kwaadaardige IP-adressen. Deze inzichten worden gepresenteerd in dashboards die organisaties helpen om netwerkbeveiliging te verbeteren, kosten te optimaliseren door het identificeren van ongebruikte of inefficiënte verkeersstromen, en compliance te waarborgen door het demonstreren van netwerkmonitoring. Traffic Analytics vereist dat NSG Flow Logs zijn ingeschakeld en dat logs worden doorgestuurd naar Log Analytics Workspace. De service analyseert logs van alle NSG's binnen een abonnement en biedt een geconsolideerd overzicht van netwerkactiviteiten, wat vooral waardevol is in complexe omgevingen met veel NSG's en Virtual Networks. Voor Nederlandse overheidsorganisaties kan Traffic Analytics helpen bij het voldoen aan NIS2-vereisten voor netwerkmonitoring en incidentdetectie.

Het optimaliseren van NSG-regels is een continu proces dat regelmatige reviews en aanpassingen vereist. Na verloop van tijd kunnen NSG-regels verouderd raken, kunnen ongebruikte regels zich ophopen, en kunnen nieuwe bedrijfsvereisten nieuwe regels noodzakelijk maken. Organisaties moeten minimaal kwartaalgewijs een review uitvoeren van alle NSG-regels 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. Azure biedt tools zoals NSG Flow Logs en Traffic Analytics die kunnen helpen bij het identificeren van ongebruikte regels door te analyseren welk verkeer daadwerkelijk door NSG's wordt gefilterd. Organisaties kunnen ook gebruik maken van Azure Policy om te voorkomen dat overbrede regels worden toegevoegd, bijvoorbeeld door policies te definiëren die waarschuwen wanneer regels worden gemaakt die verkeer van 'Internet' toestaan naar alle poorten.

Diagnostische instellingen moeten worden geconfigureerd om NSG-activiteiten te loggen naar Log Analytics Workspace voor monitoring en compliance. Deze instellingen loggen informatie over NSG-regel evaluaties, inclusief welke regels zijn geëvalueerd, welke regels hebben gematcht, en welke acties zijn genomen. Deze logs kunnen worden gebruikt om te analyseren hoe NSG's worden gebruikt, om problemen te troubleshooten wanneer verkeer onverwacht wordt geblokkeerd, en om compliance-rapportages te genereren. Diagnostische instellingen moeten worden geconfigureerd voor alle NSG's en moeten logs naar een centrale Log Analytics-workspace sturen voor geconsolideerde analyse. Organisaties moeten ook retentiebeleid instellen die voldoen aan compliance-vereisten en moeten alertregels configureren die waarschuwingen genereren bij ongebruikelijke activiteiten, zoals plotselinge toename van geblokkeerd verkeer of herhaalde pogingen tot toegang tot geblokkeerde poorten.

Gebruik PowerShell-script network-security-groups.ps1 (functie Invoke-Remediation) – Genereert een gedetailleerd overzicht van Network Security Group-configuraties en identificeert ontbrekende of suboptimale instellingen die moeten worden aangepast..

Beveiligingsbest practices en risicobeheer

Het implementeren van beveiligingsbest practices voor Network Security Groups is essentieel voor het waarborgen van effectieve netwerkbeveiliging en het voorkomen van beveiligingsincidenten. De belangrijkste best practice is het toepassen van het principe van least privilege: alleen het minimale netwerkverkeer dat nodig is voor de werking van workloads moet worden toegestaan, en al het andere verkeer moet expliciet worden geblokkeerd. Dit betekent dat organisaties moeten beginnen met deny-all regels en vervolgens specifieke allow-regels toevoegen voor legitiem verkeer, in plaats van te beginnen met allow-all en vervolgens deny-regels toe te voegen. Het principe van least privilege vermindert het aanvalsoppervlak en beperkt de schade die kan worden veroorzaakt wanneer een resource wordt gecompromitteerd, omdat aanvallers alleen toegang hebben tot services en poorten die expliciet zijn toegestaan.

Het voorkomen van overbrede regels is cruciaal voor netwerkbeveiliging. Overbrede regels zijn regels die verkeer toestaan van of naar grote IP-bereiken of alle poorten, wat aanzienlijke beveiligingsrisico's introduceert. Bijvoorbeeld, een regel die verkeer toestaat van 'Internet' naar alle poorten op een virtuele machine is extreem gevaarlijk omdat het de machine blootstelt aan alle mogelijke aanvallen. Organisaties moeten specifieke bron-IP-adressen of IP-bereiken gebruiken wanneer mogelijk, en moeten poorten beperken tot alleen wat nodig is. Voor beheerdoeleinden zoals RDP of SSH moeten organisaties overwegen om alleen verkeer toe te staan van beheerders-IP-adressen of van een beveiligde jump host, in plaats van verkeer van 'Internet' toe te staan. Het gebruik van Azure Bastion of een VPN-verbinding voor beheer is aanbevolen omdat dit voorkomt dat beheerpoorten direct blootgesteld worden aan internet.

Default deny-regels moeten worden geïmplementeerd om ervoor te zorgen dat verkeer dat niet expliciet is toegestaan automatisch wordt geblokkeerd. Azure NSG's hebben standaard deny-regels voor inkomend verkeer van buiten het Virtual Network, maar organisaties moeten expliciete deny-regels toevoegen voor specifieke bedreigingen of onwenselijk verkeer. Bijvoorbeeld, organisaties kunnen deny-regels toevoegen die verkeer blokkeren van bekende kwaadaardige IP-adressen, van specifieke landen waar geen zakelijke relaties zijn, of naar specifieke poorten die niet gebruikt moeten worden. Deze deny-regels moeten een lagere prioriteit hebben dan allow-regels om ervoor te zorgen dat legitiem verkeer niet wordt geblokkeerd, maar moeten een hogere prioriteit hebben dan de standaard deny-regels om specifieke bedreigingen te blokkeren voordat ze de standaardregels bereiken.

Netwerksegmentatie is een belangrijke best practice die organisaties in staat stelt om workloads te isoleren en laterale beweging van aanvallers te beperken. Door verschillende subnetten te gebruiken voor verschillende workload-tiers (bijvoorbeeld web tier, application tier, database tier) en door NSG's te configureren die alleen verkeer toestaan tussen tiers zoals nodig, kunnen organisaties ervoor zorgen dat een gecompromitteerde resource in één tier niet direct toegang heeft tot resources in andere tiers. Deze segmentatie is vooral belangrijk voor gevoelige workloads zoals databases die alleen toegankelijk moeten zijn vanuit application tiers, niet vanuit web tiers of internet. Application Security Groups kunnen worden gebruikt om deze segmentatie te implementeren op basis van workload-identiteit in plaats van IP-adressen, wat flexibeler en onderhoudbaarder is.

Regelmatige reviews en audits van NSG-configuraties zijn essentieel voor het handhaven van netwerkbeveiliging en het voorkomen van configuratiedrift. Organisaties moeten minimaal kwartaalgewijs een review uitvoeren van alle NSG-regels om te verifiëren dat regels nog steeds nodig zijn, correct zijn geconfigureerd, en voldoen aan beveiligingsbest practices. 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. Deze reviews moeten worden gedocumenteerd en gerapporteerd aan security- en risicocomités, en bevindingen moeten worden vertaald naar concrete verbeteracties met eigenaren en deadlines. Het gebruik van geautomatiseerde tools zoals Azure Policy en monitoring scripts kan helpen bij het identificeren van niet-compliant configuraties en het versnellen van het reviewproces.

Beheer, governance en compliance

Effectief beheer van Network Security Groups vereist duidelijke governance-structuren, gedefinieerde processen en continue monitoring. Organisaties moeten vastleggen wie verantwoordelijk is voor het dagelijks beheer van NSG's, wie NSG-regels 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 NSG-beheer nodig hebben. Het is aanbevolen om verschillende rollen te definiëren: NSG-beheerders die volledige controle hebben over NSG-configuraties, 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 NSG-regels 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 biedt de mogelijkheid om NSG-regels 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 NSG-configuraties up-to-date blijven en aansluiten bij veranderende bedrijfsbehoeften en beveiligingsvereisten. Organisaties moeten minimaal kwartaalgewijs een review uitvoeren van alle NSG-regels 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 NSG Flow Logs 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 NSG's voldoende capaciteit hebben. 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 Network Security Groups correct zijn geconfigureerd en effectief werken. Tijdens audits moeten organisaties kunnen laten zien: dat alle kritieke subnetten en netwerkinterfaces zijn beveiligd met NSG's, dat NSG-regels zijn gebaseerd op het principe van least privilege en regelmatig worden gereviewd, dat NSG Flow Logs zijn ingeschakeld en logs worden bewaard volgens de vereiste retentietermijnen, dat logging correct is geconfigureerd en logs worden gebruikt voor monitoring en incidentdetectie, en dat er processen zijn voor incidentdetectie en -respons op basis van NSG-logs. Het bijbehorende PowerShell-script kan worden gebruikt om compliance-rapportages te genereren die aantonen welke NSG's 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

Network Security Group-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 Network Security Groups vormen een belangrijk onderdeel van het bewijs dat deze vereiste wordt nageleefd. Tijdens BIO-audits wordt niet alleen gekeken naar het bestaan van NSG's, maar vooral naar de kwaliteit van de configuratie, de wijze van beheer, de monitoringresultaten en de aansluiting op incidentresponsprocessen. Organisaties moeten kunnen aantonen dat NSG Flow Logs zijn 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. Network Security Groups voldoen aan deze vereiste door geavanceerde netwerkfiltering te bieden op basis van IP-adressen, poorten en protocollen. 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 NSG's voortkomt uit een risicoafweging, dat NSG-regels 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. Network Security Groups voldoen aan deze vereiste door geavanceerde netwerkfiltering te bieden met gedetailleerde logging van alle netwerkactiviteiten. Organisaties moeten kunnen aantonen dat incidentresponsprocedures correct zijn gedocumenteerd, dat beveiligingsincidenten tijdig worden gedetecteerd via NSG Flow 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 Network Security Groups wordt vertaald naar begrijpelijke stuurinformatie. Bestuurders hoeven niet te weten welke individuele NSG-regels actief zijn, maar wel of alle kritieke subnetten en netwerkinterfaces zijn beveiligd, hoeveel netwerkverkeer wordt gefilterd en geblokkeerd, of er recente incidenten zijn geweest die door NSG's zijn gedetecteerd, 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

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).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Network Security Groups Monitoring en Remediation .DESCRIPTION Controleert of Network Security Groups correct zijn geïmplementeerd en geconfigureerd met passende regels, logging en best practices. .NOTES Filename: network-security-groups.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 6.3, 6.4, 6.15 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Network, Az.Resources [CmdletBinding()] param( [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert, [Parameter()][switch]$WhatIf ) $ErrorActionPreference = 'Stop' $PolicyName = "Network Security Groups" function Connect-RequiredServices { if (-not (Get-AzContext)) { Write-Host "Verbinden met Azure..." -ForegroundColor Yellow Connect-AzAccount | Out-Null } } function Test-NetworkSecurityGroupCompliance { <# .SYNOPSIS Controleert Network Security Group-implementaties op compliance #> param() try { $nsgs = Get-AzNetworkSecurityGroup -ErrorAction SilentlyContinue $results = @() if ($nsgs.Count -eq 0) { return @{ TotalNSGs = 0 CompliantNSGs = 0 IsCompliant = $false Details = @() } } foreach ($nsg in $nsgs) { $nsgResult = @{ Name = $nsg.Name ResourceGroup = $nsg.ResourceGroupName Location = $nsg.Location HasInboundRules = $false HasOutboundRules = $false HasDefaultDenyRules = $false HasFlowLogs = $false HasDiagnosticSettings = $false HasOverlyBroadRules = $false RuleCount = 0 IsCompliant = $false } # Controleer inkomende regels if ($nsg.SecurityRules) { $inboundRules = $nsg.SecurityRules | Where-Object { $_.Direction -eq 'Inbound' } $outboundRules = $nsg.SecurityRules | Where-Object { $_.Direction -eq 'Outbound' } $nsgResult.HasInboundRules = ($inboundRules.Count -gt 0) $nsgResult.HasOutboundRules = ($outboundRules.Count -gt 0) $nsgResult.RuleCount = $nsg.SecurityRules.Count # Controleer op default deny-regels $denyRules = $nsg.SecurityRules | Where-Object { $_.Access -eq 'Deny' -and $_.SourceAddressPrefix -eq '*' -and $_.DestinationAddressPrefix -eq '*' } $nsgResult.HasDefaultDenyRules = ($denyRules.Count -gt 0) # Controleer op overbrede regels (Internet naar alle poorten) $broadRules = $nsg.SecurityRules | Where-Object { $_.Access -eq 'Allow' -and ($_.SourceAddressPrefix -eq '*' -or $_.SourceAddressPrefix -eq 'Internet') -and ($_.DestinationPortRange -eq '*' -or $_.DestinationPortRange -eq '0-65535') } $nsgResult.HasOverlyBroadRules = ($broadRules.Count -gt 0) } # Controleer NSG Flow Logs $resourceId = $nsg.Id $flowLogs = Get-AzNetworkWatcherFlowLog -NetworkWatcherName "NetworkWatcher_*" -ResourceGroupName "*" -ErrorAction SilentlyContinue | Where-Object { $_.TargetResourceId -eq $resourceId } if ($flowLogs) { $nsgResult.HasFlowLogs = $true } # Controleer diagnostische instellingen $diagnosticSettings = Get-AzDiagnosticSetting -ResourceId $resourceId -ErrorAction SilentlyContinue if ($diagnosticSettings) { $nsgResult.HasDiagnosticSettings = $true } # Bepaal compliance $nsgResult.IsCompliant = ( ($nsgResult.HasInboundRules -or $nsgResult.HasOutboundRules) -and -not $nsgResult.HasOverlyBroadRules ) $results += $nsgResult } $compliantCount = ($results | Where-Object { $_.IsCompliant }).Count return @{ TotalNSGs = $nsgs.Count CompliantNSGs = $compliantCount IsCompliant = ($compliantCount -eq $nsgs.Count -and $nsgs.Count -gt 0) Details = $results } } catch { Write-Error "Fout bij het controleren van Network Security Group compliance: $_" return @{ TotalNSGs = 0 CompliantNSGs = 0 IsCompliant = $false Details = @() Error = $_.Exception.Message } } } function Get-SubnetNSGCoverage { <# .SYNOPSIS Controleert NSG-dekking op subnetten #> param() try { $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue $subnetResults = @() foreach ($vnet in $vnets) { foreach ($subnet in $vnet.Subnets) { # Sla GatewaySubnet en AzureBastionSubnet over if ($subnet.Name -like '*GatewaySubnet*' -or $subnet.Name -like '*AzureBastionSubnet*') { continue } $subnetResult = @{ VNetName = $vnet.Name SubnetName = $subnet.Name ResourceGroup = $vnet.ResourceGroupName HasNSG = ($null -ne $subnet.NetworkSecurityGroup) NSGId = $subnet.NetworkSecurityGroup.Id } $subnetResults += $subnetResult } } return $subnetResults } catch { Write-Error "Fout bij het controleren van subnet NSG-dekking: $_" return @() } } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status van Network Security Groups #> [CmdletBinding()] param() Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName - Monitoring" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan try { Connect-RequiredServices $result = Test-NetworkSecurityGroupCompliance $subnetCoverage = Get-SubnetNSGCoverage Write-Host "Network Security Group Overzicht:" -ForegroundColor Yellow Write-Host " Totaal aantal NSG's: $($result.TotalNSGs)" -ForegroundColor White if ($result.TotalNSGs -eq 0) { Write-Host "`n⚠️ Geen Network Security Group-implementaties gevonden" -ForegroundColor Yellow Write-Host " Overweeg NSG's te implementeren voor netwerkbeveiliging" -ForegroundColor Yellow Write-Host "`nNON-COMPLIANT" -ForegroundColor Red exit 1 } Write-Host " Compliante NSG's: $($result.CompliantNSGs)" -ForegroundColor $(if ($result.CompliantNSGs -eq $result.TotalNSGs) { 'Green' } else { 'Yellow' }) # Subnet dekking $subnetsWithNSG = ($subnetCoverage | Where-Object { $_.HasNSG }).Count $totalSubnets = $subnetCoverage.Count if ($totalSubnets -gt 0) { Write-Host "`nSubnet NSG-dekking:" -ForegroundColor Yellow Write-Host " Subnetten met NSG: $subnetsWithNSG / $totalSubnets" -ForegroundColor $(if ($subnetsWithNSG -eq $totalSubnets) { 'Green' } else { 'Yellow' }) if ($subnetsWithNSG -lt $totalSubnets) { Write-Host "`n⚠️ Subnetten zonder NSG:" -ForegroundColor Yellow foreach ($subnet in ($subnetCoverage | Where-Object { -not $_.HasNSG })) { Write-Host " - $($subnet.VNetName)/$($subnet.SubnetName) ($($subnet.ResourceGroup))" -ForegroundColor Red } } } Write-Host "`nGedetailleerde Status per NSG:" -ForegroundColor Yellow foreach ($detail in $result.Details) { $statusColor = if ($detail.IsCompliant) { 'Green' } else { 'Red' } $statusText = if ($detail.IsCompliant) { 'COMPLIANT' } else { 'NON-COMPLIANT' } Write-Host "`n NSG: $($detail.Name)" -ForegroundColor Cyan Write-Host " Resource Group: $($detail.ResourceGroup)" -ForegroundColor White Write-Host " Locatie: $($detail.Location)" -ForegroundColor White Write-Host " Aantal regels: $($detail.RuleCount)" -ForegroundColor White Write-Host " Status: $statusText" -ForegroundColor $statusColor if (-not $detail.IsCompliant) { Write-Host " Ontbrekende of problematische configuraties:" -ForegroundColor Yellow if (-not $detail.HasInboundRules -and -not $detail.HasOutboundRules) { Write-Host " - Geen beveiligingsregels geconfigureerd" -ForegroundColor Red } if ($detail.HasOverlyBroadRules) { Write-Host " - Overbrede regels gedetecteerd (beveiligingsrisico)" -ForegroundColor Red } } else { Write-Host " Configuratie:" -ForegroundColor Green Write-Host " ✓ Beveiligingsregels geconfigureerd" -ForegroundColor Green if ($detail.HasFlowLogs) { Write-Host " ✓ NSG Flow Logs ingeschakeld" -ForegroundColor Green } else { Write-Host " ⚠ NSG Flow Logs niet ingeschakeld (aanbevolen)" -ForegroundColor Yellow } if ($detail.HasDiagnosticSettings) { Write-Host " ✓ Diagnostische instellingen geconfigureerd" -ForegroundColor Green } else { Write-Host " ⚠ Diagnostische instellingen niet geconfigureerd (aanbevolen)" -ForegroundColor Yellow } } } Write-Host "`n========================================" -ForegroundColor Cyan if ($result.IsCompliant -and $subnetsWithNSG -eq $totalSubnets) { Write-Host "COMPLIANT" -ForegroundColor Green exit 0 } else { Write-Host "NON-COMPLIANT" -ForegroundColor Red Write-Host "`nGebruik -Remediation om aanbevelingen te krijgen voor het verbeteren van de configuratie." -ForegroundColor Yellow exit 1 } } catch { Write-Host "`nERROR: $_" -ForegroundColor Red exit 2 } } function Invoke-Remediation { <# .SYNOPSIS Genereert aanbevelingen voor het verbeteren van Network Security Group-configuraties .DESCRIPTION Dit script genereert een gedetailleerd overzicht van ontbrekende of suboptimale configuraties en biedt aanbevelingen voor verbetering. #> [CmdletBinding()] param() Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName - Remediation" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan try { Connect-RequiredServices $result = Test-NetworkSecurityGroupCompliance $subnetCoverage = Get-SubnetNSGCoverage if ($result.TotalNSGs -eq 0) { Write-Host "Geen Network Security Group-implementaties gevonden." -ForegroundColor Yellow Write-Host "`nAanbeveling: Implementeer Network Security Groups voor netwerkbeveiliging." -ForegroundColor Yellow Write-Host "Zie het artikel voor implementatie-instructies." -ForegroundColor Yellow exit 0 } Write-Host "Remediatie-aanbevelingen per NSG:" -ForegroundColor Yellow foreach ($detail in $result.Details) { Write-Host "`nNSG: $($detail.Name) ($($detail.ResourceGroup))" -ForegroundColor Cyan $recommendations = @() if (-not $detail.HasInboundRules -and -not $detail.HasOutboundRules) { $recommendations += "Voeg beveiligingsregels toe voor inkomend en/of uitgaand verkeer" } if ($detail.HasOverlyBroadRules) { $recommendations += "Vervang overbrede regels door specifieke regels met beperkte IP-bereiken en poorten" } if (-not $detail.HasDefaultDenyRules) { $recommendations += "Overweeg default deny-regels toe te voegen voor extra beveiliging" } if (-not $detail.HasFlowLogs) { $recommendations += "Schakel NSG Flow Logs in voor netwerkzichtbaarheid en compliance" } if (-not $detail.HasDiagnosticSettings) { $recommendations += "Configureer diagnostische instellingen om NSG-activiteiten te loggen naar Log Analytics" } if ($recommendations.Count -eq 0) { Write-Host " ✓ Geen remediatie nodig - NSG is correct geconfigureerd" -ForegroundColor Green } else { Write-Host " Aanbevelingen:" -ForegroundColor Yellow foreach ($rec in $recommendations) { Write-Host " - $rec" -ForegroundColor White } } } # Subnet aanbevelingen $subnetsWithoutNSG = $subnetCoverage | Where-Object { -not $_.HasNSG } if ($subnetsWithoutNSG.Count -gt 0) { Write-Host "`nSubnetten zonder NSG:" -ForegroundColor Yellow foreach ($subnet in $subnetsWithoutNSG) { Write-Host " - $($subnet.VNetName)/$($subnet.SubnetName) ($($subnet.ResourceGroup))" -ForegroundColor White Write-Host " Aanbeveling: Koppel een NSG aan dit subnet voor netwerkbeveiliging" -ForegroundColor Yellow } } Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Voor gedetailleerde implementatie-instructies, zie het bijbehorende artikel." -ForegroundColor Yellow Write-Host "========================================`n" -ForegroundColor Cyan exit 0 } catch { Write-Host "`nERROR: $_" -ForegroundColor Red exit 2 } } function Invoke-Revert { <# .SYNOPSIS Herstelt wijzigingen (niet van toepassing voor monitoring-only script) #> [CmdletBinding()] param() Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName - Revert" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan Write-Host "[INFO] Dit script voert alleen monitoring uit." -ForegroundColor Yellow Write-Host "[INFO] Er zijn geen automatische wijzigingen om terug te draaien." -ForegroundColor Yellow Write-Host "`nGebruik -Monitoring om de huidige status te controleren." -ForegroundColor Yellow Write-Host "========================================`n" -ForegroundColor Cyan exit 0 } # Main execution try { if ($Revert) { Invoke-Revert } elseif ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { Invoke-Remediation } else { Write-Host "`nGebruik: -Monitoring | -Remediation | -Revert" -ForegroundColor Yellow Write-Host "`nVoorbeelden:" -ForegroundColor Cyan Write-Host " .\network-security-groups.ps1 -Monitoring" -ForegroundColor White Write-Host " .\network-security-groups.ps1 -Remediation" -ForegroundColor White } } catch { Write-Host "`nFATALE FOUT: $_" -ForegroundColor Red exit 2 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder correct geconfigureerde Network Security Groups zijn Azure-resources direct blootgesteld aan ongefilterd netwerkverkeer, wat leidt tot aanzienlijke beveiligingsrisico's. Virtuele machines kunnen worden benaderd vanaf ongeautoriseerde bronnen, gevoelige data kan worden blootgesteld via onbeveiligde poorten, en aanvallers kunnen laterale beweging uitvoeren tussen subnetten zonder detectie. Het ontbreken van NSG's betekent dat organisaties geen granulair controle hebben over welke services toegankelijk zijn, welke IP-adressen verbindingen mogen maken, en welke protocollen zijn toegestaan. Dit schendt fundamentele beveiligingsprincipes zoals least privilege en defense in depth, waardoor organisaties kwetsbaar zijn voor ransomware-aanvallen, data exfiltration, en ongeautoriseerde toegang tot kritieke systemen. Voor Nederlandse overheidsorganisaties die moeten voldoen aan compliance-frameworks zoals BIO norm 13.01, ISO 27001:2022 controle A.8.20 en NIS2 artikel 21 is het ontbreken van NSG's onacceptabel: deze frameworks vereisen expliciete netwerkfiltering, logging van netwerkactiviteiten en aantoonbare maatregelen tegen netwerkgebaseerde bedreigingen. In audits zal het ontbreken van NSG's worden gezien als een structurele tekortkoming in de technische beveiligingsmaatregelen die kan leiden tot negatieve auditbevindingen en mogelijke boetes.

Management Samenvatting

Network Security Groups vormen een verplichte beveiligingslaag voor Azure Virtual Networks binnen de Nederlandse Baseline voor Veilige Cloud. Door een gestandaardiseerde architectuur, moderne NSG-configuratie met least privilege-principes en strakke integratie met NSG Flow Logs en Azure Monitor te implementeren, worden netwerkaanvallen vroegtijdig gedetecteerd en geblokkeerd en wordt een rijk beeld van dreigingen opgebouwd. Het bijbehorende PowerShell-script inventariseert automatisch welke NSG's 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 56 uur initiële implementatie), terwijl de risicoreductie en auditbaarheid aanzienlijk zijn voor alle netwerkgebaseerde diensten in Azure.