Tokénisation des données PII

Tokenization des données PII

1) Pourquoi Tokenization et exactement ce que Tokenizons

Objectif : éliminer le recours aux données personnelles « brutes » dans le circuit opérationnel et l'analyse, réduire les risques de fuites et simplifier la conformité.
Exemples de PII : Nom, téléphone, email, adresse, passeport/ID, INN, adresses IP, cookie-ID, identifiants de paiement, date de naissance, etc.

• ne révèle pas la valeur initiale ;
• peut être réversible (via un service de désintoxication sécurisé) ou irréversible ;
• peut être déterministe (pour le join/recherche) ou non déterministe (pour une intimité maximale).

2) Modèle de menace et objectifs de contrôle

Risques : fuites OBD/logs/backup, lectures d'initiés, corrélation par valeurs répétées, désintoxication non autorisée, attaques par dictionnaire/format (email/téléphone), réutilisation des secrets.

1. Diviser les zones de confiance : l'application fonctionne avec les tokens, les sources - seulement dans le service de token.

2. Garantir la résistance cryptographique des tokens et la désintoxication contrôlée.

3. Réduire le radius blast avec KMS/HSM, rotation et « crypto-stérilisation ».

4. Assurez-vous que vous êtes apte à la recherche/joyaux/analyse à un risque contrôlé.

3) Typologie des tokens

• PII pour la recherche/joyaux : déterministes réversibles, attachés à une zone (tenant/scope), avec un verrou sur le KMS.
• IPI pour le masquage opérationnel (IU) : réversible non déterminable avec une durée de vie pour réduire les risques de réutilisation.
• Pour les analystes en « zone grise » : irréversibles (NMAS/hachage clé avec sel) ou agrégations DP.

4) Architecture de tokenization

4. 1 Composants

Tokenization Service (TS) : API « tokenize/detokenize/search », zone de confiance accrue.
Token Vault (TV) : map'token protégé → original (+ métadonnées) ".
KMS/HSM : stockage des clés racines (KEK), opérations d'emballage/signature.
Moteur de politique : qui, où et pourquoi peut se désintéresser ; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutabilité : journaux immuables de toutes les opérations de tokenization/désintoxication.

4. 2 Hiérarchie des clés

Root/KEK en KMS/HSM (par organisation/région/locataire).
DEK-PII par domaine de données (email/phone/address) et/ou dataset.
Rotation : rewrap DEK sans transpiration de l'ensemble du volt ; un plan « compromettant la clé ».

4. 3 Flux

1. Tokenize : le client → TS (mTLS + A&A) → la normalisation → le calcul du token → l'enregistrement dans la TV → la réponse par le token.
2. Detokenize : client avec des droits de → TS → la vérification de la politique/de la base → l'émission de l'origine (ou le refus).
3. Recherche/Match : La tokenisation déterministe permet la recherche par token ; pour l'email/téléphone - normaliser le format avant la tokenisation.

5) Conception de tokens (crypto-conception)

5. 1 Réversible (recommandé pour le circuit opérationnel)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; token = 'prefix' nonce 'cipher' tag '.
FPE (FF1/FF3-1) pour les formats (par exemple, téléphone à 10 chiffres sans code de pays). Appliquer avec soin et avec le bon domaine (alphabet/longueur).

5. 2 Irréversibles (analyse/anonymisation à la limite)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; sel/pepper - séparé ; par locataire ou datacet.
Le risque de conflit est minimisé par le choix de la fonction (SHA-256/512) et du domaine.

5. 3 Déterminisme et domaine d'action

Pour join, utilisez un schéma déterministe avec AAD = '{tenant' purpos'field} '→ différents tokens de la même valeur correspondent à différentes cibles.
Pour l'anti-corrélation dans les différents services - différentes clés/zones.

5. 4 Minimisons les attaques selon le dictionnaire

Normalisation (canalisation email/téléphone), pepper dans KMS, limitation de la taille du domaine (ne pas donner l'erreur « aucun enregistrement trouvé » comme canal side), rate-limit et SARTSNA/proxy pour les points publics.

6) Conception de l'API et des schémas

6. 1 REST/gRPC (version)

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

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; « minimisation » de l'extradition)

'POST/v1/match {field, value} -> {token} '(chemin de recherche déterministe)

6. 2 Circuit de stockage (TV)

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

Index : par 'token', par '(tenant_id, champ, hash_index)' pour la duplication/recherche.
L'indice Hash (HMAC d'un PII normalisé) permet une recherche sans désintoxication.

6. 3 Convoyeurs de normalisation

email : lowercasing, trim, canonical local-part (pas de « manger » agressif des points pour tous les domaines).
phone : E.164 (avec code pays), supprimer les caractères de formatage.
address/name : translittération par règles, trim, collapse spaces.

7) Polyvalence et isolation

Clés et namespaces par locataire : KEK/DEK per tenant.
Politiques de désintoxication : rôle + objectif + cause + event-audit.
Crypto-suppression des données du locataire - la révocation de KEK et la destruction de DEK → volt devient inutile (pour ses enregistrements).

8) Intégration

8. 1 Bases de données et caches

Ne stockez que les jetons dans les tables d'exploitation.
Pour les cas rares, vous avez besoin d'une désintoxication « à la volée » via un mandataire/agent.
Cache de token - seulement en mémoire avec TTL court, pas d'écriture sur disque.

8. 2 Analyse/BI/ML

Dans le DWH/lac - jetons ou hachages. Join est exécuté à partir des tokens déterministes de la scope correspondante.
Pour ML - de préférence pseudonymisation et agrégats ; éviter le rétablissement de la personne.

8. 3 Services de soutien et antifrod

UI avec masque (« + 380 ») et désintoxication épisodique pour une raison justifiée (code reason) + second facteur.

9) Rotation, versions et cycle de vie

Séparez l'ID de token et la version de cryptage (v1/v2).
Rewrap : on change KEK sans toucher aux données.
Le plan des incidents : компрометация des clés → le rappel instantané, l'interdiction детокенизации, le recul jusqu'à "read-only", la mise en marche rewrap.
Tokens TTL : par politique - permanents (identifiants) ou courts (liens jetables/intégrations temporaires).

10) Performance et fiabilité

Accélérations matérielles (AES-NI/ARMv8), pools de connexion au KMS, cache de DEK enveloppé.
Mise à l'échelle horizontale du TS ; séparation des chemins de lecture/écriture.
Idempotency-key pour les répétitions tokenize dans les flaps réseau.
DR/HA : multizonalité, réplique de volt asynchrone, tests de récupération réguliers.
SLO : p99 latences 'tokenize' ≤ 50-100 ms ; 'detokenize' ≤ 50 ms ; disponibilité ≥ 99. 9%.

11) Observation, audit, conformité

Métriques : QPS par méthode, erreurs A et A, proportion de désintoxications (par rôle/cible), cache hit-rate, durée des opérations KMS.
Audit (immuable) : chaque désintoxication avec 'who/what/why/where', hachage de requête, résultat.
Stratégies de stockage et WORM pour le journal (voir Audits et journaux immuables).
Conformité : RGPD (minimisation, droit de suppression par crypto-effacement), PCI DSS (pour PAN - FPE/pseudonymisation), rapport ISO/SOC.

12) Tests et sécurité

Tests crypto-unitaires : stabilité des tokens déterministes, vérification AAD et défaillance en cas de non-conformité.
Tests négatifs : attaques par dictionnaire, inverse de format, rate-limit, CSRF (pour les panneaux Web), SSRF sur les beckends.
Chaos : KMS/volt non disponible, clé obsolète, réplication partielle.
Des tentatives périodiques de désintoxication de Red-Team sans raison et par des canaux latéraux.

13) Mini recettes

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) Erreurs fréquentes et comment les éviter

Jetons dans les logs. Masquer et les jetons eux-mêmes (particulièrement réversibles) sont des données sensibles.
Une seule clé pour tout. Diviser par locataires/champs/cibles ; utilisez AAD.
La normalisation « comment c'est arrivé ». La canonisation incohérente brise la recherche/joyaux.
Désintoxication sans motifs/restrictions. Toujours code reason, audit et rate-limit.
FPE comme panacée. Appliquer uniquement si le format est vraiment nécessaire et avec le bon domaine/clés.
Caches à longue durée de vie sur le disque. Cache uniquement en mémoire TTL.
Pas de rewrap. La rotation KEK sans temps d'arrêt est obligatoire.

15) Chèques-feuilles

Avant la vente

• Les profils de token par champ/cible (réversibilité/déterminisme/zone) ont été sélectionnés.
• La hiérarchie des clés (KEK/DEK), les politiques KMS, l'audit des opérations clés ont été configurés.
• Normalisation des entrées, pipeline de validation des formats.
• Inclus rate-limit, reason-codes, vérification immuable.
• Les tests d'attaques de vocabulaire/format/rôle-based access sont passés.
• DR/réplique de volt et plan de compromission des clés.

Exploitation

• Rapport mensuel sur la désintoxication (qui/pourquoi/combien).
• Rotation périodique KEK/pepper, rewrap DEK.
• Red-team sur la désintoxication non autorisée/canaux latéraux.
• Révision de la normalisation lorsque de nouveaux formats/régions apparaissent.

16) FAQ

Q : Tokenisation = anonymisation ?
Oh non. Tokenization - pseudonyme. L'origine sera restaurée (ou comparable) si vous avez des clés/volts. Une anonymisation fiable est nécessaire pour quitter le domaine du RGPD.

Q : Comment chercher par email/téléphone sans désintoxication ?
R : Tokenisation déteminée avec canonisation. Pour les adresses/FIO - index de hachage/clés de recherche et tables auxiliaires.

Q : Quand le FPE est-il nécessaire ?
R : Lorsque le contrat/schéma externe nécessite un format (longueur/alphabet). Dans les autres cas, les jetons AEAD sont plus faciles et plus sûrs.

Q : Un jeton peut-il être utilisé à toutes fins ?
R : Mieux vaut des zones différentes (scope/purpose) : le même PII donne des jetons différents pour différentes tâches, → le risque de corrélation est réduit.

Q : Comment effectuer le « droit de suppression » ?
R : Crypto-suppression : Nous rappelons KEK/DEK pour l'ensemble correspondant et/ou nous supprimons l'enregistrement dans la vague + nous détruisons les clés de champ/lot ; en analyse, TTL/aggrégation/impersonnalisation.

• « Gestion des secrets »
• Cryptage At Rest
• Cryptage In Transit
• «Privacy by Design (GDPR)»
• Audit et journaux invariables
• Gestion des clés et rotation