Netwerksegmentatie is al decennia het fundament onder digitale weerbaarheid, maar veel Nederlandse overheidsnetwerken zijn nog steeds vlak. Wanneer een aanvaller een enkele werkplek of serviceaccount overneemt, kan hij zich vaak vrij bewegen richting zaaksystemen, identiteitsdiensten en gegevensmagazijnen. Die kwetsbaarheid is zowel technisch als bestuurlijk problematisch, omdat bestuurders onvoldoende overtuigend kunnen aantonen dat de Baseline Informatiebeveiliging Overheid (BIO) en de zorgplichten uit NIS2 artikel 21 daadwerkelijk worden ingevuld. Zero Trust-architectuur maakt daarom een einde aan implicit trust: elk netwerkpad wordt expliciet geverifieerd voordat verkeer wordt toegelaten en elk segment krijgt een eigen beschermingsmechanisme.
Cloudplatforms zoals Azure bieden een rijk palet aan segmentatieopties. Network Security Groups (NSG's) en Application Security Groups zorgen voor fijnmazige filtering op subnet- en werklaagniveau, Azure Firewall centraliseert dreigingsinformatie en biedt stateful inspectie, terwijl Private Link en Virtual Network Manager segmentatiebeleid uniform uitrollen. Het vraagstuk is daarmee geen gebrek aan technologie, maar het ontwerpen van een coherente architectuur die aansluit op Nederlandse wet- en regelgeving, hybride realiteit en bestaande exploitatieprocessen. Organisaties die alleen techniek implementeren zonder governance, belanden alsnog in een moeras van uitzonderingen en shadow IT.
Deze blog beschrijft hoe een hub-spoke-topologie de basis vormt, hoe micro-segmentatie met NSG's, ASG's en Azure Firewall concreet wordt ingericht, en hoe je operationele borging realiseert met monitoring, evidence en continue verbetering. Elke sectie is geschreven voor architecten, netwerkbeheerders en CISO's die verantwoordelijkheid dragen voor de Nederlandse Baseline voor Veilige Cloud en die een verhaal voor bestuur en toezichthouder moeten kunnen vertellen.
Deze gids biedt een leidraad voor Nederlandse netwerkarchitecten die hub-spoke-topologie, Azure Firewall, NSG's, Private Link en monitoring willen combineren tot één coherent Zero Trust-programma. Je leest hoe je beleidszones koppelt aan BIO-classificaties, hoe je transitoir verkeer verplicht langs inspectiepunten leidt en hoe je governanceprocessen voorkomt dat uitzonderingen de segmentatie uithollen.
Verzamel eerst meetdata voordat je verkeer blokkeert. Zet NSG flow logs, Azure Firewall Policy Analytics en Defender for Cloud aanbevelingen vier weken lang aan in audit-stand, modelleer de echte afhankelijkheden en vertaal ze daarna naar allowlists. Zo voorkom je paniekuitzonderingen en houd je regelsets compact.
Strategisch hub-spoke ontwerp en governance
Een hub-spoke-topologie vormt het fundament van elke Zero Trust-netwerkarchitectuur voor de Nederlandse publieke sector, omdat gedeelde diensten veilig gecentraliseerd blijven terwijl workloads per applicatie of per vertrouwensniveau worden afgescheiden. Het hubnetwerk bevat identity providers, bastiondiensten, DNS, SIEM-collector, Azure Firewall en de gateways voor VPN of ExpressRoute. Door alle uitgaand internetverkeer en inter-spoke communicatie via de hub te dwingen ontstaat een consistent inspectiepunt waar verkeer kan worden gevalideerd op beleidsregels, dreigingsinformatie en compliance-eisen. Dat betekent niet dat de hub een bottleneck is; moderne Azure Firewall Premium-instanties schalen automatisch en kunnen policies per regio of per tenant delen via Azure Firewall Manager, zodat Rijksbreed of per uitvoeringsorganisatie dezelfde regelset wordt toegepast.
Een effectief ontwerp begint met het uitlijnen van netwerkzones op de BIO-beschermingsniveaus en de gegevensclassificatie die de CIO al heeft vastgesteld. In de praktijk komt dit neer op gescheiden spoke-VNets voor ontwikkelomgevingen, testomgevingen, productie met interne gebruikers en productie met burgerinteractie. Elke zone krijgt een eigen Virtual Network, eigen route-tabellen en eigen Network Security Groups, zodat verkeer nooit toevallig tussen zones kan lekken. De koppeling met on-premises gebeurt via BGP en ExpressRoute of via IPsec, maar slechts voor de spokes die dat nodig hebben. Daarmee wordt shadow peering voorkomen en kun je aantonen dat kritieke OT-systemen niet indirect aan internet gekoppeld zijn.
Het hub-spoke-pattern maakt groei beheersbaar, omdat een nieuw project slechts een extra spoke behoeft. Een gemeente die een nieuw zaaksysteem introduceert, maakt een dedicated spoke met de vereiste subnets voor web, applicatie en data, koppelt deze aan de hub en voegt enkel de noodzakelijke routes toe. Het securityteam hoeft het hubnetwerk niet opnieuw te ontwerpen en kan via Azure Policy automatisch afdwingen dat de nieuwe spoke de juiste NSG's, route-tabellen en diagnostische instellingen erft. Dat is essentieel voor organisaties die tientallen leveranciers beheren en regelmatig tijdelijke projectomgevingen inrichten.
Governance is de doorslaggevende factor. Definieer vooraf welke teams een peering mogen aanvragen, welke tagging verplicht is voor elke subnet en welke changeprocedures gelden wanneer een spoke extra connectiviteit wil. Azure Virtual Network Manager kan hier als policy-plane dienen door segmentatiegroepen en connectiviteitsconfiguraties te declareren. Wanneer je segmentatie koppelt aan een CMDB en een autorisatieproces, ontstaat inzicht in welke applicaties elkaar mogen benaderen en kun je afwijkingen direct blokkeren. Zonder die governance verzandt de architectuur alsnog in willekeurige peeringrelaties, waardoor laterale beweging terugkeert.
Een praktijkvoorbeeld: een agentschap dat archief- en burgerdossiers beheert, plaatste eerst alle workloads in drie grote spoke-VNets. Tijdens een tabletop-oefening bleek dat een compromis van de archiefspoke alsnog toegang gaf tot de dossierspokes via een gedeeld beheersegment. Door beheerfuncties te verplaatsen naar de hub, remote management via Bastion en Just-in-Time access te forceren, werd de blast radius teruggebracht. Tegelijk is gekozen voor dedicated spokes per ketenpartner, zodat leveranciers alleen in hun eigen omgeving beheer uitvoeren.
Tot slot vraagt een toekomstbestendige hub-spoke-architectuur om duidelijke KPI's. Denk aan gemiddelde time-to-approve voor nieuwe peerings, aantal afwijkingen op mandatory tagging, percentage spokes met ingestelde diagnostische settings en het aantal routes dat zonder Firewall-inspectie verloopt. Door die indicatoren maandelijks te rapporteren aan de CISO en het portfoliobestuur, blijft segmentatie geen eenmalig project maar een bestuurlijk bewaakt programma.
Micro-segmentatie met NSG's, ASG's en Azure Firewall
Waar de hub-spoke-architectuur de macro-segmentatie definieert, zorgen NSG's, ASG's en Azure Firewall voor de fijnmazige controle die Zero Trust vereist. Begin altijd met een default-deny-postuur: elke subnet en elke NIC krijgt een NSG die alle inkomend en uitgaand verkeer blokkeert, behalve de verbindingen die aantoonbaar nodig zijn. Dat dwingt teams om expliciet te beschrijven welke poort, welk protocol en welke richting geautoriseerd is. Door flows eerst te profileren via NSG flow logs, Azure Monitor en Defender for Cloud, weet je precies welke verkeer noodzakelijk is en voorkom je dat functioneel beheer in paniek brede uitzonderingen aanvraagt.
Application Security Groups zijn daarbij onmisbaar. In plaats van IP-adressen in regels vast te leggen, groepeer je workloads logisch, bijvoorbeeld "Zaaksysteem-Web" en "Zaaksysteem-SQL". Wanneer een schaalset groeit of een container wordt verplaatst, hoeven regels niet te worden aangepast, omdat de nieuwe instantie automatisch lid wordt van de juiste ASG. Dit reduceert beheerlast en minimaliseert fouten. Een goede praktijk is om ASG's te koppelen aan hetzelfde label- en tagstelsel dat ook in het CMDB wordt gebruikt. Zo kan het controleteam eenvoudig herleiden welke applicatie schuilgaat achter een regel en of een wijziging ook in de documentatie is verwerkt.
Azure Firewall vormt het centrale inspectiepunt voor verkeer dat spokes of on-premises domeinen kruist. Stateful filtering, IDPS-signatures, TLS-inspectie en Threat Intelligence mode bieden een tweede verdedigingslinie naast de NSG's. Segmentatie wordt sterker wanneer je per zone een eigen rule collection group aanmaakt: beleid voor burgerportalen wordt gescheiden van beleid voor interne bedrijfsvoering en van beleid voor beheerfuncties. Firewall Policy Analytics en Policy Insights geven inzicht in onbenutte regels, overlappingen en asymmetrische flows zodat je regelsets continu kunt verfijnen. Vergeet niet dat DNS-filtering en FQDN-tags steeds belangrijker worden naarmate applicaties naar SaaS bewegen; via Azure Firewall kun je toegestane SaaS-domeinen whitelisten en onbekende diensten blokkeren.
Observability sluit naadloos op segmentatiebeleid aan. NSG flow logs worden naar een centraal Log Analytics workspace gestuurd en gekoppeld aan Microsoft Sentinel of Splunk. Daaruit genereer je queries die afwijkende laterale beweging detecteren, zoals een beheersegment dat ineens met workloads in een burgerzone praat. Door de flow logs te verrijken met tagginginformatie uit Azure Resource Graph, kun je dashboards opbouwen die bestuurders in één oogopslag tonen hoeveel verbindingen per BIO-klasse worden toegestaan. Dat maakt het gesprek met auditors en toezichthouders concreet: je kunt aantonen welke verkeersstromen bewust zijn vrijgegeven en hoe vaak uitzonderingen voorkomen.
Automatisering is cruciaal om menselijke fouten te vermijden. Gebruik Bicep of Terraform modules voor NSG's, ASG's, route-tabellen en Firewall policies, inclusief unit tests die controleren of default-deny werkelijk is geconfigureerd. Combineer dat met Azure Policy en Defender for Cloud om afwijkingen automatisch te remediëren: wanneer iemand een NIC zonder NSG uitrolt, wordt dit direct hersteld of geblokkeerd. Voor tijdelijke uitzonderingen, bijvoorbeeld om een migratievenster mogelijk te maken, gebruik je Just-in-Time access en expire-dates zodat de regel vanzelf verdwijnt.
Tot slot moet security operations nauw betrokken blijven. Elke nieuwe regel gaat vergezeld van een use case in Sentinel, zodat verdachte patronen direct alarm slaan. Wanneer een NSG-regel verkeer toestaat tussen twee gevoelige ASG's, hoort daar een detectionscenario bij dat afgaat bij volumetoename of ongebruikelijke tijden. Op deze manier wordt segmentatie geen papieren ontwerp, maar een dynamisch, meetbaar stelsel dat continu getoetst wordt aan dreigingsinformatie.
Operationele borging, monitoring en continue verbetering
Micro-segmentatie invoeren is een meerjarig veranderprogramma dat techniek, processen en mensen raakt. Begin met een routekaart die per kwartaal beschrijft welke netwerkscopes worden aangepakt, welke applicaties worden gemigreerd en welke business-eigenaren tekenen voor acceptatie. Combineer dat met een communicatieplan richting bestuur, leveranciers en auditors, zodat iedereen begrijpt dat segmentatie niet optioneel is maar een direct vereiste vanuit BIO, NIS2 en vaak ook sectorale richtlijnen zoals de Wet Digitale Overheid. Door successen zichtbaar te maken, bijvoorbeeld een vermindering van laterale bewegingsmogelijkheden in een test, vergroot je draagvlak.
Tijdens de migratie naar micro-segmentatie staat beschikbaarheid altijd onder spanning. Voer daarom dependency-analyses uit met behulp van Azure Monitor, Application Insights en eventueel traditionele netwerkscans. Gebruik change slots waarin je eerst in audit-modus draait, het verkeer monitort en pas daarna in enforce-modus schakelt. Wanneer incidenten zich voordoen, hanteer je een runbook waarin omschreven staat hoe tijdelijk verkeer wordt toegestaan, welke logging verplicht is en hoe je terugkeert naar het gewenste beleid. Daarmee voorkom je dat crisissituaties leiden tot permanente achterdeurtjes.
Continue monitoring vormt het bewijs dat segmentatie ook na oplevering werkt. Combineer Network Watcher, Traffic Analytics en Sentinel dashboards om dagelijks inzicht te geven in het aantal geblokkeerde laterale bewegingen, het aantal uitzonderingsaanvragen, de gemiddelde doorlooptijd voor een nieuwe verbinding en de mate waarin logging actief is. Deel die gegevens met het security operations center, maar ook met CIO-office en audit, zodat compliance en operatie dezelfde feitenbasis delen. Het maakt auditgesprekken aanzienlijk eenvoudiger wanneer je exact kunt laten zien welke netwerkpaden zijn gecontroleerd op de dag dat een steekproef is genomen.
Compliance-evidence moet structureel geborgd worden. Leg per segment vast welke controles het afdekt binnen BIO 12.2, 13.1 en 14.1, koppel die aan het Register van Verwerkingen en aan de DPIA's die persoonsgegevens bevatten. Documenteer in een configuration baseline welke templates zijn gebruikt, hoe vaak policies zijn gevalideerd en waar de logging wordt opgeslagen. Gebruik Microsoft Purview of een GRC-tool om deze evidence automatisch te verzamelen, zodat auditors niet afhankelijk zijn van losse spreadsheets. Transparantie richting de Autoriteit Persoonsgegevens of Agentschap Telecom wordt daarmee een stuk eenvoudiger.
Segmentatie vereist daarnaast nauwe samenwerking tussen netwerkbeheerders, cloudteams, identityspecialisten en applicatie-eigenaren. Stel een segmentatieboard in dat wekelijks wijzigingsaanvragen beoordeelt, lessons learned bespreekt en beslissingen documenteert. Zorg ervoor dat leveranciers dezelfde standaarden hanteren door eisen op te nemen in contracten en door inpen tests te laten controleren of leveranciersspokes alleen de afgesproken verbindingen hebben. Zo ontstaat een ketenbrede aanpak waarin ook shared services en regionale samenwerkingen meegenomen worden.
Investeren in vaardigheden en capaciteit is minstens zo belangrijk als technologie. Richt een opleidingsprogramma in waarin netwerkengineers leren werken met Infrastructure as Code, waarin security operations Sentinel-queries rond laterale beweging oefenen en waarin leveranciers toegang krijgen tot een sandbox om segmentatieregels te testen. Reserveer budget voor tooling en voor tijdelijke dubbele beheerlast tijdens migraties, want zonder realistische capaciteit zullen teams shortcuts nemen die de architectuur ondermijnen.
Tot slot hoort continue verbetering bij de Nederlandse Baseline voor Veilige Cloud. Evalueer ieder kwartaal of nieuwe Azure-functies, zoals Virtual Network Manager security admin rules of Azure Firewall single-click upgrades, extra bescherming kunnen bieden. Blijf oefenen via red-teaming en purple-teaming om te toetsen of laterale beweging daadwerkelijk wordt gedetecteerd en gestopt. Door segmentatie als doorlopend programma te behandelen, blijft de architectuur afgestemd op nieuwe dreigingen, beleidswijzigingen en de groeiende afhankelijkheid van SaaS en hybride werkplekken.
Segmentatie is geen ouderwetse netwerkmaatregel maar een directe voorwaarde voor Zero Trust binnen de Nederlandse Baseline voor Veilige Cloud. Door een robuuste hub-spoke-topologie te combineren met default-deny NSG's, logisch beheerde ASG's, centrale Azure Firewall policies en streng changebeheer, beperk je de blast radius van elke inbraak tot een hanteerbaar minimum. De beschreven aanpak biedt bestuurders aantoonbaar bewijs richting BIO-, NIS2- en Archiefwet-toezichthouders, terwijl operationele teams profiteren van herhaalbare templates, geautomatiseerde controles en realtime monitoring. Organisaties die segmentatie als continu programma behandelen, zijn beter voorbereid op nieuwe dreigingen, kunnen sneller reageren tijdens incidenten en bouwen vertrouwen op bij burgers en ketenpartners doordat zij kunnen laten zien dat laterale beweging aantoonbaar wordt gestopt.