Maak kennis met het nieuwe concept van Crypto-Shredding

Crypto-shredding is de techniek waarbij de encryptiesleutel die een dataset beschermt permanent wordt vernietigd, in plaats van de data zelf te verwijderen. Hierdoor wordt de data in de praktijk onherstelbaar. Dit is belangrijk omdat organisaties hiermee kunnen voldoen aan verzoeken om "recht op verwijdering" (AVG-artikel 17) voor back-ups en replica's, zonder elke kopie afzonderlijk te hoeven opsporen. Aanbevolen actie: gebruik de ingebouwde workflow voor sleutelvernietiging van uw cloud-KMS met een weloverwogen wachttijd en combineer deze met sterke encryptie, zodat de techniek daadwerkelijk effectief is.

Gepubliceerd: augustus 2021. Bijgewerkt: augustus 2026. Beoordeeld door het Cloud Key Management Team van Encryption Consulting.

Voor meer informatie over hoe de bredere nalevingsverplichtingen van de AVG van toepassing zijn op cloudomgevingen, naast het vernietigen van sleutels, zie ons artikel Cloud Security Compliance Standards – PCI DSS and GDPR . Voor meer informatie over de verschillen tussen de onderliggende KMS-systemen van verschillende aanbieders, zie AWS KMS Vs Azure Key Vault Vs GCP KMS.

Wat is cryptovernietiging?

Crypto-shredding is de techniek waarbij de encryptiesleutel voor een dataset wordt weggegooid zonder de versleutelde gegevens zelf te wissen of te verwijderen. Hierdoor worden die gegevens in de praktijk permanent onleesbaar. Gegevensbescherming is een belangrijk thema geworden, omdat datalekken en strengere regelgeving ervoor hebben gezorgd dat encryptie de standaard is geworden in diverse sectoren. Het versleutelen van alles creëert echter een tweede probleem: wat er met versleutelde gegevens moet gebeuren zodra deze vernietigd moeten worden.

Versleutelde gegevens vallen over het algemeen in twee categorieën. Actief versleutelde gegevens worden momenteel gebruikt door applicaties en verwerkt binnen het normale beveiligingssysteem. Passief versleutelde gegevens worden niet actief gebruikt en komen in aanmerking voor vernietiging, bijvoorbeeld omdat een bewaartermijn is verlopen of omdat een betrokkene zijn recht op verwijdering heeft uitgeoefend. Crypto-shredding is de praktische oplossing voor de passieve categorie.

Waarom is het verwijderen van gegevens in het kader van het GDPR-recht op verwijdering zo moeilijk?

Het correct vernietigen van gegevens is een lastige opgave wanneer dit als een individueel recht wordt uitgeoefend, met name onder gegevensbeschermingsregelgeving zoals artikel 17 van de AVG. Om het recht op verwijdering letterlijk te respecteren, moet een organisatie elke verwijzing naar de gegevens van een specifiek individu opsporen in productiedatabases, logbestanden, back-ups, datawarehouses en alle daaropvolgende exporten, en vervolgens elke kopie verwijderen. Dat is geen eenvoudige taak: back-ups zijn vaak onveranderlijk, juist vanwege de bescherming tegen ransomware die ze zo waardevol maakt; logbestanden kunnen onderworpen zijn aan een aparte bewaarplicht; en een daaropvolgende export voor analyses kan de gegevens al hebben verspreid naar een locatie waar het oorspronkelijke systeem geen toegang toe heeft.

Hoe lost cryptovernietiging het probleem van datavernietiging op?

Crypto-shredding omzeilt het probleem van zoeken en verwijderen volledig. Omdat de gegevens al versleuteld waren voordat ze ergens werden opgeslagen, maakt het vernietigen van de sleutel elke kopie van die gegevens (productie, back-up, logboek, export) in één keer onleesbaar, zonder dat elke kopie afzonderlijk hoeft te worden gelokaliseerd. Als de versleutelingssleutel is vernietigd en er geen andere kopie meer van bestaat, kunnen de gegevens die met die sleutel beveiligd waren door niemand worden ontsleuteld , waar ze zich ook fysiek bevinden.

Twee voorwaarden moeten gelden wil dit daadwerkelijk werken. Ten eerste mag er geen andere kopie van de sleutel bestaan; een sleutel die in een tweede systeem is opgeslagen, in een applicatieproces is gecached of apart is geback-upt, maakt de hele techniek onbruikbaar. Ten tweede moet het encryptiealgoritme zelf ongeschonden blijven; als de versleuteling die de gegevens beschermt, te kraken was, zou deze al door NIST of een andere standaardisatie-instantie als verouderd zijn bestempeld en had deze überhaupt niet gebruikt mogen worden. Dit is dus een redelijke aanname voor elk momenteel goedgekeurd algoritme (bijvoorbeeld AES-256). Gezien beide voorwaarden is crypto-shredding functioneel gelijk aan het verwijderen of wissen van de gegevens zelf, ook al zijn de versleutelde bytes fysiek nog steeds aanwezig op de schijf.

In de praktijk verandert dit de betekenis van een "verwijder"-verzoek op infrastructuurniveau. Wanneer nieuwe data wordt aangemaakt en opgeslagen, geback-upt of gerepliceerd moet worden, wordt deze eerst versleuteld met een sleutel die specifiek is voor die data (per tenant, per gebruiker of per record, afhankelijk van de granulariteitsvereisten). Wanneer die data verwijderd moet worden, zoekt het systeem niet in de infrastructuur naar elke kopie, maar verwijdert het de versleutelingssleutel.

Hoe beïnvloedt het gebruik van interne versus externe sleutelbeheer het vernietigen van cryptovaluta?

De locatie van de sleutel bepaalt hoe snel, hoe traceerbaar en hoe omkeerbaar een cryptovernietigingsoperatie daadwerkelijk is.

Sleutelbesturingsmodel	Hoe vernietiging werkt	Beste pasvorm
Native cloudbeheer (AWS KMS, Azure Key Vault, Google Cloud KMS)	De cloudprovider hanteert een verplichte wachttijd voordat gegevens definitief worden verwijderd (zie onderstaande tabel). Tijdens deze periode kan de bewerking worden geannuleerd.	De meeste workloads. Biedt een goede balans tussen een degelijk vangnet tegen onbedoelde/kwaadwillige verwijdering en een uiteindelijke, door de provider afgedwongen permanente vernietiging.
BYOK (door de klant aangeleverd sleutelmateriaal, gehost in de cloud)	Dezelfde door de provider beheerde vernietigingsworkflow als bij native sleutels, maar de organisatie behoudt een eigen kopie van het originele sleutelmateriaal buiten de cloud. Deze kopie moet ook worden vernietigd om de cryptografische vernietiging te voltooien.	Organisaties die de herkomst of overdraagbaarheid van belangrijke gegevens moeten bewijzen, maar het geen probleem vinden dat de HSM in het dagelijks beheer bij de cloudprovider blijft.
HYOK / externe sleutelbeheerder (Cloud EKM, AWS External Key Store, Azure Managed HSM met een externe root)	De KMS-sleutel van de cloud verwijst naar een sleutel die wordt beheerd door een externe sleutelbeheerder; het vernietigen van de sleutel in het externe systeem heeft onmiddellijk effect en staat los van de eigen bewaartermijn van de cloud.	Sterk gereguleerde data waarbij een organisatie moet aantonen dat zij, en niet de cloudprovider, de uiteindelijke controle had over de vernietiging van de gegevens, en waarbij onmiddellijke, provideronafhankelijke vernietiging een uitdrukkelijke vereiste is.

De meeste organisaties zouden moeten vertrouwen op de native, in de cloud beheerde vernietiging van sleutels met de ingebouwde wachttijd; dit is traceerbaar, omkeerbaar binnen de aangegeven periode en vereist geen extra infrastructuur. Stap alleen over op een extern/HYOK-model wanneer een specifieke wettelijke of contractuele vereiste vernietiging voorschrijft die niet afhankelijk is van het proces van de cloudprovider.

Hoe moet IAM bepalen wie een sleutel mag vernietigen?

Het vernietigen van een sleutel is een van de weinige cryptografische bewerkingen die niet ongedaan gemaakt kan worden zodra de wachttijd is verstreken. Daarom zou het IAM-model hiervoor strenger moeten zijn dan bij gewone sleutelgebruiksrechten.

1. Scheid de machtigingen voor "sleutelgebruik" (versleutelen/ontsleutelen) van de machtigingen voor "het plannen van de vernietiging van de sleutel"; vrijwel geen enkele identiteit heeft beide nodig.
2. Vereis een gedocumenteerde, vastgelegde rechtvaardiging (een specifiek verwijderingsverzoek-ID, een vervaldatum van het bewaarbeleid) voordat de vernietiging van sleutels wordt ingepland.
3. Gebruik een tweede goedkeuringsprocedure of een noodprocedure voor vernietigingsverzoeken van sleutels die de gegevens van meer dan één betrokkene beschermen, aangezien een foutieve vernietiging van meerdere sleutels een dataverlies is en geen winstpunt voor de privacy.
4. Geef ruime rechten om geplande vernietiging te annuleren (een beveiligingsbeheerder moet altijd snel een vernietiging tijdens de uitvoering kunnen stoppen), zelfs als de rechten om vernietiging te initiëren beperkt blijven.
5. Registreer elke geplande, geannuleerde en voltooide vernietigingsgebeurtenis in een systeem dat de vernietigende entiteit zelf niet kan wijzigen.

Hoe verhoudt sleutelrotatie zich tot cryptovernietiging?

Rotatie en crypto-shredding zijn tegenovergestelde bewerkingen die gemakkelijk door elkaar gehaald kunnen worden. Bij rotatie wordt een nieuwe actieve sleutelversie aangemaakt, terwijl oude versies opzettelijk bewaard blijven, zodat eerder versleutelde gegevens decodeerbaar blijven; geen van de drie grote cloud-KMS-producten vernietigt oude sleutelversies automatisch bij rotatie. Crypto-shredding is de opzettelijke, tegenovergestelde actie: het opzettelijk vernietigen van een specifieke sleutelversie, waardoor de gegevens die deze beschermt permanent onherstelbaar worden.

De twee werken samen in encryptiearchitecturen per tenant of per record: als een systeem een ​​gedeelde sleutel roteert voor de gegevens van meerdere tenants, kan een crypto-shreddingsverzoek van een individuele tenant die gedeelde sleutel niet vernietigen zonder ook de toegang van alle andere tenants te blokkeren. Fijnmazige crypto-shredding vereist een fijnmazige sleutelarchitectuur (één sleutel, of één sleutelversie, per data-eenheid die voor verwijdering in aanmerking komt) die tijdens het ontwerp wordt bepaald en niet achteraf wordt toegevoegd nadat het eerste verwijderingsverzoek is ontvangen.

Wat moet je vastleggen voor het vernietigen van cryptovaluta om een ​​audit te kunnen doorstaan?

• Het verwijderingsverzoek dat de vernietiging in gang zette: Het specifieke ticket met recht op verwijdering, de regel in het bewaarbeleid of het incident dat de actie rechtvaardigde.
• Evenementenplanning en annuleringen: Wie heeft de vernietiging gepland, wanneer, en of deze is geannuleerd voordat de wachtperiode afliep.
• Bevestiging van voltooide vernietiging: Het tijdstempel waarop de sleutel permanent onherstelbaar werd, dient als bewijs voor een voltooid verwijderingsverzoek.
• Omzetting van sleutel naar gegevensbereik: welke records, huurders of betrokkenen door die specifieke sleutel worden beschermd, zodat een auditor kan controleren of de vernietiging daadwerkelijk de reikwijdte van het verwijderingsverzoek omvat.

Wat kost het vernietigen van cryptovaluta?

Cryptografische vernietiging wordt door geen enkele grote cloud-KMS apart in rekening gebracht; het plannen en voltooien van sleutelvernietiging is inbegrepen in de standaard KMS-bewerkingen. De werkelijke kostenfactor is architectonisch: het ondersteunen van gedetailleerde cryptografische vernietiging (één sleutel per tenant of per record, in plaats van één gedeelde sleutel voor een volledige dataset) verhoogt het aantal actieve sleutels dat een KMS moet beheren, en de prijs per sleutel of per HSM-partitie (met name voor HSM-ondersteunde sleutels) schaalt mee met dat aantal. Een ontwerp dat individuele klantrecords moet vernietigen, en niet alleen volledige datasets, moet een aanzienlijk grotere sleutelvoorraad budgetteren dan een ontwerp met één sleutel per dataset.

De versleutelde gegevens zelf worden niet verwijderd door crypto-shredding, dus de opslagkosten voor die nu permanent ontoegankelijke versleutelde tekst blijven bestaan ​​totdat een apart beleid voor de levenscyclus van de opslag deze verwijdert. Houd rekening met deze doorlopende opslagkosten in een bewaarbeleid in plaats van ervan uit te gaan dat crypto-shredding alleen de kosten voor het bewaren van de gegevens dekt.

Hoe ziet een multi-cloud architectuur voor het vernietigen van cryptovaluta eruit?

Elke grote cloudprovider implementeert een eigen methode voor het vernietigen van sleutels, met een vergelijkbare structuur maar verschillende details. Dit is van belang voor een organisatie die één consistent verwijderingsproces wil hanteren voor alle drie de cloudproviders.

Cloud	Standaard wachttijd	Instelbaar bereik
AWS KMS	30 dagen	7-30 dagen
Azure Key Vault (soft-delete)	90 dagen	7-90 dagen, alleen in te stellen bij het aanmaken van de kluis.
Google Cloud KMS	30 dagen	Aanpasbaar per sleutel bij het aanmaken; organisaties kunnen een minimum afdwingen via een beleidsbeperking.

Een workflow voor het wissen van gegevens in meerdere clouds (waarbij de gegevens van één klant verspreid zijn over AWS, Azure en GCP) moet rekening houden met het feit dat de standaard bewaartermijn van Azure drie keer langer is dan die van AWS of GCP. Dit is van belang bij het rapporteren van een voltooiingsdatum voor een GDPR-verzoek tot gegevensverwijdering dat meerdere clouds omvat. Standaardiseer de kortste bewaartermijn die binnen uw risicotolerantie valt voor alle drie de clouds, in plaats van drie verschillende voltooiingsdata aan dezelfde betrokkene te rapporteren.

Wat zijn de beperkingen van cryptovernietiging?

• Het werkt alleen als de versleuteling sterk was en er geen sleutelbewaring of back-upkopie bestaat; een zwakke versleuteling of een vergeten sleutelback-up maakt de "vernietiging" slechts cosmetisch.
• De versleutelde gegevens zelf nemen nog steeds opslagruimte in beslag en vereisen nog steeds een eigen levenscyclus-/bewaarbeslissing.
• Geen enkele belangrijke normeringsinstantie (inclusief NIST) schrijft crypto-shredding momenteel voor als een gecertificeerde methode voor gegevenssanering; NIST SP 800-88 Rev. 1 blijft de referentiestandaard voor het saneren van media, en organisaties die een gecertificeerde saneringsclaim nodig hebben, dienen deze direct te toetsen aan die standaard in plaats van alleen op crypto-shredding te vertrouwen.
• Fijnmazige (per record) cryptografische vernietiging vereist dat de sleutelarchitectuur daar vooraf op is ontworpen; het kan niet zomaar achteraf worden ingebouwd in een systeem dat is gebouwd rond één gedeelde sleutel.

Besluitchecklist: Crypto-Shredding implementeren

1. Controleer of elke dataset die mogelijk afzonderlijk gewist moet worden, versleuteld is met een eigen sleutel of sleutelversie, en niet met een gedeelde sleutel voor de hele dataset.
2. Kies standaard voor native cloud-beheerde sleutelvernietiging; reserveer externe/HYOK-vernietiging voor gevallen met een specifieke vereiste voor provideronafhankelijkheid.
3. Vereis een tweede goedkeurder en een gedocumenteerde onderbouwing voor elk verzoek tot vernietiging van sleutels.
4. Registreer het verwijderingsverzoek, de geplande/geannuleerde gebeurtenissen en de bevestiging van de voltooide vernietiging als auditspoor voor de verwijdering.
5. Combineer het vernietigen van sleutels met een apart beleid voor de levensduur van de opslag, zodat de nu onleesbare versleutelde tekst niet oneindig blijft bestaan.

Wat zou Encryption Consulting aanbevelen?

De organisaties die de dupe worden van crypto-shredding zijn bijna altijd de organisaties die hun encryptiearchitectuur hebben ontworpen rond één gedeelde sleutel per dataset, en die vervolgens bij het eerste individuele verwijderingsverzoek ontdekken dat ze geen enkel record kunnen verwijderen zonder ook alle andere records onder dezelfde sleutel te beschadigen. De Cloud Key Management-services van Encryption Consulting ontwerpen de sleutelarchitectuur per tenant of per record, de goedkeuringsworkflow voor verwijdering en het auditspoor dat nodig is om een ​​op crypto-shredding gebaseerd verwijderingsproces te verdedigen. Ons HSM-as-a-Service- aanbod biedt hardware-ondersteunde bewaring van die sleutelinventaris zonder de operationele overhead van het zelf beheren van HSM's.

Veelgestelde Vragen / FAQ

Is cryptovernietiging een officieel erkende standaard voor gegevenssanering?

Nee. Er bestaat geen standaard van NIST, GDPR of een andere autoriteit die crypto-shredding formeel voorschrijft als een gecertificeerde saneringsmethode. NIST Special Publication 800-88 Revision 1 blijft het referentiedocument voor mediasanering in het algemeen, en organisaties die een certificeerbare claim nodig hebben, dienen zich direct aan die standaard te toetsen.

Voldoet het vernietigen van cryptografie aan het recht op verwijdering van gegevens zoals vastgelegd in de AVG?

Het wordt veelvuldig gebruikt als een praktisch mechanisme om te voldoen aan verzoeken op grond van artikel 17, met name bij back-ups en replica's waarbij anders elke kopie afzonderlijk zou moeten worden opgespoord en verwijderd. Het is een technische controle, geen wettelijke garantie; of het voldoet aan de verwachtingen van een specifieke toezichthouder hangt af van de sterkte van de encryptie en de afwezigheid van een overgebleven sleutelkopie.

Kan ik de gegevens van één enkele klant cryptografisch vernietigen als die klant dezelfde sleutel deelt met andere klanten?

Niet zonder de toegang van elke andere klant tot gegevens onder diezelfde sleutel te blokkeren. Gedetailleerde cryptografische vernietiging vereist een sleutelarchitectuur per gebruiker of per record, die vanaf het begin is ontworpen.

Hoe lang duurt het voordat een sleutel permanent wordt verwijderd op AWS, Azure of GCP?

AWS KMS hanteert standaard een wachttijd van 30 dagen (configureerbaar van 7 tot 30 dagen), Azure Key Vault gebruikt standaard een wachttijd van 90 dagen voor soft-delete (configureerbaar van 7 tot 90 dagen, in te stellen bij het aanmaken van de kluis), en Google Cloud KMS hanteert standaard een wachttijd van 30 dagen, aanpasbaar per sleutel en afhankelijk van eventuele minimumvereisten in het organisatiebeleid.

Wat gebeurt er met de versleutelde gegevens nadat de sleutel is vernietigd?

Het blijft precies waar het was, het neemt nog steeds opslagruimte in beslag, maar is permanent onleesbaar. Crypto-shredding verwijdert of verplaatst de versleutelde tekst niet; een apart beleid voor de levenscyclus van de opslag is nodig om deze uiteindelijk te verwijderen.

Heeft u hulp nodig bij het ontwerpen van een sleutelarchitectuur die daadwerkelijk cryptografische vernietiging per record ondersteunt? Neem dan contact op met het Cloud Key Management-team van Encryption Consulting.

Informatiebronnen

NIST SP 800-88 Rev. 1: Richtlijnen voor het saneren van media