Data Residency Controls Voor Azure Workloads

💼 Management Samenvatting

Data residency controls vormen de technische en beleidsmatige basis voor het beheersen van waar gegevens worden opgeslagen en verwerkt binnen Azure-omgevingen. Voor Nederlandse overheidsorganisaties die werken onder de BIO, AVG en NIS2 zijn deze controls essentieel om aantoonbaar te kunnen rapporteren over datalocaties, jurisdicties en compliance met regionale vereisten. Zonder gestructureerde controls blijft data residency een papieren belofte zonder concrete technische afdwinging.

Aanbeveling
IMPLEMENTEER DATA RESIDENCY CONTROLS VOOR ALLE AZURE WORKLOADS
Risico zonder
High
Risk Score
8/10
Implementatie
80u (tech: 50u)
Van toepassing op:
Azure Tenant
Azure Resources
Publieke Sector
Overheidsorganisaties

Zonder geïmplementeerde data residency controls kunnen Azure-resources onbedoeld worden uitgerold in regio's die niet voldoen aan de compliance-eisen van de organisatie. Dit kan leiden tot onduidelijkheid over welke jurisdicties van toepassing zijn, mogelijke schending van AVG-doorgiftebepalingen en kritische bevindingen bij audits. Voor Nederlandse overheidsorganisaties die gevoelige of geclassificeerde gegevens verwerken, kan het ontbreken van technische controls resulteren in bestuurlijke verantwoordelijkheid, reputatieschade en mogelijke sancties van toezichthouders. Bovendien verlangen normenkaders zoals de BIO-paragraaf 08.03.01, ISO 27001 control A.5.30 en NIS2 artikel 21 dat organisaties aantoonbaar kunnen beheersen waar gegevens worden verwerkt en opgeslagen. Zonder concrete technische maatregelen zoals Azure Policies, resource locks en geautomatiseerde monitoring blijft data residency een theoretisch concept zonder praktische afdwinging.

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

Implementatie

Dit artikel beschrijft hoe Nederlandse publieke organisaties data residency controls implementeren binnen Azure-omgevingen. We beginnen met de uitleg van het concept en de relatie met compliance-eisen, gevolgd door architectuurprincipes voor regionale beheersing. Vervolgens gaan we in op praktische implementatiestappen, zoals het configureren van Azure Policies die alleen goedgekeurde regio's toestaan, het instellen van resource locks om onbedoelde wijzigingen te voorkomen en het opzetten van geautomatiseerde monitoring. In de secties over governance en remediatie laten we zien hoe je met behulp van een PowerShell-script periodiek kunt toetsen of resources voldoen aan de data residency-eisen en hoe je bevindingen vertaalt naar verbeteracties. Het doel is een praktisch toepasbaar raamwerk dat technische teams, CISO's en auditors in staat stelt om data residency niet alleen te definiëren, maar ook technisch af te dwingen en continu te monitoren.

Concept en compliance-vereisten voor data residency

Data residency verwijst naar de fysieke of logische locatie waar gegevens worden opgeslagen en verwerkt. Voor Nederlandse overheidsorganisaties is dit concept cruciaal omdat verschillende datacategorieën verschillende juridische en compliance-eisen met zich meebrengen. Persoonsgegevens die onder de AVG vallen, moeten bijvoorbeeld voldoen aan doorgiftebepalingen wanneer zij buiten de Europese Economische Ruimte worden verwerkt. Geclassificeerde informatie volgens de BIO moet bovendien voldoen aan specifieke eisen rond opslaglocatie en toegangsbeveiliging. NIS2 verlangt daarnaast dat essentiële en belangrijke entiteiten aantoonbaar kunnen rapporteren over datalocaties en de risico's die daarmee samenhangen. Data residency controls zijn de technische en beleidsmatige maatregelen die organisaties inzetten om te garanderen dat gegevens daadwerkelijk in de beoogde regio's worden opgeslagen en verwerkt, en dat afwijkingen worden gedetecteerd en gecorrigeerd.

Vanuit AVG-perspectief raken data residency controls vooral de bepalingen rond doorgifte van persoonsgegevens aan derde landen (artikelen 44-49). Wanneer organisaties kunnen aantonen dat persoonsgegevens binnen de EER blijven, vermindert dat de noodzaak om complexe doorgiftegrondslagen te onderbouwen, zoals standaard contractbepalingen of adequacy decisions. Tegelijkertijd blijven andere verplichtingen onverkort gelden: passende technische en organisatorische maatregelen (artikel 32), transparantie richting betrokkenen en heldere verwerkersovereenkomsten. De BIO benadrukt daarnaast beheersing van uitbesteding en contractmanagement: overheidsorganisaties moeten kunnen laten zien welke cloudleverancier welke data verwerkt, in welke regio's dat gebeurt en welke garanties er zijn rond continuïteit en beveiliging. Voor aanbieders die onder NIS2 vallen, speelt daarbovenop de eis om risico's in de toeleveringsketen systematisch te beoordelen en te documenteren. Data residency controls kunnen daarbij een belangrijke mitigerende maatregel zijn, maar alleen als de feitelijke configuratie van Azure-resources aantoonbaar in lijn is met de verwachtingen.

Een veelvoorkomend misverstand is dat data residency automatisch wordt gegarandeerd zodra een organisatie een tenant in een Europese regio gebruikt. In werkelijkheid kunnen resources onbedoeld worden uitgerold in andere regio's, kunnen replicaties plaatsvinden naar niet-goedgekeurde locaties of kunnen bepaalde diensten per definitie wereldwijd opereren. Dit vraagt om een volwassen aanpak waarin data residency expliciet wordt gedefinieerd, technisch wordt afgedwongen via policies en continu wordt gemonitord. Door architectuurprincipes te vertalen naar concrete Azure Policies, resource locks en geautomatiseerde controles, ontstaat een sluitende keten van preventie, detectie en correctie. Dit artikel helpt organisaties om die vertaalslag gestructureerd te maken en te verankeren in de bredere cloudstrategie en compliance-aanpak.

Architectuurprincipes voor data residency controls

Een effectieve implementatie van data residency controls begint bij heldere architectuurprincipes die richting geven aan regioselectie, policy-configuratie en workloadplaatsing. Het eerste principe is 'regionale whitelisting': nieuwe Azure-resources mogen uitsluitend worden uitgerold in vooraf goedgekeurde regio's die voldoen aan de compliance-eisen van de organisatie. Deze lijst wordt vastgelegd in Azure Policies en wordt automatisch gecontroleerd bij elke resource deployment. Het tweede principe is 'dataclassificatie-driven controls': verschillende datacategorieën krijgen verschillende regionale restricties. Geclassificeerde informatie kan bijvoorbeeld alleen in specifieke EU-regio's worden opgeslagen, terwijl publieke data mogelijk in bredere regio's mag worden verwerkt. Het derde principe is 'defense in depth': data residency wordt niet alleen afgedwongen via policies, maar ook via resource locks, monitoring en governance-processen die ervoor zorgen dat afwijkingen snel worden gedetecteerd en gecorrigeerd.

Binnen Azure vertaalt dit zich naar een architectuur waarin management groups, subscriptions en resource groups zijn ontworpen met data residency in het achterhoofd. Productie-omgevingen met gevoelige of geclassificeerde data worden geconcentreerd in een beperkt aantal goedgekeurde regio's, terwijl experimentele of minder gevoelige workloads eventueel in breder toegestane regio's kunnen draaien, mits goed gedocumenteerd. Door standaard deployment-templates en Infrastructure as Code (bijvoorbeeld Bicep of Terraform) te gebruiken, kan de regioselectie worden vastgelegd en geborgd in code, in plaats van overgelaten aan handmatige keuzes in de portal. Azure Policies worden ingezet om te voorkomen dat resources in niet-goedgekeurde regio's worden uitgerold, met automatische afwijzing van deployments die niet voldoen aan de regionale eisen.

Architectuurprincipes moeten bovendien worden verankerd in governance: besluitvormingsstructuren, richtlijnen en standaarddocumentatie. Dat betekent dat elk nieuw cloudproject een expliciete data residency-paragraaf in zijn architectuurdossier krijgt, waarin wordt beschreven welke regio's worden gebruikt, welke datacategorieën worden verwerkt en welke uitzonderingen worden aangevraagd. Deze informatie wordt hergebruikt in DPIA's, NIS2-risicobeoordelingen en contractdossiers. Door de gekozen principes te koppelen aan meetbare criteria – bijvoorbeeld een maximaal percentage resources buiten goedgekeurde regio's of een verplichte lijst van toegestane regio's – ontstaat een basis voor geautomatiseerde controles. Het bijbehorende PowerShell-script, zoals in dit artikel beschreven, kan deze architectuurprincipes vervolgens toetsen tegen de werkelijkheid door te analyseren in welke regio's Azure-resources daadwerkelijk draaien en of deze voldoen aan de gedefinieerde data residency-eisen.

Implementatie van data residency controls in Azure

Gebruik PowerShell-script data-residency-controls.ps1 (functie Invoke-Implementation) – Gebruik dit PowerShell-script om Azure Policies voor data residency te configureren, toegestane regio's te definiëren en resource locks in te stellen voor kritieke workloads..

De implementatie van data residency controls start met het definiëren van de toegestane regio's per dataclassificatie. Voor Nederlandse overheidsorganisaties betekent dit meestal dat gevoelige en geclassificeerde data uitsluitend in EU-regio's mogen worden opgeslagen, terwijl minder gevoelige data mogelijk in bredere regio's mag worden verwerkt. Deze lijst wordt vastgelegd in een centrale configuratie die wordt gebruikt voor Azure Policies, deployment-templates en monitoring. Vervolgens worden Azure Policies geconfigureerd die automatisch controleren of nieuwe resources voldoen aan de regionale eisen en deployments afwijzen die niet voldoen aan de gedefinieerde restricties.

  1. Definieer een centrale lijst van toegestane regio's per dataclassificatie en leg deze vast in een configuratiebestand of Azure Key Vault zodat deze consistent kan worden gebruikt voor policies, templates en monitoring. Documenteer per regio waarom deze is goedgekeurd en welke compliance-eisen deze regio ondersteunt.
  2. Configureer Azure Policies op management group-niveau die automatisch controleren of nieuwe resources worden uitgerold in toegestane regio's. Gebruik de ingebouwde policy 'Allowed locations' of maak aangepaste policies die specifieke regio's per resource type of dataclassificatie afdwingen.
  3. Stel resource locks in voor kritieke workloads om te voorkomen dat resources onbedoeld worden verplaatst of verwijderd. Gebruik CanNotDelete-locks voor productie-omgevingen en ReadOnly-locks voor resources die niet mogen worden gewijzigd zonder expliciete goedkeuring.
  4. Integreer data residency controls in deployment-pipelines door Infrastructure as Code-templates te configureren die standaard alleen goedgekeurde regio's gebruiken. Valideer tijdens de build-fase of deployments voldoen aan de regionale eisen voordat deze worden uitgerold.
  5. Documenteer uitzonderingen en mitigerende maatregelen wanneer resources om functionele redenen in niet-goedgekeurde regio's moeten draaien. Leg vast welke compenserende maatregelen zijn getroffen, wie de uitzondering heeft goedgekeurd en wanneer deze wordt herzien.

Een cruciaal onderdeel van de implementatie is communicatie en documentatie. Bestuurders, CISO's en privacy officers moeten helder inzicht krijgen in welke data residency controls zijn geïmplementeerd, welke regio's zijn goedgekeurd en welke uitzonderingen bestaan. Dit vraagt om begrijpelijke overzichten, bijvoorbeeld in de vorm van managementsamenvattingen waarin per workload is aangegeven welke regio's worden gebruikt en of deze voldoen aan de compliance-eisen. Tegelijkertijd moeten technische teams beschikken over gedetailleerde instructies en referentie-implementaties. Het in dit artikel beschreven PowerShell-script sluit daarop aan door beheerders een herhaalbare manier te geven om data residency controls te configureren en te monitoren, zowel in een veilige lokaal-debugmodus als in productieomgevingen. De uitkomsten kunnen worden gebruikt om compliance te toetsen, afwijkingen te detecteren en rapportages richting bestuur en auditors te onderbouwen.

Monitoring van data residency controls

Gebruik PowerShell-script data-residency-controls.ps1 (functie Invoke-Monitoring) – Voert een periodieke controle uit op Azure-resources en rapporteert of deze voldoen aan de gedefinieerde data residency-eisen, met ondersteuning voor een lokale debugmodus zonder cloudverbinding..

Monitoring van data residency controls kan niet worden beperkt tot eenmalige configuratiecontroles. Nieuwe projecten, uitbreidingen en wijzigingen in de Azure-omgeving kunnen ertoe leiden dat resources alsnog buiten de beoogde regio's worden uitgerold, ondanks de ingestelde policies. Een volwassen monitoringaanpak combineert daarom geautomatiseerde controles met vaste rapportagemomenten. Voor Azure betekent dit dat er periodiek – bijvoorbeeld maandelijks of per kwartaal – een inventarisatie wordt uitgevoerd van resources per subscription, inclusief hun regio en dataclassificatie. Op basis daarvan kan worden vastgesteld welk percentage van de resources voldoet aan de data residency-eisen en waar uitzonderingen of afwijkingen optreden. Deze informatie wordt geaggregeerd naar een overzicht voor CISO en CIO, waarin bijvoorbeeld staat hoeveel subscriptions volledig compliant zijn en hoeveel resources nog moeten worden gecorrigeerd.

  1. Controleer maandelijks in Azure Policy compliance-rapporten of alle resources voldoen aan de gedefinieerde regionale restricties en onderzoek afwijkingen direct zodat data residency-eisen aantoonbaar worden nageleefd. Registreer elke bevinding in het ITSM-systeem en sluit deze pas wanneer de volgende run bewezen succesvol is uitgevoerd.
  2. Stel waarschuwingen in via Azure Monitor en e-mail zodat de piketdienst onmiddellijk een melding ontvangt bij resources die in niet-goedgekeurde regio's worden uitgerold, ondanks de ingestelde policies. Test de meldingen maandelijks door een gecontroleerde deployment te simuleren en verifieer dat alle communicatiestromen werken.
  3. Gebruik wekelijks het overzicht van Azure Resource Graph of een geautomatiseerd PowerShell-rapport om te bevestigen dat iedere productie-resource daadwerkelijk in een goedgekeurde regio draait en corrigeer afwijkingen voordat nieuwe releases live gaan. Combineer dit met Azure Policy compliance-data zodat ook policy-afwijkingen zichtbaar worden.
  4. Controleer kwartaalgewijs of resource locks nog actief zijn voor kritieke workloads en of deze locks correct zijn geconfigureerd zodat onbedoelde wijzigingen worden voorkomen. Documenteer eventuele wijzigingen inclusief goedkeuring en zorg dat de CISO deze aftekent.
  5. Monitor het aantal en type uitzonderingen op data residency-eisen en vergelijk dit met begrotingen; significante groei kan wijzen op onduidelijke richtlijnen of onvoldoende afdwinging en moet daarom direct worden besproken met architectuur en compliance. Visualiseer trends in Power BI zodat besluitvorming over policy-aanpassingen wordt ondersteund.
  6. Plan ieder kwartaal een integraal compliance-scenario waarbij data residency controls worden getest, inclusief policy-afdwinging, monitoring en remediatie; leg bevindingen vast en voer verbeteringen direct door in beleid en scripts. Betrek naast IT ook proceseigenaren, privacy officers en auditors om de volledige keten te oefenen.
  7. Gebruik Azure Policy compliance-rapporten en Microsoft Defender for Cloud-aanbevelingen om realtime te meten of nieuwe of gewijzigde resources voldoen aan de verplichte data residency-standaard en lever rapportages aan het auditteam. Koppel deze inzichten aan het risicoregister en bespreek structurele afwijkingen in het beveiligingsoverleg.

Governance, remediatie en continue verbetering

Gebruik PowerShell-script data-residency-controls.ps1 (functie Invoke-Remediation) – Ondersteunt beheerders bij het interpreteren van monitoringsresultaten en geeft gerichte aanbevelingen voor remediatie, inclusief voorbeeldcmdlets voor het verplaatsen van resources naar goedgekeurde regio's..

Wanneer monitoring laat zien dat een deel van de Azure-resources niet voldoet aan de data residency-eisen, is een gestructureerde remediatieaanpak noodzakelijk. In plaats van ad-hoc migraties of losse wijzigingen in de portal, wordt eerst een analyse gemaakt van patronen: welke subscriptions of projecten wijken structureel af, welke typen resources worden het vaakst in niet-goedgekeurde regio's uitgerold en welke bedrijfsonderdelen zijn daarbij betrokken? Op basis hiervan kan de organisatie prioriteiten stellen: kritieke workloads met gevoelige gegevens gaan voor, gevolgd door omgevingen met lagere impact. Voor elke prioritaire afwijking wordt een concreet verbeterplan opgesteld, met maatregelen zoals het aanpassen van deployment-templates, het versterken van Azure Policies of het plannen van geordende resource-migraties naar goedgekeurde regio's.

Governance richt zich er vervolgens op om herhaling te voorkomen en lessen te verankeren in beleid en werkwijze. Als blijkt dat ontwikkelteams structureel resources in niet-toegestane regio's uitrollen, is dat vaak een symptoom van onduidelijke richtlijnen, onvoldoende standaardisatie in deployment-sjablonen of te ruime selfservice-mogelijkheden. Door architectuurprincipes te vertalen naar harde beleidsregels, goedgekeurde blauwdrukken en technische guardrails (zoals policies en role-based access control), wordt de kans op nieuwe afwijkingen verkleind. Het PowerShell-script speelt hierbij een ondersteunende rol: het voert geen automatische remediatie uit, maar presenteert de monitoringsresultaten in een vorm die eenvoudig in governance-overleggen, rapportages en GRC-systemen kan worden gebruikt. Door bevindingen, beslissingen en uitgevoerde maatregelen systematisch vast te leggen, kunnen organisaties richting auditors en toezichthouders aantonen dat zij niet alleen data residency definiëren, maar ook actief sturen op naleving en continue 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
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Controle op data residency controls voor Azure-resources .DESCRIPTION Voert een controle uit op: - Of Azure Policies voor data residency zijn geconfigureerd - In welke Azure-regio's resources zijn uitgerold - Of resources voldoen aan gedefinieerde regionale restricties - Of resource locks zijn geconfigureerd voor kritieke workloads Het script ondersteunt twee gebruiksscenario's: - Productie: verbinding met Azure om daadwerkelijke configuratie en resources op te halen - Lokale debugmodus: synthetische testdata genereren zonder cloudverbinding Dit script sluit inhoudelijk aan op het artikel 'Data Residency Controls voor Azure Workloads'. .NOTES Filename: data-residency-controls.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/compliance/data-residency-controls.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources, Az.PolicyInsights [CmdletBinding()] param( [Parameter(HelpMessage = "Monitor current configuration status")] [switch]$Monitoring, [Parameter(HelpMessage = "Apply recommended configuration")] [switch]$Remediation, [Parameter(HelpMessage = "Show what would happen without making changes")] [switch]$WhatIf, [Parameter(HelpMessage = "Enable debug mode with synthetic test data")] [switch]$DebugMode ) $ErrorActionPreference = 'Stop' $PolicyName = "Data Residency Controls - Azure" function Get-AllowedRegions { <# .SYNOPSIS Geeft de lijst met geaccepteerde regio's voor data residency terug #> [CmdletBinding()] param() return @( "westeurope", "northeurope", "germanywestcentral", "germanynorth", "norwayeast", "norwaywest", "swedencentral", "swedensouth", "uksouth", "ukwest", "francecentral", "francesouth", "switzerlandnorth", "switzerlandwest", "italynorth", "spaincentral", "polandcentral" ) } function Connect-RequiredServices { [CmdletBinding()] param( [switch]$DebugMode ) if ($DebugMode) { Write-Verbose "DebugMode is ingeschakeld: er wordt geen verbinding met Azure gemaakt." return } if (-not (Get-AzContext -ErrorAction SilentlyContinue)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Test-DataResidencyControls { <# .SYNOPSIS Controleert data residency controls en rapporteert compliance-status .OUTPUTS PSCustomObject met policy status, resource compliance en locks status #> [CmdletBinding()] param( [switch]$DebugMode ) $allowedRegions = Get-AllowedRegions if ($DebugMode) { # Synthetische testdata voor lokale validatie zonder cloudverbinding return [PSCustomObject]@{ Mode = "Debug" PoliciesConfigured = $true TotalSubscriptions = 2 TotalResources = 150 ResourcesInAllowedRegions = 140 ResourcesOutsideAllowedRegions = 10 CompliancePercentage = [math]::Round((140 / 150) * 100, 1) ResourceLocksConfigured = $true LocksCount = 25 IsCompliant = $false DetectedRegions = @("westeurope", "northeurope", "eastus", "westus") } } # Controleer Azure Policies voor data residency $policiesConfigured = $false try { $locationPolicies = Get-AzPolicyDefinition -ErrorAction SilentlyContinue | Where-Object { $_.Properties.DisplayName -like "*allowed locations*" -or $_.Properties.DisplayName -like "*allowed regions*" } if ($locationPolicies) { $policiesConfigured = $true } } catch { Write-Verbose "Kon policies niet ophalen: $_" } # Haal subscriptions en resources op $subscriptions = Get-AzSubscription -ErrorAction Stop | Where-Object { $_.State -eq 'Enabled' } $totalResources = 0 $resourcesInAllowedRegions = 0 $resourcesOutsideAllowedRegions = 0 $regions = [System.Collections.Generic.HashSet[string]]::new([System.StringComparer]::OrdinalIgnoreCase) $locksCount = 0 foreach ($sub in $subscriptions) { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null try { # Controleer resource locks $locks = Get-AzResourceLock -ErrorAction SilentlyContinue $locksCount += $locks.Count # Haal resources op $resources = Get-AzResource -ErrorAction SilentlyContinue if ($resources) { foreach ($r in $resources) { if (-not $r.Location) { continue } $totalResources++ $null = $regions.Add($r.Location.ToLowerInvariant()) if ($allowedRegions -contains $r.Location.ToLowerInvariant()) { $resourcesInAllowedRegions++ } else { $resourcesOutsideAllowedRegions++ } } } } catch { Write-Verbose "Kon resources voor subscription '$($sub.Name)' niet ophalen: $_" } } $compliancePercentage = $null if ($totalResources -gt 0) { $compliancePercentage = [math]::Round(($resourcesInAllowedRegions / $totalResources) * 100, 1) } $isCompliant = ($policiesConfigured -and $resourcesOutsideAllowedRegions -eq 0) [PSCustomObject]@{ Mode = "Live" PoliciesConfigured = $policiesConfigured TotalSubscriptions = $subscriptions.Count TotalResources = $totalResources ResourcesInAllowedRegions = $resourcesInAllowedRegions ResourcesOutsideAllowedRegions = $resourcesOutsideAllowedRegions CompliancePercentage = $compliancePercentage ResourceLocksConfigured = ($locksCount -gt 0) LocksCount = $locksCount IsCompliant = $isCompliant DetectedRegions = @($regions) | Sort-Object } } function Test-Compliance { <# .SYNOPSIS Wrapper function die compliance-status test .OUTPUTS Returns monitoring result object with isCompliant property #> [CmdletBinding()] param( [switch]$DebugMode ) $result = Test-DataResidencyControls -DebugMode:$DebugMode return [PSCustomObject]@{ isCompliant = $result.IsCompliant details = $result } } function Invoke-Monitoring { <# .SYNOPSIS Monitors and reports current data residency controls status .DESCRIPTION Checks current configuration against data residency requirements. Reports compliance status and identifies non-compliant settings. .OUTPUTS Returns hashtable with: - isCompliant: Boolean indicating overall compliance - details: Detailed findings #> [CmdletBinding()] param( [switch]$DebugMode ) try { Write-Host "`nMonitoring:" -ForegroundColor Yellow Connect-RequiredServices -DebugMode:$DebugMode Write-Host "Checking data residency controls..." -ForegroundColor Gray $result = Test-DataResidencyControls -DebugMode:$DebugMode Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Modus : {0}" -f $result.Mode) -ForegroundColor White Write-Host ("Policies geconfigureerd : {0}" -f $(if ($result.PoliciesConfigured) { "Ja" } else { "Nee" })) -ForegroundColor $(if ($result.PoliciesConfigured) { 'Green' } else { 'Yellow' }) Write-Host ("Subscripties : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Totaal aantal resources : {0}" -f $result.TotalResources) -ForegroundColor White Write-Host ("Resources in toegestane regio's : {0}" -f $result.ResourcesInAllowedRegions) -ForegroundColor White Write-Host ("Resources buiten toegestane regio's : {0}" -f $result.ResourcesOutsideAllowedRegions) -ForegroundColor $(if ($result.ResourcesOutsideAllowedRegions -eq 0) { 'Green' } else { 'Yellow' }) if ($null -ne $result.CompliancePercentage) { Write-Host ("Compliance percentage : {0}%" -f $result.CompliancePercentage) -ForegroundColor $(if ($result.CompliancePercentage -ge 100) { 'Green' } else { 'Yellow' }) } else { Write-Host "Compliance percentage : n.v.t. (geen resources gevonden)" -ForegroundColor Yellow } Write-Host ("Resource locks geconfigureerd : {0}" -f $(if ($result.ResourceLocksConfigured) { "Ja ($($result.LocksCount) locks)" } else { "Nee" })) -ForegroundColor $(if ($result.ResourceLocksConfigured) { 'Green' } else { 'Yellow' }) if ($result.DetectedRegions -and $result.DetectedRegions.Count -gt 0) { Write-Host ("Gedetecteerde regio's : {0}" -f ($result.DetectedRegions -join ", ")) -ForegroundColor White } Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host "SUMMARY:" -ForegroundColor Cyan if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green Write-Host "Alle data residency controls zijn correct geconfigureerd." -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red if (-not $result.PoliciesConfigured) { Write-Host " - Azure Policies voor data residency zijn niet geconfigureerd" -ForegroundColor Yellow } if ($result.ResourcesOutsideAllowedRegions -gt 0) { Write-Host " - Er zijn $($result.ResourcesOutsideAllowedRegions) resources buiten toegestane regio's" -ForegroundColor Yellow } if (-not $result.ResourceLocksConfigured) { Write-Host " - Resource locks zijn niet geconfigureerd voor kritieke workloads" -ForegroundColor Yellow } } return @{ isCompliant = $result.IsCompliant details = $result timestamp = Get-Date } } catch { Write-Host "`n[FAIL] ERROR during monitoring: $_" -ForegroundColor Red throw } } function Invoke-Remediation { <# .SYNOPSIS Applies recommended data residency controls configuration .DESCRIPTION Implements recommended configuration to meet data residency requirements. Uses native PowerShell cmdlets where possible. .PARAMETER WhatIf Shows what would be changed without making actual changes #> [CmdletBinding(SupportsShouldProcess)] param( [switch]$WhatIf, [switch]$DebugMode ) try { Write-Host "`nRemediation:" -ForegroundColor Yellow if ($DebugMode) { Write-Host "[INFO] DebugMode: geen daadwerkelijke wijzigingen worden uitgevoerd" -ForegroundColor Yellow return } Connect-RequiredServices Write-Host "Applying data residency controls configuration..." -ForegroundColor Gray # Controleer eerst de huidige status $currentStatus = Test-DataResidencyControls if ($currentStatus.IsCompliant) { Write-Host " [OK] Data residency controls zijn al correct geconfigureerd" -ForegroundColor Green return } # Configureer Azure Policy voor toegestane locaties indien nodig if (-not $currentStatus.PoliciesConfigured) { Write-Host "`n[INFO] Azure Policy voor toegestane locaties configureren:" -ForegroundColor Yellow Write-Host " Gebruik de volgende stappen om een policy te configureren:" -ForegroundColor White Write-Host " 1. Navigeer naar Azure Portal > Policy > Definitions" -ForegroundColor White Write-Host " 2. Zoek naar 'Allowed locations' policy" -ForegroundColor White Write-Host " 3. Wijs de policy toe aan management group of subscription" -ForegroundColor White Write-Host " 4. Configureer de lijst van toegestane regio's" -ForegroundColor White if ($PSCmdlet.ShouldProcess("Azure Policy", "Configure allowed locations policy")) { Write-Host " [NOTE] Policy-configuratie vereist handmatige stappen in Azure Portal" -ForegroundColor Yellow } } # Geef aanbevelingen voor resources buiten toegestane regio's if ($currentStatus.ResourcesOutsideAllowedRegions -gt 0) { Write-Host "`n[INFO] Resources buiten toegestane regio's gevonden:" -ForegroundColor Yellow Write-Host " Aantal resources: $($currentStatus.ResourcesOutsideAllowedRegions)" -ForegroundColor White Write-Host " Overweeg de volgende acties:" -ForegroundColor White Write-Host " 1. Identificeer welke resources buiten toegestane regio's draaien" -ForegroundColor White Write-Host " 2. Evalueer of migratie naar toegestane regio's mogelijk is" -ForegroundColor White Write-Host " 3. Documenteer uitzonderingen indien migratie niet mogelijk is" -ForegroundColor White Write-Host " 4. Plan migraties binnen reguliere changeprocessen" -ForegroundColor White } # Configureer resource locks indien nodig if (-not $currentStatus.ResourceLocksConfigured) { Write-Host "`n[INFO] Resource locks configureren voor kritieke workloads:" -ForegroundColor Yellow Write-Host " Gebruik de volgende PowerShell-cmdlets:" -ForegroundColor White Write-Host " New-AzResourceLock -LockName 'DataResidencyLock' -LockLevel CanNotDelete -ResourceGroupName 'RG-Name' -ResourceName 'Resource-Name' -ResourceType 'Microsoft.Storage/storageAccounts'" -ForegroundColor Gray if ($PSCmdlet.ShouldProcess("Resource Locks", "Configure locks for critical workloads")) { Write-Host " [NOTE] Resource locks moeten per resource worden geconfigureerd" -ForegroundColor Yellow } } Write-Host "`n[OK] Remediation-aanbevelingen gepresenteerd" -ForegroundColor Green Write-Host " Voer de bovenstaande stappen uit om data residency controls volledig te implementeren" -ForegroundColor White } catch { Write-Host "`n[FAIL] ERROR during remediation: $_" -ForegroundColor Red throw } } function Invoke-Implementation { <# .SYNOPSIS Implementeert configuratie (delegeert naar remediatie) #> [CmdletBinding()] param( [switch]$WhatIf, [switch]$DebugMode ) Invoke-Remediation -WhatIf:$WhatIf -DebugMode:$DebugMode } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { # Determine which action to perform if ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow Invoke-Remediation -WhatIf -DebugMode:$DebugMode } else { Invoke-Remediation -DebugMode:$DebugMode } } elseif ($Monitoring) { $result = Invoke-Monitoring -DebugMode:$DebugMode # Exit with appropriate code for automation if ($result.isCompliant) { exit 0 # Success - Compliant } else { exit 1 # Warning - Non-compliant } } else { # No parameters - show usage Write-Host "Available parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Check current configuration status" -ForegroundColor Gray Write-Host " -Remediation : Apply recommended configuration" -ForegroundColor Gray Write-Host " -WhatIf : Preview changes without applying" -ForegroundColor Gray Write-Host " -DebugMode : Use synthetic test data (no Azure connection)" -ForegroundColor Gray Write-Host "`nExample: .\data-residency-controls.ps1 -Monitoring" -ForegroundColor Cyan Write-Host "Example: .\data-residency-controls.ps1 -Monitoring -DebugMode" -ForegroundColor Cyan } } catch { Write-Error "Script execution failed: $_" exit 2 # Error } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan } # ============================================================================ # EXIT CODES # ============================================================================ # 0 = Success / Compliant # 1 = Warning / Non-compliant # 2 = Error / Execution failed

Risico zonder implementatie

Risico zonder implementatie
High: Wanneer een organisatie data residency niet technisch afdwingt via policies en monitoring, kunnen resources onbedoeld worden uitgerold in niet-goedgekeurde regio's. Dit vergroot de kans op niet-naleving van AVG-doorgiftebepalingen, kritische bevindingen bij audits en een verlies aan vertrouwen bij burgers, toezichthouders en ketenpartners.

Management Samenvatting

Data residency controls bieden Nederlandse overheidsorganisaties een belangrijke bouwsteen voor compliance, maar alleen als regionale restricties technisch worden afgedwongen via Azure Policies, resource locks en geautomatiseerde monitoring. Door architectuurprincipes vast te leggen, policies te configureren en periodieke controles uit te voeren met een PowerShell-script, ontstaat aantoonbare controle over datalocaties en compliance. Dit artikel geeft technische teams, CISO's en auditors een concreet raamwerk om data residency integraal te verankeren in cloudstrategie, compliance en governance.