Format Preserving Encryption (FPE) – Gebruik op GCP

Formaatbehoudende encryptie (FPE) is een versleutelingstechniek die gegevens versleutelt tot ciphertext met exact dezelfde lengte en tekenset als de invoer, bijvoorbeeld door een 16-cijferig kaartnummer om te zetten in een ander 16-cijferig getal. Dit is belangrijk omdat het ervoor zorgt dat bestaande schema's, validatieregels en downstream-systemen ongewijzigd kunnen blijven werken, terwijl de onderliggende waarde cryptografisch beschermd is. Gebruik in Google Cloud het FF1-algoritme binnen Sensitive Data Protection met een Cloud KMS-versleutelde sleutel in plaats van een kale sleutel of een handmatig geïmplementeerde code.

Gepubliceerd: augustus 2020. Bijgewerkt: augustus 2026. Beoordeeld door het Cloud Data Protection Team van Encryption Consulting.

Voor een leveranciersneutrale definitie van Format-Preserving Encryption en hoe deze zich verhoudt tot andere anonimiseringstechnieken, zie ons artikel ' Wat is Format-Preserving Encryption?' in het Educatiecentrum . Voor informatie over het beheer van de versleutelde sleutel onder FPE, zie AWS KMS versus Azure Key Vault versus GCP KMS.

Wat is formaatbehoudende encryptie?

Als een organisatie 16-cijferige creditcardnummers in een database heeft opgeslagen en elk systeem, index en validatieregel verwacht dat dit veld exact 16 cijfers lang blijft, dan breekt standaardversleuteling het schema. De platte tekst die met AES-GCM of een vergelijkbare methode is versleuteld, produceert namelijk versleutelde tekst met een andere lengte en tekenset. Formaatbehoudende versleuteling (FPE) biedt hiervoor een oplossing: het versleutelt platte tekst van een bepaalde lengte en alfabet naar versleutelde tekst met exact dezelfde lengte en hetzelfde alfabet. Het versleutelen van de platte tekst 1483920193402918 met FPE zou bijvoorbeeld de uitvoer 1483666666662918 kunnen opleveren : dezelfde 16 cijfers, hetzelfde numerieke alfabet, maar cryptografisch beveiligd.

FPE is een van de drie pseudonimiseringstechnieken die Google Cloud ondersteunt voor het anonimiseren van gegevens via Sensitive Data Protection (voorheen Cloud DLP): deterministische encryptie met AES-SIV, Format-Preserving Encryption en cryptografische hashing. Alle drie vervangen gevoelige waarden door cryptografisch gegenereerde tokens met behulp van een sleutel; dit artikel richt zich specifiek op de FPE-methode.

Hoe werkt formaatbehoudende encryptie op Google Cloud?

Google Cloud implementeert FPE via een constructie genaamd FFX , die twee kandidaatmethoden definieert, FF1 en FF3, voor het omzetten van platte tekst naar formaatbehoudende versleutelde tekst. FF1 is de enige FFX-methode die momenteel is goedgekeurd voor encryptie op Google Cloud. FF2 is nooit definitief gepubliceerd toen FFX werd ontwikkeld, en FF3 bleek cryptanalytisch zwak te zijn tijdens een aanval in 2017, waarna NIST zijn aanbeveling voor FF3 introk in afwachting van een sterkere herziening (FF3-1). De implementatie van Google Cloud weerspiegelt deze geschiedenis door alleen FF1 te ondersteunen.

FFX construeert versleutelde tekst door meerdere rondes van een Feistel-functie uit te voeren op de platte tekst, waarbij in elke ronde de encryptiesleutel wordt gebruikt. Een Feistel-functie splitst de platte tekst in twee helften, past een sleutelgebaseerde permutatie toe op de ene helft op basis van de andere, en verwisselt de helften in elke ronde. FF1 gebruikt 10 rondes van deze Feistel-functie (FF3 gebruikte er 8, wat mede verklaart waarom het zwakker bleek). Voordat de encryptie kan beginnen, moet het alfabet dat gebruikt wordt om de gegevens te anonimiseren op een van de volgende drie manieren worden gespecificeerd: door een van Google's vier vooraf gedefinieerde, veelgebruikte tekensets te selecteren, een radixwaarde op te geven (2 voor binair, 95 voor het volledige afdrukbare ASCII-bereik met cijfers, hoofdletters/kleine letters en symbolen), of door een aangepast alfabet te leveren dat de exacte tekens bevat die moeten worden gebruikt.

Wanneer FPE-FFX wordt uitgevoerd in de modus voor bescherming van gevoelige gegevens, kan de resulterende versleutelde tekst worden voorafgegaan door een surrogaatannotatie om een ​​definitief token te vormen in de vorm van surrogate_infotype(surrogate_length):surrogate_valueHet infotype is door de gebruiker gedefinieerd en de surrogaatwaarde is de versleutelde tekst zelf. Voor het opnieuw identificeren van ongestructureerde data is het volledige token inclusief de surrogaatannotatie nodig; voor gestructureerde data (een bekende kolom in een bekend schema) is alleen de surrogaatwaarde nodig, aangezien het infotype en de lengte al door het schema worden geïmpliceerd.

Hoe werkt native versus externe toetsenbediening voor FPE?

Elke FPE-FFX-transactie vereist een AES-sleutel, en Google Cloud biedt drie manieren om deze te leveren, elk met een ander bewaarmodel.

Sleutelbesturingsmodel	Hoe werkt onze technologie?	Beste pasvorm
Native (onbewerkte sleutel in verzoek)	De base64-gecodeerde AES-sleutel wordt direct opgenomen in elke API-aanroep voor anonimisering/heridentificatie.	Alleen voor lokaal testen. De sleutel is opgenomen in de payload van het verzoek en moet handmatig worden uitgesloten van de logboekregistratie.
Cloud KMS-verpakte sleutel (BYOK-equivalent)	De AES-sleutel wordt versleuteld met een Cloud KMS-sleutel en alleen de versleutelde tekst wordt opgeslagen/verzonden; de afdeling Bescherming van Gevoelige Gegevens roept Cloud KMS aan om deze per bewerking te ontsleutelen.	Productie. IAM bepaalt wie de unwrap-functie mag uitvoeren, en elke unwrap-bewerking wordt vastgelegd in de cloudauditlogboeken.
Externe/HYOK-equivalent (Cloud EKM)	De Cloud KMS-sleutel die de AES-sleutel bevat, wordt zelf beheerd door een externe sleutelbeheerder via Cloud External Key Manager. Google bewaart dus nooit bruikbaar sleutelmateriaal in rust.	Gereguleerde data waarbij een contract of toezichthouder vereist dat de cloudprovider nooit de sleutel in bezit heeft, en de extra latentie van een externe sleutelbeheerder bij elke bewerking accepteert.

Het model met een omhulde sleutel zou de standaard moeten zijn voor elke FPE-implementatie die met echte klantgegevens werkt. Het biedt IAM-gestuurde toegangscontrole en een volledig auditspoor dat een kale sleutel niet kan bieden, en het is het patroon dat Google zelf aanbeveelt voor tokenisatie in productieomgevingen en FPE-workloads.

Hoe moet IAM bepalen wie tokenisatie en heridentificatie mag uitvoeren?

FPE is per definitie omkeerbaar, en dat is precies wat het nuttig maakt (een betalingssysteem heeft uiteindelijk het echte kaartnummer weer nodig) en waarom toegangscontrole hier belangrijker is dan bij eenrichtingshashing. Structureer IAM rond de bewerking, niet alleen rond de data:

1. Geef de applicatielaag die alleen dat nodig heeft de benodigde machtiging. shop Een tokenized waarde die toestemming geeft om de functie voor anonimisering aan te roepen, maar niet voor heridentificatie.
2. Geef alleen toestemming voor het opnieuw identificeren van gegevens aan de specifieke serviceaccounts die de oorspronkelijke waarde daadwerkelijk nodig hebben (bijvoorbeeld een betalingsverwerker of een workflow voor fraudebestrijding), en nooit aan een algemene analysefunctie.
3. Geef de Cloud KMS-wrappersleutel op cryptoKeyEncrypterDecrypter De rol wordt alleen aan het DLP-serviceaccount gekoppeld, nooit rechtstreeks aan een menselijke identiteit.
4. Scheid de identiteit die de inspectie-/anonimiseringssjablonen beheert van de identiteit die de getokeniseerde uitvoer verwerkt, zodat sjabloonwijzigingen traceerbaar zijn, onafhankelijk van de gegevenstoegang.
5. Beoordeel heridentificatietoestemmingen met dezelfde frequentie als beoordelingen van toegang tot de productiedatabase, aangezien een verlopen heridentificatietoestemming functioneel gelijkwaardig is aan permanente toegang tot de onversleutelde tekst.

Hoe moet je sleutelrotatie aanpakken voor FPE?

Het roteren van de Cloud KMS-sleutel die een FPE AES-sleutel omhult, creëert een nieuwe sleutelversie. Google Cloud benadrukt echter expliciet dat rotatie "uw gegevens niet opnieuw versleutelt en eerdere sleutelversies niet uitschakelt of verwijdert". Voor FPE betekent dit specifiek dat elke waarde die is getokeniseerd met de oude omhullende sleutelversie, nog steeds diezelfde sleutelversie nodig heeft om later opnieuw te kunnen worden geïdentificeerd. Als een sleutelversie wordt vernietigd voordat elke afhankelijke FPE-waarde opnieuw is versleuteld met de nieuwe versie, worden die gegevens, zoals bedoeld, permanent onherstelbaar.

Een veilig patroon: roteer de Cloud KMS-wrapperkey volgens een vast schema (er is geen vast minimum- of maximuminterval voor Cloud KMS-rotatie, maar een gangbare richtlijn is 90 dagen voor symmetrische sleutels), decodeer en herversleutel bestaande FPE-waarden met de nieuwe sleutelversie in een batchtaak op de achtergrond, en plan de verwijdering van de oude sleutelversie pas in wanneer die batchtaak bevestigt dat er geen afhankelijke waarden meer zijn. Het standaardvenster voor geplande verwijdering in Cloud KMS is 30 dagen, wat een redelijke buffer biedt om eventuele waarden die een batchtaak heeft gemist, alsnog te verwerken.

Wat moet je registreren bij een FPE-implementatie?

• Elke heridentificatieoproep, met de belleridentificatie en het specifieke veld/record waarnaar wordt verwezen, aangezien heridentificatie de bewerking is die daadwerkelijk de platte tekst blootlegt.
• Cloud KMS-uitpakbewerkingen tegen de omhullende sleutel, automatisch vastgelegd via cloudauditlogboeken.
• Sjabloonwijzigingen naar de inspectie-/anonimiseringsconfiguratie die definieert op welke velden FPE wordt toegepast en met welk alfabet.
• Levenscyclusgebeurtenissen van sleutelversies (rotatie, geplande vernietiging, annulering), zodat een beveiligingsbeheerder een incident waarbij een waarde niet langer kan worden geïdentificeerd, kan koppelen aan een specifieke sleutelgebeurtenis.

Wat kost FPE op Google Cloud?

FPE zelf wordt gefactureerd als een transformatiebewerking voor de bescherming van gevoelige gegevens, onder dezelfde prijsstelling voor contentmethoden of opslagtaken die in het algemeen voor tokenisatie geldt: in de regel kost een transformatie voor contentmethoden ongeveer $ 2.00/GB na een gratis limiet van 1 GB/maand, tot 1 TB, met een lager tarief per GB daarboven (controleer de actuele tarieven op de prijslijst van Google, aangezien de prijsstelling voor de bescherming van gevoelige gegevens gelaagd is en kan veranderen). De Cloud KMS-wrapper voegt een aparte, op gebruik gebaseerde vergoeding toe voor elke wrap-/unwrap-bewerking, die schaalt met het aantal uitgevoerde FPE-bewerkingen, niet met het volume van de gescande gegevens.

Het kostendetail dat de meeste teams over het hoofd zien: omdat FPE omkeerbaar is, betaalt een workload die zowel tokeniseert bij het schrijven als opnieuw identificeert bij het lezen (bijvoorbeeld een betalingssysteem) de operationele kosten van Cloud KMS twee keer per recordlevenscyclus, niet één keer. Modelleer dat verdubbelde aantal bewerkingen voordat u de totale kosten van FPE vergelijkt met een eenrichtings-hashing- of maskeermethode die nooit heridentificatie vereist.

Hoe ziet een multi-cloud FPE-architectuur eruit?

FPE-ondersteuning is niet uniform in de belangrijkste cloudomgevingen. Google Cloud heeft FF1 direct ingebouwd in Sensitive Data Protection; AWS heeft geen native FPE-primitief in AWS KMS en vereist doorgaans een bibliotheek van een derde partij of een FPE-implementatie van een leverancier van hardwarebeveiligingsmodules die bovenop AWS CloudHSM draait; Azure heeft evenmin een native FPE-service en vertrouwt op partneroplossingen of de deterministische encryptie van Always Encrypted (die niet dezelfde constructie heeft als FPE) voor schema-behoudende bescherming. Een multi-cloud dataplatform dat consistente formaatbehoudende tokenisatie in alle drie de clouds vereist, moet over het algemeen standaardiseren op een FPE-bibliotheek van een derde partij of een zelfgehoste bibliotheek in plaats van de eigen native tools van elke cloud, en het sleutelmateriaal van die bibliotheek in de native KMS van elke cloud (Cloud KMS, AWS KMS, Azure Key Vault) verpakken voor consistente toegangscontrole en auditing.

Bekijk onze vergelijking van AWS KMS, Azure Key Vault en GCP KMS om te zien hoe de native sleutelbeheerlaag onder elke FPE-implementatie verschilt tussen de drie providers.

Wat zijn de beperkingen van formaatbehoudende encryptie?

• FPE behoudt de lengte en het alfabet, maar niet de semantische geldigheid. Een downstream-systeem dat een Luhn-checksum op kaartnummers of een datumbereikcontrole afdwingt, kan FPE-cijfertekst afwijzen, tenzij de transformatie is ontworpen om die specifieke eigenschap te behouden.
• Omdat FPE omkeerbaar is, voldoet het niet aan de eisen die onomkeerbare de-identificatie of anonimisering vereisen; gebruik in plaats daarvan hashing of generalisatie wanneer omkeerbaarheid zelf het nalevingsprobleem is.
• Momenteel is alleen FF1 goedgekeurd; teams dienen FF3 niet te implementeren of erop te vertrouwen voor nieuw werk, gezien de bekende cryptanalytische zwakte ervan.
• De levenscyclus van sleutelversies is volledig de verantwoordelijkheid van de klant; Google versleutelt FPE-waarden niet automatisch opnieuw wanneer een versleutelde sleutel wordt geroteerd.

Checklist voor besluitvorming: FPE implementeren op Google Cloud

1. Bevestig dat het veld daadwerkelijk formaatbehoud nodig heeft (een downstream schema- of validatieafhankelijkheid), en niet alleen algemene anonimisering.
2. Gebruik uitsluitend FF1; ontwikkel geen nieuwe workflows in FF3.
3. Verpak de AES-sleutel in Cloud KMS en verleen de benodigde rechten. cryptoKeyEncrypterDecrypter Alleen voor het serviceaccount dat de functie voor bescherming van gevoelige gegevens aanroept.
4. Scheid IAM-toestemmingen voor anonimisering en heridentificatie, en beoordeel de toegang tot heridentificatiegegevens met dezelfde frequentie als de toegang tot productiedata.
5. Schrijf het draaiboek voor sleutelrotatie en her-tokenisatie voordat de eerste productiewaarde wordt getokeniseerd.

Wat zou Encryption Consulting aanbevelen?

FPE-implementaties werken doorgaans prima op de eerste dag, maar vormen een probleem bij de eerste sleutelrotatie, omdat het re-tokenisatie-runbook nooit is opgesteld. De Cloud Data Protection -adviesdienst van Encryption Consulting ontwerpt de FPE-sleutellevenscyclus, de IAM-splitsing voor anonimisering en heridentificatie, en het rotatie-runbook in één keer. Ons HSM-as-a-Service- aanbod biedt de Cloud KMS-wrapper-sleutel hardware-ondersteunde bewaring waar FIPS 140-3-garantie vereist is.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen FPE en tokenisatie?

Tokenisatie is het algemene concept van het vervangen van een gevoelige waarde door een vervangend token; FPE is een specifieke cryptografische techniek voor het genereren van dat vervangende token, een techniek die garandeert dat de uitvoer dezelfde lengte en tekenset heeft als de invoer. Google Cloud's Sensitive Data Protection biedt FPE naast twee andere tokenisatiemethoden (deterministische AES-SIV-encryptie en cryptografische hashing).

Waarom ondersteunt Google Cloud alleen FF1 en niet FF3?

Uit een aanval in 2017 bleek dat FF3 cryptanalytisch zwak was, waarna de veiligheidsmarge onvoldoende werd geacht voor gebruik in productieomgevingen. FF1 gebruikt meer Feistel-rondes (10 tegenover 8 in FF3) en blijft de goedgekeurde methode.

Kan FPE-cijfertekst worden gebruikt in een database-index of unieke beperking?

Ja, voor deterministische FPE, omdat dezelfde platte tekst met dezelfde sleutel en hetzelfde alfabet altijd dezelfde versleutelde tekst oplevert. Dat maakt het, in tegenstelling tot gerandomiseerde encryptie, bruikbaar als index- of koppelingssleutel zonder eerst te decoderen.

Veroorzaakt het roteren van de Cloud KMS-wrappersleutel problemen met bestaande FPE-gegevens?

Niet direct. Rotatie creëert een nieuwe sleutelversie zonder de oude te verwijderen, waardoor bestaande FPE-cijfertekst heridentificeerbaar blijft zolang de oorspronkelijke sleutelversie nog bestaat. Het risico ontstaat pas als die oude versie wordt vernietigd voordat een hertokenisatiestap wordt uitgevoerd.

Is FPE standaard beschikbaar op AWS of Azure, net als op Google Cloud?

Nee. Noch AWS KMS, noch Azure Key Vault biedt een eigen FPE-primitief dat vergelijkbaar is met de FF1-implementatie van Google Cloud binnen Sensitive Data Protection; de meeste AWS- en Azure-implementaties maken in plaats daarvan gebruik van een FPE-implementatie van een externe bibliotheek of leverancier van hardwarebeveiligingsmodules.

Heeft u hulp nodig bij het ontwerpen van de belangrijkste levenscyclus achter een FPE-implementatie, en niet alleen bij de encryptieaanroep zelf? Neem dan contact op met het Cloud Data Protection-team van Encryption Consulting.