Azure SQL Database: Transparent Data Encryption Met Customer-Managed Keys

Standaard gebruikt Azure SQL Database Transparent Data Encryption met door Microsoft beheerde sleutels (MMK) waarbij Microsoft de versleutelingssleutels beheert en roteert. Voor veel organisaties is dit voldoende, maar gereguleerde industrieën hebben vaak strengere vereisten waarbij volledige controle over de versleutelingslevenscyclus essentieel is. Zonder door de klant beheerde sleutels hebben organisaties geen controle over sleutelcreatie, sleutelrotatie of sleutelrevocatie. Bovendien zijn de sleutels niet geografisch gebonden aan de eigen Key Vault van de organisatie, wat gegevenssoevereiniteitsvereisten schendt. Er ontbreekt ook de mogelijkheid tot noodrevocatie van sleutels waarbij onmiddellijk toegang tot gegevens kan worden geblokkeerd bij beveiligingsincidenten. Daarnaast ontbreekt een gedetailleerd auditlogboek van alle sleuteloperaties, en kunnen strikte compliance-vereisten voor versleuteling zoals vereist in de financiële sector (PCI-DSS), gezondheidszorg (HIPAA-equivalent in de EU), of overheid (specifieke versleutelingseisen) niet worden aangetoond. Voor organisaties in deze sectoren is TDE CMK vaak wettelijk verplicht of contractueel vereist door klanten of partners. Door de klant beheerde sleutels via Azure Key Vault bieden eigen Key Vault-beheer binnen het abonnement en de geografische regio van de organisatie, sleutelrotatie op eigen schema (bijvoorbeeld elke 90 dagen) in plaats van het rotatieschema van Microsoft, onmiddellijke revocatiemogelijkheid door Key Vault-toegang in te trekken wat database-toegang direct blokkeert, geografisch gebonden sleutels die binnen de door de organisatie gekozen regio blijven voor gegevenssoevereiniteit, en een volledig auditlogboek via Key Vault diagnostische logs van alle wrap- en unwrap-operaties. Deze controle is essentieel voor compliance met AVG gegevenssoevereiniteitsvereisten waar persoonsgegevens onder volledige controle van de organisatie moeten blijven, NIS2 Artikel 21 dat specifieke cryptografische maatregelen vereist voor kritieke systemen, en sectorspecifieke eisen zoals PCI-DSS of BIO overheidsrichtlijnen.

Implementatie

Deze maatregel implementeert TDE door de klant beheerde sleutels voor Azure SQL Database waarbij versleuteling wordt beheerd via een door de organisatie beheerde Azure Key Vault in plaats van door Microsoft beheerde sleutels. De implementatie vereist eerst het aanmaken van een Azure Key Vault met Soft Delete en Purge Protection ingeschakeld. Deze beveiligingsmaatregelen kunnen niet worden uitgeschakeld na activering en zijn essentieel om per ongeluk verwijderen van sleutels te voorkomen. Vervolgens moet een RSA-versleutelingssleutel worden gecreëerd met een minimum van 2048-bit maar bij voorkeur 3072 of 4096-bit voor verhoogde beveiliging in hoogbeveiligde omgevingen. De SQL-server moet een door het systeem toegewezen beheerde identiteit hebben die automatisch wordt aangemaakt wanneer deze functie wordt ingeschakeld in de SQL-serverinstellingen. Deze beheerde identiteit moet toegang krijgen tot de Key Vault via een toegangsbeleid met minimaal de rechten Get (om de sleutel te lezen), Wrap Key (om de databaseversleutelingssleutel te versleutelen), en Unwrap Key (om de databaseversleutelingssleutel te ontsleutelen bij toegang). De SQL-server TDE protector wordt vervolgens geconfigureerd om de door de klant beheerde sleutel te gebruiken in plaats van de door de service beheerde sleutel, waarbij alle databases binnen deze server automatisch de CMK erven. Een formeel sleutelrotatieproces moet worden geïmplementeerd met een aanbevolen frequentie van 90-180 dagen waarbij een nieuwe sleutelversie in Key Vault wordt gemaakt en de SQL-server TDE protector wordt bijgewerkt. Cruciale back-upprocedures moeten worden gedocumenteerd inclusief Key Vault-back-up en break-glass procedures voor scenario's waarbij Key Vault-toegang verloren gaat. De kosten zijn beperkt tot Key Vault-operaties (circa €0,025 per 10.000 operaties) plus administratieve overhead voor sleutelrotatie. Deze implementatie vereist 3-5 uur technisch werk en is sterk aanbevolen voor gereguleerde sectoren, maar optioneel voor standaard bedrijfsdatabases waar door Microsoft beheerde sleutels voldoende beveiliging bieden.

Vereisten

De implementatie van Transparent Data Encryption met door de klant beheerde sleutels vereist een zorgvuldige voorbereiding en specifieke Azure-componenten. Voordat organisaties beginnen met de configuratie, moeten zij beschikken over een Azure Key Vault die voldoet aan de hoogste beveiligingsstandaarden. Dit betekent dat de Key Vault moet worden geconfigureerd met zowel Soft Delete als Purge Protection functionaliteiten. Deze beveiligingsmaatregelen zijn essentieel omdat zij voorkomen dat versleutelingssleutels per ongeluk of opzettelijk permanent worden verwijderd, wat zou resulteren in onherstelbaar dataverlies. Soft Delete zorgt ervoor dat verwijderde sleutels gedurende een configureerbare bewaarperiode (aanbevolen 90 dagen) behouden blijven, terwijl Purge Protection een extra beveiligingslaag biedt die zelfs beheerders met hoogste privileges verhindert om sleutels definitief te verwijderen binnen de bewaarperiode.

Naast de Key Vault configuratie is het noodzakelijk dat de Azure SQL Server beschikt over een System-Assigned Managed Identity. Deze beheerde identiteit wordt automatisch aangemaakt door Azure wanneer deze functionaliteit wordt ingeschakeld in de server-instellingen. De Managed Identity fungeert als een veilige authenticatiemethode waarmee de SQL Server zich kan authenticeren bij de Key Vault zonder dat er expliciete credentials hoeven te worden opgeslagen of beheerd. Dit elimineert het risico op credential leakage en vereenvoudigt het beheer aanzienlijk. De Managed Identity moet worden geconfigureerd met specifieke toegangsrechten op de Key Vault, namelijk de permissions Get, Wrap Key en Unwrap Key. Deze drie permissions zijn minimaal vereist voor de correcte werking van TDE met Customer-Managed Keys.

Een kritiek onderdeel van de implementatie is het vaststellen van een formeel sleutelrotatieproces. Organisaties moeten een duidelijk gedefinieerd schema implementeren waarbij versleutelingssleutels regelmatig worden vervangen. De aanbevolen frequentie voor sleutelrotatie ligt tussen de 90 en 180 dagen, afhankelijk van de gevoeligheid van de data en de compliance-vereisten van de organisatie. Voor hoogst gevoelige databases in de financiële sector of gezondheidszorg kan een kortere rotatieperiode van 90 dagen worden overwogen, terwijl voor minder kritieke databases een periode van 180 dagen acceptabel kan zijn. Het rotatieproces moet worden gedocumenteerd en geautomatiseerd waar mogelijk om menselijke fouten te voorkomen en consistentie te waarborgen.

Tenslotte moeten organisaties beschikken over een break-glass key recovery procedure. Deze procedure beschrijft de stappen die moeten worden genomen in het scenario waarbij toegang tot de Key Vault verloren gaat of wanneer er sprake is van een security incident. De break-glass procedure moet gedetailleerde instructies bevatten voor het herstellen van toegang tot versleutelde databases, inclusief contactgegevens van key personnel, escalation procedures en tijdlijnen voor herstel. Deze procedure moet regelmatig worden getest en bijgewerkt om ervoor te zorgen dat organisaties in staat zijn om snel te reageren op noodsituaties zonder dat dit resulteert in langdurige datatoegangsproblemen.

Implementatie

**FASE 1: Azure Key Vault Opzetten met Security Hardening (Duur: 45 minuten)**

De eerste fase van de implementatie omvat het opzetten van een dedicated Azure Key Vault die specifiek is geconfigureerd voor het beheren van SQL TDE versleutelingssleutels. Organisaties moeten via de Azure Portal navigeren naar de Key Vaults sectie en een nieuwe Key Vault aanmaken. Bij het configureren van de Key Vault is het van cruciaal belang dat de naamgeving duidelijk en beschrijvend is, bijvoorbeeld 'kv-sql-tde-prod' om aan te geven dat deze Key Vault is bestemd voor productie SQL TDE sleutels. Een van de meest kritieke configuratie-aspecten is de selectie van de Azure-regio. De regio van de Key Vault moet exact overeenkomen met de regio waarin de SQL Server zich bevindt. Deze matching is essentieel om twee belangrijke redenen: ten eerste minimaliseert het de latency bij het ophalen en gebruiken van versleutelingssleutels, wat de databaseprestaties beïnvloedt, en ten tweede is het noodzakelijk voor compliance met data residency-vereisten waarbij versleutelingssleutels binnen dezelfde geografische grenzen moeten blijven als de data die zij beschermen.

Voor de pricing tier hebben organisaties de keuze tussen Standard en Premium. De Standard tier is voor de meeste use cases voldoende en biedt software-gebaseerde versleuteling. De Premium tier biedt Hardware Security Module (HSM)-backed keys, wat een extra beveiligingslaag biedt voor hoogst gevoelige data in gereguleerde sectoren zoals financiële dienstverlening of overheidsinstellingen. Organisaties moeten de keuze baseren op hun compliance-vereisten en risicoprofiel. Naast de basisconfiguratie zijn er drie verplichte beveiligingsinstellingen die moeten worden geactiveerd: Soft Delete, Purge Protection en netwerkbeveiliging. Soft Delete moet worden ingeschakeld met een retention periode van minimaal 90 dagen. Deze functionaliteit voorkomt dat versleutelingssleutels permanent worden verwijderd, zelfs wanneer een beheerder per ongeluk een delete-operatie uitvoert. Gedurende de retention periode kunnen verwijderde sleutels worden hersteld, wat kritiek is voor business continuity.

Purge Protection vormt een aanvullende beveiligingslaag die zelfs beheerders met de hoogste privileges verhindert om sleutels definitief te verwijderen binnen de retention periode. Het is belangrijk om te begrijpen dat zodra Purge Protection is ingeschakeld, deze functionaliteit niet meer kan worden uitgeschakeld. Deze permanente configuratie is een bewuste beveiligingsmaatregel van Microsoft om te voorkomen dat kwaadwillende actoren of gecompromitteerde accounts kritieke versleutelingssleutels kunnen verwijderen. Voor netwerkbeveiliging moeten organisaties publieke toegang uitschakelen en kiezen voor Private Endpoints of een firewall met IP-whitelisting. Private Endpoints bieden de hoogste beveiliging door de Key Vault alleen toegankelijk te maken via het Azure Virtual Network, terwijl IP-whitelisting een praktischere oplossing kan zijn voor organisaties die nog niet beschikken over een volledig geconfigureerd Virtual Network.

Diagnostische logging is een essentieel onderdeel van de Key Vault configuratie omdat het een compleet auditlogboek biedt van alle sleuteloperaties. Organisaties moeten via de diagnostische instellingen van de Key Vault een nieuwe diagnostische instelling toevoegen die alle loggegevens streamt naar een Log Analytics-werkruimte. Deze logs registreren alle belangrijke operaties inclusief Get-operaties (het ophalen van sleutels), Wrap Key-operaties (het versleutelen van databaseversleutelingssleutels), Unwrap Key-operaties (het ontsleutelen van databaseversleutelingssleutels), en alle pogingen tot Delete-operaties. Dit auditlogboek is niet alleen belangrijk voor compliance-doeleinden, maar ook voor forensisch onderzoek in het geval van beveiligingsincidenten. Voor toegangsbeheer moeten organisaties Azure RBAC (Role-Based Access Control) gebruiken in plaats van de verouderde toegangsbeleidsregels. RBAC biedt een moderner en flexibeler model voor toegangsbeheer dat beter integreert met andere Azure-services. De Key Vault moet worden geconfigureerd via toegangsconfiguratie om Azure op rollen gebaseerd toegangsbeheer te gebruiken. Tenslotte moeten organisaties de Key Vault taggen met relevante metadata zoals Purpose=SQLTDEKeys, Criticality=High, en DataClassification=Regulated. Deze tags faciliteren resource governance en helpen bij het organiseren en beheren van Azure-resources op schaal.

**FASE 2: TDE Encryption Key Genereren (Duur: 15 minuten)**

De tweede fase omvat het genereren of importeren van de daadwerkelijke versleutelingssleutel die zal worden gebruikt voor Transparent Data Encryption. Organisaties moeten binnen de Key Vault navigeren naar de Keys sectie en kiezen voor Generate/Import. Hier hebben zij twee opties: het genereren van een nieuwe sleutel binnen Azure Key Vault, of het importeren van een bestaande sleutel vanuit een externe Hardware Security Module (HSM). Voor de meeste organisaties is het genereren van een nieuwe sleutel de aanbevolen aanpak omdat dit proces volledig wordt beheerd door Azure en geoptimaliseerd is voor gebruik met SQL TDE. Het importeren van een bestaande sleutel is alleen noodzakelijk wanneer organisaties specifieke compliance-vereisten hebben die mandateren dat sleutels worden gegenereerd binnen een externe HSM.

Bij het configureren van de sleutel is het belangrijk om te begrijpen dat Azure SQL Database TDE uitsluitend RSA-sleutels ondersteunt. Andere sleuteltypes zoals ECC (Elliptic Curve Cryptography) worden niet ondersteund voor TDE. Voor de sleutelgrootte hebben organisaties drie opties: 2048-bit (het minimum dat acceptabel is), 3072-bit (aanbevolen voor implementaties in 2025 en later), en 4096-bit (maximum beveiliging voor hoogst gereguleerde data zoals financiële of gezondheidszorggegevens). Het is belangrijk om te begrijpen dat grotere sleutels betere cryptografische beveiliging bieden, maar dit gaat gepaard met een lichte toename in latency bij het ophalen en gebruiken van de sleutels. Voor de meeste organisaties biedt een 3072-bit RSA-sleutel de optimale balans tussen beveiliging en prestaties.

De naamgeving van de sleutel moet beschrijvend en gestructureerd zijn om het beheer en de tracking van sleutelrotaties te faciliteren. Een goede naamgevingsconventie is bijvoorbeeld 'sql-tde-prod-key-2025', waarbij het jaar wordt opgenomen om te helpen bij het volgen van wanneer de sleutel is gegenereerd en wanneer deze moet worden geroteerd. Organisaties moeten activerings- en vervaldatums instellen voor de sleutel. De activeringsdatum moet worden ingesteld op de huidige datum, terwijl de vervaldatum moet worden ingesteld op 180 dagen in de toekomst. Deze vervaldatum forceert een sleutelrotatie elke zes maanden, wat een best practice is voor hoogst gevoelige databases. De sleutel moet worden ingeschakeld (Enabled: Yes) om te kunnen worden gebruikt door de SQL Server.

Voor de sleuteloperaties moeten organisaties specifieke rechten configureren. De operaties Get, Wrap Key en Unwrap Key moeten worden ingeschakeld omdat deze essentieel zijn voor de werking van TDE. De Get-operatie stelt de SQL Server in staat om de sleutel te lezen, Wrap Key wordt gebruikt om de databaseversleutelingssleutel te versleutelen, en Unwrap Key wordt gebruikt om de databaseversleutelingssleutel te ontsleutelen wanneer toegang tot de database nodig is. De operaties Sign, Verify, Encrypt en Decrypt moeten worden uitgeschakeld omdat deze niet nodig zijn voor TDE en het uitschakelen ervan de aanvalsoppervlakte verkleint volgens het principe van least privilege. Na het klikken op Create duurt het genereren van de sleutel ongeveer 5 tot 10 seconden. Organisaties moeten de sleutelidentifier URI noteren, die eruitziet als https://kv-sql-tde-prod.vault.azure.net/keys/sql-tde-prod-key-2025/[version-id]. Deze URI is nodig voor de configuratie van TDE op de SQL Server in een latere fase.

**FASE 3: SQL Server Managed Identity Configureren (Duur: 10 minuten)**

De derde fase omvat het configureren van een System-Assigned Managed Identity voor de Azure SQL Server. Deze beheerde identiteit is essentieel omdat het de SQL Server in staat stelt om zich te authenticeren bij de Key Vault zonder dat er expliciete credentials hoeven te worden opgeslagen of beheerd. Organisaties moeten via de Azure Portal navigeren naar de SQL Server en vervolgens naar de Identity sectie. Binnen deze sectie moeten zij kiezen voor System assigned, wat betekent dat Azure automatisch een Service Principal aanmaakt in Azure Active Directory die gekoppeld is aan de SQL Server. Deze Service Principal wordt gebruikt voor alle authenticatie-verzoeken naar de Key Vault.

Om de Managed Identity te activeren, moeten organisaties de Status schakelaar instellen op 'On' en vervolgens op Save klikken. Zodra deze actie is voltooid, creëert Azure automatisch de Service Principal in Azure Active Directory. Dit proces duurt meestal enkele seconden. Na activering is het van cruciaal belang dat organisaties de Object (principal) ID noteren, omdat deze identifier nodig is voor het verlenen van toegang tot de Key Vault in de volgende fase. Deze ID kan worden gevonden in de Identity blade van de SQL Server en ziet eruit als een GUID (Globally Unique Identifier).

Het is belangrijk om te begrijpen dat een System-Assigned Managed Identity automatisch wordt verwijderd wanneer de SQL Server wordt verwijderd. Dit betekent dat de identiteit en alle bijbehorende toegangsrechten verloren gaan. Voor scenario's waarbij meerdere SQL Servers dezelfde versleutelingssleutel moeten delen, of wanneer organisaties een meer permanente identiteit nodig hebben die onafhankelijk is van de levenscyclus van een specifieke server, moeten zij overwegen om een User-Assigned Managed Identity te gebruiken. Een User-Assigned Managed Identity is een standalone Azure-resource die kan worden gekoppeld aan meerdere services en niet automatisch wordt verwijderd wanneer een service wordt verwijderd.

**FASE 4: Key Vault Access Verlenen aan SQL Server (Duur: 15 minuten)**

De vierde fase omvat het verlenen van toegang aan de SQL Server Managed Identity zodat deze de versleutelingssleutel kan ophalen en gebruiken uit de Key Vault. Organisaties moeten binnen de Key Vault navigeren naar Access control (IAM) voor het RBAC-model, of naar Access policies voor het legacy-model. Het RBAC-model is de moderne en aanbevolen aanpak omdat het beter integreert met andere Azure-services en een meer granulaire controle biedt over toegangsrechten. Het legacy Access Policies-model wordt nog steeds ondersteund maar wordt niet meer aanbevolen voor nieuwe implementaties.

Voor het RBAC-model moeten organisaties een nieuwe roltoewijzing toevoegen. De specifieke rol die moet worden toegewezen is 'Key Vault Crypto Service Encryption User', wat een gespecialiseerde rol is die specifiek is ontworpen voor TDE-implementaties. Deze rol verleent precies de benodigde rechten: Get (om de sleutel te lezen), Wrap Key (om de databaseversleutelingssleutel te versleutelen), en Unwrap Key (om de databaseversleutelingssleutel te ontsleutelen). Bij het selecteren van leden moeten organisaties zoeken naar de naam van de SQL Server, wat automatisch de bijbehorende beheerde identiteit zal identificeren. Na het toewijzen van de rol moet de SQL Server beheerde identiteit zichtbaar zijn in de lijst van roltoewijzingen.

Voor organisaties die het verouderde toegangsbeleidsmodel gebruiken, moeten zij een nieuwe toegangsbeleidsregel toevoegen. Binnen deze beleidsregel moeten secretrechten worden ingesteld op NONE (omdat TDE geen secrets gebruikt), sleutelrechten moeten worden ingesteld op Get, Wrap Key en Unwrap Key (deze drie zijn het minimum dat nodig is voor TDE), en certificaatrechten moeten worden ingesteld op NONE. Bij het selecteren van de principal moeten organisaties zoeken naar de naam van de SQL Server beheerde identiteit. Na het toevoegen van de beleidsregel moet de beheerde identiteit zichtbaar zijn in de lijst van toegangsbeleidsregels. Het valideren van de toegang is belangrijk, maar de daadwerkelijke verificatie dat de SQL Server de sleutel kan ophalen gebeurt in fase 5 wanneer TDE CMK wordt geconfigureerd.

**FASE 5: TDE Customer-Managed Key Configureren op SQL Server (Duur: 20 minuten)**

De vijfde en laatste fase omvat het daadwerkelijk configureren van Transparent Data Encryption om de door de klant beheerde sleutel te gebruiken in plaats van de door Microsoft beheerde sleutel. Organisaties moeten via de Azure Portal navigeren naar de SQL Server, vervolgens naar de Security sectie, en tenslotte naar Transparent data encryption. Binnen deze blade moeten zij naar de door de klant beheerde sleutel sectie navigeren en klikken op 'Change key'. Hier hebben zij twee opties voor het selecteren van de sleutel: 'Select a key' (waarbij zij een bestaande sleutel uit de Key Vault kunnen kiezen via een dropdown-menu), of 'Enter key identifier' (waarbij zij de volledige sleutelidentifier URI kunnen plakken die is genoteerd in fase 2).

Bij het configureren van de TDE protector moeten organisaties drie belangrijke selecties maken: de Key Vault (die moet overeenkomen met de Key Vault die is aangemaakt in fase 1), de Key (die moet overeenkomen met de TDE-sleutel die is gegenereerd in fase 2), en de Version. Voor de versie hebben organisaties twee opties: het selecteren van een specifieke versie (wat betekent dat de SQL Server altijd deze specifieke versie zal gebruiken totdat deze handmatig wordt bijgewerkt), of 'Always use current version' (wat betekent dat de SQL Server automatisch de nieuwste versie van de sleutel zal gebruiken wanneer deze beschikbaar komt, wat automatische sleutelrotatie mogelijk maakt).

Na het klikken op Save begint Azure met het configureren van TDE CMK. Dit proces duurt meestal 2 tot 5 minuten, afhankelijk van het aantal databases op de server en de grootte van deze databases. Tijdens dit proces worden alle databases op de SQL Server automatisch opnieuw versleuteld met de door de klant beheerde sleutel. Dit is een transparant proces dat geen downtime veroorzaakt - databases blijven beschikbaar en toegankelijk tijdens de herversleuteling. Het is belangrijk om te begrijpen dat dit proces niet de data zelf opnieuw versleutelt, maar alleen de databaseversleutelingssleutel (DEK) opnieuw versleutelt met de nieuwe door de klant beheerde sleutel.

Na voltooiing van het configuratieproces moeten organisaties verifiëren dat CMK actief is. De Transparent data encryption blade moet nu 'Customer-managed key' tonen, samen met de naam van de Key Vault en de naam van de sleutel. Voor elke individuele database moet de versleutelingsstatus 'Encrypted with customer-managed key' tonen. Het is van cruciaal belang om te begrijpen dat als de toegang tot de Key Vault faalt (bijvoorbeeld door incorrecte rechten of netwerkblokkering), TDE blijft werken met een gecachte versie van de sleutel, maar nieuwe databases kunnen niet worden aangemaakt omdat de SQL Server de sleutel niet kan ophalen voor nieuwe databases. In dergelijke scenario's moeten organisaties onmiddellijk de toegangsproblemen oplossen om te voorkomen dat database-operaties worden belemmerd.

⏱️ **Totale Implementatietijd**: 3-5 uur (Key Vault setup 45 min, sleutelcreatie 15 min, beheerde identiteit 10 min, toegang verlenen 15 min, TDE configuratie 20 min, testen 1 uur, rotatie-automatisering 1 uur).

💰 **Kosten**: Key Vault Standard: €0,025 per 10K sleuteloperaties (verwaarloosbaar voor TDE), Premium (HSM): €1 per sleutel per maand. Sleutelopslag: gratis. Totaal: minder dan €5 per maand voor Standard, €10-15 per maand voor Premium HSM.

Monitoring

Gebruik PowerShell-script sql-tde-customer-managed-keys.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Transparent Data Encryption met door de klant beheerde sleutels is essentieel om te waarborgen dat de versleuteling correct functioneert en om tijdig te kunnen reageren op potentiële problemen. Organisaties moeten een uitgebreide monitoringstrategie implementeren die alle aspecten van de TDE CMK-implementatie omvat. De eerste en meest kritieke monitoringactiviteit betreft het monitoren van Key Vault diagnostische logs. Deze logs bevatten gedetailleerde informatie over alle sleuteloperaties die worden uitgevoerd door de SQL Server, inclusief Get-operaties (het ophalen van sleutels), Wrap Key-operaties (het versleutelen van databaseversleutelingssleutels), en Unwrap Key-operaties (het ontsleutelen van databaseversleutelingssleutels). Het is normaal om regelmatig Wrap- en Unwrap-operaties te zien in de logs, omdat deze plaatsvinden telkens wanneer de SQL Server toegang nodig heeft tot versleutelde databases. Organisaties moeten echter alert zijn op ongebruikelijke patronen, zoals een plotselinge toename in het aantal operaties of operaties die plaatsvinden buiten normale bedrijfsuren.

Een van de meest kritieke monitoring-aspecten is het instellen van waarschuwingen voor gefaalde sleuteloperaties. Wanneer een sleuteloperatie faalt, kan dit betekenen dat de SQL Server geen toegang meer heeft tot de versleutelingssleutel, wat resulteert in het blokkeren van database-toegang. Dergelijke fouten kunnen worden veroorzaakt door verschillende factoren, waaronder incorrecte rechten op de Key Vault, netwerkproblemen die de verbinding tussen de SQL Server en de Key Vault blokkeren, of problemen met de beheerde identiteit. Organisaties moeten Azure Monitor waarschuwingen configureren die onmiddellijk een melding sturen wanneer een sleuteloperatie faalt, zodat zij snel kunnen reageren en de problemen kunnen oplossen voordat dit resulteert in langdurige datatoegangsproblemen. Deze waarschuwingen moeten worden geconfigureerd met een hoge prioriteit en moeten worden doorgestuurd naar het security operations team en de databasebeheerders.

Het volgen van sleutelrotatiedatums is een ander belangrijk onderdeel van de monitoringstrategie. Organisaties moeten een proces implementeren waarbij zij regelmatig controleren wanneer versleutelingssleutels verlopen en waarschuwingen configureren die worden geactiveerd voordat de vervaldatum wordt bereikt. Dit geeft organisaties voldoende tijd om het sleutelrotatieproces te initiëren en te voltooien voordat de huidige sleutel verloopt. De aanbevolen praktijk is om waarschuwingen te configureren die worden geactiveerd 30 dagen voor de vervaldatum, wat voldoende tijd biedt voor planning en uitvoering van de rotatie. Organisaties moeten ook een tweede waarschuwing configureren die wordt geactiveerd 7 dagen voor de vervaldatum als een laatste waarschuwing, en een kritieke waarschuwing die wordt geactiveerd op de dag van vervaldatum als de rotatie nog niet is voltooid.

Het monitoren van de SQL TDE status is essentieel om te verifiëren dat door de klant beheerde sleutels actief zijn en correct worden gebruikt. Organisaties moeten regelmatig controleren dat de TDE-configuratie op elke SQL Server correct is ingesteld en dat alle databases zijn versleuteld met de door de klant beheerde sleutel in plaats van de door Microsoft beheerde sleutel. Dit kan worden geverifieerd via de Azure Portal door te navigeren naar de Transparent data encryption blade van elke SQL Server en te controleren dat de status 'Customer-managed key' toont, samen met de correcte Key Vault naam en sleutelnaam. Voor elke individuele database moet de versleutelingsstatus 'Encrypted with customer-managed key' tonen. Organisaties moeten ook PowerShell-scripts gebruiken om deze status programmatisch te controleren, wat het mogelijk maakt om monitoring te automatiseren en te integreren met bestaande monitoringtools.

Tenslotte moeten organisaties een proces implementeren voor het regelmatig back-uppen van de Key Vault configuratie. Hoewel Azure Key Vault automatisch back-ups maakt van sleutels, is het belangrijk dat organisaties ook de configuratie zelf back-uppen, inclusief toegangsbeleidsregels, diagnostische instellingen, en netwerkconfiguraties. Deze back-ups moeten minimaal elk kwartaal worden gemaakt, en vaker voor hoogst kritieke omgevingen. De back-ups moeten worden opgeslagen op een veilige locatie die gescheiden is van de productie-omgeving, en moeten worden getest om te verifiëren dat zij kunnen worden gebruikt voor herstel in het geval van een noodsituatie. Organisaties moeten ook documentatie bijhouden van alle configuratiewijzigingen, zodat zij een volledig overzicht hebben van de historische configuratie van de Key Vault.

Compliance en Auditing

De implementatie van Transparent Data Encryption met door de klant beheerde sleutels draagt significant bij aan de naleving van verschillende internationale en nationale compliance-standaarden en regelgeving. Organisaties die opereren in gereguleerde sectoren moeten kunnen aantonen dat zij volledige controle hebben over de versleutelingssleutels die worden gebruikt om hun gevoelige data te beschermen. Deze controle is niet alleen een best practice, maar vaak ook een wettelijke vereiste die moet worden aangetoond tijdens compliance-audits en regulatoire inspecties.

Voor organisaties die voldoen aan de CIS Azure Foundations Benchmark v3.0.0, is control 4.1.3 van directe relevantie. Deze control vereist specifiek dat de TDE protector (de versleutelingssleutel die wordt gebruikt om de databaseversleutelingssleutel te versleutelen) zelf is versleuteld met een door de klant beheerde sleutel in plaats van een door Microsoft beheerde sleutel. Deze control is geclassificeerd als Level 2, wat betekent dat het wordt aanbevolen voor omgevingen met verhoogde beveiligingsvereisten. Door TDE CMK te implementeren, voldoen organisaties automatisch aan deze control en kunnen zij dit aantonen tijdens CIS-compliance-audits door de TDE-configuratie te documenteren en te verifiëren dat de door de klant beheerde sleutel actief is.

De ISO 27001:2022 standaard, die de internationale norm is voor informatiebeveiligingsmanagementsystemen, bevat in control A.10.1.2 specifieke vereisten voor sleutelbeheer. Deze control vereist dat organisaties een formeel proces hebben voor het beheren van cryptografische sleutels, inclusief sleutelgeneratie, sleuteldistributie, sleutelopslag, sleutelrotatie en sleutelvernietiging. TDE CMK-implementatie voldoet aan deze vereisten door organisaties volledige controle te geven over alle aspecten van de sleutellevenscyclus. Organisaties kunnen aantonen dat zij zelf de sleutels genereren binnen hun eigen Key Vault, dat zij de sleutels roteren volgens een gedefinieerd schema, en dat zij volledige auditlogboeken hebben van alle sleuteloperaties via Key Vault diagnostische logs.

De NIS2-richtlijn (Network and Information Systems Directive 2), die van toepassing is op essentiële entiteiten en belangrijke entiteiten in de Europese Unie, bevat in Artikel 21 specifieke vereisten voor cryptografische maatregelen en sleutelbeheer. Dit artikel vereist dat organisaties passende technische en organisatorische maatregelen treffen om de beveiliging van netwerk- en informatiesystemen te waarborgen, inclusief het gebruik van cryptografie en het beheer van cryptografische sleutels. TDE CMK-implementatie voldoet aan deze vereisten door organisaties volledige controle te geven over de versleutelingssleutels en door te waarborgen dat sleutels binnen de geografische grenzen van de organisatie blijven, wat belangrijk is voor data-soevereiniteitseisen.

De Algemene Verordening Gegevensbescherming (AVG), ook bekend als GDPR, bevat in Artikel 32 specifieke vereisten voor de beveiliging van verwerking van persoonsgegevens. Dit artikel vereist dat organisaties passende technische en organisatorische maatregelen treffen om persoonsgegevens te beveiligen, inclusief pseudonimisering en versleuteling. Voor organisaties die persoonsgegevens verwerken in Azure SQL Database, is TDE CMK een belangrijke maatregel om te voldoen aan deze vereisten. Bovendien vereist de AVG dat organisaties kunnen aantonen dat zij volledige controle hebben over de verwerking van persoonsgegevens, wat wordt ondersteund door het gebruik van door de klant beheerde sleutels die volledig onder de controle van de organisatie staan in plaats van Microsoft.

Voor Nederlandse overheidsorganisaties is de BIO (Baseline Informatiebeveiliging Overheid) van directe relevantie. Thema 10.01.02 van de BIO bevat specifieke vereisten voor sleutelbeheer, waarbij wordt vereist dat organisaties een formeel proces hebben voor het beheren van cryptografische sleutels. TDE CMK-implementatie voldoet aan deze vereisten door organisaties volledige controle te geven over de versleutelingssleutels, inclusief sleutelgeneratie, sleutelrotatie en sleutelrevocatie. Overheidsorganisaties moeten kunnen aantonen dat zij voldoen aan deze vereisten tijdens BIO-audits, wat wordt gefaciliteerd door de uitgebreide auditlogboeken die beschikbaar zijn via Key Vault diagnostische logs en door de documentatie van het sleutelbeheerproces.

Remediatie

Gebruik PowerShell-script sql-tde-customer-managed-keys.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie van problemen met Transparent Data Encryption door de klant beheerde sleutels vereist een gestructureerde aanpak die rekening houdt met de kritieke aard van versleutelingssleutels en de impact die configuratiefouten kunnen hebben op database-toegankelijkheid. Organisaties moeten een uitgebreid remediatieproces ontwikkelen dat verschillende scenario's dekt, van eenvoudige configuratiefouten tot complexe noodsituaties waarbij toegang tot versleutelde databases is verloren. Het is essentieel dat alle remediatie-activiteiten worden uitgevoerd door gekwalificeerd personeel met de juiste autorisaties en dat alle acties worden gedocumenteerd voor audit-doeleinden.

Het meest voorkomende remediatiescenario betreft het herstellen van een SQL Server die nog steeds is geconfigureerd met door Microsoft beheerde sleutels in plaats van door de klant beheerde sleutels. Dit probleem wordt meestal gedetecteerd tijdens compliance-audits of wanneer organisaties hun beveiligingspostuur evalueren. De remediatieprocedure begint met het verifiëren van de huidige TDE-configuratie via de Azure Portal of Azure PowerShell. Organisaties moeten navigeren naar de Transparent data encryption blade van de SQL Server en controleren of de status 'Service-managed key' toont in plaats van 'Customer-managed key'. Zodra dit is bevestigd, moeten organisaties de volledige implementatieprocedure volgen zoals beschreven in de implementatiesectie, beginnend met het opzetten van een Azure Key Vault indien deze nog niet bestaat, gevolgd door het genereren van een versleutelingssleutel, het configureren van de SQL Server beheerde identiteit, het verlenen van toegang tot de Key Vault, en tenslotte het configureren van TDE om de door de klant beheerde sleutel te gebruiken. Het is belangrijk om te begrijpen dat tijdens deze overgang alle databases op de SQL Server automatisch worden herversleuteld met de nieuwe door de klant beheerde sleutel, wat een transparant proces is dat geen downtime veroorzaakt.

Een kritieker remediatiescenario betreft situaties waarbij de SQL Server geen toegang meer heeft tot de Key Vault, wat resulteert in geblokkeerde database-toegang. Dit kan worden veroorzaakt door verschillende factoren, waaronder het per ongeluk verwijderen of wijzigen van Key Vault toegangsbeleidsregels, netwerkproblemen die de verbinding tussen de SQL Server en de Key Vault blokkeren, of problemen met de beheerde identiteit. De eerste stap in de remediatieprocedure is het diagnosticeren van het exacte probleem door de Key Vault diagnostische logs te controleren en te identificeren welke specifieke operatie faalt. Als het probleem wordt veroorzaakt door incorrecte rechten, moeten organisaties de toegangsbeleidsregel of RBAC-roltoewijzing verifiëren en ervoor zorgen dat de SQL Server beheerde identiteit de juiste rechten heeft: Get, Wrap Key en Unwrap Key. Als de beheerde identiteit niet langer bestaat of is verwijderd, moet deze opnieuw worden geactiveerd via de Identity blade van de SQL Server. Voor netwerkproblemen moeten organisaties verifiëren dat de Key Vault firewall-regels de SQL Server beheerde identiteit toestaan, of dat Private Endpoints correct zijn geconfigureerd indien deze worden gebruikt.

In scenario's waarbij de versleutelingssleutel zelf is verwijderd of beschadigd, is de remediatieprocedure complexer en vereist dit toegang tot Key Vault back-upprocedures. Als Soft Delete is ingeschakeld op de Key Vault, kunnen verwijderde sleutels worden hersteld binnen de bewaarperiode (meestal 90 dagen). Organisaties moeten navigeren naar de Key Vault, de sectie voor verwijderde sleutels openen, de verwijderde sleutel identificeren, en deze herstellen. Na het herstellen van de sleutel moet de SQL Server TDE protector worden bijgewerkt om te verwijzen naar de herstelde sleutelversie. Als de sleutel niet kan worden hersteld of als Purge Protection is ingeschakeld en de sleutel definitief is verwijderd, moeten organisaties hun break-glass herstelprocedures activeren. Deze procedures moeten gedetailleerde instructies bevatten voor het herstellen van toegang tot versleutelde databases, inclusief contactgegevens van sleutelpersoneel, escalatieprocedures, en tijdlijnen voor herstel. In extreme gevallen waarbij de sleutel volledig verloren is gegaan en niet kan worden hersteld, kunnen organisaties worden gedwongen om databases te herstellen vanuit back-ups die zijn gemaakt voordat de sleutel verloren ging, wat kan resulteren in dataverlies voor transacties die plaatsvonden na het laatste back-uppunt.

Sleutelrotatieproblemen vormen een ander belangrijk remediatiescenario. Wanneer een sleutel nadert zijn vervaldatum maar de rotatieprocedure niet correct is uitgevoerd, kunnen organisaties worden geconfronteerd met databases die niet langer toegankelijk zijn zodra de sleutel verloopt. De remediatieprocedure begint met het onmiddellijk genereren van een nieuwe sleutelversie in de Key Vault. Deze nieuwe versie moet dezelfde configuratie hebben als de oorspronkelijke sleutel (RSA, minimaal 2048-bit, bij voorkeur 3072 of 4096-bit). Zodra de nieuwe sleutelversie is gegenereerd, moeten organisaties de SQL Server TDE protector bijwerken om de nieuwe sleutelversie te gebruiken. Als de organisatie heeft gekozen voor 'Always use current version' in de TDE-configuratie, zal de SQL Server automatisch de nieuwe versie gebruiken zodra deze beschikbaar is. Als een specifieke versie is geselecteerd, moeten organisaties handmatig de TDE protector bijwerken. Na de update moeten organisaties verifiëren dat alle databases succesvol zijn overgezet naar de nieuwe sleutelversie door de versleutelingsstatus van elke database te controleren.

Voor scenario's waarbij de Key Vault zelf niet meer toegankelijk is of is verwijderd, moeten organisaties hun disaster recovery-procedures activeren. Deze procedures moeten vooraf zijn gedocumenteerd en regelmatig worden getest om ervoor te zorgen dat organisaties in staat zijn om snel te reageren op dergelijke kritieke situaties. De eerste stap is het verifiëren of de Key Vault kan worden hersteld via Azure's Soft Delete-functionaliteit, indien deze was ingeschakeld. Als de Key Vault kan worden hersteld, moeten organisaties alle configuraties verifiëren, inclusief toegangsbeleidsregels, diagnostische instellingen, en netwerkconfiguraties, om ervoor te zorgen dat alles correct is hersteld. Als de Key Vault niet kan worden hersteld, moeten organisaties een nieuwe Key Vault opzetten met dezelfde configuratie als de oorspronkelijke, een nieuwe versleutelingssleutel genereren, en de SQL Server TDE protector bijwerken om de nieuwe sleutel te gebruiken. Het is belangrijk om te begrijpen dat als de oorspronkelijke sleutel niet kan worden hersteld, alle databases die zijn versleuteld met die sleutel niet langer toegankelijk zijn, tenzij er back-ups beschikbaar zijn die kunnen worden hersteld.

Preventieve remediatie vormt een belangrijk onderdeel van een effectief sleutelbeheerprogramma. Organisaties moeten proactieve monitoring implementeren die potentiële problemen detecteert voordat deze kritieke impact hebben. Dit omvat het regelmatig controleren van Key Vault toegangsbeleidsregels om ervoor te zorgen dat de SQL Server beheerde identiteit nog steeds de juiste rechten heeft, het monitoren van sleutelvervaldatums en het genereren van waarschuwingen voordat sleutels verlopen, en het regelmatig testen van break-glass herstelprocedures om ervoor te zorgen dat deze effectief zijn wanneer ze nodig zijn. Door deze preventieve maatregelen te implementeren, kunnen organisaties het risico op kritieke remediatiescenario's aanzienlijk verminderen en ervoor zorgen dat hun TDE CMK-implementatie betrouwbaar en compliant blijft.

Compliance & Frameworks

• CIS M365: Control 4.1.3 (L2) - CIS Azure v3.0.0 - 4.1.3: TDE protector versleuteld met Customer-beheerde Key
• BIO: 10.01.02 - BIO Baseline Informatiebeveiliging Overheid - Thema 10: Sleutelbeheer - Customer-beheerde versleutelingssleutels
• ISO 27001:2022: A.10.1.2 - sleutelbeheer
• NIS2: Artikel - versleuteling sleutelbeheer en data sovereignty

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

Transparent Data Encryption met Customer-Managed Keys (TDE CMK) geeft organisaties volledige controle over database-versleutelingssleutels via Azure Key Vault in plaats van Microsoft-Managed Keys. CMK biedt: Volledige sleutelbeheer waarbij organisaties zelf RSA-sleutels creëren, roteren en revoceren volgens eigen beleid zonder afhankelijkheid van Microsoft, Noodrevocatie van sleutels waarbij toegang tot versleutelde gegevens onmiddellijk kan worden ingetrokken door Key Vault-toegang uit te schakelen (bijvoorbeeld bij vermoedelijke inbreuk of regulatorisch onderzoek), Volledige auditlogboeken via Key Vault diagnostische logs die ALLE sleuteloperaties loggen (Get, Wrap, Unwrap met tijdstempels en identiteit), Gegevenssoevereiniteit waarbij versleutelingssleutels binnen specifieke Azure-regio's en onder controle van de klant blijven voor compliance met regionale gegevensbeschermingswetten, Geografische sleutelresidency-controle voor multinationals met land-specifieke gegevensresidency-vereisten. CMK-implementatie: Azure Key Vault creëren met Soft Delete en Purge Protection (verplicht voor productiesleutels), RSA-sleutel genereren (2048-bit minimum, 3072/4096 aanbevolen voor hogere beveiliging), SQL Server Managed Identity inschakelen en Key Vault-toegang verlenen (Get/Wrap/Unwrap rechten), TDE configureren om CMK te gebruiken in plaats van Microsoft-Managed Key. Belangrijke operationele vereisten: Sleutelrotatie elke 90-180 dagen voor beveiligingsbest practices (handmatig proces of geautomatiseerd via Azure Automation), Key Vault hoge beschikbaarheid via geo-redundante opslag en back-upsleutels, Break-glass procedures voor sleutelherstel bij Key Vault-problemen. Deze maatregel is verplicht voor: Gereguleerde sectoren (financiën onder DNB/AFM, gezondheidszorg met patiëntgegevens, overheid met geclassificeerde informatie), Databases met strikte gegevenssoevereiniteitsvereisten onder AVG/NIS2, Organisaties met interne beleidsregels die volledige cryptografische controle vereisen. Optioneel voor: Standaard bedrijfsdatabases zonder strikte soevereiniteitsvereisten (Microsoft-Managed Keys zijn cryptografisch equivalent qua beveiliging). Implementatie-inspanning: 3-5 uur (Key Vault setup 1 uur, sleutelcreatie en SQL-configuratie 1-2 uur, testen 1 uur, sleutelrotatie-automatisering 1 uur). Kosten: Key Vault-operaties minimaal (€0,025 per 10K operaties), sleutelopslag verwaarloosbaar. Doorlopende inspanning: 2-4 uur per kwartaal voor sleutelrotatie. Return on investment komt van: compliance-bereiking voor gegevenssoevereiniteitsvereisten, regelgevende goedkeuring, verbeterde beveiligingspositie, en noodrevocatiemogelijkheden voor sleutels.

• Implementatietijd: 5 uur
• FTE required: 0.05 FTE