Formaterhaltende Verschlüsselung (FPE) – Verwendung auf GCP

Formatbewahrende Verschlüsselung (FPE) ist ein Verschlüsselungsverfahren, das Daten in einen Chiffretext mit exakt derselben Länge und demselben Zeichensatz wie die Eingabe verschlüsselt, beispielsweise eine 16-stellige Kartennummer in eine andere 16-stellige Zahl. Dies ist wichtig, da bestehende Schemata, Validierungsregeln und nachgelagerte Systeme weiterhin unverändert funktionieren, während der zugrundeliegende Wert kryptografisch geschützt ist. Verwenden Sie auf Google Cloud den FF1-Algorithmus innerhalb des Schutzes sensibler Daten mit einem Cloud-KMS-verschlüsselten Schlüssel anstelle eines ungeschützten Schlüssels oder einer manuell entwickelten Implementierung.

Veröffentlicht: August 2020. Aktualisiert: August 2026. Geprüft vom Cloud Data Protection Team von Encryption Consulting.

Eine herstellerneutrale Definition von formatbewahrender Verschlüsselung (FPE) und deren Vergleich mit anderen Anonymisierungsverfahren finden Sie in unserem Artikel „ Was ist formatbewahrende Verschlüsselung?“ im Education Center . Informationen zur Verwaltung des zugrunde liegenden Schlüssels finden Sie unter AWS KMS vs. Azure Key Vault vs. GCP KMS.

Was ist formatbewahrende Verschlüsselung?

Wenn eine Organisation 16-stellige Kreditkartennummern in einer Datenbank speichert und alle nachgelagerten Systeme, Indizes und Validierungsregeln erwarten, dass dieses Feld exakt 16 Stellen hat, bricht die Standardverschlüsselung das Schema. Der Grund: Mit AES-GCM oder einem ähnlichen Verfahren verschlüsselter Klartext erzeugt einen Geheimtext mit anderer Länge und anderem Zeichensatz. Formatbewahrende Verschlüsselung (FPE) löst dieses Problem: Sie verschlüsselt Klartext einer bestimmten Länge und eines bestimmten Alphabets in einen Geheimtext exakt derselben Länge und desselben Alphabets. Die Verschlüsselung des Klartexts 1483920193402918 mit FPE könnte beispielsweise zu einer Ausgabe wie 1483666666662918 führen : dieselben 16 Ziffern, dasselbe numerische Alphabet, aber kryptografisch geschützt.

FPE ist eines von drei Pseudonymisierungsverfahren, die Google Cloud zur Anonymisierung von Daten im Rahmen des Schutzes sensibler Daten (ehemals Cloud DLP) unterstützt: deterministische Verschlüsselung mit AES-SIV, formatbewahrende Verschlüsselung und kryptografisches Hashing. Alle drei Verfahren ersetzen sensible Werte durch kryptografisch generierte Token mithilfe eines Schlüssels; dieser Artikel konzentriert sich speziell auf das FPE-Verfahren.

Wie funktioniert formatbewahrende Verschlüsselung in Google Cloud?

Google Cloud implementiert FPE mithilfe einer Konstruktion namens FFX , die zwei Kandidatenmethoden, FF1 und FF3, zur Umwandlung von Klartext in formatbewahrenden Chiffretext definiert. FF1 ist die einzige FFX-Methode, die derzeit für die Verschlüsselung auf Google Cloud zugelassen ist. FF2 wurde bei der Entwicklung von FFX nie zur Veröffentlichung freigegeben, und FF3 erwies sich bei einem Angriff im Jahr 2017 als kryptoanalytisch schwach. Daraufhin zog das NIST seine Empfehlung für FF3 bis zur Veröffentlichung einer stärkeren Version (FF3-1) zurück. Die Implementierung von Google Cloud trägt dieser Vorgeschichte Rechnung, indem sie nur FF1 unterstützt.

FFX erzeugt den Chiffretext, indem es mehrere Runden einer Feistel-Funktion auf den Klartext anwendet und dabei in jeder Runde den Verschlüsselungsschlüssel verwendet. Die Feistel-Funktion teilt den Klartext in zwei Hälften, wendet auf eine Hälfte basierend auf der anderen eine permutierte Verschlüsselung an und vertauscht die Hälften in jeder Runde. FF1 verwendet 10 Runden dieser Feistel-Funktion (FF3 verwendete 8, was mit ein Grund für die geringere Sicherheit war). Bevor die Verschlüsselung beginnen kann, muss das Alphabet zur Anonymisierung der Daten auf eine von drei Arten festgelegt werden: Auswahl eines der vier vordefinierten gängigen Zeichensätze von Google, Angabe eines Basiswerts (2 für Binärzahlen, 95 für den gesamten druckbaren ASCII-Bereich mit Zahlen, Groß- und Kleinbuchstaben sowie Symbolen) oder Bereitstellung eines benutzerdefinierten Alphabets mit den exakt zu verwendenden Zeichen.

Wenn FPE-FFX im Modus „Schutz sensibler Daten“ ausgeführt wird, kann dem resultierenden Chiffretext eine Ersatzannotation vorangestellt werden, um ein endgültiges Token in folgender Form zu bilden: surrogate_infotype(surrogate_length):surrogate_valueDer Infotyp ist benutzerdefiniert, und der Ersatzwert ist der Chiffretext selbst. Zur Reidentifizierung unstrukturierter Daten wird das vollständige Token einschließlich seiner Ersatzannotation benötigt; strukturierte Daten (eine bekannte Spalte in einem bekannten Schema) benötigen lediglich den Ersatzwert, da Infotyp und Länge bereits durch das Schema impliziert sind.

Wie funktioniert die native vs. externe Tastensteuerung für FPE?

Für jede FPE-FFX-Operation wird ein AES-Schlüssel benötigt, und Google Cloud bietet drei Möglichkeiten zur Bereitstellung dieses Schlüssels an, jede mit einem anderen Verwahrungsmodell.

Tastensteuerungsmodell	So funktioniert’s	Optimale Bildschirmwahl
Native (Rohschlüssel in der Anfrage)	Der Base64-kodierte AES-Schlüssel wird direkt in jeden De-Identifizierungs-/Re-Identifizierungs-API-Aufruf eingebunden.	Nur lokale Tests. Der Schlüssel ist in der Anfragenutzlast enthalten und muss manuell von der Protokollierung ausgeschlossen werden.
Cloud-KMS-geschützter Schlüssel (BYOK-Äquivalent)	Der AES-Schlüssel wird mit einem Cloud-KMS-Schlüssel verschlüsselt, und nur der verschlüsselte Chiffretext wird gespeichert/übertragen; Sensitive Data Protection ruft Cloud KMS auf, um ihn bei jeder Operation zu entschlüsseln.	Produktion. IAM regelt, wer den Entpackungsvorgang auslösen darf, und jeder Entpackungsvorgang wird in Cloud-Audit-Logs protokolliert.
Extern/HYOK-Äquivalent (Cloud EKM)	Der Cloud-KMS-Schlüssel, der den AES-Schlüssel umschließt, wird selbst von einem externen Schlüsselmanager über den Cloud External Key Manager gehostet, sodass Google niemals nutzbares Schlüsselmaterial im Ruhezustand speichert.	Regulierte Daten, bei denen ein Vertrag oder eine Aufsichtsbehörde vorschreibt, dass der Cloud-Anbieter niemals den Schlüssel besitzen darf, wobei die zusätzliche Latenz eines externen Schlüsselverwaltungs-Roundtrips bei jeder Operation in Kauf genommen wird.

Das Wrapped-Key-Modell sollte für jede FPE-Implementierung, die echte Kundendaten verarbeitet, die Standardeinstellung sein. Es bietet eine IAM-gesteuerte Zugriffskontrolle und einen vollständigen Audit-Trail, den ein einfacher Schlüssel nicht bereitstellen kann. Googles eigene Dokumentation empfiehlt dieses Modell für die Tokenisierung in Produktionsumgebungen und für FPE-Workloads.

Wie sollte IAM regeln, wer tokenisieren und erneut identifizieren darf?

FPE ist systembedingt reversibel, was es besonders nützlich macht (ein Zahlungssystem benötigt schließlich die echte Kartennummer) und genau deshalb ist die Zugriffskontrolle hier wichtiger als bei Einweg-Hashing. Strukturieren Sie IAM um die Operation herum, nicht nur um die Daten.

1. Gewähren Sie der Anwendungsschicht, die nur Folgendes benötigt: Shop an Ein tokenisierter Wert mit der Berechtigung, die Anonymisierung aufzurufen, jedoch nicht die Reidentifizierung.
2. Die Berechtigung zur erneuten Identifizierung sollte nur denjenigen Servicekonten erteilt werden, die den ursprünglichen Wert tatsächlich benötigen (z. B. ein Zahlungsabwickler, ein Workflow zur Betrugsprüfung), niemals jedoch einer umfassenden Analyserolle.
3. Geben Sie die Cloud KMS-Wrapper-Schlüssel an cryptoKeyEncrypterDecrypter Die Rolle wird ausschließlich dem DLP-Dienstkonto zugewiesen, niemals direkt einer menschlichen Identität.
4. Trennen Sie die Identität, die die Inspektions-/Anonymisierungsvorlagen verwaltet, von der Identität, die tokenisierte Ausgaben verarbeitet, damit Vorlagenänderungen unabhängig vom Datenzugriff überprüfbar sind.
5. Die Überprüfung von Re-Identifizierungsberechtigungen sollte im gleichen Rhythmus erfolgen wie die Überprüfung des Zugriffs auf die Produktionsdatenbank, da eine veraltete Re-Identifizierungsberechtigung funktional gleichwertig mit einem permanenten Zugriff auf den Klartext ist.

Wie sollte die Tastenrotation für FPE gehandhabt werden?

Durch die Rotation des Cloud-KMS-Schlüssels, der einen FPE-AES-Schlüssel umschließt, wird eine neue Schlüsselversion erzeugt. Google Cloud stellt jedoch ausdrücklich klar, dass die Rotation „Ihre Daten nicht neu verschlüsselt und vorherige Schlüsselversionen weder deaktiviert noch löscht“. Konkret bedeutet dies für FPE, dass jeder Wert, der unter der alten Schlüsselversion tokenisiert wurde, weiterhin genau diese Schlüsselversion benötigt, um später wieder identifiziert werden zu können. Wird eine Schlüsselversion zerstört, bevor alle abhängigen FPE-Werte mit der neuen Version neu verschlüsselt wurden, sind diese Daten – systembedingt – unwiederbringlich verloren.

Ein sicheres Vorgehen: Rotieren Sie den Cloud-KMS-Wrapper-Key nach einem festgelegten Zeitplan (es gibt kein festes minimales oder maximales Rotationsintervall, üblicherweise werden jedoch 90 Tage für symmetrische Schlüssel verwendet). Entschlüsseln und tokenisieren Sie vorhandene FPE-Werte mit der neuen Schlüsselversion in einem Hintergrundprozess. Planen Sie die Löschung der ausgemusterten Schlüsselversion erst, wenn dieser Hintergrundprozess keine verbleibenden Abhängigkeiten mehr bestätigt. Das standardmäßige Löschfenster von Cloud KMS beträgt 30 Tage. Dies bietet einen ausreichenden Puffer, um eventuell vom Hintergrundprozess übersehene Werte zu erfassen.

Was sollte bei einer FPE-Bereitstellung protokolliert werden?

• Jeder erneute Identifizierungsaufruf, wobei die Anruferidentität und das spezifische Feld/der spezifische Datensatz referenziert werden, da die Re-Identifizierung die Operation ist, die den Klartext tatsächlich offenlegt.
• Cloud KMS Unwrap-Operationen gegen den Wrapping-Schlüssel, der automatisch über Cloud-Audit-Logs erfasst wird.
• Vorlagenänderungen zur Inspektions-/Deidentifizierungskonfiguration, die festlegt, auf welche Felder FPE angewendet wird und mit welchem ​​Alphabet.
• Lebenszyklusereignisse der Schlüsselversion (Rotation, geplante Vernichtung, Stornierung), damit ein Sicherheitsadministrator einen Vorfall, bei dem ein Wert nicht mehr identifiziert werden kann, einem bestimmten Schlüsselereignis zuordnen kann.

Was kostet FPE in der Google Cloud?

FPE selbst wird als Transformationsvorgang im Rahmen des Programms „Schutz sensibler Daten“ abgerechnet und unterliegt der gleichen Preisgestaltung wie die Tokenisierung im Allgemeinen (Inhaltsmethode oder Speicherauftrag): Die Kosten für eine Inhaltsmethoden-Transformation liegen bei etwa 2.00 $/GB nach einem kostenlosen Kontingent von 1 GB/Monat bis zu einem Datenvolumen von 1 TB. Darüber hinaus gilt ein niedrigerer Preis pro GB (bitte überprüfen Sie die aktuellen Preise auf der Google-Preisseite, da die Preise für „Schutz sensibler Daten“ gestaffelt sind und sich ändern können). Der Cloud-KMS-Wrapping-Key verursacht eine separate, nutzungsbasierte Gebühr für jeden Wrap-/Unwrap-Vorgang. Diese Gebühr skaliert mit der Anzahl der ausgeführten FPE-Vorgänge, nicht mit dem Volumen der gescannten Daten.

Ein Kostenaspekt, den die meisten Teams übersehen: Da FPE reversibel ist, fallen bei einer Arbeitslast, die sowohl beim Schreiben tokenisiert als auch beim Lesen neu identifiziert (z. B. ein Zahlungssystem), die Cloud-KMS-Operationskosten pro Datensatzlebenszyklus zweimal an, nicht nur einmal. Berücksichtigen Sie diese doppelte Anzahl an Operationen, bevor Sie die Gesamtkosten von FPE mit einem unidirektionalen Hashing- oder Maskierungsverfahren vergleichen, das keine Neuidentifizierung erfordert.

Wie sieht eine Multi-Cloud-FPE-Architektur aus?

Die Unterstützung für formatbewahrende Tokenisierung (FPE) ist bei den großen Cloud-Anbietern nicht einheitlich. Google Cloud hat FF1 direkt in den Schutz sensibler Daten integriert; AWS bietet keine native FPE-Funktion in AWS KMS und benötigt in der Regel eine Drittanbieterbibliothek oder die FPE-Implementierung eines Hardware-Sicherheitsmodul-Anbieters, die auf AWS CloudHSM läuft; Azure bietet ebenfalls keinen nativen FPE-Dienst und setzt für den schemaerhaltenden Schutz auf Partnerlösungen oder die deterministische Verschlüsselung von Always Encrypted (die nicht mit FPE identisch ist). Eine Multi-Cloud-Datenplattform, die eine konsistente formaterhaltende Tokenisierung über alle drei Clouds hinweg benötigt, muss sich im Allgemeinen auf eine Drittanbieter- oder selbstgehostete FPE-Bibliothek anstatt auf die nativen Tools jeder Cloud festlegen und das Schlüsselmaterial dieser Bibliothek in das jeweilige native KMS (Cloud KMS, AWS KMS, Azure Key Vault) einbinden, um eine konsistente Zugriffskontrolle und -prüfung zu gewährleisten.

In unserem Vergleich von AWS KMS, Azure Key Vault und GCP KMS erfahren Sie , wie sich die native Schlüsselverwaltungsschicht unterhalb jeder FPE-Implementierung bei den drei Anbietern unterscheidet.

Welche Einschränkungen gibt es bei formatbewahrender Verschlüsselung?

• FPE erhält Länge und Alphabet, nicht aber die semantische Gültigkeit. Ein nachgelagertes System, das eine Luhn-Prüfsumme für Kartennummern oder eine Datumsbereichsprüfung durchführt, kann FPE-Chiffretext ablehnen, sofern die Transformation nicht so konzipiert ist, dass diese spezifische Eigenschaft erhalten bleibt.
• Da FPE reversibel ist, erfüllt es nicht die Anforderungen, die eine irreversible De-Identifizierung oder Anonymisierung fordern; verwenden Sie stattdessen Hashing oder Generalisierung, wenn die Reversibilität selbst das Compliance-Problem darstellt.
• Aktuell ist nur FF1 zugelassen; Teams sollten FF3 aufgrund seiner bekannten kryptanalytischen Schwäche nicht für neue Projekte implementieren oder darauf zurückgreifen.
• Die Verantwortung für den Lebenszyklus der Schlüsselversionen liegt vollständig beim Kunden; Google verschlüsselt FPE-Werte nicht automatisch neu, wenn ein Wrapping-Schlüssel rotiert.

Entscheidungscheckliste: Bereitstellung von FPE auf Google Cloud

1. Prüfen Sie, ob das Feld tatsächlich eine Formatbeibehaltung (eine nachgelagerte Schema- oder Validierungsabhängigkeit) benötigt und nicht nur eine allgemeine Anonymisierung.
2. Verwenden Sie ausschließlich FF1; erstellen Sie keine neuen Workflows auf FF3.
3. Verpacken Sie den AES-Schlüssel in Cloud KMS und gewähren Sie ihm die entsprechende Berechtigung. cryptoKeyEncrypterDecrypter nur an das Dienstkonto, das den Datenschutz für sensible Daten aufruft.
4. Trennen Sie die Anonymisierungs- und Reidentifizierungsberechtigungen für IAM und überprüfen Sie den Reidentifizierungszugriff im gleichen Rhythmus wie den Zugriff auf Produktionsdaten.
5. Schreiben Sie das Runbook für die Schlüsselrotation und erneute Tokenisierung, bevor der erste Produktionswert tokenisiert wird.

Was würde Encryption Consulting empfehlen?

FPE-Implementierungen funktionieren in der Regel anfangs problemlos, werden aber bei der ersten Schlüsselrotation zum Problem, da das Runbook für die Re-Tokenisierung nicht erstellt wurde. Der Cloud-Datenschutz -Beratungsdienst von Encryption Consulting konzipiert gemeinsam den FPE-Schlüssellebenszyklus, die IAM-Aufteilung für De-Identifizierung/Re-Identifizierung und das Rotations-Runbook. Unser HSM-as-a-Service- Angebot bietet hardwaregestützte Verwahrung für die Cloud-KMS-Schlüssel, wo die Anforderungen von FIPS 140-3 erfüllt werden müssen.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen FPE und Tokenisierung?

Tokenisierung ist das allgemeine Konzept, einen sensiblen Wert durch ein Ersatztoken zu ersetzen. FPE ist eine spezielle kryptografische Technik zur Erzeugung dieses Ersatztokens, die garantiert, dass die Ausgabe dieselbe Länge und denselben Zeichensatz wie die Eingabe aufweist. Google Cloud Sensitive Data Protection bietet FPE neben zwei weiteren Tokenisierungsverfahren (deterministische AES-SIV-Verschlüsselung und kryptografisches Hashing).

Warum unterstützt Google Cloud nur FF1 und nicht FF3?

FF3 erwies sich bei einem Angriff im Jahr 2017 als kryptoanalytisch schwach, weshalb seine Sicherheitsmarge für den Produktiveinsatz als unzureichend angesehen wurde. FF1 verwendet mehr Feistel-Runden (10 gegenüber 8 bei FF3) und bleibt die empfohlene Methode.

Kann FPE-Chiffretext in einem Datenbankindex oder einer eindeutigen Einschränkung verwendet werden?

Ja, für deterministische FPE, da der gleiche Klartext unter dem gleichen Schlüssel und Alphabet immer den gleichen Chiffretext erzeugt, was ihn im Gegensatz zur randomisierten Verschlüsselung als Index- oder Join-Schlüssel ohne vorherige Entschlüsselung verwendbar macht.

Führt das Drehen des Cloud KMS-Wrapper-Schlüssels zu Datenverlusten bei bestehenden FPE-Daten?

Nicht sofort. Die Rotation erzeugt eine neue Schlüsselversion, ohne alte zu löschen. Daher bleibt vorhandener FPE-Chiffretext so lange identifizierbar, wie seine ursprüngliche Schlüsselversion noch existiert. Das Risiko besteht nur dann, wenn diese alte Version vor einer erneuten Tokenisierung zerstört wird.

Ist FPE nativ auf AWS oder Azure verfügbar, wie es bei Google Cloud der Fall ist?

Nein. Weder AWS KMS noch Azure Key Vault bieten eine native FPE-Funktion, die mit der FF1-Implementierung von Google Cloud innerhalb des Schutzes sensibler Daten vergleichbar ist; die meisten AWS- und Azure-Bereitstellungen greifen stattdessen auf die FPE-Implementierung einer Drittanbieterbibliothek oder eines Hardware-Sicherheitsmodulanbieters zurück.

Benötigen Sie Unterstützung bei der Gestaltung des Schlüssellebenszyklus hinter einer FPE-Einführung, und nicht nur beim Verschlüsselungsaufruf selbst? Sprechen Sie mit dem Cloud Data Protection Team von Encryption Consulting.