BIO 12.03 ISO A.8.13

Container Soft Delete

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

💼 Management Samenvatting

Deze beveiligingsregel waarborgt de correcte configuratie van container soft delete en beschermt tegen onherstelbaar gegevensverlies bij accidentele verwijdering.

Aanbeveling
Implementeer container soft delete
Risico zonder
Medium
Risk Score
6/10
Implementatie
1u (tech: 0.5u)
Van toepassing op:
✓ Azure opslag

Deze instelling is essentieel voor het handhaven van een veilige omgeving en voorkomt permanent gegevensverlies door het afdwingen van beveiligingsbest practices voor gegevensherstel. Zonder container soft delete kunnen organisaties bij een accidentele of kwaadwillige verwijdering van een container alle daarin opgeslagen blobs permanent verliezen, wat kan leiden tot operationele verstoringen, compliance-schendingen en aanzienlijke bedrijfsimpact.

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

Implementatie

Schakel container soft delete in op containerniveau met een retentieperiode van minimaal 90 dagen om verwijderde containers en hun inhoud te kunnen herstellen binnen de retentieperiode.

Vereisten

Voor het implementeren van container soft delete zijn specifieke vereisten van toepassing die organisaties moeten begrijpen voordat zij deze beveiligingsmaatregel activeren. De primaire vereiste betreft het beschikbaar hebben van een Azure Storage-account met blob storage-functionaliteit. Container soft delete is een functie die specifiek beschikbaar is voor blob storage-accounts en kan niet worden geactiveerd voor andere storage-accounttypen zoals file shares of queue storage.

Het Azure Storage-account moet beschikken over de juiste toegangsrechten voor configuratie. Organisaties hebben minimaal de rol Storage Account Contributor of een aangepaste rol met de machtiging Microsoft.Storage/storageAccounts/blobServices/containers/write nodig om de soft delete-instellingen te kunnen configureren. Voor organisaties die Azure RBAC gebruiken, is het belangrijk dat de beheerder die de configuratie uitvoert over de benodigde machtigingen beschikt.

Een technische vereiste betreft de versie van de Azure Storage API. Container soft delete is beschikbaar vanaf Azure Storage API versie 2020-06-12 en later. Moderne Azure Storage-accounts gebruiken standaard deze of een nieuwere API-versie, maar organisaties die werken met verouderde storage-accounts moeten controleren of hun account deze API-versie ondersteunt. Dit is met name relevant voor storage-accounts die zijn aangemaakt vóór 2020.

Qua netwerkvereisten is er geen specifieke configuratie nodig, maar organisaties moeten er rekening mee houden dat het herstellen van containers via de Azure Portal, Azure CLI of PowerShell vereist dat de beheerder toegang heeft tot het storage-account via het netwerk. Voor storage-accounts met beperkte netwerktoegang moet de beheerder zich bevinden op een locatie die toegang heeft tot het storage-account, of moet de netwerkconfiguratie tijdelijk worden aangepast voor hersteloperaties.

Een belangrijke overweging betreft de kosten. Hoewel container soft delete zelf geen extra kosten met zich meebrengt voor de functionaliteit, worden verwijderde containers en hun inhoud opgeslagen in de soft delete-status en tellen deze mee voor de storage-kosten. Organisaties moeten daarom rekening houden met de mogelijke toename in storage-kosten, met name wanneer containers regelmatig worden verwijderd en hersteld. De kosten zijn afhankelijk van de hoeveelheid data die in soft delete-status wordt bewaard en de retentieperiode die is geconfigureerd.

Voor organisaties die werken met geografisch redundante opslag (GRS) of geografisch zone-redundante opslag (GZRS) is het belangrijk te weten dat soft delete-containers ook worden gerepliceerd naar de secundaire regio. Dit betekent dat de soft delete-functionaliteit beschikbaar blijft, zelfs bij een regionale uitval, wat de bedrijfscontinuïteit ten goede komt. Organisaties moeten echter rekening houden met de replicatielatentie bij het herstellen van containers in een failover-scenario.

Monitoring

Gebruik PowerShell-script containers-blob-soft-delete.ps1 (functie Invoke-Monitoring) – Automatische controle uitvoeren.

Het monitoren van container soft delete-configuratie is essentieel om te waarborgen dat deze kritieke beveiligingsmaatregel actief blijft en correct is geconfigureerd. Organisaties moeten een gestructureerde monitoringaanpak implementeren die regelmatige controles omvat om te verifiëren dat container soft delete is ingeschakeld voor alle relevante storage-accounts en dat de retentieperiode is ingesteld op minimaal 90 dagen, zoals aanbevolen door de Nederlandse Baseline voor Veilige Cloud.

De monitoringaanpak begint met het regelmatig controleren van de soft delete-configuratie voor elk Azure Storage-account binnen de organisatie. Dit kan worden geautomatiseerd met behulp van PowerShell-scripts die de huidige configuratie ophalen en vergelijken met de gewenste instellingen. Het monitoring script dat beschikbaar is via de scriptReference controleert of container soft delete is ingeschakeld en of de retentieperiode voldoet aan de minimale eis van 90 dagen. Organisaties moeten deze controle minimaal wekelijks uitvoeren, of vaker wanneer er wijzigingen worden aangebracht aan storage-accounts.

Naast het controleren van de configuratie zelf, moeten organisaties ook monitoren of er containers daadwerkelijk in soft delete-status zijn. Dit geeft inzicht in het gebruik van de functionaliteit en kan helpen bij het identificeren van patronen in containerverwijderingen. Wanneer containers regelmatig worden verwijderd, kan dit wijzen op operationele problemen of mogelijke beveiligingsincidenten die nader onderzoek vereisen. Monitoring van soft delete-containers helpt organisaties ook om te bepalen of de retentieperiode voldoende is voor hun behoeften.

Voor organisaties die werken met meerdere Azure-abonnementen of een grote hoeveelheid storage-accounts, is het aanbevolen om een gecentraliseerde monitoringoplossing te implementeren. Dit kan worden bereikt door het gebruik van Azure Policy om te controleren dat alle storage-accounts voldoen aan de soft delete-vereisten, of door het implementeren van een monitoringdashboard dat een overzicht geeft van de compliance-status van alle storage-accounts. Dergelijke oplossingen helpen organisaties om snel afwijkingen te identificeren en corrigerende maatregelen te nemen.

Een belangrijk aspect van monitoring betreft het bijhouden van storage-kosten die gerelateerd zijn aan soft delete. Omdat verwijderde containers en hun inhoud worden bewaard tijdens de retentieperiode, kunnen deze bijdragen aan de totale storage-kosten. Organisaties moeten regelmatig de kosten analyseren die worden gegenereerd door soft delete-data en deze afzetten tegen de waarde van de bescherming die wordt geboden. Wanneer de kosten significant zijn, kunnen organisaties overwegen om de retentieperiode aan te passen, hoewel dit moet worden afgewogen tegen de behoefte aan voldoende hersteltijd.

Ten slotte moeten organisaties alert zijn op wijzigingen in de soft delete-configuratie. Ongeautoriseerde wijzigingen aan deze instelling kunnen wijzen op beveiligingsincidenten of onjuiste configuratieprocessen. Door Azure Activity Logs te monitoren op wijzigingen aan de soft delete-configuratie, kunnen organisaties snel reageren op ongewenste wijzigingen en ervoor zorgen dat de beveiligingsmaatregel actief blijft. Dit is met name belangrijk voor organisaties die werken met meerdere beheerders of geautomatiseerde configuratieprocessen die mogelijk de soft delete-instellingen kunnen overschrijven.

Compliance en Auditing

Container soft delete speelt een cruciale rol in het voldoen aan verschillende compliance-vereisten die van toepassing zijn op Nederlandse overheidsorganisaties en organisaties die werken met gevoelige gegevens. De implementatie van container soft delete draagt direct bij aan het naleven van de Baseline Informatiebeveiliging Overheid (BIO) controle 12.03, die betrekking heeft op gegevensherstel. Deze controle vereist dat organisaties maatregelen treffen om gegevens te kunnen herstellen na verlies of beschadiging, en container soft delete biedt een effectieve technische oplossing om te voldoen aan deze vereiste.

BIO controle 12.03 stelt specifieke eisen aan de mogelijkheid tot gegevensherstel. Organisaties moeten kunnen aantonen dat zij beschikken over mechanismen om gegevens te herstellen die verloren zijn gegaan door accidentele verwijdering, systeemfouten of beveiligingsincidenten. Container soft delete voorziet in deze behoefte door verwijderde containers en hun volledige inhoud te bewaren gedurende een configureerbare retentieperiode, waardoor organisaties in staat zijn om snel en volledig te herstellen van onbedoelde verwijderingen. Voor Nederlandse overheidsorganisaties is het daarom essentieel om container soft delete te implementeren als onderdeel van hun compliance-strategie.

Naast BIO-naleving draagt container soft delete ook bij aan het voldoen aan ISO 27001:2022 controle A.8.13, die betrekking heeft op informatieback-ups. Hoewel container soft delete technisch gezien geen traditionele back-upoplossing is, biedt het vergelijkbare bescherming tegen gegevensverlies en kan het worden beschouwd als een aanvullende laag van gegevensbescherming. ISO 27001:2022 vereist dat organisaties regelmatige back-ups maken van informatie en systemen, en dat deze back-ups worden getest om te verifiëren dat herstel mogelijk is. Container soft delete kan worden gebruikt als aanvulling op traditionele back-upstrategieën, waarbij het snelle herstel biedt voor recent verwijderde containers zonder de noodzaak van volledige back-uprestore-procedures.

Voor organisaties die onder de Algemene Verordening Gegevensbescherming (AVG) vallen, kan container soft delete ook relevant zijn, hoewel dit afhankelijk is van de specifieke context. Wanneer containers persoonsgegevens bevatten, kan het herstellen van verwijderde containers relevant zijn voor het voldoen aan verzoeken om inzage of rectificatie. Organisaties moeten echter ook rekening houden met het recht op vergetelheid, waarbij personen kunnen verzoeken om verwijdering van hun persoonsgegevens. In dergelijke gevallen moeten organisaties ervoor zorgen dat soft delete-containers die persoonsgegevens bevatten niet worden hersteld zonder eerst te verifiëren of er geen actieve verzoeken tot verwijdering zijn.

Voor auditdoeleinden moeten organisaties kunnen aantonen dat container soft delete correct is geconfigureerd en actief is. Dit vereist het bijhouden van configuratielogs die aantonen wanneer soft delete is ingeschakeld, welke retentieperiode is geconfigureerd, en of er wijzigingen zijn aangebracht aan de configuratie. Azure Activity Logs bieden deze informatie en moeten worden bewaard voor de vereiste auditperiode. Organisaties moeten ook documenteren hoe zij gebruikmaken van container soft delete en hoe dit past binnen hun algehele gegevensherstelstrategie.

Bij het voorbereiden van compliance-audits moeten organisaties kunnen demonstreren dat container soft delete daadwerkelijk functioneert zoals bedoeld. Dit kan worden bereikt door periodieke testrestores uit te voeren, waarbij een testcontainer wordt verwijderd en vervolgens wordt hersteld om te verifiëren dat het herstelproces correct werkt. Dergelijke tests moeten worden gedocumenteerd en kunnen worden gebruikt als bewijs tijdens audits dat de organisatie beschikt over werkende gegevensherstelmechanismen. Het is aanbevolen om deze tests minimaal kwartaalijks uit te voeren en de resultaten te documenteren voor auditdoeleinden.

Remediatie

Gebruik PowerShell-script containers-blob-soft-delete.ps1 (functie Invoke-Remediation) – Automatische remediatie uitvoeren.

Wanneer monitoring aangeeft dat container soft delete niet is ingeschakeld of niet correct is geconfigureerd, moeten organisaties onmiddellijk corrigerende maatregelen nemen om deze kritieke beveiligingsmaatregel te activeren. De remediatieprocedure begint met het identificeren van alle storage-accounts die niet voldoen aan de vereisten voor container soft delete. Dit kan worden gedaan met behulp van het beschikbare remediatiescript dat automatisch alle storage-accounts controleert en de configuratie aanpast waar nodig.

Het remediatieproces kan worden uitgevoerd via verschillende methoden, afhankelijk van de voorkeur en mogelijkheden van de organisatie. De meest directe methode is het gebruik van het PowerShell-remediatiescript dat beschikbaar is via de scriptReference. Dit script maakt verbinding met Azure, identificeert storage-accounts die niet voldoen aan de vereisten, en activeert container soft delete met een retentieperiode van 90 dagen. Het script kan worden uitgevoerd voor een specifiek storage-account of voor alle storage-accounts binnen een abonnement of resourcegroep.

Voor organisaties die de voorkeur geven aan een handmatige aanpak, kan container soft delete ook worden geactiveerd via de Azure Portal. De beheerder navigeert naar het storage-account, selecteert Data protection onder de sectie Data management, en activeert Container soft delete met de gewenste retentieperiode. Het is belangrijk om minimaal 90 dagen in te stellen, zoals aanbevolen door de Nederlandse Baseline voor Veilige Cloud, om voldoende tijd te hebben voor hersteloperaties na accidentele verwijderingen.

Na het activeren van container soft delete moeten organisaties verifiëren dat de configuratie correct is toegepast. Dit kan worden gedaan door de configuratie opnieuw te controleren met het monitoring script of door de instellingen handmatig te verifiëren in de Azure Portal. Het is aanbevolen om direct na de remediatie een verificatie uit te voeren om te waarborgen dat de wijziging succesvol is doorgevoerd en dat er geen configuratiefouten zijn opgetreden.

Voor organisaties die werken met Infrastructure as Code (IaC) of geautomatiseerde configuratiebeheer, moet de remediatie ook worden doorgevoerd in de configuratiebestanden. Dit voorkomt dat toekomstige deployments de soft delete-configuratie overschrijven en zorgt ervoor dat nieuwe storage-accounts automatisch worden geconfigureerd met container soft delete. Organisaties die gebruikmaken van Terraform, ARM-templates of Bicep moeten hun templates bijwerken om container soft delete standaard in te schakelen voor alle nieuwe storage-accounts.

Een belangrijk aandachtspunt bij remediatie betreft bestaande containers die mogelijk al zijn verwijderd voordat soft delete was geactiveerd. Deze containers kunnen niet worden hersteld, omdat soft delete alleen van toepassing is op verwijderingen die plaatsvinden nadat de functie is ingeschakeld. Organisaties moeten daarom zo snel mogelijk container soft delete activeren om toekomstige verwijderingen te beschermen. Voor kritieke workloads kan het ook zinvol zijn om te evalueren of er recent verwijderde containers zijn die mogelijk moeten worden hersteld via andere methoden, zoals back-ups, indien beschikbaar.

Na succesvolle remediatie moeten organisaties ervoor zorgen dat de wijziging wordt gedocumenteerd en dat het monitoringproces wordt aangepast om toekomstige afwijkingen snel te detecteren. Het is ook aanbevolen om teamleden te informeren over de activatie van container soft delete en hen te trainen in het gebruik van de herstelfunctionaliteit, zodat zij weten hoe zij verwijderde containers kunnen herstellen wanneer dat nodig is. Dit draagt bij aan een effectieve operationele praktijk en zorgt ervoor dat de organisatie optimaal profiteert van deze beveiligingsmaatregel.

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 Containers Blob Soft Delete .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.6 Controleert container-level soft delete voor blobs. .NOTES Filename: containers-blob-soft-delete.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.6 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Containers Blob Soft Delete" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue $result = @{ TotalAccounts = $storageAccounts.Count; WithContainerSoftDelete = 0 } foreach ($account in $storageAccounts) { $blobService = Get-AzStorageBlobServiceProperty -ResourceGroupName $account.ResourceGroupName -StorageAccountName $account.StorageAccountName -ErrorAction SilentlyContinue if ($blobService.ContainerDeleteRetentionPolicy.Enabled) { $result.WithContainerSoftDelete++ } } 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 Container Soft Delete: $($r.WithContainerSoftDelete)" -ForegroundColor $(if ($r.WithContainerSoftDelete -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nContainer Soft Delete: $($r.WithContainerSoftDelete)/$($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 Container Soft Delete: $($r.WithContainerSoftDelete)" -ForegroundColor $(if ($r.WithContainerSoftDelete -eq $r.TotalAccounts) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nContainer Soft Delete: $($r.WithContainerSoftDelete)/$($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
Medium: Zonder container soft delete leidt verwijdering van een container tot permanent verlies van de container en alle daarin opgeslagen blobs. Dit kan resulteren in onherstelbaar gegevensverlies, operationele verstoringen en compliance-schendingen. De organisatie voldoet niet aan BIO controle 12.03 voor gegevensherstel. Het risiconiveau is medium, met name vanwege de impact op containerherstel en bedrijfscontinuïteit.

Management Samenvatting

Container Soft Delete: Activeer soft delete voor containers met een retentieperiode van minimaal 90 dagen. Hiermee kunnen verwijderde containers en hun volledige inhoud worden hersteld binnen de retentieperiode. Activatie via Storage Account → Gegevensbescherming → Container soft delete. De functionaliteit zelf is kosteloos, alleen de opslag van soft delete-data brengt minimale kosten met zich mee. Verplicht voor naleving van BIO controle 12.03. Implementatietijd: ongeveer 30 minuten. Biedt een aanvullende beveiligingslaag tegen permanent gegevensverlies.