Azure: Aangepaste Rollen Voorkomen Van Resource Lock Verwijdering

💼 Management Samenvatting

Aangepaste RBAC-rollen mogen geen Microsoft.Authorization/locks/delete-machtiging bevatten om te voorkomen dat resource locks onbevoegd worden verwijderd.

Aanbeveling
VERIFIEER PREVENTIE VAN LOCK-OMZEILING
Risico zonder
Medium
Risk Score
5/10
Implementatie
2u (tech: 1u)
Van toepassing op:
Azure

Resource locks vormen een essentiële beveiligingslaag die kritieke Azure-resources beschermt tegen onbedoelde verwijdering en wijzigingen. Deze beveiligingsmechanismen zijn ontworpen om te voorkomen dat zelfs beheerders met uitgebreide rechten per ongeluk of opzettelijk kritieke infrastructuurcomponenten kunnen verwijderen of wijzigen. Wanneer aangepaste rollen de mogelijkheid krijgen om resource locks te verwijderen, wordt deze beschermingslaag volledig omzeild en ontstaat er een significant beveiligingsrisico dat de fundamentele beveiligingsarchitectuur van de cloudomgeving ondermijnt. Dit kan leiden tot onbedoelde verwijdering van productieomgevingen, databases, netwerkconfiguraties of andere kritieke infrastructuurcomponenten die essentieel zijn voor de continuïteit van dienstverlening. In de context van Nederlandse overheidsorganisaties, waar de beschikbaarheid en integriteit van systemen direct verband houden met de levering van publieke diensten aan burgers, kan een dergelijk beveiligingslek catastrofale gevolgen hebben. De implementatie van strikte toegangscontroles op resource locks is daarom van fundamenteel belang voor het behoud van de integriteit, beschikbaarheid en vertrouwelijkheid van cloudomgevingen binnen de Nederlandse publieke sector. Bovendien vormt het beveiligen van resource locks een kritieke vereiste voor compliance met verschillende beveiligingsstandaarden en frameworks die van toepassing zijn op overheidsorganisaties.

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

Implementatie

Deze beveiligingsmaatregel vereist dat u systematisch verifieert dat alle aangepaste rollen binnen uw Azure-omgeving geen Microsoft.Authorization/locks/delete-actie bevatten. Deze verificatie moet regelmatig worden uitgevoerd als onderdeel van uw beveiligingsauditproces. Alleen de ingebouwde rollen Owner en User Access Administrator mogen resource locks verwijderen, omdat deze rollen expliciet zijn ontworpen voor beheer op het hoogste niveau en de juiste beveiligingscontroles en verantwoordelijkheden bevatten. Door deze beperking strikt te handhaven, wordt voorkomen dat gebruikers met aangepaste rollen de beveiligingsmaatregelen kunnen omzeilen die zijn ingesteld om kritieke resources te beschermen. Het proces omvat het inventariseren van alle aangepaste rollen, het analyseren van hun machtigingen, het identificeren van rollen die ongewenste lock-machtigingen bevatten, en het verwijderen van deze machtigingen uit de roldefinitie. Daarnaast moet u ervoor zorgen dat gebruikers die legitiem resource locks moeten kunnen beheren, de juiste ingebouwde rollen krijgen toegewezen in plaats van aangepaste rollen met uitgebreide machtigingen.

Vereisten

Voordat u begint met het controleren en configureren van aangepaste rollen voor resource lock-beveiliging, dient u te beschikken over een actieve Azure-abonnement met voldoende rechten om RBAC-rollen te kunnen bekijken en beheren. Als beheerder moet u minimaal de rol Reader hebben op het abonnementniveau om aangepaste rollen te kunnen inventariseren en hun machtigingen te kunnen bekijken. Voor het daadwerkelijk uitvoeren van wijzigingen aan roldefinities heeft u echter de rol User Access Administrator of Owner nodig, omdat deze rollen de vereiste machtigingen bevatten om roldefinities te wijzigen. Het is belangrijk om te begrijpen dat het wijzigen van aangepaste rollen directe gevolgen kan hebben voor alle gebruikers, service principals en managed identities die deze rollen hebben toegewezen gekregen. Daarom is het essentieel dat u een volledige inventarisatie heeft van alle aangepaste rollen die binnen uw Azure-omgeving zijn gedefinieerd, inclusief informatie over welke entiteiten deze rollen momenteel gebruiken. Deze inventarisatie moet niet alleen de rollen zelf omvatten, maar ook de specifieke machtigingen die aan elke rol zijn toegekend, met bijzondere aandacht voor machtigingen die betrekking hebben op resource locks en andere kritieke beveiligingsfuncties. Zonder een compleet overzicht van uw aangepaste rollen is het onmogelijk om effectief te controleren of er rollen zijn die de Microsoft.Authorization/locks/delete-machtiging bevatten of andere ongewenste beveiligingsmachtigingen. Het is aanbevolen om deze inventarisatie regelmatig bij te werken, vooral na wijzigingen in de rollenstructuur of wanneer nieuwe aangepaste rollen worden toegevoegd aan de omgeving. Daarnaast moet u beschikken over de juiste PowerShell-modules, met name Az.Accounts en Az.Resources, die nodig zijn voor het uitvoeren van de controle- en implementatiescripts. Zorg ervoor dat u bent aangemeld bij de juiste Azure-tenant en dat u toegang hebt tot alle abonnementen waar u de controle wilt uitvoeren. Voor organisaties met meerdere abonnementen of management groups is het belangrijk om een gestructureerde aanpak te volgen waarbij u systematisch door alle omgevingen gaat om ervoor te zorgen dat geen enkele aangepaste rol over het hoofd wordt gezien. Documenteer uw bevindingen en zorg voor een duidelijk proces voor het goedkeuren en implementeren van wijzigingen aan roldefinities, waarbij meerdere personen betrokken zijn bij het reviewproces om menselijke fouten te voorkomen.

Monitoring en controle

Gebruik PowerShell-script custom-role-resource-locks.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van aangepaste rollen op de aanwezigheid van resource lock-verwijdermachtigingen vormt een kritieke beveiligingstaak die regelmatig moet worden uitgevoerd als onderdeel van uw continue beveiligingsbewaking. Deze monitoringactiviteit is essentieel voor het waarborgen van de integriteit van uw Azure-beveiligingsarchitectuur en het voorkomen van onbevoegde omzeiling van resource locks die zijn ingesteld om kritieke infrastructuurcomponenten te beschermen. Het monitoringproces begint met het systematisch ophalen van alle aangepaste rollen binnen uw Azure-abonnement met behulp van de PowerShell-cmdlet Get-AzRoleDefinition. Deze cmdlet retourneert gedetailleerde informatie over elke rol, inclusief alle acties en machtigingen die aan de rol zijn toegekend, evenals informatie over het bereik waarop de rol is gedefinieerd. Deze informatie vormt de basis voor een grondige analyse van de beveiligingsimplicaties van elke aangepaste rol binnen uw omgeving. Tijdens de scan moet u specifiek zoeken naar de Microsoft.Authorization/locks/delete-actie binnen de Actions of DataActions-eigenschappen van elke aangepaste rol. Deze specifieke actie vormt het primaire beveiligingsrisico omdat deze direct de mogelijkheid biedt om resource locks te verwijderen, waardoor de bescherming van kritieke resources volledig wordt omzeild. Daarnaast is het belangrijk om ook te controleren op wildcard-machtigingen zoals Microsoft.Authorization/locks/* of Microsoft.Authorization/*, omdat deze eveneens de mogelijkheid bieden om resource locks te verwijderen en mogelijk een nog groter beveiligingsrisico vormen vanwege hun brede reikwijdte. Wanneer een aangepaste rol deze machtiging bevat, vormt dit een significant beveiligingsrisico omdat gebruikers met deze rol resource locks kunnen verwijderen, waardoor de bescherming van kritieke resources volledig wordt omzeild. Dit risico wordt nog versterkt wanneer dergelijke rollen worden toegewezen aan service principals of managed identities die worden gebruikt voor geautomatiseerde processen, omdat deze mogelijk onbeheerd kunnen worden en een groter aanvalsoppervlak vormen. Service principals en managed identities worden vaak gebruikt in geautomatiseerde workflows en kunnen, indien gecompromitteerd, aanzienlijke schade aanrichten wanneer zij beschikken over machtigingen om resource locks te verwijderen. Het is daarom essentieel om deze controle niet alleen eenmalig uit te voeren, maar als onderdeel van een regelmatig terugkerend auditproces dat is geïntegreerd in uw algemene beveiligingsgovernance. Deze continue monitoring benadering zorgt ervoor dat nieuwe beveiligingsrisico's tijdig worden gedetecteerd en verholpen voordat zij kunnen worden uitgebuit. Aanbevolen wordt om minimaal maandelijks een volledige scan uit te voeren op alle abonnementen en management groups binnen uw Azure-omgeving, en direct na elke wijziging in aangepaste rollen een aanvullende controle te doen om ervoor te zorgen dat nieuwe of gewijzigde rollen geen ongewenste machtigingen bevatten. Deze proactieve benadering voorkomt dat beveiligingslekken onopgemerkt blijven en zorgt ervoor dat uw beveiligingspostuur altijd up-to-date is. De resultaten van deze controles moeten worden gedocumenteerd en bewaard voor compliance-doeleinden, zodat u kunt aantonen dat u proactief toezicht houdt op de beveiligingsconfiguratie van uw Azure-omgeving. Deze documentatie vormt een essentieel onderdeel van uw audit trail en is vereist voor het voldoen aan verschillende compliance-frameworks zoals CIS Azure Foundations Benchmark en de BIO-norm. Overweeg het automatiseren van deze controles met behulp van Azure Policy of Azure Automation runbooks, zodat u real-time waarschuwingen ontvangt wanneer er wijzigingen worden gedetecteerd die mogelijk een beveiligingsrisico vormen. Geautomatiseerde monitoring biedt het voordeel dat beveiligingsrisico's onmiddellijk worden gedetecteerd, zelfs buiten normale kantooruren, en zorgt voor een consistente en betrouwbare beveiligingsbewaking. Daarnaast is het belangrijk om de resultaten van deze controles te analyseren en trends te identificeren, zodat u proactief kunt ingrijpen voordat er daadwerkelijk een beveiligingsincident plaatsvindt. Trendanalyse kan helpen bij het identificeren van patronen in beveiligingsconfiguraties en het voorspellen van potentiële beveiligingsrisico's. Integreer deze monitoringactiviteiten in uw bestaande security operations center (SOC) processen en zorg ervoor dat de juiste personen worden geïnformeerd wanneer er afwijkingen worden gedetecteerd. Deze integratie zorgt voor een gecoördineerde respons op beveiligingsincidenten en voorkomt dat kritieke informatie verloren gaat in de communicatie tussen verschillende teams.

Implementatie

Gebruik PowerShell-script custom-role-resource-locks.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van beveiligingsmaatregelen voor resource locks vormt een kritieke stap in het versterken van de beveiligingsarchitectuur van uw Azure-omgeving. Deze implementatie begint met een grondige en systematische review van alle aangepaste rollen binnen uw Azure-omgeving, waarbij elke rol wordt geanalyseerd op de aanwezigheid van machtigingen die betrekking hebben op resource locks. Deze review moet worden uitgevoerd door ervaren beveiligingsprofessionals die volledig begrijpen welke machtigingen legitiem zijn en welke een beveiligingsrisico vormen. Tijdens deze review moet u elke aangepaste rol systematisch analyseren op de aanwezigheid van machtigingen die betrekking hebben op resource locks, met name de Microsoft.Authorization/locks/delete-actie en andere verwante lock-machtigingen zoals Microsoft.Authorization/locks/* of bredere wildcard-machtigingen zoals Microsoft.Authorization/* die eveneens de mogelijkheid bieden om resource locks te beheren. Deze wildcard-machtigingen vormen een bijzonder risico omdat zij niet alleen de mogelijkheid bieden om resource locks te verwijderen, maar mogelijk ook toegang verlenen tot andere kritieke beveiligingsfuncties. Het is daarom essentieel om alle varianten van lock-machtigingen te identificeren en te verwijderen, niet alleen de specifieke delete-actie. Het is belangrijk om deze review uit te voeren op alle niveaus van uw Azure-hiërarchie, inclusief management groups, abonnementen en resource groups, omdat aangepaste rollen op verschillende niveaus kunnen worden gedefinieerd en elk niveau zijn eigen beveiligingsimplicaties heeft. Rollen die zijn gedefinieerd op management group-niveau hebben bijvoorbeeld een veel bredere reikwijdte dan rollen die zijn gedefinieerd op resource group-niveau, en vormen daarom een potentieel groter beveiligingsrisico wanneer zij ongewenste machtigingen bevatten. Wanneer u een aangepaste rol identificeert die deze machtigingen bevat, dient u eerst een grondige impactanalyse uit te voeren om te bepalen welke gebruikers, service principals of managed identities momenteel deze rol hebben toegewezen gekregen. Deze analyse is essentieel omdat het verwijderen van machtigingen directe gevolgen kan hebben voor deze entiteiten en mogelijk hun werkzaamheden kan verstoren. Het is belangrijk om te begrijpen welke functionaliteit mogelijk wordt beïnvloed door het verwijderen van deze machtigingen en of er alternatieve oplossingen beschikbaar zijn. Vervolgens dient u deze machtigingen onmiddellijk te verwijderen uit de roldefinitie, waarbij u ervoor moet zorgen dat u geen andere legitieme machtigingen verwijdert die nodig zijn voor de functionaliteit van de rol. Dit proces vereist zorgvuldige aandacht en moet idealiter worden uitgevoerd in een testomgeving voordat u wijzigingen doorvoert in productie. Het testen van wijzigingen in een gecontroleerde omgeving helpt bij het identificeren van potentiële problemen voordat deze de productieomgeving beïnvloeden. Na het verwijderen van de lock-machtigingen moet u de roldefinitie bijwerken met behulp van de Set-AzRoleDefinition-cmdlet, waarbij u ervoor moet zorgen dat u de volledige roldefinitie inclusief alle andere machtigingen behoudt. Het is essentieel om een back-up te maken van de oorspronkelijke roldefinitie voordat u wijzigingen doorvoert, zodat u indien nodig kunt terugkeren naar de vorige staat. Voor het beheer van resource locks dient u uitsluitend gebruik te maken van de ingebouwde Azure-rollen Owner of User Access Administrator, omdat deze rollen expliciet zijn ontworpen voor beheer op het hoogste niveau en de juiste beveiligingscontroles bevatten. Deze ingebouwde rollen zijn onderworpen aan strikte beveiligingscontroles en worden regelmatig geaudit door Microsoft, waardoor zij een betrouwbaardere keuze vormen dan aangepaste rollen. Als er gebruikers zijn die legitiem resource locks moeten kunnen beheren, dient u hen deze ingebouwde rollen toe te wijzen in plaats van een aangepaste rol met uitgebreide machtigingen. Deze aanpak zorgt ervoor dat alleen bevoegde beheerders resource locks kunnen beheren, terwijl alle andere gebruikers en rollen deze kritieke beveiligingsmaatregel niet kunnen omzeilen. Documenteer alle wijzigingen die u doorvoert en zorg ervoor dat u een rollback-plan hebt voor het geval dat er onverwachte problemen optreden. Deze documentatie vormt een essentieel onderdeel van uw change management proces en is vereist voor compliance-doeleinden. Implementeer daarnaast processen om toekomstige wijzigingen aan aangepaste rollen te controleren, zodat u kunt voorkomen dat ongewenste machtigingen opnieuw worden toegevoegd. Deze processen moeten deel uitmaken van uw algemene beveiligingsgovernance en moeten worden geïntegreerd in uw change management workflows.

Compliance en Auditing

De beveiliging van resource locks door middel van aangepaste rollen vormt een fundamenteel onderdeel van verschillende compliance-frameworks die van toepassing zijn op Nederlandse overheidsorganisaties. Deze beveiligingsmaatregel is niet alleen een technische best practice, maar ook een essentiële vereiste voor het voldoen aan nationale en internationale beveiligingsstandaarden die specifiek zijn ontwikkeld voor de publieke sector. De implementatie van strikte toegangscontroles op resource locks draagt direct bij aan het waarborgen van de beschikbaarheid, integriteit en vertrouwelijkheid van kritieke overheidsinformatie en diensten. De CIS Azure Foundations Benchmark versie 1.24 bevat specifieke en gedetailleerde richtlijnen voor het beheer van aangepaste rollen en het voorkomen van onbevoegde toegang tot kritieke beveiligingsfuncties zoals resource locks. Deze benchmark, die wordt erkend als een van de meest uitgebreide beveiligingsstandaarden voor cloudomgevingen, vereist expliciet dat organisaties regelmatig en systematisch controleren of aangepaste rollen geen onnodige of gevaarlijke machtigingen bevatten, met name machtigingen die kunnen worden gebruikt om beveiligingscontroles te omzeilen of kritieke infrastructuurcomponenten bloot te stellen aan onbevoegde wijzigingen of verwijdering. De benchmark benadrukt het belang van het principe van least privilege, waarbij gebruikers en rollen alleen de minimale rechten krijgen die absoluut noodzakelijk zijn voor het uitvoeren van hun specifieke taken. In de context van resource locks betekent dit dat alleen de hoogste beheerdersrollen, zoals Owner en User Access Administrator, de mogelijkheid moeten hebben om deze kritieke beveiligingsmaatregelen te beheren. Daarnaast is de BIO-norm 09.01 van directe toepassing op deze beveiligingsmaatregel, omdat deze norm specifiek betrekking heeft op toegangscontrole en authenticatie met een duidelijke focus op het principe van least privilege en het voorkomen van onbevoegde toegang tot kritieke systemen en gegevens. De BIO-norm, die is ontwikkeld door het Nationaal Cyber Security Centrum (NCSC) specifiek voor Nederlandse overheidsorganisaties, vereist dat organisaties uitgebreide maatregelen implementeren om ervoor te zorgen dat gebruikers alleen de minimale rechten krijgen die nodig zijn voor hun functie, en dat machtigingen die kunnen leiden tot escalatie van privileges of omzeiling van beveiligingsmaatregelen worden voorkomen. Deze norm benadrukt het belang van regelmatige audits en controles van toegangsrechten, waarbij organisaties moeten kunnen aantonen dat zij proactief toezicht houden op de beveiligingsconfiguratie van hun IT-omgevingen. De BIO-norm vereist ook dat organisaties een duidelijk proces hebben voor het beheren en controleren van toegangsrechten, inclusief procedures voor het goedkeuren van nieuwe rollen, het periodiek herzien van bestaande rollen en het verwijderen van ongebruikte of onnodige machtigingen. Naast deze specifieke normen is het beveiligen van resource locks ook relevant voor de Algemene Verordening Gegevensbescherming (AVG), omdat het verwijderen van resource locks kan leiden tot onbevoegde toegang tot of verwijdering van persoonsgegevens. Artikel 32 van de AVG vereist dat organisaties passende technische en organisatorische maatregelen treffen om persoonsgegevens te beveiligen, en het voorkomen van onbevoegde verwijdering van resource locks vormt een belangrijke technische maatregel in deze context. Door aangepaste rollen systematisch te controleren en te voorkomen dat deze resource lock-verwijdermachtigingen bevatten, voldoet u niet alleen aan deze compliance-vereisten, maar zorgt u er ook voor dat uw Azure-omgeving voldoet aan de beveiligingsstandaarden die worden verwacht van Nederlandse overheidsorganisaties. Voor audit- en compliance-doeleinden is het essentieel dat u alle controles en wijzigingen documenteert, inclusief de resultaten van regelmatige scans, de geïdentificeerde risico's, de uitgevoerde remediatie-acties en de verificatie dat de beveiligingsmaatregelen effectief zijn geïmplementeerd. Deze documentatie moet worden bewaard voor de vereiste bewaartermijn, die voor Nederlandse overheidsorganisaties doorgaans minimaal zeven jaar bedraagt, en moet beschikbaar zijn voor interne en externe audits. Het is aanbevolen om deze compliance-activiteiten te integreren in uw algemene governance, risk en compliance (GRC) processen, zodat u een holistische benadering hebt van beveiligingsmanagement en compliance-verificatie. Overweeg het implementeren van geautomatiseerde compliance-rapportage die regelmatig de status van uw aangepaste rollen controleert en rapporteert, zodat u altijd up-to-date bent over de compliance-status van uw omgeving en snel kunt reageren op eventuele afwijkingen of risico's.

Remediatie

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

Wanneer tijdens een controle wordt vastgesteld dat een aangepaste rol de Microsoft.Authorization/locks/delete-machtiging bevat, moet onmiddellijk actie worden ondernomen om dit beveiligingsrisico te verhelpen. Dit beveiligingsrisico vormt een directe bedreiging voor de integriteit van uw Azure-omgeving en kan leiden tot onbevoegde verwijdering van resource locks die zijn ingesteld om kritieke infrastructuurcomponenten te beschermen. Het is daarom essentieel om het remediatieproces snel en efficiënt uit te voeren, waarbij u ervoor zorgt dat alle stappen correct worden gevolgd en gedocumenteerd. Het remediatieproces begint met het identificeren van alle gebruikers, service principals of managed identities die momenteel deze aangepaste rol hebben toegewezen gekregen. Deze identificatie is cruciaal omdat het verwijderen van de machtiging directe gevolgen kan hebben voor deze entiteiten en mogelijk hun werkzaamheden kan verstoren. Het is daarom essentieel om eerst een grondige impactanalyse uit te voeren om te begrijpen welke functionaliteit mogelijk wordt beïnvloed door het verwijderen van deze machtigingen. Deze analyse moet niet alleen de directe gebruikers van de rol omvatten, maar ook alle downstream-processen en geautomatiseerde workflows die mogelijk afhankelijk zijn van deze machtigingen. Tijdens deze analyse is het belangrijk om te identificeren of er alternatieve oplossingen beschikbaar zijn die dezelfde functionaliteit kunnen bieden zonder het beveiligingsrisico te introduceren. Vervolgens dient u de roldefinitie te ophalen met Get-AzRoleDefinition en de Actions- of DataActions-lijst grondig te analyseren om alle machtigingen te identificeren die betrekking hebben op resource locks. Deze analyse moet niet alleen de specifieke Microsoft.Authorization/locks/delete-actie omvatten, maar ook wildcard-machtigingen die mogelijk ook de mogelijkheid bieden om locks te beheren, zoals Microsoft.Authorization/locks/* of bredere wildcard-machtigingen zoals Microsoft.Authorization/*. Het is belangrijk om alle varianten van lock-machtigingen te identificeren, omdat deze allemaal een beveiligingsrisico vormen en moeten worden verwijderd. Deze machtigingen moeten vervolgens worden verwijderd uit de roldefinitie, waarbij u ervoor moet zorgen dat u geen andere legitieme machtigingen verwijdert die nodig zijn voor de functionaliteit van de rol. Dit proces vereist zorgvuldige aandacht en moet idealiter worden uitgevoerd door ervaren beveiligingsprofessionals die volledig begrijpen welke machtigingen legitiem zijn en welke een beveiligingsrisico vormen. Het is aanbevolen om eerst een back-up te maken van de oorspronkelijke roldefinitie, zodat u indien nodig kunt terugkeren naar de vorige staat. Deze back-up vormt een essentieel onderdeel van uw rollback-strategie en moet worden bewaard voor de vereiste bewaartermijn. Na het aanpassen van de roldefinitie moet u deze bijwerken met Set-AzRoleDefinition, waarbij u ervoor moet zorgen dat u de volledige roldefinitie inclusief alle andere machtigingen behoudt. Het is essentieel om na de remediatie te verifiëren dat de wijzigingen correct zijn doorgevoerd en dat de aangepaste rol inderdaad geen resource lock-verwijdermachtigingen meer bevat. Deze verificatie is cruciaal om ervoor te zorgen dat het beveiligingsrisico daadwerkelijk is verholpen en dat er geen resterende machtigingen zijn die nog steeds een risico vormen. Dit kunt u doen door opnieuw Get-AzRoleDefinition uit te voeren en de roldefinitie grondig te analyseren op de aanwezigheid van lock-machtigingen. Als er gebruikers zijn die legitiem resource locks moeten kunnen beheren, dient u hen de ingebouwde rol Owner of User Access Administrator toe te wijzen in plaats van een aangepaste rol met uitgebreide machtigingen. Deze aanpak zorgt ervoor dat alleen bevoegde beheerders resource locks kunnen beheren, terwijl alle andere gebruikers en rollen deze kritieke beveiligingsmaatregel niet kunnen omzeilen. Het is belangrijk om deze roltoewijzingen te documenteren en regelmatig te controleren om ervoor te zorgen dat alleen de juiste personen deze kritieke machtigingen hebben. Documenteer alle uitgevoerde remediatie-acties voor audit- en compliance-doeleinden, inclusief de datum en tijd van de wijziging, de persoon die de wijziging heeft doorgevoerd, en de reden voor de wijziging. Deze documentatie vormt een essentieel onderdeel van uw audit trail en is vereist voor het voldoen aan verschillende compliance-frameworks. Zorg ervoor dat u ook documenteert welke entiteiten zijn beïnvloed door de wijziging en welke alternatieve oplossingen zijn geïmplementeerd voor gebruikers die legitiem resource locks moeten kunnen beheren. Deze documentatie helpt bij het begrijpen van de impact van de remediatie en bij het plannen van toekomstige beveiligingsverbeteringen.

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 Custom Role Resource Locks .DESCRIPTION CIS Azure Foundations Benchmark - Control 1.17 Controleert dat custom roles geen resource lock permissions hebben. .NOTES Filename: custom-role-resource-locks.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.17 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Custom Role Resource Locks" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $customRoles = Get-AzRoleDefinition | Where-Object { $_.IsCustom -eq $true } $result = @{ TotalCustomRoles = $customRoles.Count; WithLockPermissions = 0 } foreach ($role in $customRoles) { $lockActions = $role.Actions | Where-Object { $_ -like "*Microsoft.Authorization/locks*" } if ($lockActions) { $result.WithLockPermissions++ } } 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 "Custom RBAC Roles: $($r.TotalCustomRoles)" -ForegroundColor White Write-Host "With Lock Permissions: $($r.WithLockPermissions)" -ForegroundColor $(if ($r.WithLockPermissions -eq 0) { 'Green' } else { 'Yellow' }) if ($r.WithLockPermissions -gt 0) { Write-Host "`n⚠️ Review lock permissions in custom roles" -ForegroundColor Yellow } } else { $r = Test-Compliance Write-Host "`nCustom Roles with Lock Permissions: $($r.WithLockPermissions)/$($r.TotalCustomRoles)" } } 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 "Custom RBAC Roles: $($r.TotalCustomRoles)" -ForegroundColor White Write-Host "With Lock Permissions: $($r.WithLockPermissions)" -ForegroundColor $(if ($r.WithLockPermissions -eq 0) { 'Green' } else { 'Yellow' }) if ($r.WithLockPermissions -gt 0) { Write-Host "`n⚠️ Review lock permissions in custom roles" -ForegroundColor Yellow } } else { $r = Test-Compliance Write-Host "`nCustom Roles with Lock Permissions: $($r.WithLockPermissions)/$($r.TotalCustomRoles)" } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
Medium: Aangepaste RBAC-rollen met Microsoft.Authorization/locks/delete-machtiging kunnen resource locks verwijderen, waardoor de lock-bescherming wordt omzeild. Dit vormt een compliance-risico volgens CIS 1.24. Het risiconiveau is medium en betreft een scenario van escalatie van privileges waarbij gebruikers met aangepaste rollen beveiligingsmaatregelen kunnen omzeilen die bedoeld zijn om kritieke resources te beschermen.

Management Samenvatting

Beveiliging van resource locks via aangepaste rollen: Verifieer dat aangepaste RBAC-rollen geen Microsoft.Authorization/locks/delete-machtiging bevatten om lock-omzeiling te voorkomen. Voer een audit uit van alle aangepaste rollen en verwijder lock-verwijdermachtigingen waar nodig. Geen extra kosten. Verplicht volgens CIS 1.24. Implementatietijd: 1-2 uur voor audit. Voorkomt omzeiling van resource lock-bescherming.