L2 BIO 10.01 ISO A.8.24 CIS 5.2.2

Sleutelverval RBAC-kluizen

📅 2025-10-29
•
⏱️ 4 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Deze beveiligingsregel waarborgt de correcte configuratie van sleutelvervaldatums en beschermt organisaties tegen beveiligingsrisico's die ontstaan wanneer cryptografische sleutels onbeperkt geldig blijven.

Aanbeveling
IMPLEMENTEER SLEUTELVERVALDATUMS
Risico zonder
Medium
Risk Score
6/10
Implementatie
3u (tech: 2u)
Van toepassing op:
✓ Azure Key Vault

Deze instelling is essentieel voor het handhaven van een veilige omgeving en voorkomt bekende aanvalsvectoren door het afdwingen van beste beveiligingspraktijken. Sleutels zonder vervaldatum blijven onbeperkt geldig, wat betekent dat een gecompromitteerde sleutel jarenlang toegang kan verschaffen tot gevoelige gegevens en systemen. Door vervaldatums in te stellen, dwingt u organisaties tot regelmatige rotatie van sleutels, waardoor het risico op langdurige blootstelling na een compromittering aanzienlijk wordt verminderd.

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

Implementatie

Het instellen van vervaldatums voor cryptografische sleutels in Azure Key Vaults die gebruikmaken van het Role-Based Access Control (RBAC) model. Dit zorgt ervoor dat alle sleutels automatisch verlopen na een vooraf gedefinieerde periode, waardoor regelmatige sleutelrotatie wordt afgedwongen en de beveiligingspostuur van de organisatie wordt verbeterd.

Vereisten

Voor het succesvol implementeren van sleutelvervaldatums in Azure Key Vault is het fundamenteel essentieel dat de Key Vault is geconfigureerd met het Role-Based Access Control (RBAC) autorisatiemodel, dat ook wel bekend staat als op rollen gebaseerd toegangsbeheer. Dit geavanceerde autorisatiemodel biedt fijnmazige en gedetailleerde toegangscontrole op basis van Azure-rollen en wordt beschouwd als de aanbevolen en moderne aanpak voor alle nieuwe Key Vault-implementaties binnen Azure-omgevingen. Organisaties die nog gebruikmaken van het verouderde toegangsbeleidsmodel, dat door Microsoft wordt beschouwd als verouderde technologie, moeten eerst een volledige migratie uitvoeren naar het RBAC-model voordat zij vervaldatums kunnen configureren via de standaard Azure-interfaces en beheertools. De migratie naar RBAC is niet alleen een technische upgrade, maar vormt een strategische beslissing die organisaties moet nemen omdat dit model niet alleen betere en geavanceerdere beveiligingsmogelijkheden biedt, maar ook uitgebreidere levenscyclusbeheerfuncties voor cryptografische sleutels, certificaten en geheimen die essentieel zijn voor moderne cloudbeveiligingspraktijken. Het RBAC-model maakt gebruik van Azure Active Directory voor geïntegreerd identiteitsbeheer, wat zorgt voor consistente en gecentraliseerde toegangscontrole door de gehele Azure-omgeving en betere integratie met andere Azure-services zoals Azure Policy, Azure Monitor en Azure Security Center. Deze integratie maakt het mogelijk om sleutelbeheer te automatiseren en te monitoren als onderdeel van een bredere beveiligingsstrategie. Daarnaast vereist deze configuratie dat beheerders en sleutelbeheerders over de juiste Azure-rollen beschikken met voldoende machtigingen, zoals de Key Vault Administrator rol of een aangepaste rol met specifieke en gedefinieerde machtigingen voor het beheren van sleutelvervaldatums en sleutellevenscyclus. De Key Vault Administrator rol biedt volledige en onbeperkte controle over alle aspecten van de Key Vault, inclusief het instellen, wijzigen en verwijderen van vervaldatums, het beheren van sleutels, en het configureren van toegangsbeleid. Voor organisaties die meer granulaire en gedetailleerde controle willen over wie welke acties kan uitvoeren, kunnen aangepaste rollen worden gecreëerd die specifieke acties toestaan, zoals alleen het lezen van sleutelvervaldatums voor auditdoeleinden, of alleen het instellen van vervaldatums voor nieuwe sleutels zonder de mogelijkheid om bestaande vervaldatums te wijzigen. Deze granulaire controle is vooral belangrijk voor organisaties die moeten voldoen aan strikte compliance-vereisten zoals scheiding van taken en het principe van minimale bevoegdheden. Organisaties moeten ook uitgebreid rekening houden met de mogelijke impact op bestaande applicaties, services en bedrijfsprocessen die afhankelijk zijn van de betreffende sleutels, aangezien het instellen van vervaldatums uitgebreide planning vereist voor de volledige rotatieprocedure en mogelijke aanpassingen aan applicatieconfiguraties. Het is van cruciaal belang om een volledige en gedetailleerde inventarisatie te maken van alle applicaties, services, systemen en bedrijfsprocessen die gebruikmaken van cryptografische sleutels uit de Key Vault voordat vervaldatums worden ingesteld, om te voorkomen dat kritieke bedrijfsprocessen worden verstoord. Deze inventarisatie moet niet alleen de technische afhankelijkheden en configuraties omvatten, maar ook de bedrijfsprocessen die mogelijk worden beïnvloed door sleutelrotatie, de stakeholders die betrokken moeten worden bij het rotatieproces, en de risico's die gepaard gaan met tijdelijke onbeschikbaarheid van sleutels tijdens het rotatieproces. Organisaties moeten ook uitgebreid overwegen hoe zij omgaan met sleutels die worden gebruikt voor langlopende processen, verouderde systemen, of systemen die technisch moeilijk te updaten zijn vanwege verouderde technologie of beperkte ontwikkelcapaciteit. In dergelijke gevallen kan het nodig zijn om een gefaseerde en geleidelijke aanpak te volgen waarbij eerst sleutels met een langere vervalperiode worden ingesteld, bijvoorbeeld 365 dagen, gevolgd door een geleidelijke verkorting van deze periode naarmate de organisatie meer ervaring opdoet met sleutelrotatieprocessen en de technische en organisatorische capaciteit toeneemt. Daarnaast is het belangrijk om te begrijpen dat het instellen van vervaldatums alleen effectief en veilig is wanneer dit wordt gecombineerd met robuuste sleutelrotatieprocedures, uitgebreide monitoring, en gedocumenteerde incidentafhandelingsprocedures. Zonder deze ondersteunende processen en procedures kunnen vervaldatums leiden tot onverwachte en mogelijk kritieke serviceonderbrekingen wanneer sleutels verlopen voordat zij zijn vervangen, wat kan resulteren in verlies van beschikbaarheid van kritieke systemen en negatieve impact op de bedrijfscontinuïteit.

Monitoring

Gebruik PowerShell-script key-expiration-rbac-vaults.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van sleutelvervaldatums vormt de hoeksteen van een robuust sleutelbeheerprogramma en is essentieel voor het handhaven van een sterke beveiligingspostuur binnen Azure Key Vault omgevingen. Het monitoringproces omvat het systematisch en regelmatig controleren van alle cryptografische sleutels binnen Azure Key Vaults om te identificeren welke sleutels geen vervaldatum hebben ingesteld. Dit proces is van fundamenteel belang omdat sleutels zonder vervaldatum onbeperkt geldig blijven en daardoor een aanzienlijk beveiligingsrisico vormen voor de organisatie. Een gecompromitteerde sleutel zonder vervaldatum kan jarenlang worden misbruikt door aanvallers zonder dat de organisatie zich hiervan bewust is, wat de effectiviteit van incidentafhandelingsprocedures aanzienlijk vermindert en de tijd om een beveiligingsincident te detecteren en te verhelpen verlengt. Het monitoring script doorloopt systematisch alle RBAC-geconfigureerde Key Vaults binnen de Azure-tenant en genereert een uitgebreid en gedetailleerd rapport van alle sleutels die aandacht vereisen van beveiligingsteams. Dit rapport moet niet alleen de sleutels zonder vervaldatum identificeren, maar ook uitgebreide contextuele informatie bevatten zoals de leeftijd van de sleutel, de laatste gebruikdatum, de applicaties of services die afhankelijk zijn van de betreffende sleutel, en de eigenaar of verantwoordelijke voor de sleutel. Deze aanvullende informatie is cruciaal voor het nemen van weloverwogen beslissingen over welke sleutels prioriteit moeten krijgen bij het instellen van vervaldatums en welke stakeholders betrokken moeten worden bij het rotatieproces. Organisaties moeten dit monitoringproces wekelijks of maandelijks uitvoeren, afhankelijk van hun specifieke beveiligingsvereisten en compliance-verplichtingen. Voor organisaties met hoge beveiligingsvereisten, zoals financiële instellingen of overheidsorganisaties die werken met gevoelige persoonsgegevens, wordt wekelijkse monitoring sterk aanbevolen om snel te kunnen reageren op wijzigingen in de sleutelconfiguratie en om te voorkomen dat nieuwe sleutels zonder vervaldatum langere tijd onopgemerkt blijven. Het identificeren van sleutels zonder vervaldatum stelt beveiligingsteams in staat om proactief actie te ondernemen voordat deze sleutels een beveiligingsprobleem worden en voordat zij worden gecompromitteerd door aanvallers. Daarnaast moet de monitoring ook uitgebreide aandacht besteden aan sleutels die binnenkort verlopen, zodat organisaties tijdig kunnen plannen voor sleutelrotatie zonder onverwachte serviceonderbrekingen die de bedrijfscontinuïteit kunnen beïnvloeden. Een bewezen beste praktijk is om geautomatiseerde waarschuwingen te configureren voor sleutels die binnen 30, 60 en 90 dagen verlopen, zodat er voldoende tijd is voor de volledige rotatieprocedure inclusief testen en validatie. Het is sterk aanbevolen om deze monitoring volledig te automatiseren en te integreren met bestaande beveiligingsinformatie- en gebeurtenisbeheersystemen, ook wel bekend als SIEM-systemen, voor centrale rapportage en geavanceerde waarschuwingen. Deze integratie maakt het mogelijk om sleutelvervaldatums te correleren met andere beveiligingsgebeurtenissen binnen de organisatie en om trends en patronen te identificeren in sleutelbeheer die kunnen wijzen op bredere beveiligingsproblemen of organisatorische uitdagingen. Automatische monitoring kan ook worden geconfigureerd om directe notificaties te versturen naar verantwoordelijke beheerders en sleutelbeheerders wanneer nieuwe sleutels worden aangemaakt zonder vervaldatum, waardoor het probleem bij de bron wordt aangepakt en wordt voorkomen dat nieuwe sleutels zonder vervaldatum worden geïntroduceerd in de omgeving. Organisaties moeten ook regelmatig uitgebreide trendanalyses uitvoeren om te identificeren of bepaalde teams, afdelingen of applicaties consistent sleutels aanmaken zonder vervaldatums, wat kan wijzen op een gebrek aan bewustzijn, onvoldoende training, of technische beperkingen in de ontwikkelprocessen. Deze analyses kunnen worden gebruikt om gerichte trainingen en bewustwordingsprogramma's te ontwikkelen, om technische controles te implementeren die voorkomen dat nieuwe sleutels zonder vervaldatum worden aangemaakt, en om organisatiebrede beste praktijken en richtlijnen te verbeteren. Daarnaast is het van cruciaal belang om alle monitoringresultaten uitgebreid te documenteren en te archiveren voor auditdoeleinden en compliance-verificatie, zodat organisaties kunnen aantonen dat zij regelmatig en systematisch controleren op naleving van het sleutelvervalbeleid en dat zij proactief maatregelen nemen om beveiligingsrisico's te mitigeren.

Compliance en Controle

Het instellen van vervaldatums voor cryptografische sleutels vormt een fundamentele en onmisbare vereiste binnen meerdere belangrijke beveiligingsstandaarden en compliance-frameworks die wereldwijd worden erkend en gebruikt door organisaties in verschillende sectoren. Deze vereiste is niet alleen een technische beste praktijk die wordt aanbevolen door beveiligingsexperts, maar vormt een essentieel en integraal onderdeel van een holistische en uitgebreide beveiligingsstrategie die effectieve bescherming biedt tegen langdurige blootstelling na een beveiligingsincident en die de impact van gecompromitteerde sleutels aanzienlijk vermindert. De Center for Internet Security (CIS) Azure Foundations Benchmark controle 5.2.2 specificeert expliciet en zonder uitzondering dat alle cryptografische sleutels binnen Azure Key Vault omgevingen een vervaldatum moeten hebben ingesteld om te voldoen aan de beveiligingsvereisten. Deze controle is geclassificeerd als Level 2, wat betekent dat deze wordt aanbevolen voor omgevingen met verhoogde beveiligingsvereisten en voor organisaties die streven naar een hoger niveau van beveiligingsvolwassenheid. Level 2 controles zijn specifiek bedoeld voor organisaties die een hogere mate van beveiliging nodig hebben vanwege de gevoeligheid van hun gegevens of de kritieke aard van hun systemen, en die bereid zijn om aanvullende en geavanceerde maatregelen te implementeren bovenop de basisbeveiliging die wordt vereist door Level 1 controles. Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van cruciaal en fundamenteel belang en vormt de wettelijke en verplichte basis voor informatiebeveiliging binnen de gehele publieke sector in Nederland. BIO controle 10.01 richt zich specifiek en uitgebreid op het beheer van de volledige levenscyclus van cryptografische sleutels, inclusief het instellen van vervaldatums, het uitvoeren van regelmatige en geplande rotatie, en het waarborgen van de beschikbaarheid en integriteit van sleutels gedurende hun gehele levenscyclus. Deze controle is essentieel en verplicht voor het waarborgen van de vertrouwelijkheid, integriteit en beschikbaarheid van gevoelige overheidsgegevens en is wettelijk verplicht voor alle Nederlandse overheidsorganisaties die werken met persoonsgegevens, gevoelige overheidsinformatie, of andere geclassificeerde gegevens. De BIO vereist expliciet dat organisaties kunnen aantonen en documenteren dat zij passende en effectieve maatregelen hebben getroffen voor het beheer van cryptografische sleutels, wat betekent dat het instellen van vervaldatums alleen niet voldoende is om te voldoen aan de vereisten, maar dat dit moet worden ondersteund door uitgebreide gedocumenteerde procedures, regelmatige controles, en traceerbare logs van alle sleutelbeheeractiviteiten. Daarnaast vereist ISO 27001:2022 controle A.8.24, die specifiek gericht is op cryptografie en cryptografische controles, dat organisaties passende en effectieve maatregelen treffen voor het beheer van cryptografische sleutels gedurende hun volledige levenscyclus, van generatie tot vernietiging. Dit omvat niet alleen het instellen van vervaldatums op alle productiesleutels, maar ook het documenteren van uitgebreide sleutelrotatieprocedures, het waarborgen van de beschikbaarheid van back-upsleutels voor noodhersteldoeleinden, en het implementeren van controles om te voorkomen dat verlopen sleutels worden gebruikt. ISO 27001 is een internationaal erkende en breed geaccepteerde standaard voor informatiebeveiligingsmanagement en wordt door veel organisaties wereldwijd gebruikt als basis voor hun beveiligingsprogramma en als framework voor het implementeren van een Information Security Management System (ISMS). Voor organisaties die ISO 27001 certificering nastreven of behouden, is het instellen van vervaldatums op cryptografische sleutels een verplichte controle die regelmatig moet worden geverifieerd tijdens interne audits, externe certificeringsaudits, en surveillance audits om te waarborgen dat de certificering geldig blijft. Voor auditdoeleinden en compliance-verificatie moeten organisaties uitgebreid kunnen aantonen dat alle productiesleutels een vervaldatum hebben ingesteld, dat er gedocumenteerde en geteste procedures bestaan voor het beheren van sleutelverval en rotatie, en dat deze procedures daadwerkelijk worden nageleefd in de praktijk. Dit vereist niet alleen gedocumenteerde processen en procedures, maar ook regelmatige en systematische controles, volledig traceerbare logs van alle sleutelbeheeractiviteiten, en bewijs van training en bewustwording onder betrokken personeel. Auditoren en compliance-verificatoren zullen niet alleen controleren of vervaldatums technisch zijn ingesteld op alle sleutels, maar ook of deze daadwerkelijk worden nageleefd in de praktijk, of er robuuste procedures bestaan voor het omgaan met verlopen sleutels, en of de organisatie in staat is om snel te reageren wanneer sleutels verlopen. Organisaties moeten daarom niet alleen technische controles en automatisering implementeren, maar ook uitgebreide organisatorische maatregelen treffen zoals training en bewustwordingsprogramma's voor personeel, duidelijke verantwoordelijkheden en rollen toewijzen aan specifieke personen of teams, en regelmatige reviews en verbeteringen van sleutelbeheerprocessen. Daarnaast moeten organisaties uitgebreid rekening houden met sector-specifieke vereisten en richtlijnen, zoals de NEN 7510 voor zorgorganisaties die werken met medische gegevens, of de DNB-richtlijnen voor financiële instellingen die onder toezicht staan van De Nederlandsche Bank, die aanvullende en vaak strengere eisen kunnen stellen aan het beheer van cryptografische sleutels vanwege de gevoeligheid van de gegevens en de kritieke aard van de dienstverlening.

Remediatie

Gebruik PowerShell-script key-expiration-rbac-vaults.ps1 (functie Invoke-Remediation) – Herstellen.

Het remediatieproces voor het instellen van vervaldatums op cryptografische sleutels vereist uitgebreide en zorgvuldige planning, gedetailleerde coördinatie tussen verschillende teams en afdelingen, en een systematische aanpak om onverwachte serviceonderbrekingen te voorkomen en om ervoor te zorgen dat de volledige implementatie soepel en zonder problemen verloopt zonder negatieve impact op kritieke bedrijfsprocessen en de beschikbaarheid van systemen. Dit proces moet worden benaderd als een strategisch en multidisciplinair project dat niet alleen technische aspecten en configuraties omvat, maar ook uitgebreide organisatorische overwegingen, procesmatige aanpassingen, en communicatie met alle betrokken stakeholders. Voordat vervaldatums daadwerkelijk worden ingesteld op productiesleutels, moeten organisaties eerst een volledige en gedetailleerde inventarisatie uitvoeren van alle cryptografische sleutels die momenteel geen vervaldatum hebben ingesteld, inclusief sleutels in alle omgevingen zoals productie, test, en ontwikkeling. Deze inventarisatie moet uitgebreid en compleet zijn en niet alleen de technische details van de sleutels omvatten zoals het type, de grootte, en de algoritme, maar ook de volledige bedrijfscontext waarin zij worden gebruikt, de applicaties en services die afhankelijk zijn van elke sleutel, en de kritiekheid van de bedrijfsprocessen die gebruikmaken van de betreffende sleutels. Het is van fundamenteel belang om volledig te begrijpen welke bedrijfsprocessen en kritieke systemen afhankelijk zijn van elke sleutel, wat de mogelijke impact zou zijn van een tijdelijke onbeschikbaarheid tijdens het rotatieproces, welke stakeholders en applicatie-eigenaren betrokken moeten worden bij de rotatieprocedure, en wat de risico's zijn van het niet uitvoeren van de rotatie op tijd. Voor elke sleutel moet zorgvuldig worden bepaald wat de meest geschikte vervalperiode is op basis van de gevoeligheid van de gegevens, de beveiligingsvereisten van de organisatie, en de technische complexiteit van het rotatieproces. Typisch ligt deze periode tussen 90 en 365 dagen, waarbij sleutels die worden gebruikt voor het versleutelen van zeer gevoelige gegevens, zoals medische dossiers, financiële transacties, of persoonsgegevens, kortere vervalperioden moeten hebben van bijvoorbeeld 90 tot 180 dagen om het risico te beperken. Sleutels voor minder kritieke toepassingen of systemen met beperkte gevoeligheid kunnen langere perioden hebben van bijvoorbeeld 180 tot 365 dagen, mits dit wordt ondersteund door robuuste monitoring en waarschuwingen. Het is cruciaal en essentieel om volledig te identificeren welke applicaties, services, systemen en bedrijfsprocessen afhankelijk zijn van elke sleutel, zodat deze tijdig kunnen worden geïnformeerd over de geplande rotatie en uitgebreid kunnen voorbereiden op de wijziging door het testen van nieuwe configuraties en het ontwikkelen van terugdraaiscenario's. Deze communicatie moet tijdig en proactief plaatsvinden, bij voorkeur minimaal 60 tot 90 dagen voordat de vervaldatum verstrijkt, zodat applicatie-eigenaren, ontwikkelaars en beheerders voldoende tijd hebben om hun systemen voor te bereiden, testen uit te voeren, en eventuele problemen op te lossen voordat de daadwerkelijke rotatie plaatsvindt. Het remediatiescript stelt automatisch en systematisch vervaldatums in op alle geïdentificeerde sleutels die momenteel geen vervaldatum hebben, maar organisaties moeten ervoor zorgen dat zij beschikken over volledig gedocumenteerde en geteste robuuste sleutelrotatieprocedures voordat de vervaldatums daadwerkelijk verstrijken en de rotatie moet worden uitgevoerd. Deze procedures moeten zeer gedetailleerd zijn en alle stappen omvatten die nodig zijn voor een succesvolle en veilige rotatie, inclusief uitgebreide terugdraaiscenario's voor het geval er onverwachte problemen optreden tijdens de migratie, communicatieplannen voor het informeren van betrokken stakeholders, en testprocedures voor het valideren van de nieuwe configuratie. Dit omvat het genereren van nieuwe cryptografische sleutels met de juiste eigenschappen, het bijwerken van alle applicatieconfiguraties en verbindingsreeksen, het uitgebreid testen van de nieuwe configuratie in een geïsoleerde testomgeving die de productieomgeving nauwkeurig simuleert, en het uitvoeren van een geplande en gecontroleerde migratie tijdens een vooraf gedefinieerd onderhoudsvenster met voldoende tijd voor terugdraaien indien nodig. Het testen in een testomgeving is van cruciaal en fundamenteel belang omdat dit het mogelijk maakt om potentiële problemen, configuratiefouten, en compatibiliteitsproblemen te identificeren en op te lossen voordat de wijziging wordt doorgevoerd in de productieomgeving waar fouten kunnen leiden tot serviceonderbrekingen en negatieve impact op de bedrijfscontinuïteit. Organisaties moeten ook uitgebreid overwegen om geautomatiseerde waarschuwingen en notificaties in te stellen die hen proactief waarschuwen wanneer sleutels binnen een bepaalde periode verlopen, bijvoorbeeld 30, 60 en 90 dagen voor vervaldatum, zodat er voldoende tijd is voor de volledige rotatieprocedure inclusief planning, testen, en implementatie. Deze waarschuwingen moeten worden geconfigureerd om meerdere keren en op verschillende momenten te worden verzonden, bijvoorbeeld bij 90, 60, 30, 14 en 7 dagen voor vervaldatum, om ervoor te zorgen dat verantwoordelijke personen, teams en managers voldoende tijd hebben om actie te ondernemen en om te voorkomen dat belangrijke deadlines worden gemist. Na het instellen van vervaldatums is het belangrijk en essentieel om regelmatig en systematisch te controleren of alle nieuwe sleutels die worden aangemaakt automatisch een vervaldatum krijgen toegewezen, zodat het probleem niet opnieuw ontstaat en de organisatie niet terugvalt in de oude situatie. Dit kan worden bereikt door het implementeren van geautomatiseerde controles en scripts die nieuwe sleutels identificeren zonder vervaldatum, door het trainen en bewust maken van ontwikkelaars en beheerders om altijd vervaldatums in te stellen bij het aanmaken van nieuwe sleutels, en door het opnemen van deze vereiste in ontwikkelrichtlijnen en beste praktijken. Organisaties moeten ook uitgebreid overwegen om technische controles en preventieve maatregelen te implementeren die actief voorkomen dat nieuwe sleutels worden aangemaakt zonder vervaldatum, bijvoorbeeld door gebruik te maken van Azure Policy definities die automatisch vervaldatums afdwingen, door aangepaste scripts en automatisering te ontwikkelen die automatisch vervaldatums toewijzen aan nieuwe sleutels bij het aanmaken, of door technische validaties in te bouwen in de ontwikkel- en deploymentprocessen die controleren of nieuwe sleutels voldoen aan de vereisten voordat zij worden geaccepteerd in de productieomgeving.

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 Key Expiration RBAC Vaults .DESCRIPTION CIS Azure Foundations Benchmark - Control 8.2 Controleert key expiration in RBAC Key Vaults. .NOTES Filename: key-expiration-rbac-vaults.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 8.2 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.KeyVault [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Key Expiration RBAC Vaults" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $vaults = Get-AzKeyVault -ErrorAction SilentlyContinue $result = @{ TotalKeys = 0; WithExpiration = 0 } foreach ($vault in $vaults) { $vaultDetail = Get-AzKeyVault -VaultName $vault.VaultName -ErrorAction SilentlyContinue if ($vaultDetail.EnableRbacAuthorization) { $keys = Get-AzKeyVaultKey -VaultName $vault.VaultName -ErrorAction SilentlyContinue foreach ($key in $keys) { $result.TotalKeys++ if ($key.Expires) { $result.WithExpiration++ } } } } 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 Keys (RBAC): $($r.TotalKeys)" -ForegroundColor White Write-Host "With Expiration: $($r.WithExpiration)" -ForegroundColor $(if ($r.WithExpiration -eq $r.TotalKeys) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nKey Expiration: $($r.WithExpiration)/$($r.TotalKeys) RBAC keys" } } 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 Keys (RBAC): $($r.TotalKeys)" -ForegroundColor White Write-Host "With Expiration: $($r.WithExpiration)" -ForegroundColor $(if ($r.WithExpiration -eq $r.TotalKeys) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nKey Expiration: $($r.WithExpiration)/$($r.TotalKeys) RBAC keys" } } 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: Sleutels zonder vervaldatum blijven onbeperkt geldig, wat betekent dat een gecompromitteerde sleutel jarenlang toegang kan verschaffen tot gevoelige gegevens en systemen. Dit creëert een aanzienlijk beveiligingsrisico omdat aanvallers die toegang krijgen tot een sleutel deze kunnen blijven gebruiken zolang de sleutel geldig is. Bovendien voldoet de organisatie niet aan compliance-vereisten zoals CIS 5.2.2, BIO 10.01 en ISO 27001:2022 A.8.24. Het risico wordt geclassificeerd als medium, voornamelijk vanwege de langdurige blootstelling die ontstaat wanneer sleutels geen natuurlijke vervaldatum hebben. Zonder vervaldatums ontbreekt de dwang tot regelmatige rotatie, wat betekent dat organisaties mogelijk jarenlang dezelfde sleutels gebruiken zonder deze te vernieuwen, zelfs na beveiligingsincidenten of personeelswijzigingen.

Management Samenvatting

Sleutelvervaldatums voor RBAC Key Vaults: Stel vervaldatums in op alle cryptografische sleutels met een periode van 90 tot 365 dagen, afhankelijk van de gevoeligheid en beveiligingsvereisten. Dit dwingt regelmatige sleutelrotatie af en vermindert het risico op langdurige blootstelling na een compromittering. Activatie vindt plaats via Azure Key Vault (RBAC model) door naar de Keys-sectie te navigeren en voor elke sleutel een vervaldatum in te stellen. Deze functie is zonder extra kosten beschikbaar en is verplicht volgens CIS 5.2.2. De implementatie vereist ongeveer 2 tot 3 uur werk, inclusief inventarisatie, planning en configuratie. Door vervaldatums in te stellen wordt het compromitteringsvenster aanzienlijk verkleind, omdat gecompromitteerde sleutels automatisch verlopen en moeten worden vervangen.