Por dentro do Authrim
Onde ficam os dados pessoais
Este projeto começou com um desconforto comum na operação: investigar uma falha de login e acabar vendo informações pessoais de que você não precisava.
Quando investigar expõe dados pessoais
Quem opera uma plataforma de identidade recebe esse pedido com frequência: “Um usuário não consegue entrar.” Para investigar, você acessa o ambiente do cliente e procura a conta.
Você precisa de poucas informações: a conta está bloqueada? Quando e em que etapa a última tentativa falhou? Qual caminho de login foi usado? A passkey ainda está registrada e válida?
Nada disso exige saber quem é a pessoa. Mas, ao abrir a conta, aparecem nome, e-mail, telefone e contas vinculadas, tudo na mesma tela. Você precisava saber o estado do sistema. Acabou vendo informações sobre alguém.
“Por favor, não olhe” não é uma proteção
quando a informação já está na tela.
Ninguém descumpriu o procedimento. O cliente pediu a investigação, você seguiu as regras e fez o trabalho. Mesmo assim, viu os dados. A estrutura do sistema os colocou na sua frente.
Resolver isso apenas com regras e treinamento faz a proteção depender da memória e da atenção de quem investiga. Com o tempo, isso pode virar um incidente. A separação dos dados pessoais em outro banco começou como uma tentativa de resolver esse problema na própria estrutura do sistema.
Dois bancos desde o início
Os dados que identificam diretamente uma pessoa ficam em um banco fisicamente separado. A separação não foi acrescentada depois: ela já existe na camada de acesso aos dados.
Com essa separação, o problema inicial pode ser resolvido. Bloqueios, tentativas de login e informações de dispositivos ficam à esquerda. É possível liberar o acesso necessário à investigação sem abrir o lado direito. Ninguém precisa se lembrar de desviar o olhar.
A mesma estrutura também responde a perguntas de auditoria. Fica claro onde estão nomes e e-mails e quais dados uma exclusão abrange. Resolver o problema operacional tornou o projeto mais fácil de explicar.
Dados pessoais também existem fora do PII DB
É preciso deixar isso claro: essa separação não é uma fronteira jurídica entre dados pessoais e não pessoais.
O Core DB contém endereços IP, informações de dispositivos, histórico de sessões, eventos de autenticação, metadados de credenciais e IDs internos estáveis. Dependendo do contexto, esses também são dados pessoais. Isolados, talvez não identifiquem alguém; combinados com outras informações, podem identificar.
O Authrim separa dados de identificação direta de dados de identidade necessários à operação. A investigação deve poder usar o segundo grupo sem acessar o primeiro. Isso não dispensa a proteção do segundo grupo.
Por isso, seria incorreto dizer que dados pessoais só existem no PII DB. O correto é: nomes, e-mails e outros dados de identificação direta ficam isolados no PII DB, e o acesso para investigação pode ser concedido sem abrir esse armazenamento.
Excluir é só a primeira parte
Excluir uma conta a pedido do usuário é simples. Difíceis são as duas solicitações que podem vir depois.
A primeira é comprovar a exclusão: quando ocorreu, quem a executou e por quê. A segunda é impedir um novo cadastro durante um período definido, uma regra comum em alguns serviços.
As duas exigem reconhecer uma pessoa cujos dados foram excluídos. Mas guardar informações que a identifiquem diretamente contraria o propósito da exclusão.
O princípio é guardar apenas o resumo necessário para reconhecer um novo cadastro e excluí-lo ao fim do prazo de retenção, registrando também quem excluiu, quando e por quê.
Do que depende a impossibilidade de recuperar o valor
Um detalhe técnico importa: endereços de e-mail têm baixa entropia. Com um hash simples, um ataque de dicionário pode descobrir o endereço original. “Não recuperável” não é uma garantia sem condições.
O Authrim usa um índice cego HMAC-SHA256 com uma chave secreta. O registro inclui o número da geração da chave, permitindo sua rotação. Sem a chave, não é possível testar endereços candidatos recalculando seus resumos.
Isolar a chave é uma condição dessa proteção. Guardá-la junto dos resumos elimina essa garantia. Essa condição também precisa estar clara ao descrever o recurso.
Abrir só o que a investigação precisa
Voltando ao problema de login: é preciso descobrir onde a autenticação parou. Em geral, não é necessário abrir um nome ou telefone.
O Authrim separa as informações de identificação direta para permitir o diagnóstico sem acesso a esse armazenamento. Quando a investigação realmente exige dados pessoais, alguém com as permissões adicionais adequadas cuida dessa parte.
Criptografia e controle de acesso protegem os dados; logs de auditoria registram seu uso. Além disso, quem investiga deve poder concluir o trabalho de rotina sem abrir dados pessoais de que não precisa. A separação do armazenamento torna isso o ponto de partida da operação.
Implementação: separação do armazenamento e limites de acesso implementados.
Validação: coberta por testes automatizados no repositório.
Maturidade operacional: a segurança e a confiabilidade para uso em produção continuam sendo aprimoradas. O Authrim ainda não chegou à versão 1.0.
Esse projeto facilita os processos de exclusão. Por si só, ele não garante conformidade legal, que também depende dos procedimentos e contratos da organização.