Netwerksegmentatie: Architectuur En Implementatie

Zonder effectieve netwerksegmentatie zijn alle resources binnen een Azure Virtual Network in principe met elkaar verbonden en kunnen ze vrijelijk met elkaar communiceren. Dit creëert aanzienlijke beveiligingsrisico's: wanneer een aanvaller toegang krijgt tot één systeem, kan deze zich gemakkelijk verplaatsen naar andere systemen binnen hetzelfde netwerk, wat bekend staat als lateral movement. Een compromittering van een webserver kan bijvoorbeeld leiden tot toegang tot databases, applicatieservers en andere kritieke systemen zonder aanvullende beveiligingscontroles. Dit is bijzonder problematisch voor Nederlandse overheidsorganisaties die werken met gevoelige persoonsgegevens, vertrouwelijke informatie en kritieke infrastructuur: een datalek kan zich snel verspreiden door het hele netwerk, waardoor grote hoeveelheden data worden blootgesteld en de organisatie wordt geconfronteerd met aanzienlijke compliance-schendingen, boetes en reputatieschade. Zonder netwerksegmentatie ontbreekt ook zicht op netwerkverkeer: organisaties kunnen niet effectief monitoren welke systemen met elkaar communiceren, wat normaal verkeer is versus verdacht verkeer, en waar potentiële bedreigingen zich bevinden. Dit maakt het onmogelijk om proactief te reageren op beveiligingsincidenten en om te voldoen aan audit- en verantwoordingsvereisten. De Baseline Informatiebeveiliging Overheid (BIO) vereist expliciet netwerksegmentatie en isolatie van systemen op basis van beveiligingsclassificatie, ISO 27001 vereist netwerkbeveiligingscontroles die systemen isoleren en toegang beperken, en de Network and Information Systems Directive 2 (NIS2) vereist passende technische maatregelen om de impact van beveiligingsincidenten te beperken. Zonder netwerksegmentatie kunnen organisaties niet aantonen dat zij passende maatregelen hebben genomen om systemen te isoleren en te beschermen.

Implementatie

Dit artikel beschrijft hoe organisaties binnen de Nederlandse Baseline voor Veilige Cloud effectieve netwerksegmentatie implementeren in Azure-omgevingen als onderdeel van een gelaagde beveiligingsstrategie. De focus ligt op vijf hoofdcomponenten. Ten eerste architectuur en ontwerp: het begrijpen van segmentatieprincipes en best practices, het ontwerpen van een segmentatiestrategie op basis van beveiligingsvereisten en bedrijfsbehoeften, het kiezen tussen verschillende architectuurpatronen zoals hub-spoke, mesh of gedistribueerde topologieën, en het plannen van IP-adresruimte en subnetconfiguraties. Ten tweede subnetsegmentatie: het maken van logische netwerksegmenten voor verschillende workload-categorieën zoals webservers, applicatieservers, databases en management-systemen, het implementeren van subnetgebaseerde isolatie met Network Security Groups, het configureren van route tabellen voor verkeerscontrole, en het toepassen van consistente naamgevingsconventies en tags. Ten derde microsegmentatie: het implementeren van granulair toegangscontrole op het niveau van individuele virtuele machines en applicaties, het gebruik van Application Security Groups voor vereenvoudigd beheer, het configureren van Network Security Groups op netwerkinterfaceniveau, en het toepassen van Zero Trust-principes waarbij verkeer standaard wordt geweigerd tenzij expliciet toegestaan. Ten vierde geavanceerde segmentatie: het gebruik van Azure Private Link voor PaaS-service-isolatie, het implementeren van Virtual Network peering met gecontroleerde verkeersstroom, het configureren van Azure Firewall voor gecentraliseerde netwerkfiltering, en het integreren van hybride connectiviteit via VPN of ExpressRoute met segmentatie. Ten vijfde operationalisatie en governance: het opzetten van change management-processen voor netwerkwijzigingen, het implementeren van periodieke reviews en audits, het monitoren van netwerkverkeer en het detecteren van afwijkingen, en het borgen van compliance met relevante frameworks. Het bijbehorende PowerShell-script inventariseert alle Virtual Networks en subnetten in een abonnement, analyseert de segmentatiestructuur, controleert of subnetten correct zijn geïsoleerd met Network Security Groups, identificeert ontbrekende segmentatie of onveilige configuraties, en rapporteert over de compliance-status van de netwerksegmentatie.

Architectuur en ontwerp van netwerksegmentatie

Effectieve netwerksegmentatie begint bij een doordacht architectuurontwerp dat aansluit bij de beveiligingsvereisten, bedrijfsbehoeften en compliance-verplichtingen van de organisatie. In plaats van ad-hoc subnetten toe te voegen wanneer nieuwe workloads worden geïmplementeerd, is het essentieel om vanuit een referentiearchitectuur te werken waarin netwerksegmenten logisch worden gedefinieerd op basis van beveiligingsclassificatie, functionele rol en vertrouwensniveau. Voor Nederlandse overheidsorganisaties zijn er verschillende segmentatiepatronen mogelijk: een functionele segmentatie waarbij subnetten worden georganiseerd op basis van workload-type zoals webservers, applicatieservers, databases en management-systemen, een classificatiegebaseerde segmentatie waarbij subnetten worden georganiseerd op basis van beveiligingsclassificatie zoals publiek, intern, vertrouwelijk en geheim, of een hybride aanpak die beide dimensies combineert. De keuze hangt af van factoren zoals de schaal van de omgeving, de complexiteit van de workloads, de compliance-vereisten en de gewenste mate van isolatie versus connectiviteit.

Een kritieke architectuurkeuze betreft de selectie van een netwerktopologie die netwerksegmentatie ondersteunt. De hub-spoke topologie is een veelgebruikt patroon waarbij een centraal hub Virtual Network fungeert als gecentraliseerd punt voor gedeelde services zoals Azure Firewall, VPN-gateways en DNS-servers, terwijl spoke Virtual Networks worden gebruikt voor specifieke workloads of afdelingen. Deze topologie biedt voordelen zoals gecentraliseerd beheer, consistente beveiligingscontroles via de hub, en schaalbaarheid door nieuwe spokes toe te voegen zonder de hub te wijzigen. Een alternatief is een mesh-topologie waarbij alle Virtual Networks direct met elkaar zijn verbonden via peering, wat meer flexibiliteit biedt maar complexer is om te beheren en te beveiligen. Voor kleinere omgevingen kan een enkele Virtual Network met meerdere subnetten voldoende zijn, terwijl voor grote, gedistribueerde organisaties een combinatie van topologieën nodig kan zijn. Ongeacht de gekozen topologie moet de architectuur expliciet rekening houden met verkeersstroom: welke segmenten mogen met elkaar communiceren, via welke routes, en welke beveiligingscontroles worden toegepast op elk verkeerspad.

IP-adresruimte planning is een fundamenteel onderdeel van netwerksegmentatie-architectuur. Organisaties moeten een gestructureerde aanpak hanteren waarbij IP-adresruimte wordt toegewezen aan verschillende segmenten op basis van verwachte groei, subnetgrootte en toekomstige uitbreidingsmogelijkheden. Het is aanbevolen om gebruik te maken van private IP-adresruimte zoals 10.0.0.0/8, 172.16.0.0/12 of 192.168.0.0/16, en om een hiërarchische structuur te creëren waarbij verschillende regio's, omgevingen of afdelingen hun eigen IP-adresbereiken krijgen. Bijvoorbeeld: 10.0.0.0/16 voor productieomgevingen, 10.1.0.0/16 voor testomgevingen, en 10.2.0.0/16 voor ontwikkelomgevingen. Binnen elk bereik kunnen subnetten worden toegewezen voor verschillende segmenten: bijvoorbeeld 10.0.1.0/24 voor webservers, 10.0.2.0/24 voor applicatieservers, en 10.0.3.0/24 voor databases. Het is belangrijk om voldoende adresruimte te reserveren voor toekomstige groei en om te voorkomen dat subnetten te klein worden waardoor herconfiguratie nodig is. Daarnaast moeten organisaties rekening houden met hybride scenario's waarbij Azure-netwerken worden verbonden met on-premises netwerken: IP-adresruimte moet uniek zijn en mag niet overlappen met bestaande on-premises adresruimte om routingproblemen te voorkomen.

Beveiligingszones en vertrouwensniveaus vormen de basis voor effectieve netwerksegmentatie. Organisaties moeten expliciet definiëren welke beveiligingszones bestaan, welke systemen en data in elke zone worden geplaatst, en welke verkeersregels gelden tussen zones. Een veelgebruikt model is de drie-zone architectuur: een perimeterzone (DMZ) voor internetgerichte services zoals webservers en load balancers, een applicatiezone voor applicatieservers en middleware, en een datazone voor databases en opslag. Elke zone heeft zijn eigen beveiligingsvereisten en toegangscontroles: verkeer van internet naar de perimeterzone wordt gefilterd door Azure Firewall, verkeer van de perimeterzone naar de applicatiezone wordt gecontroleerd door Network Security Groups, en verkeer naar de datazone is strikt beperkt tot alleen geautoriseerde applicatieservers. Binnen zones kunnen aanvullende segmenten worden gemaakt op basis van specifieke beveiligingsvereisten: bijvoorbeeld aparte subnetten voor productie- versus test-workloads, of aparte segmenten voor systemen die werken met verschillende beveiligingsclassificaties. Deze zonegebaseerde aanpak maakt het mogelijk om beveiligingscontroles gelaagd toe te passen en om de impact van beveiligingsincidenten te beperken door ervoor te zorgen dat een compromittering in één zone niet automatisch leidt tot toegang tot andere zones.

Compliance en governance overwegingen moeten vanaf het begin worden meegenomen in het architectuurontwerp. Nederlandse overheidsorganisaties moeten kunnen aantonen dat netwerksegmentatie correct is geïmplementeerd en dat systemen met verschillende beveiligingsclassificaties adequaat zijn geïsoleerd. Dit vereist documentatie van de segmentatiestrategie, netwerkdiagrammen die de verschillende segmenten en verkeersstromen tonen, en bewijs dat beveiligingscontroles daadwerkelijk werken zoals bedoeld. De architectuur moet ook rekening houden met toekomstige wijzigingen: wanneer nieuwe workloads worden toegevoegd, moeten deze passen binnen de bestaande segmentatiestructuur, en wanneer beveiligingsvereisten veranderen, moet de architectuur flexibel genoeg zijn om aanpassingen mogelijk te maken zonder volledige herconfiguratie. Daarnaast moeten organisaties rekening houden met operationele aspecten: segmentatie mag niet leiden tot onnodige complexiteit die het dagelijks beheer bemoeilijkt, en er moeten duidelijke processen zijn voor het beheren van uitzonderingen en het goedkeuren van nieuwe verkeersregels tussen segmenten.

Subnetsegmentatie en isolatie

Subnetsegmentatie vormt de basislaag van netwerksegmentatie in Azure en biedt logische isolatie tussen verschillende workload-categorieën binnen een Virtual Network. Een subnet is een reeks IP-adressen binnen een Virtual Network die logisch worden gegroepeerd en waaraan Network Security Groups en route tabellen kunnen worden gekoppeld om verkeer te controleren en te routeren. Effectieve subnetsegmentatie vereist dat organisaties expliciet definiëren welke workloads in welk subnet worden geplaatst, welke beveiligingsregels gelden voor elk subnet, en hoe verkeer tussen subnetten wordt gecontroleerd. Het is aanbevolen om subnetten te creëren voor verschillende functionele rollen: bijvoorbeeld aparte subnetten voor webservers, applicatieservers, databases, management-systemen, en gedeelde services zoals DNS en monitoring. Elke subnet moet zijn eigen Network Security Group hebben met specifieke regels die zijn afgestemd op de beveiligingsvereisten van de workloads in dat subnet.

Network Security Groups vormen het primaire mechanisme voor het implementeren van subnetgebaseerde isolatie en toegangscontrole. Elke subnet moet worden gekoppeld aan een Network Security Group die expliciete regels definieert voor inkomend en uitgaand verkeer. Het principe van default deny moet worden toegepast: alle verkeer wordt standaard geweigerd tenzij expliciet toegestaan door een regel. Dit betekent dat organisaties zorgvuldig moeten nadenken over welke verkeersstromen legitiem zijn en moeten worden toegestaan, en welke verkeersstromen moeten worden geblokkeerd. Voor een webserver-subnet kunnen bijvoorbeeld alleen inkomende HTTP- en HTTPS-verkeer worden toegestaan vanaf internet en van load balancers, terwijl directe toegang tot databases of andere interne systemen wordt geblokkeerd. Voor een database-subnet kan alleen verkeer worden toegestaan vanaf specifieke applicatieserver-subnetten op specifieke poorten zoals SQL-poort 1433, terwijl alle andere verkeer wordt geblokkeerd. Deze granulair toegangscontrole maakt het mogelijk om lateral movement te voorkomen: zelfs als een aanvaller toegang krijgt tot een systeem in één subnet, kan deze niet automatisch toegang krijgen tot systemen in andere subnetten zonder de juiste netwerkregels.

Route tabellen bieden aanvullende controle over verkeersstroom tussen subnetten en naar externe bestemmingen. Door User Defined Routes (UDR's) te configureren kunnen organisaties expliciet definiëren hoe verkeer wordt gerouteerd: bijvoorbeeld alle uitgaand verkeer naar internet via Azure Firewall, of verkeer tussen specifieke subnetten via specifieke routes. Route tabellen kunnen worden gekoppeld aan subnetten om verkeersstroom te controleren, wat nuttig is voor het implementeren van hub-spoke topologieën waarbij alle verkeer via een centrale hub wordt gerouteerd, of voor het forceren van verkeer via beveiligingsapparaten zoals firewalls of intrusion detection systemen. Het is belangrijk om te begrijpen dat route tabellen werken op Layer 3 (netwerklaag) en verkeer routeren op basis van IP-adressen, terwijl Network Security Groups werken op Layer 4 (transportlaag) en verkeer filteren op basis van poorten en protocollen. Beide mechanismen moeten samenwerken om effectieve netwerksegmentatie te bereiken: route tabellen bepalen waar verkeer naartoe gaat, terwijl Network Security Groups bepalen welk verkeer wordt toegestaan.

Subnetgrootte en IP-adresplanning zijn belangrijke overwegingen bij subnetsegmentatie. Subnetten moeten groot genoeg zijn om toekomstige groei te accommoderen, maar niet zo groot dat ze onnodig IP-adresruimte verspillen of dat beveiligingscontroles te breed worden toegepast. Een veelgebruikte aanpak is om subnetten te maken met een /24 CIDR-blok (256 IP-adressen) voor de meeste workloads, wat voldoende ruimte biedt voor groei terwijl het beheerbaar blijft. Voor kleinere segmenten zoals management-subnetten kan een /26 of /27 worden gebruikt, terwijl voor grote segmenten zoals webserver-farms een /23 of groter nodig kan zijn. Het is belangrijk om te onthouden dat Azure vijf IP-adressen reserveert in elk subnet voor interne doeleinden, dus een /24 subnet biedt in werkelijkheid 251 bruikbare IP-adressen. Bij het plannen van subnetgrootte moeten organisaties rekening houden met factoren zoals het verwachte aantal virtuele machines, de behoefte aan load balancers en andere netwerkapparaten, en de mogelijkheid van toekomstige uitbreiding. Het is verstandig om een subnetgrootte te kiezen die ruimte biedt voor ten minste 50% groei zonder herconfiguratie.

Gebruik PowerShell-script network-segmentation.ps1 (functie Invoke-Monitoring) – Voert een monitoringcontrole uit op netwerksegmentatie om te bepalen of Virtual Networks en subnetten correct zijn geconfigureerd met Network Security Groups en isolatie..

Microsegmentatie en granulair toegangscontrole

Microsegmentatie gaat verder dan subnetsegmentatie door granulair toegangscontrole toe te passen op het niveau van individuele virtuele machines, netwerkinterfaces en applicaties. Terwijl subnetsegmentatie verkeer controleert tussen logische netwerksegmenten, maakt microsegmentatie het mogelijk om verkeer te controleren tussen individuele systemen binnen hetzelfde subnet, waardoor de beveiligingsperimeter wordt verkleind en de impact van beveiligingsincidenten verder wordt beperkt. Microsegmentatie is bijzonder waardevol in omgevingen waar verschillende workloads met verschillende beveiligingsvereisten binnen hetzelfde subnet moeten draaien, of waar aanvullende isolatie nodig is tussen systemen die normaal gesproken in hetzelfde segment zouden worden geplaatst. Door microsegmentatie toe te passen kunnen organisaties Zero Trust-principes implementeren waarbij elk systeem wordt behandeld als een potentiële bedreiging en verkeer standaard wordt geweigerd tenzij expliciet toegestaan.

Application Security Groups (ASG's) bieden een krachtige manier om microsegmentatie te implementeren zonder complexe IP-adresgebaseerde regels te beheren. In plaats van regels te definiëren op basis van specifieke IP-adressen, kunnen organisaties ASG's maken die logisch workloads groeperen op basis van functie, zoals webservers, applicatieservers of databases. Vervolgens kunnen Network Security Group-regels worden gedefinieerd die verkeer toestaan of weigeren tussen ASG's, waardoor het beheer wordt vereenvoudigd en de configuratie flexibeler wordt. Wanneer een nieuwe virtuele machine wordt toegevoegd aan een ASG, erft deze automatisch de netwerkregels die op die ASG zijn toegepast, zonder dat handmatige wijzigingen aan Network Security Groups nodig zijn. Dit maakt het mogelijk om dynamisch workloads toe te voegen of te verwijderen terwijl de beveiligingsconfiguratie consistent blijft. ASG's kunnen worden gecombineerd met subnetgebaseerde segmentatie voor een gelaagde beveiligingsaanpak: subnetten bieden grove isolatie tussen verschillende zones, terwijl ASG's binnen subnetten granulair toegangscontrole bieden tussen individuele workloads.

Network Security Groups op netwerkinterfaceniveau bieden de meest granulair vorm van microsegmentatie door individuele netwerkinterfaces te beveiligen in plaats van hele subnetten. Wanneer een Network Security Group wordt gekoppeld aan een netwerkinterface, worden de regels in die NSG geëvalueerd in combinatie met de regels in de subnet-NSG, waarbij de meest restrictieve regel wordt toegepast. Dit maakt het mogelijk om specifieke virtuele machines of groepen van virtuele machines aanvullende beveiligingscontroles toe te passen zonder de regels voor het hele subnet te wijzigen. Bijvoorbeeld: een database-server kan een Network Security Group op netwerkinterfaceniveau hebben die alleen verkeer toestaat vanaf specifieke applicatieservers, zelfs als de subnet-NSG bredere regels heeft. Deze aanpak is bijzonder nuttig voor het beveiligen van kritieke systemen of voor het implementeren van tijdelijke beveiligingsmaatregelen tijdens incidentrespons. Het is echter belangrijk om te onthouden dat Network Security Groups op netwerkinterfaceniveau de beheercomplexiteit kunnen verhogen, en dat organisaties een balans moeten vinden tussen beveiligingsgranulariteit en beheerbaarheid.

Service tags en service endpoints bieden aanvullende mogelijkheden voor microsegmentatie door verkeer te controleren naar en van specifieke Azure-services. Service tags zijn vooraf gedefinieerde labels die groepen van IP-adressen vertegenwoordigen die worden gebruikt door Azure-services zoals Azure Storage, Azure SQL Database of Azure Key Vault. Door service tags te gebruiken in Network Security Group-regels kunnen organisaties verkeer toestaan of weigeren naar specifieke Azure-services zonder handmatig IP-adresbereiken te beheren, wat de configuratie vereenvoudigt en onderhoudbaarheid verbetert. Service endpoints maken het mogelijk om verkeer naar Azure PaaS-services te routeren via het Azure-backbone-netwerk in plaats van via internet, wat beveiliging verbetert en kosten kan verlagen. Wanneer service endpoints zijn ingeschakeld voor een subnet, kunnen Network Security Group-regels worden geconfigureerd die alleen verkeer toestaan naar specifieke Azure-services via service endpoints, terwijl directe internettoegang wordt geblokkeerd. Deze combinatie van service tags en service endpoints maakt het mogelijk om granulair toegangscontrole toe te passen op PaaS-services, wat bijzonder waardevol is voor omgevingen waar verschillende workloads toegang nodig hebben tot verschillende Azure-services.

Geavanceerde segmentatietechnieken

Azure Private Link biedt geavanceerde segmentatiemogelijkheden voor PaaS-services door deze services te isoleren binnen het Virtual Network in plaats van ze bloot te stellen aan het publieke internet. Wanneer Private Link wordt gebruikt, krijgen PaaS-services zoals Azure Storage, Azure SQL Database of Azure Key Vault een privé IP-adres binnen het Virtual Network, waardoor ze kunnen worden benaderd alsof ze on-premises services zijn. Dit elimineert de noodzaak voor publieke endpoints en vermindert het aanvalsoppervlak aanzienlijk. Network Security Groups kunnen vervolgens worden gebruikt om verkeer naar Private Link-services te controleren op basis van subnetten, Application Security Groups of individuele netwerkinterfaces, waardoor granulair toegangscontrole mogelijk is. Private Link is bijzonder waardevol voor omgevingen waar strikte netwerkisolatie vereist is, zoals systemen die werken met gevoelige persoonsgegevens of vertrouwelijke informatie. Daarnaast biedt Private Link compliance-voordelen: omdat verkeer niet via internet gaat, kunnen organisaties beter aantonen dat data niet wordt blootgesteld aan externe partijen, wat relevant is voor frameworks zoals de AVG en BIO.

Virtual Network peering met gecontroleerde verkeersstroom biedt mogelijkheden voor segmentatie tussen verschillende Virtual Networks terwijl gecontroleerde connectiviteit wordt behouden. Wanneer Virtual Networks worden gepaard, kunnen organisaties expliciet configureren welke verkeersstromen worden toegestaan tussen de gepaarde netwerken door gebruik te maken van Network Security Groups en route tabellen. Dit maakt het mogelijk om verschillende Virtual Networks te gebruiken voor verschillende omgevingen, afdelingen of workload-categorieën, terwijl gecontroleerde communicatie tussen deze netwerken mogelijk blijft. Bijvoorbeeld: een productie Virtual Network kan worden gepaard met een management Virtual Network, waarbij alleen specifiek management-verkeer wordt toegestaan, terwijl alle andere verkeer wordt geblokkeerd. Virtual Network peering biedt ook de mogelijkheid om gateway transit te configureren, waarbij één Virtual Network fungeert als hub voor VPN- of ExpressRoute-connectiviteit, terwijl andere Virtual Networks via deze hub verbinding maken met on-premises netwerken. Deze hub-spoke configuratie met peering maakt gecentraliseerd beheer en beveiliging mogelijk terwijl verschillende workloads geïsoleerd blijven in hun eigen Virtual Networks.

Azure Firewall integreert naadloos met netwerksegmentatie door gecentraliseerde netwerkfiltering te bieden op het niveau van Virtual Networks of subnetten. Wanneer Azure Firewall wordt geïmplementeerd in een hub Virtual Network, kunnen route tabellen worden geconfigureerd die alle verkeer van spoke Virtual Networks of subnetten via de firewall routeren, waardoor consistente beveiligingscontroles worden toegepast ongeacht waar workloads draaien. Azure Firewall biedt geavanceerde functies zoals FQDN-filtering, threat intelligence-integratie en TLS-inspectie die verder gaan dan wat Network Security Groups kunnen bieden, waardoor organisaties dieper inzicht krijgen in netwerkverkeer en geavanceerde bedreigingen kunnen detecteren en blokkeren. De combinatie van Azure Firewall voor gecentraliseerde filtering en Network Security Groups voor granulair toegangscontrole op subnet- en netwerkinterfaceniveau biedt een gelaagde beveiligingsaanpak die zowel breedte als diepte biedt. Voor hybride scenario's waarbij Azure-netwerken worden verbonden met on-premises netwerken via VPN of ExpressRoute, kan Azure Firewall worden gebruikt om verkeer tussen cloud en on-premises te filteren, waardoor consistente beveiligingscontroles worden toegepast over de hele hybride omgeving.

Network Watcher en flow logs bieden essentiële monitoring- en diagnostiekcapaciteiten voor netwerksegmentatie. Network Watcher biedt tools zoals IP flow verify die kunnen worden gebruikt om te controleren of Network Security Group-regels correct werken en of verkeer wordt toegestaan of geweigerd zoals bedoeld. Flow logs maken het mogelijk om gedetailleerde informatie te verzamelen over alle netwerkverkeer dat door Network Security Groups wordt geëvalueerd, inclusief bron- en doel-IP-adressen, poorten, protocollen en of verkeer is toegestaan of geweigerd. Deze logs kunnen worden geanalyseerd met Azure Monitor en Log Analytics om inzicht te krijgen in verkeerspatronen, afwijkingen te detecteren en compliance te verifiëren. Voor netwerksegmentatie zijn flow logs bijzonder waardevol omdat ze aantonen welke verkeersstromen daadwerkelijk plaatsvinden tussen segmenten, of verkeer correct wordt gecontroleerd zoals bedoeld, en waar potentiële beveiligingsproblemen zich bevinden. Organisaties moeten ervoor zorgen dat flow logs zijn ingeschakeld voor alle Network Security Groups die worden gebruikt voor segmentatie, en dat logs worden bewaard voor de vereiste retentietermijnen volgens compliance-vereisten (typisch 7 jaar voor Nederlandse overheidsorganisaties volgens BIO).

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

Beheer, governance en compliance

Effectief beheer van netwerksegmentatie vereist duidelijke governance-structuren, gedefinieerde processen en continue monitoring. Organisaties moeten vastleggen wie verantwoordelijk is voor het ontwerpen en beheren van netwerksegmentatie, wie netwerkwijzigingen mag aanvragen en goedkeuren, en hoe wijzigingen worden gecontroleerd en gedocumenteerd. Role-Based Access Control (RBAC) in Azure moet worden gebruikt om toegang te beperken tot alleen die personen en rollen die daadwerkelijk netwerkbeheer nodig hebben. Het is aanbevolen om verschillende rollen te definiëren: netwerkarchitecten die verantwoordelijk zijn voor het ontwerpen van segmentatiestrategieën, netwerkbeheerders die verantwoordelijk zijn voor het implementeren en beheren van netwerkconfiguraties, en netwerkoperators die verantwoordelijk zijn voor dagelijks monitoring en troubleshooting. 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 netwerksegmentatie, Network Security Groups en route tabellen 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, zoals het blokkeren van legitiem verkeer of het creëren van beveiligingslekken. 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 Network Security Group-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 netwerksegmentatie up-to-date blijft en aansluit bij veranderende bedrijfsbehoeften en beveiligingsvereisten. Organisaties moeten minimaal kwartaalgewijs een review uitvoeren van alle Network Security Groups, route tabellen en netwerkconfiguraties om te verifiëren dat segmentatie nog steeds correct is geïmplementeerd, dat regels nog steeds nodig zijn en correct zijn geconfigureerd, en dat nieuwe bedrijfsvereisten worden geëvalueerd voor nieuwe segmenten of wijzigingen. 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 flow logs worden geanalyseerd om te identificeren of verkeerspatronen overeenkomen met verwachtingen, of er ongebruikelijke verkeersstromen zijn die kunnen wijzen op beveiligingsproblemen, en of segmentatie effectief werkt zoals bedoeld. 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 netwerksegmentatie correct is geïmplementeerd en effectief werkt. Tijdens audits moeten organisaties kunnen laten zien: dat netwerken logisch zijn gesegmenteerd op basis van beveiligingsvereisten, dat Network Security Groups correct zijn geconfigureerd met expliciete regels, dat verkeer tussen segmenten wordt gecontroleerd en gemonitord, dat flow logs worden verzameld en bewaard volgens vereisten, en dat er processen zijn voor het beheren van wijzigingen en het uitvoeren van reviews. Het bijbehorende PowerShell-script kan worden gebruikt om compliance-rapportages te genereren die aantonen welke Virtual Networks en subnetten bestaan, hoe ze zijn geconfigureerd, of Network Security Groups correct zijn toegepast, en of segmentatie voldoet 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

Netwerksegmentatie raakt direct aan meerdere compliancekaders waar Nederlandse overheidsorganisaties aan gebonden zijn. Vanuit de Baseline Informatiebeveiliging Overheid (BIO) geldt dat systemen met verschillende beveiligingsclassificaties adequaat moeten worden geïsoleerd en dat netwerkverkeer moet worden gecontroleerd en gemonitord. Control 13.01 vereist expliciet dat organisaties netwerksegmentatie implementeren, en netwerksegmentatie vormt een belangrijk onderdeel van het bewijs dat deze vereiste wordt nageleefd. Tijdens BIO-audits wordt niet alleen gekeken naar het bestaan van subnetten en Network Security Groups, maar vooral naar de kwaliteit van de segmentatie, de wijze van beheer, de monitoringresultaten en de aansluiting op incidentresponsprocessen. Organisaties moeten kunnen aantonen dat segmentatie logisch is ontworpen op basis van beveiligingsvereisten, dat verkeer tussen segmenten wordt gecontroleerd, 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 en om systemen te isoleren waar nodig. Netwerksegmentatie voldoet aan deze vereiste door logische en fysieke isolatie te bieden tussen verschillende systemen en workload-categorieën. 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 specifieke segmentatiestrategieën voortkomt uit een risicoafweging, dat Network Security Group-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. Netwerksegmentatie voldoet aan deze vereiste door de impact van beveiligingsincidenten te beperken en door gecontroleerde verkeersstroom mogelijk te maken die monitoring en detectie ondersteunt. Organisaties moeten kunnen aantonen dat incidentresponsprocedures correct zijn gedocumenteerd, dat beveiligingsincidenten tijdig worden gedetecteerd via flow logs en monitoring, 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 netwerksegmentatie wordt vertaald naar begrijpelijke stuurinformatie. Bestuurders hoeven niet te weten welke individuele Network Security Group-regels actief zijn, maar wel of netwerken correct zijn gesegmenteerd, of systemen met verschillende beveiligingsclassificaties adequaat zijn geïsoleerd, of er recente beveiligingsincidenten zijn geweest die door segmentatie zijn tegengehouden, en welke rest-risico's nog geaccepteerd worden. Deze informatie kan worden samengevat in periodieke rapportages en dashboards die onderdeel zijn van de bredere rapportagelijn over cyberweerbaarheid. Voor Nederlandse overheidsorganisaties draagt dit bij aan transparante verantwoording richting gemeenteraad, Provinciale Staten, Tweede Kamer of toezichthouders en ondersteunt het bij het onderbouwen van investeringen in verdere versterking van digitale weerbaarheid.

Compliance & Frameworks

• CIS M365: Control 6.11 (L1/L2) - Implementeer netwerksegmentatie via subnetten en Network Security Groups in lijn met de CIS Azure Foundations Benchmark.
• BIO: 13.01, 14.02 - Netwerksegmentatie en isolatie van systemen op basis van beveiligingsclassificatie binnen de Baseline Informatiebeveiliging Overheid.
• ISO 27001:2022: A.8.20, A.8.33 - Netwerkbeveiliging en isolatie van systemen in het kader van een Information Security Management System.
• NIS2: Artikel - Technische en organisatorische maatregelen voor risicobeheersing, inclusief netwerkbeveiliging en beperking van impact van beveiligingsincidenten.

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Netwerksegmentatie vormt een verplichte beveiligingsstrategie voor Azure-omgevingen binnen de Nederlandse Baseline voor Veilige Cloud. Door een doordachte architectuur, subnetgebaseerde isolatie met Network Security Groups, microsegmentatie met Application Security Groups en geavanceerde technieken zoals Azure Private Link te implementeren, wordt de impact van beveiligingsincidenten beperkt en wordt ongeautoriseerde toegang voorkomen. Het bijbehorende PowerShell-script inventariseert automatisch alle Virtual Networks en subnetten, analyseert de segmentatiestructuur, controleert of Network Security Groups correct zijn toegepast, en identificeert ontbrekende segmentatie of onveilige configuraties, zodat hiaten snel zichtbaar worden. De benodigde inspanning is aanzienlijk (circa 72 uur initiële implementatie), maar de risicoreductie en compliance-voordelen zijn essentieel voor alle Azure-netwerkdiensten.

• Implementatietijd: 72 uur
• FTE required: 0.5 FTE