BIO 10.01.02 ISO A.8.24

Azure Key Vault-ontwerp (beheer Van Secrets, Sleutels En Certificaten)

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

💼 Management Samenvatting

Azure Key Vault is de centrale beveiligingslaag voor het opslaan en beheren van secrets (zoals wachtwoorden, connection strings en API-sleutels), versleutelingssleutels en certificaten. Deze dienst maakt gebruik van hardware security modules (HSM’s), fijnmazige toegangscontrole, auditing en geautomatiseerde rotatie om het volledige levenscyclusbeheer van gevoelige gegevens te professionaliseren en het risico op uitlekken van inloggegevens drastisch te verlagen.

Aanbeveling
Implementeer een gestandaardiseerde Azure Key Vault-architectuur voor alle gevoelige secrets, sleutels en certificaten.
Risico zonder
Critical
Risk Score
9/10
Implementatie
24u (tech: 16u)
Van toepassing op:
✓ Azure
✓ Key Vault

Zonder een centraal Key Vault-ontwerp belanden secrets vaak verspreid over broncode, configuratiebestanden, scripts en handmatige documentatie. Dat leidt tot situaties waarin wachtwoorden in Git-repositories terechtkomen, connection strings in platte tekst worden gedeeld, versleutelingssleutels lokaal op servers staan en niemand precies weet wie welke secret heeft gebruikt of gewijzigd. Rotatie van credentials gebeurt dan ad-hoc of helemaal niet, waardoor hetzelfde wachtwoord jarenlang in gebruik blijft. Een goed ingerichte Azure Key Vault lost deze problemen op door alle secrets, sleutels en certificaten gecentraliseerd op te slaan, toegang uitsluitend via geauthenticeerde identiteiten toe te staan, uitgebreide auditlogs te genereren en rotatiebeleid af te dwingen. Daarmee ondersteun je zowel de beveiligingsdoelstellingen van de organisatie als de naleving van normen zoals BIO en ISO 27001.

Implementatie

Een robuust Key Vault-ontwerp combineert architectuurkeuzes, toegangsbeheer en netwerkbeveiliging in één samenhangend geheel. Per omgeving worden afzonderlijke kluizen ingericht (bijvoorbeeld productie, test en ontwikkeling) zodat rechten en secrets nooit onnodig worden gedeeld tussen omgevingen. Applicaties krijgen toegang via beheerde identiteiten in plaats van ingebouwde gebruikersnamen en wachtwoorden, waardoor er geen vaste credentials meer in code, scripts of pipelines nodig zijn. Binnen de kluizen worden verschillende typen secrets opgeslagen, zoals connection strings, database- en API-wachtwoorden en TLS/SSL-certificaten voor publieke en interne diensten. Versleutelingssleutels kunnen softwarematig worden beschermd of, waar wet- en regelgeving dat vereist, via HSM’s met FIPS-gecertificeerde hardware. Netwerkbeveiliging wordt vormgegeven met private endpoints en firewallregels, zodat alleen goedgekeurde netwerken of IP-adressen de kluis kunnen benaderen. Tot slot worden soft delete, purge-beveiliging, back-up en – waar nodig – geo-replicatie ingeschakeld zodat verwijderingen kunnen worden teruggedraaid en kritieke secrets ook bij een storing beschikbaar blijven.

Vereisten

  1. Een Azure-abonnement waarin de Key Vault-resources worden beheerd en verantwoord kunnen worden binnen de governance-structuur van de organisatie.
  2. Een actueel en volledig overzicht van alle secrets, sleutels en certificaten die naar Key Vault gemigreerd moeten worden, inclusief eigenaarschap en gebruikende applicaties.
  3. Applicaties en services die gebruikmaken van beheerde identiteiten, zodat toegang tot de kluis wordt geregeld via identity-based toegangscontrole in plaats van statische wachtwoorden.
  4. Een RBAC-autorisatiemodel waarin duidelijk is wie Key Vault mag beheren, wie secrets mag lezen of bijwerken en hoe functiescheiding wordt toegepast voor ontwikkelaars, beheerders en auditors.
  5. Een uitgewerkte back-up- en disaster recovery-strategie voor Key Vault, inclusief afspraken over retentie, herstelprocedures en testen van het herstelproces.
  6. Duidelijke compliance- en auditvereisten (bijvoorbeeld of HSM-beschermde sleutels verplicht zijn voor specifieke systemen of gegevenscategorieën).
  7. Een netwerkbeveiligingsontwerp waarin is vastgelegd welke virtuele netwerken, subnetten en IP-adressen toegang krijgen via privé-eindpunten en welke publieke toegang, indien aanwezig, volledig wordt beperkt.

Implementatie

De implementatie van Azure Key Vault begint met het opzetten van een heldere scheiding tussen omgevingen. Richt voor iedere omgeving – zoals productie, test, acceptatie en ontwikkeling – één of meer aparte kluizen in, zodat secrets nooit onnodig gedeeld worden tussen omgevingen met verschillende risicoprofielen. Geef iedere kluis een herkenbare naamconventie waarin omgeving, regio en eigenaar zijn verwerkt, zodat beheerteams in één oogopslag zien waarvoor de kluis bedoeld is. Activeer vervolgens soft delete en purge-beveiliging op alle kluizen; dit voorkomt dat secrets of complete kluizen per ongeluk permanent worden verwijderd en maakt gecontroleerd herstel mogelijk bij fouten of misbruik. Daarna wordt het toegangsbeheer ingericht. Gebruik waar mogelijk Azure RBAC-rollen zoals Key Vault Administrator, Key Vault Secrets Officer en Key Vault Reader in plaats van oudere access policies. Koppel de rollen aan Azure AD-groepen in plaats van individuele accounts, zodat wijzigingen in team- of functierollen centraal in de identity-omgeving kunnen worden beheerd. Voor applicaties wordt toegang uitsluitend verleend via beheerde identiteiten (system-assigned of user-assigned). Hierdoor hoeven er geen inloggegevens meer in code, configuratiebestanden of CI/CD-pipelines te worden opgenomen en kan toegang worden ingetrokken door de identiteit te verwijderen of rechten aan te passen. Wanneer de basis staat, vindt de migratie van secrets plaats. Breng eerst in kaart waar secrets zich nu bevinden – bijvoorbeeld in applicatieconfiguratie, scripts, key files of documentatie – en definieer een volgorde waarin ze veilig naar Key Vault worden overgezet. Elke secret wordt in de kluis aangemaakt met een duidelijke naam, beschrijving en – waar mogelijk – een rotatiebeleid, zodat bijvoorbeeld databasewachtwoorden periodiek automatisch worden vernieuwd. Pas na succesvolle migratie en validatietests worden de oude secrets uit code en configuratie verwijderd. Parallel hieraan wordt netwerkbeveiliging ingericht: maak gebruik van privé-eindpunten om de kluis te verbinden met relevante virtuele netwerken en stel firewallregels zo in dat alleen expliciet toegestane adressen of subnetten toegang hebben. Tot slot wordt diagnostische logging geactiveerd richting bijvoorbeeld Log Analytics of een SIEM-oplossing, zodat alle toegangs- en beheergebeurtenissen centraal kunnen worden gemonitord, geanalyseerd en gebruikt voor rapportages aan auditors en het CISO-office.

Compliance en auditing

Azure Key Vault speelt een centrale rol in het voldoen aan cryptografie- en wachtwoordbeheervereisten uit relevante normen en wetgeving voor Nederlandse (overheids)organisaties. Door sleutels en secrets centraal en gecontroleerd te beheren sluit Key Vault aan bij BIO 10.01 voor cryptografisch sleutelbeheer en bij ISO 27001-controles zoals A.8.24 (gebruik van cryptografie) en A.9.4.3 (beheer van authenticatiemiddelen en wachtwoorden). Voor organisaties die betaalkaarten verwerken ondersteunt Key Vault de implementatie van PCI-DSS-eisen 3.5 en 3.6 rondom beschermings- en rotatieprocedures voor sleutels. Daarnaast sluiten de mogelijkheden voor sleutellevenscyclusbeheer goed aan bij richtlijnen uit NIST SP 800-57, waaronder het definiëren van sleutelklassen, sleutelsterkte, rotatie-intervallen en veilige vernietiging. Door auditlogs van Key Vault te koppelen aan een SIEM en periodiek te rapporteren over gebruik, mislukte toegangsverzoeken en sleutelrotaties kan de organisatie aantonen dat beleid niet alleen op papier bestaat, maar daadwerkelijk in de praktijk wordt nageleefd.

Monitoring

Gebruik PowerShell-script azure-key-vault.ps1 (functie Invoke-Monitoring) – Uitvoeren van controles op configuratie, toegangsrechten en logregistratie van Azure Key Vault om afwijkingen en mogelijke misconfiguraties tijdig te detecteren..

Remediatie

Gebruik PowerShell-script azure-key-vault.ps1 (functie Invoke-Remediation) – Automatisch herstellen van gevonden afwijkingen in de Key Vault-configuratie, zoals ontbrekende soft delete, te ruime toegangsrechten of niet-ingevoerde netwerkbeperkingen..

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
<# .SYNOPSIS Azure Key Vault Design .DESCRIPTION Implementation for Azure Key Vault Design .NOTES Filename: azure-key-vault.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/design/platform/azure-key-vault.json #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Azure Key Vault Design" $BIOControl = "10.01" function Connect-RequiredServices { # Connection logic based on API } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "azure-key-vault" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } # Compliance check implementation # Based on: Design Document $result.Details += "Compliance check - implementation required based on control" $result.NonCompliantCount = 1 return $result } function Invoke-Remediation { Write-Host "`nApplying remediation for: $PolicyName..." -ForegroundColor Cyan # Remediation implementation Write-Host " Configuration applied" -ForegroundColor Green Write-Host "`n[OK] Remediation completed" -ForegroundColor Green } function Invoke-Monitoring { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color return $result } function Invoke-Revert { Write-Host "Revert: Configuration revert not yet implemented" -ForegroundColor Yellow } try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { Invoke-Revert } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red } } } catch { Write-Error $_ }

Risico zonder implementatie

Risico zonder implementatie
Critical: Als secrets hardcoded in code of configuratiebestanden blijven staan, is het risico op credential exposure via bijvoorbeeld GitHub-lekken, code­diefstal of fout gedeelde configuratiebestanden zeer groot. Zonder centrale kluis ontstaat credential sprawl: niemand heeft nog volledig overzicht, rotatie gebeurt zelden of niet en er is geen betrouwbare audittrail van wie welke secret wanneer heeft gebruikt. Daarmee voldoet de organisatie niet aan eisen uit onder andere BIO 10.01 en PCI-DSS 3.5 en ontstaat een kritisch risico op misbruik van accounts, data­lekken en langdurige compromittering van systemen.

Management Samenvatting

Azure Key Vault biedt centraal beheer van secrets, sleutels en certificaten met HSM-ondersteunde beveiliging, integratie met beheerde identiteiten (waardoor er geen wachtwoorden meer in code nodig zijn), soft delete en purge-beveiliging voor veilig herstel, RBAC-gebaseerd toegangsbeheer, uitgebreide diagnostische logging voor auditdoeleinden en private endpoints voor afscherming binnen het netwerk. Door voor elke omgeving aparte kluizen te gebruiken en rotatiebeleid in te richten worden hardcoded secrets uitgebannen, worden compliance-eisen zoals BIO 10.01, ISO 27001 en PCI-DSS 3.5 ondersteund en wordt de basis gelegd voor een veilig applicatielandschap in de cloud.