BIO 12.03

Azure Storage Account: ReadOnly Resource Locks Overwegen Voor Archival Storage

📅 2025-10-29
•
⏱️ 3 minuten lezen
•
🟢 Nice-to-Have

💼 Management Samenvatting

ReadOnly Resource Locks voor Azure Storage Accounts bieden extra bescherming tegen ongeautoriseerde of accidentele wijzigingen en verwijderingen van archiefopslag. Deze vergrendelingen zijn optioneel en alleen relevant voor statische opslagaccounts die uitsluitend worden gebruikt voor langetermijngegevensretentie zonder frequente wijzigingen.

Aanbeveling
OPTIONEEL - CANNOTDELETE VOLDOENDE
Risico zonder
Low
Risk Score
3/10
Implementatie
0.5u (tech: 0.5u)
Van toepassing op:
✓ Azure

Voor opslagaccounts die actief worden gebruikt voor applicatiedata, back-ups of logboekregistratie is een ReadOnly-vergrendeling niet praktisch omdat deze schrijf- en verwijderingsbewerkingen blokkeert die nodig zijn voor normale werking. ReadOnly-vergrendelingen zijn echter relevant voor specifieke gebruikssituaties: archiefopslagaccounts die historische compliancegegevens bevatten en nooit mogen worden gewijzigd na de initiële schrijfbewerking, langetermijnretentieopslag voor regelgevingscompliance waarbij gegevens onveranderlijk moeten blijven gedurende 7+ jaar, forensische bewijsopslag waar gegevensintegriteit cruciaal is en wijzigingen moeten worden voorkomen, en back-uparchivering waarbij oude back-ups permanent alleen-lezen moeten blijven. De vergrendeling voorkomt accidentele verwijdering van kritieke archiefgegevens door beheerders, ongeautoriseerde wijzigingen door gecompromitteerde accounts met contributor-rechten, en scriptfouten die bulkverwijderingsbewerkingen zouden uitvoeren. Het nadeel is dat legitieme wijzigingen ook worden geblokkeerd: nieuwe bestanden kunnen niet worden toegevoegd, bestaande bestanden kunnen niet worden bijgewerkt, en verwijdering is onmogelijk, wat betekent dat de vergrendeling tijdelijk moet worden verwijderd voor schrijfbewerkingen. Voor de meeste opslagaccounts is een CanNotDelete-vergrendeling (voorkomt verwijdering maar staat wijzigingen toe) meer geschikt omdat het beschermt tegen accidentele verwijdering terwijl normale bewerkingen mogelijk blijven. ReadOnly-vergrendelingen zijn alleen relevant voor werkelijk statische archiefscenario's.

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

Implementatie

Deze maatregel overweegt implementatie van ReadOnly Resource Locks op Azure Storage Accounts die uitsluitend worden gebruikt voor archiefdoeleinden. De vergrendeling wordt geconfigureerd via New-AzResourceLock -LockLevel ReadOnly op opslagaccountniveau, wat alle schrijf- en verwijderingsbewerkingen blokkeert, inclusief nieuwe blob-uploads, bestandswijzigingen, containercreatie en accountverwijdering. Alleen leesbewerkingen blijven mogelijk. Voor archiefopslagaccounts met meerjarige complianceretentie is dit passende bescherming, maar voor actieve opslagaccounts moet een CanNotDelete-vergrendeling worden gebruikt in plaats van ReadOnly. De implementatie kost 30 minuten per opslagaccount, is kosteloos, en is alleen relevant voor BIO 12.03 gegevensbescherming bij specifieke archiefscenario's. Voor de meeste scenario's is dit OPTIONEEL (Nice-to-Have prioriteit) en worden CanNotDelete-vergrendelingen de voorkeur gegeven voor een betere balans tussen bescherming en operationele flexibiliteit.

Vereisten

Voordat ReadOnly Resource Locks kunnen worden geïmplementeerd op Azure Storage Accounts, moeten organisaties zorgvuldig evalueren of hun opslagaccounts daadwerkelijk voldoen aan de strikte criteria voor deze vorm van vergrendeling. De belangrijkste vereiste is dat het opslagaccount volledig statisch moet zijn, wat betekent dat er na de initiële configuratie en gegevensinvoer geen wijzigingen meer mogen plaatsvinden. Dit vereist een grondige analyse van het gebruikspatroon van het opslagaccount gedurende de gehele levenscyclus, waarbij organisaties moeten kunnen aantonen dat het account uitsluitend wordt gebruikt voor archiefdoeleinden waarbij gegevens permanent onveranderlijk moeten blijven. Deze vereiste is met name relevant voor scenario's waarbij regelgevingscompliance vereist dat gegevens gedurende meerdere jaren, vaak zeven jaar of langer, volledig onveranderlijk blijven. Organisaties moeten een uitgebreide documentatie opstellen die aantoont dat het opslagaccount niet wordt gebruikt voor actieve applicatiedata, real-time logboekregistratie, of dynamische back-upprocessen waarbij regelmatig nieuwe gegevens worden toegevoegd of bestaande gegevens worden bijgewerkt. De evaluatie moet ook rekening houden met de toekomstige behoeften van de organisatie, waarbij wordt beoordeeld of het opslagaccount gedurende de gehele retentieperiode daadwerkelijk statisch kan blijven. Daarnaast moeten organisaties beschikken over de juiste Azure-machtigingen om Resource Locks te kunnen configureren, wat doorgaans de rol van eigenaar of beheerder van gebruikstoegang vereist. Deze machtigingsvereisten zijn essentieel omdat Resource Locks op tenantniveau worden geconfigureerd en daarom hoge bevoegdheden vereisen. Het is cruciaal dat organisaties een duidelijk governanceproces hebben geïmplementeerd voor het beheer van deze vergrendelingen, inclusief procedures voor noodscenario's waarbij tijdelijk toegang tot schrijfbewerkingen vereist kan zijn. Dit governanceproces moet duidelijke richtlijnen bevatten over wie bevoegd is om vergrendelingen te plaatsen, te verwijderen of tijdelijk uit te schakelen, en onder welke omstandigheden dit mag gebeuren. Bovendien moeten organisaties kunnen aantonen dat alternatieve beveiligingsmaatregelen, zoals CanNotDelete-vergrendelingen, niet voldoende zijn voor hun specifieke toepassingsscenario. Dit vereist een uitgebreide risicoanalyse waarbij de behoefte aan absolute onveranderlijkheid wordt afgewogen tegen de operationele beperkingen die ReadOnly-vergrendelingen met zich meebrengen. De risicoanalyse moet ook rekening houden met de potentiële impact op bedrijfsprocessen en moet duidelijk maken waarom een minder restrictieve vergrendeling niet voldoende is. Organisaties moeten ook beschikken over adequate monitoring en auditcapaciteiten om te kunnen verifiëren dat de vergrendeling daadwerkelijk effectief is en dat er geen pogingen zijn gedaan om de vergrendeling te omzeilen of te verwijderen zonder de juiste autorisatie. Deze monitoringcapaciteiten moeten geautomatiseerd zijn waar mogelijk en moeten regelmatige verificaties uitvoeren om te bevestigen dat de vergrendeling nog steeds actief is. De auditcapaciteiten moeten volledige logboekregistratie bieden van alle activiteiten die betrekking hebben op de vergrendeling, inclusief wanneer deze is geplaatst, door wie, en of er ooit pogingen zijn gedaan om deze te wijzigen of te verwijderen.

Implementatie

Gebruik PowerShell-script readonly-locks-considered.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van ReadOnly Resource Locks op Azure Storage Accounts vereist een gestructureerde aanpak waarbij organisaties zorgvuldig moeten plannen voordat de vergrendeling wordt geactiveerd. Het implementatieproces begint met een grondige inventarisatie van alle opslagaccounts binnen de Azure-tenant om te identificeren welke accounts daadwerkelijk in aanmerking komen voor ReadOnly-vergrendeling. Deze inventarisatie moet worden uitgevoerd door een multidisciplinair team dat bestaat uit beveiligingsspecialisten, compliance officers, operations engineers en zakelijke belanghebbenden om te waarborgen dat alle aspecten van de implementatie worden overwogen. Dit vereist intensieve samenwerking tussen verschillende teams om te bepalen welke opslagaccounts uitsluitend worden gebruikt voor statische archiefdoeleinden en welke accounts mogelijk in de toekomst nog wijzigingen nodig hebben. Tijdens de inventarisatiefase moeten organisaties een gedetailleerde analyse uitvoeren van elk opslagaccount, waarbij wordt gekeken naar het gebruikspatroon, de gegevens die worden opgeslagen, de compliance-vereisten, en de verwachte levenscyclus van de gegevens. Eenmaal geïdentificeerd, moeten organisaties een uitgebreid wijzigingsbeheerproces doorlopen waarbij alle belanghebbenden worden geïnformeerd over de gevolgen van de vergrendeling, met name dat alle schrijf- en verwijderingsbewerkingen permanent worden geblokkeerd. Dit wijzigingsbeheerproces moet duidelijk communiceren wat de impact zal zijn op verschillende teams en processen, en moet procedures bevatten voor het omgaan met situaties waarin toegang tot schrijfbewerkingen nodig is. De technische implementatie wordt uitgevoerd via de Azure PowerShell-module Az.Resources, waarbij de cmdlet New-AzResourceLock wordt gebruikt met de parameter -LockLevel ingesteld op ReadOnly. Deze vergrendeling wordt toegepast op het niveau van het opslagaccount, wat betekent dat alle containers, blobs en bestanden binnen het account worden beschermd tegen wijzigingen. Het is cruciaal dat organisaties vóór de implementatie een volledige back-up maken van alle gegevens en verificatie uitvoeren dat alle benodigde gegevens daadwerkelijk zijn geüpload en correct zijn geconfigureerd. Deze verificatie moet worden gedocumenteerd en moet worden opgenomen in de wijzigingsbeheerdocumentatie. Na implementatie moeten organisaties uitgebreide tests uitvoeren om te verifiëren dat leesbewerkingen nog steeds correct functioneren, aangezien alleen-lezen toegang essentieel blijft voor compliance- en auditdoeleinden. Deze tests moeten verschillende scenario's omvatten, zoals het lezen van individuele blobs, het doorzoeken van containers, en het ophalen van metadata. De implementatie moet worden gedocumenteerd in de organisatie wijzigingsbeheersystemen, en alle relevante teams moeten worden geïnformeerd over de nieuwe beperkingen. Organisaties moeten ook procedures ontwikkelen voor het beheer van de vergrendeling in noodsituaties, waarbij een duidelijk proces wordt gedefinieerd voor het tijdelijk verwijderen van de vergrendeling indien dit absoluut noodzakelijk is, met volledige auditlogboekregistratie en goedkeuring van meerdere autorisatieniveaus. Deze procedures moeten duidelijk aangeven wie bevoegd is om de vergrendeling tijdelijk te verwijderen, onder welke omstandigheden dit mag gebeuren, en welke goedkeuringsprocessen moeten worden doorlopen. De implementatie zelf kost doorgaans ongeveer 30 minuten per opslagaccount, maar de voorbereiding en planning kunnen aanzienlijk meer tijd in beslag nemen, afhankelijk van de complexiteit van de organisatie en het aantal betrokken belanghebbenden. Organisaties moeten rekening houden met deze extra tijd bij het plannen van de implementatie en moeten voldoende buffer inbouwen voor onvoorziene uitdagingen of vertragingen.

Compliance en Audit

ReadOnly Resource Locks dragen bij aan compliance met verschillende regelgevingskaders en beveiligingsstandaarden die van toepassing zijn op Nederlandse overheidsorganisaties. De belangrijkste compliance-verwijzing betreft BIO 12.03, dat specifiek betrekking heeft op gegevensbescherming en de vereiste om gegevens te beschermen tegen ongeautoriseerde toegang, wijziging of verwijdering. ReadOnly-vergrendelingen bieden een technische controle die direct bijdraagt aan het voldoen aan deze vereiste door te voorkomen dat gegevens kunnen worden gewijzigd of verwijderd, zelfs door beheerders met volledige toegangsrechten. Deze technische controle vormt een essentieel onderdeel van de defensieve beveiligingslaag die organisaties moeten implementeren om te voldoen aan de strikte eisen die worden gesteld door de Baseline Informatiebeveiliging Overheid. Voor organisaties die werken met gevoelige overheidsgegevens of gegevens die onder de Algemene Verordening Gegevensbescherming (AVG) vallen, kunnen ReadOnly-vergrendelingen helpen bij het waarborgen van gegevensintegriteit en het voorkomen van ongeautoriseerde wijzigingen die kunnen leiden tot compliance-overtredingen. De AVG vereist dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beschermen, en ReadOnly-vergrendelingen vormen een concrete technische maatregel die kan worden gebruikt om te voldoen aan deze vereiste. Bovendien zijn ReadOnly-vergrendelingen relevant voor scenario's waarbij regelgevingscompliance vereist dat gegevens gedurende een bepaalde periode onveranderlijk moeten blijven, zoals vereisten voor financiële rapportage, belastingdocumentatie, of andere wettelijk verplichte archieven. Deze onveranderlijkheidsvereisten zijn met name relevant voor organisaties die moeten voldoen aan specifieke archiefwetgeving of regelgeving die vereist dat bepaalde gegevens gedurende een lange periode volledig onveranderlijk blijven. Organisaties moeten echter erkennen dat ReadOnly-vergrendelingen slechts één onderdeel zijn van een bredere compliance-strategie en moeten worden gecombineerd met andere beveiligingsmaatregelen zoals toegangscontrole, encryptie, en uitgebreide logboekregistratie en monitoring. Deze combinatie van beveiligingsmaatregelen vormt een gelaagde verdediging die ervoor zorgt dat zelfs als één maatregel faalt, andere maatregelen nog steeds bescherming bieden. Voor auditdoeleinden moeten organisaties kunnen aantonen dat de vergrendeling daadwerkelijk is geïmplementeerd en actief is, wat vereist dat regelmatige verificaties worden uitgevoerd om te bevestigen dat de vergrendeling nog steeds van kracht is. Deze verificaties moeten worden uitgevoerd door onafhankelijke auditeurs of door interne compliance teams, en moeten worden gedocumenteerd in auditrapporten die kunnen worden gebruikt tijdens externe audits of compliance-verificaties. Auditlogboeken moeten worden bewaard die documenteren wanneer de vergrendeling is geïmplementeerd, door wie, en of er ooit pogingen zijn gedaan om de vergrendeling te verwijderen of te wijzigen. Deze auditinformatie is essentieel voor compliance-verificaties en kan worden gebruikt om aan te tonen dat organisaties passende maatregelen hebben genomen om gegevens te beschermen tegen ongeautoriseerde wijzigingen. De auditlogboeken moeten worden bewaard gedurende de volledige retentieperiode van de gegevens, wat in veel gevallen zeven jaar of langer kan zijn. Organisaties moeten ook overwegen hoe ReadOnly-vergrendelingen passen binnen hun bredere bestuurs- en risicomanagementkaders, waarbij de balans tussen beveiliging en operationele flexibiliteit zorgvuldig wordt afgewogen. Deze afweging moet worden gedocumenteerd in risicoanalyses en bestuursdocumenten, en moet regelmatig worden herzien om te waarborgen dat de vergrendelingen nog steeds passen bij de huidige behoeften en risicoprofiel van de organisatie.

Monitoring

Gebruik PowerShell-script readonly-locks-considered.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van ReadOnly Resource Locks is essentieel om te verzekeren dat de vergrendeling daadwerkelijk actief blijft en dat er geen ongeautoriseerde pogingen worden gedaan om de vergrendeling te verwijderen of te wijzigen. Organisaties moeten een gestructureerd monitoringproces implementeren dat regelmatig verifieert dat de vergrendeling nog steeds van kracht is op alle relevante opslagaccounts. Dit monitoringproces vormt een kritiek onderdeel van de beveiligingsstrategie en moet worden geïntegreerd in de bredere beveiligingsoperaties van de organisatie. Het monitoringproces moet worden geautomatiseerd waar mogelijk, waarbij gebruik wordt gemaakt van Azure PowerShell-scripts of Azure Policy om periodiek de status van Resource Locks te controleren. Deze automatisering zorgt ervoor dat monitoring consistent wordt uitgevoerd en vermindert het risico op menselijke fouten of gemiste verificaties. De geautomatiseerde monitoring moet worden geconfigureerd om regelmatig te draaien, idealiter dagelijks of zelfs vaker voor kritieke opslagaccounts, en moet worden geïntegreerd met bestaande monitoring- en waarschuwingssystemen. De monitoring moet niet alleen verifiëren dat de vergrendeling bestaat, maar ook dat deze correct is geconfigureerd met het juiste niveau (ReadOnly) en dat er geen wijzigingen zijn aangebracht aan de vergrendelingsconfiguratie. Deze verificatie moet ook controleren of de vergrendeling is toegepast op het juiste niveau en of er geen conflicterende configuraties zijn die de effectiviteit van de vergrendeling kunnen verminderen. Organisaties moeten ook Azure Activiteitenlogboeken monitoren om te detecteren of er pogingen zijn geweest om de vergrendeling te verwijderen, te wijzigen, of om schrijfbewerkingen uit te voeren op de vergrendelde opslagaccounts. Deze logboeken moeten worden geanalyseerd op verdachte activiteiten, zoals herhaalde pogingen om de vergrendeling te verwijderen of wijzigingen aan te brengen aan de opslagaccountconfiguratie. De analyse van deze logboeken moet worden geautomatiseerd waar mogelijk, waarbij gebruik wordt gemaakt van logboekanalysehulpmiddelen of beveiligingsinformatie- en gebeurtenisbeheersystemen om verdachte patronen te detecteren. Monitoring moet ook verifiëren dat leesbewerkingen nog steeds correct functioneren, aangezien ReadOnly-vergrendelingen alleen schrijf- en verwijderingsbewerkingen moeten blokkeren, niet de toegang tot gegevens voor compliance- en auditdoeleinden. Deze verificatie is essentieel omdat leestoegang cruciaal blijft voor het uitvoeren van audits, het voldoen aan inzageverzoeken, en het waarborgen van de continuïteit van bedrijfsprocessen die afhankelijk zijn van de gegevens in het opslagaccount. Organisaties moeten waarschuwingsconfiguratie instellen die automatisch waarschuwingen genereert wanneer een vergrendeling wordt verwijderd of gewijzigd, zodat beveiligingsteams onmiddellijk kunnen reageren op mogelijke beveiligingsincidenten. Deze waarschuwingsconfiguratie moet worden ingesteld met verschillende prioriteitsniveaus, waarbij kritieke wijzigingen onmiddellijk worden geëscaleerd naar het beveiligingsoperatiecentrum, terwijl minder kritieke gebeurtenissen kunnen worden opgenomen in dagelijkse of wekelijkse rapporten. De monitoringresultaten moeten regelmatig worden gerapporteerd aan compliance- en beveiligingsteams, en moeten worden opgenomen in periodieke beveiligingsbeoordelingen en audits. Deze rapportage moet duidelijke metriek bevatten over de status van alle vergrendelingen, eventuele incidenten of pogingen tot wijziging, en trends over tijd die kunnen helpen bij het identificeren van potentiële problemen of verbeterpunten. Bovendien moeten organisaties ervoor zorgen dat monitoringhulpmiddelen zelf niet worden beïnvloed door de ReadOnly-vergrendeling, wat betekent dat monitoring- en logboekregistratie-infrastructuur moet worden geconfigureerd op een manier die compatibel is met de beperkingen die door de vergrendeling worden opgelegd. Dit kan vereisen dat monitoringhulpmiddelen worden geconfigureerd om alleen leesbewerkingen uit te voeren, of dat speciale monitoringaccounts worden gebruikt die zijn geconfigureerd om compatibel te zijn met de vergrendeling.

Remediatie

Gebruik PowerShell-script readonly-locks-considered.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring detecteert dat een ReadOnly Resource Lock ontbreekt op een opslagaccount waar dit vereist is, of wanneer een vergrendeling onjuist is geconfigureerd, moeten organisaties onmiddellijk actie ondernemen om de beveiligingspostuur te herstellen. Deze onmiddellijke actie is essentieel omdat het ontbreken van een vergrendeling betekent dat het opslagaccount kwetsbaar is voor ongeautoriseerde wijzigingen of verwijderingen, wat kan leiden tot ernstige beveiligingsincidenten of compliance-overtredingen. Het remediatieproces begint met een grondige analyse van de situatie om te begrijpen waarom de vergrendeling ontbreekt of onjuist is geconfigureerd. Deze analyse moet worden uitgevoerd door een multidisciplinair team dat bestaat uit beveiligingsspecialisten, compliance officers, en operations engineers om te waarborgen dat alle aspecten van het incident worden onderzocht. Dit kan het gevolg zijn van een onbedoelde verwijdering door een beheerder die niet op de hoogte was van de vereisten, een geautomatiseerd proces dat de vergrendeling heeft verwijderd als onderdeel van een grotere configuratiewijziging, of een beveiligingsincident waarbij een gecompromitteerd account de vergrendeling heeft verwijderd om toegang te krijgen tot de gegevens. Ongeacht de oorzaak moet de remediatie worden uitgevoerd volgens een gestructureerd proces dat begint met het documenteren van de huidige staat van het opslagaccount en het identificeren van eventuele wijzigingen die mogelijk zijn aangebracht terwijl de vergrendeling ontbrak. Deze documentatie is essentieel voor compliance doeleinden en kan worden gebruikt tijdens audits of beveiligingsonderzoeken. Organisaties moeten vervolgens de ReadOnly-vergrendeling opnieuw implementeren met behulp van dezelfde methodologie als bij de oorspronkelijke implementatie, waarbij gebruik wordt gemaakt van Azure PowerShell-cmdlets om de vergrendeling te herstellen. Tijdens deze herimplementatie moeten organisaties ervoor zorgen dat alle vereisten en best practices worden gevolgd, en moeten ze verificatie uitvoeren dat de vergrendeling correct is geconfigureerd en actief is. Het is belangrijk dat organisaties tijdens het remediatieproces verifiëren dat er geen ongeautoriseerde wijzigingen zijn aangebracht aan de gegevens in het opslagaccount, wat kan vereisen dat een forensische analyse wordt uitgevoerd om te bepalen of gegevensintegriteit is aangetast. Deze forensische analyse moet worden uitgevoerd door gespecialiseerde beveiligingsteams en moet gebruik maken van geavanceerde hulpmiddelen en technieken om eventuele wijzigingen te detecteren, zelfs als deze subtiel zijn of zijn geprobeerd te verbergen. Na herstel van de vergrendeling moeten organisaties hun monitoringprocessen evalueren om te begrijpen waarom de ontbrekende vergrendeling niet eerder werd gedetecteerd, en moeten verbeteringen worden doorgevoerd om toekomstige incidenten te voorkomen. Deze evaluatie moet een grondige analyse omvatten van de monitoringconfiguratie, de frequentie van verificaties, en de effectiviteit van waarschuwingsmechanismen. Het remediatieproces moet ook een post-incidentbeoordeling omvatten waarbij wordt geanalyseerd wat er is gebeurd, welke impact dit heeft gehad op de beveiliging en compliance, en welke maatregelen kunnen worden genomen om soortgelijke incidenten in de toekomst te voorkomen. Deze post-incidentbeoordeling moet worden gedocumenteerd en moet worden gedeeld met alle relevante teams om te waarborgen dat lessen worden geleerd en dat verbeteringen worden doorgevoerd. Organisaties moeten ook overwegen of aanvullende beveiligingsmaatregelen nodig zijn, zoals het implementeren van Azure Policy om te voorkomen dat vergrendelingen worden verwijderd zonder de juiste autorisatie, of het implementeren van extra monitoring en waarschuwingen om sneller te kunnen reageren op toekomstige incidenten. Deze aanvullende maatregelen moeten worden geëvalueerd op basis van de specifieke risico's en behoeften van de organisatie, en moeten worden geïntegreerd in de bredere beveiligingsstrategie.

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 ReadOnly Locks Considered .DESCRIPTION CIS Azure Foundations Benchmark - Control 3.19 Controleert of ReadOnly locks zijn overwogen voor storage accounts. .NOTES Filename: readonly-locks-considered.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 3.19 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Storage, Az.Resources [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "ReadOnly Locks Considered" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue $result = @{ TotalAccounts = $storageAccounts.Count; WithReadOnlyLocks = 0 } foreach ($account in $storageAccounts) { $locks = Get-AzResourceLock -ResourceGroupName $account.ResourceGroupName -ResourceName $account.StorageAccountName -ResourceType "Microsoft.Storage/storageAccounts" -ErrorAction SilentlyContinue $readOnlyLock = $locks | Where-Object { $_.Properties.Level -eq 'ReadOnly' } if ($readOnlyLock) { $result.WithReadOnlyLocks++ } } 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 ReadOnly Locks: $($r.WithReadOnlyLocks)" -ForegroundColor $(if ($r.WithReadOnlyLocks -gt 0) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nReadOnly Locks: $($r.WithReadOnlyLocks)/$($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 ReadOnly Locks: $($r.WithReadOnlyLocks)" -ForegroundColor $(if ($r.WithReadOnlyLocks -gt 0) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nReadOnly Locks: $($r.WithReadOnlyLocks)/$($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
Low: CanNotDelete-vergrendelingen zijn adequaat voor 95 procent van de scenario's. ReadOnly-vergrendelingen voorkomen alle wijzigingen (extreme beperking). Het risico is laag - CanNotDelete is voldoende.

Management Samenvatting

ReadOnly-vergrendelingen: Voorkomen alle wijzigingen aan opslagaccounts (extreme bescherming). Gebruikssituatie: alleen archief- of statische opslag. CanNotDelete-vergrendelingen hebben de voorkeur (staan updates toe, voorkomen verwijdering). Activatie: Opslag → Vergrendelingen → ReadOnly. Gratis. Implementatie: 30 minuten. Optioneel - CanNotDelete is adequaat voor de meeste gevallen.