Toquenização de dados PII

Toquenizar dados PII

1) Porquê a toquenização e exatamente o que estamos tocando

O objetivo é eliminar o recurso a dados pessoais «crus» no circuito de operações e análise, reduzir o risco de vazamentos e simplificar a conformidade.
Exemplos PII: FIO, telefone, email, endereço, passaporte/ID, INN, endereços IP, cookie-ID, identificadores de pagamento, data de nascimento, etc.

• não revela o valor original;
• pode ser reversível (através de um serviço de detonação seguro) ou irreversível;
• pode ser determinado (para join/busca) ou não-minado (para privacidade máxima).

2) Modelo de ameaças e objetivos de controle

Riscos: vazamentos de BD/logs/bacapes, leituras privilegiadas, correlação por valores repetitivos, detonação não autorizada, ataques por dicionário/formato (email/telefone), reutilização de segredos.

1. Separar as áreas de confiança: o aplicativo funciona com tocadores e os fontes apenas no serviço de Tóquio.

2. Assegure a resistência criptográfica dos tokens e a detonação controlada.

3. Reduzir a radius blast usando KMS/HSM, rotação e «cripto-esterilização».

4. Garantir a capacidade de busca/joynes/analistas em risco controlado.

3) Tipologia de tokens

• PII para busca/joyn: Detectores reversíveis amarrados à área (tenant/scope), com fechadura em KMS.
• PII para camuflagem operacional (UI): reversíveis não detectíveis com vida para reduzir os riscos de reutilização.
• Para os analistas na «zona cinzenta»: irreversíveis (chave NMAS/hash com sal) ou agregações DP.

4) Arquitetura de toquenização

4. 1 Componentes

Tokenization Service (TS): API «tokenize/detokenize/search», área de maior confiança.
Token Vault (TV): proteção mapha 'tocen → original (+ metadados)'.
KMS/HSM: armazenamento de chaves de raiz (KEK), operações de embrulho/assinatura.
Policy Engine: Quem, onde e porquê pode detonar; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Check & Imutability: Registros imutáveis de todas as operações de toquenização/detonação.

4. 2 Hierarquia das chaves

Root/KEK em KMS/HSM (para organização/região/locatário).
DEK-PII para domínio de dados (email/phone/address) e/ou datse.
Rotação: rewrap DEK sem codificar todo o volt; Plano de comprometimento da chave.

4. 3 Fluxos

1. Tokenize: cliente → TS (mTLS + A&A) → normalização → computação do token → entrada na TV → resposta em token.
2. Detokenize: cliente com direitos de → TS → verificação de política/base → emissão de origem (ou recusa).
3. Search/Match: A localização definida permite a busca por token; para email/telefone - normalize o formato antes da localização.

5) Projetos de tokens (cripto-design)

5. 1 Reversível (recomendado para o circuito operacional)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; token = 'prefix' nance 'cipher' tag '.
FPE (FF1/F3-1) para formatos (por exemplo, telefone de 10 dígitos sem código de país). Aplicar com cuidado e domínio correto (alfabeto/comprimento).

5. 2 Irreversíveis (analista/anonimato à margem)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; sal/pepper - separado; por locatário ou dataset.
Risco de conflito minimizar a escolha da função (SHA-256/512) e domínio.

5. 3 Determinismo e campo de ação

Para um join, use um esquema de determinação com AAD = 'se tenant' purpose 'field, → vários alvos correspondem a tocantes diferentes do mesmo valor.
Para a anti-correlação em serviços diferentes são chaves/áreas diferentes.

5. 4 Minimizar ataques no dicionário

Normalização (canonização de email/telefone), pepper em KMS, limitação de tamanho de domínio (não dar o erro de «gravação não encontrada» como site), rate-limit e SARTSNA/proxy para pontos públicos.

6) Design de API e circuitos

6. 1 REST/gRPC (opção)

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

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; «Minimizar» a emissão)

'POST/v1/match

6. 2 Esquema de armazenamento (TV)

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

Índices: 'tocen', '(tenant _ id, field, hash _ index)' para duplicação/pesquisa.
O hash index (HMAC do PII normalizado) permite a busca sem detonação.

6. 3 Linhas de montagem da normalização

email: lowercasing, trim, canonical local-partt (sem «comidas» agressivas para todos os domínios).
phone: E.164 (com código de país), remoção de caracteres de formatação.
address/name: translitoração de acordo com as regras, trim, collapse spaces.

7) Multiplicidade e isolamento

Chaves e namespaces no locador: KEK/DEK per tenant.
Políticas de detonação: rol + alvo + causa + auditoria de eventos.
Cripto remoção de dados do locatário - levantamento KEK e destruição DEK → volt se torna inútil (para seus registros).

8) Integração

8. 1 Bancos de dados e cachês

Guarde apenas os tokens nas planilhas operacionais.
Para as malas raras, é preciso detonar «voando» através do proxy/agente.
Os cachês de tokens são apenas na memória com TTL curto, sem gravação em disco.

8. 2 Analista/BI/ML

Em DWH/lago - tokens ou hachis. O Join é executado através de tocadores determinados.
Para ML - Preferencialmente pseudônimos e agregados; evitar recuperar a personalidade.

8. 3 Serviços de suporte e antifrode

UI com máscara ('+ 380') e detonação ocasional por uma razão razoável (reason código) + segundo fator.

9) Rotação, versões e ciclo de vida

Divida a ID do token e a versão da criptografia (v1/v2).
Rewrap: Alterando o KEK sem tocar nos dados.
Plano de incidentes: comprometimento de chaves → revisão instantânea, proibição de detonação, reversão para «read-only», lançamento de rewrap.
TTL de tokens: por política - permanente (ID) ou curto (referências descartáveis/integração temporária).

10) Desempenho e confiabilidade

Acelerações de hardware (AES-NI/ARMv8), pool de conexões KMS, dinheiro DEK envolto.
Escala horizontal do TS; separação de caminhos read/write.
Idempotency-key para repetições de tokenize em flaps de rede.
DR./HA: Multiplicidade, réplica asincrona de volt, testes regulares de recuperação.
SLO: p99 latência 'tokenize' ≤ 50-100 ms; 'detokenize' ≤ 50 ms; disponibilidade ≥ 99. 9%.

11) Observabilidade, auditoria, complacência

Métricas: QPS de métodos, erros A&A, proporção de detecção (por papéis/objetivos), hit-rate de cachê, tempo de operações KMS.
Auditoria (inalterável): cada detecção com 'who/what/why/where', hash de consulta, resultado.
Políticas de armazenamento e WORM para o registro (consulte Auditoria e registros imutáveis).
Conformidade: GDPR (minimização, direito de remoção por cripto-apagado), PCI DSS (para PAN - FPE/pseudônimo), relatório ISO/SOC.

12) Testes e segurança

Testes cripto-unit: estabilidade dos tokens determinados, verificação da AAD e falha na sua discrepância.
Testes negativos: ataques com dicionário, reversível por formato, rate-limit, CSRF (para painéis na Web), SSRF por becendes.
Chaos: KMS/volt não disponível, chave obsoleta, replicação parcial.
Tentativas de detonação periódicas do Red-Team sem fundamento e através de canais laterais.

13) Mini-receitas

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) Erros frequentes e como evitá-los

Os tokens estão nos logs. Disfarce também os tokens (especialmente os reversíveis) são dados sensíveis.
Uma única chave para tudo. Divida por locadores/campos/alvos; use AAD.
A normalização do «como está». A canonização incoerente quebra a pesquisa/joyne.
Detonação sem motivos ou restrições. Sempre reason código, auditoria e rate-limit.
FPE como panaceia. Aplicar apenas se o formato for realmente necessário e com o domínio/chave correto.
Cachês de longa vida no disco. O dinheiro está apenas na memória do TTL.
Nenhum processo rewrap. A rotação KEK sem interrupção é obrigatória.

15) Folhas de cheque

Antes de vender

• Os perfis de tokens selecionados são campo/alvo (reversível/determinismo/área).
• A hierarquia de chaves (KEK/DEK), as políticas KMS, a auditoria de operações-chave.
• A normalização de entradas, a linha de montagem de validação de formatos, está implementada.
• Incluídos rate-limit, reason-codes, auditoria imutável.
• Testes de ataque/formato/rol-baseado foram ultrapassados.
• DR./réplica de volt e plano de comprometimento de chaves.

Operação

• Relatório mensal de detonação (quem/por quê/quanto).
• Rotação periódica KEK/pepper, rewrap DEK.
• Red-team para detonação/canais laterais não autorizados.
• Revisão da normalização quando novos formatos/regiões.

16) FAQ

Em: Tocenização = Anonimato?
Oh, não. Toquenização - pseudonimização. O origem é restaurável (ou comparável) se as chaves/volts estiverem disponíveis. Para sair da esfera GDPR, é necessária uma anonimato confiável.

Em: Como procurar por email/telefone sem detonação?
A: Tocinização com canonização. Para endereços/FIO - hash index/chaves de busca e tabelas de apoio.

Quando é que o FPE precisa?
O: Quando um contrato/esquema externo requer o formato (comprimento/alfabeto). Nos outros casos, os tokens AEAD convencionais são mais simples e seguros.

Em: É possível ter um token para todos os fins?
O: Melhor áreas diferentes (scope/purpose): O mesmo PII fornece tocens diferentes para diferentes tarefas → reduz o risco de correlação.

Em: Como executar «direito de remoção»?
Ah: Cripto-remoção: Retirando o KEK/DEK para o conjunto apropriado e/ou removendo a gravação no volt + destruindo as chaves do campo/partição; na análise - TTL/Agregamento/Descontrolação.

• «Gestão de segredos»
• Criptografia At Rest
• Criptografia In Transit
• «Privacy by Design (GDPR)»
• «Auditar e Registos Imutáveis»
• Gerenciamento de chaves e rotação