L1 BIO 12.03.01 ISO A.8.13 CIS 7.3

Onveranderlijke Back-upopslag Geconfigureerd

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

💼 Management Samenvatting

Onveranderlijke back-upopslag vormt een kritieke beveiligingslaag die ervoor zorgt dat back-ups in Azure Recovery Services-kluizen niet kunnen worden gewijzigd of verwijderd gedurende de bewaartermijn, zelfs niet door beheerders met de hoogste rechten. Deze functionaliteit implementeert het WORM-principe (Write Once Read Many) op back-upopslag en biedt essentiële bescherming tegen ransomware-aanvallen, onbevoegde wijzigingen en accidentele verwijdering. Voor Nederlandse overheidsorganisaties is onveranderlijke back-upopslag een fundamentele vereiste om te voldoen aan compliance-eisen zoals BIO-paragraaf 12.03, ISO 27001 control A.8.13, AVG artikel 32 en de aankomende NIS2-richtlijn, waarbij aantoonbaar moet worden gemaakt dat back-ups beschermd zijn tegen manipulatie en verwijdering.

Aanbeveling
IMPLEMENTEER onveranderlijke back-upopslag voor alle kritieke Recovery Services-kluizen en back-upbeleid zodat back-ups beschermd zijn tegen ransomware-aanvallen, onbevoegde wijzigingen en accidentele verwijdering.
Risico zonder
Critical
Risk Score
10/10
Implementatie
3u (tech: 2u)
Van toepassing op:
✓ Azure Tenant
✓ Recovery Services Vault
✓ Azure Backup

Zonder onveranderlijke back-upopslag lopen organisaties het kritieke risico dat ransomware-aanvallen of kwaadaardige actoren back-ups kunnen verwijderen of versleutelen voordat een herstelactie kan worden uitgevoerd. Moderne ransomware-varianten zijn specifiek ontworpen om back-ups te targeten als onderdeel van hun aanvalsstrategie, waarbij zij eerst alle beschikbare back-ups verwijderen voordat zij de primaire systemen versleutelen. Zonder onveranderlijke opslag kunnen zelfs beheerders met de hoogste rechten back-ups per ongeluk of opzettelijk verwijderen, wat kan leiden tot onherstelbaar gegevensverlies en volledige uitval van kritieke diensten. Voor Nederlandse overheidsorganisaties die essentiële diensten leveren aan burgers, kan dit leiden tot bestuurlijke verantwoordelijkheid, reputatieschade en mogelijke boetes van toezichthouders. Bovendien verlangen wettelijke kaders zoals de BIO-paragraaf 12.03, ISO 27001 control A.8.13, AVG artikel 32 en de aankomende NIS2-richtlijn dat organisaties aantoonbaar in staat zijn om beschikbaarheid en integriteit snel te herstellen, waarbij back-ups beschermd moeten zijn tegen manipulatie. Zonder onveranderlijke back-upopslag mislukt iedere audit op deze onderdelen, wat kan resulteren in aanwijzingen, dwangsommen of zelfs intrekking van vergunningen. Denk aan scenario's waarbij een kritieke mGBA-omgeving of een zaaksysteem van een gemeente wordt getroffen door een zero-day exploit: zonder onveranderlijke back-ups kan een aanvaller alle herstelopties elimineren door back-ups te verwijderen, waardoor de organisatie volledig afhankelijk wordt van onderhandelingen met criminelen. Door onveranderlijke back-upopslag te implementeren bouwt men een laatste verdedigingslinie op die zelfs bij volledige compromittering van beheerdersaccounts de integriteit van back-ups waarborgt.

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

Implementatie

Onveranderlijke back-upopslag in Azure Backup wordt geïmplementeerd via de immutability-functionaliteit van Recovery Services-kluizen, waarbij back-ups worden beschermd tegen wijziging of verwijdering gedurende een vooraf bepaalde bewaartermijn. Deze functionaliteit werkt op basis van een time-based retention lock die wordt toegepast op back-upbeleid, waardoor alle herstelpunten die onder dit beleid vallen automatisch onveranderlijk worden gemaakt. Eenmaal geactiveerd kunnen back-ups niet worden gewijzigd of verwijderd, zelfs niet door beheerders met de hoogste rechten, totdat de bewaartermijn is verstreken. De immutability-functionaliteit integreert naadloos met bestaande back-upbeleid en vereist geen aanvullende configuratie per resource, waardoor organisaties eenvoudig alle kritieke workloads kunnen beschermen. Azure Backup ondersteunt zowel time-based retention locks als legal hold-functionaliteit, waarbij time-based locks een vaste bewaartermijn opleggen en legal hold flexibele bescherming biedt voor juridische doeleinden. De functionaliteit werkt op alle back-uptypen, inclusief virtuele machines, SQL-databases, bestandsshares en workloads die draaien op Azure Arc, en biedt volledige bescherming tegen ransomware, onbevoegde wijzigingen en accidentele verwijdering. Organisaties kunnen immutability activeren via het Azure-portaal, PowerShell of Azure Policy, waarbij de configuratie automatisch wordt toegepast op alle nieuwe en bestaande herstelpunten die onder het betreffende beleid vallen.

Vereisten

Voor het inschakelen en effectief gebruiken van onveranderlijke back-upopslag in Azure Backup zijn specifieke licentievereisten, beheerdersbevoegdheden en technische configuraties noodzakelijk. Deze vereisten vormen de fundamentele basis voor een succesvolle implementatie van immutability-functionaliteit en zijn essentieel om te kunnen voldoen aan compliance-vereisten en beveiligingsbest practices. Organisaties die deze vereisten niet volledig begrijpen of implementeren, lopen het risico dat zij niet beschikken over de benodigde bescherming tegen ransomware-aanvallen en niet kunnen voldoen aan wettelijke verplichtingen zoals vastgelegd in de AVG, NIS2 richtlijn en de Baseline Informatiebeveiliging Overheid.

De primaire licentievereiste voor onveranderlijke back-upopslag is een Azure Backup-abonnement dat immutability-functionaliteit ondersteunt. Deze functionaliteit is beschikbaar voor alle Recovery Services-kluizen die gebruikmaken van Azure Backup, ongeacht het licentiemodel, maar vereist dat de kluis is geconfigureerd met de juiste opslagredundantie en versleutelingsinstellingen. Voor organisaties die moeten voldoen aan strikte compliance-eisen zoals SEC 17a-4 of FINRA voor financiële instellingen, is onveranderlijke back-upopslag verplicht en moet deze worden geactiveerd voor alle kritieke back-ups. Het is belangrijk te realiseren dat immutability-functionaliteit niet kan worden uitgeschakeld zodra deze is geactiveerd, totdat de bewaartermijn is verstreken, waardoor organisaties zorgvuldig moeten plannen voordat zij deze functionaliteit activeren.

Naast licentievereisten is een specifieke beheerdersrol vereist om onveranderlijke back-upopslag te kunnen configureren en beheren. De Backup Contributor rol is de primaire rol die nodig is voor het activeren van immutability-functionaliteit op Recovery Services-kluizen en back-upbeleid. Deze rol kan worden toegewezen via het Azure-portaal, Azure CLI of PowerShell met behulp van de Az.Resources module. De Backup Contributor beschikt over de benodigde rechten om immutability-functionaliteit in te schakelen, back-upbeleid te configureren en retention locks te beheren. Het is belangrijk te realiseren dat deze rol gevoelige bevoegdheden bevat, omdat immutability-functionaliteit niet kan worden uitgeschakeld zodra deze is geactiveerd, waardoor configuratiefouten permanente gevolgen kunnen hebben. Daarom moet de rol alleen worden toegewezen aan vertrouwde beheerders die een security clearance hebben en die zijn getraind in het omgaan met immutability-functionaliteit. Organisaties moeten een proces implementeren voor het toewijzen en beheren van deze rol, inclusief regelmatige reviews om te verifiëren dat alleen geautoriseerde personen toegang hebben tot immutability-configuratie.

Voor organisaties die onveranderlijke back-upopslag willen automatiseren via Azure Policy of PowerShell-scripts, zijn aanvullende configuraties en machtigingen vereist. De automatisering van immutability-functionaliteit vereist dat de organisatie beschikt over een service principal of managed identity met de benodigde machtigingen om back-upbeleid te wijzigen en retention locks te activeren. Deze automatisering maakt het mogelijk om immutability-functionaliteit op schaal uit te rollen binnen meerdere abonnementen en resourcegroepen, wat essentieel kan zijn voor organisaties die moeten voldoen aan compliance-vereisten die onveranderlijke back-upopslag verplicht stellen voor alle kritieke workloads. Daarnaast biedt automatisering de mogelijkheid om immutability-functionaliteit te integreren met bestaande change management-processen, waardoor wijzigingen worden gedocumenteerd en goedgekeurd voordat zij worden doorgevoerd.

Technische vereisten omvatten ook de beschikbaarheid van PowerShell-modules en de juiste netwerkconnectiviteit. Beheerders die onveranderlijke back-upopslag willen configureren via PowerShell moeten beschikken over de Az.RecoveryServices module, die kan worden geïnstalleerd via de PowerShell Gallery. Deze module bevat de benodigde cmdlets voor het werken met immutability-functionaliteit, zoals Set-AzRecoveryServicesBackupProtectionPolicy voor het configureren van retention locks en Get-AzRecoveryServicesBackupProtectionPolicy voor het controleren van de huidige configuratie. Daarnaast moeten beheerders beschikken over netwerkconnectiviteit naar Azure-services, wat meestal betekent dat zij toegang hebben tot internet of dat er een ExpressRoute-verbinding is geconfigureerd voor organisaties die privéconnectiviteit vereisen. Voor organisaties met strikte netwerkbeveiliging kunnen aanvullende firewallregels nodig zijn om toegang te verlenen tot de benodigde Azure-endpoints voor immutability-functionaliteit.

Het is cruciaal te realiseren dat zonder de juiste licentie en bevoegdheden de onveranderlijke back-upopslag functionaliteit niet beschikbaar is en organisaties niet kunnen voldoen aan compliance-vereisten zoals vastgelegd in de AVG, NIS2 richtlijn en andere relevante wet- en regelgeving voor de Nederlandse publieke sector. Het ontbreken van adequate immutability-functionaliteit kan leiden tot niet-naleving van deze vereisten, wat kan resulteren in boetes, reputatieschade en juridische aansprakelijkheid. Daarom moeten organisaties ervoor zorgen dat alle vereisten volledig zijn geïmplementeerd voordat zij afhankelijk worden van onveranderlijke back-upopslag voor compliance-doeleinden of ransomware-bescherming.

Implementatie

Gebruik PowerShell-script immutable-backup-storage.ps1 (functie Invoke-Implementation) – Gebruik dit PowerShell-script om op schaal onveranderlijke back-upopslag te activeren voor Recovery Services-kluizen en back-upbeleid binnen meerdere abonnementen met uniforme logging en foutafhandeling..

De implementatie van onveranderlijke back-upopslag in Azure Backup vereist een gestructureerde aanpak die begint met verificatie van de huidige back-upconfiguratie, gevolgd door activatie van immutability-functionaliteit en validatie van de bescherming. Hoewel immutability-functionaliteit beschikbaar is voor alle Recovery Services-kluizen, is het essentieel om te verifiëren dat de functionaliteit daadwerkelijk is geactiveerd en dat alle benodigde back-upbeleid zijn geconfigureerd met retention locks. Het ontbreken van deze verificatie kan leiden tot situaties waarin organisaties ervan uitgaan dat back-ups onveranderlijk zijn, terwijl in werkelijkheid bepaalde back-ups nog steeds kunnen worden gewijzigd of verwijderd, wat kan resulteren in kwetsbaarheden voor ransomware-aanvallen en niet-naleving van compliance-vereisten.

De eerste stap in het implementatieproces is het navigeren naar het Azure-portaal en het selecteren van de Recovery Services-kluis waarin de back-ups zijn opgeslagen. Een beheerder met de Backup Contributor rol kan hier naar de Back-upbeleid sectie navigeren en de status van immutability-functionaliteit controleren. In de Back-upbeleid sectie wordt getoond welke beleidsregels zijn geconfigureerd en of retention locks zijn geactiveerd. Hoewel immutability-functionaliteit meestal niet standaard is ingeschakeld, is het belangrijk om expliciet te verifiëren dat de functie 'Retention Lock' is geactiveerd voor alle kritieke back-upbeleid en dat er geen waarschuwingen of foutmeldingen zijn die kunnen wijzen op problemen met de configuratie. Als immutability-functionaliteit niet is ingeschakeld, kan dit worden geactiveerd door het betreffende back-upbeleid te selecteren en de 'Retention Lock' optie in te schakelen, waarna Azure Backup begint met het beschermen van alle herstelpunten die onder dit beleid vallen.

Na het activeren van immutability-functionaliteit is het essentieel om te controleren of retention locks daadwerkelijk zijn toegepast op back-upbeleid en of herstelpunten correct worden beschermd. Deze verificatie kan worden uitgevoerd via PowerShell met behulp van de cmdlet Get-AzRecoveryServicesBackupProtectionPolicy uit de Az.RecoveryServices module. Deze cmdlet stelt beheerders in staat om de configuratie van back-upbeleid te controleren, inclusief de status van retention locks en de bewaartermijn. Door een testcontrole uit te voeren kunnen beheerders verifiëren dat retention locks zijn geactiveerd voor verschillende back-uptypen, zoals virtuele machines, SQL-databases en bestandsshares. Als de controle geen retention locks oplevert of als bepaalde back-uptypen ontbreken, kan dit wijzen op problemen met de configuratie die moeten worden opgelost voordat de organisatie kan vertrouwen op onveranderlijke back-upopslag voor ransomware-bescherming.

De bewaartermijn voor onveranderlijke back-upopslag is afhankelijk van de configuratie van het back-upbeleid: organisaties kunnen retention locks activeren voor de volledige bewaartermijn van het beleid, waardoor alle herstelpunten onveranderlijk worden gemaakt gedurende de gehele retentieperiode. Deze bewaartermijn kan variëren van enkele dagen tot meerdere jaren, afhankelijk van de compliance-vereisten en bedrijfscontinuïteitsdoelstellingen van de organisatie. Het is belangrijk te realiseren dat retention locks niet kunnen worden uitgeschakeld zodra zij zijn geactiveerd, totdat de bewaartermijn is verstreken, waardoor organisaties zorgvuldig moeten plannen voordat zij deze functionaliteit activeren. Voor organisaties die langere bewaartermijnen nodig hebben, bijvoorbeeld voor compliance-doeleinden of wettelijke verplichtingen die langere retentieperiodes vereisen, kunnen retention locks worden geconfigureerd voor de volledige bewaartermijn van het back-upbeleid, wat essentieel kan zijn voor organisaties die moeten voldoen aan compliance-frameworks zoals de AVG, NIS2 richtlijn of de Baseline Informatiebeveiliging Overheid die langere retentieperiodes kunnen vereisen.

De configuratie van retention locks kan worden geautomatiseerd via Azure Policy, waardoor organisaties kunnen afdwingen dat alle nieuwe back-upbeleid automatisch worden geconfigureerd met immutability-functionaliteit. Deze automatisering maakt het mogelijk om onveranderlijke back-upopslag op schaal uit te rollen binnen meerdere abonnementen en resourcegroepen, wat essentieel kan zijn voor organisaties die moeten voldoen aan compliance-vereisten die onveranderlijke back-upopslag verplicht stellen voor alle kritieke workloads. Eenmaal geconfigureerd, worden retention locks automatisch toegepast op alle nieuwe back-upbeleid die worden gemaakt, waardoor organisaties kunnen garanderen dat alle kritieke back-ups worden beschermd tegen wijziging of verwijdering. Deze automatisering biedt organisaties de mogelijkheid om onveranderlijke back-upopslag te integreren met bestaande change management-processen, waardoor wijzigingen worden gedocumenteerd en goedgekeurd voordat zij worden doorgevoerd.

Na het configureren van onveranderlijke back-upopslag en eventuele automatisering via Azure Policy, is het belangrijk om regelmatig te verifiëren dat de functionaliteit correct blijft functioneren. Dit kan worden gedaan door periodiek testcontroles uit te voeren via PowerShell of via het Azure-portaal om te verifiëren dat retention locks zijn geactiveerd voor verschillende back-uptypen. Daarnaast moeten organisaties processen implementeren voor het monitoren van de gezondheid van de immutability-functionaliteit, inclusief het controleren van de status van retention locks en het verifiëren dat back-ups correct worden beschermd. Door deze verificaties regelmatig uit te voeren kunnen organisaties ervoor zorgen dat zij altijd beschikken over onveranderlijke back-upopslag die essentieel is voor ransomware-bescherming en compliance-doeleinden.

Compliance en Auditing

Onveranderlijke back-upopslag is een fundamentele vereiste voor naleving van verschillende cybersecurity frameworks en wet- en regelgeving die van toepassing zijn op Nederlandse overheidsorganisaties. Zonder onveranderlijke back-upopslag kunnen organisaties niet voldoen aan de vereisten van internationale standaarden zoals CIS, ISO 27001 en sectorspecifieke regelgeving zoals de AVG en NIS2 richtlijn. Deze frameworks vereisen allemaal dat organisaties kunnen aantonen dat zij passende maatregelen hebben genomen om back-ups te beschermen tegen wijziging of verwijdering, wat essentieel is voor het waarborgen van beveiliging, transparantie en verantwoording. Het ontbreken van adequate onveranderlijke back-upopslag kan leiden tot niet-naleving van deze vereisten, wat kan resulteren in boetes, reputatieschade en juridische aansprakelijkheid.

De CIS Microsoft Azure Foundations Benchmark controle 7.3 specificeert expliciet dat Azure Backup moet worden geconfigureerd voor Azure-resources, waarbij onveranderlijke back-upopslag wordt aanbevolen als best practice voor ransomware-bescherming. Deze controle vormt een essentieel onderdeel van de CIS Controls en is verplicht voor organisaties die streven naar een solide beveiligingsbasis. De CIS Microsoft Azure Foundations Benchmark is een uitgebreide set van beveiligingsaanbevelingen die specifiek zijn ontwikkeld voor Azure-omgevingen en die organisaties helpen om hun beveiligingspostuur te verbeteren. Controle 7.3 vereist niet alleen dat Azure Backup is geconfigureerd, maar ook dat organisaties kunnen aantonen dat zij passende maatregelen hebben genomen om back-ups te beschermen tegen wijziging of verwijdering, wat onveranderlijke back-upopslag essentieel maakt. Het niet implementeren van deze controle resulteert in een failed audit finding, wat kan leiden tot compliance-problemen bij klanten of partners die CIS-compliance vereisen.

De Baseline Informatiebeveiliging Overheid (BIO) norm 12.03 vereist dat organisaties reservekopieën periodiek, gecontroleerd en beveiligd opslaan buiten de primaire productieomgeving, waarbij back-ups beschermd moeten zijn tegen manipulatie en verwijdering. Deze norm is specifiek ontwikkeld voor de Nederlandse publieke sector en stelt eisen aan de bescherming van back-ups tegen wijziging of verwijdering. De BIO is een verplicht framework voor Nederlandse overheidsorganisaties en vormt de basis voor informatiebeveiliging binnen de publieke sector. Norm 12.03 specificeert dat organisaties moeten kunnen aantonen dat zij alle relevante back-ups beschermen tegen wijziging of verwijdering, dat deze bescherming wordt bewaard voor de vereiste periode, en dat er processen zijn geïmplementeerd voor het analyseren en reageren op beveiligingsincidenten. Voor Azure Backup-omgevingen betekent dit dat onveranderlijke back-upopslag moet zijn geactiveerd en dat organisaties kunnen aantonen dat zij regelmatig de status van retention locks controleren en dat zij processen hebben voor het reageren op beveiligingsincidenten.

De ISO 27001 standaard, controle A.8.13, vereist eveneens dat organisaties back-ups beschermen tegen wijziging of verwijdering en dat zij kunnen aantonen dat back-ups beschikbaar zijn voor hersteldoeleinden. Deze internationale standaard wordt veelvuldig gebruikt door Nederlandse organisaties die certificering nastreven en vormt een belangrijke basis voor informatiebeveiligingsmanagement. Controle A.8.13 specificeert dat organisaties moeten kunnen aantonen dat zij alle relevante back-ups beschermen tegen wijziging of verwijdering, dat deze bescherming wordt bewaard voor de vereiste periode, en dat er processen zijn geïmplementeerd voor het analyseren en reageren op beveiligingsincidenten. Voor Azure Backup-omgevingen betekent dit dat onveranderlijke back-upopslag moet zijn geactiveerd en dat organisaties kunnen aantonen dat zij voldoen aan de vereisten van deze controle. Het niet implementeren van adequate onveranderlijke back-upopslag kan leiden tot niet-naleving van ISO 27001, wat kan resulteren in het verlies van certificering en reputatieschade.

De Algemene Verordening Gegevensbescherming (AVG), Artikel 32, verplicht organisaties om passende technische en organisatorische maatregelen te treffen om persoonsgegevens te beveiligen, waarbij bescherming van back-ups tegen wijziging of verwijdering een essentieel onderdeel vormt. Artikel 32 specificeert dat organisaties moeten kunnen aantonen dat zij passende maatregelen hebben genomen om persoonsgegevens te beveiligen, wat onder andere betekent dat zij moeten kunnen garanderen dat back-ups beschermd zijn tegen wijziging of verwijdering. Voor Azure Backup-omgevingen betekent dit dat onveranderlijke back-upopslag moet zijn geactiveerd en dat organisaties kunnen aantonen dat zij back-ups beschermen tegen wijziging of verwijdering. Het niet implementeren van adequate onveranderlijke back-upopslag kan leiden tot niet-naleving van de AVG, wat kan resulteren in boetes tot 4 procent van de wereldwijde jaaromzet of 20 miljoen euro, afhankelijk van wat hoger is.

De NIS2 richtlijn, Artikel 21, stelt specifieke eisen aan essentiële en belangrijke entiteiten met betrekking tot incident reporting en bescherming van back-ups tegen wijziging of verwijdering. Nederlandse organisaties die onder de reikwijdte van NIS2 vallen, moeten kunnen aantonen dat zij beschikken over adequate bescherming van back-ups tegen wijziging of verwijdering om beveiligingsincidenten te kunnen detecteren, te onderzoeken en te rapporteren aan de bevoegde autoriteiten. Artikel 21 specificeert dat organisaties moeten kunnen aantonen dat zij passende maatregelen hebben genomen om back-ups te beschermen tegen wijziging of verwijdering, wat onder andere betekent dat zij moeten beschikken over onveranderlijke back-upopslag die alle relevante back-ups beschermt. Voor Azure Backup-omgevingen betekent dit dat onveranderlijke back-upopslag moet zijn geactiveerd en dat organisaties kunnen aantonen dat zij back-ups beschermen tegen wijziging of verwijdering. Het niet implementeren van adequate onveranderlijke back-upopslag kan leiden tot niet-naleving van NIS2, wat kan resulteren in boetes en andere handhavingsmaatregelen door de Autoriteit Consument en Markt (ACM) of andere toezichthouders.

Monitoring

Gebruik PowerShell-script immutable-backup-storage.ps1 (functie Invoke-Monitoring) – Automatiseert de verificatie van onveranderlijke back-upopslag status en controleert of retention locks zijn geactiveerd voor alle kritieke back-upbeleid.

Effectieve monitoring van onveranderlijke back-upopslag in Azure Backup is essentieel om te waarborgen dat de functionaliteit correct blijft functioneren en dat organisaties altijd beschikken over bescherming tegen ransomware-aanvallen en onbevoegde wijzigingen. Zonder uitgebreide monitoring kunnen organisaties niet garanderen dat retention locks actief zijn, dat alle relevante back-upbeleid zijn geconfigureerd met immutability-functionaliteit, en dat er geen problemen zijn met de configuratie die kunnen leiden tot kwetsbaarheden voor ransomware-aanvallen. Monitoring omvat het continu volgen van de status van retention locks, het verifiëren dat retention locks zijn geactiveerd voor verschillende back-uptypen, het controleren van de gezondheid van de immutability-functionaliteit, en het waarborgen dat automatisering via Azure Policy correct functioneert.

De basis van monitoring wordt gevormd door regelmatige verificatie van de status van retention locks via het Azure-portaal of via PowerShell. Beheerders moeten wekelijks controleren of retention locks zijn geactiveerd voor alle kritieke back-upbeleid en of er geen waarschuwingen of foutmeldingen zijn die kunnen wijzen op problemen met de configuratie. Deze verificatie kan worden geautomatiseerd via PowerShell-scripts die de status van retention locks controleren en waarschuwingen genereren wanneer retention locks niet zijn geactiveerd of wanneer er problemen worden gedetecteerd. Het is belangrijk om deze verificaties regelmatig uit te voeren, omdat configuratiewijzigingen of beheerdersfouten kunnen leiden tot het onbedoeld uitschakelen van retention locks, wat kan resulteren in kwetsbaarheden voor ransomware-aanvallen en niet-naleving van compliance-vereisten.

Naast het controleren van de status van retention locks moeten organisaties regelmatig verifiëren dat retention locks daadwerkelijk zijn toegepast op verschillende back-uptypen. Dit kan worden gedaan door testcontroles uit te voeren via PowerShell met behulp van de Get-AzRecoveryServicesBackupProtectionPolicy cmdlet, waarbij wordt gecontroleerd of retention locks zijn geactiveerd voor verschillende back-uptypen zoals virtuele machines, SQL-databases en bestandsshares. Als de controle geen retention locks oplevert of als bepaalde back-uptypen ontbreken, kan dit wijzen op problemen met de configuratie die moeten worden opgelost. Organisaties moeten processen implementeren voor het regelmatig uitvoeren van deze verificaties, waarbij wekelijks wordt gecontroleerd of retention locks zijn geactiveerd voor verschillende back-uptypen en waarbij waarschuwingen worden gegenereerd wanneer problemen worden gedetecteerd.

Voor organisaties die retention locks automatiseren via Azure Policy, is het essentieel om te monitoren of de automatisering correct functioneert. Dit omvat het controleren of retention locks daadwerkelijk worden geactiveerd voor nieuwe back-upbeleid, of er geen fouten zijn in het automatiseringproces, en of de automatisering binnen de verwachte tijdsframes plaatsvindt. Problemen met de automatisering kunnen leiden tot situaties waarin nieuwe back-upbeleid niet worden beschermd door retention locks, wat kan resulteren in kwetsbaarheden voor ransomware-aanvallen en problemen met compliance-doeleinden. Organisaties moeten processen implementeren voor het monitoren van de automatisering-functionaliteit, waarbij dagelijks wordt gecontroleerd of automatisering correct functioneert en waarbij waarschuwingen worden gegenereerd wanneer problemen worden gedetecteerd.

Daarnaast moeten organisaties processen implementeren voor het monitoren van de gezondheid van de immutability-functionaliteit, inclusief het controleren van de status van retention locks en het verifiëren dat back-ups correct worden beschermd. Als retention locks niet actief zijn of als er problemen zijn met de configuratie, kunnen nieuwe back-ups niet worden beschermd, wat kan resulteren in kwetsbaarheden voor ransomware-aanvallen. Organisaties moeten waarschuwingen configureren die worden gegenereerd wanneer retention locks niet actief zijn, zodat proactieve maatregelen kunnen worden genomen om te voorkomen dat back-ups kwetsbaar worden voor ransomware-aanvallen. Voor organisaties die langere bewaartermijnen nodig hebben, is het belangrijk om te overwegen om retention locks te configureren voor de volledige bewaartermijn van het back-upbeleid, waar langere bewaartermijnen mogelijk zijn zonder de beperkingen van standaard back-upopslag.

Remediatie

Gebruik PowerShell-script immutable-backup-storage.ps1 (functie Invoke-Remediation) – Activeert retention locks voor back-upbeleid wanneer deze niet zijn geactiveerd en verifieert de configuratie.

Remediatie van onveranderlijke back-upopslag in Azure Backup omvat het activeren van retention locks voor back-upbeleid wanneer deze niet zijn geactiveerd, het corrigeren van configuratiefouten, en het waarborgen dat alle relevante back-upbeleid zijn geconfigureerd met immutability-functionaliteit. Het is belangrijk om te realiseren dat wanneer retention locks niet zijn geactiveerd, back-ups kunnen worden gewijzigd of verwijderd, wat kan resulteren in kwetsbaarheden voor ransomware-aanvallen en niet-naleving van compliance-vereisten. Daarom moeten organisaties processen implementeren voor het snel detecteren en oplossen van problemen met retention locks, zodat de impact op de beveiliging wordt geminimaliseerd.

Wanneer retention locks niet zijn geactiveerd voor back-upbeleid, kan dit worden geactiveerd via het Azure-portaal door te navigeren naar de Back-upbeleid sectie en de 'Retention Lock' optie in te schakelen voor het betreffende beleid. Na het activeren van retention locks begint Azure Backup onmiddellijk met het beschermen van alle herstelpunten die onder dit beleid vallen, maar het is belangrijk om te realiseren dat herstelpunten die zijn gemaakt voordat retention locks zijn geactiveerd, niet worden beschermd. Daarom moeten organisaties processen implementeren voor het snel detecteren wanneer retention locks niet zijn geactiveerd, zodat retention locks zo snel mogelijk kunnen worden geactiveerd en de impact op de beveiliging wordt geminimaliseerd.

Na het activeren van retention locks is het essentieel om te verifiëren dat de functionaliteit correct werkt en dat retention locks zijn toegepast op verschillende back-uptypen. Dit kan worden gedaan door testcontroles uit te voeren via PowerShell met behulp van de Get-AzRecoveryServicesBackupProtectionPolicy cmdlet, waarbij wordt gecontroleerd of retention locks zijn geactiveerd voor verschillende back-uptypen. Als de controle geen retention locks oplevert of als bepaalde back-uptypen ontbreken, kan dit wijzen op problemen met de configuratie die moeten worden opgelost. Organisaties moeten processen implementeren voor het uitvoeren van deze verificaties na het activeren van retention locks, zodat kan worden bevestigd dat de functionaliteit correct werkt voordat de organisatie weer afhankelijk wordt van onveranderlijke back-upopslag voor ransomware-bescherming.

Voor organisaties die retention locks automatiseren via Azure Policy, is het belangrijk om te verifiëren dat de automatisering correct functioneert na het activeren van retention locks. Dit omvat het controleren of retention locks daadwerkelijk worden geactiveerd voor nieuwe back-upbeleid, of er geen fouten zijn in het automatiseringproces, en of de automatisering binnen de verwachte tijdsframes plaatsvindt. Als er problemen zijn met de automatisering, moeten deze worden opgelost voordat de organisatie weer afhankelijk wordt van onveranderlijke back-upopslag voor ransomware-bescherming. Organisaties moeten processen implementeren voor het verifiëren van de automatisering-functionaliteit na het activeren van retention locks, zodat kan worden bevestigd dat de automatisering correct werkt.

Daarnaast moeten organisaties processen implementeren voor het onderzoeken van de oorzaak van het niet activeren van retention locks, zodat preventieve maatregelen kunnen worden genomen om te voorkomen dat het probleem opnieuw optreedt. Dit kan bijvoorbeeld betekenen dat beheerders moeten worden getraind in het belang van onveranderlijke back-upopslag, dat configuratiewijzigingen moeten worden gereviewd voordat zij worden doorgevoerd, of dat aanvullende controles moeten worden geïmplementeerd om te voorkomen dat retention locks onbedoeld niet worden geactiveerd. Door deze preventieve maatregelen te implementeren kunnen organisaties ervoor zorgen dat retention locks continu actief blijven en dat er geen kwetsbaarheden ontstaan voor ransomware-aanvallen die kunnen leiden tot niet-naleving van compliance-vereisten.

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
<# .SYNOPSIS Onveranderlijke back-upopslag geconfigureerd .DESCRIPTION CIS Azure Foundations Benchmark - Control 7.3 Controleert of onveranderlijke back-upopslag (immutable backup storage) is geconfigureerd voor Recovery Services-kluizen en back-upbeleid. Deze functionaliteit implementeert het WORM-principe (Write Once Read Many) op back-upopslag en biedt essentiële bescherming tegen ransomware-aanvallen, onbevoegde wijzigingen en accidentele verwijdering. .NOTES Filename: immutable-backup-storage.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-27 Version: 1.0 CIS Control: 7.3 Category: Backup Workload: Azure Related JSON: content/azure/backup/immutable-backup-storage.json .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\immutable-backup-storage.ps1 -Monitoring Check compliance status van onveranderlijke back-upopslag .EXAMPLE .\immutable-backup-storage.ps1 -Remediation Activeer retention locks voor back-upbeleid .EXAMPLE .\immutable-backup-storage.ps1 -Remediation -WhatIf Show what would be changed without applying #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.RecoveryServices, Az.Resources [CmdletBinding()] param( [Parameter(HelpMessage = "Monitor current configuration status")] [switch]$Monitoring, [Parameter(HelpMessage = "Apply recommended configuration")] [switch]$Remediation, [Parameter(HelpMessage = "Revert to previous configuration")] [switch]$Revert, [Parameter(HelpMessage = "Show what would happen without making changes")] [switch]$WhatIf ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' # ============================================================================ # HEADER # ============================================================================ Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Onveranderlijke back-upopslag geconfigureerd" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan # ============================================================================ # FUNCTIONS # ============================================================================ function Connect-RequiredServices { <# .SYNOPSIS Maakt verbinding met Azure-services #> [CmdletBinding()] param() try { if (-not (Get-AzContext -ErrorAction SilentlyContinue)) { Write-Host "Verbinden met Azure..." -ForegroundColor Gray Connect-AzAccount -ErrorAction Stop | Out-Null Write-Host " [OK] Verbonden met Azure" -ForegroundColor Green } else { Write-Host " [OK] Al verbonden met Azure" -ForegroundColor Green } } catch { Write-Host " [FAIL] Kan niet verbinden met Azure: $_" -ForegroundColor Red throw } } function Test-Compliance { <# .SYNOPSIS Tests if current configuration meets compliance requirements .DESCRIPTION Wrapper function that calls Invoke-Monitoring and returns compliance status .OUTPUTS Returns monitoring result object with isCompliant property #> [CmdletBinding()] param() return Invoke-Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Monitors and reports current configuration status .DESCRIPTION Checks current configuration of immutable backup storage (retention locks) against security baseline requirements. Reports compliance status and identifies back-up policies without retention locks. .OUTPUTS Returns hashtable with: - isCompliant: Boolean indicating overall compliance - totalVaults: Total number of Recovery Services vaults - totalPolicies: Total number of backup policies - policiesWithRetentionLock: Number of policies with retention lock enabled - policiesWithoutRetentionLock: Number of policies without retention lock - details: Detailed findings #> [CmdletBinding()] param() try { Write-Host "`nMonitoring:" -ForegroundColor Yellow Connect-RequiredServices Write-Host "Controleren van Recovery Services-kluizen..." -ForegroundColor Gray # Haal alle Recovery Services-kluizen op $vaults = Get-AzRecoveryServicesVault -ErrorAction SilentlyContinue if ($null -eq $vaults -or $vaults.Count -eq 0) { Write-Host " [WAARSCHUWING] Geen Recovery Services-kluizen gevonden" -ForegroundColor Yellow return @{ isCompliant = $false timestamp = Get-Date totalVaults = 0 totalPolicies = 0 policiesWithRetentionLock = 0 policiesWithoutRetentionLock = 0 findings = @("Geen Recovery Services-kluizen gevonden") } } Write-Host " [OK] $($vaults.Count) Recovery Services-kluis(zen) gevonden" -ForegroundColor Green # Initialize result object $result = @{ isCompliant = $true timestamp = Get-Date totalVaults = $vaults.Count totalPolicies = 0 policiesWithRetentionLock = 0 policiesWithoutRetentionLock = 0 findings = @() } # Controleer elke kluis foreach ($vault in $vaults) { Write-Host "`n Controleren kluis: $($vault.Name)" -ForegroundColor Gray try { # Stel de vault context in Set-AzRecoveryServicesVaultContext -Vault $vault -ErrorAction Stop | Out-Null # Haal alle backup policies op # Let op: De exacte cmdlet kan variëren afhankelijk van de Az.RecoveryServices module versie # We gebruiken Get-AzRecoveryServicesBackupProtectionPolicy indien beschikbaar try { $policies = Get-AzRecoveryServicesBackupProtectionPolicy -ErrorAction SilentlyContinue if ($null -eq $policies) { # Alternatieve methode: gebruik Azure REST API of portal method Write-Host " [INFO] Kan policies niet direct ophalen via PowerShell" -ForegroundColor Yellow Write-Host " [INFO] Controleer handmatig in Azure Portal of retention locks zijn geactiveerd" -ForegroundColor Yellow $result.findings += "Kluis $($vault.Name): Kan policies niet automatisch controleren - handmatige verificatie vereist" continue } $result.totalPolicies += $policies.Count foreach ($policy in $policies) { # Controleer of retention lock is geactiveerd # Let op: De property naam kan variëren afhankelijk van de module versie $hasRetentionLock = $false # Probeer verschillende property namen if ($policy.PSObject.Properties.Name -contains 'IsRetentionLockEnabled') { $hasRetentionLock = $policy.IsRetentionLockEnabled } elseif ($policy.PSObject.Properties.Name -contains 'RetentionLockEnabled') { $hasRetentionLock = $policy.RetentionLockEnabled } elseif ($policy.PSObject.Properties.Name -contains 'Immutable') { $hasRetentionLock = $policy.Immutable } else { # Als de property niet beschikbaar is, markeer als niet-compliant Write-Host " [WAARSCHUWING] Policy $($policy.Name): Kan retention lock status niet bepalen" -ForegroundColor Yellow $result.findings += "Policy $($policy.Name) in kluis $($vault.Name): Retention lock status onbekend" $result.policiesWithoutRetentionLock++ $result.isCompliant = $false continue } if ($hasRetentionLock) { Write-Host " [OK] Policy $($policy.Name): Retention lock is geactiveerd" -ForegroundColor Green $result.policiesWithRetentionLock++ } else { Write-Host " [FAIL] Policy $($policy.Name): Retention lock is NIET geactiveerd" -ForegroundColor Red $result.policiesWithoutRetentionLock++ $result.isCompliant = $false $result.findings += "Policy $($policy.Name) in kluis $($vault.Name): Retention lock niet geactiveerd" } } } catch { Write-Host " [WAARSCHUWING] Kan policies niet ophalen voor kluis $($vault.Name): $_" -ForegroundColor Yellow $result.findings += "Kluis $($vault.Name): Kan policies niet ophalen - $_" } } catch { Write-Host " [WAARSCHUWING] Kan vault context niet instellen voor $($vault.Name): $_" -ForegroundColor Yellow $result.findings += "Kluis $($vault.Name): Kan context niet instellen - $_" } } # ============================================= # SUMMARY # ============================================= Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "SUMMARY:" -ForegroundColor Cyan Write-Host " Recovery Services-kluizen: $($result.totalVaults)" -ForegroundColor White Write-Host " Totaal back-upbeleid: $($result.totalPolicies)" -ForegroundColor White Write-Host " Beleid met retention lock: $($result.policiesWithRetentionLock)" -ForegroundColor $(if ($result.policiesWithRetentionLock -gt 0) { 'Green' } else { 'Yellow' }) Write-Host " Beleid zonder retention lock: $($result.policiesWithoutRetentionLock)" -ForegroundColor $(if ($result.policiesWithoutRetentionLock -eq 0) { 'Green' } else { 'Red' }) if ($result.isCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green Write-Host " Alle back-upbeleid hebben retention locks geactiveerd" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red Write-Host " Issues found: $($result.findings.Count)" -ForegroundColor Yellow Write-Host "`n Aanbevelingen:" -ForegroundColor Yellow Write-Host " - Activeer retention locks voor alle back-upbeleid via Azure Portal" -ForegroundColor White Write-Host " - Controleer of de juiste bevoegdheden zijn toegewezen (Backup Contributor)" -ForegroundColor White Write-Host " - Verifieer dat immutability-functionaliteit beschikbaar is voor uw licentie" -ForegroundColor White } return $result } catch { Write-Host "`n[FAIL] ERROR during monitoring: $_" -ForegroundColor Red throw } } function Invoke-Remediation { <# .SYNOPSIS Applies recommended security configuration .DESCRIPTION Implements retention locks on backup policies to enable immutable backup storage. Note: Retention locks can only be enabled via Azure Portal or Azure REST API. This function provides guidance and checks current status. .PARAMETER WhatIf Shows what would be changed without making actual changes #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nRemediation:" -ForegroundColor Yellow Connect-RequiredServices Write-Host "`n[INFO] Retention locks kunnen momenteel alleen worden geactiveerd via:" -ForegroundColor Yellow Write-Host " 1. Azure Portal (Recovery Services Vault > Back-upbeleid > Retention Lock)" -ForegroundColor White Write-Host " 2. Azure REST API" -ForegroundColor White Write-Host "`n PowerShell-cmdlets voor retention locks zijn nog niet beschikbaar in Az.RecoveryServices module." -ForegroundColor Yellow if ($WhatIf) { Write-Host "`n[WhatIf] Zou retention locks activeren voor alle back-upbeleid zonder retention lock" -ForegroundColor Cyan } else { Write-Host "`n Volg deze stappen om retention locks handmatig te activeren:" -ForegroundColor White Write-Host "`n 1. Open Azure Portal (portal.azure.com)" -ForegroundColor Cyan Write-Host " 2. Navigeer naar Recovery Services-kluis" -ForegroundColor Cyan Write-Host " 3. Selecteer 'Back-upbeleid' in het menu" -ForegroundColor Cyan Write-Host " 4. Selecteer het back-upbeleid dat u wilt beschermen" -ForegroundColor Cyan Write-Host " 5. Klik op 'Retention Lock' of 'Onveranderlijk' in de instellingen" -ForegroundColor Cyan Write-Host " 6. Activeer de retention lock en bevestig de bewaartermijn" -ForegroundColor Cyan Write-Host " 7. Herhaal voor alle kritieke back-upbeleid" -ForegroundColor Cyan Write-Host "`n ALTERNATIEF: Gebruik Azure REST API voor automatisering:" -ForegroundColor Yellow Write-Host " - Endpoint: PUT /Subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/" -ForegroundColor Gray Write-Host " providers/Microsoft.RecoveryServices/vaults/{vaultName}/backupPolicies/{policyName}" -ForegroundColor Gray Write-Host " - Body: { 'properties': { 'retentionLock': true } }" -ForegroundColor Gray # Voer monitoring uit om huidige status te tonen Write-Host "`n Huidige status controleren..." -ForegroundColor Cyan Invoke-Monitoring } Write-Host "`n[OK] Remediation instructies verstrekt" -ForegroundColor Green } catch { Write-Host "`n[FAIL] ERROR during remediation: $_" -ForegroundColor Red throw } } function Invoke-Revert { <# .SYNOPSIS Reverts configuration to previous state .DESCRIPTION Reverts changes made by remediation to restore previous configuration. Note: Retention locks CANNOT be disabled until the retention period expires. This function provides information about this limitation. #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nRevert:" -ForegroundColor Yellow Write-Host "`n[WAARSCHUWING] Retention locks kunnen NIET worden uitgeschakeld" -ForegroundColor Red Write-Host " zodra zij zijn geactiveerd, totdat de bewaartermijn is verstreken." -ForegroundColor Red Write-Host "`n Dit is een beveiligingsfunctie die ervoor zorgt dat back-ups" -ForegroundColor Yellow Write-Host " niet kunnen worden gewijzigd of verwijderd, zelfs niet door beheerders." -ForegroundColor Yellow Write-Host "`n Als u retention locks moet verwijderen:" -ForegroundColor White Write-Host " 1. Wacht tot de bewaartermijn is verstreken" -ForegroundColor Cyan Write-Host " 2. Of neem contact op met Microsoft Support voor uitzonderlijke gevallen" -ForegroundColor Cyan Write-Host "`n Huidige status controleren..." -ForegroundColor Cyan Invoke-Monitoring } catch { Write-Host "`n[FAIL] ERROR during revert: $_" -ForegroundColor Red throw } } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { # Determine which action to perform if ($Revert) { if ($WhatIf) { Write-Host "WhatIf: Retention locks kunnen niet worden uitgeschakeld" -ForegroundColor Yellow } else { Invoke-Revert } } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Zou retention locks activeren voor back-upbeleid" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Monitoring) { $result = Invoke-Monitoring # Exit with appropriate code for automation if ($result.isCompliant) { exit 0 # Success - Compliant } else { exit 1 # Warning - Non-compliant } } else { # No parameters - show usage Write-Host "Available parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Check current configuration status" -ForegroundColor Gray Write-Host " -Remediation : Apply recommended configuration (instructies)" -ForegroundColor Gray Write-Host " -Revert : Revert to previous configuration (niet mogelijk voor retention locks)" -ForegroundColor Gray Write-Host " -WhatIf : Preview changes without applying" -ForegroundColor Gray Write-Host "`nExample: .\immutable-backup-storage.ps1 -Monitoring" -ForegroundColor Cyan } } catch { Write-Error "Script execution failed: $_" exit 2 # Error } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan } # ============================================================================ # EXIT CODES # ============================================================================ # 0 = Success / Compliant # 1 = Warning / Non-compliant # 2 = Error / Execution failed

Risico zonder implementatie

Risico zonder implementatie
Critical: Wanneer onveranderlijke back-upopslag niet is geconfigureerd, kunnen ransomware-aanvallen of kwaadaardige actoren back-ups verwijderen of versleutelen voordat een herstelactie kan worden uitgevoerd. Moderne ransomware-varianten zijn specifiek ontworpen om back-ups te targeten als onderdeel van hun aanvalsstrategie, waarbij zij eerst alle beschikbare back-ups verwijderen voordat zij de primaire systemen versleutelen. Zonder onveranderlijke opslag kunnen zelfs beheerders met de hoogste rechten back-ups per ongeluk of opzettelijk verwijderen, wat kan leiden tot onherstelbaar gegevensverlies en volledige uitval van kritieke diensten. Voor Nederlandse overheidsorganisaties die essentiële diensten leveren aan burgers, kan dit leiden tot bestuurlijke verantwoordelijkheid, reputatieschade en mogelijke boetes van toezichthouders. Bovendien mislukt iedere audit op BIO, ISO 27001 en NIS2-onderdelen zodra blijkt dat back-ups niet beschermd zijn tegen manipulatie en verwijdering.

Management Samenvatting

Onveranderlijke back-upopslag levert retention locks op back-upbeleid die garanderen dat herstelpunten niet kunnen worden gewijzigd of verwijderd gedurende de bewaartermijn, zelfs niet door beheerders met de hoogste rechten. Dit creëert ransomware-bestendige back-ups die essentieel zijn voor een effectieve rampherstelstrategie. Activatie gebeurt via het Azure-portaal of PowerShell door retention locks te configureren op back-upbeleid. De functionaliteit zelf is gratis en vereist geen aanvullende licenties. Implementatie duurt typisch 2-3 uur, inclusief planning, configuratie en verificatie. Met een investering van enkele minuten configuratietijd wordt voldaan aan CIS 7.3, BIO 12.03, ISO 27001 A.8.13, AVG artikel 32 en NIS2. Activeer retention locks voor alle kritieke back-upbeleid en monitor regelmatig de status om continuïteit te garanderen.