Secret Expiration Voor RBAC Key Vaults

💼 Management Samenvatting

Deze beveiligingsmaatregel waarborgt de correcte configuratie van vervalling van geheimen in Azure Key Vault en beschermt organisaties tegen beveiligingsrisico's die ontstaan door verouderde of permanent geldige geheimen.

Aanbeveling
Implementeer vervalling van geheimen voor alle geheimen in Azure Key Vault
Risico zonder
Medium
Risk Score
6/10
Implementatie
5u (tech: 3u)
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 beveiligingsbeste praktijken. Geheimen zonder vervaldatum blijven onbeperkt geldig, wat betekent dat gestolen credentials jarenlang bruikbaar blijven voor aanvallers. Door vervaldatums in te stellen, dwingt u organisaties tot regelmatige rotatie van geheimen, wat het blootstellingsvenster aanzienlijk verkleint.

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

Implementatie

Deze maatregel past de benodigde beveiligingsinstellingen toe via Azure Key Vault RBAC-beleid om geheimen te beschermen volgens actuele beveiligingsframeworks zoals CIS Benchmarks, BIO en ISO 27001. Het betreft specifiek het configureren van vervaldatums voor alle geheimen in Key Vaults die gebruikmaken van het RBAC-autorisatiemodel.

Vereisten

Voor het implementeren van vervalling van geheimen in Azure Key Vault zijn specifieke vereisten van toepassing die organisaties moeten begrijpen voordat zij deze beveiligingsmaatregel kunnen toepassen. De belangrijkste vereiste betreft het gebruik van het RBAC-autorisatiemodel binnen Azure Key Vault, wat fundamenteel verschilt van het traditionele toegangsbeleidsmodel dat Microsoft in eerdere versies van Key Vault gebruikte.

Azure Key Vault ondersteunt twee verschillende autorisatiemodellen voor toegangsbeheer. Het eerste model is het toegangsbeleidsmodel, waarbij toegangsrechten worden geconfigureerd op het niveau van de Key Vault zelf. Het tweede model is het RBAC-model (Role-Based Access Control), waarbij toegangsrechten worden beheerd via Azure Role-Based Access Control en Azure Active Directory rollen. Voor deze specifieke beveiligingsmaatregel is het essentieel dat organisaties gebruikmaken van Key Vaults die zijn geconfigureerd met het RBAC-autorisatiemodel.

De reden voor deze vereiste ligt in de manier waarop vervalling van geheimen wordt geïmplementeerd en beheerd binnen de verschillende autorisatiemodellen. Het RBAC-model biedt meer granulair beheer en betere integratie met Azure's identiteits- en toegangsbeheersystemen, wat essentieel is voor het effectief implementeren van vervallingsbeleid voor geheimen. Organisaties die nog gebruikmaken van het toegangsbeleidsmodel moeten eerst migreren naar het RBAC-model voordat zij deze maatregel kunnen implementeren.

Naast de vereiste van het RBAC-autorisatiemodel moeten organisaties beschikken over de juiste Azure-rollen en machtigingen. Specifiek hebben beheerders de rol 'Key Vault Secrets Officer' of 'Key Vault Administrator' nodig om vervaldatums te kunnen configureren voor geheimen. Deze rollen kunnen worden toegewezen op het niveau van de Key Vault, de resourcegroep of het abonnement, afhankelijk van de gewenste scope van beheer.

Een aanvullende technische vereiste betreft de versie van de Azure Key Vault-service. Hoewel vervalling van geheimen een standaardfunctie is in moderne Key Vault-implementaties, moeten organisaties ervoor zorgen dat zij gebruikmaken van een recente versie van de Key Vault-service die volledige ondersteuning biedt voor RBAC en het beheer van vervaldatums. Dit is doorgaans het geval voor alle Key Vaults die zijn aangemaakt na de introductie van RBAC-ondersteuning, maar organisaties moeten dit verifiëren voor bestaande implementaties.

Organisatorische vereisten omvatten het hebben van een duidelijk beleid voor beheer van geheimlevenscyclus. Organisaties moeten vooraf bepalen wat de gewenste geldigheidsperioden zijn voor verschillende typen geheimen, hoe zij omgaan met geheimen die bijna verlopen, en welke processen zij hebben voor het vernieuwen of roteren van geheimen voordat deze verlopen. Deze organisatorische voorbereiding is essentieel omdat het technisch instellen van vervaldatums zonder bijbehorende processen voor geheimrotatie kan leiden tot operationele problemen wanneer geheimen daadwerkelijk verlopen.

Tot slot moeten organisaties beschikken over monitoring- en waarschuwingscapaciteiten om te worden gewaarschuwd wanneer geheimen bijna verlopen of zijn verlopen. Dit kan worden geïmplementeerd via Azure Monitor, Log Analytics, of andere monitoringoplossingen die integratie bieden met Azure Key Vault. Zonder adequate monitoring bestaat het risico dat geheimen ongemerkt verlopen, wat kan leiden tot service-uitval of operationele verstoringen.

Monitoring

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

Monitoring van vervalling van geheimen in Azure Key Vault is een kritieke activiteit die organisaties in staat stelt om proactief te beheren welke geheimen binnenkort verlopen en welke geheimen momenteel geen vervaldatum hebben geconfigureerd. Effectieve monitoring voorkomt dat geheimen ongemerkt verlopen, wat kan leiden tot service-uitval, en identificeert beveiligingsrisico's die ontstaan door geheimen zonder vervaldatums.

Het monitoringproces begint met het inventariseren van alle geheimen binnen de Key Vaults die gebruikmaken van het RBAC-autorisatiemodel. Het monitoring script controleert systematisch elke geheim en verifieert of er een vervaldatum is ingesteld. Geheimen zonder vervaldatum worden geïdentificeerd als niet-compliant en vormen een direct beveiligingsrisico omdat deze onbeperkt geldig blijven, zelfs als ze worden gestolen of gecompromitteerd.

Naast het identificeren van geheimen zonder vervaldatums, moet monitoring ook aandacht besteden aan geheimen die binnenkort verlopen. Organisaties moeten een waarschuwingsperiode definiëren, bijvoorbeeld dertig dagen voor de vervaldatum, zodat er voldoende tijd is om geheimen te roteren voordat ze daadwerkelijk verlopen. Het monitoring script kan deze informatie verzamelen en rapporteren, waardoor organisaties proactief kunnen handelen.

De monitoring output moet duidelijk rapporteren welke geheimen momenteel geen vervaldatum hebben, wanneer bestaande geheimen verlopen, en welke geheimen binnenkort moeten worden geroteerd. Deze informatie is essentieel voor zowel operationele doeleinden als voor compliance- en auditdoeleinden. Organisaties kunnen deze rapportage gebruiken om te demonstreren dat zij voldoen aan beveiligingsstandaarden zoals CIS 5.2.3, BIO 09.04, en ISO 27001:2022 A.5.17.

Voor continue monitoring moeten organisaties overwegen om het monitoring script te integreren in hun automatiserings- en orchestratieprocessen. Dit kan worden bereikt door het script periodiek uit te voeren via Azure Automation, Azure DevOps pipelines, of andere CI/CD-tools. Regelmatige monitoring, bijvoorbeeld wekelijks of dagelijks, zorgt ervoor dat nieuwe geheimen die zonder vervaldatum worden aangemaakt snel worden geïdentificeerd en gecorrigeerd.

Het is ook belangrijk om monitoring uit te voeren op meerdere niveaus: niet alleen op het niveau van individuele Key Vaults, maar ook op het niveau van abonnementen of resourcegroepen. Dit geeft organisaties een holistisch beeld van hun compliance met vervalling van geheimen in de gehele Azure-omgeving. Dashboards en rapporten kunnen worden gegenereerd om deze informatie visueel weer te geven voor management en security teams.

Tot slot moet monitoring ook aandacht besteden aan historische trends. Door over tijd te monitoren hoeveel geheimen zonder vervaldatum zijn, kunnen organisaties meten of hun beheerprocessen voor geheimen verbeteren. Deze trendanalyse helpt bij het identificeren van terugkerende problemen en het evalueren van de effectiviteit van geïmplementeerde maatregelen en trainingen voor ontwikkelaars en beheerders.

Compliance en Auditing

Vervalling van geheimen in Azure Key Vault is een fundamentele beveiligingsmaatregel die direct aansluit bij meerdere internationale en nationale beveiligingsstandaarden en compliance frameworks. Organisaties die opereren in de Nederlandse publieke sector moeten voldoen aan specifieke eisen die zijn vastgelegd in deze frameworks, en vervalling van geheimen is een kritieke component van deze compliance-verplichtingen.

De CIS Microsoft Azure Foundations Benchmark, specifiek controle 5.2.3, vereist expliciet dat alle geheimen in Azure Key Vault een vervaldatum hebben geconfigureerd. Deze controle valt onder niveau L2 (Level 2), wat betekent dat het wordt aanbevolen voor organisaties die een hoger beveiligingsniveau willen bereiken. De CIS Benchmark is wereldwijd erkend als een beste praktijk framework voor cloud security, en naleving van deze controle is essentieel voor organisaties die hun Azure-omgeving willen beveiligen volgens industrie-standaarden.

Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van bijzonder belang. BIO controle 09.04 richt zich specifiek op beheer van credential levenscyclus en vereist dat organisaties processen hebben voor het beheren van de volledige levenscyclus van credentials, inclusief het instellen van vervaldatums en het roteren van credentials. Vervalling van geheimen in Azure Key Vault is een technische implementatie van deze BIO-vereiste en helpt organisaties te voldoen aan hun verplichtingen onder de BIO-normen.

De ISO 27001:2022 standaard, specifiek controle A.5.17 (Authentication information), vereist dat organisaties authenticatie-informatie beveiligen door middel van geschikte technische en organisatorische maatregelen. Dit omvat het beperken van de geldigheidsduur van authenticatie-informatie en het implementeren van processen voor regelmatige rotatie. Vervalling van geheimen in Azure Key Vault is een directe implementatie van deze ISO 27001-vereiste en helpt organisaties te voldoen aan deze internationale informatiebeveiligingsstandaard.

Voor auditdoeleinden moeten organisaties kunnen aantonen dat zij vervalling van geheimen hebben geïmplementeerd en dat alle geheimen binnen hun Key Vaults vervaldatums hebben. Dit vereist regelmatige monitoring en documentatie van de compliance status. Audit evidence moet omvatten: een lijst van alle geheimen met hun respectievelijke vervaldatums, historische data over geheimrotatie, en bewijs van monitoring en remediatie-activiteiten wanneer geheimen zonder vervaldatum worden geïdentificeerd.

Naast deze specifieke compliance-vereisten draagt vervalling van geheimen ook bij aan algemene privacy- en gegevensbeschermingsverplichtingen onder de Algemene Verordening Gegevensbescherming (AVG). Door geheimen regelmatig te roteren en vervaldatums te gebruiken, beperken organisaties het risico van langdurige blootstelling van persoonsgegevens in het geval van een datalek of beveiligingsincident. Dit is met name relevant voor organisaties die persoonsgegevens verwerken en moeten kunnen aantonen dat zij passende technische maatregelen hebben genomen om gegevens te beschermen.

Voor Nederlandse overheidsorganisaties is het ook belangrijk om te begrijpen dat compliance met deze frameworks niet alleen een technische oefening is, maar ook een organisatorische verplichting. Dit betekent dat organisaties niet alleen vervalling van geheimen moeten implementeren, maar ook moeten kunnen aantonen dat zij processen hebben voor het beheren van geheimlevenscyclus, dat zij regelmatig monitoren op compliance, en dat zij actie ondernemen wanneer niet-compliant situaties worden geïdentificeerd. Deze holistische aanpak is essentieel voor succesvolle compliance en voor het behalen van certificeringen zoals ISO 27001 of het voldoen aan BIO-audits.

Remediatie

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

Remediatie van geheims zonder vervaldatum in Azure Key Vault is een proces dat zorgvuldig moet worden uitgevoerd om zowel beveiligingsdoelen te bereiken als operationele verstoringen te voorkomen. Het remediatieproces omvat het identificeren van geheims zonder vervaldatum, het bepalen van geschikte geldigheidsperioden voor verschillende typen geheims, en het daadwerkelijk instellen van vervaldatums op bestaande geheims.

Voordat remediatie wordt uitgevoerd, is het essentieel om eerst een volledige inventarisatie te maken van alle geheims die momenteel geen vervaldatum hebben. Het remediatie script kan deze inventarisatie automatisch uitvoeren en een rapport genereren dat aangeeft welke geheims moeten worden bijgewerkt. Deze inventarisatie moet ook informatie bevatten over het type geheim, de datum waarop het is aangemaakt, en de applicaties of services die gebruikmaken van het geheim, zodat beheerders kunnen bepalen wat de impact zal zijn van het instellen van een vervaldatum.

Een kritieke overweging bij remediatie is het bepalen van geschikte geldigheidsperioden voor verschillende typen geheimen. Niet alle geheimen hebben dezelfde levensduur nodig: bijvoorbeeld, databaseverbindingsreeksen die worden gebruikt door productieapplicaties kunnen een langere geldigheidsperiode hebben (bijvoorbeeld 365 dagen) dan tijdelijke API-sleutels die worden gebruikt voor ontwikkeling of testen (bijvoorbeeld 90 dagen). Organisaties moeten een geheimclassificatieschema ontwikkelen dat verschillende geldigheidsperioden definieert op basis van het type geheim, de gevoeligheid van de gegevens die het geheim beschermt, en de operationele vereisten van de applicaties die het geheim gebruiken. Dit classificatieschema moet worden gedocumenteerd in het beveiligingsbeleid van de organisatie en moet regelmatig worden geëvalueerd om ervoor te zorgen dat de geldigheidsperioden nog steeds passend zijn voor de huidige bedreigingsomgeving en operationele vereisten.

Het daadwerkelijk instellen van vervaldatums op bestaande geheimen moet worden uitgevoerd met zorg om operationele verstoringen te voorkomen. Voor geheimen die momenteel actief worden gebruikt door productieapplicaties, moeten organisaties eerst verifiëren dat zij processen hebben voor geheimrotatie voordat de vervaldatum wordt bereikt. Het is niet voldoende om simpelweg een vervaldatum in te stellen zonder te zorgen dat er een mechanisme is om het geheim te vernieuwen voordat het verloopt, omdat dit kan leiden tot service-uitval wanneer het geheim daadwerkelijk verloopt. Organisaties moeten daarom een gestructureerd proces ontwikkelen voor geheimrotatie dat duidelijk definieert wie verantwoordelijk is voor het roteren van geheimen, wanneer rotatie moet plaatsvinden (bijvoorbeeld dertig dagen voor de vervaldatum), en hoe nieuwe geheimen worden gegenereerd en gedistribueerd naar de applicaties die deze gebruiken. Dit proces moet worden getest in een niet-productieomgeving voordat het wordt toegepast op productiegeheimen om ervoor te zorgen dat applicaties correct kunnen omgaan met geheimrotatie zonder service-uitval.

Het remediatie script kan worden geconfigureerd om automatisch vervaldatums in te stellen op basis van vooraf gedefinieerde policies. Dit kan worden gedaan voor nieuwe geheims die worden aangemaakt, maar voor bestaande geheims zonder vervaldatum moet vaak handmatige interventie plaatsvinden om te bepalen wat de geschikte vervaldatum is. In sommige gevallen kan het nodig zijn om eerst contact op te nemen met de eigenaar van de applicatie of service die het geheim gebruikt om te verifiëren wat de impact zal zijn en om te coördineren wanneer de vervaldatum wordt ingesteld.

Na het instellen van vervaldatums moet het remediatieproces ook aandacht besteden aan het opzetten van monitoring en waarschuwingssystemen om te waarschuwen wanneer geheims binnenkort verlopen. Dit is essentieel omdat het instellen van vervaldatums alleen niet voldoende is: organisaties moeten ook kunnen reageren wanneer geheims daadwerkelijk verlopen. Het remediatie script kan worden uitgebreid om automatisch alerts te configureren in Azure Monitor of andere monitoringoplossingen, zodat beheerders proactief kunnen handelen voordat geheims verlopen.

Voor organisaties met een groot aantal geheims kan remediatie een tijdrovend proces zijn. In dergelijke gevallen is het aan te raden om remediatie gefaseerd uit te voeren, te beginnen met de meest kritieke geheims (bijvoorbeeld geheims die worden gebruikt voor productieapplicaties of geheims die toegang geven tot gevoelige data) en vervolgens geleidelijk uit te breiden naar minder kritieke geheims. Deze gefaseerde aanpak minimaliseert het risico van operationele problemen en geeft organisaties de tijd om hun geheim rotation processen te verbeteren terwijl remediatie wordt uitgevoerd.

Tot slot moet remediatie worden gedocumenteerd voor auditdoeleinden. Organisaties moeten bijhouden welke geheims zijn bijgewerkt, wanneer de vervaldatums zijn ingesteld, en welke geldigheidsperioden zijn gebruikt. Deze documentatie is essentieel voor het aantonen van compliance met beveiligingsstandaarden en voor het verifiëren dat remediatie correct is uitgevoerd. Het remediatie script kan automatisch deze documentatie genereren, wat het proces vereenvoudigt en zorgt voor consistente rapportage.

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 RBAC Vaults .DESCRIPTION CIS Azure Foundations Benchmark - Control 8.16 Controleert secret expiration in RBAC Key Vaults. .NOTES Filename: secret-expiration-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 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 ($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 (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) 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 (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) 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: Geheimen zonder vervaldatum blijven onbeperkt geldig, wat betekent dat gestolen credentials jarenlang bruikbaar blijven voor aanvallers. Dit vormt een significant beveiligingsrisico omdat gecompromitteerde geheimen niet automatisch worden uitgeschakeld. Organisaties voldoen niet aan compliance-vereisten zoals CIS 5.2.3, BIO 09.04, en ISO 27001:2022 A.5.17. Het risico wordt geclassificeerd als medium, met name gerelateerd aan beheer van credential levensduur en de potentiële lange-termijn impact van gestolen credentials.

Management Samenvatting

Vervalling van geheimen voor RBAC Key Vaults: Stel vervaldatums in voor alle geheimen (aanbevolen periode 90-365 dagen afhankelijk van het type geheim). Dit dwingt organisaties tot regelmatige geheimrotatie, wat het blootstellingsvenster aanzienlijk verkleint. Activatie vindt plaats via Azure Key Vault (RBAC model) → Geheimen → Vervaldatum instellen. De functie is gratis beschikbaar en is verplicht volgens CIS 5.2.3. Implementatie vereist ongeveer 3-5 uur werk, inclusief configuratie en het instellen van monitoring. Deze maatregel beperkt de potentiële schade van gecompromitteerde geheimen door automatische vervalling.