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

Azure Network Security Groups: Correcte Configuratie En Best Practices

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

💼 Management Samenvatting

Het correct configureren van Azure Network Security Groups (NSG's) is een kritieke beveiligingsmaatregel die bepaalt hoe effectief netwerkverkeer wordt gefilterd en beveiligd binnen Azure Virtual Networks. In tegenstelling tot het simpelweg aanmaken van NSG's vereist correcte configuratie een diepgaand begrip van netwerkarchitectuur, beveiligingsprincipes en operationele best practices. Een verkeerd geconfigureerde NSG kan leiden tot beveiligingsgaten die aanvallers in staat stellen om ongeautoriseerd toegang te krijgen tot kritieke resources, of kan legitiem verkeer blokkeren waardoor workloads niet meer functioneren. Voor Nederlandse overheidsorganisaties die moeten voldoen aan BIO, NIS2 en ISO 27001 is het niet alleen belangrijk dat NSG's aanwezig zijn, maar vooral dat ze correct zijn geconfigureerd volgens het principe van least privilege, dat logging is ingeschakeld voor compliance en auditing, en dat configuraties regelmatig worden gereviewd en geoptimaliseerd.

Aanbeveling
CONFIGUREER NETWORK SECURITY GROUPS CORRECT VOLGENS BEVEILIGINGSBEST PRACTICES
Risico zonder
High
Risk Score
9/10
Implementatie
56u (tech: 40u)
Van toepassing op:
✓ Azure Virtual Networks
✓ Azure Subnets
✓ Network Interfaces
✓ Network Security Groups
✓ Netwerkbeveiliging

Een verkeerd geconfigureerde Network Security Group kan aanzienlijke beveiligingsrisico's creëren die vaak pas worden ontdekt tijdens een incident of audit. Veelvoorkomende configuratiefouten omvatten het gebruik van overbrede regels die verkeer toestaan van 'Internet' naar alle poorten, het ontbreken van default deny-regels waardoor onbedoeld verkeer wordt toegestaan, het verkeerd instellen van regelprioriteiten waardoor deny-regels per ongeluk allow-regels overschrijven, het niet inschakelen van NSG Flow Logs waardoor er geen zichtbaarheid is in netwerkactiviteiten, en het niet regelmatig reviewen van regels waardoor verouderde of ongebruikte regels blijven bestaan. Deze fouten kunnen leiden tot ongeautoriseerde toegang tot virtuele machines, data exfiltration, laterale beweging van aanvallers binnen netwerken, en het onvermogen om beveiligingsincidenten te detecteren of te onderzoeken. 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 verkeerde configuratie onacceptabel: deze frameworks vereisen niet alleen dat netwerkfiltering aanwezig is, maar ook dat deze correct is geconfigureerd, wordt gemonitord en regelmatig wordt gereviewd. Tijdens audits zal verkeerde configuratie worden gezien als een structurele tekortkoming 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, Az.Monitor

Implementatie

Dit artikel beschrijft hoe organisaties binnen de Nederlandse Baseline voor Veilige Cloud Network Security Groups correct configureren volgens beveiligingsbest practices en compliance-vereisten. De focus ligt op zes hoofdcomponenten. Ten eerste configuratieprincipes en -methodologie: het begrijpen van het principe van least privilege, het toepassen van default deny-benaderingen, het correct instellen van regelprioriteiten, en het gebruik van service tags en application security groups voor vereenvoudigd beheer. Ten tweede regelontwerp en -implementatie: het ontwerpen van specifieke en veilige NSG-regels, het voorkomen van overbrede regels, het implementeren van gelaagde beveiliging met subnet- en interface-NSG's, en het gebruik van naming conventions voor beheerbaarheid. Ten derde logging en monitoring: het inschakelen en configureren van NSG Flow Logs, het instellen van diagnostische instellingen voor compliance, het integreren met Azure Monitor en Log Analytics voor netwerkanalyse, en het configureren van alertregels voor bedreigingsdetectie. Ten vierde beveiligingsvalidatie en -testing: het testen van NSG-configuraties voordat ze in productie worden geïmplementeerd, het valideren dat legitiem verkeer niet wordt geblokkeerd, het identificeren van beveiligingsgaten en het uitvoeren van regelmatige security assessments. Ten vijfde operationele best practices: het opzetten van change management-processen voor NSG-wijzigingen, het implementeren van periodieke reviews en audits, het documenteren van configuraties en wijzigingen, en het automatiseren van configuratiechecks via Azure Policy. Ten zesde compliance en governance: het waarborgen van compliance met relevante frameworks, het genereren van auditrapportages, het definiëren van verantwoordelijkheden en het implementeren van governance-processen. Het bijbehorende PowerShell-script valideert NSG-configuraties, controleert of regels correct zijn geconfigureerd volgens best practices, identificeert configuratiefouten en genereert compliance-rapportages.

Configuratieprincipes en methodologie

Het correct configureren van Network Security Groups begint met het begrijpen en toepassen van fundamentele beveiligingsprincipes die de basis vormen voor effectieve netwerkbeveiliging. Het belangrijkste principe is least privilege: alleen het minimale netwerkverkeer dat absoluut noodzakelijk 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 een deny-all benadering waarbij alle verkeer standaard wordt geblokkeerd, en vervolgens specifieke allow-regels toevoegen voor alleen die verkeer dat legitiem en noodzakelijk is. Deze aanpak is fundamenteel anders dan een allow-all benadering waarbij alle verkeer standaard wordt toegestaan en vervolgens deny-regels worden toegevoegd voor specifieke bedreigingen. Een allow-all benadering is inherent onveilig omdat het risico creëert dat nieuwe services of poorten per ongeluk worden toegestaan zonder expliciete beveiligingsreview, terwijl een deny-all benadering ervoor zorgt dat elke nieuwe service expliciet moet worden goedgekeurd voordat verkeer wordt toegestaan.

De correcte instelling van regelprioriteiten is cruciaal voor de werking van NSG's omdat prioriteiten bepalen in welke volgorde regels worden geëvalueerd. Azure evalueert NSG-regels in oplopende volgorde van prioriteit (lagere nummers worden eerst geëvalueerd), en zodra een regel matcht wordt verdere evaluatie gestopt en wordt de actie van die regel toegepast. Dit betekent dat organisaties zorgvuldig moeten nadenken over prioriteiten om te voorkomen dat brede regels specifiekere regels overschrijven, of dat deny-regels per ongeluk allow-regels blokkeren. Als algemene regel moeten allow-regels een hogere prioriteit hebben (lagere nummers) dan deny-regels om ervoor te zorgen dat legitiem verkeer niet per ongeluk wordt geblokkeerd. Specifiekere regels moeten een hogere prioriteit hebben dan algemene regels: bijvoorbeeld, een regel die verkeer toestaat van een specifiek beheerders-IP-adres moet een hogere prioriteit hebben dan een regel die verkeer toestaat van een heel subnet. Organisaties moeten een prioriteitenschema definiëren dat consistent wordt toegepast over alle NSG's, bijvoorbeeld: prioriteiten 100-199 voor specifieke allow-regels, prioriteiten 200-299 voor algemene allow-regels, prioriteiten 3000-3099 voor specifieke deny-regels, en prioriteiten 4000-4096 voor default deny-regels.

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, KeyVault, of AzureDatabricks. 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. Organisaties moeten echter voorzichtig zijn bij het gebruik van service tags: sommige service tags zoals Internet zijn zeer breed en moeten alleen worden gebruikt wanneer absoluut noodzakelijk. Specifiekere service tags zoals Storage of Sql zijn veiliger omdat ze alleen IP-adressen van die specifieke service bevatten.

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.

Het gebruik van gelaagde beveiliging met zowel subnet-NSG's als interface-NSG's biedt extra beveiliging maar vereist zorgvuldige planning om te voorkomen dat regels conflicteren. 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 betekent dat organisaties ervoor moeten 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 op subnetniveau, en alleen interface-NSG's toe te voegen wanneer specifieke workloads unieke beveiligingsvereisten hebben die niet kunnen worden geadresseerd op subnetniveau. Bijvoorbeeld, een subnet-NSG kan algemene regels bevatten voor alle workloads in een subnet, terwijl een interface-NSG specifieke regels kan bevatten voor een individuele virtuele machine die extra beveiliging nodig heeft. Deze gelaagde aanpak verhoogt de beveiliging maar verhoogt ook de complexiteit, en organisaties moeten ervoor zorgen dat ze de interactie tussen subnet- en interface-NSG's volledig begrijpen voordat ze deze implementeren.

Regelontwerp en implementatie

Het ontwerpen van effectieve NSG-regels vereist een diepgaand begrip van de netwerkvereisten van workloads en een zorgvuldige balans tussen beveiliging en functionaliteit. Elke regel moet worden ontworpen met een specifiek doel en moet zo specifiek mogelijk zijn om het principe van least privilege te waarborgen. Organisaties moeten beginnen met het identificeren van alle netwerkvereisten voor elke workload: welke services moeten toegankelijk zijn, vanaf welke bronnen, op welke poorten, en met welke protocollen. Deze vereisten moeten worden gedocumenteerd en goedgekeurd door zowel technische teams als beveiligingsteams voordat NSG-regels worden geïmplementeerd. Tijdens het ontwerpen van regels moeten organisaties specifieke bron-IP-adressen of IP-bereiken gebruiken wanneer mogelijk, in plaats van brede ranges zoals 'Internet' of hele subnetten. Bijvoorbeeld, 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 voorkomen van overbrede regels is cruciaal voor netwerkbeveiliging omdat overbrede regels aanzienlijke beveiligingsrisico's introduceren. Overbrede regels zijn regels die verkeer toestaan van of naar grote IP-bereiken of alle poorten, wat het aanvalsoppervlak aanzienlijk vergroot. 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 services die toegankelijk moeten zijn vanaf internet, zoals web servers, moeten organisaties overwegen om alleen specifieke poorten toe te staan (bijvoorbeeld poort 80 voor HTTP en poort 443 voor HTTPS) in plaats van alle poorten. Het gebruik van Azure Application Gateway of Azure Front Door kan helpen om web services te beveiligen door SSL-terminatie en Web Application Firewall-functionaliteit te bieden, waardoor de noodzaak voor directe internettoegang tot virtuele machines wordt verminderd.

Het implementeren van default deny-regels is essentieel 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. Organisaties moeten ook overwegen om deny-regels toe te voegen voor verouderde of onveilige protocollen, zoals Telnet (poort 23) of FTP (poort 21), tenzij deze expliciet nodig zijn voor legacy-systemen.

Het gebruik van consistente naming conventions voor NSG-regels is belangrijk voor beheerbaarheid en maakt het gemakkelijker om te begrijpen welke regels welke functie hebben. Organisaties moeten een naamgevingsstandaard definiëren die duidelijk maakt wat de regel doet, bijvoorbeeld 'Allow-HTTPS-From-Internet' voor een regel die HTTPS-verkeer vanaf internet toestaat, of 'Deny-RDP-From-Internet' voor een regel die RDP-verkeer vanaf internet blokkeert. Deze naming conventions moeten consistent worden toegepast over alle NSG's en moeten worden gedocumenteerd zodat nieuwe teamleden snel kunnen begrijpen wat elke regel doet. Naast namen moeten organisaties ook beschrijvingen toevoegen aan NSG-regels die uitleggen waarom de regel nodig is, welke workload of service ermee wordt beveiligd, en wie de regel heeft goedgekeurd. Deze beschrijvingen zijn waardevol voor troubleshooting, audits en compliance-rapportages. Organisaties moeten ook overwegen om tags toe te voegen aan NSG-regels voor extra metadata, zoals eigenaar, kostenplaats, of compliance-informatie.

Het testen van NSG-configuraties voordat ze in productie worden geïmplementeerd is essentieel om te voorkomen dat legitiem verkeer wordt geblokkeerd of dat beveiligingsgaten worden geïntroduceerd. Organisaties moeten NSG-regels eerst testen in een niet-productieomgeving die zo veel mogelijk lijkt op de productieomgeving, en moeten verifiëren dat alle benodigde verkeer werkt zoals verwacht. Tijdens het testen moeten organisaties alle scenario's testen: normale werking van workloads, beheeractiviteiten zoals RDP of SSH, backup- en monitoring-activiteiten, en disaster recovery-scenario's. 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 ook overwegen om NSG Flow Logs te gebruiken tijdens het testen om te verifiëren dat verkeer wordt gefilterd zoals verwacht en om te identificeren of er onverwacht verkeer wordt geblokkeerd of toegestaan. Na het testen moeten organisaties een rollback-plan hebben voor het geval een configuratie problemen veroorzaakt in productie.

Gebruik PowerShell-script network-security-groups-configured.ps1 (functie Invoke-Monitoring) – Voert een validatiecontrole uit op Network Security Group-configuraties om te bepalen of NSG's correct zijn geconfigureerd volgens beveiligingsbest practices en compliance-vereisten..

Logging en monitoring

Het inschakelen en configureren van NSG Flow Logs is een verplichte beveiligingsmaatregel 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).

Het configureren van diagnostische instellingen voor NSG's is belangrijk voor het loggen van NSG-activiteiten 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 ervoor zorgen dat logs worden bewaard voor de vereiste perioden. Het is aanbevolen om diagnostische instellingen te configureren via Infrastructure as Code of geautomatiseerde scripts om consistentie te waarborgen en te voorkomen dat NSG's worden aangemaakt zonder logging.

Het integreren van NSG-logs met Azure Monitor en Log Analytics biedt krachtige mogelijkheden voor netwerkanalyse en bedreigingsdetectie. Log Analytics biedt query-taal (KQL) waarmee organisaties complexe queries kunnen uitvoeren op NSG-logs om patronen te identificeren, afwijkingen te detecteren, en compliance-rapportages te genereren. Bijvoorbeeld, organisaties kunnen queries maken die identificeren wanneer er herhaalde pogingen zijn om toegang te krijgen tot geblokkeerde poorten, wat kan wijzen op een aanval of een configuratiefout. Organisaties kunnen ook queries maken die analyseren welk verkeer het meest wordt geblokkeerd, wat kan helpen bij het optimaliseren van NSG-regels of het identificeren van nieuwe bedrijfsvereisten. Azure Monitor biedt de mogelijkheid om alertregels te configureren die waarschuwingen genereren bij ongebruikelijke activiteiten, zoals plotselinge toename van geblokkeerd verkeer, herhaalde pogingen tot toegang tot geblokkeerde poorten, of verkeer van bekende kwaadaardige IP-adressen. Deze alerts kunnen worden geïntegreerd met incident response-processen om snelle reactie op bedreigingen mogelijk te maken.

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 configureren van alertregels voor NSG-activiteiten is belangrijk voor proactieve bedreigingsdetectie en snelle incidentrespons. Organisaties moeten alertregels configureren die waarschuwingen genereren bij ongebruikelijke activiteiten, zoals plotselinge toename van geblokkeerd verkeer, herhaalde pogingen tot toegang tot geblokkeerde poorten, of verkeer van bekende kwaadaardige IP-adressen. Deze alerts moeten worden geïntegreerd met incident response-processen en moeten worden geconfigureerd met de juiste prioriteiten en escalatiepaden. Organisaties moeten ook overwegen om alerts te configureren voor configuratiewijzigingen, zoals wanneer NSG-regels worden toegevoegd, gewijzigd of verwijderd, om te detecteren wanneer onbevoegde wijzigingen worden gemaakt. Deze alerts kunnen worden geïntegreerd met Azure Security Center of Azure Sentinel voor geavanceerde security orchestration en automated response (SOAR) mogelijkheden. Het is belangrijk om alertregels regelmatig te reviewen en te optimaliseren om te voorkomen dat te veel false positives worden gegenereerd, wat kan leiden tot alert fatigue en het missen van echte bedreigingen.

Beveiligingsvalidatie en testing

Het valideren van NSG-configuraties is een continu proces dat moet worden uitgevoerd voordat configuraties in productie worden geïmplementeerd, en regelmatig daarna om te waarborgen dat configuraties correct blijven werken. Validatie begint met het testen van NSG-regels in een niet-productieomgeving die zo veel mogelijk lijkt op de productieomgeving. Tijdens het testen moeten organisaties alle scenario's testen: normale werking van workloads, beheeractiviteiten zoals RDP of SSH, backup- en monitoring-activiteiten, en disaster recovery-scenario's. Organisaties moeten ook testen of deny-regels correct werken door te proberen verbinding te maken met geblokkeerde poorten of vanaf geblokkeerde bronnen. Azure biedt de mogelijkheid om NSG-regels te versieren, wat nuttig is voor het testen van nieuwe regels voordat ze volledig worden geactiveerd. Tijdens het testen moeten organisaties NSG Flow Logs gebruiken om te verifiëren dat verkeer wordt gefilterd zoals verwacht en om te identificeren of er onverwacht verkeer wordt geblokkeerd of toegestaan.

Het uitvoeren van regelmatige security assessments van NSG-configuraties is essentieel om te waarborgen dat configuraties up-to-date blijven en aansluiten bij veranderende bedrijfsbehoeften en beveiligingsvereisten. Tijdens deze assessments moeten organisaties alle NSG-regels reviewen om te verifiëren dat regels nog steeds nodig zijn, correct zijn geconfigureerd, en voldoen aan het principe van least privilege. Organisaties moeten ook controleren of er ongebruikte regels zijn die kunnen worden verwijderd, of brede regels die kunnen worden aangescherpt. NSG Flow Logs kunnen worden gebruikt om te analyseren welk verkeer daadwerkelijk door NSG's wordt gefilterd, wat kan helpen bij het identificeren van ongebruikte regels of het detecteren van onverwacht verkeer. Organisaties moeten minimaal kwartaalgewijs een security assessment uitvoeren, en vaker voor kritieke workloads of wanneer er significante wijzigingen zijn aan de netwerkarchitectuur. De resultaten van security assessments 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 voor NSG-configuratievalidatie kan helpen bij het identificeren van configuratiefouten en het waarborgen van consistentie. Azure Policy kan worden gebruikt om policies te definiëren die vereisen dat NSG's specifieke regels bevatten (bijvoorbeeld default deny-regels), dat NSG Flow Logs zijn ingeschakeld, of dat bepaalde configuraties worden gebruikt. 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 NSG Flow Logs in te schakelen wanneer ze ontbreken. Het bijbehorende PowerShell-script kan worden gebruikt om regelmatige validatiechecks uit te voeren die controleren of NSG-configuraties voldoen aan beveiligingsbest practices en compliance-vereisten. Deze geautomatiseerde aanpak vermindert de werklast voor IT-teams en zorgt voor consistente beveiliging, zelfs wanneer er frequente wijzigingen zijn aan de cloudomgeving.

Het documenteren van NSG-configuraties en wijzigingen is belangrijk voor troubleshooting, audits en compliance. Organisaties moeten voor elke NSG een configuratiedocument bijhouden dat beschrijft welke regels zijn geconfigureerd, waarom ze nodig zijn, welke workloads ermee worden beveiligd, en wie verantwoordelijk is voor het beheer. Wijzigingen aan NSG-configuraties moeten worden gedocumenteerd in een changelog 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. Deze documentatie is waardevol voor troubleshooting wanneer verkeer onverwacht wordt geblokkeerd, voor audits wanneer organisaties moeten aantonen dat NSG's correct zijn geconfigureerd, en voor compliance-rapportages wanneer organisaties moeten laten zien dat beveiligingsmaatregelen worden geïmplementeerd en gereviewd. Organisaties moeten ook overwegen om NSG-configuraties te versiebeheren via Infrastructure as Code, wat helpt bij het bijhouden van wijzigingen en het terugdraaien van problematische configuraties.

Operationele best practices

Effectief beheer van Network Security Group-configuraties vereist duidelijke processen, gedefinieerde verantwoordelijkheden en continue monitoring. Organisaties moeten vastleggen wie verantwoordelijk is voor het dagelijks beheer van NSG-configuraties, 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.

Het automatiseren van NSG-configuratiechecks via Azure Policy en scripts kan helpen bij het waarborgen van consistentie en het voorkomen van configuratiefouten. Organisaties kunnen policies definiëren die vereisen dat NSG's specifieke regels bevatten (bijvoorbeeld default deny-regels), dat NSG Flow Logs zijn ingeschakeld, of dat bepaalde configuraties worden gebruikt. 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. Het bijbehorende PowerShell-script kan worden gebruikt om regelmatige validatiechecks uit te voeren die controleren of NSG-configuraties voldoen aan beveiligingsbest practices en compliance-vereisten. Deze geautomatiseerde aanpak vermindert de werklast voor IT-teams en zorgt voor consistente beveiliging, zelfs wanneer er frequente wijzigingen zijn aan de cloudomgeving.

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, governance en verantwoording

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.

Effectieve governance van Network Security Group-configuraties vereist duidelijke processen, gedefinieerde verantwoordelijkheden en continue monitoring. Organisaties moeten vastleggen wie verantwoordelijk is voor het beheer van NSG-configuraties, 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. Organisaties moeten ook overwegen om Azure Policy te gebruiken om consistente NSG-configuraties af te dwingen en te voorkomen dat niet-compliant configuraties worden geïmplementeerd. 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, wat helpt om configuratiedrift te voorkomen en consistentie te waarborgen.

Voor verantwoording richting bestuur en politiek is het belangrijk dat de complexiteit van Network Security Group-configuraties 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
<# .SYNOPSIS Azure Network Security Groups Configuratie Validatie en Implementatie .DESCRIPTION Dit script ondersteunt Nederlandse overheidsorganisaties bij het valideren en implementeren van correct geconfigureerde Network Security Groups (NSG's) in Azure-omgevingen. Het script controleert de configuratie van alle NSG's, valideert of regels correct zijn geconfigureerd volgens beveiligingsbest practices, en identificeert configuratiefouten zoals overbrede regels, ontbrekende default deny-regels, of verkeerd ingestelde prioriteiten. Het script is ontworpen om veilig lokaal of vanuit een beheerde automation-runner te draaien met READ-ONLY rechten voor monitoring, en met beperkte schrijfrechten voor remediatie. Het voert configuratiewijzigingen alleen uit na expliciete bevestiging of in WhatIf-modus. .NOTES Filename: network-security-groups-configured.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-15 Version: 1.0 Related JSON: content/azure/network/network-security-groups-configured.json Category: network Workload: azure .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\network-security-groups-configured.ps1 -Monitoring Voert een read-only validatie uit van alle NSG-configuraties en toont een samenvatting van de huidige status. .EXAMPLE .\network-security-groups-configured.ps1 -Remediation -WhatIf Genereert een rapport met concrete aanbevelingen zonder wijzigingen aan te brengen. .EXAMPLE .\network-security-groups-configured.ps1 -ExportPath .\nsg-config-report.json Exporteert de validatie- en aanbevelingsgegevens naar een JSON-bestand. #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Network, Az.Resources, Az.Monitor [CmdletBinding()] param( [Parameter(HelpMessage = "Voer een read-only validatie uit van alle Network Security Group-configuraties")] [switch]$Monitoring, [Parameter(HelpMessage = "Genereer aanbevelingen en implementeer ontbrekende NSG-configuraties")] [switch]$Remediation, [Parameter(HelpMessage = "Draai implementatiewijzigingen terug (indien mogelijk)")] [switch]$Revert, [Parameter(HelpMessage = "Toon welke acties zouden worden uitgevoerd zonder deze echt uit te voeren")] [switch]$WhatIf, [Parameter(HelpMessage = "Optioneel pad om resultaten als JSON te exporteren")] [string]$ExportPath ) $ErrorActionPreference = 'Stop' # ============================================================================ # HEADER # ============================================================================ Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Azure NSG Configuratie – Validatie" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan # ============================================================================ # HULPFUNCTIES # ============================================================================ function Connect-NbvvcAzContext { <# .SYNOPSIS Zorgt voor een geldige Az-context voor leesacties .DESCRIPTION Probeert eerst een bestaande context te gebruiken. Als er geen context is, wordt Connect-AzAccount aangeroepen. Dit is geschikt voor lokale debug- scenario's met een interactieve sessie of een managed identity. #> [CmdletBinding()] param() try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Geen actieve Azure-context gevonden. Probeer te verbinden..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null $context = Get-AzContext -ErrorAction Stop } Write-Host "Actieve Azure-context: $($context.Subscription.Name) [$($context.Subscription.Id)]" -ForegroundColor Gray return $context } catch { Write-Host "[FAIL] Kon geen geldige Azure-context verkrijgen: $_" -ForegroundColor Red throw } } function Get-NbvvcNSGConfigurationStatus { <# .SYNOPSIS Verzamelt de configuratiestatus van alle Network Security Groups .DESCRIPTION Haalt de configuratiestatus op van NSG's, valideert regels op best practices, controleert op configuratiefouten, en identificeert ontbrekende of suboptimale configuraties. De validatie is read-only en bedoeld als input voor verder architectuur- en compliancewerk. .OUTPUTS Hashtable met NSG-configuratiestatus per component #> [CmdletBinding()] param() $status = @{ timestamp = Get-Date subscriptionId = (Get-AzContext).Subscription.Id networkSecurityGroups = @{ totalCount = 0 compliantCount = 0 nonCompliantCount = 0 nsgDetails = @() findings = @() } configurationIssues = @{ overlyBroadRules = 0 missingDefaultDeny = 0 incorrectPriorities = 0 missingFlowLogs = 0 missingDiagnosticSettings = 0 issues = @() } overallScore = 0 } Write-Host "`nValidatie van Network Security Group-configuraties (read-only)..." -ForegroundColor Yellow # NSG's - Inventariseer alle Network Security Groups try { $nsgs = Get-AzNetworkSecurityGroup -ErrorAction SilentlyContinue $status.networkSecurityGroups.totalCount = $nsgs.Count Write-Host " Network Security Groups: $($nsgs.Count) gevonden" -ForegroundColor Gray foreach ($nsg in $nsgs) { $nsgDetail = @{ name = $nsg.Name resourceGroup = $nsg.ResourceGroupName location = $nsg.Location id = $nsg.Id ruleCount = 0 inboundRuleCount = 0 outboundRuleCount = 0 hasDefaultDenyInbound = $false hasDefaultDenyOutbound = $false hasOverlyBroadRules = $false hasFlowLogs = $false hasDiagnosticSettings = $false configurationIssues = @() isCompliant = $false } # Analyseer NSG-regels if ($nsg.SecurityRules) { $nsgDetail.ruleCount = $nsg.SecurityRules.Count $inboundRules = $nsg.SecurityRules | Where-Object { $_.Direction -eq 'Inbound' } $outboundRules = $nsg.SecurityRules | Where-Object { $_.Direction -eq 'Outbound' } $nsgDetail.inboundRuleCount = $inboundRules.Count $nsgDetail.outboundRuleCount = $outboundRules.Count # Controleer op default deny-regels $denyInbound = $inboundRules | Where-Object { $_.Access -eq 'Deny' -and ($_.SourceAddressPrefix -eq '*' -or $_.SourceAddressPrefix -eq 'Internet') -and ($_.DestinationAddressPrefix -eq '*' -or $_.DestinationAddressPrefix -eq 'VirtualNetwork') } $denyOutbound = $outboundRules | Where-Object { $_.Access -eq 'Deny' -and ($_.SourceAddressPrefix -eq '*' -or $_.SourceAddressPrefix -eq 'Internet') -and ($_.DestinationAddressPrefix -eq '*' -or $_.DestinationAddressPrefix -eq 'Internet') } if ($denyInbound.Count -gt 0) { $nsgDetail.hasDefaultDenyInbound = $true } else { $status.configurationIssues.missingDefaultDeny++ $nsgDetail.configurationIssues += "Ontbrekende default deny-regel voor inkomend verkeer" } if ($denyOutbound.Count -gt 0) { $nsgDetail.hasDefaultDenyOutbound = $true } # 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' -or $_.DestinationPortRange -eq '1-65535') } if ($broadRules.Count -gt 0) { $nsgDetail.hasOverlyBroadRules = $true $status.configurationIssues.overlyBroadRules++ $nsgDetail.configurationIssues += "$($broadRules.Count) overbrede regel(s) gevonden die verkeer van Internet naar alle poorten toestaan" } # Controleer regelprioriteiten (allow-regels moeten lagere prioriteit hebben dan deny-regels) $allowRules = $nsg.SecurityRules | Where-Object { $_.Access -eq 'Allow' } $denyRules = $nsg.SecurityRules | Where-Object { $_.Access -eq 'Deny' } if ($allowRules.Count -gt 0 -and $denyRules.Count -gt 0) { $minAllowPriority = ($allowRules | Measure-Object -Property Priority -Minimum).Minimum $maxDenyPriority = ($denyRules | Measure-Object -Property Priority -Maximum).Maximum if ($minAllowPriority -gt $maxDenyPriority) { $status.configurationIssues.incorrectPriorities++ $nsgDetail.configurationIssues += "Allow-regels hebben hogere prioriteit dan deny-regels; dit kan legitiem verkeer blokkeren" } } } # Controleer NSG Flow Logs try { $networkWatcher = Get-AzNetworkWatcher -ErrorAction SilentlyContinue | Select-Object -First 1 if ($networkWatcher) { $flowLogs = Get-AzNetworkWatcherFlowLog -NetworkWatcherName $networkWatcher.Name -ResourceGroupName $networkWatcher.ResourceGroupName -ErrorAction SilentlyContinue | Where-Object { $_.TargetResourceId -eq $nsg.Id } if ($flowLogs -and $flowLogs.Enabled) { $nsgDetail.hasFlowLogs = $true } else { $status.configurationIssues.missingFlowLogs++ $nsgDetail.configurationIssues += "NSG Flow Logs zijn niet ingeschakeld" } } } catch { # Network Watcher mogelijk niet beschikbaar } # Controleer diagnostische instellingen try { $diagnosticSettings = Get-AzDiagnosticSetting -ResourceId $nsg.Id -ErrorAction SilentlyContinue if ($diagnosticSettings) { $nsgDetail.hasDiagnosticSettings = $true } else { $status.configurationIssues.missingDiagnosticSettings++ $nsgDetail.configurationIssues += "Diagnostische instellingen zijn niet geconfigureerd" } } catch { # Diagnostische instellingen mogelijk niet beschikbaar } # Bepaal compliance $nsgDetail.isCompliant = ( $nsgDetail.ruleCount -gt 0 -and -not $nsgDetail.hasOverlyBroadRules -and ($nsgDetail.hasDefaultDenyInbound -or $nsgDetail.inboundRuleCount -eq 0) ) if ($nsgDetail.isCompliant) { $status.networkSecurityGroups.compliantCount++ } else { $status.networkSecurityGroups.nonCompliantCount++ } $status.networkSecurityGroups.nsgDetails += $nsgDetail } if ($nsgs.Count -eq 0) { $status.networkSecurityGroups.findings += "Geen Network Security Groups gevonden; overweeg implementatie voor netwerkbeveiliging." } else { $nonCompliantNSGs = $status.networkSecurityGroups.nsgDetails | Where-Object { -not $_.isCompliant } if ($nonCompliantNSGs.Count -gt 0) { $status.networkSecurityGroups.findings += "$($nonCompliantNSGs.Count) NSG(s) gevonden met configuratieproblemen; review en corrigeer configuraties." } } } catch { Write-Host " [WARN] Kon NSG-configuratiestatus niet volledig valideren: $_" -ForegroundColor Yellow $status.networkSecurityGroups.findings += "Kon NSG-configuratiestatus niet volledig valideren; controleer rechten en Az.Network-module." } # Bereken overall score if ($status.networkSecurityGroups.totalCount -gt 0) { $compliantPercentage = ($status.networkSecurityGroups.compliantCount / $status.networkSecurityGroups.totalCount) * 100 $status.overallScore = [math]::Round($compliantPercentage, 1) } return $status } function Invoke-Monitoring { <# .SYNOPSIS Voert een read-only NSG-configuratievalidatie uit .DESCRIPTION Gebruikt configuratiecontroles om inzicht te geven in de huidige NSG-configuraties per component. Dit helpt bij het prioriteren van implementatietrajecten en het identificeren van configuratiefouten. .OUTPUTS Hashtable met samenvattende metrics en status per component #> [CmdletBinding()] param() $null = Connect-NbvvcAzContext $status = Get-NbvvcNSGConfigurationStatus Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "SAMENVATTING NSG CONFIGURATIE STATUS" -ForegroundColor Cyan Write-Host " Overall Score : $($status.overallScore)%" -ForegroundColor White Write-Host "`n Network Security Groups:" -ForegroundColor Yellow Write-Host " Totaal aantal NSG's : $($status.networkSecurityGroups.totalCount)" -ForegroundColor Gray Write-Host " Compliant NSG's : $($status.networkSecurityGroups.compliantCount)" -ForegroundColor Green Write-Host " Non-compliant NSG's : $($status.networkSecurityGroups.nonCompliantCount)" -ForegroundColor $(if ($status.networkSecurityGroups.nonCompliantCount -gt 0) { "Red" } else { "Gray" }) Write-Host "`n Configuratieproblemen:" -ForegroundColor Yellow Write-Host " Overbrede regels : $($status.configurationIssues.overlyBroadRules)" -ForegroundColor $(if ($status.configurationIssues.overlyBroadRules -gt 0) { "Red" } else { "Gray" }) Write-Host " Ontbrekende deny : $($status.configurationIssues.missingDefaultDeny)" -ForegroundColor $(if ($status.configurationIssues.missingDefaultDeny -gt 0) { "Yellow" } else { "Gray" }) Write-Host " Verkeerde prioriteiten: $($status.configurationIssues.incorrectPriorities)" -ForegroundColor $(if ($status.configurationIssues.incorrectPriorities -gt 0) { "Yellow" } else { "Gray" }) Write-Host " Ontbrekende Flow Logs: $($status.configurationIssues.missingFlowLogs)" -ForegroundColor $(if ($status.configurationIssues.missingFlowLogs -gt 0) { "Yellow" } else { "Gray" }) Write-Host " Ontbrekende diagnostics: $($status.configurationIssues.missingDiagnosticSettings)" -ForegroundColor $(if ($status.configurationIssues.missingDiagnosticSettings -gt 0) { "Yellow" } else { "Gray" }) if ($status.networkSecurityGroups.nsgDetails.Count -gt 0) { Write-Host "`n NSG-details:" -ForegroundColor Yellow foreach ($nsgDetail in $status.networkSecurityGroups.nsgDetails) { $complianceStatus = if ($nsgDetail.isCompliant) { "✓" } else { "✗" } $color = if ($nsgDetail.isCompliant) { "Green" } else { "Red" } Write-Host " $complianceStatus $($nsgDetail.name) ($($nsgDetail.resourceGroup)): $($nsgDetail.ruleCount) regel(s)" -ForegroundColor $color if ($nsgDetail.configurationIssues.Count -gt 0) { foreach ($issue in $nsgDetail.configurationIssues) { Write-Host " - $issue" -ForegroundColor Yellow } } } } $allFindings = @() $allFindings += $status.networkSecurityGroups.findings $allFindings += $status.configurationIssues.issues if ($allFindings.Count -gt 0) { Write-Host "`nAandachtspunten:" -ForegroundColor Yellow foreach ($f in $allFindings) { Write-Host " - $f" -ForegroundColor Yellow } } else { Write-Host "`nGeen specifieke aandachtspunten gedetecteerd op basis van deze scan." -ForegroundColor Green } return @{ status = $status } } function Invoke-Remediation { <# .SYNOPSIS Genereert NSG-configuratieaanbevelingen en implementeert ontbrekende configuraties .DESCRIPTION Op basis van de configuratievalidatie worden concrete aanbevelingen gegenereerd voor vervolgstappen zoals het corrigeren van overbrede regels, het toevoegen van default deny-regels, of het inschakelen van NSG Flow Logs. Het script voert configuratiewijzigingen alleen uit na expliciete bevestiging of in WhatIf-modus. #> [CmdletBinding(SupportsShouldProcess)] param( [string]$ReportPath ) if ($WhatIf) { Write-Host "`nWhatIf: er wordt een aanbevelingsrapport gegenereerd op basis van configuratievalidatie, maar er vinden geen wijzigingen plaats." -ForegroundColor Yellow } $result = Invoke-Monitoring $status = $result.status $recommendations = @() if ($status.configurationIssues.overlyBroadRules -gt 0) { $recommendations += "Corrigeer $($status.configurationIssues.overlyBroadRules) overbrede NSG-regel(s) die verkeer van Internet naar alle poorten toestaan; gebruik specifieke bron-IP-adressen en poorten." } if ($status.configurationIssues.missingDefaultDeny -gt 0) { $recommendations += "Voeg default deny-regels toe aan $($status.configurationIssues.missingDefaultDeny) NSG(s) om ervoor te zorgen dat onbedoeld verkeer wordt geblokkeerd." } if ($status.configurationIssues.incorrectPriorities -gt 0) { $recommendations += "Corrigeer regelprioriteiten in $($status.configurationIssues.incorrectPriorities) NSG(s); allow-regels moeten een lagere prioriteit hebben dan deny-regels." } if ($status.configurationIssues.missingFlowLogs -gt 0) { $recommendations += "Schakel NSG Flow Logs in voor $($status.configurationIssues.missingFlowLogs) NSG(s) voor netwerkzichtbaarheid en compliance." } if ($status.configurationIssues.missingDiagnosticSettings -gt 0) { $recommendations += "Configureer diagnostische instellingen voor $($status.configurationIssues.missingDiagnosticSettings) NSG(s) voor logging en monitoring." } if ($status.networkSecurityGroups.nonCompliantCount -gt 0) { $recommendations += "Review en corrigeer configuraties voor $($status.networkSecurityGroups.nonCompliantCount) non-compliant NSG(s) volgens beveiligingsbest practices." } if ($recommendations.Count -eq 0) { $recommendations += "Geen specifieke aanbevelingen op basis van deze scan; voer een diepgaand netwerkarchitectuur-assessment uit voor optimalisatie." } Write-Host "`nAanbevolen vervolgstappen:" -ForegroundColor Cyan foreach ($rec in $recommendations) { Write-Host " - $rec" -ForegroundColor White } $report = @{ generatedAt = Get-Date subscriptionId = $status.subscriptionId overallScore = $status.overallScore nsgConfigStatus = @{ status = $status recommendations = $recommendations } } $targetPath = $null if ($PSBoundParameters.ContainsKey("ReportPath") -and $ReportPath) { $targetPath = $ReportPath } elseif ($ExportPath) { $targetPath = $ExportPath } if ($targetPath) { if ($PSCmdlet.ShouldProcess($targetPath, "Schrijf NSG-configuratie rapport naar JSON-bestand")) { $report | ConvertTo-Json -Depth 6 | Out-File -FilePath $targetPath -Encoding UTF8 Write-Host "`n[OK] Rapport geschreven naar: $targetPath" -ForegroundColor Green } } } function Invoke-Revert { <# .SYNOPSIS Draai implementatiewijzigingen terug .DESCRIPTION Dit script voert configuratiewijzigingen alleen uit na expliciete bevestiging. Revert-functionaliteit is beperkt omdat NSG-configuraties complex zijn en handmatige interventie vereisen. De functie is aanwezig voor consistentie met andere scripts binnen de Nederlandse Baseline voor Veilige Cloud. #> [CmdletBinding(SupportsShouldProcess)] param() Write-Host "`nNSG-configuraties vereisen handmatige interventie voor revert-operaties." -ForegroundColor Yellow Write-Host "Raadpleeg de documentatie en Azure-portal voor specifieke revert-stappen per component." -ForegroundColor Gray } function Invoke-Implementation { <# .SYNOPSIS Implementeert correct geconfigureerde Network Security Groups .DESCRIPTION Deze functie is een alias voor Invoke-Remediation voor consistentie met andere scripts binnen de Nederlandse Baseline voor Veilige Cloud. #> [CmdletBinding()] param() Invoke-Remediation } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { if ($Revert) { Invoke-Revert } elseif ($Remediation) { Invoke-Remediation -ReportPath $ExportPath } elseif ($Monitoring) { $null = Invoke-Monitoring } else { Write-Host "Beschikbare parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Voer een read-only NSG-configuratievalidatie uit" -ForegroundColor Gray Write-Host " -Remediation : Genereer NSG-configuratieaanbevelingen (geen wijzigingen)" -ForegroundColor Gray Write-Host " -Revert : Beperkte revert-functionaliteit (handmatige interventie vereist)" -ForegroundColor Gray Write-Host " -WhatIf : Toon welke acties logisch zouden zijn zonder uitvoer" -ForegroundColor Gray Write-Host " -ExportPath : Optioneel pad voor JSON-rapport" -ForegroundColor Gray Write-Host "`nVoorbeeld: .\network-security-groups-configured.ps1 -Monitoring" -ForegroundColor Cyan } } catch { Write-Error "Scriptuitvoering mislukt: $_" exit 2 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan } # Exitcodes: # 0 = Succesvolle uitvoering # 2 = Fout tijdens uitvoering

Risico zonder implementatie

Risico zonder implementatie
High: Een verkeerd geconfigureerde Network Security Group kan aanzienlijke beveiligingsrisico's creëren die vaak pas worden ontdekt tijdens een incident of audit. Veelvoorkomende configuratiefouten omvatten het gebruik van overbrede regels die verkeer toestaan van 'Internet' naar alle poorten, het ontbreken van default deny-regels waardoor onbedoeld verkeer wordt toegestaan, het verkeerd instellen van regelprioriteiten waardoor deny-regels per ongeluk allow-regels overschrijven, het niet inschakelen van NSG Flow Logs waardoor er geen zichtbaarheid is in netwerkactiviteiten, en het niet regelmatig reviewen van regels waardoor verouderde of ongebruikte regels blijven bestaan. Deze fouten kunnen leiden tot ongeautoriseerde toegang tot virtuele machines, data exfiltration, laterale beweging van aanvallers binnen netwerken, en het onvermogen om beveiligingsincidenten te detecteren of te onderzoeken. 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 verkeerde configuratie onacceptabel: deze frameworks vereisen niet alleen dat netwerkfiltering aanwezig is, maar ook dat deze correct is geconfigureerd, wordt gemonitord en regelmatig wordt gereviewd.

Management Samenvatting

Het correct configureren van Network Security Groups is een kritieke beveiligingsmaatregel die bepaalt hoe effectief netwerkverkeer wordt gefilterd en beveiligd binnen Azure Virtual Networks. Door een gestandaardiseerde configuratiemethodologie, moderne NSG-regelontwerp 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 valideert automatisch NSG-configuraties, controleert of regels correct zijn geconfigureerd volgens best practices, identificeert configuratiefouten en genereert compliance-rapportages. De benodigde inspanning is beperkt (circa 56 uur initiële implementatie), terwijl de risicoreductie en auditbaarheid aanzienlijk zijn voor alle netwerkgebaseerde diensten in Azure.