Tokenisierung von PII-Daten

Tokenisierung von PII-Daten

1) Warum Tokenisierung und was genau wir tokenisieren

Das Ziel: Den Rückgriff auf „rohe“ personenbezogene Daten im Betriebskreis und in der Analytik zu eliminieren, das Risiko von Leckagen zu reduzieren und die Compliance zu vereinfachen.
PII-Beispiele: Name, Telefon, E-Mail, Adresse, Pass/ID, TIN, IP-Adressen, Cookie-ID, Zahlungs-IDs, Geburtsdatum usw.

• den ursprünglichen Wert nicht offenbart;
• kann reversibel (durch einen geschützten Entgiftungsdienst) oder irreversibel sein;
• kann deterministisch (für join/search) oder nicht deterministisch (für maximale Privatsphäre) sein.

2) Bedrohungsmodell und Kontrollziele

Risiken: DB/Logs/Backups Leaks, Insiderlesungen, Korrelation durch repetitive Werte, unautorisierte Detokenisierung, Wörterbuch/Format Angriffe (E-Mail/Telefon), Wiederverwendung von Geheimnissen.

1. Teilen Sie Vertrauenszonen: Die App arbeitet mit Token, die Quellen nur im Token-Dienst.

2. Garantieren Sie die kryptographische Stabilität der Token und die kontrollierte Entgiftung.

3. Reduzieren Sie den Blast-Radius mit KMS/HSM, Rotation und „Krypto-Sterilisation“.

4. Stellen Sie die Eignung für Suche/Joins/Analyse unter kontrolliertem Risiko sicher.

3) Typologie der Token

• PII für Search/Joins: Reversibel deterministisch, flächengebunden (tenant/scope), mit Latch am KMS.
• PII für die operative Maskierung (UI): reversible nicht-deterministische mit einer Lebensdauer, um das Risiko der Wiederverwendung zu reduzieren.
• Für Analysen in der „Grauzone“: irreversible (Schlüssel-NMAS/Hash mit Salz) oder DP-Aggregationen.

4) Tokenisierung Architektur

4. 1 Komponenten

Tokenization Service (TS): API „tokenize/detokenize/search“, Zone mit erhöhtem Vertrauen.
Token Vault (TV): Geschützte Mapa 'Token → Original (+ Metadaten)'.
KMS/HSM: Root Key Storage (KEK), Wrapper/Signatur-Operationen.
Policy Engine: Wer, wo und warum kann entgiften; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: Unveränderliche Protokolle aller Tokenisierungs-/Entgiftungsvorgänge.

4. 2 Hierarchie der Schlüssel

Root/KEK im KMS/HSM (pro Organisation/Region/Mieter).
DEK-PII pro Daten-Domain (email/phone/address) und/oder Dataset.
Rotation: Rewrap DEK ohne Umschreiben des gesamten Volts; Plan „Kompromittierung des Schlüssels“.

4. 3 Ströme

1. Tokenize: Der Client → TS (mTLS + A&A) → die Normalisierung → Berechnung des Tokens → den Eintrag im TV → die Antwort des Tokens.
2. Detokenize: Client mit TS- → → Überprüfung der Richtlinie/Grundlage → Ausgabe der Quelle (oder Ablehnung).
3. Search/Match: deterministische Tokenisierung ermöglicht die Suche nach einem Token; für E-Mail/Telefon - normalisieren Sie das Format vor der Tokenisierung.

5) Token-Designs (Krypto-Design)

5. 1 Reversibel (empfohlen für die Operationsschleife)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; token = 'prefix' nonce' cipher 'tag'.
FPE (FF1/FF3-1) für Formate (z.B. 10-stelliges Telefon ohne Ländercode). Mit Vorsicht und der richtigen Domäne (Alphabet/Länge) anwenden.

5. 2 Irreversibel (Analytik/Anonymisierung am Rande)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; Salz/Pfeffer - getrennt; auf den Mieter oder das Dataset.
Das Kollisionsrisiko wird durch die Auswahl der Funktion (SHA-256/512) und der Domäne minimiert.

5. 3 Determinismus und Handlungsfeld

Um sich zu verbinden, verwenden Sie ein deterministisches Schema mit AAD ='{tenant 'purpose' field} '→ verschiedene Ziele entsprechen verschiedenen Token desselben Wertes.
Für Anti-Korrelation in verschiedenen Diensten - verschiedene Schlüssel/Bereiche.

5. 4 Minimierung von Wörterbuchangriffen

Normalisierung (Kanonisierung von E-Mail/Telefon), Pepper im KMS, Begrenzung der Domain-Größen (keine Fehler „no record found“ als Side-Channel), Rate-Limit und SARTSNA/Proxy für Public Points.

6) API-Design und Schema

6. 1 REST/gRPC (Option)

`POST /v1/tokenize { field, value, scope, tenant_id, purpose } -> { token, meta }`

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; „Minimierung“ der Ausstellung)

'POST/v1/match {field, value} -> {token}' (deterministischer Pfad für die Suche)

6. 2 Speicherschaltung (TV)

Таблица `tokens(field, scope, tenant_id, token, created_at, version, wrapped_key_id, hash_index)`

Indizes: durch 'token', durch'(tenant_id, Feld, hash_index) 'für De-Duplizierung/Suche.
Der Hash-Index (HMAC aus normalisiertem PII) ermöglicht eine Suche ohne Entgiftung.

6. 3 Normalisierungspipelines

email: lowercasing, trim, canonical local-part (ohne aggressives „Fressen“ von Punkten für alle Domains).
phone: E.164 (mit Ländercode), Löschen von Formatierungszeichen.
address/name: Transliteration nach Regeln, trim, collapse spaces.

7) Multi-Leasing und Isolierung

Schlüssel und Namensschilder pro Mieter: KEK/DEK per tenant.
Entgiftungsrichtlinien: Rolle + Zweck + Grund + Ereignis-Audit.
Krypto-Löschung von Mieterdaten - KEK-Rückruf und DEK → Volta-Zerstörung werden nutzlos (für seine Aufzeichnungen).

8) Integration

8. 1 Datenbanken und Caches

Speichern Sie nur Token in Operationstabellen.
Für seltene Fälle ist eine Detokenisierung „on the fly“ über einen Proxy/Agent erforderlich.
Token-Caches - nur im Speicher mit kurzer TTL, ohne auf die Festplatte zu schreiben.

8. 2 Analytik/BI/ML

In DWH/See gibt es Token oder Hashes. Join wird über die deterministischen Token des entsprechenden Scope ausgeführt.
Für ML - vorzugsweise Pseudonymisierung und Aggregate; die Wiederherstellung von Personen zu vermeiden.

8. 3 Unterstützungsdienste und Betrugsbekämpfung

UI mit Maske ('+ 380') und episodischer Entgiftung aus triftigem Grund (Grundcode) + zweiter Faktor.

9) Rotation, Versionen und Lebenszyklus

Trennen Sie die Token-ID und die Verschlüsselungsversion (v1/v2).
Rewrap: Ändern Sie den KEK, ohne die Daten zu berühren.
Incident Plan: Kompromittierung der Schlüssel → sofortiger Rückruf, Verbot der Entgiftung, Rollback auf „nur lesen“, Rewrap-Start.
TTL-Token: per Richtlinie - persistent (IDs) oder kurz (einmalige Links/temporäre Integrationen).

10) Leistung und Zuverlässigkeit

Hardware-Beschleunigungen (AES-NI/ARMv8), Verbindungspools zum KMS, Cache der eingewickelten DEKs.
Horizontale Skalierung TS; Trennen von Read/Write-Pfaden.
Idempotency-key für Tokenize-Wiederholungen bei Netzwerk-Flaps.
DR/HA: Multizone, asynchrone Volta-Replikation, regelmäßige Wiederherstellungstests.
SLO: p99 Latenz' tokenize' ≤ 50-100 ms; 'detokenize' ≤ 50 ms; Verfügbarkeit ≥ 99. 9%.

11) Beobachtbarkeit, Audit, Compliance

Metriken: QPS nach Methoden, A & A-Fehler, Anteil der Detokenitierungen (nach Rollen/Zielen), Hit-Rate des Caches, Zeit der KMS-Operationen.
Audit (unveränderlich): jede Detokenisierung mit 'who/what/why/where', Abfrage-Hash, Ergebnis.
Aufbewahrungs- und WORM-Richtlinien für das Protokoll (siehe „Überwachung und unveränderliche Protokolle“).
Compliance: DSGVO (Minimierung, Recht auf Löschung durch Krypto-Löschung), PCI DSS (für PAN - FPE/Pseudonymisierung), ISO/SOC Reporting.

12) Prüfung und Sicherheit

Krypto-Unit-Tests: Stabilität von deterministischen Token, Verifizierung von AAD und Ablehnung, wenn es inkonsistent ist.
Negative Tests: Wörterbuchangriffe, Reverse-to-Format, Rate-Limit, CSRF (für Web-Panels), SSRF auf Beckends.
Chaos: KMS/Volt nicht verfügbar, Legacy-Schlüssel, teilweise Replikation.
Periodisches Red-Team versucht, ohne Grund und über Seitenkanäle zu entgiften.

13) Mini-Rezepte

pii_norm = normalize(value)
aad   = scope          tenant          field dek   = kms. unwrap(kek_id, wrapped_dek_for_field)
token = aead_siv_encrypt (dek, pii_norm, aad) # deterministically store_vault (token, pii_norm, meta)
return token

pii_norm = normalize(value)
pepper  = kms. get_secret("pepper/"+tenant+"/"+field)
token = HMAC_SHA256 (pepper, pii_norm) # deterministically within scope return base64url (token)

allow if role in {SupportL2, Risk, DPO} and purpose in {KYC, Chargeback, DSAR}
and mTLS and OIDC_claims match tenant and reason_code provided and ticket_id linked rate_limit per actor <= N/min

kms. disable_key(kek_tenant)
access to unwrap is blocked → detoxification is not possible schedule_destroy (kek_tenant, hold_days=7)

14) Häufige Fehler und wie man sie vermeidet

Token in den Protokollen. Maskieren und Token selbst (insbesondere reversible) sind sensible Daten.
Ein einziger Schlüssel „für alles“. Teilen Sie nach Mietern/Feldern/Zielen; AAD verwenden.
Normalisierung „wie es kam“. Unkoordinierte Kanonisierung bricht die Suche/Joins.
Entgiftung ohne Ursachen/Einschränkungen. Immer reagieren Code, Audit und Rate-Limit.
FPE als Allheilmittel. Nur anwenden, wenn das Format wirklich benötigt wird und mit der richtigen Domäne/den richtigen Schlüsseln.
Langlebige Caches auf der Festplatte. Cache nur im Speicher mit TTL.
Kein Rewrap-Prozess. Eine KEK-Rotation ohne Ausfallzeiten ist Pflicht.

15) Checklisten

Vor dem Verkauf

• Ausgewählte Token-Profile pro Feld/Ziel (Reversibilität/Determinismus/Region).
• Konfigurierte Schlüsselhierarchie (KEK/DEK), KMS-Richtlinien, Überwachung von Schlüsseloperationen.
• Normalisierung der Eingänge, Formatvalidierungspipeline implementiert.
• Einschliesslich rate-limit, reason-codes, unveränderliches Audit.
• sind die Prüfungen auf wörterbuch- ataki/format/rol-basirowannyj der Zugang vorbeigekommen.
• DR/Volta-Replik und Schlüsselkompromittierungsplan.

Betrieb

• Monatlicher Bericht über Detokenisierungen (wer/warum/wie viel).
• Periodische Rotation KEK/Pfeffer, Rewrap DEK.
• Red-Team für nicht autorisierte Detox/Seitenkanäle.
• Überarbeitung der Normalisierung bei neuen Formaten/Regionen.

16) FAQ

F: Tokenisierung = Anonymisierung?
Oh, nein. Tokenisierung - Pseudonymisierung. Die Quelle wird wiederhergestellt (oder vergleichbar), wenn Schlüssel/Volta vorhanden sind. Um den Geltungsbereich der DSGVO zu verlassen, ist eine zuverlässige Anonymisierung erforderlich.

F: Wie suche ich per E-Mail/Telefon ohne Entgiftung?
A: Deteminierte Tokenisierung mit Kanonisierung. Für Adressen/Name - Hash-Indizes/Suchschlüssel und Hilfstabellen.

F: Wann wird FPE benötigt?
A: Wenn ein externer Vertrag/Schema ein Format (Länge/Alphabet) erfordert. In anderen Fällen sind herkömmliche AEAD-Token einfacher und sicherer.

F: Ist ein Token für alle Zwecke möglich?
A: Verschiedene Bereiche sind besser (Scope/Purpose): Derselbe PII gibt verschiedene Token für verschiedene Aufgaben → das Korrelationsrisiko wird reduziert.

F: Wie erfülle ich das „Recht auf Löschung“?
A: Krypto-Löschung: Wir widerrufen KEK/DEK für den entsprechenden Satz und/oder löschen den Eintrag in der Volta + zerstören die Feld-/Partienschlüssel; in der Analytik - TTL/Aggregation/Anonymisierung.

• „Management von Geheimnissen“
• „At Rest Verschlüsselung“
• „Verschlüsselung im Transit“
• «Privacy by Design (GDPR)»
• „Audit und unveränderliche Protokolle“
• „Schlüsselmanagement und Rotation“