BIO 12.03 ISO A.8.13

Azure Storage: Geo-Redundante Opslag Voor Bedrijfscontinuïteit

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

💼 Management Samenvatting

Geo-redundante opslag is een fundamentele beveiligingsmaatregel die Azure Storage-accounts beschermt tegen regionale uitval, natuurrampen en grootschalige storingen door gegevens automatisch te repliceren naar een secundaire regio op honderden kilometers afstand. Voor Nederlandse overheidsorganisaties is geo-redundantie niet alleen een technische best practice, maar ook een compliance-vereiste die essentieel is voor het waarborgen van bedrijfscontinuïteit en het voldoen aan normen zoals de Baseline Informatiebeveiliging Overheid (BIO) en ISO 27001:2022.

Aanbeveling
IMPLEMENTEER GEO-REDUNDANTIE VOOR ALLE PRODUCTIE-OPSLAGACCOUNTS
Risico zonder
High
Risk Score
9/10
Implementatie
4u (tech: 2u)
Van toepassing op:
✓ Azure Storage
✓ Blob Storage
✓ File Storage
✓ Queue Storage
✓ Table Storage

Zonder geo-redundante opslag lopen organisaties het risico op volledig gegevensverlies bij regionale incidenten zoals datacenteruitval, natuurrampen, cyberaanvallen of grootschalige storingen. Lokaal redundante opslag (LRS) biedt alleen bescherming tegen hardwarefouten binnen één datacenter, maar biedt geen bescherming tegen regionale uitval. Voor productieomgevingen waar gegevensverlies onacceptabel is, is geo-redundantie een absolute vereiste. De Baseline Informatiebeveiliging Overheid (BIO) controle 12.03 vereist expliciet dat organisaties passende maatregelen treffen voor rampherstel en bedrijfscontinuïteit, waarbij geo-redundantie een essentiële component vormt. Bovendien kunnen organisaties zonder geo-redundantie niet voldoen aan ISO 27001:2022 controle A.8.13 over informatieback-ups, wat kan leiden tot compliance-schendingen en mogelijke boetes. Voor Nederlandse overheidsorganisaties die onder de NIS2-richtlijn vallen, is geo-redundantie een belangrijke technische maatregel die bijdraagt aan het voldoen aan de vereisten voor bedrijfscontinuïteit en rampherstel.

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

Implementatie

Dit artikel beschrijft hoe organisaties Azure Storage-accounts kunnen configureren met geo-redundante opslag, specifiek gericht op Geo-Redundant Storage (GRS) en Geo-Zone-Redundant Storage (GZRS). GRS biedt zes kopieën van gegevens: drie kopieën in de primaire regio en drie kopieën in een gekoppelde secundaire regio die zich op honderden kilometers afstand bevindt. GZRS voegt hieraan zone-redundantie toe binnen de primaire regio, wat extra bescherming biedt tegen uitval van beschikbaarheidszones. Het artikel behandelt de technische implementatie, monitoring, compliance-aspecten en best practices voor het beheren van geo-redundante opslagconfiguraties binnen Nederlandse overheidsorganisaties. Het bijbehorende PowerShell-script ondersteunt organisaties bij het monitoren van de redundantieconfiguratie van alle opslagaccounts en het detecteren van niet-compliant configuraties die onmiddellijke aandacht vereisen.

Overzicht en voordelen van geo-redundante opslag

Geo-redundante opslag vormt de basis voor robuuste bedrijfscontinuïteit en disaster recovery binnen Azure Storage-omgevingen. Het concept is gebaseerd op het principe dat gegevens niet alleen lokaal worden beschermd tegen hardwarefouten, maar ook tegen regionale incidenten die een volledig datacenter of zelfs een hele regio kunnen uitschakelen. Azure biedt verschillende redundantieopties, elk met specifieke kenmerken en use cases. Lokaal redundante opslag (LRS) repliceert gegevens drie keer binnen één datacenter en biedt bescherming tegen hardwarefouten, maar geen bescherming tegen regionale uitval. Zone-redundante opslag (ZRS) repliceert gegevens synchroon over drie beschikbaarheidszones binnen één regio, wat bescherming biedt tegen uitval van beschikbaarheidszones, maar nog steeds kwetsbaar is voor regionale incidenten. Geo-redundante opslag (GRS) combineert lokale redundantie met asynchrone replicatie naar een secundaire regio, waardoor zes kopieën van gegevens ontstaan: drie in de primaire regio en drie in de secundaire regio. Geo-zone-redundante opslag (GZRS) combineert zone-redundantie in de primaire regio met asynchrone replicatie naar een secundaire regio, wat de hoogste mate van bescherming biedt tegen zowel zone-uitval als regionale incidenten.

Voor Nederlandse overheidsorganisaties biedt geo-redundantie verschillende kritieke voordelen. Allereerst beschermt het tegen gegevensverlies bij regionale rampen zoals overstromingen, branden, aardbevingen of grootschalige cyberaanvallen die een hele regio kunnen treffen. In Nederland, waar overstromingsrisico's en andere natuurrampen reëel zijn, is geo-redundantie een essentiële maatregel voor het waarborgen van continuïteit van kritieke overheidsdiensten. Ten tweede draagt geo-redundantie bij aan compliance met verschillende normen en regelgevingen. De Baseline Informatiebeveiliging Overheid (BIO) controle 12.03 vereist expliciet dat organisaties passende maatregelen treffen voor rampherstel en bedrijfscontinuïteit. Zonder geo-redundantie kunnen organisaties niet aantonen dat zij voldoen aan deze vereiste. ISO 27001:2022 controle A.8.13 over informatieback-ups vereist dat organisaties regelmatige back-ups maken en testen, waarbij geo-redundantie kan worden beschouwd als een vorm van continue back-up. Voor organisaties die onder de NIS2-richtlijn vallen, is geo-redundantie een belangrijke technische maatregel die bijdraagt aan het voldoen aan de vereisten voor bedrijfscontinuïteit.

Een derde belangrijk voordeel is de verbeterde beschikbaarheid en duurzaamheid van gegevens. Geo-redundantie garandeert een duurzaamheid van 99.99999999999999% (16 negens) voor objecten over een gegeven jaar, wat betekent dat de kans op gegevensverlies extreem laag is. Dit niveau van duurzaamheid is essentieel voor kritieke overheidsgegevens die niet verloren mogen gaan, zoals burgergegevens, belastinginformatie, of historische archieven. Bovendien biedt geo-redundantie de mogelijkheid tot read-access geo-redundantie (RA-GRS), waarbij gegevens in de secundaire regio kunnen worden gelezen, wat kan worden gebruikt voor disaster recovery-scenario's of voor het verbeteren van de prestaties voor gebruikers in de secundaire regio. Voor Nederlandse overheidsorganisaties die diensten moeten blijven leveren, zelfs tijdens regionale incidenten, kan RA-GRS een belangrijke component zijn van de bedrijfscontinuïteitsstrategie.

Technische implementatie en configuratie

De implementatie van geo-redundante opslag begint bij het selecteren van de juiste redundantieoptie tijdens het aanmaken van een Azure Storage-account. Voor productieomgevingen moeten organisaties kiezen tussen Standard_GRS (Geo-Redundant Storage) of Standard_GZRS (Geo-Zone-Redundant Storage), afhankelijk van hun specifieke vereisten voor beschikbaarheid en kosten. GRS is de meest kosteneffectieve optie voor geo-redundantie en verhoogt de opslagkosten met ongeveer vijftig procent ten opzichte van lokaal redundante opslag. GZRS biedt extra bescherming tegen zone-uitval maar is duurder en is alleen beschikbaar voor bepaalde opslagtypen zoals Blob Storage en Data Lake Storage Gen2. Bij het selecteren van een secundaire regio moet rekening worden gehouden met verschillende factoren, waaronder de geografische afstand, de beschikbaarheid van services, en eventuele compliance-vereisten voor gegevenslocatie. Azure selecteert automatisch een gekoppelde secundaire regio op basis van de primaire regio, waarbij wordt gegarandeerd dat de secundaire regio zich op voldoende afstand bevindt om bescherming te bieden tegen regionale incidenten.

Voor bestaande opslagaccounts kan de redundantieconfiguratie worden gewijzigd via de Azure Portal, Azure PowerShell, of de Azure CLI. Het is belangrijk om te begrijpen dat het wijzigen van de redundantieconfiguratie tijd kan kosten, afhankelijk van de hoeveelheid gegevens die moet worden gerepliceerd. Voor grote opslagaccounts met terabytes aan gegevens kan dit proces enkele uren duren. Tijdens de migratie blijft het opslagaccount functioneel, maar zonder de volledige bescherming van geo-redundantie totdat de replicatie is voltooid. Organisaties moeten daarom migraties plannen tijdens perioden met lage werkbelasting en stakeholders informeren over mogelijke impact. Voor nieuwe opslagaccounts moet de juiste redundantieconfiguratie worden geselecteerd tijdens het aanmaken om te voorkomen dat later wijzigingen nodig zijn. Dit kan worden geautomatiseerd via Azure Policy of Infrastructure as Code-templates, waardoor wordt gegarandeerd dat alle nieuwe opslagaccounts automatisch worden geconfigureerd met de juiste redundantie-instellingen.

Een belangrijk technisch aspect van geo-redundantie is de asynchrone aard van de replicatie. Wijzigingen in de primaire regio worden niet onmiddellijk gerepliceerd naar de secundaire regio, maar met een vertraging die typisch enkele minuten bedraagt. Deze asynchrone replicatie betekent dat er een Recovery Point Objective (RPO) is van enkele minuten, wat betekent dat bij een failover naar de secundaire regio, recente wijzigingen mogelijk verloren kunnen gaan. Voor de meeste werkbelastingen is deze RPO acceptabel, maar voor applicaties die real-time consistentie vereisen of die geen gegevensverlies kunnen tolereren, kan dit een overweging zijn. Organisaties moeten hun applicaties ontwerpen met dit RPO in gedachten en waar nodig aanvullende maatregelen implementeren, zoals transactionele replicatie of synchrone back-ups voor kritieke gegevens. Voor Nederlandse overheidsorganisaties die werken met kritieke gegevens zoals burgergegevens of financiële informatie, is het belangrijk om de RPO te begrijpen en te accepteren, of om aanvullende maatregelen te overwegen voor gegevens die geen enkele minuut van gegevensverlies kunnen tolereren.

Monitoring en verificatie van geo-redundante opslag

Gebruik PowerShell-script geo-redundant-storage.ps1 (functie Invoke-Monitoring) – Automatische verificatie van geo-redundante opslagconfiguratie.

Effectieve monitoring van geo-redundante opslagconfiguraties is essentieel voor het waarborgen van continue bescherming tegen gegevensverlies en het voldoen aan compliance-vereisten. Organisaties moeten regelmatig controleren of hun opslagaccounts de juiste redundantie-instellingen hebben, met name voor productieomgevingen waar gegevensverlies onacceptabel is. De monitoring moet zich richten op het verifiëren van de SKU-configuratie van elk opslagaccount, waarbij moet worden gecontroleerd of opslagaccounts zijn geconfigureerd met Standard_GRS, Standard_GZRS, of Standard_RA-GRS als redundantieoptie. Opslagaccounts die zijn geconfigureerd met Standard_LRS (lokaal redundante opslag) of Standard_ZRS (zone-redundante opslag) bieden onvoldoende bescherming tegen regionale uitval en voldoen niet aan de vereisten voor rampherstel zoals gesteld in de BIO-normen. Automatische monitoring kan worden geïmplementeerd met behulp van Azure Policy, PowerShell-scripts, of Azure Monitor, waarbij regelmatig de configuratie van opslagaccounts wordt gecontroleerd. Deze controles moeten minimaal wekelijks worden uitgevoerd, en bij voorkeur dagelijks voor kritieke omgevingen. Wanneer een opslagaccount wordt gedetecteerd met onvoldoende redundantie, moet dit onmiddellijk worden gemeld aan de verantwoordelijke beheerders en moet er een remediatieplan worden opgesteld.

Naast het controleren van de redundantieconfiguratie zelf, moeten organisaties ook de replicatiestatus monitoren. Azure biedt metrische gegevens over de replicatielatentie en de status van de secundaire regio via Azure Monitor. Abnormale replicatielatentie of fouten in de replicatie kunnen wijzen op problemen die moeten worden onderzocht, zoals netwerkproblemen, configuratiefouten, of problemen met de secundaire regio. Organisaties moeten alert zijn op waarschuwingen over replicatiefouten en deze onmiddellijk onderzoeken, omdat replicatiefouten betekenen dat gegevens niet worden beschermd tegen regionale uitval, zelfs wanneer de redundantieconfiguratie correct is ingesteld. Voor Nederlandse overheidsorganisaties is het belangrijk om monitoringresultaten te documenteren voor auditdoeleinden. Compliance-vereisten zoals BIO 12.03 en ISO 27001:2022 vereisen dat organisaties kunnen aantonen dat passende maatregelen zijn getroffen voor gegevensbescherming en rampherstel. Regelmatige monitoring en documentatie vormen een essentieel onderdeel van deze compliance, waarbij audit trails moeten worden bewaard voor een periode van minimaal zeven jaar in overeenstemming met Nederlandse archiefwetgeving.

Organisaties moeten ook alert zijn op wijzigingen in de configuratie. Ongeautoriseerde wijzigingen van GRS naar LRS kunnen het gevolg zijn van menselijke fouten of mogelijk kwaadwillende activiteiten. Monitoringtools moeten daarom ook wijzigingsdetectie bevatten, zodat configuratiewijzigingen onmiddellijk worden opgemerkt en indien nodig kunnen worden teruggedraaid. Azure Activity Log kan worden gebruikt om wijzigingen in opslagaccountconfiguraties te detecteren, waarbij organisaties alerts kunnen configureren voor wijzigingen in de redundantie-instellingen. Het implementeren van effectieve monitoring vereist een combinatie van technische tools en organisatorische processen. Technische tools kunnen automatisch controleren en rapporteren, maar organisaties moeten ook duidelijke procedures hebben voor het reageren op bevindingen en het nemen van corrigerende maatregelen wanneer dat nodig is. Deze procedures moeten worden gedocumenteerd en regelmatig worden getest om te verzekeren dat ze effectief zijn en dat medewerkers weten hoe ze moeten reageren op niet-compliant configuraties.

Compliance en auditvereisten

Geo-redundante opslag speelt een cruciale rol in het voldoen aan verschillende compliance-vereisten die van toepassing zijn op Nederlandse overheidsorganisaties. De implementatie van GRS of GZRS draagt direct bij aan het naleven van meerdere normen en regelgevingen, waarbij organisaties moeten kunnen aantonen dat zij passende maatregelen hebben getroffen voor gegevensbescherming en rampherstel. De Baseline Informatiebeveiliging Overheid (BIO) controle 12.03 vereist expliciet dat organisaties passende maatregelen treffen voor rampherstel en bedrijfscontinuïteit. Geo-redundantie is een essentiële component van deze maatregelen, omdat het bescherming biedt tegen regionale uitval en natuurrampen. Zonder geo-redundantie kunnen organisaties niet aantonen dat zij voldoen aan de vereisten voor gegevensbescherming en herstel na incidenten. Bij BIO-audits moeten organisaties kunnen demonstreren dat kritieke gegevens zijn beschermd tegen verlies bij regionale incidenten, en geo-redundantie is een van de meest effectieve manieren om dit te bereiken. Auditoren zullen vragen naar de procedures voor het controleren van redundantie-instellingen, de maatregelen die worden genomen wanneer niet-compliant configuraties worden gedetecteerd, en de documentatie die beschikbaar is om aan te tonen dat geo-redundantie correct is geconfigureerd en wordt onderhouden.

ISO 27001:2022 controle A.8.13 richt zich op informatieback-ups en vereist dat organisaties regelmatige back-ups maken van informatie en software, en dat deze back-ups worden getest om te verifiëren dat ze kunnen worden hersteld. Geo-redundante opslag kan worden beschouwd als een vorm van continue back-up, waarbij gegevens automatisch worden gerepliceerd naar een secundaire locatie. Voor organisaties die ISO 27001-certificering nastreven of behouden, is het belangrijk om geo-redundantie te documenteren als onderdeel van hun back-upstrategie en te verifiëren dat de replicatie correct functioneert. Tijdens ISO 27001-audits moeten organisaties kunnen aantonen dat zij beschikken over gedocumenteerde procedures voor het beheer van geo-redundantie, dat deze procedures daadwerkelijk worden gevolgd, en dat er regelmatige controles worden uitgevoerd om te verzekeren dat de configuratie correct blijft. Auditoren zullen ook vragen naar de testprocedures voor disaster recovery, waarbij organisaties moeten kunnen aantonen dat zij hebben getest of gegevens kunnen worden hersteld vanuit de secundaire regio in het geval van een regionale uitval.

De NIS2-richtlijn, zoals geïmplementeerd in Nederlandse wetgeving, vereist in Artikel 21 dat essentiële entiteiten en belangrijke entiteiten passende technische en organisatorische maatregelen treffen om de beveiliging van netwerk- en informatiesystemen te waarborgen. Dit omvat maatregelen voor bedrijfscontinuïteit en rampherstel. Voor organisaties die onder de NIS2-richtlijn vallen, is geo-redundantie een belangrijke technische maatregel die bijdraagt aan het voldoen aan deze vereisten. Organisaties moeten kunnen aantonen dat zij beschikken over adequate maatregelen voor het beschermen van gegevens tegen verlies bij regionale incidenten, waarbij geo-redundantie een essentiële component vormt. Bij het voorbereiden van audits moeten organisaties kunnen aantonen dat zij hun opslagaccounts hebben geconfigureerd met de juiste redundantie-instellingen. Dit vereist documentatie van de configuratie, regelmatige verificatie dat de configuratie correct blijft, en bewijs van monitoring en onderhoud. Organisaties moeten ook rekening houden met de bewaartermijnen voor auditbewijs. De BIO vereist dat auditbewijs wordt bewaard voor een periode van zeven jaar, wat betekent dat configuratiecontroles, monitoringrapporten en andere relevante documentatie moeten worden bewaard en toegankelijk blijven voor auditdoeleinden.

Remediatie en best practices

Gebruik PowerShell-script geo-redundant-storage.ps1 (functie Invoke-Remediation) – Herstellen van geo-redundante opslagconfiguratie.

Wanneer monitoring detecteert dat een opslagaccount niet is geconfigureerd met geo-redundantie, moet onmiddellijk actie worden ondernomen om deze situatie te herstellen. Het herstellen van de juiste redundantieconfiguratie is een kritieke beveiligingsmaatregel die niet kan worden uitgesteld, vooral voor productieomgevingen waar gegevensverlies onacceptabel is. De remediatieprocedure begint met het identificeren van de huidige configuratie van het opslagaccount en het bepalen van de meest geschikte geo-redundantieoptie. Voor de meeste productieomgevingen is Standard_GRS de aanbevolen optie, omdat het een goede balans biedt tussen kosten en bescherming. Voor kritieke workloads die extra bescherming tegen zone-uitval vereisen, kan Standard_GZRS worden overwogen, hoewel dit duurder is en alleen beschikbaar is voor bepaalde opslagtypen. Het wijzigen van de redundantieconfiguratie kan worden uitgevoerd via de Azure Portal, Azure PowerShell, of de Azure CLI, waarbij organisaties moeten rekening houden met de tijd die nodig is voor replicatie en mogelijke impact op de prestaties tijdens de migratie.

Voor organisaties die meerdere opslagaccounts beheren, kan geautomatiseerde remediatie worden geïmplementeerd met behulp van Azure Policy of PowerShell-scripts. Azure Policy kan worden gebruikt om automatisch te controleren of nieuwe opslagaccounts de juiste redundantieconfiguratie hebben, en om waarschuwingen te genereren wanneer niet-compliant configuraties worden gedetecteerd. Voor bestaande opslagaccounts kunnen PowerShell-scripts worden gebruikt om automatisch de configuratie te wijzigen, hoewel dit zorgvuldig moet worden gepland om te voorkomen dat productieomgevingen worden verstoord. Geautomatiseerde remediatie is vooral belangrijk voor grote organisaties met honderden of duizenden opslagaccounts, waar handmatige remediatie niet praktisch is. Na remediatie moeten organisaties de oorzaak van de niet-compliant configuratie onderzoeken. Was het een menselijke fout tijdens het aanmaken of wijzigen van het opslagaccount? Was het een geautomatiseerd proces dat de verkeerde configuratie heeft toegepast? Door de oorzaak te begrijpen, kunnen organisaties maatregelen nemen om te voorkomen dat het probleem opnieuw optreedt, zoals het verbeteren van procedures, het toevoegen van extra controles aan geautomatiseerde processen, of het trainen van medewerkers in de juiste configuratieprocedures.

Best practices voor het beheren van geo-redundante opslag omvatten het gebruik van Infrastructure as Code (IaC) voor het definiëren en beheren van opslagaccountconfiguraties, het implementeren van Azure Policy om te garanderen dat alle nieuwe opslagaccounts automatisch worden geconfigureerd met de juiste redundantie-instellingen, en het regelmatig testen van disaster recovery-scenario's om te verifiëren dat gegevens daadwerkelijk kunnen worden hersteld vanuit de secundaire regio. Organisaties moeten ook duidelijke procedures hebben voor het beheren van kosten, omdat geo-redundantie de opslagkosten verhoogt. Het is belangrijk om regelmatig te evalueren of alle opslagaccounts daadwerkelijk geo-redundantie nodig hebben, en om voor niet-kritieke workloads zoals ontwikkel- en testomgevingen te overwegen om lokaal redundante opslag te gebruiken om kosten te besparen. Voor productieomgevingen met kritieke gegevens moet geo-redundantie echter altijd worden gebruikt, ongeacht de kosten, omdat gegevensverlies onacceptabel is en kan leiden tot compliance-schendingen, reputatieschade, en mogelijke boetes.

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 Azure Storage: Geo-Redundante Opslag voor Bedrijfscontinuïteit .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.20 Controleert of Azure Storage-accounts zijn geconfigureerd met geo-redundante opslag (GRS of GZRS) voor bescherming tegen regionale uitval en rampen. .NOTES Filename: geo-redundant-storage.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.20 Workload: Azure Category: opslag #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param( [Parameter()][switch]$Monitoring, [Parameter()][string]$ResourceGroupName, [Parameter()][string]$SubscriptionId ) $ErrorActionPreference = 'Stop' $PolicyName = "Geo-Redundante Opslag voor Azure Storage" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } if ($SubscriptionId) { Set-AzContext -SubscriptionId $SubscriptionId | Out-Null } } function Test-Compliance { [CmdletBinding()] param() $results = @{ TotalAccounts = 0 WithGRS = 0 WithGZRS = 0 WithRAGRS = 0 WithLRS = 0 WithZRS = 0 NonCompliantAccounts = @() ConfigurationErrors = @() } try { if ($ResourceGroupName) { $storageAccounts = Get-AzStorageAccount -ResourceGroupName $ResourceGroupName -ErrorAction SilentlyContinue } else { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue } $results.TotalAccounts = $storageAccounts.Count foreach ($account in $storageAccounts) { $accountInfo = @{ Name = $account.StorageAccountName ResourceGroup = $account.ResourceGroupName SkuName = $account.Sku.Name Location = $account.Location Kind = $account.Kind } $skuName = $account.Sku.Name # Controleer redundantieconfiguratie if ($skuName -like "*GRS*" -and $skuName -notlike "*RA-GRS*" -and $skuName -notlike "*GZRS*") { $results.WithGRS++ } elseif ($skuName -like "*GZRS*") { $results.WithGZRS++ } elseif ($skuName -like "*RA-GRS*") { $results.WithRAGRS++ } elseif ($skuName -like "*LRS*") { $results.WithLRS++ $results.NonCompliantAccounts += $accountInfo } elseif ($skuName -like "*ZRS*" -and $skuName -notlike "*GZRS*") { $results.WithZRS++ $results.NonCompliantAccounts += $accountInfo } else { $results.ConfigurationErrors += "Onbekende SKU-configuratie voor account '$($account.StorageAccountName)': $skuName" $results.NonCompliantAccounts += $accountInfo } } return $results } catch { Write-Error "Fout bij het ophalen van Storage Accounts: $($_.Exception.Message)" throw } } function Invoke-Implementation { <# .SYNOPSIS Implementeert geo-redundante opslagconfiguratie #> [CmdletBinding()] param() Write-Host "[INFO] Implementatie van geo-redundante opslag vereist handmatige configuratie" -ForegroundColor Yellow Write-Host "[INFO] Zie de documentatie voor gedetailleerde implementatie-instructies" -ForegroundColor Yellow Write-Host "" Write-Host "Implementatiestappen:" -ForegroundColor Cyan Write-Host "1. Identificeer opslagaccounts die geo-redundantie nodig hebben" -ForegroundColor White Write-Host "2. Selecteer de juiste redundantieoptie (GRS of GZRS)" -ForegroundColor White Write-Host "3. Wijzig de redundantieconfiguratie via Azure Portal of PowerShell" -ForegroundColor White Write-Host "4. Monitor de replicatiestatus totdat deze is voltooid" -ForegroundColor White Write-Host "5. Verifieer dat de configuratie correct is toegepast" -ForegroundColor White Write-Host "" Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status van geo-redundante opslag #> [CmdletBinding()] param() try { Connect-RequiredServices $results = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "" Write-Host "Overzicht:" -ForegroundColor Yellow Write-Host " Totaal Storage Accounts: $($results.TotalAccounts)" -ForegroundColor White Write-Host " Met Geo-Redundant Storage (GRS): $($results.WithGRS)" -ForegroundColor $(if ($results.WithGRS -gt 0) { 'Green' } else { 'Yellow' }) Write-Host " Met Geo-Zone-Redundant Storage (GZRS): $($results.WithGZRS)" -ForegroundColor $(if ($results.WithGZRS -gt 0) { 'Green' } else { 'Yellow' }) Write-Host " Met Read-Access Geo-Redundant Storage (RA-GRS): $($results.WithRAGRS)" -ForegroundColor $(if ($results.WithRAGRS -gt 0) { 'Green' } else { 'Yellow' }) Write-Host " Met Lokaal Redundant Storage (LRS): $($results.WithLRS)" -ForegroundColor $(if ($results.WithLRS -eq 0) { 'Green' } else { 'Red' }) Write-Host " Met Zone Redundant Storage (ZRS): $($results.WithZRS)" -ForegroundColor $(if ($results.WithZRS -eq 0) { 'Green' } else { 'Yellow' }) Write-Host "" $totalGeoRedundant = $results.WithGRS + $results.WithGZRS + $results.WithRAGRS if ($results.NonCompliantAccounts.Count -gt 0) { Write-Host "Niet-compliant accounts (geen geo-redundantie):" -ForegroundColor Red foreach ($account in $results.NonCompliantAccounts) { Write-Host " - $($account.Name) (RG: $($account.ResourceGroup), SKU: $($account.SkuName), Locatie: $($account.Location))" -ForegroundColor Red } Write-Host "" } if ($results.ConfigurationErrors.Count -gt 0) { Write-Host "Configuratiefouten:" -ForegroundColor Red foreach ($error in $results.ConfigurationErrors) { Write-Host " - $error" -ForegroundColor Red } Write-Host "" } if ($results.NonCompliantAccounts.Count -eq 0 -and $results.ConfigurationErrors.Count -eq 0) { Write-Host "Status: COMPLIANT" -ForegroundColor Green Write-Host "Alle Storage Accounts zijn geconfigureerd met geo-redundante opslag." -ForegroundColor Green Write-Host "Totaal geo-redundant: $totalGeoRedundant/$($results.TotalAccounts) accounts" -ForegroundColor Green } elseif ($results.NonCompliantAccounts.Count -gt 0) { Write-Host "Status: NON-COMPLIANT" -ForegroundColor Red Write-Host "$($results.NonCompliantAccounts.Count) Storage Account(s) gebruiken geen geo-redundantie." -ForegroundColor Red Write-Host "Deze accounts zijn kwetsbaar voor regionale uitval en voldoen niet aan BIO 12.03 vereisten." -ForegroundColor Red } else { Write-Host "Status: WAARSCHUWING" -ForegroundColor Yellow Write-Host "Er zijn configuratieproblemen gedetecteerd." -ForegroundColor Yellow } Write-Host "" Write-Host "Aanbevelingen:" -ForegroundColor Cyan if ($results.WithLRS -gt 0) { Write-Host " - Migreer LRS-accounts naar GRS voor productieomgevingen" -ForegroundColor White } if ($results.WithZRS -gt 0) { Write-Host " - Overweeg GZRS voor ZRS-accounts die extra bescherming nodig hebben" -ForegroundColor White } if ($totalGeoRedundant -lt $results.TotalAccounts) { Write-Host " - Zorg dat alle productie-opslagaccounts geo-redundantie gebruiken" -ForegroundColor White } return $results } catch { Write-Error "Fout bij monitoring: $($_.Exception.Message)" exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Deze functie biedt richtlijnen voor het configureren van geo-redundante opslag. Automatische remediatie is mogelijk maar vereist zorgvuldige planning. #> [CmdletBinding()] param( [Parameter()][switch]$WhatIf ) try { Connect-RequiredServices $results = Test-Compliance if ($results.NonCompliantAccounts.Count -eq 0) { Write-Host "[INFO] Geen niet-compliant accounts gevonden. Configuratie is correct." -ForegroundColor Green return } Write-Host "[INFO] Remediatie van geo-redundante opslagconfiguratie" -ForegroundColor Cyan Write-Host "" if ($WhatIf) { Write-Host "[WHATIF] De volgende accounts zouden worden gemigreerd naar GRS:" -ForegroundColor Yellow } else { Write-Host "De volgende accounts worden gecontroleerd voor migratie naar GRS:" -ForegroundColor Yellow } foreach ($account in $results.NonCompliantAccounts) { Write-Host "" Write-Host "Account: $($account.Name)" -ForegroundColor Cyan Write-Host " Resource Group: $($account.ResourceGroup)" -ForegroundColor White Write-Host " Huidige SKU: $($account.SkuName)" -ForegroundColor White Write-Host " Locatie: $($account.Location)" -ForegroundColor White if ($WhatIf) { Write-Host " [WHATIF] Zou worden gemigreerd naar: Standard_GRS" -ForegroundColor Yellow } else { Write-Host " [INFO] Automatische migratie naar GRS vereist handmatige tussenkomst" -ForegroundColor Yellow Write-Host " [INFO] Gebruik de volgende PowerShell-opdracht:" -ForegroundColor Yellow Write-Host " Set-AzStorageAccount -ResourceGroupName '$($account.ResourceGroup)' -Name '$($account.Name)' -SkuName 'Standard_GRS'" -ForegroundColor White Write-Host "" Write-Host " [WAARSCHUWING] Migratie kan enkele uren duren voor grote accounts" -ForegroundColor Yellow Write-Host " [WAARSCHUWING] Plan migratie tijdens perioden met lage werkbelasting" -ForegroundColor Yellow } } Write-Host "" Write-Host "Remediatiestappen:" -ForegroundColor Cyan Write-Host "1. Plan migratie tijdens perioden met lage werkbelasting" -ForegroundColor White Write-Host "2. Informeer stakeholders over mogelijke impact" -ForegroundColor White Write-Host "3. Wijzig redundantieconfiguratie via Azure Portal of PowerShell" -ForegroundColor White Write-Host "4. Monitor replicatiestatus totdat migratie is voltooid" -ForegroundColor White Write-Host "5. Verifieer configuratie na migratie" -ForegroundColor White Write-Host "" Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring } catch { Write-Error "Fout bij remediatie: $($_.Exception.Message)" exit 1 } } # Main execution try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } else { $results = Test-Compliance $totalGeoRedundant = $results.WithGRS + $results.WithGZRS + $results.WithRAGRS Write-Host "`nGeo-Redundante Opslag Status:" -ForegroundColor Cyan Write-Host " Geo-redundant: $totalGeoRedundant/$($results.TotalAccounts) accounts" -ForegroundColor $(if ($totalGeoRedundant -eq $results.TotalAccounts) { 'Green' } else { 'Yellow' }) Write-Host " LRS (niet-compliant): $($results.WithLRS)/$($results.TotalAccounts) accounts" -ForegroundColor $(if ($results.WithLRS -eq 0) { 'Green' } else { 'Red' }) if ($results.NonCompliantAccounts.Count -gt 0) { Write-Host "`nNiet-compliant accounts gevonden. Gebruik -Monitoring voor details." -ForegroundColor Yellow } } } catch { Write-Error "Fout: $($_.Exception.Message)" exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder geo-redundante opslag lopen organisaties het risico op volledig gegevensverlies bij regionale incidenten zoals datacenteruitval, natuurrampen, of grootschalige cyberaanvallen. Lokaal redundante opslag (LRS) biedt alleen bescherming tegen hardwarefouten binnen één datacenter, maar geen bescherming tegen regionale uitval. Dit heeft directe gevolgen voor compliance met BIO 12.03, ISO 27001:2022 controle A.8.13, en NIS2-vereisten, en vormt een kritiek risico voor bedrijfscontinuïteit en de beschikbaarheid van kritieke overheidsdiensten.

Management Samenvatting

Geo-redundante opslag (GRS/GZRS) biedt zes kopieën van gegevens: drie kopieën in de primaire regio en drie kopieën in een gekoppelde secundaire regio op honderden kilometers afstand. Dit beschermt tegen regionale rampen, datacenteruitval en grootschalige storingen. GZRS voegt zone-redundantie toe binnen de primaire regio voor extra bescherming. Kosten: ongeveer vijftig procent meer dan lokaal redundante opslag voor GRS. Configuratie: Storage Account → Configuration → Redundancy: GRS/GZRS. Verplicht volgens BIO 12.03, ISO 27001:2022 A.8.13, en NIS2. Implementatietijd: 2-4 uur. KRITIEK voor productiewerkbelastingen - gebruik LRS alleen voor ontwikkel- en testomgevingen.