Azure Databricks: Customer-Managed Key Versleuteling Inschakelen

Azure Databricks bevat vaak zeer gevoelige gegevens zoals persoonsgegevens (PII), financiële informatie of gezondheidszorgdata. Standaard maakt Databricks gebruik van Microsoft-Managed Keys voor versleuteling, waarbij organisaties geen controle hebben over de levenscyclus van deze versleutelingssleutels. Voor veel compliance-frameworks en gereguleerde sectoren is echter vereist dat organisaties volledige controle hebben over hun versleutelingssleutels. Dit omvat: eigen sleutelbeheer en -eigenaarschap, controle over sleutelrotatie en levenscyclus, de mogelijkheid om toegang tot gegevens direct in te trekken door sleutels te revoeren, een volledige audittrail van alle sleuteloperaties, en data sovereignty waarbij sleutels binnen de eigen geografische regio blijven. Zonder CMK is uw organisatie afhankelijk van Microsoft's sleutelbeheer, ontbreekt de mogelijkheid voor noodintrekking van sleutels bij beveiligingsincidenten, is audit logging beperkt, en ontstaan er potentiële compliance-hiaten voor gereguleerde gegevens. Voor organisaties in de financiële sector, gezondheidszorg of overheidsdiensten is CMK daarom vaak een absolute vereiste.

Implementatie

Deze maatregel implementeert Customer-Managed Key versleuteling voor Azure Databricks workspaces. De implementatie omvat verschillende kritieke stappen: het aanmaken van een Azure Key Vault met Soft Delete en Purge Protection ingeschakeld om onbedoeld verlies van sleutels te voorkomen, het creëren van een versleutelingssleutel binnen deze Key Vault, het toekennen van de benodigde machtigingen aan de Databricks service principal voor toegang tot de Key Vault (inclusief Get, Wrap en Unwrap permissions), het configureren van de Databricks workspace met CMK tijdens het initiële aanmaken (let op: dit kan later niet meer worden gewijzigd, bestaande workspaces moeten volledig opnieuw worden aangemaakt), het optioneel inschakelen van een separate CMK voor het Databricks File System (DBFS) voor extra beveiliging, en het implementeren van een geautomatiseerd sleutelrotatieproces met een aanbevolen frequentie van elke 90 dagen. Belangrijke aandachtspunten zijn dat deze functionaliteit alleen beschikbaar is op de Azure Databricks Premium tier en dat er kosten zijn verbonden aan Key Vault-operaties van circa €0,025 per 10.000 operaties.

Vereisten

Voordat u Customer-Managed Key versleuteling implementeert voor Azure Databricks, moet u ervoor zorgen dat uw organisatie beschikt over de juiste infrastructuur, licenties en processen. Deze vereisten zijn essentieel voor een succesvolle implementatie en om te voldoen aan compliance-standaarden en beveiligingsbest practices.

De primaire technische vereiste is een Azure Databricks workspace op het Premium tier. Customer-Managed Key versleuteling is uitsluitend beschikbaar op de Premium tier en kan niet worden geconfigureerd op de Standard tier. Dit betekent dat organisaties die momenteel gebruikmaken van de Standard tier moeten upgraden naar Premium voordat CMK kan worden geïmplementeerd. De Premium tier biedt naast CMK ook aanvullende beveiligings- en governance-functies zoals audit logging, advanced networking opties en enhanced compliance capabilities, waardoor de upgrade vaak een logische stap is voor organisaties met gevoelige data.

Een tweede kritieke vereiste is de aanwezigheid van een Azure Key Vault met specifieke beveiligingsfuncties ingeschakeld. De Key Vault moet Soft Delete hebben ingeschakeld met een retentieperiode van minimaal 90 dagen. Soft Delete voorkomt dat versleutelingssleutels permanent verloren gaan wanneer ze per ongeluk worden verwijderd, wat cruciaal is voor disaster recovery scenario's. Daarnaast moet Purge Protection zijn ingeschakeld, wat voorkomt dat zelfs beheerders met volledige rechten sleutels permanent kunnen verwijderen binnen de retentieperiode. Zonder deze bescherming zou een gecompromitteerd beheerdersaccount kunnen leiden tot permanent verlies van alle versleutelde data, wat catastrofaal zou zijn voor de organisatie.

De Azure Databricks service principal heeft specifieke machtigingen nodig op de Key Vault om versleutelingssleutels te kunnen gebruiken. Deze service principal moet de volgende Key Vault permissions hebben: Get (om sleutelmetadata op te halen), WrapKey (om data encryption keys te versleutelen) en UnwrapKey (om data encryption keys te ontsleutelen). Deze machtigingen kunnen worden toegekend via traditionele Key Vault access policies of via moderne Azure RBAC-rollen zoals 'Key Vault Crypto Service Encryption User'. Het is belangrijk om het principe van least privilege toe te passen en alleen de minimaal benodigde machtigingen te verlenen.

Organisaties moeten een gestructureerd sleutelrotatieproces implementeren waarbij versleutelingssleutels regelmatig worden vervangen. Microsoft en beveiligingsexperts raden aan om sleutelrotatie minimaal elke 90 dagen uit te voeren, hoewel sommige organisaties met zeer gevoelige data of specifieke compliance-vereisten een frequentere rotatie kunnen vereisen. Het rotatieproces moet geautomatiseerd worden via Azure Automation runbooks of Logic Apps om menselijke fouten te voorkomen en consistentie te waarborgen. Daarnaast moet er een validatieproces zijn dat verifieert dat de nieuwe sleutelversie correct wordt gebruikt door de Databricks workspace.

Een uitgebreide backup- en disaster recovery strategie voor sleutels is essentieel om te garanderen dat versleutelde data kan worden hersteld in geval van ongelukken of beveiligingsincidenten. Hoewel de versleutelingssleutels zelf niet kunnen worden geëxporteerd uit Azure Key Vault (dit is by design voor beveiliging), moeten organisaties wel key identifiers, Key Vault configuraties, access policies en service principal mappings documenteren en backuppen. Deze informatie is cruciaal voor disaster recovery scenario's waarbij een Key Vault moet worden hersteld of gereconstrueerd.

Ten slotte moet er een break-glass procedure zijn voor noodsituaties waarbij normale toegang tot de Key Vault is geblokkeerd of verloren. Deze procedure moet gedocumenteerde emergency access accounts bevatten met volledige Key Vault-machtigingen, waarvan de credentials veilig worden bewaard in een fysieke kluis of een apart secret management systeem. Deze break-glass accounts moeten regelmatig worden getest om te verifiëren dat ze nog steeds toegang hebben, en alle gebruik van deze accounts moet worden geaudit via Azure AD sign-in logs. De procedure moet ook escalation-paden bevatten die specificeren wie moet worden gecontacteerd bij key-related incidents en binnen welke tijdsframes respons moet plaatsvinden.

Implementatie

Gebruik PowerShell-script databricks-cmk-encryption.ps1 (functie Invoke-Remediation) – Automatiseert CMK-configuratie voor nieuwe Databricks workspaces en verifieert Key Vault-integratie.

⚠️ **KRITIEKE BEPERKING - LEES DIT EERST**: Customer-Managed Key versleuteling kan UITSLUITEND worden geconfigureerd tijdens het initiële aanmaken van een Azure Databricks workspace. Het is technisch onmogelijk om een bestaande workspace die gebruikmaakt van Microsoft-Managed Keys achteraf te converteren naar CMK. Voor bestaande productie-workspaces betekent dit dat een volledige workspace-recreatie met data-migratie noodzakelijk is, wat zorgvuldige planning (2-4 weken), goedkeuring van business stakeholders, downtime-coördinatie met gebruikers en uitgebreide testing vereist.

**FASE 1: Azure Key Vault Opzetten met Security Hardening (Duur: 2-3 uur)**

De eerste fase van de implementatie richt zich op het opzetten van een beveiligde Azure Key Vault die voldoet aan alle beveiligings- en compliance-vereisten. Begin met het creëren van een nieuwe Azure Key Vault in dezelfde Azure-regio als de Databricks workspace. Deze regionale co-locatie is essentieel om lage latency te garanderen voor key operations en om te voldoen aan data residency-vereisten die kunnen gelden voor gevoelige gegevens. Gebruik een consistente naming convention zoals 'kv-databricks-prod-westeu' om duidelijkheid te creëren over het doel en de omgeving van de Key Vault.

Soft Delete moet worden ingeschakeld met een retentieperiode van minimaal 90 dagen. Deze functie voorkomt permanent dataverlies wanneer sleutels per ongeluk worden verwijderd, wat cruciaal is voor disaster recovery scenario's. Wanneer een sleutel wordt verwijderd, blijft deze gedurende de retentieperiode beschikbaar voor herstel, waardoor organisaties de tijd hebben om onbedoelde verwijderingen te detecteren en ongedaan te maken. Soft Delete is verplicht voor alle CMK-scenario's en kan niet worden uitgeschakeld nadat de Key Vault is aangemaakt.

Purge Protection is een aanvullende beveiligingslaag die voorkomt dat zelfs beheerders met volledige rechten sleutels permanent kunnen verwijderen binnen de retentieperiode. Zonder Purge Protection zou een gecompromitteerd beheerdersaccount kunnen leiden tot permanent verlies van alle versleutelingssleutels, wat catastrofaal zou zijn omdat alle versleutelde data onbruikbaar zou worden. Met Purge Protection kunnen verwijderde sleutels alleen worden hersteld, niet permanent worden gewist, totdat de retentieperiode is verstreken.

Netwerktoegangsbeperkingen moeten worden geconfigureerd om de Key Vault te beschermen tegen onbevoegde toegang. Schakel 'Allow trusted Microsoft services' in om ervoor te zorgen dat Azure Databricks toegang heeft tot de Key Vault. Voor organisaties met strikte netwerkisolatie-vereisten kunnen Private Endpoints worden geïmplementeerd, waardoor de Key Vault alleen toegankelijk is via privénetwerken. Alternatief kunnen IP-based firewall rules worden geconfigureerd die alleen toegang verlenen aan vertrouwde Azure-services en beheerderswerkstations met bekende IP-adressen.

Azure Key Vault diagnostic logging moet worden ingeschakeld en geconfigureerd om alle logboeken te streamen naar een Log Analytics workspace. Deze audit trails zijn essentieel voor compliance-doeleinden en beveiligingsmonitoring. De logs bevatten informatie over alle key operations inclusief Get-operaties (het ophalen van sleutelmetadata), WrapKey-operaties (het versleutelen van data encryption keys), UnwrapKey-operaties (het ontsleutelen van data encryption keys) en alle delete-pogingen. Deze logs moeten minimaal 7 jaar worden bewaard voor compliance met frameworks zoals AVG en ISO 27001.

Azure Key Vault access policies moeten worden geïmplementeerd volgens het principe van least privilege. Alleen de Databricks service principal moet de specifieke permissions krijgen die nodig zijn voor normale operaties: Get, WrapKey en UnwrapKey. Key administrators moeten Create, Update en Rotate permissions krijgen voor sleutelbeheer, maar geen toegang tot de daadwerkelijke sleutelwaarden. Emergency break-glass accounts moeten volledige permissions hebben maar mogen alleen worden gebruikt tijdens beveiligingsincidenten, waarbij alle gebruik wordt geaudit en gedocumenteerd.

**FASE 2: Encryption Key Creatie en Configuratie (Duur: 1 uur)**

In de tweede fase worden de daadwerkelijke versleutelingssleutels aangemaakt en geconfigureerd binnen de Key Vault. Begin met het creëren van een nieuwe RSA-versleutelingssleutel met minimaal 2048-bit key size (RSA-2048). Deze key size biedt voldoende beveiliging voor de meeste use cases en is compatibel met alle Azure-services. Voor organisaties met zeer gevoelige data zoals financiële informatie of gezondheidszorgdata in high-security scenario's, wordt aanbevolen om RSA-4096 te gebruiken voor toekomstbestendige encryptie-sterkte die bestand is tegen toekomstige cryptografische aanvallen.

Configureer de key activation date op immediate, wat betekent dat de sleutel direct beschikbaar is voor gebruik zodra deze is aangemaakt. Optioneel kan een expiration date worden ingesteld als uw organisatie een policy heeft die key rotation via expiration afdwingt in plaats van handmatige rotatie. Wanneer een expiration date is ingesteld, zal Azure Key Vault automatisch waarschuwingen genereren wanneer de vervaldatum nadert, wat helpt bij het plannen van sleutelrotatie.

Stel de key permissions in volgens het principe van least privilege. Voor Azure Databricks zijn alleen WrapKey en UnwrapKey permissions vereist. WrapKey wordt gebruikt om data encryption keys te versleutelen voordat ze worden opgeslagen, terwijl UnwrapKey wordt gebruikt om deze keys te ontsleutelen wanneer ze nodig zijn voor data-operaties. Andere key operations zoals Sign, Verify, Encrypt en Decrypt zijn niet nodig voor Databricks CMK-scenario's en moeten worden uitgesloten om het aanvalsoppervlak te minimaliseren.

Documenteer zorgvuldig de Key Vault Resource ID en de Key Name en Version. Deze informatie is vereist tijdens de Databricks workspace deployment en moet nauwkeurig worden ingevoerd. Het formaat van de key URI is: https://.vault.azure.net/keys//. Deze URI wordt gebruikt door Azure Databricks om de versleutelingssleutel te identificeren en er toegang toe te krijgen. Zorg ervoor dat deze informatie wordt opgeslagen in een beveiligde documentatie repository en alleen toegankelijk is voor geautoriseerd personeel.

Optioneel kunt u een tweede versleutelingssleutel creëren specifiek voor het Databricks File System (DBFS). Deze separate key isolation biedt defense-in-depth beveiliging waarbij een compromittering van één sleutel niet beide data stores blootstelt. De workspace managed storage (waar notebooks, clusterconfiguraties en metadata worden opgeslagen) gebruikt de primaire CMK, terwijl user-uploaded files in DBFS een separate sleutel gebruiken. Deze aanpak wordt aanbevolen voor high-security workloads waar extra isolatie tussen verschillende data types gewenst is.

**FASE 3: Databricks Service Principal Permissions (Duur: 30 minuten)**

De derde fase richt zich op het configureren van de juiste machtigingen voor de Azure Databricks service principal zodat deze toegang heeft tot de versleutelingssleutels in de Key Vault. Begin met het identificeren van de Azure Databricks service principal Object ID voor uw specifieke Azure-regio. Deze Object ID is region-specifiek en verschilt per Azure-regio. Voor West Europe heeft de service principal bijvoorbeeld een andere Object ID dan voor East US. Deze Object IDs zijn gedocumenteerd in de Microsoft Learn-documentatie en moeten nauwkeurig worden gebruikt om ervoor te zorgen dat de juiste service principal toegang krijgt.

Ken via Key Vault Access Policies de volgende permissions toe aan de Databricks service principal. De Key Permissions die nodig zijn zijn: Get (om sleutelmetadata op te halen), Wrap Key (om data encryption keys te versleutelen voordat ze worden opgeslagen) en Unwrap Key (om data encryption keys te ontsleutelen wanneer ze nodig zijn voor data-operaties). Het is cruciaal dat alle andere permissions worden uitgesloten volgens het principe van least privilege. Permissions zoals Sign, Verify, Encrypt, Decrypt, Delete of Backup zijn niet nodig voor Databricks CMK-operaties en moeten expliciet worden geweigerd.

Een alternatieve en modernere aanpak is het gebruik van Azure RBAC voor Key Vault in plaats van traditionele access policies. Met Azure RBAC kunt u de rol 'Key Vault Crypto Service Encryption User' toewijzen aan de Databricks service principal op het scope van de specifieke encryption key. Deze aanpak biedt meer granulariteit dan access policies omdat u permissions kunt toekennen op key-niveau in plaats van op Key Vault-niveau. Dit betekent dat de service principal alleen toegang heeft tot de specifieke sleutel die nodig is voor Databricks, en niet tot andere sleutels in dezelfde Key Vault.

Test de geconfigureerde permissions door een test key operation uit te voeren via Azure CLI. Gebruik de opdracht 'az keyvault key show' met de service principal credentials om te verifiëren dat de service principal de sleutel kan ophalen. Als deze test faalt met een authorization error, betekent dit dat de permissions incorrect zijn geconfigureerd en dat de Databricks workspace deployment zal falen wanneer CMK wordt geconfigureerd. Het is essentieel om deze test uit te voeren voordat u doorgaat naar de volgende fase, omdat het corrigeren van permission-problemen na workspace deployment veel complexer is.

**FASE 4: Databricks Workspace Deployment met CMK (Duur: 2-4 uur voor nieuwe workspace, 20-40 uur voor migratie)**

De vierde fase omvat de daadwerkelijke deployment van de Databricks workspace met Customer-Managed Key versleuteling. Voor nieuwe workspaces start u het aanmaakproces via de Azure Portal door te navigeren naar Create Resource, Azure Databricks te selecteren en door de configuratiewizard te gaan. Tijdens de 'Encryption' configuratie-tab selecteert u 'Customer-managed keys' in plaats van de standaard Microsoft-managed keys. Voer vervolgens de Key Vault URI en Key Name in die u in Fase 2 heeft gedocumenteerd. Het is belangrijk om deze informatie nauwkeurig in te voeren, omdat een typefout zal leiden tot een mislukte deployment.

Voor Managed Services encryption, die de workspace storage, notebooks en clusterconfiguraties beschermt, specificeert u de primaire versleutelingssleutel die u in Fase 2 heeft aangemaakt. Deze sleutel wordt gebruikt om alle door de workspace beheerde data te versleutelen, inclusief notebook-bestanden, clusterconfiguraties, job definitions en metadata. Deze versleuteling gebeurt transparant voor gebruikers, maar biedt volledige controle over de versleutelingssleutels aan de organisatie.

Optioneel kunt u voor DBFS encryption een separate sleutel configureren door 'Enable customer-managed key for DBFS' te selecteren en de tweede sleutel te specificeren die u in Fase 2 heeft aangemaakt. Deze configuratie wordt aanbevolen voor high-security workloads waar extra isolatie gewenst is tussen workspace-managed storage en user-uploaded files. Wanneer deze optie is ingeschakeld, worden bestanden die gebruikers uploaden naar DBFS versleuteld met een andere sleutel dan de workspace-managed data, wat defense-in-depth beveiliging biedt.

Tijdens het deployment-proces valideert Azure automatisch of de Key Vault permissions correct zijn geconfigureerd. Als de Databricks service principal geen toegang heeft tot de sleutel, zal de deployment falen met een duidelijke error message die aangeeft dat de service principal niet geautoriseerd is. In dit geval moet u terugkeren naar Fase 3 om de permissions te corrigeren voordat u opnieuw probeert de workspace aan te maken. Het is daarom essentieel om de permission-tests uit Fase 3 zorgvuldig uit te voeren voordat u begint met de workspace deployment.

Voor bestaande workspaces die moeten migreren naar CMK is een uitgebreider proces vereist, omdat CMK alleen kan worden geconfigureerd tijdens workspace creation. Plan eerst een maintenance window van 4-8 uur, afhankelijk van het data volume en de complexiteit van de workloads. Exporteer alle notebooks via de Databricks CLI of Git-integratie om ervoor te zorgen dat geen werk verloren gaat. Documenteer alle job definitions, clusterconfiguraties, geïnstalleerde libraries en init scripts, zodat deze kunnen worden gereproduceerd in de nieuwe workspace.

Maak vervolgens de nieuwe CMK-enabled workspace aan volgens de stappen hierboven beschreven. Importeer alle notebooks en configuraties naar de nieuwe workspace en migreer data via geautomatiseerde copy jobs of Azure Data Factory pipelines. Voer uitgebreide tests uit van alle jobs en notebooks om te verifiëren dat alles correct functioneert in de nieuwe omgeving. Voer een parallel run uit waarbij beide workspaces tijdelijk operationeel zijn, zodat gebruikers kunnen valideren dat de nieuwe workspace correct werkt voordat de cutover plaatsvindt.

Na validatie kunnen gebruikers worden overgezet naar de nieuwe workspace. De oude workspace moet worden behouden voor een retention period van minimaal 30 dagen om ervoor te zorgen dat alle data correct is gemigreerd en dat er geen kritieke informatie verloren is gegaan. Na deze periode kan de oude workspace worden gedecommissioneerd, maar alleen na een laatste verificatie dat alle data succesvol is gemigreerd.

Na de deployment moet u de encryptie-status verifiëren via de Azure Portal door te navigeren naar de Databricks workspace en de Encryption settings te bekijken. Hier moet 'Customer-managed key' worden getoond samen met de Key Vault details, inclusief de Key Vault naam, sleutelnaam en versie. Deze informatie bevestigt dat CMK correct is geconfigureerd en actief is.

Test ten slotte de data access door een test notebook uit te voeren dat data schrijft naar en leest van DBFS. Deze test verifieert dat de encryption en decryption correct functioneren en dat gebruikers normaal kunnen werken met de versleutelde data. Als deze test succesvol is, betekent dit dat de CMK-implementatie correct is voltooid en dat de workspace klaar is voor productiegebruik.

**FASE 5: Key Rotation Automation Implementeren (Duur: 2-3 uur)**

De vijfde fase richt zich op het implementeren van geautomatiseerde sleutelrotatie om ervoor te zorgen dat versleutelingssleutels regelmatig worden vervangen volgens security best practices. Implementeer een Azure Automation runbook of Logic App die elke 90 dagen automatisch een nieuwe key version creëert in de Key Vault. Azure Key Vault's key versioning feature maakt het mogelijk om nieuwe versions aan te maken terwijl oude versions behouden blijven, wat essentieel is voor een naadloze rotatie zonder service-onderbreking.

Azure Databricks detecteert automatisch nieuwe key versions en begint deze te gebruiken voor nieuwe encryption operations zonder dat workspace reconfiguratie nodig is. Dit betekent dat de rotatie transparant is voor gebruikers en dat er geen downtime optreedt. Bestaande versleutelde data blijft versleuteld met de oude key versions, terwijl nieuwe data wordt versleuteld met de nieuwe key version. Azure Key Vault ondersteunt meerdere actieve key versions simultaan, waardoor deze aanpak mogelijk is zonder dataverlies of service-onderbreking.

Configureer Azure Monitor alert rules die 14 dagen vóór de geplande rotatiedatum een email sturen naar key administrators als reminder voor een handmatige review voordat de geautomatiseerde rotatie plaatsvindt. Deze review is belangrijk om te verifiëren dat er geen actieve incidenten zijn, dat alle stakeholders op de hoogte zijn van de rotatie, en dat er geen geplande maintenance-activiteiten zijn die kunnen conflicteren met de rotatie. De alert moet ook informatie bevatten over hoe de rotatie kan worden uitgesteld indien nodig.

Implementeer een post-rotation validation script dat verifieert dat Databricks succesvol de nieuwe key version gebruikt. Dit script moet test data schrijven naar DBFS en vervolgens de encryption key version verifiëren via Key Vault audit logs. De audit logs moeten aantonen dat de nieuwe key version wordt gebruikt voor WrapKey en UnwrapKey operaties. Als de validatie faalt, moet het script een alert genereren zodat key administrators onmiddellijk kunnen ingrijpen.

Documenteer uitgebreide rollback procedures waarbij u kunt terugkeren naar een vorige key version indien de nieuwe version problemen veroorzaakt. Dit kan gebeuren via de Azure Portal door te navigeren naar Key Vault, Keys, de specifieke Key Name, Versions en vervolgens een vorige version te herstellen als actieve versie. Het is belangrijk om te begrijpen dat rollback alleen mogelijk is binnen de retentieperiode van Soft Delete, en dat alle data die is versleuteld met de nieuwe key version opnieuw moet worden versleuteld met de herstelde key version.

Test het volledige rotation-proces grondig in een non-productie Databricks workspace voordat u het in productie implementeert. Deze testing is essentieel om onverwachte downtime of problemen te voorkomen. Tijdens de test moet u verifiëren dat: de nieuwe key version correct wordt aangemaakt, Databricks de nieuwe version automatisch detecteert en gebruikt, bestaande data toegankelijk blijft, nieuwe data correct wordt versleuteld met de nieuwe key, en het rollback-proces werkt indien nodig. Alleen na succesvolle testing in een testomgeving mag het rotation-proces in productie worden geactiveerd.

**FASE 6: Monitoring, Alerting en Audit Logging (Duur: 2 uur)**

De zesde fase richt zich op het opzetten van uitgebreide monitoring, alerting en audit logging om de beveiliging en compliance van de CMK-implementatie te waarborgen. Begin met het inschakelen van Azure Key Vault diagnostic settings die alle audit logs naar een Log Analytics workspace sturen voor long-term retention en real-time analysis. Deze logs moeten minimaal 7 jaar worden bewaard om te voldoen aan compliance-vereisten van frameworks zoals AVG, ISO 27001 en sectorspecifieke regelgeving. De logs bevatten gedetailleerde informatie over alle key operations inclusief wie, wat, wanneer en waarom, wat essentieel is voor forensisch onderzoek en compliance-audits.

Configureer Azure Monitor alert rules voor kritieke key events die kunnen wijzen op beveiligingsincidenten of operationele problemen. Failed key access attempts moeten worden gemonitord met een threshold van meer dan 5 mislukte pogingen binnen 1 uur, wat kan duiden op permission issues of brute-force aanvallen. Key deletion attempts moeten onmiddellijk een alert genereren, omdat ELKE delete-poging moet worden onderzocht om te verifiëren dat het geen onbevoegde actie is. Abnormal key operation volume, gedefinieerd als een toename van meer dan 1000% in key operations, kan wijzen op data exfiltratie of ransomware-activiteit en vereist onmiddellijke aandacht. Key not found errors zijn kritieke incidenten omdat dit betekent dat de workspace data niet kan ontsleutelen, wat leidt tot service-onderbreking.

Creëer een Azure Monitor workbook dashboard specifiek voor Databricks CMK monitoring met visuele weergaven van belangrijke metrics. Het dashboard moet visualisaties bevatten van key operations per uur, inclusief het volume van WrapKey en UnwrapKey operaties, wat helpt bij het identificeren van normale gebruikspatronen en afwijkingen. De success versus failed operations ratio geeft inzicht in de gezondheid van het systeem en kan vroegtijdig problemen signaleren. Key rotation compliance status toont het aantal dagen sinds de laatste rotatie, wat helpt bij het waarborgen dat rotatie volgens schema plaatsvindt. Key access patterns per service principal helpen bij het identificeren van ongebruikelijke toegangspatronen die kunnen wijzen op beveiligingsincidenten.

Implementeer Azure Security Center recommendations monitoring die automatisch waarschuwt bij Key Vault misconfigurations. Deze monitoring detecteert problemen zoals uitgeschakelde Soft Delete of Purge Protection, onjuiste network access restrictions, ontbrekende diagnostic logging, of access policies die niet voldoen aan best practices. Deze waarschuwingen moeten worden geïntegreerd in uw security operations center (SOC) workflow zodat ze onmiddellijk worden opgepakt en gecorrigeerd.

Plan kwartaalelijk handmatige reviews van Key Vault access policies om ervoor te zorgen dat alleen geautoriseerde service principals en administrators toegang hebben. Tijdens deze reviews moeten orphaned permissions worden opgeruimd (permissions voor service principals of accounts die niet meer bestaan of niet meer worden gebruikt), moet worden geverifieerd dat het principe van least privilege wordt gehandhaafd, en moeten alle wijzigingen sinds de laatste review worden gedocumenteerd. Deze reviews zijn essentieel voor het waarborgen van continue beveiliging en compliance, vooral in dynamische omgevingen waar service principals en accounts regelmatig worden toegevoegd of verwijderd.

**FASE 7: Disaster Recovery en Break-Glass Procedures (Duur: 3 uur voor documentatie en testing)**

De zevende en laatste fase richt zich op het opzetten van uitgebreide disaster recovery procedures en break-glass mechanismen om ervoor te zorgen dat de organisatie kan reageren op noodsituaties waarbij normale toegang tot versleutelingssleutels is geblokkeerd of verloren. Documenteer uitgebreide disaster recovery procedures voor verschillende scenario's. Bij accidental key deletion kan de sleutel worden hersteld via Soft Delete binnen de 90-dagen retentieperiode, waarbij de sleutel wordt teruggezet naar de actieve status via de Azure Portal of Azure CLI. Als de Key Vault zelf is gecompromitteerd, moet onmiddellijk key rotation plaatsvinden naar een nieuwe Key Vault, waarbij alle versleutelde data opnieuw wordt versleuteld met de nieuwe sleutels. Bij een Azure region outage moeten failover procedures worden geactiveerd indien een multi-region setup is geïmplementeerd, waarbij de Key Vault en Databricks workspace in een secundaire regio beschikbaar zijn. Als normale Key Vault toegang verloren is gegaan, moeten break-glass accounts worden geactiveerd om emergency access te verkrijgen.

Implementeer break-glass emergency access accounts die alleen worden gebruikt tijdens noodsituaties. Creëer minimaal 2 dedicated Azure AD accounts (bijvoorbeeld 'breakglass-keyvault-admin-1' en 'breakglass-keyvault-admin-2') die volledige Key Vault permissions hebben. Deze accounts moeten worden beveiligd met sterke wachtwoorden en multi-factor authenticatie, en de credentials moeten encrypted worden bewaard in een fysieke kluis of een apart secret management systeem dat niet afhankelijk is van dezelfde infrastructuur. Test kwartaal of de break-glass accounts nog steeds toegang hebben tot de Key Vault, omdat permissions kunnen veranderen of accounts kunnen worden uitgeschakeld. Alle gebruik van break-glass accounts moet worden geaudit via Azure AD sign-in logs, en elk gebruik moet worden gereviewd en goedgekeurd door security management. Het is essentieel dat deze accounts alleen worden gebruikt tijdens echte noodsituaties en niet voor routine-operaties.

Backup encryption key identifiers in encrypted vorm naar een secure off-site location. Het is belangrijk om te begrijpen dat de encryption keys zelf niet kunnen worden geëxporteerd uit Azure Key Vault - dit is by design voor beveiliging om te voorkomen dat sleutels worden gestolen of misbruikt. Wat wel moet worden gebackupt zijn de key identifiers: Key Vault naam, resource group, subscription ID, key naam, key versions, en de Key Vault URI. Deze informatie is essentieel voor disaster recovery scenario's waarbij een Key Vault moet worden gereconstrueerd of waarbij toegang moet worden hersteld. De backup moet encrypted zijn en opgeslagen op een locatie die fysiek en logisch gescheiden is van de primaire infrastructuur. Overweeg het gebruik van Azure Backup of een vergelijkbare service voor geautomatiseerde backups van deze metadata.

Test jaarlijks het complete disaster recovery proces in een dedicated test-omgeving om ervoor te zorgen dat alle procedures correct werken en dat het personeel bekend is met de stappen. Simuleer verschillende scenario's inclusief Key Vault deletion and recovery via Soft Delete, waarbij u verifieert dat verwijderde sleutels kunnen worden hersteld binnen de retentieperiode. Test service principal permission revocation and restoration om te verifiëren dat toegang kan worden hersteld na een incident. Simuleer emergency key rotation naar een nieuwe Key Vault om te oefenen met het migreren van versleutelde data naar nieuwe sleutels. Test workspace recovery met restored keys om te verifiëren dat een Databricks workspace kan worden hersteld met behulp van back-upped key identifiers. Documenteer alle bevindingen en verbeter de procedures op basis van de lessons learned.

Train minimaal 2 senior cloud architects in emergency key recovery procedures om single points of failure te elimineren. Deze training moet hands-on zijn en moet alle stappen van de disaster recovery procedures omvatten, inclusief het gebruik van break-glass accounts, het herstellen van sleutels, en het uitvoeren van emergency key rotation. De training moet jaarlijks worden opgefrist om ervoor te zorgen dat de kennis up-to-date blijft en dat nieuwe teamleden worden opgeleid. Documenteer alle training sessies en verifieer dat deelnemers de procedures correct kunnen uitvoeren voordat ze worden geautoriseerd om deze procedures in productie uit te voeren. Overweeg het opzetten van een rotation-schema waarbij verschillende teamleden worden getraind om ervoor te zorgen dat er altijd voldoende gekwalificeerd personeel beschikbaar is.

Documenteer uitgebreide escalation procedures die specificeren wie moet worden gecontacteerd bij key-related incidents. Deze procedures moeten 24/7 on-call contacten bevatten voor verschillende severity levels. Severity level S1 (kritiek) wordt gedefinieerd als situaties waarbij de workspace geen toegang heeft tot data vanwege key issues, wat leidt tot complete service-onderbreking. Voor S1-incidents moet er binnen 15 minuten respons zijn van een senior cloud architect of security engineer. Severity level S2 (hoog) wordt gedefinieerd als degraded key performance waarbij de service nog functioneel is maar niet optimaal presteert. Voor S2-incidents moet er binnen 1 uur respons zijn. Severity level S3 (normaal) omvat geplande activiteiten zoals key rotation die via standard change management procedures worden afgehandeld. Communication templates moeten worden voorbereid voor notificaties aan business stakeholders bij key-related downtime, zodat zij tijdig en accuraat worden geïnformeerd over de impact en verwachte resolutietijd. Deze templates moeten worden getest en goedgekeurd door communicatie- en managementteams voordat ze in productie worden gebruikt.

⏱️ **Totale Implementatie-tijd**: 10-16 uur voor nieuwe workspaces (Key Vault setup, key creation, workspace deployment, testing, documentation). Voor migratie van bestaande workspaces: 30-50 uur additional (planning, data export, workspace recreation, data migration, parallel testing, cutover). Ongoing maintenance: 4 uur per jaar voor key rotation en quarterly reviews.

💰 **Kosten**: Azure Key Vault operations circa €0,025 per 10.000 operations. Voor een typische Databricks workspace met moderate usage: €5-15 per maand aan Key Vault costs. Key Vault storage van encryption keys: €0,03 per key per maand (verwaarloosbaar). Databricks Premium tier vereist (€0,55 DBU vs €0,40 Standard) maar CMK is niet de enige reden voor Premium - overweeg alle Premium features in de business case.

Monitoring

Gebruik PowerShell-script databricks-cmk-encryption.ps1 (functie Invoke-Monitoring) – Automatiseert monitoring van CMK-configuratie en sleuteloperaties.

Effectieve monitoring van Customer-Managed Key versleuteling voor Azure Databricks is essentieel om te waarborgen dat versleutelingssleutels correct functioneren, dat beveiligingsincidenten tijdig worden gedetecteerd, en dat compliance-vereisten worden nageleefd. Monitoring omvat het continu volgen van sleuteloperaties, het detecteren van afwijkende patronen die kunnen wijzen op beveiligingsbedreigingen, het verifiëren dat sleutelrotatie op tijd plaatsvindt, en het waarborgen dat alle sleutelgerelateerde activiteiten worden gelogd voor auditdoeleinden. Zonder uitgebreide monitoring kunnen organisaties niet garanderen dat hun versleutelingssleutels veilig zijn en dat ze voldoen aan compliance-vereisten zoals AVG, NIS2 en ISO 27001.

De basis van CMK-monitoring wordt gevormd door Azure Key Vault diagnostische logboeken. Deze logboeken registreren alle operaties die worden uitgevoerd op versleutelingssleutels, inclusief Get-operaties (het ophalen van sleutelmetadata), WrapKey-operaties (het versleutelen van data encryption keys), UnwrapKey-operaties (het ontsleutelen van data encryption keys), en alle pogingen tot sleutelverwijdering. Organisaties moeten deze diagnostische instellingen inschakelen en de logboeken streamen naar een Log Analytics-workspace voor langetermijnretentie en real-time analyse. Voor compliance-doeleinden wordt aanbevolen om logboeken minimaal zeven jaar te bewaren, wat overeenkomt met veel compliance-frameworks zoals AVG en ISO 27001. De logboeken moeten worden geconfigureerd om alle relevante categorieën vast te leggen, waaronder AuditEvent (voor alle sleuteloperaties) en AllMetrics (voor prestatie- en beschikbaarheidsmetrieken).

Azure Monitor waarschuwingsregels moeten worden geconfigureerd om kritieke sleutelgebeurtenissen automatisch te detecteren en te rapporteren. Een van de belangrijkste waarschuwingen is voor mislukte sleuteltoegangspogingen. Wanneer er meer dan vijf mislukte toegangspogingen binnen één uur plaatsvinden, kan dit wijzen op permission-problemen, geautomatiseerde aanvallen, of pogingen tot ongeautoriseerde toegang. Deze waarschuwingen moeten onmiddellijk worden verzonden naar het security operations center en naar key administrators. Een tweede kritieke waarschuwing betreft pogingen tot sleutelverwijdering. Elke poging om een versleutelingssleutel te verwijderen moet onmiddellijk worden gemeld, zelfs als deze wordt geblokkeerd door Soft Delete of Purge Protection. Deze waarschuwingen zijn essentieel voor het detecteren van insider threats of gecompromitteerde administrator-accounts.

Abnormale volumes van sleuteloperaties kunnen wijzen op beveiligingsincidenten zoals data exfiltratie of ransomware-aanvallen. Wanneer het volume van WrapKey- of UnwrapKey-operaties met meer dan 1000 procent toeneemt ten opzichte van het normale baseline-niveau, moet dit worden onderzocht als een potentiële beveiligingsbedreiging. Dergelijke pieken kunnen erop wijzen dat een aanvaller grote hoeveelheden versleutelde data probeert te ontsleutelen of dat er een geautomatiseerd proces actief is dat ongeautoriseerd gebruik maakt van versleutelingssleutels. Waarschuwingsregels moeten worden geconfigureerd om dergelijke afwijkingen te detecteren op basis van statistische analyse van historische data, waarbij rekening wordt gehouden met normale variaties zoals maandelijkse rapportage-cycli of geplande data-migraties.

Key not found-fouten zijn bijzonder kritiek omdat ze betekenen dat de Databricks-workspace geen toegang meer heeft tot de versleutelingssleutels die nodig zijn om data te ontsleutelen. Dit kan gebeuren wanneer sleutels per ongeluk worden verwijderd, wanneer service principal-machtigingen worden ingetrokken, of wanneer er problemen zijn met de Key Vault-beschikbaarheid. Deze fouten moeten worden behandeld als kritieke incidenten die onmiddellijke respons vereisen, omdat ze kunnen resulteren in volledige data-onbeschikbaarheid. Waarschuwingsregels moeten worden geconfigureerd om onmiddellijk te escaleren naar het on-call team wanneer dergelijke fouten worden gedetecteerd, met een doelstelling voor respons binnen 15 minuten.

Organisaties moeten een specifiek Azure Monitor workbook-dashboard creëren voor Databricks CMK-monitoring. Dit dashboard moet visualisaties bevatten van sleuteloperaties per uur, waarbij onderscheid wordt gemaakt tussen WrapKey- en UnwrapKey-operaties. Het dashboard moet ook de verhouding tussen succesvolle en mislukte operaties tonen, wat helpt bij het identificeren van prestatieproblemen of permission-issues. Een belangrijk onderdeel van het dashboard is de sleutelrotatie compliance-status, die het aantal dagen sinds de laatste rotatie toont en waarschuwingen genereert wanneer de rotatie deadline nadert. Het dashboard moet ook sleuteltoegangspatronen per service principal visualiseren, wat helpt bij het detecteren van afwijkend gedrag of ongeautoriseerd gebruik.

Azure Security Center-aanbevelingen moeten worden gemonitord om automatisch te waarschuwen bij Key Vault-misconfiguraties. Security Center detecteert wanneer Soft Delete of Purge Protection is uitgeschakeld, wanneer diagnostische logboeken niet zijn geconfigureerd, of wanneer er onveilige netwerktoegangsregels zijn geconfigureerd. Deze aanbevelingen moeten worden behandeld als hoge prioriteit omdat ze de beveiliging van versleutelingssleutels direct beïnvloeden. Organisaties moeten een proces implementeren waarbij Security Center-aanbevelingen wekelijks worden gereviewd en waarbij alle kritieke bevindingen binnen 48 uur worden opgelost.

Kwartaalreviews van Key Vault-toegangsbeleid zijn essentieel om te waarborgen dat alleen geautoriseerde service principals en administrators toegang hebben tot versleutelingssleutels. Tijdens deze reviews moeten organisaties verifiëren dat alle toegangsbeleid nog steeds geldig zijn, dat orphaned permissions (machtigingen voor service principals die niet meer bestaan) worden opgeruimd, en dat het principe van least privilege wordt gehandhaafd. Deze reviews moeten worden gedocumenteerd en alle wijzigingen moeten worden goedgekeurd door senior management. De reviews moeten ook worden gebruikt om te verifiëren dat break-glass accounts nog steeds toegang hebben en dat alle gebruik van deze accounts is geaudit.

De versleutelingsstatus van de Databricks-workspace moet regelmatig worden geverifieerd via de Azure Portal. Organisaties moeten maandelijks controleren dat de workspace nog steeds is geconfigureerd met Customer-Managed Keys en dat de Key Vault-details correct zijn. Eventuele wijzigingen in de versleutelingsconfiguratie moeten onmiddellijk worden onderzocht, omdat dit kan wijzen op een beveiligingsincident of een onbedoelde configuratiewijziging. Deze verificaties moeten worden gedocumenteerd en moeten deel uitmaken van de reguliere security compliance-checks.

Compliance

Customer-Managed Key versleuteling voor Azure Databricks is essentieel voor het voldoen aan verschillende compliance-frameworks en regelgevingsvereisten die van toepassing zijn op Nederlandse organisaties, met name in de publieke sector en gereguleerde industrieën. Deze maatregel helpt organisaties te voldoen aan vereisten voor data sovereignty, cryptografische beveiliging, en controle over versleutelingssleutels zoals gespecificeerd in internationale standaarden en Nederlandse wetgeving. Zonder CMK kunnen organisaties niet volledig voldoen aan de vereisten van frameworks zoals AVG, NIS2, ISO 27001, CIS Azure, en de BIO-baseline.

De CIS Azure Benchmark controle 2.1.1 vereist dat organisaties gebruikmaken van customer-managed keys voor gegevensversleuteling in plaats van service-managed keys. Deze controle is geclassificeerd als Level 2, wat betekent dat deze wordt aanbevolen voor organisaties met hoge beveiligingsvereisten. De controle specificeert dat organisaties volledige controle moeten hebben over versleutelingssleutels, inclusief de mogelijkheid om sleutels te roteren, te revokeren, en te beheren volgens eigen beleid. Voor Azure Databricks betekent dit dat organisaties CMK moeten implementeren om te voldoen aan deze controle. Het niet implementeren van CMK resulteert in een failed audit finding voor deze controle, wat kan leiden tot compliance-problemen bij klanten of partners die CIS Azure-compliance vereisen.

ISO 27001 controle A.10.1.2 richt zich op cryptografische controles en vereist dat organisaties passende cryptografische maatregelen implementeren om de vertrouwelijkheid, integriteit en authenticiteit van informatie te waarborgen. Deze controle vereist dat organisaties cryptografische sleutels beheren volgens een gedefinieerd beleid, inclusief sleutelgeneratie, distributie, opslag, archivering en vernietiging. Customer-Managed Keys voor Azure Databricks stellen organisaties in staat om te voldoen aan deze vereisten door volledige controle te hebben over de levenscyclus van versleutelingssleutels. Organisaties moeten kunnen aantonen dat ze sleutels beheren volgens hun eigen beleid, dat sleutelrotatie regelmatig plaatsvindt, en dat er procedures zijn voor sleutelherstel en -vernietiging. Zonder CMK kunnen organisaties deze controle niet volledig aantonen omdat Microsoft de controle heeft over de sleutellevenscyclus.

De NIS2-richtlijn, die in Nederland is geïmplementeerd via de Wet beveiliging netwerk- en informatiesystemen, vereist in Artikel 21 dat essentiële en belangrijke entiteiten passende maatregelen implementeren voor versleuteling en sleutelbeheer. Deze vereiste is met name relevant voor organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg, en financiële dienstverlening. Artikel 21 specificeert dat organisaties moeten kunnen aantonen dat ze controle hebben over versleutelingssleutels en dat ze in staat zijn om toegang tot versleutelde data onmiddellijk in te trekken bij beveiligingsincidenten. Customer-Managed Keys voor Azure Databricks stellen organisaties in staat om te voldoen aan deze vereisten door volledige controle te hebben over versleutelingssleutels en door de mogelijkheid te bieden om sleutels onmiddellijk te revokeren. Het niet implementeren van CMK kan resulteren in niet-naleving van NIS2-vereisten, wat kan leiden tot boetes en andere handhavingsmaatregelen door de Autoriteit Consument en Markt (ACM) of andere toezichthouders.

De Algemene Verordening Gegevensbescherming (AVG), ook wel bekend als GDPR, vereist in Artikel 32 dat organisaties passende technische en organisatorische maatregelen implementeren om persoonsgegevens te beveiligen. Voor organisaties die persoonsgegevens verwerken in Azure Databricks, betekent dit dat ze moeten kunnen aantonen dat ze passende versleutelingsmaatregelen hebben geïmplementeerd. Artikel 32 specificeert ook dat organisaties moeten kunnen aantonen dat ze controle hebben over de beveiliging van persoonsgegevens, wat data sovereignty-vereisten omvat. Customer-Managed Keys stellen organisaties in staat om te voldoen aan deze vereisten door volledige controle te hebben over versleutelingssleutels en door te kunnen garanderen dat sleutels binnen specifieke geografische regio's blijven. Dit is met name belangrijk voor Nederlandse organisaties die moeten voldoen aan data sovereignty-vereisten waarbij persoonsgegevens binnen de Europese Unie moeten blijven. Het niet implementeren van CMK kan resulteren in niet-naleving van AVG-vereisten, wat kan leiden tot boetes tot 4 procent van de wereldwijde jaaromzet of 20 miljoen euro, afhankelijk van wat hoger is.

De Baseline Informatiebeveiliging Overheid (BIO) specificeert in Thema 10.01 dat organisaties cryptografische maatregelen moeten implementeren om informatie te beveiligen. Deze maatregelen omvatten het gebruik van sterke cryptografie, het beheren van cryptografische sleutels volgens een gedefinieerd beleid, en het waarborgen dat cryptografische maatregelen regelmatig worden geëvalueerd en bijgewerkt. Voor Nederlandse overheidsorganisaties is de BIO-baseline verplicht, en het niet voldoen aan deze vereisten kan leiden tot beveiligingsincidenten en compliance-problemen. Customer-Managed Keys voor Azure Databricks stellen overheidsorganisaties in staat om te voldoen aan BIO-vereisten door volledige controle te hebben over cryptografische sleutels en door te kunnen aantonen dat sleutels worden beheerd volgens het gedefinieerde beleid. Organisaties moeten kunnen aantonen dat ze sleutelrotatie regelmatig uitvoeren, dat er procedures zijn voor sleutelherstel, en dat alle sleuteloperaties worden gelogd voor auditdoeleinden.

Naast deze specifieke compliance-frameworks zijn er ook sectorspecifieke vereisten die Customer-Managed Keys kunnen vereisen. Financiële instellingen die onder toezicht staan van De Nederlandsche Bank (DNB) of de Autoriteit Financiële Markten (AFM) moeten vaak kunnen aantonen dat ze volledige controle hebben over versleutelingssleutels voor gevoelige financiële data. Gezondheidszorgorganisaties die patiëntgegevens verwerken moeten voldoen aan de Wet op de geneeskundige behandelingsovereenkomst (WGBO) en moeten kunnen aantonen dat versleutelingssleutels worden beheerd volgens strikte beveiligingsvereisten. Organisaties in kritieke infrastructuren moeten vaak voldoen aan aanvullende beveiligingsvereisten die Customer-Managed Keys vereisen voor compliance.

Voor auditdoeleinden moeten organisaties kunnen aantonen dat Customer-Managed Keys correct zijn geïmplementeerd en worden beheerd. Dit omvat het documenteren van de Key Vault-configuratie, het bijhouden van sleutelrotatie-activiteiten, het loggen van alle sleuteloperaties, en het regelmatig reviewen van toegangsbeleid. Organisaties moeten ook kunnen aantonen dat er procedures zijn voor sleutelherstel en dat break-glass procedures zijn gedocumenteerd en getest. Deze documentatie is essentieel voor het succesvol doorstaan van compliance-audits en voor het aantonen van due diligence bij beveiligingsincidenten.

Remediatie

Gebruik PowerShell-script databricks-cmk-encryption.ps1 (functie Invoke-Remediation) – Automatiseert de implementatie van CMK-versleuteling voor nieuwe Databricks workspaces.

Remediatie van Customer-Managed Key versleuteling voor Azure Databricks omvat het implementeren van CMK voor workspaces die momenteel gebruikmaken van Microsoft-Managed Keys, of het corrigeren van configuratiefouten in bestaande CMK-implementaties. Het is belangrijk om te begrijpen dat CMK alleen kan worden geconfigureerd tijdens het initiële aanmaken van een Databricks workspace, wat betekent dat remediatie voor bestaande workspaces een volledige workspace-migratie vereist. Voor nieuwe workspaces kan remediatie worden uitgevoerd door de workspace opnieuw aan te maken met CMK-configuratie, terwijl voor bestaande productie-workspaces een uitgebreid migratieproces noodzakelijk is.

Voor nieuwe workspaces die nog niet in productie zijn, is remediatie relatief eenvoudig. De bestaande workspace kan worden verwijderd en opnieuw worden aangemaakt met CMK-configuratie tijdens het aanmaakproces. Het is belangrijk om ervoor te zorgen dat alle configuraties, notebooks en data eerst worden geëxporteerd voordat de workspace wordt verwijderd. Gebruik de Databricks CLI of Git-integratie om alle notebooks te exporteren, documenteer alle clusterconfiguraties, job definitions en geïnstalleerde libraries, en maak backups van alle belangrijke data. Na het exporteren kan de workspace worden verwijderd en opnieuw worden aangemaakt met de juiste CMK-configuratie volgens de implementatie-instructies in de vorige secties.

Voor bestaande productie-workspaces is remediatie veel complexer en vereist een zorgvuldige planning en uitvoering. Het proces begint met een uitgebreide assessment van de huidige workspace-configuratie, inclusief een inventarisatie van alle notebooks, jobs, clusters, libraries en data. Plan een maintenance window van minimaal 4-8 uur, afhankelijk van het data volume en de complexiteit van de workloads. Communiceer proactief met alle stakeholders, inclusief data scientists, data engineers en business gebruikers, over de geplande migratie en de verwachte impact op hun werkzaamheden.

De eerste stap in het remediatieproces is het opzetten van de vereiste infrastructuur volgens de implementatie-instructies. Dit omvat het creëren van een Azure Key Vault met Soft Delete en Purge Protection, het aanmaken van versleutelingssleutels, en het configureren van de juiste permissions voor de Databricks service principal. Zorg ervoor dat alle infrastructuur-componenten correct zijn geconfigureerd voordat u begint met de workspace-migratie, omdat configuratiefouten tijdens de migratie kunnen leiden tot aanzienlijke vertragingen en extra downtime.

Exporteer vervolgens alle content van de bestaande workspace. Gebruik de Databricks CLI of Git-integratie om alle notebooks te exporteren naar een versiebeheersysteem. Documenteer alle job definitions inclusief schedules, dependencies en configuraties. Exporteer clusterconfiguraties inclusief instance types, autoscaling settings, en init scripts. Maak een lijst van alle geïnstalleerde libraries en hun versies. Voor data in DBFS, gebruik de Databricks CLI of Azure Data Factory om data te kopiëren naar een tijdelijke opslaglocatie. Documenteer alle externe data-verbindingen, secrets en configuraties die nodig zijn voor de nieuwe workspace.

Maak de nieuwe CMK-enabled workspace aan volgens de implementatie-instructies in de vorige secties. Zorg ervoor dat u de Key Vault URI en Key Name correct invoert tijdens het aanmaakproces. Na het aanmaken van de workspace, importeer alle geëxporteerde content. Importeer notebooks via de Databricks CLI of Git-integratie, herstel alle job definitions met de juiste configuraties, en reconfigureer alle clusters met de oorspronkelijke instellingen. Installeer alle benodigde libraries en reconfigureer alle externe verbindingen en secrets.

Migreer data van de oude naar de nieuwe workspace. Gebruik Azure Data Factory pipelines of geautomatiseerde copy jobs om data efficiënt te migreren. Verifieer dat alle data correct is gemigreerd door data-integrity checks uit te voeren, waarbij u steekproefsgewijs data vergelijkt tussen de oude en nieuwe workspace. Test alle jobs en notebooks in de nieuwe workspace om te verifiëren dat alles correct functioneert. Voer een parallel run uit waarbij beide workspaces tijdelijk operationeel zijn, zodat gebruikers kunnen valideren dat de nieuwe workspace correct werkt voordat de cutover plaatsvindt.

Na succesvolle validatie kunnen gebruikers worden overgezet naar de nieuwe workspace. Update alle documentatie, training materialen en user guides om te verwijzen naar de nieuwe workspace. De oude workspace moet worden behouden voor een retention period van minimaal 30 dagen om ervoor te zorgen dat alle data correct is gemigreerd en dat er geen kritieke informatie verloren is gegaan. Na deze periode kan de oude workspace worden gedecommissioneerd, maar alleen na een laatste verificatie dat alle data succesvol is gemigreerd en dat er geen actieve dependencies meer zijn.

Voor bestaande CMK-implementaties die configuratiefouten hebben, kan remediatie worden uitgevoerd zonder volledige workspace-migratie. Als de Key Vault permissions incorrect zijn geconfigureerd, kunnen deze worden gecorrigeerd via de Azure Portal of Azure CLI zonder impact op de workspace. Als de Key Vault zelf problemen heeft, zoals uitgeschakelde Soft Delete of Purge Protection, moet eerst de Key Vault-configuratie worden gecorrigeerd. Voor problemen met sleutelrotatie kunnen nieuwe key versions worden aangemaakt en geconfigureerd zonder workspace-reconfiguratie. Het is belangrijk om alle configuratiewijzigingen te documenteren en te testen in een testomgeving voordat ze in productie worden geïmplementeerd.

Compliance & Frameworks

• CIS M365: Control 2.1.1 (L2) - Customer-managed keys voor gegevensversleuteling
• BIO: 10.01.01, 10.01.02 - Cryptografische maatregelen - Customer-managed keys
• ISO 27001:2022: A.10.1.2 - Key management
• NIS2: Artikel - Versleuteling en sleutelbeheer controls

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) voor Azure Databricks bieden organisaties volledige controle over versleutelingssleutels via Azure Key Vault, wat essentieel is voor compliance met AVG data sovereignty-eisen, NIS2 versleutelingsvereisten en sectorspecifieke regelgeving in financiële dienstverlening en gezondheidszorg. CMK stelt organisaties in staat om: (1) zelf sleutels te beheren en te roteren volgens eigen beleid, (2) toegang tot versleutelde data onmiddellijk in te trekken door sleutels te revokeren bij beveiligingsincidenten, (3) complete audit trails te verkrijgen over alle sleuteloperaties, (4) data sovereignty te waarborgen waarbij sleutels binnen specifieke geografische regio's blijven. Deze maatregel is VERPLICHT voor Databricks-workspaces met gereguleerde data zoals persoonsgegevens, financiële informatie of gezondheidszorgdata, AANBEVOLEN voor workspaces met business-critical IP of vertrouwelijke bedrijfsdata, en OPTIONEEL voor standaard analytics-workloads met niet-gevoelige data. Belangrijke vereisten zijn Azure Databricks Premium tier (CMK niet beschikbaar op Standard), dedicated Azure Key Vault met Soft Delete en Purge Protection, en bewustzijn dat CMK ALLEEN tijdens workspace creation kan worden geconfigureerd - bestaande workspaces moeten volledig opnieuw worden aangemaakt wat datamigratie vereist. Implementatie-inspanning is 10-16 uur inclusief Key Vault setup, sleutel-creatie, Databricks workspace deployment met CMK, testing van versleuteling en datamigratie indien van toepassing. Doorlopende inspanning van 4 uur per jaar voor sleutelrotatie. Kosten zijn beperkt tot Key Vault operations (€0,025 per 10K operations). Return on investment komt van compliance-bereiking, verminderde auditbevindingen, regelgevingsgoedkeuring en verbeterde beveiligingspositie voor gevoelige analytics-workloads.

• Implementatietijd: 16 uur
• FTE required: 0.2 FTE