Tokenizarea datelor PII

Tokenizarea datelor PII

1) De ce tokenization și ce anume am tokenize

Scopul: excluderea accesului la date cu caracter personal „brute” în circuitul operațional și în analiză, reducerea riscului de scurgeri și simplificarea respectării cerințelor.
Exemple PII: nume complet, număr de telefon, e-mail, adresă, pașaport/ID, TIN, adrese IP, cookie-ID, identificatori de plată, data nașterii etc.

• nu divulgă valoarea inițială;
• poate fi reversibil (printr-un serviciu de detokenation sigur) sau ireversibil;
• poate fi determinist (pentru alăturare/căutare) sau nedeterminist (pentru confidențialitate maximă).

2) Modelul amenințării și obiectivele de control

Riscuri: scurgeri de baze de date/jurnal/backup, citiri insider, corelare prin repetarea valorilor, detokenizare neautorizată, atacuri dicționar/format (e-mail/telefon), reutilizarea secretelor.

1. Zone de încredere separate: aplicația funcționează cu token-uri, sursele - numai în serviciul token.

2. Garantați puterea criptografică a jetoanelor și a detokenării gestionate.

3. Reduceți raza de explozie cu KMS/HSM, rotație și sterilizare cripto.

4. Asigurarea adecvării pentru căutare/joyns/analytics cu risc controlat.

3) Tipologia jetoanelor

• PII pentru căutare/joynes: determinist reversibil, legat de regiune (chiriaș/domeniu de aplicare), blocat pe KMS.
• PII pentru mascarea operațională (UI): nedeterminist reversibil cu durata de viață pentru a reduce riscurile de reutilizare.
• Pentru analiza zonei gri: agregări ireversibile (cheie NMAC/sare) sau DP.

4) Arhitectura de tokenizare

4. 1 Componente

Tokenization Service (TS): „tokenize/detokenize/search” API, zonă de încredere ridicată.
Token Vault (TV): hartă protejată 'token → original (+ metadate)'.
KMS/HSM: stocare cheie rădăcină (KEK), operațiuni de ambalare/semnare.
Motor de politică: cine, unde și de ce se poate detokeniza; domeniul de aplicare/TTL/limitele de rată; mTLS/mTLS + mTLS.
Audit și imunitate: jurnalele neschimbabile ale tuturor operațiunilor de tokenizare/detokenizare.

4. 2 Ierarhia cheie

Root/KEK în KMS/HSM (per organizație/regiune/chiriaș).
DEK-PII per domeniu de date (e-mail/telefon/adresă) și/sau set de date.
Rotație: rewrap DEK fără a re-cripta întregul volt; Planul „compromisului cheie”.

4. 3 Fluxuri

1. Tokenize: TS → client (mTLS + A&A) → normalizare → calcul token → scriere la TV → răspuns token.
2. Detokenize - TS → Politica de → a clientului/Verificarea motivului → Verificarea sursei (sau Respingerea).
3. Căutare/Meci: tokenizarea deterministă vă permite să căutați după token; pentru e-mail/telefon - normalizați formatul înainte de tokenizare.

5) Modele token (design cripto)

5. 1 Reversibil (recomandat pentru circuitul operațional)

Plic AES-SIV/AEAD: „cifru = AEAD_Encrypt (DEK, PII, AAD = scope 'tenant' field')”; token = 'prefix' nonce 'cifru' tag '.
FPE (FF1/FF3-1) pentru formate (ex. telefon de 10 cifre fără cod de țară). Aplicați cu precauție și domeniul corect (alfabet/lungime).

5. 2 Ireversibil (analiză/anonimizare față)

Keyed HMAC/хэш: 'token = HMAC (PII_normalized, cheie = K _ scope)'; sare/piper - separat; per chiriaș sau set de date.
Minimizați riscul de coliziuni prin alegerea unei funcții (SHA-256/512) și a unui domeniu.

5. 3 Determinismul și domeniul de aplicare

Pentru a vă alătura, utilizați o schemă deterministă cu AAD = '{chiriaș' scop 'câmp}' → jetoanele diferite de aceeași valoare corespund unor ținte diferite.
Pentru anti-corelare în diferite servicii - chei/zone diferite.

5. 4 Minimizați atacurile dicționarului

Normalizarea (canonizarea e-mail/telefon), piper în KMS, limitarea dimensiunii domeniului (nu dau „nici o înregistrare găsite” erori ca un canal lateral), rata-limită și SARTSNA/proxy pentru puncte publice.

6) proiectare și scheme API

6. 1 REST/gRPC (opțiune)

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

'POST/v1/detokenize {token, purpose} -> {value}' (mTLS + OIDC + ABAC; „minimizarea” emisiunii)

'POST/v1/match {field, value} -> {token}' (cale de căutare deterministă)

6. 2 Diagrama de stocare (TV)

'tokens (field, scope, , token, , version, )'

Indici: prin „token”, prin „(tenant_id, câmp, hash_index)” pentru depreciere/căutare.
Indexul Hash (HMAC din PII normalizat) vă permite să căutați fără detokenizare.

6. 3 Conducte de normalizare

e-mail: micșorare, tăiere, canonică locală-parte (fără agresiv „mănâncă” de puncte pentru toate domeniile).
telefon: E.164 (cu codul de țară), eliminarea caracterelor de formatare.
adresă/nume: transliterare după reguli, tăiere, colaps spații.

7) Multi-chirie și izolare

Chei și spații de nume per chiriaș: KEK/DEK per chiriaș.
Politici de detokenizare: rol + obiectiv + cauză + audit eveniment.
Ștergerea cripto a datelor chiriașilor - revocarea KEK și distrugerea DEK → volți devine inutilă (pentru înregistrările sale).

8) Integrări

8. 1 Baze de date și cache-uri

Stocați numai jetoane în mesele de operare.
Cazurile rare necesită detokenizare în timpul zborului printr-un proxy/agent.
Token cache - numai în memorie cu un TTL scurt, fără a scrie pe disc.

8. 2 Analytics/BI/ML

În DWH/lac, jetoane sau hashes. Alăturați-vă se efectuează pe jetoanele deterministe ale domeniului de aplicare corespunzător.
Pentru ML, sunt preferate pseudonimizarea și agregatele; evitarea restabilirii persoanelor.

8. 3 Servicii de asistență și antifraudă

UI cu mască ('+ 380') și detokenizare episodică pentru un motiv rezonabil (cod motiv) + al doilea factor.

9) Rotație, versiuni și ciclu de viață

Separați ID-ul token și versiunea de criptare (v1/v2).
Rewrap: schimbați KEK fără a atinge datele.
Planul incidentului: compromisul cheie → rechemarea instantanee, interzicerea detokenizării, revenirea la „read-only”, lansarea repornirii.
Jetoane TTL: prin politică - permanentă (identificatori) sau scurtă (legături unice/integrări temporare).

10) Performanță și fiabilitate

Accelerații hardware (AES-NI/ARMv8), bazine de conexiuni la KMS, memoria cache a DEK-urilor învelite.
Scalare orizontală TS; împărțiți căile de citire/scriere.
Tasta Idempotency pentru repetări tokenize pentru steaguri de rețea.
DR/HA: multi-zona, asincron volt replica, teste regulate de recuperare.
SLO: p99 latență „tokenize” ≤ 50-100 ms; „cetokenize” ≤ 50 ms; disponibilitate ≥ 99. 9%.

11) Observabilitate, audit, conformitate

Valori: QPS prin metode, erori A&A, cota de detokenations (de roluri/goluri), cache hit-rate, timpul de funcționare KMS.
Audit (imuabil): fiecare detokenare cu „cine/ce/de ce/unde”, interogare hash, rezultat.
Politici de retenție și WORM pentru jurnal (a se vedea Jurnale de audit și imuabile).
Conformitate: GDPR (minimizare, dreptul de a șterge prin ștergere cripto), PCI DSS (pentru PAN - FPE/pseudonimizare), raportare ISO/SOC.

12) Testarea și siguranța

Teste de unitate cripto: stabilitatea tokenurilor deterministe, verificarea AAD și eșecul dacă nu se potrivește.
Teste negative: atacuri dicționar, format invers, rata-limită, CSRF (pentru panouri web), SSRF pentru backends.
Haos: KMS/Volt indisponibil, cheie moștenire, replicare parțială.
Echipa roșie periodică încearcă să se detokenizeze fără motiv și prin canale laterale.

13) Mini rețete

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) Greșeli frecvente și cum să le evitați

Jetoane în jurnale. Maschează jetoanele în sine (în special cele reversibile) - acestea sunt date sensibile.
O singură cheie "pentru orice. "Împărțiți pe chiriaș/câmp/obiectiv; utilizați AAD.
Normalizarea "la întâmplare. "Canonizarea necoordonată descompune căutarea/joynes.
Detokenizare fără cauză/limitare. Întotdeauna codul motiv, audit și rata-limită.
FPE ca un panaceu. Utilizați numai atunci când formatul este într-adevăr necesar și cu domeniul/cheile corecte.
Cache-uri de lungă durată pe disc. Cache numai în memorie cu TTL.
Nici un proces de reprelucrare. Rotirea KEK fără downtime este obligatorie.

15) Liste de verificare

Înainte de vânzare

• Profiluri token selectate pe câmp/țintă (reversibilitate/determinism/domeniu de aplicare).
• Ierarhia cheie (KEK/DEK), politicile KMS, auditul operațiunilor cheie sunt configurate.
• Normalizarea intrărilor, implementarea conductei de validare a formatului.
• Limită de rată, coduri de motive, audit imuabil activat.
• Teste pentru atacuri de dicționar/format/acces pe bază de rol trecut.
• DR/replica volt și planul de compromis cheie.

Funcționare

• Raport lunar de detokenation (cine/de ce/cât de mult).
• Rotație periodică a KEK/piper, rewrap DEK.
• Echipa roșie pentru canalele neautorizate de detokenare/laterale.
• Revizuiți normalizarea pe măsură ce apar noi formate/regiuni.

16) ÎNTREBĂRI FRECVENTE

Î: Tokenizare = anonimizare?
Oh, nu. Tokenizare - pseudonimizare. Sursa va fi restaurată (sau comparabilă) dacă există chei/volt. Pentru a ieși din sfera GDPR este nevoie de o anonimizare fiabilă.

Î: Cum să căutați prin e-mail/telefon fără detokenizare?
R: Tokenizare deteminată cu canonizare. Pentru adrese/nume complete - indici hash/chei de căutare și tabele auxiliare.

Î: Când este nevoie de FPE?
R: Atunci când un contract/schemă externă necesită format (lungime/alfabet). În alte cazuri, jetoanele AEAD obișnuite sunt mai simple și mai sigure.

Î: Este posibil să aveți un token pentru toate scopurile?
R: Scopuri diferite mai bune (scop/scop): același PII oferă jetoane diferite pentru diferite sarcini → reduce riscul de corelare.

Î: Cum vă exercitați „dreptul de a elimina”?
A: Ștergere cripto: revocați KEK/DEK pentru setul corespunzător și/sau ștergeți intrarea în volt + distrugeți tastele câmpului/părții; in analytics - TTL/agregare/depersonalizare.

• „Managementul secret”
• „La criptare de odihnă”
• „În criptarea tranzitului”
• „Confidențialitate prin design (GDPR)”
• „Audit și jurnale imuabile”
• „Managementul și rotația cheilor”