BIO 13.01 ISO A.8.20

Hub-Spoke Architectuur Implementatie Voor Azure Netwerken

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

💼 Management Samenvatting

Hub-spoke architectuur is een netwerkontwerppatroon dat gecentraliseerde beveiliging en beheer combineert met gedistribueerde workloads in Azure-omgevingen. Deze architectuur implementeert een centraal hub-netwerk dat fungeert als knooppunt voor gedeelde beveiligingsservices, terwijl individuele spoke-netwerken workloads isoleren en segmenteren volgens Zero Trust-principes. Voor Nederlandse overheidsorganisaties biedt deze architectuur een solide basis voor het voldoen aan NIS2-verplichtingen, BIO-normen en ISO 27001-vereisten voor netwerksegmentatie en beveiliging.

Aanbeveling
IMPLEMENT
Risico zonder
High
Risk Score
8/10
Implementatie
90u (tech: 60u)
Van toepassing op:
✓ Azure abonnementen
✓ Enterprise netwerkomgevingen
✓ Hybride cloudomgevingen

Traditionele platte netwerkarchitecturen waarbij alle workloads in één virtueel netwerk worden geplaatst, creëren aanzienlijke beveiligingsrisico's. Zonder netwerksegmentatie kunnen aanvallers die toegang krijgen tot één workload gemakkelijk laterale beweging uitvoeren naar andere systemen binnen hetzelfde netwerk. Dit principe van 'eenmaal binnen, overal toegang' vormt een fundamentele kwetsbaarheid die in strijd is met moderne beveiligingsprincipes zoals Zero Trust en defense in depth. Hub-spoke architectuur lost dit op door workloads te isoleren in afzonderlijke spoke-netwerken, terwijl gecentraliseerde beveiligingsservices in het hub-netwerk alle verkeer inspecteren, filteren en controleren voordat het tussen netwerken of naar het internet wordt doorgestuurd. Deze architectuur maakt het mogelijk om consistente beveiligingsbeleidsregels toe te passen op alle netwerkverkeer, ongeacht in welk spoke-netwerk de workload zich bevindt, wat essentieel is voor het waarborgen van compliance met frameworks zoals NIS2, BIO en ISO 27001. Daarnaast vereenvoudigt hub-spoke architectuur het beheer en de governance van netwerkresources door centrale services te concentreren, wat de operationele efficiëntie verhoogt en de kosten voor beveiligingsinfrastructuur verlaagt door schaalvoordelen.

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

Implementatie

Dit artikel beschrijft een complete implementatie van hub-spoke netwerkarchitectuur in Azure, specifiek toegespitst op de context van Nederlandse overheidsorganisaties. De architectuur bestaat uit drie primaire componenten: het centrale hub-netwerk, meerdere spoke-netwerken en VNet-peering verbindingen die deze netwerken naadloos met elkaar verbinden. Het hub-netwerk bevat gedeelde beveiligingsservices zoals Azure Firewall voor gecentraliseerde netwerkbeveiliging en threat intelligence, Azure VPN Gateway of ExpressRoute Gateway voor hybride connectiviteit, Azure Bastion voor veilige beheerstoegang zonder publieke IP-adressen, en Network Watcher voor uitgebreide netwerkmonitoring en diagnostiek. Spoke-netwerken bevatten geïsoleerde workloads die zijn georganiseerd op basis van verschillende criteria zoals omgeving (productie, ontwikkeling, test), afdeling, project of gevoeligheidsniveau van data. VNet-peering maakt directe, privéconnectiviteit mogelijk tussen het hub-netwerk en alle spoke-netwerken zonder dat verkeer via het publieke internet hoeft te gaan, wat de beveiliging verhoogt en de latentie verlaagt. Het artikel beschrijft gedetailleerde implementatiestappen voor het ontwerpen van de netwerkarchitectuur, het configureren van VNet-peering met de juiste routingregels, het implementeren van Azure Firewall policies voor verkeersfiltering, het configureren van Network Security Groups voor subnet-niveau beveiliging, en het opzetten van monitoring en logging voor compliance-doeleinden. Daarnaast wordt uitgelegd hoe deze architectuur aansluit bij Zero Trust-principes door verkeer te verifiëren en te autoriseren op basis van identiteit, applicatie en context, en hoe organisaties kunnen voldoen aan NIS2-verplichtingen voor netwerkbeveiliging en BIO-normen voor netwerksegmentatie.

Vereisten

Een succesvolle implementatie van hub-spoke netwerkarchitectuur in Azure vereist een grondige voorbereiding op zowel technisch als organisatorisch vlak. De eerste vereiste is een volledige inventarisatie van alle workloads, applicaties en services die onderdeel uitmaken van de Azure-omgeving. Deze inventarisatie moet niet alleen technische details bevatten – zoals virtuele machines, containers, databases, storage accounts en applicatieservices – maar ook functionele context: welke workloads zijn kritiek voor de dienstverlening, welke data wordt verwerkt en wat is de classificatie daarvan, welke externe partijen hebben toegang en wat zijn de compliance-vereisten per workload. Deze informatie vormt de basis voor het bepalen van welke workloads in welke spoke-netwerken worden geplaatst en welke beveiligingsniveaus nodig zijn voor elk netwerksegment. Een tweede cruciale vereiste is het hebben van een duidelijk netwerkarchitectuurbeleid dat specifiek is uitgewerkt voor hub-spoke implementaties. Dit beleid moet definiëren welke services verplicht in het hub-netwerk moeten worden geplaatst, welke workloads in welke spoke-netwerken worden georganiseerd, welke routingregels en toegangscontroles worden toegepast, en hoe nieuwe workloads worden toegevoegd aan de architectuur. Binnen Nederlandse overheidsorganisaties moet dit beleid expliciet aansluiten bij het BIO-raamwerk, NIS2-verplichtingen en ISO 27001-vereisten voor netwerksegmentatie. Het beleid moet schriftelijk zijn vastgelegd, door het bestuur zijn goedgekeurd en regelmatig worden herzien op basis van veranderende dreigingen en nieuwe Azure-services. Zonder een dergelijk kader bestaat het risico dat hub-spoke architectuur ad hoc wordt geïmplementeerd zonder duidelijke samenhang of dat bepaalde beveiligingsservices worden overgeslagen omdat de noodzaak niet duidelijk is. Technisch gezien vereist hub-spoke architectuur de beschikbaarheid van de juiste Azure-licenties en services. Voor het hub-netwerk is Azure Firewall vereist voor gecentraliseerde netwerkbeveiliging, Azure VPN Gateway of ExpressRoute Gateway voor hybride connectiviteit, en Azure Bastion voor veilige beheerstoegang. Voor VNet-peering zijn er geen extra kosten verbonden aan de peering-verbindingen zelf, maar er zijn wel kosten voor dataoverdracht tussen netwerken. Voor organisaties met hoge dataoverdrachtvolumes kan dit aanzienlijke kosten met zich meebrengen, wat moet worden meegenomen in de kosten-batenanalyse. Daarnaast vereist hub-spoke architectuur voldoende IP-adresruimte voor alle netwerken, waarbij moet worden gelet op het voorkomen van IP-adresconflicten tussen hub en spokes, en tussen verschillende spokes onderling. Het is belangrijk om een gestructureerd IP-adresplan op te stellen voordat de implementatie begint. Daarnaast is er een duidelijke rol- en verantwoordelijkheidsverdeling nodig tussen verschillende teams en functies. De netwerkarchitect is verantwoordelijk voor het ontwerpen van de hub-spoke architectuur en het zorgen dat alle componenten onderling goed samenwerken. Security engineers zijn verantwoordelijk voor de technische implementatie en configuratie van beveiligingsservices zoals Azure Firewall en Network Security Groups. Network engineers zijn verantwoordelijk voor het configureren van VNet-peering, routingregels en netwerkconnectiviteit. Operations teams zijn verantwoordelijk voor het dagelijks beheer en monitoring van de netwerkarchitectuur. Zonder deze duidelijke verdeling ontstaat verwarring over wie verantwoordelijk is voor welke component, wat kan leiden tot gaten in de beveiliging of overlappende inspanningen. Tot slot vereist hub-spoke architectuur een volwassen proces voor continue monitoring, evaluatie en verbetering. Netwerkarchitecturen zijn niet statisch maar moeten regelmatig worden geëvalueerd op effectiviteit, bijgewerkt op basis van nieuwe dreigingen en Azure-services, en getest om te verifiëren dat zij nog steeds functioneren zoals bedoeld. Dit vereist vaste planningsmomenten in de governancekalender, waarin de netwerkarchitectuur wordt gereviewd, nieuwe bedreigingen worden geëvalueerd en verbetermaatregelen worden geïdentificeerd. Daarnaast moeten er processen zijn voor het reageren op security incidents waarbij wordt geanalyseerd welke netwerkcontroles hebben gefaald en hoe deze kunnen worden verbeterd. Alleen met een dergelijk continu verbeterproces blijft een hub-spoke implementatie effectief in de tijd.

Implementatie

Gebruik PowerShell-script hub-spoke-architecture.ps1 (functie Invoke-Implementation) – Valideert en implementeert hub-spoke netwerkarchitectuur met alle benodigde componenten.

De implementatie van hub-spoke netwerkarchitectuur in Azure begint met het opstellen van een gedetailleerd implementatieplan dat alle componenten omvat en prioriteert op basis van risico en kritiekheid van workloads. Het plan moet per component beschrijven welke Azure-services worden ingezet, welke configuraties worden toegepast, welke resources worden beschermd en in welke volgorde de implementatie plaatsvindt. In de praktijk wordt vaak begonnen met het ontwerpen en implementeren van het centrale hub-netwerk, omdat dit de basis vormt voor alle andere componenten. Vervolgens worden spoke-netwerken geïmplementeerd en gekoppeld aan het hub-netwerk via VNet-peering. De eerste stap in het implementatieproces is het ontwerpen van de netwerkarchitectuur op basis van de inventarisatie van workloads en de vereisten uit het netwerkarchitectuurbeleid. Het hub-netwerk moet worden ontworpen met voldoende IP-adresruimte voor alle gedeelde services, waarbij rekening wordt gehouden met toekomstige groei. Typische subnetten in het hub-netwerk omvatten een subnet voor Azure Firewall, een subnet voor VPN Gateway of ExpressRoute Gateway, een subnet voor Azure Bastion, en eventueel een subnet voor gedeelde services zoals domain controllers of monitoring tools. Elke subnet moet voldoende IP-adressen hebben voor de verwachte workload, met een marge voor groei. Het is belangrijk om IP-adresruimte te reserveren die niet conflicteert met on-premises netwerken of andere Azure-netwerken die mogelijk in de toekomst worden toegevoegd. Na het ontwerpen van het hub-netwerk worden de spoke-netwerken ontworpen op basis van de organisatie van workloads. Workloads kunnen worden georganiseerd op basis van verschillende criteria, zoals omgeving (productie, ontwikkeling, test), afdeling, project, of gevoeligheidsniveau van data. Elke spoke moet voldoende IP-adresruimte hebben voor alle workloads die erin worden geplaatst, met subnetten die zijn georganiseerd op basis van de specifieke behoeften van de workloads. Het is belangrijk om consistentie te behouden in de subnetstructuur tussen verschillende spokes, zodat beveiligingsbeleidsregels consistent kunnen worden toegepast. Daarnaast moeten spoke-netwerken worden ontworpen met het oog op toekomstige uitbreiding, zodat nieuwe workloads eenvoudig kunnen worden toegevoegd zonder grote herstructurering. De implementatie van het hub-netwerk begint met het creëren van het virtuele netwerk en de benodigde subnetten. Azure Firewall wordt geïmplementeerd in een dedicated subnet met de naam AzureFirewallSubnet, waarbij moet worden gelet op de minimale subnetgrootte die vereist is voor de firewall. De firewall wordt geconfigureerd met network rules voor verkeersfiltering op basis van bron- en doel-IP-adressen en poorten, en application rules voor FQDN-filtering en bedreigingsinformatie. Azure VPN Gateway of ExpressRoute Gateway wordt geïmplementeerd in een dedicated subnet met de naam GatewaySubnet, waarbij de gateway wordt geconfigureerd met de juiste SKU voor de verwachte bandbreedte en connectiviteit. Azure Bastion wordt geïmplementeerd in een dedicated subnet met de naam AzureBastionSubnet, waarbij de bastion wordt geconfigureerd voor veilige RDP- en SSH-toegang tot virtuele machines zonder publieke IP-adressen. Vervolgens worden de spoke-netwerken geïmplementeerd met hun respectieve subnetten en workloads. Elke spoke wordt geconfigureerd met Network Security Groups voor subnet-niveau beveiliging, waarbij regels worden toegepast die verkeer filteren op basis van bron- en doel-IP-adressen, poorten en protocollen. Application Security Groups kunnen worden gebruikt om virtuele machines te groeperen op basis van hun rol, waardoor beveiligingsregels eenvoudiger kunnen worden beheerd. Workloads worden geïmplementeerd in de juiste subnetten binnen hun respectieve spoke-netwerken, waarbij moet worden gelet op de beveiligingsvereisten en connectiviteitsbehoeften van elke workload. Het koppelen van spoke-netwerken aan het hub-netwerk gebeurt via VNet-peering, waarbij twee peering-verbindingen worden gemaakt: één van het hub-netwerk naar het spoke-netwerk en één van het spoke-netwerk naar het hub-netwerk. Peering wordt geconfigureerd met de juiste instellingen voor gateway transit, waarbij het hub-netwerk fungeert als transit gateway voor spoke-netwerken die toegang nodig hebben tot on-premises resources of andere Azure-netwerken. Route tables worden geconfigureerd om verkeer te routeren via Azure Firewall in het hub-netwerk, waarbij user-defined routes worden toegevoegd die alle internetverkeer en verkeer tussen netwerken via de firewall routeren. Dit zorgt ervoor dat alle verkeer wordt geïnspecteerd en gefilterd voordat het wordt doorgestuurd, wat essentieel is voor Zero Trust-netwerkbeveiliging. Na de implementatie van de basisarchitectuur worden aanvullende beveiligingsservices geconfigureerd. Azure Firewall policies worden geconfigureerd met application rules voor toegestane FQDN's en network rules voor toegestane IP-adressen en poorten. Threat intelligence wordt ingeschakeld om automatisch verkeer te blokkeren van bekende kwaadaardige IP-adressen en domeinen. Network Watcher wordt ingeschakeld voor uitgebreide netwerkmonitoring en diagnostiek, waarbij NSG flow logs worden geconfigureerd voor gedetailleerde logging van netwerkverkeer. Azure Monitor wordt geconfigureerd voor het verzamelen en analyseren van netwerkmetrieken en logs, waarbij waarschuwingen worden ingesteld voor verdacht verkeer of configuratiewijzigingen. Tot slot worden compliance- en governanceprocessen geïmplementeerd. Azure Policy wordt gebruikt om ervoor te zorgen dat nieuwe resources voldoen aan de hub-spoke architectuurvereisten, zoals het voorkomen van directe peering tussen spokes of het vereisen van bepaalde beveiligingsconfiguraties. Tagging wordt geïmplementeerd voor consistente resource-organisatie en kostenbeheer. Documentatie wordt bijgewerkt met netwerkdiagrammen, IP-adresplannen en beveiligingsconfiguraties. Regelmatige reviews worden ingepland om te verifiëren dat de architectuur nog steeds voldoet aan de vereisten en om verbetermaatregelen te identificeren.

Monitoring

Gebruik PowerShell-script hub-spoke-architecture.ps1 (functie Invoke-Monitoring) – Monitort de status van hub-spoke netwerkarchitectuur en alle componenten.

Effectieve monitoring van hub-spoke netwerkarchitectuur in Azure is essentieel om te waarborgen dat alle componenten correct blijven functioneren en dat bedreigingen tijdig worden gedetecteerd. Monitoring richt zich niet alleen op individuele componenten, maar vooral ook op de samenhang tussen componenten en de algehele netwerkbeveiliging. In de praktijk betekent dit dat de organisatie een beperkt aantal kernindicatoren definieert – Key Network Indicators (KNI's) – die periodiek worden gemeten en gerapporteerd aan CISO, CIO en bestuur. Voor elke component worden specifieke metrics gedefinieerd die aangeven of de component effectief functioneert. Voor het hub-netwerk worden metrics gemeten zoals de beschikbaarheid en gezondheid van Azure Firewall, het aantal geblokkeerde bedreigingen en verdacht verkeer, de doorvoer en latentie van de firewall, de status van VPN Gateway of ExpressRoute Gateway connectiviteit, en het aantal actieve Azure Bastion-sessies. Voor spoke-netwerken worden metrics gemeten zoals het aantal actieve VNet-peering verbindingen, de status van peering-verbindingen, het aantal workloads per spoke, en de netwerkverkeersvolumes tussen spokes en het hub-netwerk. Voor netwerkbeveiliging worden metrics gemeten zoals het aantal NSG rules dat actief is, het aantal geblokkeerde verkeerspogingen door NSG's, het aantal Network Watcher alerts, en het percentage verkeer dat wordt geïnspecteerd door Azure Firewall. Een belangrijk onderdeel van monitoring is het creëren van geïntegreerde dashboards die de status van alle hub-spoke componenten samenbrengen in één overzichtelijk beeld. In plaats van afzonderlijke dashboards per component, wordt informatie samengebracht in een centraal netwerkdashboard dat laat zien hoe de verschillende componenten samenwerken en waar potentiële zwaktes bestaan. Dit dashboard moet niet alleen technische details tonen, maar vooral ook risico-indicatoren die begrijpelijk zijn voor bestuurders en niet-technische stakeholders. Binnen Nederlandse overheidsorganisaties sluit dit aan bij de behoefte aan overzichtelijke rapportages die voldoen aan NIS2- en BIO-verplichtingen voor security reporting. De monitoringfunctie moet ook concrete drempelwaarden en escalatiepaden definiëren. Voor elke KNI wordt vastgelegd bij welke waarde het risiconiveau verandert – bijvoorbeeld van 'aanvaardbaar' naar 'zorgelijk' of 'onacceptabel' – en welke acties dan vereist zijn. Dit kan variëren van het verplicht opstellen van een verbeterplan binnen een maand, via het tijdelijk blokkeren van nieuwe resources die niet voldoen aan hub-spoke vereisten, tot het escaleren naar de CISO of het bestuurlijke crisisteam bij zeer ernstige afwijkingen. Deze drempelwaarden worden afgestemd op de bestaande risicobereidheid van de organisatie en op wettelijke vereisten vanuit NIS2 en BIO. Tot slot vereist monitoring een nauwe koppeling tussen de dagelijkse operationele securityprocessen – zoals SOC-monitoring, netwerkbeheer en incident response – en de meerjarige beveiligingssturing. Operationele teams leveren signalen over concrete incidenten, near misses en ontdekt misbruik van configuratiefouten. Deze signalen moeten systematisch worden geanalyseerd om te bepalen of zij duiden op structurele tekortkomingen in hub-spoke configuraties of de beveiliging daarvan. Wanneer bijvoorbeeld meerdere incidenten wijzen op onvoldoende netwerksegmentatie of zwakke firewallconfiguraties, moet dit leiden tot een herziening van de relevante componenten en verbetermaatregelen. Het PowerShell-script dat bij dit artikel hoort, kan dienen als technisch hulpmiddel om op vaste momenten kernstatistieken uit Azure op te halen – zoals VNet-peering status, firewall health, NSG compliance en netwerkverkeersvolumes – en die als bijlage toe te voegen aan periodieke security rapportages. Zo ontstaat een gesloten feedbacklus tussen monitoring, analyse en bijsturing.

Compliance en Auditing

Hub-spoke netwerkarchitectuur is niet alleen een best practice voor cloudbeveiliging, maar een expliciete eis vanuit verschillende nationale en internationale kaders die gelden voor Nederlandse overheidsorganisaties en andere vitale of belangrijke entiteiten. De NIS2-richtlijn verlangt dat organisaties passende technische en organisatorische maatregelen treffen voor risicobeheersing en beveiliging, waarbij wordt benadrukt dat beveiliging moet worden toegepast op basis van risicoanalyse en niet op basis van verondersteld vertrouwen. Dit betekent concreet dat organisaties niet kunnen volstaan met platte netwerkarchitecturen zonder segmentatie, maar moeten kunnen aantonen dat zij een hub-spoke aanpak hebben geïmplementeerd die netwerkverkeer isoleert, inspecteert en controleert op basis van contextuele signalen. Het hier beschreven hub-spoke raamwerk levert precies dat aantoonbare spoor: van netwerksegmentatie via gecentraliseerde beveiliging tot gedetailleerde logging en monitoring. Het BIO-raamwerk benadrukt in meerdere thema's – met name thema 13 (Netwerkbeveiliging) en thema 12 (Beveiligingsmaatregelen) – dat overheidsorganisaties structureel moeten bepalen welke beveiligingsmaatregelen nodig zijn en hoe deze worden geïmplementeerd en gemonitord op basis van risicoanalyse. In moderne omgevingen bevinden veel van deze maatregelen zich in Azure, en zonder een specifiek uitgewerkt hub-spoke kader is het vrijwel onmogelijk om aan te tonen dat de BIO-eisen voor netwerksegmentatie en beveiliging daadwerkelijk zijn ingevuld voor deze platformlaag. Door hub-spoke te integreren in hetzelfde beveiligingskader en dezelfde governancecyclus als on-premises systemen en andere IT-diensten, kan de organisatie aan auditors laten zien dat cloud niet als losstaand eiland wordt behandeld, maar als integraal onderdeel van de beveiligingsarchitectuur. Ook ISO 27001 speelt een rol in hub-spoke netwerkarchitectuur, met name waar het gaat om netwerkbeveiliging en toegangscontrole. Controle A.8.20 vereist dat organisaties netwerken beveiligen en beheren om de beschikbaarheid, integriteit en vertrouwelijkheid van informatie te waarborgen, waarbij netwerksegmentatie een belangrijk middel is om de impact van beveiligingsincidenten te beperken. In de context van Azure betekent dit onder meer dat men moet beoordelen welke risico's er zijn voor verlies, ongeautoriseerde toegang of onbeschikbaarheid van informatie door cloud-specifieke dreigingen, en welke hub-spoke maatregelen hiervoor zijn gekozen (zoals netwerksegmentatie, gecentraliseerde firewall, private connectivity en monitoring). Deze keuzes en de onderbouwing ervan moeten worden gedocumenteerd, zodat bij een incident of audit kan worden aangetoond dat de organisatie weloverwogen en proportionele maatregelen heeft getroffen op basis van risicoanalyse. Auditors – zowel interne auditdiensten als externe toezichthouders – verwachten steeds vaker dat organisaties een consistente methode hanteren voor netwerkarchitectuur over alle technologieën heen, inclusief cloud. Het beschreven hub-spoke raamwerk biedt hiervoor een duidelijke kapstok. Voor auditdoeleinden is het essentieel dat de organisatie kan laten zien dat: er een formeel vastgesteld netwerkarchitectuurbeleid is dat ook voor Azure geldt; hub-spoke architectuur is geïmplementeerd met alle benodigde componenten; de resultaten zijn vastgelegd in beveiligingsdocumentatie met toegewezen eigenaarschap; en dat uitgevoerde maatregelen en resterende risico's traceerbaar zijn naar concrete besluiten en acties. Het gebruik van gestandaardiseerde formats, centrale opslag van configuraties en systematische koppeling met compliance-dashboards is hierbij onmisbaar. Het PowerShell-script uit dit artikel kan aanvullend worden gebruikt als bron van objectief bewijsmateriaal over de technische inrichting van de Azure-netwerkarchitectuur, bijvoorbeeld om te onderbouwen dat er daadwerkelijk hub-spoke configuraties zijn geïmplementeerd en dat deze correct functioneren.

Remediatie

Gebruik PowerShell-script hub-spoke-architecture.ps1 (functie Invoke-Remediation) – Identificeert en herstelt ontbrekende of zwakke hub-spoke configuraties.

Wanneer uit audits, incidenten of periodieke assessments blijkt dat hub-spoke netwerkarchitectuur onvoldoende is geïmplementeerd of dat bepaalde componenten zwak zijn, is een gestructureerd remediatieproces noodzakelijk om het beveiligingsniveau snel en gecontroleerd te verhogen. De eerste stap in dit proces is het uitvoeren van een gap-analyse ten opzichte van het gewenste hub-spoke raamwerk: welke componenten zijn al aanwezig en correct geconfigureerd, welke componenten zijn gedeeltelijk geïmplementeerd maar hebben tekortkomingen, en welke componenten ontbreken volledig? Deze gap-analyse wordt idealiter uitgevoerd door een multidisciplinair team bestaande uit netwerkarchitect, security engineers, cloudbeheerders en vertegenwoordigers uit de business. Het resultaat is een overzicht van concrete tekortkomingen per component, geprioriteerd op basis van risico en compliance-impact. Vervolgens wordt per tekortkoming een gerichte remediatiestrategie bepaald. Ontbreekt bijvoorbeeld het hub-netwerk volledig, dan is de remediatie het inrichten van een project waarin het centrale hub-netwerk wordt gecreëerd met alle benodigde services zoals Azure Firewall, VPN Gateway en Azure Bastion. Zijn spoke-netwerken gedeeltelijk aanwezig maar ontbreken VNet-peering verbindingen, dan ligt de nadruk op het configureren van peering tussen hub en spokes met de juiste routingregels. In situaties waarin meerdere componenten zwak zijn – wat zeker bij versneld gecreëerde cloudomgevingen vaak voorkomt – moet een gefaseerde aanpak worden gevolgd waarbij eerst het hub-netwerk wordt versterkt, gevolgd door de implementatie van spoke-netwerken en peering-verbindingen, en tot slot aanvullende beveiligingsservices en monitoring. Een belangrijk remediatiepad betreft het migreren van bestaande platte netwerkarchitecturen naar hub-spoke. Wanneer organisaties momenteel alle workloads in één virtueel netwerk hebben, vereist de migratie naar hub-spoke een gefaseerde aanpak. De eerste fase omvat het ontwerpen van de nieuwe architectuur, inclusief het identificeren van welke services in het centrale hub-netwerk moeten worden geplaatst en welke workloads in de verschillende spoke-netwerken moeten worden georganiseerd. Deze ontwerpfase is cruciaal en moet worden uitgevoerd door ervaren netwerkarchitecten in samenwerking met beveiligingsexperts. De implementatiefase begint met het creëren van het centrale hub-netwerk en het migreren van gedeelde services naar dit netwerk. Vervolgens moeten de bestaande workloads worden georganiseerd in logische groepen die worden vertegenwoordigd door verschillende spoke-netwerken, waarbij zorgvuldig moet worden gecontroleerd dat alle afhankelijkheden en verbindingen correct worden gehandhaafd. Technisch gezien kan remediatie ook bestaan uit het herstructureren van bestaande hub-spoke configuraties om beveiliging te verbeteren. Denk aan het toevoegen van ontbrekende beveiligingsservices zoals Azure Firewall of het verbeteren van firewallconfiguraties met threat intelligence en application rules. Het implementeren van Network Security Groups voor subnet-niveau beveiliging waar deze ontbreken, of het configureren van route tables om verkeer te routeren via de firewall. Het inschakelen van Network Watcher en NSG flow logs voor uitgebreide monitoring waar deze nog niet zijn geconfigureerd. Deze stappen moeten altijd worden uitgevoerd op basis van een gedetailleerd migratieplan, inclusief impactanalyse, fallbackscenario's en communicatie met betrokken teams. Tot slot moet elke remediatie-inspanning worden afgesloten met een expliciete evaluatie en bijstelling van het hub-spoke raamwerk. De lessen uit incidenten en audits – bijvoorbeeld een succesvolle aanval die netwerksegmentatie heeft doorbroken of onvoldoende detectie van verdacht verkeer – moeten structureel worden verwerkt in de netwerkarchitectuur, configuraties en procedures. Het is raadzaam om na afronding van een remediatieprogramma een integrale security assessment te laten uitvoeren door een interne auditdienst of een onafhankelijke derde, zodat kan worden vastgesteld of het nieuwe niveau van hub-spoke daadwerkelijk in lijn is met NIS2, BIO en de verwachtingen van het bestuur. De uitkomsten hiervan worden vastgelegd in beveiligingsdocumentatie en vormen het nieuwe vertrekpunt voor de reguliere cyclus van monitoring en verbetering.

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 Hub-Spoke Architectuur validatie en implementatie .DESCRIPTION Dit script ondersteunt Nederlandse overheidsorganisaties bij het valideren en implementeren van hub-spoke netwerkarchitectuur in Azure-omgevingen. Het script controleert de status van alle hub-spoke componenten: hub-netwerk, spoke-netwerken, VNet-peering verbindingen, Azure Firewall, en netwerkbeveiliging. 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: hub-spoke-architecture.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-15 Version: 1.0 Related JSON: content/azure/network/hub-spoke-architecture.json Category: network Workload: azure .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\hub-spoke-architecture.ps1 -Monitoring Voert een read-only validatie uit van alle hub-spoke componenten en toont een samenvatting van de huidige status. .EXAMPLE .\hub-spoke-architecture.ps1 -Remediation -WhatIf Genereert een rapport met concrete aanbevelingen zonder wijzigingen aan te brengen. .EXAMPLE .\hub-spoke-architecture.ps1 -ExportPath .\hub-spoke-report.json Exporteert de validatie- en aanbevelingsgegevens naar een JSON-bestand. #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Network, Az.Resources [CmdletBinding()] param( [Parameter(HelpMessage = "Voer een read-only validatie uit van alle hub-spoke componenten")] [switch]$Monitoring, [Parameter(HelpMessage = "Genereer aanbevelingen en implementeer ontbrekende hub-spoke 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 Hub-Spoke Architectuur – 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-NbvvcHubSpokeStatus { <# .SYNOPSIS Verzamelt de status van alle hub-spoke componenten .DESCRIPTION Haalt de status op van hub-netwerk, spoke-netwerken, VNet-peering, Azure Firewall en netwerkbeveiliging. De validatie is read-only en bedoeld als input voor verder architectuur- en compliancewerk. .OUTPUTS Hashtable met hub-spoke status per component #> [CmdletBinding()] param() $status = @{ timestamp = Get-Date subscriptionId = (Get-AzContext).Subscription.Id hubNetwork = @{ exists = $false vnetName = $null firewallEnabled = $false bastionEnabled = $false vpnGatewayEnabled = $false findings = @() } spokeNetworks = @{ count = 0 peerings = 0 findings = @() } networkSecurity = @{ nsgCount = 0 privateEndpoints = 0 findings = @() } overallScore = 0 } Write-Host "`nValidatie van hub-spoke componenten (read-only)..." -ForegroundColor Yellow # Hub-netwerk - Controleer op VNets met typische hub-subnetten try { $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue $hubVNet = $null foreach ($vnet in $vnets) { $subnetNames = $vnet.Subnets | ForEach-Object { $_.Name } # Typische hub-subnetten: AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet if ($subnetNames -contains "AzureFirewallSubnet" -or $subnetNames -contains "GatewaySubnet" -or $subnetNames -contains "AzureBastionSubnet") { $hubVNet = $vnet break } } if ($hubVNet) { $status.hubNetwork.exists = $true $status.hubNetwork.vnetName = $hubVNet.Name Write-Host " Hub-netwerk: $($hubVNet.Name) gevonden" -ForegroundColor Gray # Controleer Azure Firewall $firewalls = Get-AzFirewall -ErrorAction SilentlyContinue if ($firewalls.Count -gt 0) { $status.hubNetwork.firewallEnabled = $true Write-Host " Hub-netwerk: $($firewalls.Count) Azure Firewall(s) gevonden" -ForegroundColor Gray } else { $status.hubNetwork.findings += "Geen Azure Firewall gevonden in hub-netwerk; overweeg implementatie voor gecentraliseerde netwerkbeveiliging." } # Controleer Azure Bastion $bastions = Get-AzBastion -ErrorAction SilentlyContinue if ($bastions.Count -gt 0) { $status.hubNetwork.bastionEnabled = $true Write-Host " Hub-netwerk: $($bastions.Count) Azure Bastion(s) gevonden" -ForegroundColor Gray } else { $status.hubNetwork.findings += "Geen Azure Bastion gevonden in hub-netwerk; overweeg implementatie voor veilige beheerstoegang." } # Controleer VPN Gateway $vpnGateways = Get-AzVirtualNetworkGateway -ErrorAction SilentlyContinue | Where-Object { $_.GatewayType -eq "Vpn" } if ($vpnGateways.Count -gt 0) { $status.hubNetwork.vpnGatewayEnabled = $true Write-Host " Hub-netwerk: $($vpnGateways.Count) VPN Gateway(s) gevonden" -ForegroundColor Gray } } else { $status.hubNetwork.findings += "Geen hub-netwerk gevonden met typische hub-subnetten (AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet)." } } catch { Write-Host " [WARN] Kon hub-netwerkstatus niet volledig valideren: $_" -ForegroundColor Yellow $status.hubNetwork.findings += "Kon hub-netwerkstatus niet volledig valideren; controleer rechten en Az.Network-module." } # Spoke-netwerken - Controleer VNets en peering-verbindingen try { $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue $allPeerings = @() foreach ($vnet in $vnets) { $peerings = Get-AzVirtualNetworkPeering -ResourceGroupName $vnet.ResourceGroupName -VirtualNetworkName $vnet.Name -ErrorAction SilentlyContinue $allPeerings += $peerings } $status.spokeNetworks.count = $vnets.Count $status.spokeNetworks.peerings = $allPeerings.Count Write-Host " Spoke-netwerken: $($vnets.Count) VNets gevonden, $($allPeerings.Count) peering-verbindingen" -ForegroundColor Gray if ($allPeerings.Count -eq 0 -and $vnets.Count -gt 1) { $status.spokeNetworks.findings += "Meerdere VNets gevonden maar geen peering-verbindingen; overweeg hub-spoke topologie met VNet-peering." } elseif ($allPeerings.Count -gt 0 -and -not $status.hubNetwork.exists) { $status.spokeNetworks.findings += "Peering-verbindingen gevonden maar geen duidelijk hub-netwerk geïdentificeerd; verifieer netwerkarchitectuur." } } catch { Write-Host " [WARN] Kon spoke-netwerkstatus niet volledig valideren: $_" -ForegroundColor Yellow $status.spokeNetworks.findings += "Kon spoke-netwerkstatus niet volledig valideren; controleer rechten en Az.Network-module." } # Netwerkbeveiliging - Controleer NSG's en private endpoints try { $nsgs = Get-AzNetworkSecurityGroup -ErrorAction SilentlyContinue $status.networkSecurity.nsgCount = $nsgs.Count Write-Host " Netwerkbeveiliging: $($nsgs.Count) Network Security Group(s) gevonden" -ForegroundColor Gray $privateEndpoints = Get-AzPrivateEndpoint -ErrorAction SilentlyContinue $status.networkSecurity.privateEndpoints = $privateEndpoints.Count Write-Host " Netwerkbeveiliging: $($privateEndpoints.Count) private endpoint(s) gevonden" -ForegroundColor Gray if ($nsgs.Count -eq 0) { $status.networkSecurity.findings += "Geen Network Security Groups gevonden; overweeg implementatie voor subnet-niveau beveiliging." } if ($privateEndpoints.Count -eq 0) { $status.networkSecurity.findings += "Geen private endpoints gevonden; overweeg implementatie voor private connectivity naar Azure-services." } } catch { Write-Host " [WARN] Kon netwerkbeveiligingsstatus niet volledig valideren: $_" -ForegroundColor Yellow $status.networkSecurity.findings += "Kon netwerkbeveiligingsstatus niet volledig valideren; controleer rechten en benodigde modules." } # Bereken overall score (eenvoudige berekening op basis van beschikbare controles) $scoreComponents = 0 $scoreTotal = 0 if ($status.hubNetwork.exists) { $scoreComponents++ } if ($status.hubNetwork.firewallEnabled) { $scoreComponents++ } if ($status.hubNetwork.bastionEnabled) { $scoreComponents++ } $scoreTotal += 3 if ($status.spokeNetworks.peerings -gt 0) { $scoreComponents++ } $scoreTotal += 1 if ($status.networkSecurity.nsgCount -gt 0) { $scoreComponents++ } if ($status.networkSecurity.privateEndpoints -gt 0) { $scoreComponents++ } $scoreTotal += 2 if ($scoreTotal -gt 0) { $status.overallScore = [math]::Round(($scoreComponents / $scoreTotal) * 100, 1) } return $status } function Invoke-Monitoring { <# .SYNOPSIS Voert een read-only hub-spoke validatie uit .DESCRIPTION Gebruikt statuscontroles om inzicht te geven in de huidige hub-spoke implementatie per component. Dit helpt bij het prioriteren van implementatietrajecten en het identificeren van gaten in de beveiliging. .OUTPUTS Hashtable met samenvattende metrics en status per component #> [CmdletBinding()] param() $null = Connect-NbvvcAzContext $status = Get-NbvvcHubSpokeStatus Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "SAMENVATTING HUB-SPOKE STATUS" -ForegroundColor Cyan Write-Host " Overall Score : $($status.overallScore)%" -ForegroundColor White Write-Host "`n Hub-netwerk:" -ForegroundColor Yellow Write-Host " Hub-netwerk gevonden : $($status.hubNetwork.exists)" -ForegroundColor Gray if ($status.hubNetwork.exists) { Write-Host " Hub VNet naam : $($status.hubNetwork.vnetName)" -ForegroundColor Gray } Write-Host " Firewall ingeschakeld : $($status.hubNetwork.firewallEnabled)" -ForegroundColor Gray Write-Host " Bastion ingeschakeld : $($status.hubNetwork.bastionEnabled)" -ForegroundColor Gray Write-Host " VPN Gateway ingeschakeld: $($status.hubNetwork.vpnGatewayEnabled)" -ForegroundColor Gray Write-Host "`n Spoke-netwerken:" -ForegroundColor Yellow Write-Host " Aantal VNets : $($status.spokeNetworks.count)" -ForegroundColor Gray Write-Host " Peering-verbindingen : $($status.spokeNetworks.peerings)" -ForegroundColor Gray Write-Host "`n Netwerkbeveiliging:" -ForegroundColor Yellow Write-Host " Network Security Groups: $($status.networkSecurity.nsgCount)" -ForegroundColor Gray Write-Host " Private Endpoints : $($status.networkSecurity.privateEndpoints)" -ForegroundColor Gray $allFindings = @() $allFindings += $status.hubNetwork.findings $allFindings += $status.spokeNetworks.findings $allFindings += $status.networkSecurity.findings 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 hub-spoke aanbevelingen en implementeert ontbrekende configuraties .DESCRIPTION Op basis van de statusvalidatie worden concrete aanbevelingen gegenereerd voor vervolgstappen zoals het implementeren van ontbrekende hub-spoke componenten. 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 statusvalidatie, maar er vinden geen wijzigingen plaats." -ForegroundColor Yellow } $result = Invoke-Monitoring $status = $result.status $recommendations = @() if (-not $status.hubNetwork.exists) { $recommendations += "Implementeer een centraal hub-netwerk met gedeelde beveiligingsservices zoals Azure Firewall, VPN Gateway en Azure Bastion." } if (-not $status.hubNetwork.firewallEnabled) { $recommendations += "Implementeer Azure Firewall in het hub-netwerk voor gecentraliseerde netwerkbeveiliging en threat intelligence." } if (-not $status.hubNetwork.bastionEnabled) { $recommendations += "Implementeer Azure Bastion in het hub-netwerk voor veilige beheerstoegang zonder publieke IP-adressen." } if ($status.spokeNetworks.peerings -eq 0 -and $status.spokeNetworks.count -gt 1) { $recommendations += "Configureer VNet-peering tussen hub-netwerk en spoke-netwerken voor naadloze connectiviteit en netwerksegmentatie." } if ($status.networkSecurity.nsgCount -eq 0) { $recommendations += "Implementeer Network Security Groups voor subnet-niveau beveiliging in alle netwerken." } if ($status.networkSecurity.privateEndpoints -eq 0) { $recommendations += "Implementeer private endpoints voor alle kritieke Azure-services om publieke toegang te voorkomen." } if ($recommendations.Count -eq 0) { $recommendations += "Geen specifieke aanbevelingen op basis van deze scan; voer een diepgaand netwerkarchitectuur-assessment uit voor kernsystemen." } 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 hubSpoke = @{ 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 hub-spoke 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 hub-spoke implementaties 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 "`nHub-spoke implementaties 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 hub-spoke netwerkarchitectuur .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 hub-spoke validatie uit" -ForegroundColor Gray Write-Host " -Remediation : Genereer hub-spoke aanbevelingen (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: .\hub-spoke-architecture.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: Kritiek - Zonder hub-spoke netwerkarchitectuur is de organisatie kwetsbaar voor laterale beweging door aanvallers, wat kan leiden tot volledige compromittering van de cloudomgeving en niet-naleving van NIS2 en BIO vereisten.

Management Samenvatting

Implementeer hub-spoke netwerkarchitectuur met centraal hub-netwerk voor gedeelde beveiligingsservices en geïsoleerde spoke-netwerken voor workloads. Essentieel voor netwerksegmentatie, Zero Trust en NIS2/BIO compliance. Implementatie: 90 uur.