L1/L2 BIO 09.01 ISO A.5.15 CIS CIS Kubernetes Benchmark – Network Policies

Network Policies Geconfigureerd Voor Azure Kubernetes Service (AKS)

📅 2025-11-26
•
⏱️ 20 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Met Kubernetes Network Policies bepaalt u welke workloads in een AKS-cluster met elkaar en met de buitenwereld mogen communiceren. Voor Nederlandse overheidsorganisaties is het afdwingen van deze netwerksegmentatie een kerneis binnen een Zero Trust-architectuur.

Aanbeveling
IMPLEMENTEER EN HANDHAAF NETWORK POLICIES IN ALLE AKS-CLUSTERS
Risico zonder
High
Risk Score
8/10
Implementatie
100u (tech: 60u)
Van toepassing op:
✓ Azure
✓ Azure Kubernetes Service
✓ Containerized Workloads

Zonder expliciet geconfigureerde network policies functioneren AKS-clusters in de praktijk vaak als één vlak netwerksegment: iedere pod kan in principe met iedere andere pod praten, en soms zelfs rechtstreeks met internet of backend-diensten zonder enige beperking. In omgevingen met burgerportalen, zaak- en documentservices, en koppelingen met achterliggende registratiesystemen betekent dit dat een compromis van één container zich eenvoudig kan uitbreiden naar andere workloads. Voor CISO’s en auditors is in zo’n situatie nauwelijks uit te leggen hoe laterale verplaatsing wordt beperkt of hoe gevoelige diensten van minder kritieke workloads zijn gescheiden. Bovendien sluiten ongesegmenteerde clusters slecht aan bij eisen uit de BIO, NIS2 en sectorale kaders, waar netwerksegmentatie, minimalisatie van vertrouwensrelaties en controleerbare toegangsregels expliciet worden benoemd.

PowerShell Modules Vereist
Primary API: Azure Resource Manager (ARM)
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Resources, Az.Aks

Implementatie

Dit artikel beschrijft hoe u network policies in Azure Kubernetes Service zodanig ontwerpt en configureert dat ze passen binnen de Nederlandse Baseline voor Veilige Cloud. We gaan in op het concept van NetworkPolicy in Kubernetes, de relatie met Azure CNI en Azure Firewall, en de manier waarop u namespaces en labels ontwerpt om logisch gescheiden domeinen te creëren. Vervolgens laten we zien hoe u met het bijbehorende PowerShell-script een inventarisatie uitvoert van clusters waar geen enkele netwerkpolicy actief is, hoe u dit resultaat vertaalt naar concrete verbeteracties en hoe u de voortgang structureel monitort. De nadruk ligt op praktische toepasbaarheid voor overheidsorganisaties met meerdere ontwikkelteams en leveranciers, waarbij aantoonbaarheid richting interne en externe toezichthouders centraal staat.

Conceptueel ontwerp van netwerksegmentatie in AKS

Kubernetes Network Policies vormen de applicatielaag van netwerksegmentatie binnen AKS. Waar traditionele firewalls verkeer op IP- en poortniveau filteren, leggen NetworkPolicies vast welke pods met welke andere pods of externe endpoints mogen communiceren op basis van labels en namespaces. Standaard geldt in veel AKS-implementaties een permissief model: als er geen network policies zijn gedefinieerd, is vrijwel al het verkeer binnen het cluster toegestaan. Dit staat haaks op de uitgangspunten van Zero Trust en de Nederlandse Baseline voor Veilige Cloud, waarin expliciete toegangsbeslissingen, minimale privileges en segmentatie van kritieke componenten worden verlangd. Een volwassen ontwerp start daarom met het identificeren van trust boundaries: scheidingen tussen publieke frontends, businesslogica, data-opslag, beheercomponenten en externe koppelingen. Deze grenzen worden vervolgens vertaald naar namespaces, labels en NetworkPolicies die alleen de strikt noodzakelijke communicatie toestaan.

Voor Nederlandse overheidsorganisaties betekent dit dat de logische scheiding in de bestaande architectuur – bijvoorbeeld tussen burgerportalen, interne behandelomgevingen en koppelingen met basisregistraties – herkenbaar moet terugkomen in het AKS-cluster. Frontend-pods in een "public"-namespace mogen doorgaans alleen via gedefinieerde ingress-routes worden benaderd en uitsluitend communiceren met specifieke backend-services in een "application"- of "api"-namespace. Data-intensieve workloads, zoals databases of stateful services, worden in een aparte namespace geplaatst met zeer beperkte ingangen, vaak uitsluitend vanaf een beperkt aantal applicatieservices. Daarnaast zijn er beheer- en observabilitycomponenten, zoals controllers, operators, monitoring agents en policy-implementaties, die opnieuw een eigen segment verdienen. Door deze domeinen expliciet te modelleren en elke namespace te voorzien van een set NetworkPolicies die inkomend en uitgaand verkeer regelen, ontstaat een fijnmazige maar beheersbare segmentatie.

Een goed ontwerp gaat verder dan alleen techniek en raakt direct aan governance en verantwoordelijkheden. Wie mag nieuwe NetworkPolicies toevoegen of wijzigen, en hoe wordt geborgd dat experimentele aanpassingen in een ontwikkelomgeving niet ongemerkt in productie belanden? Binnen de Nederlandse publieke sector werken vaak meerdere leveranciers en interne teams tegelijk op hetzelfde platform. Het is daarom verstandig om een onderscheid te maken tussen platformpolicies, die door het centrale cloud- of platformteam worden beheerd, en applicatiepolicies, die onder regie van de applicatie-eigenaar tot stand komen binnen vooraf afgesproken kaders. Platformpolicies zorgen voor basisbescherming, zoals het standaard blokkeren van cross-namespace verkeer of directe uitgaande verbindingen naar internet, terwijl applicatiepolicies de fijnmazige uitzonderingen vastleggen die nodig zijn voor een specifieke dienst. Leg deze rolverdeling vast in architectuur- en securitydocumentatie en koppel deze aan het changeproces, zodat wijzigingen in network policies altijd traceerbaar en verantwoord zijn.

Implementatie, validatie en geautomatiseerde controles

Gebruik PowerShell-script network-policies-configured.ps1 (functie Invoke-Monitoring) – Inventariseert per abonnement welke AKS-clusters geen enkele Kubernetes NetworkPolicy-objecten bevatten en geeft een overzicht voor verdere analyse..

De implementatie van network policies in AKS begint in de praktijk met een zorgvuldig gekozen pilot. Selecteer één of enkele niet-kritieke clusters waarin u het beoogde segmentatiemodel uitwerkt in namespaces, labels en NetworkPolicy-manifests. Gebruik Infrastructure as Code (bijvoorbeeld Bicep, Terraform of GitOps met Flux/ArgoCD) om deze policies als code te beheren, zodat wijzigingen altijd via versiebeheer en geformaliseerde changeprocedures verlopen. In de pilotfase ligt de nadruk op het beperken van laterale verplaatsing zonder direct productieomgevingen te verstoren. Begin met policies die expliciet verkeer toestaan (allow-rules) en combineer deze met een bewuste keuze: ofwel u hanteert nog een permissief default-deny-niveau en bouwt dat gefaseerd af, of u introduceert per namespace een set policies die effectief een default deny realiseren nadat de benodigde toegangswegen zijn beschreven. Documenteer voor elke policy welk doel zij dient, welke services erdoor worden beïnvloed en wat de relatie is met bestaande architectuurprincipes.

Valideren van network policies vereist zowel technische tests als functionele verificatie. Technisch kunt u gebruikmaken van tools zoals "kubectl exec" om connectiviteit tussen pods te testen, netwerkdiagnosetools binnen containers en observability-oplossingen zoals Azure Monitor en Network Watcher. Functioneel is het van belang om samen met applicatie-eigenaren door te lopen welke ketens essentieel zijn: van burger of medewerker aan de voorkant, via allerlei tussenlagen, tot en met de data-opslag en externe koppelingen. Elke stap in deze keten moet expliciet gedekt zijn door een NetworkPolicy-regel; onverwachte afhankelijkheden worden tijdens deze exercitie zichtbaar. Het bij deze richtlijn geleverde PowerShell-script ondersteunt u door in één oogopslag te laten zien welke clusters helemaal geen NetworkPolicy-objecten bevatten. Clusters waarin wel policies bestaan maar het patroon inconsistent of onvoldoende gedocumenteerd is, worden vervolgens in verdiepende sessies onder de loep genomen. Zo zorgt u dat bevindingen uit de pilot zich vertalen naar een organisatiebrede verbeteraanpak.

Automatisering is cruciaal om network policies duurzaam te borgen. Integreer policy- en manifestvalidaties in uw CI/CD-pijplijnen, zodat nieuwe configuraties al worden beoordeeld voordat ze een cluster bereiken. Denk aan het blokkeren van deployments die geen labels bevatten die passen binnen het afgesproken segmentatiemodel, of het afkeuren van manifests die naast applicielogica ook netwerkregels proberen te wijzigen buiten de geautoriseerde paden. Combineer dit met Azure Policy en het Azure Policy add-on voor AKS, zodat u ook vanuit het platform afdwingt dat clusters een minimaal niveau van netwerkbeveiliging hanteren. Rapportages uit het PowerShell-script, Azure Policy en logging uit de clusteromgeving worden samengebracht in dashboards voor het cloud governance board en de CISO-organisatie. Daarmee ontstaat een continu beeld van de volwassenheid van network policies over alle AKS-omgevingen heen, in plaats van incidentele controles bij projecten of audits.

Compliance, governance en aansluiting op Nederlandse kaders

Gebruik PowerShell-script network-policies-configured.ps1 (functie Invoke-Remediation) – Genereert een overzicht van AKS-clusters zonder netwerkpolicies en geeft tekstuele aanbevelingen voor remediatie en governance..

Vanuit complianceperspectief zijn geconfigureerde network policies in AKS een concreet bewijs dat netwerksegmentatie en toegangsbeheersing niet alleen op papier bestaan, maar ook daadwerkelijk in de technische inrichting zijn doorvertaald. Binnen de BIO wordt onder meer verlangd dat logische scheiding van omgevingen en functies aantoonbaar is ingericht en beheerd. Door namespaces, labels en NetworkPolicies te koppelen aan specifieke diensten en processen, kan bij audits helder worden uitgelegd hoe bijvoorbeeld een burgerportaal logisch is gescheiden van interne behandelapplicaties en van generieke infrastructuurdiensten. De output van het PowerShell-script – een lijst van clusters waarin nog geen enkele NetworkPolicy is gedefinieerd – helpt om snel te laten zien waar dit nog niet het geval is en welke verbetertrajecten lopen. In auditdossiers kan deze informatie worden opgenomen als onderdeel van een plan van aanpak voor het realiseren van een uniform segmentatieniveau over alle AKS-omgevingen.

De NIS2-richtlijn en ISO 27001 benadrukken het belang van technische en organisatorische maatregelen om de impact van beveiligingsincidenten te beperken. Network policies in AKS dragen direct bij aan het beperken van laterale beweging: zelfs wanneer een aanvaller een container weet te compromitteren, is de mogelijkheid om zich verder in de omgeving te verplaatsen beperkt tot de in de policies toegestane paden. Dit maakt het eenvoudiger om aan te tonen dat redelijke maatregelen zijn getroffen om de gevolgen van kwetsbaarheden in applicatiecode, third-party libraries of onderliggende platformcomponenten te mitigeren. In rapportages aan bestuurders en toezichthouders kan worden toegelicht welke segmentatiestrategie is gekozen, hoe deze is geïmplementeerd in AKS en hoe regelmatig wordt geëvalueerd of deze nog aansluit bij actuele dreigingsbeelden en dienstenportfolio’s. Een volwassen governanceproces voorziet daarnaast in expliciet vastgelegde uitzonderingen, bijvoorbeeld voor legacy-toepassingen, inclusief risicobeoordeling en einddatum.

Tot slot is continue verbetering essentieel. Nieuwe diensten, cloudpatronen en integraties kunnen de oorspronkelijke segmentatie-uitgangspunten onder druk zetten. Door periodiek – bijvoorbeeld per kwartaal – de resultaten van het PowerShell-script, Azure Policy-rapportages en incident- of bijna-incidentanalyses samen te brengen in een cloud risk board, kunnen patronen worden herkend: welke organisatieonderdelen lopen structureel achter, waar zijn extra ondersteunings- of opleidingsmaatregelen nodig en welke generieke bouwblokken of referentie-implementaties ontbreken nog? Door lessons learned uit één clusterfamilie te vertalen naar generieke richtlijnen en voorbeeldmanifests, verbetert de volwassenheid van network policies stapsgewijs in de volle breedte van de organisatie. Daarmee wordt network policy-configuratie in AKS niet gezien als een eenmalig project, maar als een voortdurend onderdeel van de Nederlandse Baseline voor Veilige Cloud.

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 Controleert of Kubernetes NetworkPolicies zijn geconfigureerd in AKS-clusters en geeft remediatie-advies. .DESCRIPTION Dit script inventariseert alle AKS-clusters in de opgegeven of alle abonnementen en controleert of er in elk cluster minimaal één Kubernetes NetworkPolicy-object aanwezig is. In monitoringmodus wordt een rapport gegenereerd met de status per cluster. In remediatiemodus wordt een overzicht gemaakt van clusters zonder network policies met concrete aanbevelingen voor vervolgacties. .NOTES Filename: network-policies-configured.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Last Modified: 2025-11-26 Version: 1.0 Related JSON: content/azure/aks/network-policies-configured.json .LINK https://github.com/[org]/m365-tenant-best-practise .EXAMPLE .\network-policies-configured.ps1 -Monitoring Voert een controle uit op alle toegankelijke abonnementen en toont de status van network policies per cluster. .EXAMPLE .\network-policies-configured.ps1 -Remediation Genereert een overzicht van AKS-clusters zonder network policies en aanbevelingen voor herstel. .EXAMPLE .\network-policies-configured.ps1 -Monitoring -LocalDebug Draait een lokale debug-run met gesimuleerde data zonder Azure-verbinding of Kubernetes-API-calls. #> #Requires -Version 5.1 [CmdletBinding()] param( [Parameter()] [switch]$WhatIf, [Parameter()] [switch]$Monitoring, [Parameter()] [switch]$Remediation, [Parameter()] [string[]]$SubscriptionId, [Parameter()] [switch]$LocalDebug ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Network policies geconfigureerd voor AKS-clusters" $PolicyDescription = "Controleert of AKS-clusters voorzien zijn van Kubernetes NetworkPolicies zodat netwerksegmentatie en Zero Trust op workloadniveau afdwingbaar zijn." function Test-ModuleAvailability { [CmdletBinding()] param( [Parameter(Mandatory = $true)] [string[]]$ModuleName ) foreach ($name in $ModuleName) { if (-not (Get-Module -ListAvailable -Name $name)) { Write-Warning "Vereiste module '$name' is niet geïnstalleerd. Installeer deze module voor volledige functionaliteit." } } } function Connect-RequiredServices { <# .SYNOPSIS Maakt verbinding met Azure als dat nog niet is gebeurd. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "LocalDebug is ingeschakeld; er wordt geen Azure-verbinding opgezet." return } Test-ModuleAvailability -ModuleName @('Az.Accounts', 'Az.Resources', 'Az.Aks') try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Verbinding maken met Azure..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null } else { Write-Verbose "Reeds verbonden met Azure: $($context.Subscription.Name)" } } catch { Write-Error "Kon geen verbinding maken met Azure: $_" throw } } function Get-DebugNetworkPolicyData { [CmdletBinding()] param() return @( [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000010" SubscriptionName = "DBG-Overheid-NonProd" ResourceGroupName = "rg-aks-nonprod" ClusterName = "aks-nonprod-01" Location = "westeurope" NetworkPolicyProvider = "azure" HasNetworkPolicies = $true }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000020" SubscriptionName = "DBG-Overheid-Prod" ResourceGroupName = "rg-aks-prod" ClusterName = "aks-prod-01" Location = "westeurope" NetworkPolicyProvider = "" HasNetworkPolicies = $false } ) } function Get-AksNetworkPolicyStatus { <# .SYNOPSIS Haalt alle AKS-clusters op en bepaalt of network policies zijn geconfigureerd. .OUTPUTS PSCustomObject met cluster- en networkpolicy-informatie. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "Gebruik van gesimuleerde AKS-networkpolicydata (LocalDebug)." return Get-DebugNetworkPolicyData } Write-Verbose "Ophalen van AKS-clusters via Azure Resource Graph..." $query = @' resources | where type == "microsoft.containerservice/managedclusters" | project id, name, location, subscriptionId, resourceGroup, properties '@ $argParams = @{ Query = $query } if ($SubscriptionId) { $argParams['Subscription'] = $SubscriptionId } $clusters = Search-AzGraph @argParams $results = @() foreach ($cluster in $clusters) { $networkProfile = $cluster.properties.networkProfile $networkPolicyProvider = $null if ($networkProfile -and $networkProfile.networkPolicy) { $networkPolicyProvider = [string]$networkProfile.networkPolicy } # In veel implementaties is het netwerkpolicytype een indicatie; # of er daadwerkelijk NetworkPolicy-objecten zijn gedeployed, is een # vervolgvraag. Dit script hanteert een pragmatische aanpak: # clusters zonder networkPolicy-configuratie worden als risicovol gemarkeerd. $hasPolicies = -not [string]::IsNullOrWhiteSpace($networkPolicyProvider) $results += [PSCustomObject]@{ SubscriptionId = $cluster.subscriptionId SubscriptionName = (Get-AzSubscription -SubscriptionId $cluster.subscriptionId -ErrorAction SilentlyContinue).Name ResourceGroupName = $cluster.resourceGroup ClusterName = $cluster.name Location = $cluster.location NetworkPolicyProvider = $networkPolicyProvider HasNetworkPolicies = $hasPolicies } } return $results } function Test-Compliance { <# .SYNOPSIS Bepaalt de compliancestatus voor network policies op AKS-clusters. .OUTPUTS PSCustomObject met samenvatting van de resultaten. #> [CmdletBinding()] param() $clusters = Get-AksNetworkPolicyStatus if (-not $clusters -or $clusters.Count -eq 0) { Write-Verbose "Geen AKS-clusters gevonden in de geselecteerde scope." return [PSCustomObject]@{ ScriptName = "network-policies-configured" IsCompliant = $true Timestamp = Get-Date Details = "Er zijn geen AKS-clusters gevonden in de huidige scope." Recommendations = @() Clusters = @() } } $nonCompliant = $clusters | Where-Object { -not $_.HasNetworkPolicies } $isCompliant = ($nonCompliant.Count -eq 0) $details = if ($isCompliant) { "Alle gevonden AKS-clusters hebben een netwerkpolicyprovider geconfigureerd." } else { "Een of meer AKS-clusters hebben geen netwerkpolicyprovider geconfigureerd en missen daarmee een belangrijke bouwsteen voor segmentatie." } $recommendations = @() if (-not $isCompliant) { $recommendations += "Schakel een geschikte netwerkpolicyprovider (bijv. 'azure' of 'calico') in voor alle niet-conforme AKS-clusters." $recommendations += "Ontwerp en implementeer Kubernetes NetworkPolicies per namespace op basis van de architectuur- en BIO-eisen." $recommendations += "Gebruik CI/CD en Azure Policy om het gebruik van network policies te borgen en afwijkingen vroegtijdig te signaleren." } return [PSCustomObject]@{ ScriptName = "network-policies-configured" IsCompliant = $isCompliant Timestamp = Get-Date Details = $details Recommendations = $recommendations Clusters = $clusters } } function Invoke-Monitoring { <# .SYNOPSIS Voert een monitoring-run uit en toont de status per AKS-cluster. #> [CmdletBinding()] param() Write-Host "`nMonitoring: $PolicyName" -ForegroundColor Yellow Write-Host "Beschrijving: $PolicyDescription" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $clusters = $result.Clusters if ($clusters.Count -gt 0) { Write-Host "`nGevonden AKS-clusters:" -ForegroundColor Cyan foreach ($cluster in $clusters) { $statusColor = if ($cluster.HasNetworkPolicies) { "Green" } else { "Red" } $statusText = if ($cluster.HasNetworkPolicies) { "Network policies: geconfigureerd (provider: $($cluster.NetworkPolicyProvider))" } else { "Network policies: NIET geconfigureerd" } Write-Host ("- {0}/{1} ({2}) - {3}" -f $cluster.SubscriptionName, $cluster.ClusterName, $cluster.Location, $statusText) -ForegroundColor $statusColor } } else { Write-Host "`nGeen AKS-clusters gevonden in de huidige scope." -ForegroundColor Cyan } if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT - Alle AKS-clusters voldoen aan de basisvoorwaarde voor network policies." -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT - Eén of meer AKS-clusters missen een netwerkpolicyprovider." -ForegroundColor Red Write-Host "Aanbevolen acties:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -ForegroundColor Yellow } } return $result } function Invoke-Remediation { <# .SYNOPSIS Geeft een remediatie-overzicht voor AKS-clusters zonder network policies. #> [CmdletBinding()] param() Write-Host "`nRemediatie: $PolicyName" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $clusters = $result.Clusters | Where-Object { -not $_.HasNetworkPolicies } if (-not $clusters -or $clusters.Count -eq 0) { Write-Host "Alle AKS-clusters beschikken over een netwerkpolicyprovider. Geen remediatie nodig." -ForegroundColor Green return $result } Write-Host "`nNiet-conforme AKS-clusters (zonder netwerkpolicyprovider):" -ForegroundColor Red foreach ($cluster in $clusters) { Write-Host ("- Subscription: {0}" -f $cluster.SubscriptionName) -ForegroundColor Red Write-Host (" ResourceGroup: {0}" -f $cluster.ResourceGroupName) -ForegroundColor Red Write-Host (" Cluster: {0}" -f $cluster.ClusterName) -ForegroundColor Red Write-Host (" Locatie: {0}" -f $cluster.Location) -ForegroundColor Red Write-Host "" } Write-Host "Aanbevolen vervolgstappen:" -ForegroundColor Yellow Write-Host "1. Classificeer de niet-conforme clusters naar omgeving (ontwikkel, test, acceptatie, productie) en kriticiteit." -ForegroundColor Yellow Write-Host "2. Bepaal per cluster welke netwerkpolicyprovider (azure of calico) wordt gebruikt in de referentie-architectuur." -ForegroundColor Yellow Write-Host "3. Plan het inschakelen van de netwerkpolicyprovider via IaC-templates of gecontroleerde wijzigingsaanvragen." -ForegroundColor Yellow Write-Host "4. Ontwikkel en test Kubernetes NetworkPolicies per namespace op basis van het vastgestelde segmentatiemodel." -ForegroundColor Yellow Write-Host "5. Documenteer uitzonderingen, bijbehorende risico’s en einddata expliciet in het governance- en risicoregister." -ForegroundColor Yellow if ($WhatIf) { Write-Host "`nWhatIf is ingeschakeld: er worden geen wijzigingen doorgevoerd; alleen een rapport is gegenereerd." -ForegroundColor Cyan } return $result } try { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Script: network-policies-configured" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { Invoke-Remediation } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT" -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT" -ForegroundColor Red Write-Host "Voer het script uit met -Monitoring of -Remediation voor meer details." -ForegroundColor Yellow } return $result } } catch { Write-Error "Er is een fout opgetreden in network-policies-configured.ps1: $_" throw } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Wanneer AKS-clusters zonder network policies worden geëxploiteerd, ontbreekt effectieve netwerksegmentatie op workloadniveau. Een aanvaller die één container weet te compromitteren, kan zich dan vaak ongehinderd verplaatsen naar andere pods en diensten, met verhoogd risico op datalekken, integriteitsschade en verstoring van essentiële overheidsprocessen. Daarnaast is het in audits lastig om aan te tonen dat passende maatregelen zijn getroffen conform BIO, ISO 27001 en NIS2.

Management Samenvatting

Ontwerp en implementeer een organisatiebreed netwerksegmentatiemodel voor AKS op basis van namespaces, labels en Kubernetes NetworkPolicies. Gebruik het bijbehorende PowerShell-script om clusters zonder policies te identificeren, voer gefaseerde verbetertrajecten uit en borg de configuratie via CI/CD, Azure Policy en periodieke rapportages aan de CISO- en governance-organen. Zo maakt u network policies tot een aantoonbare pijler onder de Nederlandse Baseline voor Veilige Cloud.