Customer-beheerde Keys (CMK) Voor Azure Resources

Microsoft-beheerde Keys (MMK, standaard) bieden geen controle over de sleutellevenscyclus. Voor organisaties met strikte compliance vereisten zoals AVG, NIS2 en ISO27001 is vaak vereist: eigen sleutelbeheer, controle over sleutelrotatie, de mogelijkheid om toegang direct in te trekken bij beveiligingsincidenten, geografisch specifieke sleutelopslag voor dataregionaliteit, en een compleet auditlogboek van alle sleuteloperaties. Zonder CMK ontstaan er problemen: geen compliance met strikte datasobereiniteit vereisten, geen mogelijkheid tot noodintrekking van sleutels, beperkt auditlogboek, en afhankelijkheid van Microsoft sleutelbeheerbeleid.

Implementatie

CMK implementatie omvat het aanmaken van een dedicated Key Vault per omgeving met passende op rollen gebaseerde toegangscontrole (RBAC), het inschakelen van Soft Delete en Purge bescherming (vereist), het aanmaken van customer-beheerde versleutelingssleutels in Key Vault, het toekennen van passende toegangsmachtigingen aan service-principals voor opslag, SQL en Cosmos DB, het configureren van Azure resources om CMK te gebruiken, het implementeren van een sleutelrotatiebeleid (handmatig of automatisch elke 90 dagen), en het monitoren van sleutelgebruik via diagnostische logboeken. Deze aanpak ondersteunt Azure opslagaccounts, Azure SQL Databases, Cosmos DB, beheerde Disks, en meer. De kosten bestaan uit Key Vault operations (€0,025 per 10K operations) plus operationele overhead voor sleutelbeheer.

Vereisten

Voordat organisaties Customer-beheerde Keys kunnen implementeren in hun Azure omgeving, moeten verschillende technische en organisatorische vereisten worden vervuld. Deze vereisten vormen de fundering voor een veilige en beheerbare sleutelbeheeromgeving die voldoet aan strenge compliance vereisten en best practices op het gebied van cryptografische beveiliging. Het implementeren van Customer-beheerde Keys zonder deze fundamentele vereisten te vervullen kan leiden tot beveiligingsrisico's, compliance problemen en operationele uitdagingen die de effectiviteit van de hele implementatie ondermijnen.

Op technisch niveau is een Azure Key Vault Premium tier vereist wanneer organisaties gebruik willen maken van HSM-backed keys. Hardware Security Modules (HSM) bieden de hoogste beveiligingsstandaard door sleutels in FIPS 140-2 Level 3 gecertificeerde hardware op te slaan. Deze hardware-gebaseerde beveiliging zorgt ervoor dat sleutels nooit de HSM verlaten en dat alle cryptografische operaties binnen de beveiligde hardware worden uitgevoerd. Voor de meeste organisaties zijn software-backed keys echter voldoende, maar voor financiële instellingen, overheidsorganisaties met classificaties, en bedrijven die onder PCI-DSS vallen, is HSM-backing vaak verplicht. De keuze tussen software-backed en HSM-backed keys moet worden gemaakt op basis van compliance vereisten, risicobeoordeling en budgettaire overwegingen.

Een kritieke beveiligingsvereiste is het inschakelen van Soft Delete en Purge bescherming op de Key Vault. Soft Delete zorgt ervoor dat verwijderde sleutels veertien dagen behouden blijven, wat bescherming biedt tegen onopzettelijke verwijderingen en kwaadwillende acties. Deze functie maakt het mogelijk om verwijderde sleutels te herstellen binnen de retentieperiode, wat cruciaal kan zijn wanneer een beheerder per ongeluk een sleutel verwijdert of wanneer een aanvaller probeert sleutels te verwijderen om sporen uit te wissen. Purge bescherming voorkomt dat zelfs beheerders met volledige machtigingen deze periode kunnen omzeilen door sleutels direct permanent te verwijderen. Deze functies zijn niet alleen best practice, maar vaak ook expliciet vereist in compliance frameworks zoals ISO 27001 en de BIO. Zonder deze beschermingen lopen organisaties het risico dat kritieke versleutelingssleutels permanent verloren gaan, wat kan leiden tot onherstelbare dataverlies en ernstige bedrijfsimpact.

Voor de operationele werking van Customer-beheerde Keys moeten service-principals van Azure resources zoals Storage Accounts, SQL Databases en Cosmos DB accounts beschikken over passende machtigingen op de Key Vault. Deze service-principals hebben minimaal de machtiging 'Get', 'Unwrap Key' en 'Wrap Key' nodig om versleutelingsoperaties uit te voeren. De 'Get' machtiging stelt de service-principal in staat om sleutelmetadata op te halen, terwijl 'Unwrap Key' en 'Wrap Key' machtigingen nodig zijn voor het ontsleutelen en versleutelen van data encryption keys. Het toekennen van deze machtigingen gebeurt via op rollen gebaseerde toegangscontrole (RBAC) of via Key Vault toegangsbeleid, waarbij het principe van minimale rechten moet worden toegepast. Dit betekent dat elke service-principal alleen de exacte machtigingen krijgt die nodig zijn voor zijn specifieke functie, en geen extra rechten die kunnen worden misbruikt bij een compromittering. Organisaties moeten regelmatig controleren of deze machtigingen nog steeds nodig zijn en of er geen ongebruikte of overbodige toegang is verleend.

Organisatorisch gezien vereist een succesvolle CMK implementatie een gedocumenteerd sleutelrotatieproces. Sleutelrotatie is essentieel voor het beperken van de impact van potentiële sleutelcompromittering en is vaak verplicht gesteld in compliance frameworks. Wanneer een sleutel wordt gecompromitteerd, kan de schade worden beperkt door regelmatig sleutels te roteren, waardoor oude sleutels niet meer bruikbaar zijn voor nieuwe versleutelingsoperaties. Het proces kan handmatig worden uitgevoerd elke 90 dagen, maar automatische rotatie via Azure Automation of Azure Functions wordt sterk aanbevolen voor betrouwbaarheid en consistentie. Automatische rotatie elimineert menselijke fouten en zorgt ervoor dat rotatie altijd op tijd plaatsvindt, zelfs wanneer beheerders druk zijn met andere taken. De documentatie moet duidelijk beschrijven wie verantwoordelijk is voor het rotatieproces, welke stappen worden genomen, hoe het proces wordt geverifieerd, en wat er moet gebeuren wanneer rotatie faalt. Deze documentatie moet regelmatig worden geüpdatet en moet beschikbaar zijn voor alle betrokken teams.

Een robuuste backup en disaster recovery strategie voor versleutelingssleutels is cruciaal voor bedrijfscontinuïteit. Organisaties moeten procedures hebben voor het veilig backuppen van sleutels naar een secundaire locatie, waarbij de backups zelf ook versleuteld moeten zijn om te voorkomen dat ze kunnen worden misbruikt wanneer ze worden gestolen of gecompromitteerd. De backup locatie moet fysiek gescheiden zijn van de primaire Key Vault om te beschermen tegen regionale uitval of natuurrampen. In het geval van een disaster scenario waarbij de primaire Key Vault niet meer beschikbaar is, moeten organisaties snel kunnen terugvallen op deze backups zonder dat dit leidt tot langdurige uitval van kritieke systemen. Het herstelproces moet regelmatig worden getest om te verzekeren dat het effectief werkt wanneer het daadwerkelijk nodig is. Organisaties moeten ook overwegen om backups te maken in meerdere geografische regio's om bescherming te bieden tegen grootschalige uitval, en moeten procedures hebben voor het veilig transporteren en opslaan van backup sleutels.

Een break-glass procedure voor emergency key recovery is essentieel voor scenario's waarin normale toegangsmechanismen niet meer functioneren, bijvoorbeeld bij verlies van credentials of tijdens een security incident. Deze procedure moet duidelijk beschrijven hoe geautoriseerde personen in noodsituaties toegang kunnen krijgen tot sleutels, waarbij alle acties worden gelogd voor latere audit. De procedure moet specifieke stappen bevatten voor verschillende scenario's, zoals verlies van beheerder credentials, compromittering van normale toegangsmechanismen, of noodzaak voor snelle sleutelintrekking tijdens een actief security incident. Alle acties die worden uitgevoerd tijdens break-glass procedures moeten worden gedocumenteerd en geaudit, en er moeten procedures zijn voor het herstellen van normale toegangsmechanismen na het oplossen van de noodsituatie. De procedure moet regelmatig worden getest om te verzekeren dat deze effectief werkt wanneer deze daadwerkelijk nodig is, en alle betrokken personen moeten bekend zijn met de procedure en weten wanneer deze mag worden gebruikt.

Ten slotte vereist effectief sleutelbeheer training van het security team. Teamleden moeten niet alleen technisch in staat zijn om Key Vault te beheren, maar ook begrijpen welke compliance vereisten gelden, hoe incidenten moeten worden afgehandeld, en wat de impact is van sleuteloperaties op productiesystemen. Training moet zowel technische vaardigheden als proceskennis omvatten, en moet regelmatig worden geüpdatet wanneer nieuwe functies worden geïntroduceerd of wanneer compliance vereisten veranderen. Regelmatige training en certificering helpen ervoor te zorgen dat het team up-to-date blijft met best practices en nieuwe beveiligingstechnologieën. Daarnaast moeten organisaties overwegen om cross-training te implementeren zodat meerdere teamleden in staat zijn om sleutelbeheer uit te voeren, wat bescherming biedt tegen uitval van individuele teamleden en zorgt voor continuïteit van operaties.

Monitoring

Gebruik PowerShell-script encryption-cmk.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Customer-beheerde Keys is essentieel voor het waarborgen van beveiliging, compliance en operationele continuïteit. Monitoring omvat het continue volgen van Key Vault toegang, sleuteloperaties, fouten en verdachte activiteiten. Zonder adequate monitoring kunnen organisaties niet tijdig reageren op beveiligingsincidenten, compliance schendingen of operationele problemen die de beschikbaarheid van versleutelde resources kunnen beïnvloeden. Een goed ontworpen monitoring strategie stelt organisaties in staat om proactief te reageren op problemen voordat ze kritieke systemen beïnvloeden, en biedt de benodigde inzichten voor compliance rapportage en audit doeleinden.

Azure Key Vault biedt uitgebreide diagnostische logboeken die alle sleuteloperaties vastleggen, inclusief sleutel creatie, wijziging, verwijdering, wrap- en unwrap-operaties. Deze logboeken bevatten gedetailleerde informatie over wie welke operatie heeft uitgevoerd, wanneer deze plaatsvond, en wat het resultaat was. Deze logboeken moeten worden ingeschakeld en doorgestuurd naar Azure Monitor Log Analytics voor gedetailleerde analyse en lange-termijn opslag. Door gebruik te maken van Log Analytics kunnen organisaties complexe queries uitvoeren om specifieke gebeurtenissen te identificeren, trends te analyseren en afwijkingen te detecteren die kunnen wijzen op beveiligingsincidenten. De logboeken moeten worden bewaard voor minimaal de periode die vereist is door compliance frameworks, wat vaak zeven jaar of langer kan zijn voor financiële en overheidsorganisaties.

Een kritieke monitoring component is het implementeren van real-time alerting voor verdachte activiteiten. Organisaties moeten alerts configureren voor scenario's zoals meerdere mislukte toegangspogingen, ongeautoriseerde toegangspogingen, pogingen om soft delete te omzeilen, en ongebruikelijke sleuteloperaties buiten normale kantooruren. Deze alerts moeten worden geïntegreerd met Security Information and Event Management (SIEM) systemen voor gecentraliseerde beveiligingsmonitoring en incident response workflows. Alerts moeten worden geconfigureerd met passende drempelwaarden om false positives te minimaliseren terwijl echte bedreigingen niet worden gemist. Organisaties moeten ook procedures hebben voor het escaleren van alerts naar de juiste teams en voor het documenteren van reacties op alerts voor audit doeleinden.

Naast beveiligingsmonitoring moeten organisaties ook operationele metrics volgen die impact hebben op beschikbaarheid en prestaties. Belangrijke metrics omvatten sleuteloperatie latencies, Key Vault beschikbaarheid, rate limiting events, en foutpercentages. Het monitoren van deze metrics helpt organisaties proactief problemen te identificeren voordat deze kritieke systemen beïnvloeden en maakt het mogelijk om schaalbaarheidsproblemen vroegtijdig te detecteren. Wanneer sleuteloperaties langzamer worden of wanneer rate limiting events optreden, kan dit wijzen op problemen met de Key Vault configuratie of op schaalbaarheidsproblemen die moeten worden aangepakt voordat ze kritieke systemen beïnvloeden. Organisaties moeten baseline metrics vaststellen voor normale operaties en alerts configureren wanneer metrics significant afwijken van deze baselines.

Compliance monitoring is eveneens cruciaal, waarbij organisaties moeten kunnen aantonen dat sleuteloperaties worden uitgevoerd in overeenstemming met beleid en regulering. Dit vereist het monitoren van sleutelrotatieschema's, toegangsmachtigingen, en auditlogboekintegriteit. Organisaties moeten regelmatig compliance rapportages genereren die aantonen dat sleutelbeheer voldoet aan vereisten zoals ISO 27001, NIS2, AVG, en BIO normen. Deze rapportages moeten beschikbaar zijn voor zowel interne auditors als externe compliance controles. Compliance monitoring moet ook controleren of sleutelrotatie plaatsvindt volgens het vastgestelde schema, of toegangsmachtigingen correct zijn geconfigureerd volgens het principe van minimale rechten, en of alle sleuteloperaties correct worden gelogd voor audit doeleinden. Automatische compliance checks kunnen worden geïmplementeerd om regelmatig te verifiëren dat alle configuraties voldoen aan compliance vereisten.

Het gebruik van Customer-beheerde Keys introduceert nieuwe afhankelijkheden tussen Azure resources en Key Vault. Monitoring moet daarom ook de status van deze afhankelijkheden volgen, waarbij alerts worden geconfigureerd wanneer resources niet meer kunnen communiceren met Key Vault of wanneer sleuteloperaties falen. Dergelijke scenario's kunnen leiden tot downtime van kritieke systemen als deze niet snel worden opgelost, waardoor proactieve monitoring van essentieel belang is. Organisaties moeten monitoring implementeren die detecteert wanneer een resource niet meer kan communiceren met Key Vault, wanneer sleuteloperaties consistent falen, of wanneer er problemen zijn met netwerkconnectiviteit tussen resources en Key Vault. Deze monitoring moet worden geïntegreerd met incident response procedures zodat problemen snel kunnen worden opgelost voordat ze kritieke systemen beïnvloeden.

Voor geavanceerde monitoring kunnen organisaties gebruik maken van Azure Sentinel of andere SIEM-oplossingen voor correlation van Key Vault events met andere beveiligingssignalen. Dit maakt het mogelijk om complexe attack patterns te detecteren waarbij aanvallen op meerdere services worden gecoördineerd. Machine learning gebaseerde anomaliedetectie kan helpen bij het identificeren van subtiele afwijkingen die mogelijk wijzen op geavanceerde persistent threats of insider threats. Door Key Vault events te correleren met events van andere Azure services en on-premises systemen, kunnen organisaties een compleet beeld krijgen van beveiligingsincidenten en kunnen ze aanvallen detecteren die anders onopgemerkt zouden blijven. Machine learning modellen kunnen worden getraind om normale patronen te herkennen en alerts te genereren wanneer activiteiten significant afwijken van deze patronen, wat helpt bij het detecteren van geavanceerde bedreigingen die traditionele rule-based monitoring zou missen.

Het is belangrijk om regelmatig monitoring configuraties te reviewen en aan te passen op basis van geleerde lessen en veranderende bedreigingslandschappen. Monitoring dashboards moeten worden ontworpen met input van zowel technische teams als compliance officers om ervoor te zorgen dat alle relevante aspecten worden gedekt. Training van het monitoring team is essentieel om effectief gebruik te maken van de beschikbare tools en om incidenten snel te kunnen escaleren wanneer dit nodig is. Monitoring configuraties moeten worden geüpdatet wanneer nieuwe bedreigingen worden geïdentificeerd, wanneer compliance vereisten veranderen, of wanneer nieuwe Azure services worden geïntegreerd met Customer-beheerde Keys. Regelmatige reviews van monitoring effectiviteit helpen organisaties om te verifiëren dat alle kritieke aspecten worden gemonitord en dat alerts correct worden geconfigureerd om echte bedreigingen te detecteren zonder te veel false positives te genereren.

Implementatie

De implementatie van Customer-beheerde Keys vereist een gestructureerde aanpak waarbij elke Azure resource type specifieke configuratiestappen heeft. Organisaties moeten beginnen met het opzetten van een dedicated Key Vault per omgeving (ontwikkeling, test, productie) met passende op rollen gebaseerde toegangscontrole (RBAC) en beveiligingsinstellingen zoals Soft Delete en Purge bescherming ingeschakeld. De implementatie volgt typisch een fasering waarbij eerst niet-kritieke resources worden geconfigureerd, gevolgd door een geleidelijke uitrol naar productie workloads. Deze gefaseerde aanpak stelt organisaties in staat om ervaring op te doen met CMK configuratie en om eventuele problemen te identificeren en op te lossen voordat kritieke productiesystemen worden gemigreerd. Tijdens elke fase moeten organisaties uitgebreide tests uitvoeren om te verifiëren dat versleuteling en ontsleuteling correct werken en dat er geen prestatieproblemen zijn ontstaan.

Voor Azure opslagaccounts wordt Customer-beheerde Keys geconfigureerd tijdens het aanmaken van een nieuw storage account of door een bestaand account bij te werken. Het PowerShell commando New-AzStorageAccount met de parameters -EncryptionKeyVault en -KeyVaultKeyName maakt het mogelijk om een opslagaccount te creëren dat gebruik maakt van een specifieke sleutel uit Key Vault. Voor bestaande storage accounts kan de Update-AzStorageAccount cmdlet worden gebruikt, hoewel dit zorgvuldig moet worden gepland omdat er mogelijk korte momenten van service interruption kunnen optreden tijdens de overgang van Microsoft-beheerde naar customer-beheerde keys. Organisaties moeten ervoor zorgen dat het storage account een Managed Identity heeft die toegang heeft tot de Key Vault, en dat deze identiteit de juiste machtigingen heeft op de sleutel. Voor storage accounts met hoge beschikbaarheidsvereisten moet de migratie worden uitgevoerd tijdens geplande onderhoudsvensters, en moeten organisaties overwegen om eerst een test storage account te migreren om het proces te valideren voordat productie accounts worden gemigreerd.

Azure SQL Database ondersteunt Customer-beheerde Keys via Transparent Data Encryption (TDE) met een customer-managed TDE protector. Het configureren hiervan gebeurt met de Set-AzSqlDatabase cmdlet waarbij de parameter -EncryptionProtector wordt ingesteld op CustomerManaged, gevolgd door de referentie naar de Key Vault sleutel. Het is belangrijk op te merken dat deze configuratie op database niveau wordt ingesteld, wat betekent dat organisaties voor elke database in een SQL Server expliciet de CMK configuratie moeten toepassen. Voor SQL Managed Instances is een vergelijkbare aanpak beschikbaar, maar met specifieke overwegingen voor netwerkconnectiviteit naar Key Vault. De SQL Server of Managed Instance moet beschikken over een Managed Identity die toegang heeft tot de Key Vault, en deze identiteit moet de juiste machtigingen hebben op de sleutel. Voor grote omgevingen met honderden databases kan dit proces worden geautomatiseerd via PowerShell scripts of Azure Automation runbooks, wat consistentie en efficiëntie verbetert en menselijke fouten reduceert.

Cosmos DB accounts kunnen worden geconfigureerd met Customer-beheerde Keys via de Update-AzCosmosDBAccount cmdlet waarbij de -KeyVaultKeyUri parameter wordt gebruikt om de URI van de Key Vault sleutel op te geven. Het is cruciaal dat het Cosmos DB account toegang heeft tot de Key Vault via een Managed Identity of service-principal met de juiste machtigingen. Cosmos DB ondersteunt zowel account-level als database-level versleuteling met CMK, afhankelijk van de gebruikte API en service tier. Organisaties moeten ervoor zorgen dat het Cosmos DB account en de Key Vault zich in dezelfde Azure regio bevinden, of dat er voldoende netwerkconnectiviteit is tussen de regio's indien cross-region configuratie wordt gebruikt. Voor Cosmos DB accounts met hoge beschikbaarheidsvereisten moet de configuratie zorgvuldig worden gepland om serviceonderbrekingen te voorkomen, en moeten organisaties overwegen om eerst een test account te configureren om het proces te valideren.

Voor Azure beheerde Disks wordt Customer-beheerde Keys geïmplementeerd via Disk Encryption Sets, die worden gemaakt met de New-AzDiskEncryptionSet cmdlet. Een Disk Encryption Set fungeert als een container die de Key Vault referentie en identiteit bevat die nodig zijn voor het versleutelen en ontsleutelen van disks. Wanneer een nieuwe VM wordt gemaakt met versleutelde managed disks, wordt de Disk Encryption Set gespecificeerd, waardoor alle schijven automatisch worden versleuteld met de customer-beheerde sleutel. Bestaande VMs kunnen worden gemigreerd naar CMK-encrypted disks, maar dit vereist een downtime en herconfiguratie van de VM. Het migratieproces omvat het stoppen van de VM, het loskoppelen van de oude disks, het creëren van nieuwe disks met de Disk Encryption Set, het koppelen van de nieuwe disks aan de VM, en het opnieuw opstarten van de VM. Voor productie workloads moet dit proces zorgvuldig worden gepland tijdens geplande onderhoudsvensters, en moeten organisaties overwegen om eerst een test VM te migreren om het proces te valideren.

Na de initiële configuratie moeten organisaties een automatische sleutelrotatiebeleid implementeren, wat sterk wordt aanbevolen voor alle productie workloads. Automatische rotatie kan worden geïmplementeerd via Azure Automation runbooks of Azure Functions die regelmatig controleren of sleutels moeten worden geroteerd op basis van configuratie-instellingen. Het rotatieproces omvat het creëren van een nieuwe sleutelversie in Key Vault, het bijwerken van de resource configuratie om de nieuwe sleutelversie te gebruiken, en het verifiëren dat alle versleutelingsoperaties succesvol zijn. Oude sleutelversies moeten behouden blijven totdat alle data is gere-encrypted, waarna ze veilig kunnen worden gearchiveerd of verwijderd. Het rotatieproces moet worden gedocumenteerd en getest om te verifiëren dat het correct werkt, en organisaties moeten procedures hebben voor het handmatig roteren van sleutels wanneer automatische rotatie faalt. Monitoring moet worden geconfigureerd om alerts te genereren wanneer rotatie faalt of wanneer sleutels niet op tijd worden geroteerd.

Regelmatig testen van break-glass key recovery scenario's is essentieel om te verzekeren dat de organisatie kan blijven functioneren tijdens noodsituaties. Deze tests moeten minimaal elk kwartaal worden uitgevoerd en moeten simuleren scenario's zoals verlies van credentials, Key Vault onbeschikbaarheid, en herstel van backups. Tijdens deze tests moeten alle betrokken teams deelnemen, inclusief security, operations en disaster recovery teams, om ervoor te zorgen dat procedures duidelijk zijn en effectief werken onder stress. De tests moeten worden gedocumenteerd en alle geïdentificeerde problemen moeten worden opgelost voordat de volgende test wordt uitgevoerd. Organisaties moeten ook overwegen om onverwachte tests uit te voeren om te verifiëren dat teams in staat zijn om effectief te reageren op noodsituaties zonder voorafgaande waarschuwing, wat helpt bij het identificeren van gebieden waar verbetering nodig is.

Documentatie van key ownership en de responsibility matrix is cruciaal voor effectief beheer en compliance. Deze documentatie moet duidelijk beschrijven wie verantwoordelijk is voor verschillende aspecten van sleutelbeheer, inclusief sleutelcreatie, rotatie, back-up, recovery, en incident response. Rollen zoals Key Vault beheerder, Security Officer, Compliance Officer, en Disaster Recovery Lead moeten worden gedefinieerd met duidelijke verantwoordelijkheden. Deze documentatie moet regelmatig worden geüpdatet wanneer teams veranderen of nieuwe vereisten ontstaan, en moet beschikbaar zijn voor zowel operationele teams als auditors. De documentatie moet ook procedures bevatten voor het escaleren van problemen, voor het communiceren van wijzigingen aan betrokken teams, en voor het documenteren van alle sleuteloperaties voor audit doeleinden. Organisaties moeten regelmatig reviews uitvoeren van de documentatie om te verifiëren dat deze up-to-date is en dat alle procedures correct worden gevolgd.

Compliance en auditing

Customer-beheerde Keys spelen een cruciale rol in het voldoen aan verschillende compliance frameworks en regelgeving die van toepassing zijn op Nederlandse organisaties, met name in de publieke sector en gereguleerde industrieën. De implementatie van CMK biedt organisaties de mogelijkheid om te voldoen aan strikte vereisten voor datasobereiniteit, cryptografische beveiliging, en auditabiliteit die vaak niet haalbaar zijn met standaard Microsoft-beheerde keys. Door volledige controle over versleutelingssleutels kunnen organisaties aantonen dat ze voldoen aan compliance vereisten die specifiek eisen dat organisaties controle hebben over cryptografische beveiliging, en kunnen ze snel reageren op beveiligingsincidenten door sleutels direct in te trekken wanneer dit nodig is.

ISO 27001:2022 controle A.10.1.2 vereist dat organisaties volledige controle hebben over de levenscyclus van cryptografische sleutels, inclusief sleutelgeneratie, distributie, opslag, rotatie en vernietiging. Customer-beheerde Keys via Azure Key Vault stellen organisaties in staat om aan deze vereisten te voldoen door volledige controle te bieden over alle aspecten van sleutelbeheer. Organisaties kunnen aantonen dat sleutels worden beheerd volgens goedgekeurde procedures, dat sleutelrotatie regelmatig plaatsvindt volgens beleid, en dat alle sleuteloperaties worden geaudit voor compliance doeleinden. De uitgebreide audit logging van Key Vault biedt het bewijs dat nodig is voor ISO 27001 certificering, en stelt organisaties in staat om te demonstreren dat sleutelbeheer voldoet aan alle relevante controles. Organisaties die ISO 27001 gecertificeerd willen worden of blijven, moeten kunnen aantonen dat ze volledige controle hebben over cryptografische sleutels, wat alleen mogelijk is met Customer-beheerde Keys.

De NIS2 richtlijn, die sinds 2023 van kracht is in de Europese Unie, verplicht essentiële en belangrijke entiteiten in bepaalde sectoren om adequate cybersecurity maatregelen te implementeren. Artikel 21 van NIS2 benadrukt het belang van versleuteling en sleutelbeheer controls voor de bescherming van kritieke infrastructuren. Customer-beheerde Keys helpen organisaties die onder NIS2 vallen om te voldoen aan deze vereisten door geavanceerde cryptografische beveiliging te bieden met volledige controle over sleutelbeheer, wat essentieel is voor organisaties die opereren in sectoren zoals energie, transport, financiën, gezondheidszorg, en digitale infrastructuur. Organisaties die onder NIS2 vallen moeten kunnen aantonen dat ze adequate maatregelen hebben genomen om kritieke infrastructuren te beschermen, en Customer-beheerde Keys bieden de controle en auditabiliteit die nodig zijn om aan deze vereisten te voldoen. Voor organisaties in kritieke sectoren is het vaak verplicht om volledige controle te hebben over cryptografische beveiliging, wat alleen mogelijk is met Customer-beheerde Keys.

De Algemene Verordening Gegevensbescherming (AVG/GDPR) Artikel 32 vereist dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beveiligen, inclusief versleuteling. Hoewel AVG niet expliciet customer-beheerde keys vereist, zijn er scenario's waarin datasobereiniteit en de mogelijkheid tot directe sleutelintrekking cruciaal zijn voor AVG-compliance, bijvoorbeeld bij het recht op vergetelheid (Artikel 17). Wanneer een burger zijn recht op vergetelheid uitoefent, moeten organisaties in staat zijn om gegevens permanent te verwijderen, wat vereist dat versleutelingssleutels kunnen worden verwijderd of vernietigd om te voorkomen dat gegevens opnieuw kunnen worden ontsleuteld. Met Customer-beheerde Keys kunnen organisaties direct controle uitoefenen over sleutels en kunnen ze sleutels verwijderen wanneer dit nodig is voor AVG-compliance, wat niet mogelijk is met Microsoft-beheerde keys waar organisaties afhankelijk zijn van Microsoft voor sleutelbeheer. Voor organisaties die werken met gevoelige persoonsgegevens kan de mogelijkheid tot directe sleutelintrekking cruciaal zijn voor het voldoen aan AVG-vereisten.

De BIO (Baseline Informatiebeveiliging Overheid) is het belangrijkste informatiebeveiligingskader voor Nederlandse overheidsorganisaties. Thema 10 van de BIO behandelt cryptografische maatregelen en vereist dat overheidsorganisaties passende cryptografie toepassen voor de bescherming van informatie. Customer-beheerde Keys stellen overheidsorganisaties in staat om te voldoen aan BIO vereisten voor classified informatie, waarbij volledige controle over sleutels vaak expliciet wordt vereist. Voor overheidsorganisaties die werken met gestempelde informatie zijn customer-beheerde keys met HSM-backing vaak verplicht om te voldoen aan strikte beveiligingseisen. De BIO vereist dat overheidsorganisaties kunnen aantonen dat ze volledige controle hebben over cryptografische beveiliging, en Customer-beheerde Keys bieden de controle en auditabiliteit die nodig zijn om aan deze vereisten te voldoen. Voor overheidsorganisaties die werken met zeer gevoelige informatie kan het gebruik van HSM-backed keys verplicht zijn om te voldoen aan strikte beveiligingseisen die worden gesteld door de BIO.

Voor organisaties die betalingstransacties verwerken en onder PCI-DSS vallen, is Requirement 3.6 specifiek van toepassing op sleutelbeheer voor versleuteling van payment card data. PCI-DSS vereist dat sleutelbeheer volledig wordt gedocumenteerd en dat sleutels worden beheerd volgens strikte procedures die minimale toegang, regelmatige rotatie, en veilige vernietiging omvatten. Customer-beheerde Keys via Key Vault met HSM-backing helpen organisaties om te voldoen aan deze vereisten door FIPS 140-2 Level 3 gecertificeerde hardware te gebruiken voor sleutelopslag en door uitgebreide audit logging te bieden die nodig is voor PCI-DSS compliance audits. PCI-DSS vereist dat organisaties kunnen aantonen dat sleutelbeheer voldoet aan strikte beveiligingseisen, en HSM-backed Customer-beheerde Keys bieden het hoogste niveau van beveiliging dat beschikbaar is in Azure. Organisaties die PCI-DSS gecertificeerd willen worden of blijven, moeten kunnen aantonen dat sleutelbeheer voldoet aan alle relevante vereisten, wat alleen mogelijk is met Customer-beheerde Keys en uitgebreide audit logging.

Naast deze specifieke frameworks moeten organisaties ook rekening houden met sector-specifieke regelgeving. Financiële instellingen die onder toezicht staan van De Nederlandsche Bank (DNB) en de Autoriteit Financiële Markten (AFM) moeten vaak voldoen aan aanvullende vereisten voor cryptografische beveiliging. Deze vereisten kunnen specifieke eisen stellen aan sleutelbeheer, zoals het gebruik van HSM-backed keys, regelmatige sleutelrotatie, en uitgebreide audit logging. Zorginstellingen die onder de Wet op de Geneeskundige Behandelingsovereenkomst (WGBO) vallen moeten patiëntgegevens beschermen volgens strikte privacyvereisten, wat kan vereisen dat organisaties volledige controle hebben over versleutelingssleutels om te kunnen voldoen aan privacyvereisten en om snel te kunnen reageren op privacyverzoeken. Customer-beheerde Keys bieden deze organisaties de flexibiliteit en controle die nodig zijn om te voldoen aan sector-specifieke vereisten terwijl ze gebruik maken van clouddiensten, en stellen hen in staat om snel te reageren op veranderende regelgeving en compliance vereisten.

Auditing en compliance rapportage zijn essentieel voor alle genoemde frameworks. Azure Key Vault biedt uitgebreide audit logging die alle sleuteloperaties vastlegt, inclusief wie, wat, wanneer en waarom. Deze logs moeten worden geconfigureerd voor lange-termijn opslag en moeten regelmatig worden geanalyseerd om compliance te verifiëren. Organisaties moeten compliance rapportages kunnen genereren die aantonen dat sleutelbeheer voldoet aan alle relevante vereisten, en deze rapportages moeten beschikbaar zijn voor zowel interne auditors als externe compliance controles. Regelmatige compliance assessments helpen organisaties om voortdurend te voldoen aan veranderende vereisten en om verbeteringen te identificeren in hun sleutelbeheerprocessen. De audit logs moeten worden bewaard voor minimaal de periode die vereist is door compliance frameworks, wat vaak zeven jaar of langer kan zijn voor financiële en overheidsorganisaties. Organisaties moeten procedures hebben voor het analyseren van audit logs, voor het identificeren van compliance problemen, en voor het rapporteren van compliance status aan management en auditors.

Remediatie

Gebruik PowerShell-script encryption-cmk.ps1 (functie Invoke-Remediation) – Herstellen.

Het implementeren van Customer-beheerde Keys in een bestaande Azure omgeving die momenteel gebruik maakt van Microsoft-beheerde Keys vereist een zorgvuldige en gestructureerde aanpak om serviceonderbrekingen te minimaliseren en de integriteit van versleutelde data te waarborgen. De remediatieproces begint met een grondige inventarisatie van alle Azure resources die momenteel gebruik maken van versleuteling, inclusief storage accounts, SQL databases, Cosmos DB accounts, en beheerde disks. Voor elk resource type moeten organisaties de specifieke stappen volgen die nodig zijn om de overgang van Microsoft-beheerde naar customer-beheerde keys te voltooien, waarbij rekening moet worden gehouden met de unieke karakteristieken en vereisten van elk resource type. Deze inventarisatie moet niet alleen identificeren welke resources versleuteling gebruiken, maar ook de kritiekheid van elke resource, de beschikbaarheidsvereisten, en de impact van mogelijke serviceonderbrekingen tijdens de migratie. Organisaties moeten een prioriteringsplan ontwikkelen dat bepaalt welke resources eerst worden gemigreerd, waarbij typisch wordt begonnen met niet-kritieke resources om ervaring op te doen voordat kritieke productiesystemen worden gemigreerd.

De eerste stap in het remediatieproces is het opzetten van een dedicated Azure Key Vault die voldoet aan alle beveiligingsvereisten. Dit omvat het creëren van een nieuwe Key Vault in de juiste Azure regio, het inschakelen van Soft Delete en Purge bescherming, en het configureren van passende netwerktoegangsbeperkingen via Key Vault firewall regels en private endpoints indien nodig. De Key Vault moet worden geconfigureerd met op rollen gebaseerde toegangscontrole (RBAC) waarbij alleen geautoriseerde personen toegang hebben tot sleutelbeheeroperaties. Het is essentieel dat deze Key Vault wordt opgezet voordat de overgang naar Customer-beheerde Keys wordt gestart, omdat alle resources tijdens de remediatie toegang moeten hebben tot deze Key Vault. Organisaties moeten ervoor zorgen dat de Key Vault wordt geconfigureerd in de juiste Azure regio om latencies te minimaliseren en om te voldoen aan dataregionaliteit vereisten. De Key Vault moet ook worden geconfigureerd met passende netwerkbeveiliging, zoals firewall regels die alleen toegang toestaan van geautoriseerde IP-adressen of via private endpoints voor extra beveiliging.

Voor Azure Storage Accounts begint het remediatieproces met het creëren van een nieuwe versleutelingssleutel in de Key Vault. Deze sleutel moet worden geconfigureerd met de juiste machtigingen voor de Storage Account service-principal, waarbij minimaal de machtigingen Get, Unwrap Key, en Wrap Key moeten worden toegekend. Vervolgens kan de Update-AzStorageAccount cmdlet worden gebruikt om het storage account te configureren voor gebruik van de customer-beheerde sleutel. Het is belangrijk om te begrijpen dat deze operatie asynchroon kan zijn en dat er mogelijk korte momenten van verminderde beschikbaarheid kunnen optreden tijdens de overgang. Voor productie workloads wordt sterk aanbevolen om deze operatie uit te voeren tijdens geplande onderhoudsvensters, en om eerst te testen op niet-kritieke storage accounts voordat productie workloads worden gemigreerd. Organisaties moeten ervoor zorgen dat het storage account een Managed Identity heeft die toegang heeft tot de Key Vault, en dat deze identiteit de juiste machtigingen heeft op de sleutel voordat de migratie wordt gestart. Tijdens de migratie moeten organisaties monitoring implementeren om te verifiëren dat alle operaties succesvol zijn en dat er geen onverwachte problemen optreden.

Azure SQL Database remediatie vereist een specifieke aanpak waarbij Transparent Data Encryption (TDE) wordt geconfigureerd met een customer-managed TDE protector. Het proces begint met het creëren van een asymmetrische sleutel in Key Vault die zal fungeren als de TDE protector. Vervolgens moet de SQL Server worden geconfigureerd met een Managed Identity of service-principal die toegang heeft tot de Key Vault, en deze identiteit moet de juiste machtigingen hebben op de Key Vault sleutel. De Set-AzSqlDatabase cmdlet wordt gebruikt om de database te configureren voor gebruik van de customer-managed TDE protector. Het is cruciaal om te begrijpen dat deze configuratie op database niveau wordt ingesteld, wat betekent dat organisaties voor elke database in een SQL Server expliciet de remediatie moeten uitvoeren. Voor grote omgevingen met honderden databases kan dit proces worden geautomatiseerd via PowerShell scripts of Azure Automation runbooks, wat consistentie en efficiëntie verbetert en menselijke fouten reduceert. Organisaties moeten ervoor zorgen dat alle databases worden gemigreerd en dat er geen databases overblijven die nog steeds gebruik maken van Microsoft-beheerde keys, wat compliance problemen kan veroorzaken.

Cosmos DB accounts kunnen worden gemigreerd naar Customer-beheerde Keys door gebruik te maken van de Update-AzCosmosDBAccount cmdlet waarbij de KeyVaultKeyUri parameter wordt gebruikt. Het Cosmos DB account moet beschikken over een Managed Identity die toegang heeft tot de Key Vault, en deze identiteit moet de juiste machtigingen hebben op de sleutel. Het is belangrijk om te verifiëren dat het Cosmos DB account en de Key Vault zich in dezelfde Azure regio bevinden, of dat er voldoende netwerkconnectiviteit is tussen de regio's indien cross-region configuratie wordt gebruikt. Voor Cosmos DB accounts met hoge beschikbaarheidsvereisten moet de remediatie zorgvuldig worden gepland om serviceonderbrekingen te voorkomen. Organisaties moeten ervoor zorgen dat de Managed Identity correct is geconfigureerd voordat de migratie wordt gestart, en moeten monitoring implementeren om te verifiëren dat alle operaties succesvol zijn. Voor Cosmos DB accounts met meerdere regio's moet de configuratie worden uitgevoerd voor alle regio's om consistentie te waarborgen.

Voor Azure beheerde Disks is de remediatie complexer omdat bestaande VMs niet direct kunnen worden gemigreerd naar customer-beheerde keys zonder downtime. Het proces vereist het creëren van een Disk Encryption Set die verwijst naar de Key Vault sleutel, gevolgd door het creëren van nieuwe versleutelde managed disks met deze Disk Encryption Set. Bestaande VMs moeten worden gestopt, de oude disks moeten worden losgekoppeld, nieuwe disks met customer-beheerde keys moeten worden gekoppeld, en de VM moet opnieuw worden gestart. Dit proces vereist aanzienlijke downtime en moet zorgvuldig worden gepland. Voor productie workloads wordt vaak gekozen voor een geleidelijke migratie waarbij nieuwe VMs direct worden geconfigureerd met customer-beheerde keys, terwijl bestaande VMs worden gemigreerd tijdens geplande onderhoudsvensters of wanneer VMs toch al moeten worden bijgewerkt of vervangen. Organisaties moeten ervoor zorgen dat alle data correct wordt gemigreerd naar de nieuwe disks en dat er geen data verloren gaat tijdens het migratieproces. Voor VMs met kritieke workloads moet het migratieproces worden getest op niet-kritieke VMs voordat productie VMs worden gemigreerd.

Na de initiële configuratie van Customer-beheerde Keys moeten organisaties een automatische sleutelrotatiebeleid implementeren. Dit kan worden gedaan via Azure Automation runbooks of Azure Functions die regelmatig controleren of sleutels moeten worden geroteerd op basis van configuratie-instellingen, typisch elke 90 dagen. Het rotatieproces omvat het creëren van een nieuwe sleutelversie in Key Vault, het bijwerken van de resource configuratie om de nieuwe sleutelversie te gebruiken, en het verifiëren dat alle versleutelingsoperaties succesvol zijn. Oude sleutelversies moeten behouden blijven totdat alle data is gere-encrypted met de nieuwe sleutel, waarna ze veilig kunnen worden gearchiveerd of verwijderd volgens het organisatiebeleid. Het rotatieproces moet worden gedocumenteerd en getest om te verifiëren dat het correct werkt, en organisaties moeten procedures hebben voor het handmatig roteren van sleutels wanneer automatische rotatie faalt. Monitoring moet worden geconfigureerd om alerts te genereren wanneer rotatie faalt of wanneer sleutels niet op tijd worden geroteerd, wat kan wijzen op problemen met het rotatieproces of op compliance problemen.

Tijdens het gehele remediatieproces is uitgebreide monitoring essentieel om te verifiëren dat alle operaties succesvol zijn en dat er geen onverwachte problemen optreden. Organisaties moeten Key Vault diagnostische logboeken inschakelen en doorgestuurd naar Azure Monitor Log Analytics voor gedetailleerde analyse. Alerts moeten worden geconfigureerd voor scenario's zoals mislukte sleuteloperaties, toegangsproblemen, en ongebruikelijke activiteiten. Na voltooiing van de remediatie moeten organisaties uitgebreide tests uitvoeren om te verifiëren dat alle resources correct functioneren met customer-beheerde keys, dat versleuteling en ontsleuteling correct werken, en dat er geen prestatieproblemen zijn ontstaan. Documentatie van het gehele remediatieproces is cruciaal voor toekomstige referentie en voor compliance doeleinden. Deze documentatie moet alle stappen bevatten die zijn genomen tijdens de remediatie, alle configuraties die zijn toegepast, en alle problemen die zijn opgetreden en hoe deze zijn opgelost. De documentatie moet regelmatig worden geüpdatet wanneer nieuwe resources worden gemigreerd of wanneer configuraties worden gewijzigd, en moet beschikbaar zijn voor zowel operationele teams als auditors.

Compliance & Frameworks

• BIO: 10.01.01, 10.01.02 - BIO Baseline Informatiebeveiliging Overheid - Thema 10: Cryptografische maatregelen - Customer-beheerde keys voor verbeterde controle
• ISO 27001:2022: A.10.1.2 - Sleutelbeheer - volledige levenscyclus controle over versleutelingssleutels
• NIS2: Artikel - Cybersecurity risicobeheer - versleuteling en sleutelbeheer controles

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).

Risico zonder implementatie

Management Samenvatting

Customer-Managed Keys (CMK) via Key Vault biedt: volledige sleutelcontrole inclusief creëren, roteren en intrekken van sleutels, noodintrekking van sleutels, complete auditlogboeken, en datasobereiniteit door sleutels op te slaan in Nederland of de EU. CMK is vereist voor: financiële instellingen onder DNB en AFM, zorginstellingen met patiëntgegevens, en overheidsorganisaties met classified informatie. De implementatie neemt 8 tot 12 uur in beslag. De kosten bestaan uit minimaal Key Vault operations. Voor standaard business workloads is CMK optioneel, waarbij Microsoft-beheerde keys voldoende zijn.

• Implementatietijd: 12 uur
• FTE required: 0.15 FTE