💼 Management Samenvatting
Een Azure exit strategie vormt een essentieel onderdeel van volwassen cloud governance voor Nederlandse overheidsorganisaties. Dit index-artikel beschrijft de principes, processen en technische maatregelen die nodig zijn om de mogelijkheid te behouden om workloads, data en diensten te migreren naar alternatieve cloudproviders of terug naar on-premises omgevingen, zonder dat organisaties afhankelijk worden van één enkele leverancier. Een goed doordachte exit strategie beschermt tegen vendor lock-in, waarborgt dat data altijd toegankelijk en exporteerbaar blijft, en stelt organisaties in staat om flexibel te reageren op veranderende businessvereisten, compliance-eisen of strategische overwegingen.
Aanbeveling
IMPLEMENT
Risico zonder
Medium
Risk Score
6/10
Implementatie
100u (tech: 40u)
Van toepassing op:
✓ Azure
✓ M365
✓ M365
Zonder een doordachte exit strategie lopen Nederlandse overheidsorganisaties het risico om volledig afhankelijk te worden van Microsoft Azure, wat kan leiden tot aanzienlijke operationele en financiële risico's. Vendor lock-in ontstaat wanneer data, applicaties of configuraties zodanig zijn geïntegreerd met Azure-specifieke services dat migratie naar een alternatieve omgeving extreem complex, kostbaar of zelfs onmogelijk wordt. Dit kan organisaties kwetsbaar maken voor prijsverhogingen, wijzigingen in servicevoorwaarden, of situaties waarin compliance-eisen of strategische overwegingen een overstap naar een andere leverancier noodzakelijk maken. Bovendien vereisen verschillende Nederlandse en Europese wet- en regelgevingen, zoals de AVG en de NIS2 richtlijn, dat organisaties kunnen aantonen dat zij controle hebben over hun data en dat deze data toegankelijk en exporteerbaar blijft, ongeacht de gekozen cloudleverancier. Een exit strategie zorgt ervoor dat deze vereisten worden nageleefd en dat organisaties flexibel kunnen blijven in hun keuzes voor cloudleveranciers.
PowerShell Modules Vereist
Primary API: Azure Portal, Azure Resource Manager
Connection:
Required Modules: Az.Accounts, Az.Resources, Az.Storage
Connection:
Connect-AzAccountRequired Modules: Az.Accounts, Az.Resources, Az.Storage
Implementatie
Dit index-artikel positioneert exit strategie binnen de "Nederlandse Baseline voor Veilige Cloud" en beschrijft hoe organisaties een samenhangend exit-strategielandschap kunnen opbouwen. We behandelen fundamentele concepten zoals data portability, vendor-agnostic architecture patterns, export- en migratieprocedures, en laten zien hoe deze worden vertaald naar concrete Azure-configuraties en governance-processen. Het artikel fungeert als kapstok voor meer specifieke artikelen over data export procedures, applicatie-architectuur voor portability, contractuele exit-clausules, en migratieplanning, en beschrijft hoe deze onderdelen samenkomen in een volwassen, flexibele en toekomstbestendige cloudomgeving. Daarnaast biedt het artikel handvatten voor periodieke evaluatie van de exit-readiness en het monitoren van vendor lock-in risico's.
Rol en scope van exit strategie in Azure
Exit strategie in Azure moet worden gezien als een strategisch kader dat technische maatregelen, organisatorische processen en governance met elkaar verbindt tot een samenhangend geheel dat de flexibiliteit en onafhankelijkheid van organisaties waarborgt. In tegenstelling tot ad-hoc implementaties waarbij data en applicaties volledig geïntegreerd worden met Azure-specifieke services zonder rekening te houden met toekomstige migratiemogelijkheden, vormt een doordachte exit strategie de ruggengraat die ervoor zorgt dat alle componenten – van dataopslag tot applicatielogica, van identiteitsbeheer tot netwerkconfiguratie – op een manier worden geïmplementeerd die migratie naar alternatieve omgevingen mogelijk maakt. Deze strategie moet expliciet rekening houden met de specifieke eisen die gelden voor Nederlandse overheidsorganisaties, waaronder de Baseline Informatiebeveiliging Overheid (BIO), de NIS2 richtlijn, de Algemene Verordening Gegevensbescherming (AVG) en sectorale wetgeving die vereist dat organisaties controle behouden over hun data en systemen.
De primaire rol van exit strategie in Azure is het waarborgen van een flexibele, onafhankelijke en toekomstbestendige cloudomgeving waarin organisaties hun digitale dienstverlening kunnen uitvoeren zonder onnodige afhankelijkheid van één enkele leverancier. Dit betekent dat architectuurkeuzes niet alleen technisch correct moeten zijn, maar ook moeten bijdragen aan de mogelijkheid om in de toekomst te migreren naar alternatieve oplossingen wanneer dat nodig is. Een goed ontworpen exit strategie maakt het mogelijk om te bewijzen dat passende maatregelen zijn genomen om vendor lock-in te voorkomen, dat data altijd toegankelijk en exporteerbaar blijft, en dat de organisatie in staat is om flexibel te reageren op veranderende omstandigheden. Voor auditors, toezichthouders en bestuurders biedt een gedocumenteerde exit strategie transparantie over hoe flexibiliteit en onafhankelijkheid zijn ingericht en hoe deze worden onderhouden en geëvalueerd.
De scope van exit strategie in Azure binnen de Nederlandse Baseline voor Veilige Cloud omvat alle lagen van de cloudstack: van dataopslag en databases tot applicaties en API's, van identiteits- en toegangsbeheer tot monitoring en logging, van netwerkconfiguratie tot security policies. Het exit-strategielandschap moet rekening houden met verschillende workload-typen – van Infrastructure as a Service (IaaS) virtuele machines tot Platform as a Service (PaaS) applicaties en Software as a Service (SaaS) integraties – en moet schaalbaar zijn van kleine pilots tot enterprise-omgevingen die duizenden gebruikers en honderden applicaties ondersteunen. Daarnaast moet de strategie flexibel genoeg zijn om te kunnen evolueren met nieuwe Azure-services en veranderende businessvereisten, terwijl de fundamentele principes van data portability en vendor-agnostic architecture consistent blijven.
Implementatieroadmap: van basis naar volwassen exit strategie
De implementatie van een volwassen exit strategie in Azure verloopt zelden in één grote stap, maar groeit geleidelijk van een solide basis naar een geavanceerd, geoptimaliseerd landschap. In de eerste fase wordt de fundamentele basis gelegd: een goed gestructureerde inventarisatie van alle Azure-workloads, data en configuraties, waarbij per component wordt vastgesteld wat de migratiecomplexiteit is en welke afhankelijkheden bestaan met Azure-specifieke services. Voor elk kritisch systeem worden expliciete exit-readiness criteria vastgesteld, bijvoorbeeld dat alle data in standaardformaten moet worden opgeslagen, dat applicaties gebruik moeten maken van open standaarden waar mogelijk, en dat documentatie beschikbaar moet zijn die migratie naar alternatieve omgevingen mogelijk maakt. Deze criteria vormen de harde ontwerpcriteria voor de Azure-architectuur en voorkomen dat organisaties onbewust vendor lock-in creëren.
Vervolgens wordt per workload bepaald welke exit-strategie passend en haalbaar is. Voor data-intensieve workloads kan dit betekenen dat data wordt opgeslagen in standaardformaten zoals JSON, CSV of SQL-dumps, en dat regelmatige exports worden uitgevoerd naar onafhankelijke opslaglocaties. Voor applicaties kan dit betekenen dat container-gebaseerde architecturen worden gebruikt die draagbaar zijn tussen verschillende cloudproviders, of dat microservices worden ontworpen met open API-standaarden die niet afhankelijk zijn van Azure-specifieke services. Belangrijk is dat de gekozen strategie niet alleen technisch mogelijk, maar ook financieel verantwoord en beheersbaar is, en dat deze aansluit bij de businessvereisten en compliance-eisen van de organisatie.
In de volwassenheidsfase wordt de exit strategie geoptimaliseerd en geautomatiseerd. Geautomatiseerde data export procedures zorgen ervoor dat kritieke data regelmatig wordt geëxporteerd naar onafhankelijke opslaglocaties, zonder dat handmatige interventie nodig is. Infrastructure as Code (IaC) met Azure Resource Manager templates, Bicep of Terraform zorgt voor reproduceerbare, versiebeheerde omgevingen die kunnen worden geconverteerd naar alternatieve cloudproviders. Geautomatiseerde compliance-controles en exit-readiness assessments worden regelmatig uitgevoerd om te verifiëren dat de strategie nog steeds voldoet aan alle vereisten en dat er geen nieuwe vendor lock-in risico's zijn ontstaan. Advanced monitoring, vendor lock-in detection en machine learning-gebaseerde analyse helpen om potentiële afhankelijkheden vroegtijdig te identificeren. Governance wordt volwassen met geautomatiseerde rapportages, dashboards voor bestuurders en geïntegreerde change management processen die exit-readiness als criterium meenemen bij architectuurkeuzes. Door deze fasering expliciet te maken in een roadmap – met duidelijke mijlpalen, beslismomenten en success criteria – ontstaat voorspelbaarheid voor bestuurders en wordt het eenvoudiger om investeringen, risico's en baten te verantwoorden.
Governance, compliance en relatie met andere artikelen
Governance rond exit strategie in Azure raakt meerdere disciplines: enterprise architectuur, informatiebeveiliging, cloud governance, compliance en risk management. Zonder een helder governance-model ontstaat het risico dat exit-readiness over het hoofd wordt gezien bij architectuurkeuzes, dat verschillende teams verschillende standaarden hanteren voor data portability, en dat niemand zich eigenaar voelt van de integrale exit strategie. Een effectief governance-model benoemt daarom ten minste een enterprise architect die verantwoordelijk is voor de overkoepelende architectuurvisie inclusief exit-readiness, een cloud architect die de technische Azure-architectuur beheert met aandacht voor vendor-agnostic patterns, een security architect die beveiligingsaspecten waarborgt zonder onnodige Azure-specifieke afhankelijkheden, en expliciete rollen voor CISO, privacy officer en compliance officer. Deze rollen worden vertaald naar concrete taken: wie keurt nieuwe architectuurpatronen goed met oog op exit-readiness, wie beoordeelt afwijkingen van standaarden, wie beheert de exit-strategiedocumentatie, en wie beslist over het accepteren van Azure-specifieke services wanneer dat nodig is.
Op compliancegebied vormt exit strategie in Azure een kruispunt van verschillende wettelijke kaders. De AVG vereist dat persoonsgegevens toegankelijk en exporteerbaar blijven, wat direct raakt aan exit strategie. De BIO en NIS2 leggen eisen op rond informatiebeveiliging en risicobeheer, waarbij vendor lock-in als een significant risico moet worden beschouwd. ISO 27001 biedt een internationaal erkend framework voor informatiebeveiligingsmanagement dat ook aandacht besteedt aan leveranciersafhankelijkheid. Deze compliance-vereisten moeten expliciet worden vertaald naar exit-strategiekeuzes: welke data export procedures worden gebruikt, hoe wordt toegang gecontroleerd, hoe worden logs bewaard, en hoe wordt exit-readiness geëvalueerd. Dit index-artikel moet daarom expliciet worden gelezen in samenhang met andere artikelen binnen de "Nederlandse Baseline voor Veilige Cloud", zoals de artikelen over data portability, vendor-agnostic architecture patterns, Azure data export procedures en migratieplanning. Samen vormen zij een consistent raamwerk: dit artikel schetst de overkoepelende lijnen, terwijl de deelartikelen verdieping bieden op specifieke exit-strategiepatronen en technische implementaties.
Voor auditors en toezichthouders is vooral van belang dat de samenhang tussen beleid, architectuur, implementatie en operationele controles aantoonbaar is. Dat betekent dat u niet alleen architectuurdiagrammen en procesbeschrijvingen beschikbaar heeft, maar ook concreet kunt laten zien welke Azure-resources er zijn, hoe deze zijn geconfigureerd met oog op exit-readiness, hoe vaak exit-readiness assessments worden uitgevoerd en welke verbeteracties zijn ondernomen na bevindingen. De in dit domein beschreven PowerShell-scripts – waaronder het index-script bij dit artikel en de scripts voor specifieke exit-strategiecomponenten – helpen om deze informatie snel en reproduceerbaar te verzamelen. Door hun output te koppelen aan dashboards en rapportages wordt governance niet beperkt tot papieren documenten, maar ondersteund door actuele operationele data die aantoonbaar maakt dat de exit strategie daadwerkelijk wordt nageleefd en onderhouden.
Monitoring van het exit strategie landschap
Gebruik PowerShell-script index.ps1 (functie Invoke-Monitoring) – Geeft een overzicht van de belangrijkste Azure exit strategie componenten en controleert of basiselementen aanwezig en correct geconfigureerd zijn..
Monitoring van het Azure exit strategie landschap gaat verder dan het bewaken van individuele resources. Bestuurders, enterprise architects en security teams hebben behoefte aan een samenvattend beeld: welke workloads zijn exit-ready, welke data wordt regelmatig geëxporteerd, welke Azure-specifieke services worden gebruikt die vendor lock-in kunnen veroorzaken, en zijn er signalen dat de exit strategie niet meer voldoet aan compliance-vereisten. Het index-script bij dit artikel inventariseert de belangrijkste exit-strategiecomponenten en vertaalt die naar een compacte managementsamenvatting: hoeveel workloads zijn exit-ready, hoeveel data export procedures zijn actief, welke workloads gebruiken Azure-specifieke services, en voor welke onderdelen aanvullende acties nodig zijn. Dit vormt een startpunt voor diepgaandere analyses met gespecialiseerde scripts voor specifieke exit-strategiecomponenten, en helpt om het gesprek met bestuur en auditcommissies te structureren rond feitelijke cijfers en meetbare exit-readiness.
Effectieve exit strategie monitoring omvat zowel technische als governance-aspecten. Technisch gezien moet worden gemonitord of resources correct zijn geconfigureerd volgens de exit-readiness standaarden, of data export procedures actief zijn en correct functioneren, en of er afwijkingen zijn die kunnen wijzen op nieuwe vendor lock-in risico's of compliance-problemen. Governance-monitoring richt zich op de vraag of exit-strategieprincipes worden nageleefd, of documentatie actueel is, of change management processen correct worden gevolgd met oog op exit-readiness, en of er regelmatige reviews plaatsvinden om de exit strategie te evalueren en te verbeteren. Door beide aspecten te combineren ontstaat een compleet beeld van de exit-readiness volwassenheid en kunnen gerichte verbeteracties worden ondernomen om de strategie verder te professionaliseren.
Remediatie en volwassenwording van exit strategie
Gebruik PowerShell-script index.ps1 (functie Invoke-Remediation) – Genereert overzichten van exit-strategiehiaten en biedt handvatten voor gerichte verbeteracties om de exit-readiness te verhogen..
Remediatie binnen het Azure exit strategie domein betekent in de praktijk dat u gaten dicht tussen de gewenste exit-readiness en de werkelijkheid. In veel organisaties bestaan al wel beleidsdocumenten over cloudgebruik, informatiebeveiliging en vendor management, maar ontbreekt concrete vastlegging van hoe deze worden vertaald naar Azure-configuraties die exit-readiness waarborgen, welke resources daadwerkelijk exit-ready zijn, en hoe de exit strategie wordt onderhouden en geëvalueerd. Het index-script ondersteunt remediatie door automatisch te inventariseren waar exit-readiness standaarden niet worden nageleefd, waar data export procedures ontbreken, waar Azure-specifieke services worden gebruikt zonder alternatieven, en waar documentatie verouderd of incompleet is. Op basis van deze inventarisatie kunnen gerichte verbeteracties worden gepland en uitgevoerd, waarbij prioriteit wordt gegeven aan de meest kritieke hiaten die de grootste impact hebben op flexibiliteit en compliance.
Een volwassen exit strategie in Azure groeit stap voor stap door continue verbetering. Na elke monitoringsronde worden de belangrijkste verbeterpunten vastgelegd, van een eigenaar voorzien en ingepland in het reguliere change- of verbeterportfolio. Denk aan het standaardiseren van data export procedures, het implementeren van ontbrekende export- en migratieprocessen, het verbeteren van vendor-agnostic architecture patterns, het actualiseren van exit-strategiedocumentatie of het invoeren van geautomatiseerde exit-readiness controles. Door de resultaten van het index-script te combineren met de uitkomsten van gespecialiseerde scripts voor specifieke exit-strategiecomponenten ontstaat een integraal beeld van de voortgang. Uiteindelijk wordt exit strategie in Azure zo niet alleen een technisch ontwerp, maar een aantoonbaar beheerst en verantwoord ingericht fundament voor de digitale dienstverlening van de organisatie, dat continu wordt geëvalueerd en verbeterd om te blijven voldoen aan veranderende eisen en omstandigheden.
Compliance & Frameworks
- BIO: 05.01.01, 08.03.01 - Informatiebeveiligingsbeleid en continuïteitsbeheer met aandacht voor leveranciersafhankelijkheid en exit-readiness binnen informatiebeveiligingsmanagement voor overheidsorganisaties.
- ISO 27001:2022: A.5.1.1, A.15.2.1 - Beleidsregels voor informatiebeveiliging en leveranciersrelaties met aandacht voor vendor lock-in risico's en exit strategie.
- NIS2: Artikel - Versterking van digitale weerbaarheid door gecontroleerde inzet van exit strategie maatregelen, inclusief governance, monitoring en risicobeheer rond leveranciersafhankelijkheid.
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
Azure Exit Strategie Overzicht
.DESCRIPTION
Controleert exit strategie configuratie en exit-readiness status voor Azure workloads.
Inventariseert data export procedures, vendor lock-in risico's en exit-readiness van resources.
.NOTES
Filename: index.ps1
Author: Nederlandse Baseline voor Veilige Cloud
Version: 1.0
Related JSON: content/azure/exit-strategy/index.json
#>
#Requires -Version 5.1
#Requires -Modules Az.Accounts, Az.Resources, Az.Storage
[CmdletBinding()]
param(
[Parameter(HelpMessage = "Voer een samenvattende monitoring uit van het Azure exit strategie landschap.")]
[switch]$Monitoring,
[Parameter(HelpMessage = "Genereer remediatie-overzichten en optioneel documentatietemplates.")]
[switch]$Remediation,
[Parameter(HelpMessage = "Toon welke acties zouden worden uitgevoerd zonder daadwerkelijk te wijzigen.")]
[switch]$WhatIf
)
$ErrorActionPreference = 'Stop'
$VerbosePreference = 'Continue'
$PolicyName = "Azure Exit Strategie"
function Get-RepositoryRoot {
<#
.SYNOPSIS
Bepaalt de rootmap van de repository op basis van de locatie van dit script.
.OUTPUTS
String met pad naar repository-root.
#>
[CmdletBinding()]
param()
$root = Resolve-Path (Join-Path $PSScriptRoot "..\..\..") -ErrorAction SilentlyContinue
if (-not $root) {
throw "Kon de repository-root niet bepalen op basis van PSScriptRoot: $PSScriptRoot"
}
return $root.Path
}
function Connect-RequiredServices {
<#
.SYNOPSIS
Controleert en maakt indien nodig verbinding met Azure.
#>
[CmdletBinding()]
param()
if (-not (Get-AzContext)) {
Write-Verbose "Geen actieve Azure-verbinding. Verbinden met Connect-AzAccount..."
Connect-AzAccount | Out-Null
}
else {
$context = Get-AzContext
Write-Verbose "Azure-verbinding actief: $($context.Account.Id) in tenant $($context.Tenant.Id)"
}
}
function Get-AzureExitStrategyInventory {
<#
.SYNOPSIS
Stelt een overzicht op van Azure exit-strategie-gerelateerde JSON- en PS1-bestanden.
.OUTPUTS
PSCustomObject met aantallen en details.
#>
[CmdletBinding()]
param()
$repoRoot = Get-RepositoryRoot
$contentRoot = Join-Path $repoRoot "content\azure\exit-strategy"
$codeRoot = Join-Path $repoRoot "code\azure\exit-strategy"
$jsonFiles = @()
if (Test-Path -Path $contentRoot) {
$jsonFiles = Get-ChildItem -Path $contentRoot -Filter "*.json" -File -ErrorAction SilentlyContinue
}
$ps1Files = @()
if (Test-Path -Path $codeRoot) {
$ps1Files = Get-ChildItem -Path $codeRoot -Filter "*.ps1" -File -ErrorAction SilentlyContinue
}
$byName = @{}
foreach ($json in $jsonFiles) {
$base = [System.IO.Path]::GetFileNameWithoutExtension($json.Name)
if (-not $byName.ContainsKey($base)) {
$byName[$base] = [pscustomobject]@{
Name = $base
JsonPath = $null
JsonUpdated = $null
ScriptPath = $null
ScriptUpdated= $null
}
}
$entry = $byName[$base]
$entry.JsonPath = $json.FullName
$entry.JsonUpdated = $json.LastWriteTime
$byName[$base] = $entry
}
foreach ($ps1 in $ps1Files) {
$base = [System.IO.Path]::GetFileNameWithoutExtension($ps1.Name)
if (-not $byName.ContainsKey($base)) {
$byName[$base] = [pscustomobject]@{
Name = $base
JsonPath = $null
JsonUpdated = $null
ScriptPath = $null
ScriptUpdated= $null
}
}
$entry = $byName[$base]
$entry.ScriptPath = $ps1.FullName
$entry.ScriptUpdated = $ps1.LastWriteTime
$byName[$base] = $entry
}
$items = $byName.Values | Sort-Object Name
$missingJson = $items | Where-Object { -not $_.JsonPath }
$missingScript = $items | Where-Object { -not $_.ScriptPath }
return [pscustomobject]@{
RepositoryRoot = $repoRoot
Items = $items
MissingJson = $missingJson
MissingScripts = $missingScript
TotalControls = $items.Count
WithJsonAndPs1 = ($items | Where-Object { $_.JsonPath -and $_.ScriptPath }).Count
}
}
function Test-AzureConnection {
<#
.SYNOPSIS
Controleert of er een actieve Azure-verbinding bestaat.
.OUTPUTS
Boolean: $true als verbonden, anders $false
#>
[CmdletBinding()]
param()
try {
$context = Get-AzContext -ErrorAction Stop
if ($context) {
Write-Verbose "Azure-verbinding actief: $($context.Account.Id) in tenant $($context.Tenant.Id)"
return $true
}
return $false
}
catch {
Write-Verbose "Geen actieve Azure-verbinding: $_"
return $false
}
}
function Get-AzureExitStrategyStatus {
<#
.SYNOPSIS
Inventariseert de status van belangrijke Azure exit strategie componenten.
.OUTPUTS
PSCustomObject met exit-strategiestatus.
#>
[CmdletBinding()]
param()
$isConnected = Test-AzureConnection
if (-not $isConnected) {
Write-Warning "Geen actieve Azure-verbinding. Alleen repository-inventarisatie wordt uitgevoerd."
return [pscustomobject]@{
AzureConnected = $false
StorageAccounts = 0
RecoveryVaults = 0
Subscriptions = 0
ResourceGroups = 0
}
}
try {
Write-Verbose "Inventariseren van Azure exit strategie componenten..."
$storageAccounts = @()
try {
$storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue
}
catch {
Write-Verbose "Kon storage accounts niet ophalen: $_"
}
$recoveryVaults = @()
try {
$recoveryVaults = Get-AzRecoveryServicesVault -ErrorAction SilentlyContinue
}
catch {
Write-Verbose "Kon Recovery Services-kluizen niet ophalen: $_"
}
$subscriptions = @()
try {
$subscriptions = Get-AzSubscription -ErrorAction SilentlyContinue
}
catch {
Write-Verbose "Kon subscriptions niet ophalen: $_"
}
$resourceGroups = @()
try {
$resourceGroups = Get-AzResourceGroup -ErrorAction SilentlyContinue
}
catch {
Write-Verbose "Kon resource groups niet ophalen: $_"
}
return [pscustomobject]@{
AzureConnected = $true
StorageAccounts = $storageAccounts.Count
RecoveryVaults = $recoveryVaults.Count
Subscriptions = $subscriptions.Count
ResourceGroups = $resourceGroups.Count
}
}
catch {
Write-Warning "Fout bij inventariseren van Azure-componenten: $_"
return [pscustomobject]@{
AzureConnected = $false
StorageAccounts = 0
RecoveryVaults = 0
Subscriptions = 0
ResourceGroups = 0
}
}
}
function Test-Compliance {
<#
.SYNOPSIS
Controleert de compliance status van exit strategie configuratie.
.OUTPUTS
PSCustomObject met compliance resultaten.
#>
[CmdletBinding()]
param()
$inventory = Get-AzureExitStrategyInventory
$azureStatus = Get-AzureExitStrategyStatus
$hasJsonAndScript = ($inventory.WithJsonAndPs1 -gt 0)
$hasAzureResources = ($azureStatus.AzureConnected -and ($azureStatus.StorageAccounts -gt 0 -or $azureStatus.RecoveryVaults -gt 0))
return [pscustomobject]@{
HasJsonAndScript = $hasJsonAndScript
HasAzureResources = $hasAzureResources
TotalControls = $inventory.TotalControls
WithJsonAndPs1 = $inventory.WithJsonAndPs1
AzureStatus = $azureStatus
}
}
function Invoke-Implementation {
<#
.SYNOPSIS
Implementeert de configuratie
#>
[CmdletBinding()]
param()
Write-Host "[INFO] Exit strategie implementatie vereist handmatige configuratie" -ForegroundColor Yellow
Write-Host "[INFO] Zie het bijbehorende JSON-artikel voor implementatie-instructies" -ForegroundColor Cyan
Invoke-Monitoring
}
function Invoke-Monitoring {
<#
.SYNOPSIS
Controleert de huidige configuratie status
#>
[CmdletBinding()]
param()
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "$PolicyName - Monitoring" -ForegroundColor Cyan
Write-Host "========================================" -ForegroundColor Cyan
$inventory = Get-AzureExitStrategyInventory
$azureStatus = Get-AzureExitStrategyStatus
$compliance = Test-Compliance
Write-Host "`nRepository-root: $($inventory.RepositoryRoot)" -ForegroundColor Cyan
Write-Host "Totaal exit strategie controls (JSON/PS1-combinaties): $($inventory.TotalControls)" -ForegroundColor Cyan
Write-Host "Volledig gekoppeld (JSON + PS1): $($inventory.WithJsonAndPs1)" -ForegroundColor Cyan
if ($azureStatus.AzureConnected) {
Write-Host "`nAzure-omgeving status:" -ForegroundColor Cyan
Write-Host " Storage Accounts: $($azureStatus.StorageAccounts)" -ForegroundColor Gray
Write-Host " Recovery Services-kluizen: $($azureStatus.RecoveryVaults)" -ForegroundColor Gray
Write-Host " Subscriptions: $($azureStatus.Subscriptions)" -ForegroundColor Gray
Write-Host " Resource Groups: $($azureStatus.ResourceGroups)" -ForegroundColor Gray
}
else {
Write-Host "`n⚠️ Geen actieve Azure-verbinding. Verbind met Connect-AzAccount voor volledige monitoring." -ForegroundColor Yellow
}
if ($inventory.MissingJson.Count -gt 0) {
Write-Host "`n❌ Ontbrekende JSON voor de volgende scripts:" -ForegroundColor Red
foreach ($item in $inventory.MissingJson) {
Write-Host " - $($item.Name) (script: $($item.ScriptPath))" -ForegroundColor Red
}
}
if ($inventory.MissingScripts.Count -gt 0) {
Write-Host "`n❌ Ontbrekende PS1-scripts voor de volgende JSON-bestanden:" -ForegroundColor Red
foreach ($item in $inventory.MissingScripts) {
Write-Host " - $($item.Name) (json: $($item.JsonPath))" -ForegroundColor Red
}
}
if (($inventory.MissingJson.Count -eq 0) -and ($inventory.MissingScripts.Count -eq 0)) {
Write-Host "`n✅ Alle Azure exit strategie artikelen hebben zowel JSON als PS1." -ForegroundColor Green
}
else {
Write-Host "`n⚠️ Er zijn nog hiaten in de JSON/PS1-koppeling voor Azure exit strategie." -ForegroundColor Yellow
Write-Host " Gebruik -Remediation om gericht met deze hiaten aan de slag te gaan." -ForegroundColor Yellow
}
Write-Host "`n⚠️ Let op: Exit strategie vereist handmatige evaluatie van:" -ForegroundColor Yellow
Write-Host " - Data export procedures en frequenties" -ForegroundColor Gray
Write-Host " - Vendor lock-in risico's per workload" -ForegroundColor Gray
Write-Host " - Exit-readiness status van applicaties" -ForegroundColor Gray
Write-Host " - Contractuele exit-clausules" -ForegroundColor Gray
return [pscustomobject]@{
Inventory = $inventory
AzureStatus = $azureStatus
Compliance = $compliance
}
}
function Invoke-Remediation {
<#
.SYNOPSIS
Herstelt de configuratie naar de gewenste staat
.DESCRIPTION
Genereert overzichten van exit-strategiehiaten en biedt handvatten voor gerichte verbeteracties.
#>
[CmdletBinding()]
param()
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "$PolicyName - Remediatie" -ForegroundColor Cyan
Write-Host "========================================" -ForegroundColor Cyan
$inventory = Get-AzureExitStrategyInventory
$repoRoot = $inventory.RepositoryRoot
Write-Host "`nSamenvatting remediatie-status:" -ForegroundColor Cyan
Write-Host (" Items zonder JSON: {0}" -f $inventory.MissingJson.Count) -ForegroundColor Cyan
Write-Host (" Items zonder script: {0}" -f $inventory.MissingScripts.Count) -ForegroundColor Cyan
Write-Host "`n⚠️ Exit strategie remediatie vereist handmatige actie:" -ForegroundColor Yellow
Write-Host " 1. Evalueer alle workloads op exit-readiness" -ForegroundColor Gray
Write-Host " 2. Implementeer data export procedures waar nodig" -ForegroundColor Gray
Write-Host " 3. Documenteer vendor lock-in risico's per workload" -ForegroundColor Gray
Write-Host " 4. Stel exit-readiness criteria vast en monitor deze" -ForegroundColor Gray
Write-Host " 5. Zorg voor regelmatige exit-readiness assessments" -ForegroundColor Gray
if ($WhatIf) {
Write-Host "`n[WhatIf] Zou exit-strategie documentatie genereren en assessments uitvoeren" -ForegroundColor Yellow
}
return [pscustomobject]@{
Inventory = $inventory
RemediationActions = @(
"Evalueer exit-readiness van alle workloads",
"Implementeer data export procedures",
"Documenteer vendor lock-in risico's",
"Stel exit-readiness criteria vast",
"Plan regelmatige assessments"
)
}
}
try {
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "Azure Exit Strategie Overzichtsmonitor" -ForegroundColor Cyan
Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan
Write-Host "========================================`n" -ForegroundColor Cyan
if ($Monitoring) {
Invoke-Monitoring | Out-Null
}
elseif ($Remediation) {
Invoke-Remediation | Out-Null
}
else {
# Standaard: compacte compliance check via monitoring
$result = Invoke-Monitoring
if (($result.Inventory.MissingJson.Count -eq 0) -and ($result.Inventory.MissingScripts.Count -eq 0)) {
Write-Host "`n✅ COMPLIANT (basis)" -ForegroundColor Green
Write-Host "⚠️ Let op: Exit strategie vereist aanvullende handmatige evaluatie" -ForegroundColor Yellow
}
else {
Write-Host "`n❌ NON-COMPLIANT" -ForegroundColor Red
Write-Host "Run met -Remediation voor een gericht overzicht van hiaten." -ForegroundColor Yellow
}
}
}
catch {
Write-Error "Er is een fout opgetreden in index.ps1: $_"
throw
}
finally {
Write-Host "`n========================================`n" -ForegroundColor Cyan
}
Risico zonder implementatie
Risico zonder implementatie
Medium: Zonder een doordachte exit strategie in Azure ontstaan organisaties die volledig afhankelijk zijn van Microsoft Azure, wat kan leiden tot vendor lock-in, beperkte flexibiliteit bij veranderende businessvereisten of compliance-eisen, en het risico op aanzienlijke kosten of complexiteit bij toekomstige migraties. Dit kan leiden tot niet-naleving van AVG-vereisten rond dataportabiliteit, bestuurlijke aansprakelijkheid bij contractuele wijzigingen, en verlies van strategische flexibiliteit bij keuzes voor cloudleveranciers.
Management Samenvatting
Een doordachte exit strategie in Azure vormt de fundamentele basis voor flexibele, onafhankelijke en toekomstbestendige cloudomgevingen binnen de Nederlandse publieke sector. Dit index-artikel schetst de overkoepelende principes, strategieën en best practices, en fungeert als kapstok voor meer specifieke artikelen over data portability, vendor-agnostic architecture patterns en migratieplanning.
- Implementatietijd: 100 uur
- FTE required: 0.5 FTE