L2 BIO 09.04 ISO A.5.17 CIS 5.3.3

Secret Vervaldatum Voor Non-RBAC Kluizen

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

💼 Management Samenvatting

Deze beveiligingsmaatregel is essentieel voor het waarborgen van een veilige cloudomgeving en beschermt tegen ongeautoriseerde toegang en datalekken.

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

Zonder deze beveiligingsmaatregel kunnen er significante beveiligingsrisico's ontstaan die leiden tot gegevenscompromittering, nalevingsovertredingen en reputatieschade voor de organisatie.

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

Implementatie

Deze maatregel implementeert beveiligingsbest practices via Azure-beleid, ARM-templates of Microsoft Intune om cloudresources en endpoints te beschermen volgens actuele compliance frameworks.

Vereisten

Voor het implementeren van secret vervaldatum in Azure Key Vault met het toegangsbeleidsmodel (Access Policy model) zijn specifieke vereisten nodig om de beveiligingsmaatregel effectief te kunnen toepassen. De belangrijkste vereiste is dat de Key Vault gebruik maakt van het traditionele toegangsbeleidsmodel in plaats van het modernere op rollen gebaseerde toegangsbeheermodel (RBAC). Dit is van cruciaal belang omdat de implementatie en configuratie van secret vervaldatum verschillend zijn tussen deze twee toegangsmodellen. Organisaties moeten eerst bepalen welk toegangsmodel hun Key Vault gebruikt voordat ze secret vervaldatum kunnen configureren. Daarnaast is het essentieel dat de juiste bevoegdheden aanwezig zijn om wijzigingen aan te brengen in de Key Vault-configuratie. Beheerders moeten beschikken over voldoende rechten om toegangsbeleid te wijzigen en secrets te beheren. Dit omvat typisch de rol van Key Vault-beheerder of specifieke toegangsbeleidsrechten die het mogelijk maken om vervaldatums te configureren voor bestaande en nieuwe secrets. Zonder deze bevoegdheden kan de implementatie van secret vervaldatum niet worden uitgevoerd, wat kan leiden tot beveiligingsrisico's door het gebruik van verouderde of niet-verlopen credentials. Een derde belangrijke vereiste is de beschikbaarheid van een gestructureerd proces voor het beheer van secret levenscyclus. Dit betekent dat organisaties een duidelijk beleid moeten hebben voor hoe lang secrets geldig mogen zijn, wanneer ze moeten worden vernieuwd, en hoe de rotatieprocedure moet worden uitgevoerd. Dit vereist coördinatie tussen verschillende teams, waaronder security, operations en development, om ervoor te zorgen dat secret vervaldatum op een manier wordt geïmplementeerd die de operationele continuïteit niet verstoort terwijl de beveiliging wordt verbeterd. Een vierde vereiste betreft de technische infrastructuur en automatisering. Organisaties moeten beschikken over de juiste tools en scripts om secret vervaldatum te monitoren en te beheren. Dit omvat PowerShell-scripts die kunnen scannen op secrets zonder vervaldatum, waarschuwingssystemen die meldingen genereren wanneer secrets naderen aan hun verloopdatum, en geautomatiseerde rotatieprocessen die ervoor zorgen dat nieuwe secrets tijdig worden gegenereerd en geïmplementeerd. Zonder deze technische ondersteuning wordt het beheer van secret vervaldatum een handmatig en foutgevoelig proces, wat het risico op vergeten secrets of gemiste rotaties aanzienlijk verhoogt. Ten slotte is het belangrijk dat organisaties een duidelijk begrip hebben van de impact van secret vervaldatum op hun applicaties en systemen. Applicaties die secrets gebruiken moeten worden voorbereid op het feit dat secrets zullen verlopen en moeten beschikken over mechanismen om automatisch nieuwe secrets op te halen wanneer oude secrets verlopen. Dit vereist vaak wijzigingen in applicatiecode of configuratie, wat betekent dat development-teams betrokken moeten worden bij het implementatieproces. Door deze vereisten zorgvuldig te adresseren, kunnen organisaties secret vervaldatum succesvol implementeren als onderdeel van hun algehele beveiligingsstrategie.

Monitoring

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

Effectieve monitoring van secret vervaldatum in Azure Key Vault is essentieel om ervoor te zorgen dat alle geheimen een geldige vervaldatum hebben en dat organisaties proactief kunnen reageren op naderende verlopingsdatums. Het monitoringproces moet regelmatig worden uitgevoerd om een overzicht te krijgen van alle secrets die momenteel geen vervaldatum hebben geconfigureerd, wat een potentieel beveiligingsrisico vormt. Secrets zonder vervaldatum blijven onbeperkt geldig, wat betekent dat ze kunnen worden gebruikt totdat ze handmatig worden verwijderd of geroteerd, zelfs als ze al lang niet meer actueel of veilig zijn. Het identificeren van secrets zonder vervaldatum is de eerste stap in het monitoringproces. Dit kan worden bereikt door alle secrets in een Key Vault op te halen en te controleren of ze een vervaldatum hebben ingesteld. Secrets zonder vervaldatum vereisen onmiddellijke aandacht, omdat ze een langdurig beveiligingsrisico vormen. Als een secret wordt gecompromitteerd maar geen vervaldatum heeft, kan een aanvaller dit secret onbeperkt gebruiken zonder dat het automatisch verloopt. Dit verlengt de compromitteringsperiode aanzienlijk en kan leiden tot ernstige gegevenslekken of ongeautoriseerde toegang tot systemen en applicaties. Naast het identificeren van secrets zonder vervaldatum is het ook belangrijk om te monitoren op secrets die binnenkort verlopen. Dit stelt organisaties in staat om proactief rotatieprocedures in gang te zetten voordat secrets daadwerkelijk verlopen en applicaties worden verstoord. Een goed monitoringproces genereert regelmatig rapporten die secrets categoriseren op basis van hun verloopstatus. Secrets zonder vervaldatum vormen de hoogste prioriteit omdat ze onbeperkt geldig blijven. Secrets die binnen 30 dagen verlopen vereisen planning voor rotatie, terwijl secrets die binnen 7 dagen verlopen dringende actie vereisen om applicatiestoringen te voorkomen. Secrets die al zijn verlopen maar nog niet zijn geroteerd vormen een kritiek beveiligingsrisico en moeten onmiddellijk worden aangepakt. Deze categorisering helpt prioriteiten te stellen en zorgt ervoor dat kritieke secrets tijdig worden vernieuwd. Het implementeren van geautomatiseerde monitoring met PowerShell-scripts maakt het mogelijk om deze controles regelmatig en consistent uit te voeren zonder handmatige interventie. Deze scripts kunnen worden geïntegreerd in bestaande monitoring- en waarschuwingssystemen om security teams te informeren over secrets die aandacht vereisen. Door monitoring te automatiseren, verminderen organisaties het risico op menselijke fouten en zorgen ze ervoor dat geen secrets over het hoofd worden gezien, wat essentieel is voor het handhaven van een sterke beveiligingspostuur in de cloudomgeving. Een geavanceerd monitoringproces omvat ook het bijhouden van historische data over secret rotaties en het analyseren van patronen in secret gebruik. Dit stelt organisaties in staat om te identificeren welke secrets vaak worden gebruikt en welke mogelijk kunnen worden geconsolideerd of verwijderd. Daarnaast kan monitoring helpen bij het identificeren van afwijkingen in secret gebruik, zoals ongebruikelijke toegangspatronen die kunnen wijzen op een potentiële compromittering. Door deze diepgaande monitoring in te richten, transformeren organisaties secret vervaldatum van een eenvoudige compliance-vereiste naar een krachtig instrument voor beveiligingsbeheer en risicovermindering.

Compliance en Auditing

Het implementeren van secret vervaldatum in Azure Key Vault is niet alleen een best practice voor beveiliging, maar ook een vereiste vanuit verschillende compliance frameworks die van toepassing zijn op Nederlandse overheidsorganisaties en bedrijven die werken met gevoelige gegevens. De Center for Internet Security (CIS) Microsoft Azure Foundations Benchmark specificeert in control 5.3.3 dat alle secrets in Key Vault een vervaldatum moeten hebben. Deze control is geclassificeerd als Level 2, wat betekent dat het wordt aanbevolen voor organisaties die een verhoogde beveiligingspostuur nodig hebben. Het niet naleven van deze control kan leiden tot auditbevindingen en kan het moeilijk maken om te demonstreren dat passende beveiligingsmaatregelen zijn genomen om credentials te beschermen. Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van toepassing, waarin controle 09.04 specifiek ingaat op credential levenscyclusbeheer. Deze controle vereist dat organisaties een proces hebben voor het beheer van de levenscyclus van credentials, inclusief het instellen van vervaldatums en het uitvoeren van regelmatige rotaties. Het BIO-framework benadrukt het belang van het beperken van de geldigheidsduur van credentials om het risico te verkleinen dat verlopen of gecompromitteerde credentials worden gebruikt voor ongeautoriseerde toegang. Organisaties die niet voldoen aan deze BIO-controles kunnen worden geconfronteerd met vragen tijdens audits en kunnen worden gevraagd om verbeteringen door te voeren. Het ISO 27001:2022 informatiebeveiligingsmanagementsysteem bevat in controle A.5.17 specifieke vereisten voor authenticatie. Hoewel deze controle breder is dan alleen secret vervaldatum, omvat het de noodzaak om authenticatiemethoden te beheren en te controleren, inclusief het instellen van vervaldatums voor credentials en tokens. Voor organisaties die gecertificeerd zijn of streven naar ISO 27001-certificering, is het implementeren van secret vervaldatum een belangrijk onderdeel van het demonstreren van compliance met deze internationale standaard. Tijdens externe audits zal worden gecontroleerd of organisaties passende maatregelen hebben genomen om de levenscyclus van credentials te beheren, en het ontbreken van vervaldatums kan leiden tot non-conformity bevindingen. Naast deze specifieke compliance vereisten draagt secret vervaldatum ook bij aan het voldoen aan algemene privacy- en gegevensbeschermingsvereisten, zoals die worden gesteld door de Algemene Verordening Gegevensbescherming (AVG). Door secrets regelmatig te roteren en vervaldatums te gebruiken, beperken organisaties de tijd waarin gecompromitteerde credentials kunnen worden gebruikt om toegang te krijgen tot persoonsgegevens, wat een belangrijk aspect is van het waarborgen van passende technische en organisatorische maatregelen zoals vereist in artikel 32 van de AVG. Voor organisaties die werken met geclassificeerde informatie volgens de Nederlandse classificatierichtlijnen, is secret vervaldatum een kritieke beveiligingsmaatregel. Geclassificeerde informatie vereist strengere beveiligingscontroles, en het gebruik van langlevende secrets zonder vervaldatum kan leiden tot schendingen van classificatievereisten. Door secret vervaldatum te implementeren, demonstreren organisaties dat zij serieus omgaan met de bescherming van gevoelige informatie en voldoen aan de verwachtingen van classificatiebeheerders en auditoren. Tijdens externe en interne audits zal worden gecontroleerd of organisaties een adequaat proces hebben voor het beheer van secret levenscyclus. Auditors zullen vragen stellen over hoe organisaties ervoor zorgen dat alle secrets een vervaldatum hebben, hoe rotatieprocedures worden uitgevoerd, en hoe organisaties monitoren op secrets die verlopen zijn of binnenkort zullen verlopen. Het hebben van gedocumenteerde processen en geautomatiseerde monitoringtools maakt het voor organisaties veel eenvoudiger om compliance te demonstreren en auditbevindingen te voorkomen.

Remediatie

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

Het herstellen van secrets zonder vervaldatum in Azure Key Vault vereist een gestructureerde aanpak om ervoor te zorgen dat alle secrets een geldige vervaldatum krijgen zonder de operationele continuïteit te verstoren. Het remediatieproces begint met het identificeren van alle secrets die momenteel geen vervaldatum hebben geconfigureerd. Dit kan worden gedaan met behulp van geautomatiseerde PowerShell-scripts die door alle Key Vaults in de organisatie scannen en een overzicht genereren van secrets die aandacht vereisen. Eenmaal geïdentificeerd, moeten organisaties een beleid vaststellen voor de gewenste vervaldatumperiode. Deze periode moet worden afgestemd op het type secret en de risicoklasse ervan. Voor kritieke secrets zoals database-wachtwoorden of API-sleutels wordt vaak een kortere vervaldatumperiode van 90 dagen aanbevolen, terwijl minder kritieke secrets mogelijk een langere periode van 365 dagen kunnen hebben. Het is belangrijk dat deze vervaldatums realistisch zijn en aansluiten bij het vermogen van de organisatie om secrets regelmatig te roteren zonder dat applicaties worden verstoord. Het instellen van vervaldatums voor bestaande secrets moet zorgvuldig worden uitgevoerd met coördinatie tussen security-, operations- en development-teams. Voordat vervaldatums worden ingesteld, moeten teams worden geïnformeerd over de aanstaande wijzigingen en moeten zij hun applicaties voorbereiden op het feit dat secrets zullen verlopen en geroteerd moeten worden. Dit voorkomt dat applicaties onverwacht stoppen wanneer secrets verlopen voordat ze zijn geroteerd. In sommige gevallen kan het nodig zijn om eerst een secret rotatieproces te implementeren voordat vervaldatums worden ingesteld, vooral voor kritieke productieomgevingen. Na het instellen van vervaldatums is het essentieel om een proces in te richten voor het beheren van secrets die naderen aan hun verloopdatum. Dit omvat het genereren van waarschuwingen voor secrets die binnen 30 dagen verlopen, zodat teams voldoende tijd hebben om rotatieprocedures uit te voeren. Automatisering kan hierbij helpen door automatisch nieuwe versies van secrets te genereren en applicaties te informeren over de beschikbaarheid van nieuwe secret versies. Door een goed remediatie- en rotatieproces te implementeren, zorgen organisaties ervoor dat secret vervaldatum niet alleen een beveiligingsmaatregel is, maar ook een beheersbare en operationeel geïntegreerde praktijk wordt. Het remediatieproces moet ook rekening houden met de verschillende typen secrets die in een organisatie worden gebruikt. Database-wachtwoorden vereisen bijvoorbeeld vaak een andere aanpak dan API-sleutels of certificaten. Sommige secrets kunnen automatisch worden geroteerd zonder impact op applicaties, terwijl andere secrets handmatige interventie vereisen of wijzigingen in applicatiecode. Door een gedetailleerde inventarisatie te maken van alle secrets en hun gebruik, kunnen organisaties een gefaseerd remediatieplan ontwikkelen dat rekening houdt met de specifieke vereisten van elk type secret. Ten slotte is het belangrijk dat het remediatieproces wordt gedocumenteerd en dat alle wijzigingen worden vastgelegd voor auditdoeleinden. Dit omvat het bijhouden van welke secrets vervaldatums hebben gekregen, wanneer deze zijn ingesteld, en welke teams betrokken waren bij het proces. Door deze documentatie bij te houden, kunnen organisaties tijdens audits aantonen dat zij proactief hebben gehandeld om secret vervaldatum te implementeren en dat zij een gestructureerd proces hebben voor het beheer van secret levenscyclus.

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 Secret Expiration Non-RBAC Vaults .DESCRIPTION CIS Azure Foundations Benchmark - Control 8.16 Controleert secret expiration in non-RBAC Key Vaults. .NOTES Filename: secret-expiration-non-rbac-vaults.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 8.16 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.KeyVault [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Secret Expiration Non-RBAC Vaults" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $vaults = Get-AzKeyVault -ErrorAction SilentlyContinue $result = @{ TotalSecrets = 0; WithExpiration = 0 } foreach ($vault in $vaults) { $vaultDetail = Get-AzKeyVault -VaultName $vault.VaultName -ErrorAction SilentlyContinue if (-not $vaultDetail.EnableRbacAuthorization) { $secrets = Get-AzKeyVaultSecret -VaultName $vault.VaultName -ErrorAction SilentlyContinue foreach ($secret in $secrets) { $result.TotalSecrets++ if ($secret.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 Secrets (Non-RBAC): $($r.TotalSecrets)" -ForegroundColor White Write-Host "With Expiration: $($r.WithExpiration)" -ForegroundColor $(if ($r.WithExpiration -eq $r.TotalSecrets) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nSecret Expiration: $($r.WithExpiration)/$($r.TotalSecrets) non-RBAC secrets" } } 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 Secrets (Non-RBAC): $($r.TotalSecrets)" -ForegroundColor White Write-Host "With Expiration: $($r.WithExpiration)" -ForegroundColor $(if ($r.WithExpiration -eq $r.TotalSecrets) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nSecret Expiration: $($r.WithExpiration)/$($r.TotalSecrets) non-RBAC secrets" } } 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: Secrets zonder vervaldatum blijven onbeperkt geldig. Een gecompromitteerd secret kan jarenlang worden gebruikt zonder automatische vervaldatum, wat leidt tot langdurige blootstelling van systemen en gegevens. Compliancevereiste: CIS 5.3.3. Het risico is gemiddeld door het gebruik van langlevende credentials zonder automatische rotatie.

Management Samenvatting

Secret Vervaldatum Non-RBAC: Stel vervaldatum in voor alle secrets (90-365 dagen). Dwingt rotatie af. Activatie: Key Vault (Access Policy model) → Secrets → Stel vervaldatum in. Gratis. Verplicht volgens CIS 5.3.3. Implementatie: 3-5 uur. Verkleint het compromitteringsvenster aanzienlijk.