Formatbevarande kryptering (FPE) – Användning på GCP

Formatbevarande kryptering (FPE) är en chifferkonstruktion som krypterar data till chiffertext med exakt samma längd och teckenuppsättning som indata, till exempel att omvandla ett 16-siffrigt kortnummer till ett annat 16-siffrigt nummer. Det är viktigt eftersom det låter äldre scheman, valideringsregler och nedströmssystem fortsätta att fungera oförändrade medan det underliggande värdet är kryptografiskt skyddat. Använd FF1-algoritmen i Sensitive Data Protection på Google Cloud med en Cloud KMS-inlindad nyckel snarare än en ren nyckel eller en handrullad implementering.

Publicerad: augusti 2020. Uppdaterad: augusti 2026. Granskad av Encryption Consultings molndataskyddsteam.

För den leverantörsneutrala definitionen av formatbevarande kryptering och hur den jämförs med andra avidentifieringstekniker, se vår utbildningsartikel Vad är formatbevarande kryptering?. För hur omslagsnyckeln under FPE ska hanteras, se AWS KMS vs. Azure Key Vault vs. GCP KMS.

Vad är formatbevarande kryptering?

Om en organisation har 16-siffriga kreditkortsnummer lagrade i en databas, och varje nedströmssystem, index och valideringsregel förväntar sig att fältet ska vara exakt 16 siffror långt, bryter standardkryptering schemat, eftersom klartext krypterad med AES-GCM eller liknande producerar chiffertext med olika längd och teckenuppsättning. Formatbevarande kryptering (FPE) löser detta: den krypterar klartext med en given längd och alfabet till chiffertext med exakt samma längd och alfabet. Att kryptera klartexten 1483920193402918 med FPE kan producera en utdata som 1483666666662918 : samma 16 siffror, samma numeriska alfabet, men kryptografiskt skyddad.

FPE är en av tre pseudonymiseringstekniker som Google Cloud stöder för avidentifierande data genom Sensitive Data Protection (tidigare Cloud DLP): deterministisk kryptering med AES-SIV, formatbevarande kryptering och kryptografisk hashing. Alla tre ersätter känsliga värden med kryptografiskt genererade tokens med hjälp av en nyckel; den här artikeln fokuserar specifikt på FPE-metoden.

Hur fungerar formatbevarande kryptering på Google Cloud?

Google Cloud implementerar FPE genom en konstruktion som kallas FFX , som definierar två kandidatmetoder, FF1 och FF3, för att omvandla klartext till formatbevarande chiffertext. FF1 är den enda FFX-metoden som för närvarande är godkänd för kryptering på Google Cloud. FF2 slutfördes aldrig för publicering när FFX skapades, och FF3 befanns vara kryptanalytiskt svag i en attack 2017, varefter NIST drog tillbaka sin rekommendation för FF3 i avvaktan på en starkare revision (FF3-1). Google Clouds implementering återspeglar den historiken genom att endast stödja FF1.

FFX bygger chiffertext genom att köra flera omgångar av en Feistel-funktion mot klartexten, med hjälp av krypteringsnyckeln vid varje omgång. En Feistel-funktion delar klartexten i två halvor, tillämpar en nyckelpermutation på den ena halvan baserat på den andra och byter halvorna varje omgång. FF1 använder 10 omgångar av denna Feistel-funktion (FF3 använde 8, vilket delvis var anledningen till att den visade sig vara svagare). Innan krypteringen kan starta måste alfabetet som används för att avidentifiera data anges på ett av tre sätt: att välja en av Googles fyra fördefinierade vanliga teckenuppsättningar, ange ett radixvärde (2 för binär, 95 för hela utskrivbara ASCII-området med siffror, stora/små bokstäver och symboler), eller att tillhandahålla ett anpassat alfabet som innehåller exakt de tecken som ska användas.

När FPE-FFX körs i skydd av känsliga data kan den resulterande chiffertexten läggas till med en surrogatannotering för att bilda en slutlig token i formen surrogate_infotype(surrogate_length):surrogate_valueInfotypen är användardefinierad och surrogatvärdet är själva chiffertexten. Omidentifiering av ostrukturerad data kräver hela token inklusive dess surrogatannotering; strukturerad data (en känd kolumn i ett känt schema) behöver bara surrogatvärdet, eftersom infotypen och längden redan är implicerade av schemat.

Hur fungerar nativ kontra extern nyckelkontroll för FPE?

Varje FPE-FFX-operation behöver en AES-nyckel, och Google Cloud erbjuder tre sätt att tillhandahålla den, vart och ett med en annan förvaringsmodell.

Nyckelkontrollmodell	Hur det fungerar	Bästa passform
Ursprunglig (rå nyckel i begäran)	Den base64-kodade AES-nyckeln ingår direkt i varje API-anrop för avidentifiering/omidentifiering.	Endast lokal testning. Nyckeln exponeras i begäran och måste undantas från loggning manuellt.
Cloud KMS-inlindad nyckel (BYOK-ekvivalent)	AES-nyckeln krypteras av en Cloud KMS-nyckel och endast den inkapslade chiffertexten lagras/överförs; Sensitive Data Protection anropar Cloud KMS för att packa upp den per operation.	Produktion. IAM styr vem som kan anropa uppackningen, och varje uppackning registreras i molngranskningsloggar.
Extern/HYOK-ekvivalent (Cloud EKM)	Cloud KMS-nyckeln som omsluter AES-nyckeln hanteras i sig av en extern nyckelhanterare via Cloud External Key Manager, så Google lagrar aldrig användbart nyckelmaterial vilande.	Reglerade data där ett avtal eller en tillsynsmyndighet kräver att molnleverantören aldrig innehar nyckeln, och accepterar den extra latensen för en extern nyckelhanterare tur och retur vid varje operation.

Den inpackade nyckelmodellen bör vara standard för alla FPE-distributioner som hanterar verkliga kunddata. Den lägger till IAM-styrd åtkomstkontroll och en fullständig revisionslogg som en enkel nyckel inte kan tillhandahålla, och det är det mönster som Googles egen dokumentation rekommenderar för produktionstokenisering och FPE-arbetsbelastningar.

Hur ska IAM styra vem som kan tokenisera och omidentifiera?

FPE är reversibelt till sin design, vilket är precis det som gör det användbart (ett betalningssystem behöver så småningom få tillbaka det riktiga kortnumret) och exakt varför åtkomstkontroll är viktigare här än för enkelriktad hashing. Strukturera IAM kring operationen, inte bara data:

1. Bevilja applikationslagret som bara behöver lagra en tokeniserad värdebehörighet att anropa avidentifiera, men inte omidentifiera.
2. Ge endast behörighet att återidentifiera till de specifika tjänstekonton som legitimt behöver tillbaka det ursprungliga värdet (en betalningsbehandlare, ett arbetsflöde för bedrägerigranskning), aldrig till en bred analysroll.
3. Ge Cloud KMS-omslagsnycklarna cryptoKeyEncrypterDecrypter rollen endast till DLP-tjänstkontot, aldrig direkt till en mänsklig identitet.
4. Separera identiteten som hanterar mallarna för inspektion/avidentifiering från identiteten som förbrukar tokeniserad utdata, så att malländringar kan granskas oberoende av dataåtkomst.
5. Granska omidentifieringsbeviljanden i samma takt som granskningar av åtkomst till produktionsdatabasen, eftersom ett inaktuellt omidentifieringsbeviljande funktionellt sett motsvarar permanent åtkomst till klartexten.

Hur ska man hantera nyckelrotation för FPE?

Att rotera Cloud KMS-nyckeln som omsluter en FPE AES-nyckel skapar en ny nyckelversion, men Google Cloud är tydlig med att rotationen "inte omkrypterar dina data och inte inaktiverar eller tar bort tidigare nyckelversioner". För FPE specifikt innebär detta att varje värde som tokeniserats under den gamla omslutande nyckelversionen fortfarande behöver exakt den nyckelversionen vara tillgänglig för att kunna identifieras senare. Förstör en nyckelversion innan varje beroende FPE-värde har omkrypterats under den nya versionen, och den informationen blir permanent oåterställbar, avsiktligt.

Ett säkert mönster: rotera Cloud KMS-omslagningsnyckeln enligt ett definierat schema (det finns inget fast minimalt eller maximalt rotationsintervall för Cloud KMS, men en vanlig baslinje är 90 dagar för symmetriska nycklar), dekryptera och omtokenisera befintliga FPE-värden under den nya nyckelversionen i ett bakgrundsbatchjobb, och schemalägg endast förstörelse av den pensionerade nyckelversionen när batchjobbet bekräftar noll återstående beroenden. Cloud KMS standardfönster för schemalagd förstörelse är 30 dagar, vilket ger en rimlig buffert för att fånga upp eventuella värden som ett batchjobb missat.

Vad ska du logga för en FPE-distribution?

• Varje omidentifierande samtal, med uppringaridentitet och det specifika fält/post som refereras, eftersom omidentifiera är den operation som faktiskt exponerar klartext.
• Uppackningsåtgärder i Cloud KMS mot omslagsnyckeln, som registreras automatiskt via molngranskningsloggar.
• Malländringar till konfigurationen för inspektera/avidentifiera som definierar vilka fält som får FPE tillämpad och med vilket alfabet.
• Livscykelhändelser för nyckelversion (rotation, schemalagd förstörelse, annullering), så att en säkerhetsadministratör kan korrelera en incident med "värdet kan inte längre återidentifieras" tillbaka till en specifik nyckelhändelse.

Vad kostar FPE på Google Cloud?

FPE i sig faktureras som en transformationsåtgärd för känsligt dataskydd, under samma prissättning för innehållsmetod eller lagringsjobb som generellt täcker tokenisering: riktningsvis kostar innehållsmetodtransformationen ungefär 2.00 USD/GB efter en gratisnivå på 1 GB/månad, upp till 1 TB, med en lägre kostnad per GB ovanför det (bekräfta aktuella priser mot Googles prissida, eftersom prissättningen för känsligt dataskydd är nivåindelad och kan ändras). Cloud KMS-wrapningnyckeln lägger till en separat, användningsbaserad avgift för varje wrap/upwrap-åtgärd, som skalas med hur många FPE-åtgärder som körs, inte med volymen av data som skannas.

Kostnadsdetaljen som de flesta team missar: eftersom FPE är reversibel betalar en arbetsbelastning som både tokeniseras vid skrivning och omidentifieras vid läsning (till exempel ett betalningssystem) Cloud KMS-driftskostnaden två gånger per postlivscykel, inte en gång. Modell som fördubblade antalet operationer innan FPE:s totala kostnad jämfördes med en enkelriktad hashing- eller maskeringsmetod som aldrig behöver omidentifieras.

Hur ser en FPE-arkitektur för flera moln ut?

FPE-stödet är inte enhetligt i de stora molnen. Google Cloud har FF1 inbyggt direkt i Sensitive Data Protection; AWS har ingen inbyggd FPE-primitiv i AWS KMS och kräver vanligtvis ett tredjepartsbibliotek eller en FPE-implementering från en leverantör av hårdvarusäkerhetsmoduler som körs ovanpå AWS CloudHSM; Azure har på liknande sätt ingen inbyggd FPE-tjänst och förlitar sig på partnerlösningar eller Always Encrypteds deterministiska kryptering (som inte är samma konstruktion som FPE) för schemabevarande skydd. En multimolndataplattform som behöver konsekvent formatbevarande tokenisering i alla tre molnen måste i allmänhet standardisera på ett tredjeparts- eller självhostat FPE-bibliotek snarare än varje molns egna inbyggda verktyg, och slå in det bibliotekets nyckelmaterial i varje molns inbyggda KMS (Cloud KMS, AWS KMS, Azure Key Vault) för konsekvent åtkomstkontroll och granskning.

Se vår jämförelse av AWS KMS, Azure Key Vault och GCP KMS för hur det inbyggda nyckelhanteringslagret under en FPE-implementering skiljer sig mellan de tre leverantörerna.

Vilka är begränsningarna med formatbevarande kryptering?

• FPE bevarar längd och alfabet, inte semantisk giltighet. Ett nedströmssystem som tillämpar en Luhn-kontrollsumma på kortnummer, eller en datumintervallkontroll, kan avvisa FPE-chiffrerad text om inte transformationen är byggd för att bevara den specifika egenskapen.
• Eftersom FPE är reversibel uppfyller den inte krav som kräver oåterkallelig avidentifiering eller anonymisering; använd hashing eller generalisering istället när reversibiliteten i sig är efterlevnadsproblemet.
• Endast FF1 är för närvarande godkänd; team bör inte implementera eller förlita sig på FF3 för nytt arbete med tanke på dess kända kryptanalytiska svaghet.
• Nyckelversionens livscykel är helt kundens ansvar; Google omkrypterar inte automatiskt FPE-värden när en omslagsnyckel roteras.

Beslutschecklista: Implementera FPE på Google Cloud

1. Bekräfta att fältet verkligen behöver formatbevaring (ett nedströmsschema eller valideringsberoende), inte bara avidentifiering i allmänhet.
2. Använd endast FF1; bygg inte nya arbetsflöden på FF3.
3. Slå in AES-nyckeln i Cloud KMS och bevilja cryptoKeyEncrypterDecrypter endast till det tjänstkonto som anropar skydd av känsliga data.
4. Separera avidentifierande och omidentifierande IAM-beviljanden och granska omidentifierande åtkomst i samma takt som åtkomst till produktionsdata.
5. Skriv runbooken för nyckelrotation och omtokenisering innan det första produktionsvärdet tokeniseras.

Vad skulle krypteringskonsulter rekommendera?

FPE-distributioner tenderar att fungera bra från dag ett och bli en belastning vid den första nyckelrotationen, eftersom omtokeniseringsrunbooken aldrig byggdes. Encryption Consultings rådgivningstjänst för Cloud Data Protection utformar FPE-nyckellivscykeln, avidentifierings-/omidentifierings-IAM-uppdelningen och rotationsrunbooken tillsammans, och vårt HSM-as-a-Service- erbjudande ger Cloud KMS-inpackning av nyckel hårdvarubaserad förvaring där FIPS 140-3-säkring krävs.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan FPE och tokenisering?

Tokenisering är det allmänna konceptet att ersätta ett känsligt värde med en ersättningstoken; FPE är en specifik kryptografisk teknik för att generera den ersättningen, en teknik som garanterar att utdata har samma längd och teckenuppsättning som indata. Google Clouds Sensitive Data Protection erbjuder FPE tillsammans med två andra tokeniseringsmetoder (deterministisk AES-SIV-kryptering och kryptografisk hashing).

Varför stöder Google Cloud bara FF1 och inte FF3?

FF3 visade sig vara kryptanalytiskt svag i en attack 2017, varefter dess säkerhetsmarginal ansågs otillräcklig för produktionsanvändning. FF1 använder fler Feistel-rundor (10 mot FF3:s 8) och är fortfarande den godkända metoden.

Kan FPE-chiffertext användas i ett databasindex eller en unik begränsning?

Ja för deterministisk FPE, eftersom samma klartext under samma nyckel och alfabet alltid producerar samma chiffertext, vilket är precis det som gör den användbar som en index- eller kopplingsnyckel utan att först dekryptera, till skillnad från randomiserad kryptering.

Bryter rotering av Cloud KMS-omslutningsnyckeln befintliga FPE-data?

Inte omedelbart. Rotation skapar en ny nyckelversion utan att gamla raderas, så befintlig FPE-krypteringstext förblir återidentifierbar så länge dess ursprungliga nyckelversion fortfarande finns kvar. Risken uppstår bara om den gamla versionen förstörs innan ett omtokeniseringspass körs.

Är FPE tillgängligt direkt på AWS eller Azure, precis som det är på Google Cloud?

Nej. Varken AWS KMS eller Azure Key Vault levererar en inbyggd FPE-primitiv som är jämförbar med Google Clouds FF1-implementering i Sensitive Data Protection; de flesta AWS- och Azure-distributioner förlitar sig istället på en tredjepartsbiblioteks- eller FPE-implementering från leverantören av hårdvarusäkerhetsmoduler.

Behöver du hjälp med att utforma nyckellivscykeln bakom en FPE-utrullning, inte bara själva krypteringsanropet? Prata med Encryption Consultings team för molndataskydd.