Bekanta dig med det nya konceptet kryptoförstöring

Kryptoförstöring är tekniken att permanent förstöra krypteringsnyckeln som skyddar en datamängd, snarare än att radera själva informationen, så att informationen i praktiken blir oåterställbar. Det är viktigt eftersom det låter organisationer uppfylla begäranden om "rätt till radering" (GDPR artikel 17) över säkerhetskopior och repliker utan att behöva leta upp varje kopia. Rekommenderad åtgärd: använd ditt moln-KMS:s inbyggda arbetsflöde för nyckelförstöring med en avsiktlig väntetid och para ihop det med stark kryptering så att tekniken faktiskt är sund.

Publicerad: augusti 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings Cloud Key Management Team.

För information om hur GDPR:s bredare efterlevnadsskyldigheter gäller i molnmiljöer utöver enbart nyckelförstöring, se vårt inlägg Cloud Security Compliance Standards – PCI DSS och GDPR . För information om hur det underliggande KMS skiljer sig mellan leverantörer, se AWS KMS Vs Azure Key Vault Vs GCP KMS.

Vad är kryptofragmentering?

Kryptoförstöring är tekniken att kassera krypteringsnyckeln för en datamängd utan att nollställa eller radera själva krypterade data, vilket gör dessa data permanent odekrypterbara i praktiken. Dataskydd har blivit ett huvudproblem i takt med att dataintrång och strängare reglering har gjort kryptering till standardställningen i alla branscher, men att kryptera allt skapar ett andra problem: att hantera vad som händer med krypterad data när den behöver förstöras.

Krypterad data delas generellt in i två kategorier. Aktivt krypterad data används för närvarande av applikationer och hanteras inom det normala säkerhetsekosystemet. Passivt krypterad data används inte aktivt och är en kandidat för förstörelse, antingen på grund av att en lagringsperiod har löpt ut eller att en registrerad person har utövat sin rätt till radering. Kryptofragmentering är det praktiska svaret på den passiva kategorin.

Varför är det så svårt att radera data enligt GDPR:s rätt till radering?

Dataförstöring är verkligen svårt att genomföra korrekt när det utövas som en individs rättighet, särskilt enligt dataskyddsregler som GDPR artikel 17. För att respektera rätten till radering bokstavligt måste en organisation lokalisera varje referens till en specifik individs data i produktionsdatabaser, loggar, säkerhetskopior, datalager och all nedströms export, och sedan radera varje kopia. Det är inte en enkel uppgift: säkerhetskopior är ofta oföränderliga av designen av just de skäl som gör dem värdefulla för att motstå ransomware, loggar kan vara föremål för ett separat lagringskrav, och en nedströms analysexport kan redan ha spridit informationen någonstans där det ursprungliga systemet inte har någon insyn.

Hur löser kryptofragmentering problemet med dataförstöring?

Kryptoförstöring kringgår problemet med sök-och-radering helt och hållet. Eftersom informationen krypterades innan den skrevs någonstans, gör förstörelsen av nyckeln att varje kopia av informationen (produktion, säkerhetskopiering, logg, export) blir odekrypterbar på en gång, utan att man någonsin behöver lokalisera varje kopia individuellt. Om krypteringsnyckeln förstörs och ingen annan kopia av den finns, kan informationen som nyckeln skyddade inte dekrypteras av någon, var den än råkar finnas fysiskt.

Två villkor måste uppfyllas för att detta faktiskt ska vara giltigt. För det första kan ingen annan kopia av nyckeln existera; en nyckel som är deponerad i ett andra system, cachad i en applikationsprocess eller säkerhetskopierad separat omintetgör hela tekniken. För det andra måste själva krypteringsalgoritmen förbli intakt; om chifferet som skyddar informationen var brytbart skulle det redan vara markerat som föråldrat av NIST eller ett annat standardiseringsorgan och borde inte ha använts från början, så detta är ett rimligt antagande för alla för närvarande godkända algoritmer (till exempel AES-256). Givet båda villkoren är kryptoförstöring funktionellt likvärdigt med att radera eller nollställa själva informationen, även om chiffertextbyten fortfarande finns fysiskt på disken.

I praktiken förändrar detta vad en "borttagningsbegäran" betyder på infrastrukturlagret. När ny data skapas och ska lagras, säkerhetskopieras eller replikeras, krypteras den först, under en nyckel som är avsedd för den informationen (per hyresgäst, per användare eller per post, beroende på granularitetskrav). När informationen behöver förstöras söker systemet inte igenom sin infrastruktur efter varje kopia; det tar bort krypteringsnyckeln.

Hur påverkar nativ kontra extern nyckelkontroll kryptoförstöring?

Var nyckeln finns avgör hur snabb, hur granskningsbar och hur reversibel en kryptofragmentering faktiskt är.

Nyckelkontrollmodell	Hur förstörelse fungerar	Bästa passform
Inbyggt molnhanterat (AWS KMS, Azure Key Vault, Google Cloud KMS)	Molnleverantören tillämpar en obligatorisk väntetid innan permanent förstöring (se tabellen nedan), under vilken åtgärden kan avbrytas.	De flesta arbetsbelastningar. Balanserar ett genuint skyddsnät mot oavsiktlig/skadlig radering med en eventuell, leverantörspåtvingad permanent förstörelse.
BYOK (kundlevererat nyckelmaterial, molnhostat)	Samma leverantörshanterade arbetsflöde för destruktion som för nativa nycklar, men organisationen behåller sin egen kopia av det ursprungliga nyckelmaterialet utanför molnet, vilket också måste förstöras för att kryptofragmenteringen ska vara fullständig.	Organisationer som behöver bevisa nyckelproveniens eller portabilitet men som är bekväma med molnleverantörens HSM-förvaring i det dagliga arbetet.
HYOK / extern nyckelhanterare (Cloud EKM, AWS External Key Store, Azure Managed HSM med en extern rot)	Molnets KMS-nyckel är en pekare till en nyckel som innehas av en extern nyckelhanterare; att förstöra nyckeln i det externa systemet träder i kraft omedelbart och är oberoende av molnets eget lagringsfönster.	Starkt reglerad data där en organisation behöver visa att den, inte molnleverantören, hade den slutgiltiga kontrollen över förstörelsehändelsen, och där en omedelbar, leverantörsoberoende strimling är ett uttalat krav.

De flesta organisationer bör förlita sig på inbyggd molnhanterad nyckelförstöring med dess inbyggda väntetid; den är granskningsbar, reversibel under fönstret och kräver ingen ytterligare infrastruktur. Byt till en extern/HYOK-modell endast när ett specifikt regulatoriskt eller avtalsenligt krav kräver förstöring som inte är beroende av molnleverantörens egen process.

Hur ska IAM styra vem som kan förstöra en nyckel?

Att förstöra en nyckel är en av få kryptografiska operationer utan möjlighet att ångra när väntetiden löpt ut, så dess IAM-modell bör vara strängare än vanliga nyckelanvändningsbehörigheter.

1. Separera behörigheterna "använd nyckeln" (kryptera/dekryptera) från behörigheterna "schemalägg förstörelse av nyckeln"; nästan ingen identitet behöver båda.
2. Kräv en dokumenterad, ärendebekräftad motivering (ett specifikt ID för raderingsbegäran, ett utgångsdatum för lagringspolicyn) innan någon nyckelförstöring schemaläggs.
3. Använd ett arbetsflöde för en andra godkännare eller ett system för att förstöra glaset för begäranden om förstörelse av nyckel som skyddar mer än en registrerads register, eftersom en felaktig massförstörelse av nyckelringar är en dataförlustincident, inte bara en integritetsvinst.
4. Bevilja allmänna rättigheter för att annullera schemalagd förstörelse (en säkerhetsadministratör bör alltid kunna stoppa en förstörelse under färd snabbt) även om rättigheterna för att initiera förstörelse förblir begränsade.
5. Logga alla schemalagda, avbrutna och slutförda förstörelsehändelser till ett system som den förstörande identiteten inte själv kan ändra.

Hur interagerar nyckelrotation med kryptoförstöring?

Rotation och kryptoförstöring är motsatta operationer som är lätta att blanda ihop. Rotation skapar en ny aktiv nyckelversion samtidigt som gamla versioner avsiktligt bevaras så att tidigare krypterad data förblir dekrypterbar; ingen av de tre största moln-KMS-produkterna förstör gamla nyckelversioner automatiskt vid rotation. Kryptoförstöring är den avsiktliga, motsatta handlingen: att förstöra en specifik nyckelversion med flit så att de data den skyddar blir permanent oåterkalleliga.

De två interagerar i krypteringsarkitekturer per hyresgäst eller per post: om ett system roterar en delad nyckel över många hyresgästers data, kan en enskild hyresgästs begäran om kryptoförstöring inte förstöra den delade nyckeln utan att också förstöra alla andra hyresgästers åtkomst. Finkornig kryptoförstöring kräver en finkornig nyckelarkitektur (en nyckel, eller en nyckelversion, per raderingsberättigad dataenhet) som bestäms vid designtillfället, och inte eftermonteras efter att den första raderingsbegäran anländer.

Vad ska du logga för att kryptofragmentering ska hålla i sig i en granskning?

• Begäran om radering som utlöste förstöring: den specifika rätten till radering, regeln i lagringspolicyn eller incidenten som motiverade åtgärden.
• Schemalägg och avbokning av evenemang: vem som planerade förstörelsen, när och om den ställdes in innan väntetiden löpte ut.
• Bekräftelse på fullbordad förstörelse: tidsstämpeln då nyckeln blev permanent oåterställbar, vilket är bevismaterialet för en slutförd raderingsbegäran.
• Mappning från nyckel till dataomfattning: vilka register, hyresgäster eller registrerade som den specifika nyckeln skyddade, så att en revisor kan verifiera att förstörelsen faktiskt täckte omfattningen av raderingsbegäran.

Vad kostar kryptoförstöring?

Kryptoförstöring i sig prissätts inte separat av något större moln-KMS; schemaläggning och slutförande av nyckelförstöring ingår i standard KMS-drift. Den verkliga kostnadsdrivaren är arkitektonisk: stöd för finkornig kryptoförstöring (en nyckel per hyresgäst eller per post, snarare än en delad nyckel för en hel datauppsättning) multiplicerar antalet aktiva nycklar som ett KMS måste hantera, och prissättning per nyckel eller per HSM-partition (särskilt för HSM-backade nycklar) skalas med det antalet. En design som behöver kryptoförstöra enskilda kundposter, inte bara hela datauppsättningar, bör budgetera för ett väsentligt större nyckellager än en design med en enda nyckel per datauppsättning.

Själva krypterade data raderas inte genom kryptostrimling, så lagringskostnaderna för den nu permanent oåtkomliga chiffertexten fortsätter tills en separat policy för lagringslivscykeln tar bort den. Kostnaden för att lagra data elimineras genom att man räknar in den löpande lagringskostnaden i en lagringspolicy, snarare än att anta att enbart kryptostrimling gör det.

Hur ser en arkitektur för kryptoförstöring i flera moln ut?

Varje större moln implementerar inbyggd nyckelförstöring med liknande form men olika detaljer, vilket är viktigt för en organisation som försöker köra en konsekvent raderingsprocess över alla tre.

cloud	Standardvänteperiod	Konfigurerbart intervall
AWS KMS	30 DAYS	7-30 dagar
Azure Key Vault (mjuk borttagning)	90 DAYS	7–90 dagar, inställs endast vid valvskapandet
Google Cloud KMS	30 DAYS	Anpassningsbar per nyckel vid skapandet; organisationer kan tillämpa ett minimum via en organisationspolicybegränsning

Ett arbetsflöde för radering i flera moln (en enskild kunds data spridda över AWS, Azure och GCP) måste ta hänsyn till att Azures standardfönster för lagring är tre gånger längre än AWS eller GCP, vilket är viktigt när man rapporterar ett slutförandedatum för en GDPR-raderingsbegäran som omfattar moln. Standardisera på det kortaste kompatibla fönstret som din risktolerans tillåter för alla tre, snarare än att rapportera tre olika slutförandedatum till samma registrerade.

Vilka är begränsningarna med kryptoförstöring?

• Det fungerar bara om krypteringen var stark och det inte finns någon nyckeldeposition eller säkerhetskopia; en svag chiffer eller en förbisedd nyckelsäkerhetskopia gör "förstörelsen" kosmetisk.
• Den krypterade informationen upptar fortfarande lagringsutrymme och kräver fortfarande ett eget livscykel-/lagringsbeslut.
• Inget större standardiseringsorgan (inklusive NIST) föreskriver för närvarande kryptostrimling som en certifierad datasaneringsmetod; NIST SP 800-88 Rev. 1 är fortfarande referensstandarden för mediasanering, och organisationer som behöver ett certifierbart saneringskrav bör utvärdera direkt mot den standarden snarare än att enbart förlita sig på kryptostrimling.
• Finkornig (per-post) kryptoförstöring kräver att nyckelarkitekturen utformas för det i förväg; det kan inte enkelt eftermonteras på ett system som är byggt kring en delad nyckel.

Beslutschecklista: Implementering av kryptoförstöring

1. Bekräfta att varje dataset som kan behöva raderas individuellt är krypterat under en egen nyckel eller nyckelversion, inte en delad nyckel för hela datasetet.
2. Välj inbyggd molnhanterad nyckelförstöring som standard; reservera extern/HYOK-förstöring för ärenden med ett specifikt krav på leverantörsoberoende.
3. Kräv en andra godkännare och en dokumenterad motivering för varje begäran om nyckelförstöring.
4. Logga raderingsbegäran, schemaläggnings-/avbrytningshändelserna och bekräftelsen på slutförd förstörelse som revisionslogg för raderingen.
5. Koppla ihop nyckelförstöring med en separat policy för lagringslivscykeln så att den nu odekrypterbara chiffertexten inte finns kvar i all oändlighet.

Vad skulle krypteringskonsulter rekommendera?

De organisationer som drabbas av kryptoförstöring är nästan alltid de som utformat sin krypteringsarkitektur kring en delad nyckel per dataset, och sedan vid den första individuella raderingsbegäran upptäckte att de inte kunde strimla en enda post utan att förstöra alla andra poster under samma nyckel. Encryption Consultings Cloud Key Management-tjänster utformar nyckelarkitekturen per hyresgäst eller per post, arbetsflödet för godkännande av förstöring och den revisionslogg som behövs för att göra en kryptoförstöringsbaserad raderingsprocess försvarbar, och vårt HSM-as-a-Service- erbjudande ger den nyckelinventeringen hårdvarubaserad förvaring utan den operativa omkostnaden för att köra HSM:er direkt.

Vanliga frågor om partihandel med mat och dryck

Är kryptofragmentering en officiellt erkänd standard för datasanering?

Nej. Det finns ingen standard från NIST, GDPR eller någon annan myndighet som formellt föreskriver kryptoförstöring som en certifierad saneringsmetod. NIST Special Publication 800-88 Revision 1 är fortfarande referensdokumentet för mediasanering generellt, och organisationer som behöver ett certifierbart påstående bör utvärdera det direkt mot den standarden.

Uppfyller kryptofragmentering GDPR:s rätt till radering?

Det används ofta som en praktisk mekanism för att tillgodose förfrågningar enligt Artikel 17, särskilt för säkerhetskopior och repliker som annars skulle kräva att varje kopia lokaliseras och raderas individuellt. Det är en teknisk kontroll, inte en rättslig garanti; huruvida den uppfyller en specifik tillsynsmyndighets förväntningar beror på krypteringsstyrkan och avsaknaden av någon överlevande nyckelkopia.

Kan jag kryptoförstöra en enskild kunds data om den delar en nyckel med andra kunder?

Inte utan att förstöra alla andra kunders åtkomst till data under samma nyckel. Finmaskig kryptoförstöring kräver en nyckelarkitektur per hyresgäst eller per post som är utformad från början.

Hur lång tid tar det för en nyckel att förstöras permanent på AWS, Azure eller GCP?

AWS KMS har som standard en vänteperiod på 30 dagar (konfigurerbar 7–30 dagar), Azure Key Vaults mjukborttagningsperiod har som standard 90 dagar (konfigurerbar 7–90 dagar, inställd vid skapandet av valvet) och Google Cloud KMS har som standard 30 dagar, justerbar per nyckel och med förbehåll för organisationens minimumpolicy.

Vad händer med den krypterade informationen efter att nyckeln har förstörts?

Den stannar exakt där den var, upptar fortfarande lagringsutrymme, men är permanent oläslig. Kryptoförstöring varken tar bort eller flyttar chiffertexten; en separat policy för lagringslivscykeln behövs för att så småningom ta bort den.

Behöver du hjälp med att utforma en nyckelarkitektur som faktiskt kan stödja kryptoförstöring per post? Prata med Encryption Consultings Cloud Key Management-team.

Resurser

NIST SP 800-88 Rev. 1: Riktlinjer för mediesanering