BIO 12.03 ISO A.8.13

Opslag Geo-Redundancy (GRS)

📅 2025-10-29
•
⏱️ 5 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Deze beveiligingscontrole waarborgt de correcte configuratie van geo-redundante opslag en beschermt tegen beveiligingsrisico's en gegevensverlies bij regionale uitval.

Aanbeveling
IMPLEMENTEER GRS VOOR PRODUCTIE
Risico zonder
High
Risk Score
8/10
Implementatie
2u (tech: 1u)
Van toepassing op:
✓ Azure opslag

Deze instelling is essentieel voor het handhaven van een veilige omgeving en voorkomt bekende aanvalsvectoren door het afdwingen van beveiligingsbest practices. Geo-redundantie beschermt organisaties tegen complete gegevensverlies bij regionale rampen, datacenteruitval of grootschalige storingen.

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

Implementatie

Gebruik Geo-Redundant Storage (GRS) of Geo-Zone-Redundant Storage (GZRS) voor productieopslag. Gegevens worden automatisch gerepliceerd naar een secundaire regio, waardoor hoge beschikbaarheid en duurzaamheid worden gegarandeerd.

Vereisten

Voor het implementeren van geo-redundante opslag in Azure zijn specifieke vereisten van toepassing. De primaire vereiste is het bezit van een Azure Storage-account met de juiste configuratiemogelijkheden. Het opslagaccount moet worden geconfigureerd met een van de ondersteunde redundantieopties: Geo-Redundant Storage (GRS) of 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. Deze configuratie beschermt tegen regionale uitval, natuurrampen en grootschalige storingen. GZRS voegt hieraan zone-redundantie toe binnen de primaire regio, wat extra bescherming biedt tegen uitval van beschikbaarheidszones. Voor Nederlandse overheidsorganisaties is het belangrijk om te begrijpen dat geo-redundantie niet alleen een technische keuze is, maar ook een compliance-vereiste. De Baseline Informatiebeveiliging Overheid (BIO) vereist in controle 12.03 dat organisaties passende maatregelen treffen voor rampherstel en bedrijfscontinuïteit. Dit betekent dat kritieke gegevens moeten worden beschermd tegen verlies bij regionale incidenten. Bij het selecteren van een redundantieoptie moeten organisaties rekening houden met verschillende factoren. De kosten spelen een belangrijke rol: GRS verhoogt de opslagkosten met ongeveer vijftig procent ten opzichte van lokaal redundante opslag (LRS). Voor GZRS zijn de kosten nog hoger, maar de bescherming is ook uitgebreider. Organisaties moeten een afweging maken tussen kosten en het vereiste beschermingsniveau. Daarnaast is het belangrijk om te begrijpen dat geo-redundantie asynchrone replicatie gebruikt. Dit betekent dat wijzigingen in de primaire regio niet onmiddellijk beschikbaar zijn in de secundaire regio. Voor de meeste werkbelastingen is deze vertraging acceptabel, maar voor applicaties die real-time consistentie vereisen, kan dit een overweging zijn. De implementatie van geo-redundantie vereist geen extra technische expertise, maar wel een goed begrip van de implicaties voor kosten, prestaties en compliance. Organisaties moeten hun opslagaccounts regelmatig controleren om te verifiëren dat de juiste redundantieconfiguratie is toegepast, vooral voor productieomgevingen waar gegevensverlies onacceptabel is.

Monitoring

Gebruik PowerShell-script redundancy-grs.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van geo-redundante opslagconfiguraties is essentieel voor het waarborgen van continue bescherming tegen gegevensverlies. 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. Voor geo-redundantie moeten opslagaccounts zijn geconfigureerd met Standard_GRS of Standard_GZRS als redundantieoptie. Lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS) 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 of PowerShell-scripts die regelmatig de configuratie van opslagaccounts controleren. 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. 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. Abnormale replicatielatentie of fouten in de replicatie kunnen wijzen op problemen die moeten worden onderzocht. 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. 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. 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.

Compliance en Audit

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. De Baseline Informatiebeveiliging Overheid (BIO) controle 12.03 vereist 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 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. ISO 27001:2022 controle A.8.13 richt zich op informatieback-ups. Deze controle 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. 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. 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. Auditoren zullen vragen naar de procedures voor het controleren van redundantie-instellingen en de maatregelen die worden genomen wanneer niet-compliant configuraties worden gedetecteerd. Organisaties moeten ook rekening houden met de bewaartermijnen voor auditbewijs. De BIO vereist dat auditbewijs wordt bewaard voor een periode van zeven jaar. Dit betekent dat configuratiecontroles, monitoringrapporten en andere relevante documentatie moeten worden bewaard en toegankelijk blijven voor auditdoeleinden. Geo-redundantie zelf draagt ook bij aan de duurzaamheid van gegevens, wat belangrijk is voor het voldoen aan archiveringsvereisten. Voor Nederlandse overheidsorganisaties is het belangrijk om te begrijpen dat compliance niet alleen gaat om het implementeren van technische maatregelen, maar ook om het kunnen aantonen dat deze maatregelen effectief zijn en correct worden onderhouden. Geo-redundantie is een krachtige technische maatregel, maar zonder adequate monitoring, documentatie en onderhoud kan het niet worden gebruikt om compliance aan te tonen bij audits.

Remediatie

Gebruik PowerShell-script redundancy-grs.ps1 (functie Invoke-Remediation) – Herstellen.

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. Opslagaccounts kunnen worden geconfigureerd met verschillende redundantieopties: lokaal redundante opslag (LRS), zone-redundante opslag (ZRS), geo-redundante opslag (GRS), geo-zone-redundante opslag (GZRS), of read-access geo-redundante opslag (RA-GRS). Voor productieomgevingen moeten organisaties GRS of GZRS gebruiken om te voldoen aan compliance-vereisten en adequate bescherming te bieden tegen regionale uitval. Het wijzigen van de redundantieconfiguratie van een bestaand opslagaccount kan worden uitgevoerd 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 kan dit proces enkele uren duren, en gedurende deze tijd kan de opslagaccount nog steeds functioneel zijn, maar zonder de volledige bescherming van geo-redundantie. Voor nieuwe opslagaccounts moet de juiste redundantieconfiguratie worden geselecteerd tijdens het aanmaken. Dit voorkomt dat later wijzigingen nodig zijn en zorgt ervoor dat gegevens vanaf het begin worden beschermd met geo-redundantie. Organisaties moeten standaardprocedures hebben die ervoor zorgen dat alle nieuwe opslagaccounts automatisch worden geconfigureerd met de juiste redundantie-instellingen. Na het herstellen van de configuratie moet worden geverifieerd dat de wijziging correct is toegepast. Dit kan worden gedaan door de configuratie opnieuw te controleren met monitoringtools of PowerShell-scripts. Organisaties moeten ook controleren of de replicatie naar de secundaire regio correct functioneert, omdat configuratiefouten of netwerkproblemen kunnen voorkomen dat gegevens daadwerkelijk worden gerepliceerd. Het is belangrijk om te begrijpen dat het wijzigen van de redundantieconfiguratie kosten met zich meebrengt. GRS verhoogt de opslagkosten met ongeveer vijftig procent ten opzichte van LRS, en GZRS is nog duurder. Organisaties moeten deze kosten accepteren als onderdeel van hun compliance-vereisten en beveiligingsstrategie. Het niet implementeren van geo-redundantie om kosten te besparen is geen acceptabele praktijk voor productieomgevingen waar gegevensverlies onacceptabel is. Voor organisaties die meerdere opslagaccounts beheren, kan geautomatiseerde remediatie worden geïmplementeerd met behulp van Azure Policy of PowerShell-scripts. Deze automatisering kan ervoor zorgen dat niet-compliant configuraties automatisch worden gedetecteerd en hersteld, waardoor de tijd tussen detectie en remediatie wordt geminimaliseerd. 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. Dit kan bijvoorbeeld betekenen dat procedures worden verbeterd, dat extra controles worden toegevoegd aan geautomatiseerde processen, of dat medewerkers worden getraind in de juiste configuratieprocedures.

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 Redundancy GRS .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.20 Controleert gebruik van GRS redundancy voor storage accounts. .NOTES Filename: redundancy-grs.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.20 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Redundancy GRS" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue $result = @{ TotalAccounts = $storageAccounts.Count; WithGRS = 0 } foreach ($account in $storageAccounts) { if ($account.Sku.Name -like "*GRS*" -or $account.Sku.Name -like "*GZRS*") { $result.WithGRS++ } } return $result } try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total Storage Accounts: $($r.TotalAccounts)" -ForegroundColor White Write-Host "With GRS/GZRS: $($r.WithGRS)" -ForegroundColor $(if ($r.WithGRS -gt 0) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nGRS Redundancy: $($r.WithGRS)/$($r.TotalAccounts) accounts" } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total Storage Accounts: $($r.TotalAccounts)" -ForegroundColor White Write-Host "With GRS/GZRS: $($r.WithGRS)" -ForegroundColor $(if ($r.WithGRS -gt 0) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nGRS Redundancy: $($r.WithGRS)/$($r.TotalAccounts) accounts" } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
High: Lokaal redundante opslag (LRS) alleen betekent dat een uitval van één datacenter kan leiden tot volledig gegevensverlies. Regionale rampen zoals overstromingen, branden of grootschalige storingen kunnen resulteren in permanent gegevensverlies voor productieomgevingen. Dit heeft directe gevolgen voor compliance met BIO 12.03 en ISO 27001:2022, en vormt een hoog risico voor bedrijfscontinuïteit.

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 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. Implementatietijd: 1-2 uur. KRITIEK voor productiewerkbelastingen - gebruik LRS alleen voor ontwikkel- en testomgevingen.