Tokenización de datos PII

Tokenización de datos PII

1) Por qué la tokenización y qué es exactamente tokenizamos

Objetivo: eliminar el acceso a datos personales «crudos» en el circuito operativo y análisis, reducir el riesgo de fugas y simplificar el cumplimiento.
Ejemplos PII: FIO, teléfono, correo electrónico, dirección, pasaporte/ID, DNI, direcciones IP, ID de cookie, ID de pago, fecha de nacimiento, etc.

• no revela el valor original;
• puede ser reversible (a través de un servicio de desintoxicación protegido) o irreversible;
• puede ser determinista (para join/search) o no determinista (para máxima privacidad).

2) Modelo de amenazas y objetivos de control

Riesgos: fugas de BD/logs/backups, lecturas con información privilegiada, correlación por valores repetitivos, desintoxicación no autorizada, ataques por diccionario/formato (email/teléfono), reutilización de secretos.

1. Dividir zonas de confianza: la aplicación funciona con tokens, los orígenes sólo en el servicio de token.

2. Garantizar la durabilidad criptográfica de los tokens y la desintoxicación controlada.

3. Reduzca el blast radius con KMS/HSM, rotación y «cifrado-esterilización».

4. Garantizar la idoneidad para la búsqueda/joynes/análisis en riesgo controlado.

3) Tipología de tokens

• PII para búsqueda/joynes: determinista reversible, enlazado al área (tenant/scope), con un pestillo en KMS.
• PII para enmascaramiento operativo (IU): no determinista reversible con vida útil para reducir los riesgos de reutilización.
• Para los analistas en la «zona gris»: irreversibles (clave NMAS/hash con sal) o agregaciones DP.

4) Arquitectura de tokenización

4. 1 Componentes

Tokenization Service (TS): API «tokenize/detokenize/search», una zona de mayor confianza.
Token Vault (TV): mapa protegida 'token → original (+ metadatos)'.
KMS/HSM: almacenamiento de claves raíz (KEK), operaciones de envoltura/firma.
Policy Engine: quién, dónde y por qué puede desintoxicar; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: registros inmutables de todas las operaciones de tokenización/desintoxicación.

4. 2 Jerarquía de claves

Root/KEK en KMS/HSM (por organización/región/inquilino).
DEK-PII por dominio de datos (email/phone/address) y/o dataset.
Rotación: rewrap DEK sin volver a cifrar todo el volt; un plan de «compromiso clave».

4. 3 Hilos

1. Tokenize: cliente → TS (mTLS + A&A) → normalización → cálculo de token → escritura en TV → respuesta con token.
2. Detokenize: cliente con derechos de → TS → verificación de políticas/motivos → emisión de origen (o denegación).
3. Search/Match: la tokenización determinista permite buscar por token; para correo electrónico/teléfono: normalizamos el formato antes de la tokenización.

5) Diseños de tokens (diseño criptográfico)

5. 1 Reversible (recomendado para el circuito operativo)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; token = 'prefix' nonce 'cipher' tag '.
FPE (FF1/FF3-1) para formatos (por ejemplo, un teléfono de 10 dígitos sin código de país). Aplicar con precaución y el dominio correcto (alfabeto/longitud).

5. 2 Irreversibles (analítica/anonimización en el borde)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; sal/pepper - separado; sobre el inquilino o el dataset.
El riesgo de colisiones se minimiza con la selección de la función (SHA-256/512) y el dominio.

5. 3 Determinismo y campo de acción

Para join, utilice un esquema determinista con AAD = '{tenant' purpose 'field}' → diferentes objetivos corresponden a diferentes tokens del mismo valor.
Para la anti-correlación en diferentes servicios - diferentes claves/áreas.

5. 4 Minimiza los ataques por diccionario

Normalización (canonización de correo electrónico/teléfono), pepper en KMS, límite de tamaño de dominio (no dar error «no se encuentra registro» como canal lateral), rate-limit y SARTSNA/proxy para puntos públicos.

6) Diseño de API y diagramas

6. 1 NAT/gRPC (opción)

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

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; «minimización» de la extradición)

'POST/v1/match {field, value} -> {token}' (ruta determinista para buscar)

6. 2 Esquema de almacenamiento (TV)

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

Índices: por 'token', por '(tenant_id, campo, hash_index)' para la duplicación/búsqueda.
Hash index (HMAC de PII normalizado) permite la búsqueda sin desintoxicación.

6. 3 Transportadores de normalización

email: lowercasing, trim, canonical local-part (sin «comer» puntos agresivos para todos los dominios).
phone: E.164 (con código de país), eliminación de caracteres de formato.
address/name: transliteración por reglas, trim, espacios collapse.

7) Multi-alquiler y aislamiento

Llaves y namespaces en el inquilino: KEK/DEK per tenant.
Políticas de desintoxicación: rol + objetivo + causa + auditoría de eventos.
Crypto-eliminación de los datos del inquilino - la revisión de KEK y la destrucción de DEK → volt se vuelve inútil (para sus registros).

8) Integración

8. 1 Bases de datos y cachés

Almacene sólo los tokens en las tablas operativas.
Para casos raros, se necesita desintoxicación «sobre la marcha» a través de un proxy/agente.
Cachés de tokens: sólo en memoria con TTL corta, sin escritura en disco.

8. 2 Análisis/BI/ML

En DWH/lago - tokens o hashes. Join se ejecuta sobre los tokens deterministas del scope correspondiente.
Para ML, preferiblemente seudonimización y agregados; evitar la restauración de las personas.

8. 3 Servicios de soporte y antifraude

IU con mascarilla ('+ 380') y desintoxicación esporádica por causa justificada (código reason) + factor segundo.

9) Rotación, versiones y ciclo de vida

Separe el identificador del token y la versión de cifrado (v1/v2).
Rewrap: cambiamos KEK sin tocar los datos.
Plan de incidentes: compromiso de claves → revocación instantánea, prohibición de desintoxicación, retroceso a «sólo lectura», lanzamiento de rewrap.
TTL de tokens: por política: constantes (identificadores) o cortas (referencias desechables/integraciones temporales).

10) Rendimiento y confiabilidad

Aceleraciones de hardware (AES-NI/ARMv8), grupos de conexiones a KMS, caché envuelto en DEK.
Escala horizontal de TS; división read/write de las maneras.
Idempotency-key para repeticiones de tokenize en flaps de red.
DR/HA: multizonalidad, réplica asíncrona de wolt, pruebas de recuperación regulares.
SLO: p99 de latencia 'tokenize' ≤ 50-100 ms; 'detokenize' ≤ 50 ms; disponibilidad ≥ 99. 9%.

11) Observabilidad, auditoría, cumplimiento

Métricas: QPS por métodos, errores A&A, proporción de desintoxicaciones (por roles/objetivos), memoria caché hit-rate, tiempo de operaciones KMS.
Auditoría (inmutable): cada desintoxicación con 'who/what/why/where', hash de consulta, resultado.
Políticas de retención y WORM para el registro (consulte Auditoría y registros inmutables).
Cumplimiento: GDPR (minimización, derecho de eliminación a través de cifrado-borrado), PCI DSS (para PAN - FPE/seudonimización), informes ISO/SOC.

12) Pruebas y seguridad

Pruebas de criptomonedas: estabilidad de tokens deterministas, verificación de AAD y fallo en su inconsistencia.
Pruebas negativas: ataques por diccionario, reverso por formato, rate-limit, CSRF (para paneles web), SSRF en beckends.
Chaos: KMS/volt no está disponible, clave obsoleta, replicación parcial.
Periódicamente, el equipo rojo intenta desintoxicar sin motivo y a través de canales laterales.

13) Mini recetas

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) Errores frecuentes y cómo evitarlos

Los tokens están en los logs. Enmascarar y los propios tokens (especialmente los reversibles) son datos sensibles.
Una llave única «para todo». Dividir por inquilinos/campos/objetivos; use AAD.
Normalización «como cayó». La canonización inconsistente rompe la búsqueda/joyna.
Desintoxicación sin razones ni limitaciones. Siempre reason code, auditoría y rate-limit.
FPE como panacea. Aplique sólo cuando sea realmente necesario un formato y con el dominio/claves correctos.
Cachés de larga vida en el disco. Caché sólo en memoria con TTL.
No hay proceso rewrap. La rotación KEK sin tiempo de inactividad es obligatoria.

15) Hojas de cheques

Antes de la venta

• Se han seleccionado perfiles de tokens per campo/objetivo (reversibilidad/determinismo/área).
• Se ha configurado la jerarquía de claves (KEK/DEK), las políticas de KMS y la auditoría de las operaciones clave.
• Normalización de entradas implementada, transportador de validación de formatos.
• Incluye rate-limit, reason-codes, auditoría inmutable.
• Se han superado las pruebas de ataque de vocabulario/formato/acceso basado en roles.
• DR/réplica de wolt y plan de compromiso de claves.

Operación

• Informe mensual sobre desintoxicaciones (quién/por qué/cuánto).
• Rotación periódica KEK/pepper, rewrap DEK.
• Equipo rojo para desintoxicación no autorizada/canales laterales.
• Revisar la normalización cuando aparezcan nuevos formatos/regiones.

16) FAQ

P: ¿Tokenización = anonimización?
Oh no. Tokenización - seudonimización. El origen es recuperable (o comparable) si hay claves/volt. Para salir de la esfera GDPR se requiere un anonimato confiable.

P: ¿Cómo buscar por correo electrónico/teléfono sin desintoxicación?
R: Tokenización deteminada con canonización. Para direcciones/FIO - hash índices/claves de búsqueda y tablas auxiliares.

P: ¿Cuándo necesita FPE?
R: Cuando un contrato/esquema externo requiere un formato (longitud/alfabeto). En el resto de los casos, los tokens AEAD convencionales son más fáciles y seguros.

P: ¿Es posible un solo token para todos los propósitos?
R: Mejor diferentes áreas (scope/purpose): el mismo PII da diferentes tokens para diferentes tareas → disminuye el riesgo de correlación.

P: ¿Cómo puedo cumplir con el «derecho de eliminación»?
R: Crypto-eliminación: revocamos KEK/DEK para el conjunto correspondiente y/o eliminamos la entrada en volta + destruimos las claves de campo/lote; en análisis - TTL/agregación/despersonalización.

• «Gestión de secretos»
• «Encriptación de At Nat»
• «Encriptación In Transit»
• «Privacy by Design (GDPR)»
• «Auditoría y registros inmutables»
• «Administración de claves y rotación»