Proteger dados foi mais simples do que eu imaginava.

Sobre proteger dados sensíveis, LGPD na prática, e o que acontece com o CPF antes de ele chegar ao banco.

Na faculdade e nos cursos de ciência de dados, a gente aprende cedo que dado sensível não é coisa pra colecionar. A lógica é simples: não colete o que você não precisa, e o que você precisar, proteja. Fácil de entender, fácil de concordar.

Até o dia em que você está construindo um sistema real e percebe que precisa de um dado sensível de verdade. No meu caso foi o CPF das pessoas.

Por que o CPF era inevitável?

O sistema que estou construindo é um diário digital de creche, comunicação diária entre a escola e as famílias de crianças de 0 a 3 anos. Uma das decisões mais importantes do projeto foi como garantir que a pessoa que está acessando os dados de uma criança é realmente quem diz ser?

O fluxo funciona assim: a coordenadora da creche cadastra o responsável pelo sistema e gera um link de convite, que ela envia via WhatsApp. O responsável clica no link e cria sua senha. Simples até aí.

O problema é que esse link pode, em teoria, chegar em mãos erradas. Uma mensagem encaminhada, um celular desbloqueado na mesa. Quando estamos falando de dados diários de bebês, rotina, humor, ocorrências, fotos, qualquer acesso indevido é sério. Precisávamos de uma camada de verificação de identidade e o CPF fazia sentido: a escola já tem esse dado na matrícula, o responsável já forneceu uma vez, e é uma informação que não muda. A fricção de digitar o CPF uma única vez, no momento de ativar o acesso, é completamente justificável. Estamos falando de acompanhar a rotina de um bebê.

Eu sabia que CPF é dado sensível. Sabia que circula fácil demais, basta uma promoção, sorteio, um, cadastro qualquer, e justamente por isso precisa de cuidado especial quando entra num sistema que você constrói. Sabia da LGPD, sabia da ética de dados, sabia do princípio.

O que eu não sabia era o como. Guardar o CPF em texto puro no banco estava fora de questão. Se o banco vazar, os CPFs de todas as famílias vazam junto. Mas como verificar a identidade de alguém sem guardar o dado que você está usando pra verificar?

Hash: o CPF entrou no meu sistema uma vez, cumpriu sua função e nunca mais apareceu

Imagina pegar o número do CPF, passar por uma fórmula que só tem ida, e guardasse o resultado. A fórmula é pública, qualquer um pode saber como ela funciona, mas sem o CPF original, é apenas uma sequencia de caracteres. E não dá para voltar para trás, fazer o inverso e chegar no CPF.

Na hora de verificar a identidade, você pede o CPF pra pessoa, passa pela mesma fórmula, e compara os dois resultados. Se baterem, é a mesma pessoa. Se não baterem, acesso negado. O que fica no banco é só uma espécie de impressão digital daquele dado, que é única, mas que a utilidade é comparar com as de um determinado dedo e dizer se aquela pessoa é ou não é a dona da impressão. Mas ela sozinha não diz nada.

Esse processo tem nome: bcrypt. É uma função de hash criptográfico, amplamente usada exatamente para esse tipo de situação como senhas, documentos, qualquer dado que precisa ser verificado sem ser armazenado.

Hash não é o único caminho quando você precisa proteger um dado sensível. Existe também a criptografia, que ao contrário do hash, é reversível. Você cifra o dado com uma chave e pode decifrá-lo depois com a mesma chave. Faz sentido quando você precisa recuperar o dado original em algum momento: um CPF que precisa aparecer numa nota fiscal, por exemplo, ou um endereço que o sistema precisa usar pra calcular uma entrega. Existe ainda a tokenização, muito comum em pagamentos, onde o dado sensível é substituído por um token sem valor próprio e a correspondência real fica guardada em outro sistema isolado.

A diferença está no que o sistema precisa fazer com o dado. Se precisa ler, criptografia ou tokenização. Se só precisa comparar, hash. No projeto, nunca precisaríamos ver o CPF de volta. Só precisávamos confirmar se o que foi digitado no momento do acesso era o mesmo que foi cadastrado pela escola. Hash pareceu a melhor escolha. E dentro dos algoritmos de hash disponíveis, bcrypt é super bem estabelecido, maduro, amplamente testado, com suporte em praticamente qualquer ambiente.

Quem faz, como e onde

Essa parte é onde a maioria dos textos sobre hash me deixava meio voando. Tudo bem, mas onde no código isso acontece?

A resposta tem consequência: no servidor. Sempre no servidor. Nunca no browser.

Se o hash fosse feito no front-end, no navegador antes de enviar, o CPF ainda teria passeado pela rede de cara limpa, sem nenhum disfarce. O ponto vulnerável é exatamente esse trânsito. O CPF precisa sumir antes de qualquer transmissão, e o lugar seguro pra isso é o servidor.

No projeto, isso acontece numa Server Action, que é uma função do Next.js que roda exclusivamente no servidor e nunca é exposta ao cliente. A escola preenche o CPF no formulário de cadastro, o dado vai pro servidor, o bcrypt faz o hash, e o que chega ao banco é só o resultado. O CPF original some no processo.

O fluxo completo ficou assim:

A creche cadastra o responsável com nome, telefone e CPF. O sistema faz o hash do CPF e salva apenas esse resultado na tabela. Gera um token de convite com validade de 72 horas. A coordenadora envia o link via WhatsApp. O responsável clica no link, digita o CPF e cria uma senha. O sistema pega o CPF digitado, passa pelo mesmo processo de hash, e compara com o que está salvo. Se bater, o acesso é criado. Se não bater, bloqueia e orienta a pessoa a procurar a escola.

O CPF real nunca existiu no banco.

Porque o CPF? Por que não o e-mail?

Você deve ter notado que o fluxo de onboarding desse sistema tem algumas particularidades, link de convite, token com prazo, verificação por CPF em vez de email. Isso tem uma razão: boa parte dos responsáveis e sua rede de apoio não usam email no dia a dia. A vó ou a tia que só tem WhatsApp, por exemplo. Esse é um problema à parte, com decisões próprias e alguma gambiarra criativa. Vou falar sobre isso no próximo artigo.

Esse artigo faz parte de uma série sobre o processo de construir um sistema de comunicação de creche do zero : as decisões de produto, segurança, banco de dados e desenvolvimento, documentadas ao longo do caminho. Caso você queira conferir a pagina mencionada aqui do projeto, ele está em

https://github.com/eridecarv/agenda-zero-creche/blob/main/src/app/actions/registerGuardian.ts

https://github.com/eridecarv/agenda-zero-reche/blob/main/src/app/actions/verifyCpf.ts