OneNymIDs substitutos e tokens
Referencie pedidos e membros.
Reduza o armazenamento direto de dados pessoais.
ONENYM PLATFORM / PROJETO TÉCNICO
Execute a ação necessária,
sem compartilhar dados pessoais.
Em vez de duplicar dados pessoais entre empresas,
execute ações autorizadas com acesso limitado.
O OneNym Platform combina IDs substitutos, tokens, autorização e um cofre separado. Seu projeto separa dados pessoais dos sistemas de negócio e limita seu uso às finalidades necessárias.
01 / ARQUITETURA
Separe identidade, permissões e dados.
Sistemas de negócio processam IDs substitutos e tokens. Consultas e processamento passam por autorização independente. Mantenha dados pessoais em um cofre separado e reduza cópias entre sistemas.
Solicitar uma ação
↓
↓
Apenas ações permitidas
Verifique solicitante, finalidade, registro e validade.
Rejeite solicitações fora da autorização.
Limitar às informações necessárias
↓
↓
Cofre de dados
Gerencie dados pessoais e mapeamentos.
Retorne resultados ou campos limitados.
Diagrama conceitual. Os mapeamentos entre IDs substitutos e dados pessoais também precisam ser protegidos como informações sensíveis.
02 / QUATRO COMPONENTES
Reduza a exposição pelo projeto.
01 / PROXY IDENTITY
ID substituto
Referencie pessoas por identificadores específicos de cada serviço, em vez de dados pessoais. IDs separados entre serviços reduzem as possibilidades de correlação e rastreamento.
Considerações: isolamento de tenants e serviços, IDs imprevisíveis, rotação, exclusão e acesso restrito aos mapeamentos.
02 / TOKENIZATION
Tokenização
Use tokens de referência limitados por finalidade em vez de endereços ou e-mails. Gerencie ações permitidas, validade e limites de uso.
Considerações: abuso de tokens roubados, limites de reutilização, revogação e quem pode resolver um token. Um simples hash não torna os dados anônimos.
03 / PERMISSIONS
Permissões de acesso
Verifique condições por operação, como permitir que a empresa A use o endereço deste pedido uma vez para entrega. Além do login, confirme quem pode tratar quais dados e para qual finalidade.
Considerações: isolamento de tenants, finalidade, escopo, validade, revogação, administração e trilhas de auditoria. Permissão técnica é diferente de consentimento ou fundamento contratual.
04 / DATA VAULT
Cofre de dados
Separe dados pessoais dos registros de negócio e disponibilize-os apenas por caminhos restritos. Projete criptografia, gestão de chaves, administração, backups e exclusão em conjunto. Use serviços como Azure Key Vault ou AWS KMS conforme o ambiente.
Considerações: separação de chaves e dados, fronteiras entre tenants, recuperação, disponibilidade, auditoria e retenção. Um cofre centralizado pode se tornar um alvo valioso.
03 / EXEMPLO DE INTEGRAÇÃO
Solicite a entrega sem armazenar o endereço.
Exemplo de projeto para um varejista e um provedor de entrega. Integração, custódia de dados e fundamentos de uso exigem projeto e acordo específicos.
Cadastrar os dados necessários no cofre
Cadastre um endereço de entrega e retorne ao varejista um ID substituto associado ao pedido. Projete a entrada para evitar seus servidores e logs.
Emitir um token limitado por finalidade
Limite o token ao pedido, à transportadora e à validade. O varejista transmite o token em vez do endereço.
Autorizar o provedor de entrega
Autentique o provedor e valide o escopo do token. Retorne apenas os dados de entrega permitidos.
Aplicar expiração e revogação
Interrompa acessos futuros quando a autorização expirar ou for revogada. A exclusão de endereços já consultados depende das operações e dos acordos com o provedor.
Exemplo de registros mantidos pelo varejista
ID do pedido, ID substituto, token de entrega e status da entrega.
Exemplo de dados com menor retenção diretaNome, CEP e endereço. Defina separadamente o que faturamento e atendimento precisam manter.
TECHNICAL DEEP DIVE
Conheça projetos em nível de implementação.
Leia exemplos concretos de mapeamentos, autorização, chaves de criptografia e exclusão.
PROXY IDENTITY
IDs substitutos e isolamento de tenants
Separe identificadores dos dados pessoais e estabeleça fronteiras por tenant e serviço.
Leia o projeto técnicoTOKENIZATIONTokens por finalidade e revogação
Transmita referências em vez de dados, limitando registros, destinatários, finalidades e validade. Separe a posse do token da permissão de consultar dados.
Leia o projeto técnicoPERMISSIONSAutorização e integração de API
A autenticação identifica o solicitante. A autorização determina as ações permitidas. Verifique registro e finalidade por operação.
Leia o projeto técnicoDATA VAULTCriptografia, gestão de chaves e armazenamento
Armazene dados pessoais separadamente e restrinja os caminhos de descriptografia. Projete armazenamento, uso, exclusão e recuperação como um único ciclo de vida.
Leia o projeto técnico04 / LIMITES E CONSIDERAÇÕES
Reduzir a retenção é apenas parte da solução.
IDs substitutos também precisam de proteção
IDs e tokens que identificam ou se vinculam a uma pessoa não são automaticamente anônimos. Gerencie armazenamento e acesso de forma adequada.
Dados consultados podem permanecer
Revogar o acesso não apaga cópias ou logs já criados. Parceiros precisam de políticas de retenção e exclusão.
Disponibilidade e responsabilidades
Acorde impacto de falhas, recuperação, responsabilidades, localização dos dados e retenção durante a implantação.
Decisões de projeto antes da implementação
Defina autenticação, autorização, chaves, auditoria, retenção, exclusão, comportamento em falhas e migração. APIs e escopo de integração dependem do sistema e do processo.
FROM EXPOSURE TO ARCHITECTURE
Comece entendendo seu fluxo de dados.
Um Exposure Test pode avaliar os caminhos atuais até os dados pessoais.
Entre em contato para discutir como reduzir a retenção de dados.