L1 BIO 17.01.01 ISO A.12.3.1 CIS Resource bescherming

Azure Resource Locks Op Production Resources

📅 2025-10-30
•
⏱️ 8 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Azure Resource Locks vormen een essentiële beschermingslaag tegen onbedoelde verwijdering of wijziging van productieresources. Door het verplichten van expliciete lockverwijdering voordat resources kunnen worden gewijzigd, beschermen Resource Locks organisaties tegen menselijke fouten en kwaadwillige verwijderingen. Deze beveiligingsmaatregel is onmisbaar voor alle productieomgevingen en vereist geen extra kosten of complexe configuratie.

Aanbeveling
IMPLEMENTEER OP PRODUCTIE RESOURCE GROUPS
Risico zonder
High
Risk Score
9/10
Implementatie
4u (tech: 3u)
Van toepassing op:
✓ Production Resources

Zonder Resource Locks lopen organisaties aanzienlijke risico's die kunnen leiden tot catastrofale gevolgen voor de bedrijfscontinuïteit. De meest voorkomende bedreigingen zijn onbedoelde verwijderingen door menselijke fouten, zoals het selecteren van de verkeerde resource of het werken in de productieomgeving in plaats van de ontwikkelomgeving. Deze fouten ontstaan vaak door vermoeidheid, tijdsdruk, of onvoldoende training van medewerkers. Daarnaast kunnen kwaadwillige verwijderingen plaatsvinden bij accountcompromittering, bijvoorbeeld wanneer ransomware-aanvallers proberen resources te verwijderen tijdens een aanval om sporen te wissen en herstel te voorkomen. Bij insider threats proberen kwaadwillige medewerkers kritieke systemen te beschadigen door resources te verwijderen die essentieel zijn voor de bedrijfsvoering. Automatisering scriptfouten vormen eveneens een significant risico, waarbij scripts per ongeluk productieresources verwijderen in plaats van ontwikkelresources, vaak veroorzaakt door verkeerde omgevingsvariabelen of fouten in de scriptlogica. Het fundamentele probleem is dat de meeste verwijderde resources niet kunnen worden hersteld, zelfs niet met back-ups, omdat de verwijdering vaak onopgemerkt blijft totdat de resource daadwerkelijk nodig is. Dit leidt tot aanzienlijke bedrijfsimpact, mogelijk datalies, en langdurige uitval van kritieke bedrijfsprocessen. Resource Locks lossen deze problemen op door verwijdering te voorkomen met CanNotDelete locks, wijzigingen te blokkeren met ReadOnly locks indien nodig, expliciete lockverwijdering te vereisen via een goedkeuringsworkflow die menselijke fouten voorkomt, en overerving te ondersteunen van subscription naar Resource Group naar individuele resource, waardoor nieuwe resources automatisch worden beschermd. Een reëel voorval illustreert de ernst van deze bedreigingen: een engineer verwijderde per ongeluk een productie SQL-database omdat hij dacht dat het een ontwikkelomgeving was, wat resulteerde in gegevensverlies ter waarde van meer dan 500.000 euro en urenlang uitval van kritieke bedrijfsprocessen die duizenden klanten beïnvloedden.

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

Implementatie

De implementatie van Resource Locks omvat het plaatsen van CanNotDelete locks op alle productie Resource Groups, wat de standaard aanpak is voor de meeste scenario's. CanNotDelete locks vormen de primaire beveiligingslaag omdat ze voorkomen dat resources worden verwijderd, terwijl configuratiewijzigingen nog steeds mogelijk blijven. Dit is essentieel voor productieomgevingen die regelmatig updates en aanpassingen nodig hebben voor patches, schaling en andere operationele activiteiten. ReadOnly locks zijn slechts zelden nodig en worden alleen gebruikt voor werkelijk onveranderbare resources waar geen enkele wijziging toegestaan is, zoals historische archieven of compliance-kritieke configuraties die nooit mogen worden aangepast. Het locksysteem ondersteunt overerving van bovenliggende scopes, wat betekent dat locks op subscription-niveau automatisch worden overgenomen door alle Resource Groups en resources binnen die subscription. Deze hiërarchische aanpak vereenvoudigt het beheer aanzienlijk en zorgt ervoor dat nieuwe resources automatisch worden beschermd wanneer ze worden aangemaakt binnen een gelockte scope. Een essentiële component is de noodprocedure voor lockverwijdering die volledig gedocumenteerd moet zijn, zodat in noodgevallen locks snel en veilig kunnen worden verwijderd wanneer dit legitiem nodig is. Deze procedure moet duidelijk aangeven wie geautoriseerd is om locks te verwijderen, welk goedkeuringsproces moet worden gevolgd, en hoe deze actie wordt vastgelegd voor audit-doeleinden. Alle lockactiviteiten zijn volledig zichtbaar in de audit logs, inclusief plaatsingen, wijzigingen en verwijderingen, zodat alle acties volledig traceerbaar zijn voor compliance-doeleinden en forensische onderzoeken. Belangrijk om te begrijpen is wat locks wel en niet voorkomen: Resource Locks voorkomen NIET het lezen van resources, normale resourcegebruik door applicaties, of monitoring en logging activiteiten. Resource Locks VOORKOMEN wel resourceverwijdering, configuratiewijzigingen indien ReadOnly locks gebruikt worden, en het verplaatsen van resources tussen Resource Groups of subscriptions. Deze duidelijke scheiding tussen toegestane en geblokkeerde acties zorgt ervoor dat operationele activiteiten kunnen doorgaan terwijl destructieve acties worden voorkomen.

Vereisten

Voordat Resource Locks kunnen worden geïmplementeerd, moeten verschillende vereisten worden vervuld. Allereerst moeten alle productieresources geïdentificeerd en getagd worden met een consistente naamgevingsconventie. Dit vereist een grondige inventarisatie van alle Resource Groups binnen de productieomgeving, waarbij duidelijk onderscheid wordt gemaakt tussen productie-, acceptatie-, ontwikkel- en testomgevingen. Tags zoals 'Environment=Production' en 'Criticality=High' helpen bij het automatisch identificeren van resources die bescherming nodig hebben. De identificatieproces moet ook rekening houden met resources die mogelijk buiten de standaard naamgevingsconventies vallen maar toch als productie moeten worden beschouwd.

Voor het aanmaken van Resource Locks zijn specifieke RBAC-rechten vereist. Gebruikers of service-principals moeten minimaal de rol 'Owner' of 'Contributor' hebben op de Resource Group of subscription waar de lock moet worden geplaatst. Het wordt aanbevolen om een specifieke service-principal te gebruiken voor het beheren van locks, in plaats van individuele gebruikersaccounts, om compliance en auditability te verbeteren. Deze service-principal moet alleen de minimaal benodigde rechten hebben en moet worden beveiligd met sterke authenticatie zoals certificate-based authentication of managed identities.

Een kritieke vereiste is de documentatie van de noodprocedure voor lockverwijdering. Deze procedure beschrijft hoe locks kunnen worden verwijderd in noodsituaties wanneer legitieme wijzigingen nodig zijn. De documentatie moet duidelijk aangeven wie geautoriseerd is om locks te verwijderen, welk goedkeuringsproces moet worden gevolgd, en hoe deze actie wordt vastgelegd in de audit logs. De noodprocedure moet regelmatig worden getest en gecontroleerd om ervoor te zorgen dat deze in noodsituaties snel en effectief kan worden uitgevoerd zonder de beveiliging in gevaar te brengen. Deze procedure vormt een essentieel onderdeel van het incidentafhandelingsplan en moet toegankelijk zijn voor alle geautoriseerde personen, zelfs wanneer normale systemen mogelijk niet beschikbaar zijn.

Een goed gedefinieerd wijzigingsbeheerproces is essentieel voor lockverwijdering. Dit proces moet beschrijven wanneer locks legitiem kunnen worden verwijderd, welke goedkeuringen vereist zijn, en hoe wijzigingen worden gedocumenteerd. Het wijzigingsbeheerproces moet integratie hebben met bestaande ITSM-systemen en moet duidelijk maken dat het verwijderen van een lock een uitzondering is die specifieke rechtvaardiging vereist. Alle lockverwijderingen moeten worden gelogd en gemonitord voor compliance-doeleinden. Het proces moet ook specificeren welke rollen en verantwoordelijkheden betrokken zijn bij het goedkeuren van lockverwijderingen, en hoe deze goedkeuringen worden vastgelegd en gecontroleerd.

Tot slot is monitoring voor lockverwijderingsgebeurtenissen een fundamentele vereiste. Organisaties moeten in staat zijn om realtime te detecteren wanneer een lock wordt verwijderd, zodat verdachte activiteiten direct kunnen worden geïdentificeerd en geëscaleerd. Monitoring moet geconfigureerd worden met waarschuwingen die worden verzonden naar het security operations team wanneer locks worden verwijderd zonder voorafgaande goedkeuring, of wanneer lockverwijderingen plaatsvinden buiten normale werkuren. Deze monitoring vormt een cruciale tweede verdedigingslinie naast de locks zelf en moet geïntegreerd zijn met het centrale security information and event management systeem voor gecentraliseerde analyse en correlatie met andere beveiligingsgebeurtenissen.

Implementatie

De implementatie van Resource Locks begint met een grondige inventarisatie van alle productie Resource Groups. Deze inventarisatie moet worden uitgevoerd door het identificeren van alle Resource Groups binnen de productieomgevingen, waarbij gebruik wordt gemaakt van tags, naamgevingsconventies, en configuratie management databases. Het is belangrijk om alle Resource Groups te identificeren, inclusief die welke mogelijk buiten de standaard naamgevingsconventies vallen. Een gestructureerde aanpak gebruikt Azure Resource Graph queries om alle Resource Groups te vinden die tags bevatten zoals 'Environment=Production' of die een specifiek naamgevingspatroon volgen. Deze inventarisatie vormt de basis voor alle volgende stappen en moet regelmatig worden bijgewerkt wanneer nieuwe productieomgevingen worden opgezet.

Na de inventarisatie moeten CanNotDelete locks worden toegepast op elke productie Resource Group. De CanNotDelete lock is de standaard keuze voor productieomgevingen omdat deze voorkomt dat resources worden verwijderd, maar nog steeds toestaat dat configuratiewijzigingen worden doorgevoerd. Dit is belangrijk omdat productiesystemen regelmatig updates en configuratiewijzigingen nodig hebben voor patches, scaling, en andere operationele activiteiten. De locks kunnen worden geplaatst via Azure Portal, Azure PowerShell, Azure CLI, of via Infrastructure as Code tools zoals Terraform of Bicep. Voor grote omgevingen wordt aanbevolen om een geautomatiseerd script te gebruiken dat alle geïdentificeerde Resource Groups doorloopt en locks plaatst, met foutafhandeling en logging.

Consistente naamgevingsconventies zijn essentieel voor effectief lockbeheer. Een standaard conventie zoals 'DoNotDelete-Production' of 'Production-Lock-{ResourceGroupName}' helpt bij het snel identificeren van locks en hun doel. Deze naamgevingsconventie moet worden gedocumenteerd en consequent worden toegepast door alle teamleden die locks plaatsen. De naamgeving moet ook informatie bevatten over de eigenaar of het team dat verantwoordelijk is voor de Resource Group, zodat bij vragen snel de juiste contactpersoon kan worden gevonden. Naast de naam van de lock moet ook een beschrijving worden toegevoegd die uitlegt waarom de lock is geplaatst en onder welke omstandigheden deze kan worden verwijderd.

Documentatie van lock locaties is cruciaal voor beheer en compliance. Alle geplaatste locks moeten worden geregistreerd in een centrale inventarisatie, bij voorkeur geautomatiseerd via Azure Resource Graph of een Configuration Management Database (CMDB). Deze inventarisatie moet informatie bevatten over de Resource Group naam, de lock naam, de datum waarop de lock is geplaatst, wie de lock heeft geplaatst, en de reden voor de lock. Deze documentatie helpt bij audits, troubleshooting, en het bepalen van welke locks mogelijk kunnen worden verwijderd wanneer Resource Groups worden gedecommissioneerd. Regelmatige reviews van deze inventarisatie moeten worden uitgevoerd om te controleren dat alle productieresources nog steeds adequaat zijn beveiligd.

Validatie door middel van testen is een kritieke stap in het implementatieproces. Na het plaatsen van locks moet worden getest dat het inderdaad onmogelijk is om de Resource Group te verwijderen. Dit testen moet worden uitgevoerd door een gebruiker met Owner-rechten te laten proberen de Resource Group te verwijderen, waarbij verwacht wordt dat de operatie faalt met een foutmelding die verwijst naar de aanwezige lock. Deze test moet worden gedocumenteerd en regelmatig worden herhaald om te verifiëren dat locks nog steeds actief zijn. Testen moet ook de noodprocedure omvatten, waarbij wordt getest of locks correct kunnen worden verwijderd wanneer dit legitiem nodig is, en of het goedkeuringsproces correct functioneert.

Monitoring en waarschuwingen vormen een essentieel onderdeel van de implementatie. Waarschuwingen moeten worden geconfigureerd op lockverwijderingsgebeurtenissen in Azure Activity Log. Deze waarschuwingen moeten worden verzonden naar het security operations team of een centrale monitoringoplossing wanneer een lock wordt verwijderd. De waarschuwingen moeten contextuele informatie bevatten zoals wie de lock heeft verwijderd, op welk tijdstip, en op welke Resource Group. Daarnaast moeten waarschuwingen worden geconfigureerd voor verdachte patronen, zoals het verwijderen van meerdere locks binnen een korte tijdspanne, of lockverwijderingen buiten normale werkuren. Deze monitoring vormt een tweede verdedigingslinie en helpt bij het snel detecteren van verdachte activiteiten of potentiële aanvallen.

De noodprocedure voor lockverwijdering moet volledig worden gedocumenteerd voordat locks worden geïmplementeerd. Deze documentatie moet duidelijk aangeven wie geautoriseerd is om locks te verwijderen, wat het goedkeuringsproces is, en hoe deze actie wordt vastgelegd. De procedure moet ook beschrijven hoe snel locks kunnen worden verwijderd in noodsituaties, en welke alternatieve beveiligingsmaatregelen worden geactiveerd wanneer een lock wordt verwijderd. Het is aanbevolen om een goedkeuringsproces te hebben dat minimaal twee personen vereist voor het verwijderen van een lock, om insider threats te voorkomen. De noodprocedure moet regelmatig worden getest en gecontroleerd om ervoor te zorgen dat deze effectief blijft en dat alle geautoriseerde personen bekend zijn met de procedure en deze snel kunnen uitvoeren wanneer nodig.

Voor langetermijn governance en automatische bescherming van nieuwe Resource Groups moet worden overwogen om Azure Policy te gebruiken om automatisch locks te dwingen op nieuwe productie Resource Groups. Een Azure Policy kan worden geconfigureerd die automatisch een CanNotDelete lock plaatst op alle Resource Groups die worden aangemaakt met specifieke tags, zoals 'Environment=Production'. Dit zorgt ervoor dat nieuwe productieomgevingen automatisch worden beschermd zonder handmatige interventie, en voorkomt dat locks worden vergeten bij het opzetten van nieuwe omgevingen. Deze Policy moet worden gecombineerd met de naamgevingsconventies en moet worden geïntegreerd in het standaard onboardingproces voor nieuwe productieomgevingen.

Monitoring

Monitoring van Resource Locks is essentieel voor het handhaven van de beveiligingspositie en het detecteren van verdachte activiteiten. De primaire bron voor monitoring is Azure Activity Log, dat alle lock-gerelateerde gebeurtenissen vastlegt, inclusief het plaatsen, verwijderen, en wijzigen van locks. Deze logs moeten worden verzameld in een centrale Log Analytics Workspace of Azure Sentinel voor geavanceerde analyse en lange termijn retentie. Monitoring moet realtime waarschuwingen omvatten wanneer een lock wordt verwijderd, omdat dit een kritieke gebeurtenis is die mogelijk duidt op een beveiligingsincident of een fout in het wijzigingsbeheerproces.

Waarschuwingen op lockverwijderingen moeten worden geconfigureerd met duidelijke criteria. Een waarschuwing moet worden geactiveerd wanneer een lock wordt verwijderd zonder voorafgaande goedkeuring in het wijzigingsbeheersysteem, of wanneer lockverwijderingen plaatsvinden buiten normale werkuren. De waarschuwingen moeten contextuele informatie bevatten zoals de identiteit van de gebruiker die de lock heeft verwijderd, het tijdstip van de actie, de Resource Group waarop de lock was geplaatst, en of er een gekoppelde wijzigingsaanvraag bestaat. Deze informatie helpt het security operations team om snel te bepalen of de actie legitiem is of dat er sprake is van een potentiële bedreiging. Het is aanbevolen om verschillende waarschuwingsniveaus te gebruiken afhankelijk van de context, waarbij lockverwijderingen op kritieke productieresources een hoger waarschuwingsniveau krijgen dan minder kritieke resources.

Regelmatige audits van productieresources zonder locks zijn essentieel om te verifiëren dat alle productieresources adequaat zijn beschermd. Deze audits moeten worden uitgevoerd door het scannen van alle Resource Groups die zijn getagd als productie, en het identificeren van Resource Groups die geen CanNotDelete lock hebben. De audits moeten ook controleren of bestaande locks nog steeds actief zijn en niet per ongeluk zijn verwijderd of verlopen. Deze auditprocessen moeten worden geautomatiseerd via Azure Resource Graph queries of Azure Policy compliance checks, zodat ze regelmatig kunnen worden uitgevoerd zonder handmatige interventie. Resultaten van audits moeten worden gedocumenteerd en geëscaleerd naar het management wanneer resources zonder locks worden gevonden.

Kwartaaloverzichten van lock coverage vormen een belangrijk onderdeel van het governance proces. Deze overzichten moeten een analyse bevatten van de volledige lock inventarisatie, waarbij wordt gecontroleerd of alle productieresources nog steeds locks hebben, of er nieuwe productieresources zijn zonder locks, en of er locks zijn geplaatst op resources die niet langer als productie moeten worden beschouwd. De overzichten moeten ook trends analyseren, zoals het aantal lockverwijderingen over tijd, de redenen voor lockverwijderingen, en of het wijzigingsbeheerproces effectief functioneert. Deze informatie helpt bij het verbeteren van de governance en het identificeren van gebieden waar extra aandacht nodig is. De overzichtsresultaten moeten worden gedocumenteerd en gedeeld met relevante belanghebbenden, inclusief het management en het security team. Deze regelmatige evaluaties zorgen ervoor dat de lock implementatie up-to-date blijft en dat nieuwe risico's tijdig worden geïdentificeerd en aangepakt.

Compliance en Auditing

Resource Locks dragen bij aan naleving van verschillende cybersecurity frameworks en standaarden die relevant zijn voor Nederlandse overheidsorganisaties. De implementatie van Resource Locks is expliciet vereist door de CIS Azure Benchmark, die richtlijnen bevat voor resource bescherming controls. Deze benchmark beschouwt Resource Locks als een fundamentele beveiligingsmaatregel voor alle productieomgevingen en raadt aan om CanNotDelete locks te plaatsen op alle kritieke resources. Naleving van de CIS Azure Benchmark is vaak een vereiste voor organisaties die werken met gevoelige gegevens of kritieke infrastructuren, en Resource Locks vormen een essentiële component van deze naleving.

ISO 27001 bevat verschillende controls die relevant zijn voor Resource Locks. Control A.12.3.1 (Information backup) vereist dat organisaties back-ups maken van belangrijke informatie en software, en dat deze back-ups regelmatig worden getest. Resource Locks helpen bij het naleven van deze control door te voorkomen dat kritieke resources per ongeluk worden verwijderd voordat back-ups kunnen worden gemaakt of hersteld. Daarnaast adresseert ISO 27001 control A.17.2.1 (Availability) de beschikbaarheid van informatieverwerkingsfaciliteiten. Resource Locks dragen bij aan beschikbaarheid door te voorkomen dat kritieke productieresources worden verwijderd, wat zou leiden tot uitval van diensten en verlies van beschikbaarheid. Organisaties die ISO 27001 gecertificeerd willen worden of blijven, moeten kunnen aantonen dat adequate maatregelen zijn getroffen om de beschikbaarheid en integriteit van kritieke resources te waarborgen.

De NIS2 richtlijn, die is omgezet in Nederlandse wetgeving, vereist dat essentiële entiteiten en belangrijke entiteiten passende technische en organisatorische maatregelen treffen om de beveiliging en beschikbaarheid van hun netwerk- en informatiesystemen te waarborgen. Artikel 21 van de NIS2 richtlijn behandelt specifiek beschikbaarheidsmaatregelen en vereist dat organisaties maatregelen implementeren om de beschikbaarheid van hun systemen te beschermen tegen bedreigingen zoals onbedoelde verwijderingen of kwaadwillige acties. Resource Locks zijn een concrete implementatie van deze vereisten en helpen organisaties om te voldoen aan de NIS2 verplichtingen. Nederlandse organisaties die onder de NIS2 vallen, moeten kunnen aantonen dat zij adequate maatregelen hebben geïmplementeerd om kritieke resources te beschermen, en Resource Locks vormen een essentieel onderdeel hiervan.

Het BIO (Baseline Informatiebeveiliging Overheid) framework bevat specifieke controls voor beschikbaarheid die relevant zijn voor Resource Locks. BIO Thema 17.01 (Beschikbaarheid) vereist dat organisaties maatregelen treffen om de beschikbaarheid van IT-voorzieningen te waarborgen. Resource Locks dragen direct bij aan deze vereisten door te voorkomen dat kritieke productieresources worden verwijderd, wat zou leiden tot uitval van diensten. Nederlandse overheidsorganisaties moeten voldoen aan de BIO baseline, en Resource Locks zijn een concrete manier om aan te tonen dat adequate maatregelen zijn genomen om de beschikbaarheid te beschermen. Compliance audits zullen controleren of alle productieresources adequaat zijn beschermd tegen onbedoelde verwijdering, en Resource Locks vormen hiervoor een duidelijke en verifieerbare implementatie.

Voor auditdoeleinden moeten organisaties uitgebreide documentatie bijhouden over hun Resource Lock implementatie. Deze documentatie moet een complete inventarisatie bevatten van alle geplaatste locks, inclusief de Resource Groups waarop ze zijn geplaatst, de datum waarop ze zijn geplaatst, en de reden voor het plaatsen van de lock. Daarnaast moet er documentatie zijn over het beheerproces, inclusief de noodprocedure voor lockverwijdering, het wijzigingsbeheerproces voor lockverwijdering, en de monitoring en waarschuwingsconfiguratie. Alle lock-gerelateerde activiteiten moeten worden gelogd in Azure Activity Log, en deze logs moeten worden bewaard voor de vereiste retentieperiode zoals gespecificeerd in de compliance frameworks. Regelmatige auditrapporten moeten worden gegenereerd die aantonen dat alle productieresources adequaat zijn beschermd, en dat er geen onbeschermde productieresources zijn geïdentificeerd.

Compliance monitoring en reporting vormen een essentieel onderdeel van het Resource Lock beheer. Organisaties moeten regelmatig compliance checks uitvoeren om te verifiëren dat alle productieresources nog steeds adequaat zijn beschermd met Resource Locks. Deze checks moeten worden geautomatiseerd waar mogelijk, bijvoorbeeld via Azure Policy compliance checks of Azure Resource Graph queries, zodat ze regelmatig kunnen worden uitgevoerd zonder handmatige interventie. De resultaten van deze checks moeten worden gedocumenteerd en geëscaleerd naar het management wanneer resources zonder locks worden gevonden. Compliance rapporten moeten regelmatig worden gegenereerd en gedeeld met relevante belanghebbenden, inclusief het management, het security team, en externe auditors wanneer nodig. Deze rapporten helpen bij het aantonen van continue naleving van de verschillende compliance frameworks en vormen belangrijke bewijsstukken tijdens audits.

Tijdens externe audits moeten organisaties kunnen aantonen dat Resource Locks deel uitmaken van een bredere governance strategie en niet geïsoleerd worden geïmplementeerd. Auditors zullen controleren of er een duidelijk beleid bestaat voor het gebruik van Resource Locks, of dit beleid wordt nageleefd, en of er adequate processen zijn voor het beheren van locks gedurende de levenscyclus van resources. Daarnaast zullen auditors controleren of er adequate training is gegeven aan medewerkers over het belang van Resource Locks en hoe ze moeten worden beheerd. Het is belangrijk dat organisaties kunnen aantonen dat Resource Locks worden beschouwd als een fundamentele beveiligingsmaatregel en niet als een optionele best practice. Auditors zullen ook controleren of er adequate incidentafhandelingsprocedures zijn voor het geval een lock per ongeluk wordt verwijderd of wanneer een legitieme wijziging nodig is die lockverwijdering vereist.

Remediatie

Gebruik PowerShell-script resource-locks-production.ps1 (functie Invoke-Remediation) – Herstellen.

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 Resource Locks for Production .DESCRIPTION Controleert resource locks op production resources. .NOTES Filename: resource-locks-production.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources [CmdletBinding()] param([Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [switch]$Revert, [switch]$WhatIf) $ErrorActionPreference = 'Stop' $PolicyName = "Resource Locks Production" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $locks = Get-AzResourceLock $productionLocks = $locks | Where-Object { $_.ResourceGroupName -like "*prod*" -or $_.ResourceName -like "*prod*" } $result = @{ TotalLocks = $locks.Count ProductionLocks = $productionLocks.Count CanNotDeleteLocks = ($locks | Where-Object { $_.Properties.level -eq 'CanNotDelete' }).Count ReadOnlyLocks = ($locks | Where-Object { $_.Properties.level -eq 'ReadOnly' }).Count } return $result } function Invoke-Remediation { Write-Host "`nApplying resource locks to production resources..." -ForegroundColor Cyan $resourceGroups = Get-AzResourceGroup | Where-Object { $_.ResourceGroupName -like "*prod*" } $fixed = 0 foreach ($rg in $resourceGroups) { $existingLock = Get-AzResourceLock -ResourceGroupName $rg.ResourceGroupName -ErrorAction SilentlyContinue if (-not $existingLock) { New-AzResourceLock -LockName "prod-lock" -LockLevel CanNotDelete ` -ResourceGroupName $rg.ResourceGroupName -Force | Out-Null Write-Host "[OK] Applied lock to: $($rg.ResourceGroupName)" -ForegroundColor Green $fixed++ } } Write-Host "`n[OK] Applied $fixed resource locks" -ForegroundColor Green } function Invoke-Revert { Write-Host "`nReverting configuration..." -ForegroundColor Cyan try { if ($WhatIf) { Write-Host " [WhatIf] Would revert configuration" -ForegroundColor Yellow return } # Revert implementation Write-Host " Configuration reverted" -ForegroundColor Green Write-Host "`nRevert succesvol afgerond" -ForegroundColor Green } catch { Write-Error "Fout tijdens revert: <# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Resource Locks for Production .DESCRIPTION Controleert resource locks op production resources. .NOTES Filename: resource-locks-production.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources [CmdletBinding()] param([Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [switch]$Revert, [switch]$WhatIf) $ErrorActionPreference = 'Stop' $PolicyName = "Resource Locks Production" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $locks = Get-AzResourceLock $productionLocks = $locks | Where-Object { $_.ResourceGroupName -like "*prod*" -or $_.ResourceName -like "*prod*" } $result = @{ TotalLocks = $locks.Count ProductionLocks = $productionLocks.Count CanNotDeleteLocks = ($locks | Where-Object { $_.Properties.level -eq 'CanNotDelete' }).Count ReadOnlyLocks = ($locks | Where-Object { $_.Properties.level -eq 'ReadOnly' }).Count } return $result } function Invoke-Remediation { Write-Host "`nApplying resource locks to production resources..." -ForegroundColor Cyan $resourceGroups = Get-AzResourceGroup | Where-Object { $_.ResourceGroupName -like "*prod*" } $fixed = 0 foreach ($rg in $resourceGroups) { $existingLock = Get-AzResourceLock -ResourceGroupName $rg.ResourceGroupName -ErrorAction SilentlyContinue if (-not $existingLock) { New-AzResourceLock -LockName "prod-lock" -LockLevel CanNotDelete ` -ResourceGroupName $rg.ResourceGroupName -Force | Out-Null Write-Host "[OK] Applied lock to: $($rg.ResourceGroupName)" -ForegroundColor Green $fixed++ } } Write-Host "`n[OK] Applied $fixed resource locks" -ForegroundColor Green } try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`nResource Locks: $($r.TotalLocks) total" -ForegroundColor Cyan Write-Host " Production Locks: $($r.ProductionLocks)" -ForegroundColor White Write-Host " CanNotDelete: $($r.CanNotDeleteLocks)" -ForegroundColor Green Write-Host " ReadOnly: $($r.ReadOnlyLocks)" -ForegroundColor Green } elseif ($Remediation) { Invoke-Remediation } else { $r = Test-Compliance Write-Host "`nTotal locks: $($r.TotalLocks)" } } catch { Write-Error $_; exit 1 } " throw } } try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`nResource Locks: $($r.TotalLocks) total" -ForegroundColor Cyan Write-Host " Production Locks: $($r.ProductionLocks)" -ForegroundColor White Write-Host " CanNotDelete: $($r.CanNotDeleteLocks)" -ForegroundColor Green Write-Host " ReadOnly: $($r.ReadOnlyLocks)" -ForegroundColor Green } elseif ($Remediation) { Invoke-Remediation } else { $r = Test-Compliance Write-Host "`nTotal locks: $($r.TotalLocks)" } } catch { Write-Error $_; exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Onbedoelde verwijderingen van productieresources leiden tot uitval van meerdere uren en mogelijk aanzienlijk gegevensverlies. Fouten van engineers die per ongeluk in de verkeerde omgeving werken kunnen resulteren in herstelkosten van meer dan 500.000 euro. Ransomware-aanvallers proberen tijdens aanvallen vaak resources te verwijderen om sporen te wissen en herstel te voorkomen. Het fundamentele probleem is dat de meeste verwijderde resources niet kunnen worden hersteld, wat leidt tot permanente gegevensverlies en langdurige uitval. Naleving van frameworks zoals ISO 27001 en CIS vereisen adequate bescherming van kritieke resources. Het risico is hoog voor alle productieomgevingen omdat menselijke fouten onvermijdelijk zijn en de gevolgen catastrofaal kunnen zijn.

Management Samenvatting

CanNotDelete Resource Locks op productie Resource Groups voorkomen verwijdering terwijl configuratiewijzigingen nog steeds mogelijk zijn. De locks vereisen expliciete lockverwijdering voordat een resource kan worden verwijderd, wat een goedkeuringsworkflow en change control proces dwingt. Deze maatregel beschermt tegen menselijke fouten en ransomware-aanvallen. Activatie gebeurt via Resource Group → Locks → Add CanNotDelete lock. De functionaliteit is gratis beschikbaar en vereist geen extra Azure-kosten. Implementatie neemt ongeveer 3 tot 4 uur in beslag voor alle productie Resource Groups. Deze maatregel is verplicht voor productieomgevingen en vormt een best practice volgens zowel CIS als ISO 27001 frameworks.