BIO 17.02.01 ISO A.17.2.1

Resource Locks Op Mission-Critical Resources

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

💼 Management Samenvatting

Mission-critical resources vereisen ReadOnly locks die alle wijzigingen voorkomen, niet alleen verwijdering. Deze bescherming is essentieel voor resources waarbij configuratiewijzigingen directe uitval veroorzaken.

Aanbeveling
Implementeer voor mission-critical resources
Risico zonder
Critical
Risk Score
10/10
Implementatie
3u (tech: 2u)
Van toepassing op:
✓ Mission-Critical Resources

Mission-critical resources zoals productiedatabases, kernnetwerken en identiteitsinfrastructuur vormen het hart van organisaties en zijn essentieel voor de continuïteit van bedrijfsprocessen. Deze resources hebben een Recovery Time Objective (RTO) van minder dan één uur, wat betekent dat uitval directe en aanzienlijke impact heeft op de organisatie. Een enkele verkeerde configuratie kan leiden tot een uitval van meerdere uren, met als gevolg verlies van productiviteit, financiële schade en mogelijk reputatieschade. Configuratiewijzigingen vormen een hoog risico omdat ze directe impact hebben op de beschikbaarheid van kritieke diensten. Zelfs kleine wijzigingen kunnen cascade-effecten veroorzaken die leiden tot complete systeemuitval. Een ReadOnly lock voorkomt alle wijzigingen, inclusief verwijdering en aanpassingen, en vereist expliciete verwijdering van de lock plus goedkeuring voordat wijzigingen mogelijk zijn. Deze bescherming is cruciaal voor resources waarvan de beschikbaarheid direct gekoppeld is aan de bedrijfscontinuïteit. Voorbeelden van mission-critical resources zijn productie Azure SQL Databases die essentiële bedrijfsdata bevatten, Hub Virtual Networks die de kern vormen van de netwerkinfrastructuur, Azure AD Connect servers die identiteitsfederatie verzorgen, Backup vaults die essentiële hersteldata bevatten, en Key Vaults met productiesleutels die gebruikt worden voor encryptie en authenticatie.

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

Implementatie

Het fundamentele verschil tussen ReadOnly en CanNotDelete locks vormt de kern van een effectieve beveiligingsstrategie voor Azure-resources en is cruciaal voor het beschermen van mission-critical infrastructuur tegen onbevoegde wijzigingen en verwijdering. CanNotDelete locks vormen een relatief lichte beveiligingsmaatregel die uitsluitend voorkomt dat resources worden verwijderd, maar alle andere vormen van wijzigingen, inclusief configuratiewijzigingen, schaaloperaties en andere modificaties, nog steeds toestaat. Dit betekent dat hoewel een resource niet per ongeluk kan worden verwijderd, een aanvaller of gecompromitteerd account nog steeds wijzigingen kan aanbrengen die de beschikbaarheid, integriteit of vertrouwelijkheid van het resource kunnen compromitteren. ReadOnly locks daarentegen bieden complete en uitgebreide bescherming door zowel verwijdering als alle mogelijke vormen van wijzigingen te blokkeren, inclusief configuratiewijzigingen, schaaloperaties, naamswijzigingen en andere modificaties, waardoor ze een veel sterker beveiligingsniveau bieden dat essentieel is voor mission-critical resources. Het maken van de juiste keuze tussen deze twee typen locks is fundamenteel voor het implementeren van een effectieve beveiligingsstrategie die is afgestemd op de kritiekheid en risicoprofiel van elk resource. Mission-critical resources, die worden gedefinieerd als resources met een Recovery Time Objective van minder dan één uur en waarvan uitval directe en aanzienlijke impact heeft op de bedrijfscontinuïteit, krijgen daarom ReadOnly locks toegepast om maximale bescherming te bieden tegen alle vormen van wijzigingen. Reguliere productieresources, die wel belangrijk zijn maar niet dezelfde kritiekheid hebben, krijgen CanNotDelete locks toegepast die voldoende bescherming bieden tegen verwijdering maar nog steeds flexibiliteit bieden voor legitieme configuratiewijzigingen. De implementatie van deze locks omvat een gestructureerde en methodische aanpak die begint met het systematisch identificeren en classificeren van alle resources op basis van hun kritiekheid en impact op de bedrijfscontinuïteit. Mission-critical resources worden geïdentificeerd op basis van specifieke criteria, waaronder een Recovery Time Objective van minder dan één uur, directe impact op kritieke bedrijfsprocessen, en de potentie om aanzienlijke financiële schade of reputatieschade te veroorzaken bij uitval. Zodra deze resources zijn geïdentificeerd, worden ReadOnly locks toegepast op alle mission-critical resources om te zorgen dat zij volledig beschermd zijn tegen zowel verwijdering als wijzigingen. Daarnaast wordt een uitgebreide en goed gedocumenteerde noodprocedure ontwikkeld voor het verwijderen van locks in noodsituaties, met strikte controles en goedkeuringsprocessen om te voorkomen dat locks onbevoegd worden verwijderd. Ten slotte wordt een gestructureerd en regelmatig reviewproces op kwartaalbasis ingesteld waarbij de volledige inventaris van mission-critical resources wordt geëvalueerd en bijgewerkt om ervoor te zorgen dat nieuwe resources worden beveiligd en dat de kritiekheid van bestaande resources regelmatig wordt herbeoordeeld.

Implementatie

Gebruik PowerShell-script resource-locks-mission-critical.ps1 (functie Invoke-Implementation) – Implementeren.

Monitoring

Gebruik PowerShell-script resource-locks-mission-critical.ps1 (functie Invoke-Monitoring) – Controleren.

Compliance en Auditing

Remediatie

Gebruik PowerShell-script resource-locks-mission-critical.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 Mission Critical .DESCRIPTION Controleert resource locks op mission-critical resources. .NOTES Filename: resource-locks-mission-critical.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) $ErrorActionPreference = 'Stop' $PolicyName = "Resource Locks Mission Critical" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $locks = Get-AzResourceLock $criticalLocks = $locks | Where-Object { $_.ResourceGroupName -like "*critical*" -or $_.ResourceGroupName -like "*mission*" -or $_.ResourceName -like "*critical*" } $result = @{ TotalLocks = $locks.Count CriticalLocks = $criticalLocks.Count ReadOnlyLocks = ($locks | Where-Object { $_.Properties.level -eq 'ReadOnly' }).Count } 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 Locks: $($r.TotalLocks)" -ForegroundColor White Write-Host "Mission Critical Locks: $($r.CriticalLocks)" -ForegroundColor $(if ($r.CriticalLocks -gt 0) { 'Green' } else { 'Yellow' }) Write-Host "ReadOnly Locks: $($r.ReadOnlyLocks)" -ForegroundColor Green } else { $r = Test-Compliance Write-Host "`nCritical Locks: $($r.CriticalLocks)/$($r.TotalLocks)" } } 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 Locks: $($r.TotalLocks)" -ForegroundColor White Write-Host "Mission Critical Locks: $($r.CriticalLocks)" -ForegroundColor $(if ($r.CriticalLocks -gt 0) { 'Green' } else { 'Yellow' }) Write-Host "ReadOnly Locks: $($r.ReadOnlyLocks)" -ForegroundColor Green } else { $r = Test-Compliance Write-Host "`nCritical Locks: $($r.CriticalLocks)/$($r.TotalLocks)" } } 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
Critical: Een enkele verkeerde configuratie op een mission-critical resource kan leiden tot onmiddellijke uitval van meerdere uren. Een wijziging aan een productiedatabase kan resulteren in data corruptie en onherstelbaar verlies van informatie. Een wijziging aan een Virtual Network kan leiden tot complete netwerkuitval waardoor alle services onbereikbaar worden. Zonder adequate change control is een Recovery Time Objective van minder dan één uur niet haalbaar, wat betekent dat de organisatie niet kan voldoen aan haar beschikbaarheidsverplichtingen. Het risico is kritiek voor mission-critical resources zoals core databases, primary Virtual Networks en Azure AD Connect servers, waar uitval directe impact heeft op de bedrijfscontinuïteit.

Management Samenvatting

ReadOnly Resource Locks op mission-critical resources voorkomen zowel verwijdering als alle wijzigingen, wat strenger is dan CanNotDelete locks die alleen verwijdering voorkomen. Deze locks moeten worden toegepast op productiedatabases met een Recovery Time Objective van minder dan één uur, core Virtual Networks, Azure AD Connect servers en Key Vaults met productiesleutels. Het wijzigingsproces vereist goedkeuring van de Chief Technology Officer, gevolgd door verwijdering van de lock, uitvoering van de wijziging en onmiddellijk hertoepassen van de lock. Activatie gebeurt via de Azure Portal door naar het resource te navigeren, Locks te selecteren en een ReadOnly lock toe te voegen. De implementatie is kosteloos en neemt ongeveer twee tot drie uur in beslag. Deze maatregel is essentieel voor alle resources met een Recovery Time Objective van minder dan één uur.