BIO 12.03 ISO A.8.13

Azure Storage Account: Geo-Redundante Opslag Configuratie Verificatie

📅 2025-01-27
•
⏱️ 6 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Deze beveiligingscontrole verifieert dat Azure Storage Accounts correct zijn geconfigureerd met geo-redundante opslag (GRS) of geo-zone-redundante opslag (GZRS) voor productieomgevingen. Deze verificatieprocedure waarborgt dat organisaties voldoen aan compliance-vereisten voor rampherstel en bedrijfscontinuïteit, en beschermt tegen volledig gegevensverlies bij regionale uitval, natuurrampen of grootschalige datacenterstoringen.

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

Het verifiëren van geo-redundante opslagconfiguratie is essentieel voor het handhaven van een veilige en compliant cloudomgeving. Zonder geo-redundantie lopen organisaties het risico op volledig gegevensverlies wanneer een hele Azure-regio uitvalt, wat kan gebeuren door natuurrampen, grootschalige cyberaanvallen, of technische storingen op datacenterniveau. Voor Nederlandse overheidsorganisaties is geo-redundantie niet alleen een best practice, maar ook een compliance-vereiste volgens de Baseline Informatiebeveiliging Overheid (BIO) controle 12.03, die passende maatregelen voor rampherstel en bedrijfscontinuïteit verplicht stelt. Het risico van gegevensverlies bij regionale uitval is bijzonder hoog voor organisaties die kritieke gegevens opslaan, zoals persoonsgegevens, bedrijfsgeheimen, of vertrouwelijke overheidsinformatie. Een dergelijk gegevensverlies kan catastrofale gevolgen hebben voor zowel de organisatie als de betrokken individuen, en kan leiden tot aanzienlijke compliance-schendingen, boetes, en reputatieschade. Geo-redundantie biedt bescherming tegen deze risico's door automatische replicatie van gegevens naar een secundaire regio die zich op honderden kilometers afstand bevindt, waardoor zelfs bij volledige uitval van de primaire regio gegevens beschikbaar blijven. Deze verificatieprocedure zorgt ervoor dat organisaties proactief kunnen controleren of hun opslagaccounts correct zijn geconfigureerd, en dat eventuele configuratiefouten of wijzigingen onmiddellijk worden gedetecteerd en gecorrigeerd voordat ze kunnen leiden tot beveiligingsincidenten of compliance-schendingen.

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

Implementatie

Deze maatregel vormt een systematische verificatieprocedure om te bevestigen dat alle Azure Storage Accounts binnen de omgeving van een organisatie correct zijn geconfigureerd met geo-redundante opslag voor productieomgevingen. De verificatieprocedure controleert de SKU-configuratie van elk opslagaccount om te verifiëren dat de redundantie-instelling is ingesteld op Geo-Redundant Storage (GRS) of Geo-Zone-Redundant Storage (GZRS), in plaats van lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS) die onvoldoende bescherming bieden tegen regionale uitval. GRS 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, wat bescherming biedt tegen regionale rampen, natuurrampen en grootschalige storingen. GZRS voegt hieraan zone-redundantie toe binnen de primaire regio, wat extra bescherming biedt tegen uitval van beschikbaarheidszones terwijl nog steeds geo-redundantie wordt geboden. De verificatie kan worden uitgevoerd via PowerShell-scripts die automatisch alle opslagaccounts binnen een abonnement of resourcegroep controleren, of via de Azure Portal voor handmatige verificatie van individuele accounts. Voor organisaties met honderden of duizenden opslagaccounts is geautomatiseerde verificatie essentieel om efficiënt te kunnen controleren op naleving zonder handmatige inspanning voor elk individueel account. De verificatieprocedure moet regelmatig worden uitgevoerd, bij voorkeur wekelijks of dagelijks voor kritieke omgevingen, om te zorgen dat configuratiewijzigingen of nieuwe opslagaccounts onmiddellijk worden gedetecteerd. Wanneer een opslagaccount wordt aangetroffen zonder geo-redundantie, moet onmiddellijk actie worden ondernomen om de configuratie te herstellen, vooral voor productieomgevingen waar gegevensverlies onacceptabel is. De verificatie kost doorgaans minder dan 30 minuten voor een gemiddelde Azure-omgeving en kan worden geïntegreerd in bestaande monitoring- en compliance-workflows voor continue verificatie zonder significante operationele overhead.

Vereisten

Voor de implementatie en verificatie van geo-redundante opslagconfiguratie zijn specifieke vereisten noodzakelijk die organisaties moeten begrijpen voordat zij beginnen met de verificatieprocedure. De primaire vereiste betreft de aanwezigheid van Azure Storage Accounts binnen de Azure-omgeving, waarbij organisaties moeten kunnen identificeren welke accounts worden gebruikt voor productieomgevingen en welke voor ontwikkel- of testomgevingen. Productieomgevingen vereisen geo-redundantie om te voldoen aan compliance-vereisten en adequate bescherming te bieden tegen regionale uitval, terwijl ontwikkel- en testomgevingen mogelijk kunnen volstaan met lokaal redundante opslag (LRS) om kosten te besparen, hoewel dit per organisatie kan verschillen afhankelijk van de specifieke vereisten en risicotolerantie. Voor de verificatie van de configuratie is toegang tot de Azure-omgeving vereist via een account met voldoende machtigingen. De minimale vereiste rol is Lezer voor het ophalen van opslagaccounteigenschappen, wat betekent dat een gebruiker met deze rol de redundantieconfiguratie kan controleren maar geen wijzigingen kan aanbrengen. Voor volledige verificatie en eventuele remediatie is de rol Inzender of Opslagaccount Inzender aanbevolen, omdat deze rollen de mogelijkheid bieden om niet alleen de status te controleren maar ook eventuele configuratiewijzigingen door te voeren indien nodig. Daarnaast is PowerShell met de Az.Storage-module vereist voor het uitvoeren van de verificatiescripts. De module kan worden geïnstalleerd via Install-Module -Name Az.Storage -Force en vereist een actieve verbinding met Azure via Connect-AzAccount. De verificatie kan worden uitgevoerd op abonnementsniveau voor een volledig overzicht van alle opslagaccounts binnen een organisatie, wat ideaal is voor centrale compliance-verificatie en auditdoeleinden. Alternatief kan verificatie worden uitgevoerd op resourcegroepniveau voor gerichte verificatie van specifieke workloads of projecten, wat handig is voor gefaseerde implementaties of wanneer organisaties verschillende teams hebben die verantwoordelijk zijn voor verschillende resourcegroepen. Het is belangrijk te benadrukken dat geo-redundantie extra 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 voor productieomgevingen, waarbij het niet implementeren van geo-redundantie om kosten te besparen geen acceptabele praktijk is voor omgevingen waar gegevensverlies onacceptabel is. 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, wat betekent dat kritieke gegevens moeten worden beschermd tegen verlies bij regionale incidenten. Organisaties moeten daarom kunnen aantonen tijdens audits dat zij hun opslagaccounts hebben geconfigureerd met de juiste redundantie-instellingen en dat zij regelmatige verificaties uitvoeren om te bevestigen dat de configuratie correct blijft.

Monitoring en Verificatie

Gebruik PowerShell-script geo-redundant-storage-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren en verifiëren van geo-redundante opslagconfiguraties vormt een kritiek onderdeel van de beveiligingspostuur van elke organisatie die gebruik maakt van Azure-opslagdiensten voor productieomgevingen. Regelmatige verificatie is essentieel om te zorgen dat alle opslagaccounts de juiste redundantie-instellingen hebben, en om eventuele configuratiefouten of ongeautoriseerde wijzigingen onmiddellijk te detecteren voordat ze kunnen leiden tot beveiligingsrisico's of compliance-schendingen. Deze verificatie is niet alleen belangrijk voor het voldoen aan externe auditvereisten maar ook voor het behouden van interne beveiligingsstandaarden en het kunnen aantonen van noodzakelijke zorgvuldigheid bij gegevensbescherming. De verificatieprocedure begint met het ophalen van alle opslagaccounts binnen het Azure-abonnement of de specifieke resourcegroep. Dit gebeurt via de PowerShell cmdlet Get-AzStorageAccount, die een overzicht geeft van alle beschikbare opslagaccounts inclusief hun configuratie-eigenschappen. Deze cmdlet biedt gedetailleerde informatie over elk opslagaccount, waaronder de naam, resourcegroep, locatie, SKU-type, en kritiek voor deze verificatie, de redundantieconfiguratie. Vervolgens wordt voor elk opslagaccount de SKU-configuratie gecontroleerd om te verifiëren dat de redundantie-instelling is ingesteld op Standard_GRS, Standard_GZRS, Standard_RAGRS, of Standard_RAGZRS. 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. De monitoring moet zich richten op het verifiëren van de SKU-configuratie van elk opslagaccount, met speciale aandacht voor productieomgevingen waar gegevensverlies onacceptabel is. Voor productieomgevingen moeten opslagaccounts zijn geconfigureerd met GRS of GZRS om te voldoen aan compliance-vereisten en adequate bescherming te bieden tegen regionale uitval. Ontwikkel- en testomgevingen kunnen mogelijk volstaan met LRS om kosten te besparen, hoewel dit per organisatie kan verschillen afhankelijk van de specifieke vereisten en risicotolerantie. 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. De melding moet gedetailleerde informatie bevatten over het specifieke opslagaccount, de huidige configuratie, de vereiste configuratie, en aanbevelingen voor remediatie. 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. De verificatie kost doorgaans minder dan 30 minuten voor een gemiddelde Azure-omgeving en kan worden geïntegreerd in bestaande monitoring- en compliance-workflows, waardoor het een efficiënte en kosteneffectieve manier is om te voldoen aan beveiligings- en compliance-vereisten zonder significante operationele overhead.

Compliance en Audit

Geo-redundante opslagconfiguratie speelt een cruciale rol in het voldoen aan verschillende compliance-vereisten die van toepassing zijn op Nederlandse overheidsorganisaties. De implementatie en verificatie van GRS of GZRS draagt direct bij aan het naleven van meerdere normen en regelgevingen, waardoor het een essentieel onderdeel vormt van elke serieuze beveiligingsstrategie voor cloudopslag. 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. De BIO-normen zijn specifiek ontwikkeld voor de Nederlandse publieke sector en bieden een praktisch kader voor het implementeren van informatiebeveiliging in overeenstemming met Nederlandse wet- en regelgeving. 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. ISO 27001 is een internationaal erkende standaard voor informatiebeveiligingsmanagement, waardoor naleving van deze controles belangrijk is voor organisaties die werken met internationale partners of die ISO-certificering nastreven. 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. NIS2 is de Europese richtlijn voor netwerk- en informatiesystemenbeveiliging, die specifieke vereisten stelt aan organisaties die worden aangemerkt als essentiële of belangrijke entiteiten, waaronder veel Nederlandse overheidsorganisaties en kritieke infrastructuurbedrijven. 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. 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. Organisaties moeten daarom een systematische aanpak hebben voor het verifiëren, documenteren en onderhouden van geo-redundante opslagconfiguraties, waarbij regelmatige controles en documentatie essentieel zijn voor het kunnen aantonen van compliance tijdens externe audits.

Remediatie

Gebruik PowerShell-script geo-redundant-storage-configured.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 moet worden uitgevoerd door een beheerder met voldoende machtigingen, bij voorkeur met de rol Opslagaccount Inzender of Inzender, om ervoor te zorgen dat alle benodigde configuratiewijzigingen kunnen worden doorgevoerd zonder belemmeringen. 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. Dit kan worden geautomatiseerd via Azure Policy, wat organisaties in staat stelt om automatisch te controleren op naleving van redundantievereisten en om automatisch te waarschuwen of te handelen wanneer afwijkingen worden geconstateerd. 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. 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.

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 Geo-Redundant Storage Configured .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.20 Verifieert dat storage accounts zijn geconfigureerd met geo-redundantie (GRS/GZRS). .NOTES Filename: geo-redundant-storage-configured.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.20 Related JSON: content/azure/storage/geo-redundant-storage-configured.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param( [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$WhatIf ) $ErrorActionPreference = 'Stop' $PolicyName = "Geo-Redundant Storage Configured" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { <# .SYNOPSIS Test of storage accounts zijn geconfigureerd met geo-redundantie .OUTPUTS PSCustomObject met compliance resultaten #> [CmdletBinding()] param() $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue $result = @{ TotalAccounts = $storageAccounts.Count WithGRS = 0 WithoutGRS = 0 NonCompliantAccounts = @() } foreach ($account in $storageAccounts) { $skuName = $account.Sku.Name if ($skuName -like "*GRS*" -or $skuName -like "*GZRS*") { $result.WithGRS++ } else { $result.WithoutGRS++ $result.NonCompliantAccounts += [PSCustomObject]@{ Name = $account.StorageAccountName ResourceGroup = $account.ResourceGroupName CurrentRedundancy = $skuName Location = $account.Location } } } $result.IsCompliant = ($result.WithoutGRS -eq 0) return $result } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar geo-redundantie voor niet-compliant accounts .DESCRIPTION Wijzigt de redundantieconfiguratie van opslagaccounts naar GRS. Let op: Dit kan alleen voor nieuwe accounts of via upgrade. #> [CmdletBinding()] param() Write-Host "[INFO] Remediatie voor geo-redundantie" -ForegroundColor Cyan Write-Host "[INFO] Let op: Redundantie kan alleen worden gewijzigd tijdens account creatie of via upgrade" -ForegroundColor Yellow $result = Test-Compliance if ($result.IsCompliant) { Write-Host "[INFO] Alle accounts zijn al compliant" -ForegroundColor Green return } Write-Host "`nNiet-compliant accounts gevonden:" -ForegroundColor Yellow foreach ($account in $result.NonCompliantAccounts) { Write-Host " - $($account.Name) in $($account.ResourceGroup) (Huidig: $($account.CurrentRedundancy))" -ForegroundColor Yellow if ($WhatIf) { Write-Host " [WhatIf] Zou configureren naar Standard_GRS" -ForegroundColor Gray } else { Write-Host " [INFO] Voor bestaande accounts moet redundantie worden gewijzigd via Azure Portal of upgrade proces" -ForegroundColor Yellow Write-Host " [INFO] Navigeer naar: Storage Account -> Configuration -> Redundancy -> GRS" -ForegroundColor Cyan } } if (-not $WhatIf) { Write-Host "`n[INFO] Voor nieuwe accounts, gebruik: New-AzStorageAccount met -SkuName Standard_GRS" -ForegroundColor Cyan } } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status en genereert rapportage #> [CmdletBinding()] param() try { Connect-RequiredServices $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total Storage Accounts: $($result.TotalAccounts)" -ForegroundColor White Write-Host "Met GRS/GZRS: $($result.WithGRS)" -ForegroundColor $(if ($result.WithGRS -gt 0) { 'Green' } else { 'Yellow' }) Write-Host "Zonder GRS/GZRS: $($result.WithoutGRS)" -ForegroundColor $(if ($result.WithoutGRS -eq 0) { 'Green' } else { 'Red' }) if ($result.NonCompliantAccounts.Count -gt 0) { Write-Host "`nNiet-compliant accounts:" -ForegroundColor Red foreach ($account in $result.NonCompliantAccounts) { Write-Host " - $($account.Name) ($($account.ResourceGroup)) - Huidig: $($account.CurrentRedundancy)" -ForegroundColor Yellow } } if ($result.IsCompliant) { Write-Host "`n✅ ALLE ACCOUNTS ZIJN COMPLIANT" -ForegroundColor Green } else { Write-Host "`n❌ NIET-COMPLIANT ACCOUNTS GEVONDEN" -ForegroundColor Red Write-Host "Run met -Remediation om te herstellen" -ForegroundColor Yellow } return $result } catch { Write-Error "Monitoring fout: $_" throw } } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } # ================================================================================ # MAIN EXECUTION # ================================================================================ try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { Invoke-Remediation } else { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "GRS/GZRS Redundancy: $($result.WithGRS)/$($result.TotalAccounts) accounts" -ForegroundColor White if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT" -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT" -ForegroundColor Red Write-Host "Run met -Monitoring voor details of -Remediation om te herstellen" -ForegroundColor Yellow } return $result } } catch { Write-Error "Error: $_" exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Opslagaccounts zonder geo-redundantie lopen het risico op volledig gegevensverlies bij regionale uitval, natuurrampen of grootschalige datacenterstoringen. Dit heeft directe gevolgen voor compliance met BIO 12.03 en ISO 27001:2022, en vormt een hoog risico voor bedrijfscontinuïteit. Voor productieomgevingen is geo-redundantie verplicht.

Management Samenvatting

Verifieer dat alle productieopslagaccounts zijn geconfigureerd met Geo-Redundant Storage (GRS) of Geo-Zone-Redundant Storage (GZRS). GRS biedt zes kopieën van gegevens: drie in de primaire regio en drie in een secundaire regio op honderden kilometers afstand. GZRS voegt zone-redundantie toe binnen de primaire regio. Kosten: ongeveer vijftig procent meer dan LRS voor GRS. Configuratie: Storage Account → Configuration → Redundancy: GRS/GZRS. Verplicht volgens BIO 12.03. Implementatietijd: 1-2 uur. KRITIEK voor productiewerkbelastingen.