Privacidade é poder: seu sistema está com a embalagem aberta?

Dois pirulitos, aparentemente iguais. Um está embalado. O outro está descoberto, com moscas sobre a superfície. A diferença salta aos olhos: existe uma barreira entre aquilo que tem valor e o ambiente ao redor.

A frase que acompanha essa ideia é direta: privacidade é poder.

Quando trago a imagem para o desenvolvimento de sistemas, penso em formulários, currículos, fotos, cadastros, credenciais e informações de clientes. Tudo aquilo que alguém entrega a uma aplicação porque precisa resolver alguma coisa.

O problema é que, no software, a embalagem não aparece no print.

Um painel bonito pode esconder permissões mal definidas. Uma tela de login pode existir sem proteger adequadamente os dados. Um botão escrito “excluir” pode apagar uma linha e deixar cópias espalhadas. Por isso, privacidade precisa participar do projeto desde o começo.

O poder de colocar limites

Pense no seu endereço. Você pode informá-lo para receber uma encomenda sem desejar que ele fique disponível para qualquer visitante de um site. Pode entregar um currículo a uma empresa sem querer que seu histórico profissional vire uma base para finalidades que você desconhece.

O contexto muda o significado do compartilhamento.

Para mim, falar em privacidade é discutir esses limites: quais informações são necessárias, para qual finalidade, quem pode utilizá-las e por quanto tempo. A pessoa precisa entender o que acontece com seus dados; quem constrói o serviço precisa conseguir explicar e sustentar essas escolhas.

A LGPD, em seu artigo 6º, trata de princípios como finalidade, necessidade, transparência e segurança. O artigo 46 também exige medidas de proteção desde a concepção do produto ou serviço.

Isso tem consequência prática: dá para proteger muito bem um banco de dados e, ainda assim, coletar informação demais. Segurança e privacidade precisam caminhar juntas.

A tela era bonita. A senha era “admin123”

Em trabalhos de apoio a projetos, já encontrei uma situação cuja lógica podia ser resumida assim:

se senha == "admin123", então é administrador

Era isso que definia o acesso administrativo.

Esse tipo de descoberta explica por que insisto tanto em olhar além da interface. A aplicação pode parecer pronta enquanto uma decisão essencial está sustentada por uma credencial fixa no código.

O MITRE CWE-798 descreve justamente o uso de credenciais embutidas no software. Ter um nome técnico para a falha ajuda a reconhecê-la e a discutir sua correção com precisão.

E trocar aquela senha por uma frase gigantesca não resolve, sozinho, o desenho do controle de acesso. É preciso identificar usuários, proteger a autenticação e estabelecer quais operações cada identidade pode executar.

Já comparei esse cenário a trocar o escudo do Capitão América por uma pipa de papel de seda: linda, caprichada, mas inadequada para a função.

Isso vale para software produzido com ou sem inteligência artificial. A responsabilidade de verificar o resultado continua existindo.

Quem está aprendendo precisa de orientação para enxergar essas camadas. Quando o projeto começa a receber dados de outras pessoas, a revisão dessas escolhas passa a fazer parte da entrega.

O currículo que não precisa virar um banco de dados

Uma decisão que discuti recentemente para o Pinheiral Digital foi a proposta de um gerador público de currículos: a pessoa preenche, cria o documento e baixa no próprio dispositivo, sem precisar de login e sem a intenção de armazenar seu currículo no serviço.

O objetivo do projeto é ajudar alguém a produzir um arquivo útil.

A partir daí, cabe perguntar se manter uma coleção de currículos no servidor acrescentaria algo necessário àquela entrega. Cada informação guardada traz novas tarefas: controlar acesso, definir retenção, atender solicitações e administrar cópias.

A OWASP, no guia de armazenamento criptográfico, recomenda evitar o armazenamento de informações sensíveis quando isso for possível. É uma orientação que combina muito com esse desenho.

Em alguns projetos, uma boa medida de proteção é deixar de criar um acervo desnecessário.

Há uma diferença, porém, entre a intenção de “não armazenar” e a implementação dessa promessa. Se os campos passam pelo servidor, entram em registros de erro ou são capturados por uma ferramenta de análise de uso, a informação já percorreu outros caminhos.

Por isso, uma arquitetura que gere o arquivo no navegador precisa também verificar scripts de terceiros, telemetria e requisições de rede. O preenchimento local só cumpre a proposta se o restante da aplicação respeitar essa decisão.

Esse exemplo continua sendo uma escolha de projeto que venho discutindo. Ele mostra como privacidade pode orientar a arquitetura antes mesmo da primeira tabela.

Guardar para sempre também é uma decisão

Em outra discussão de projeto, envolvendo fotografias numa rotina de recepção, trabalhávamos inicialmente com uma proposta de retenção de 90 dias. A orientação recebida na consultoria com o Sebrae foi reduzir esse prazo para 60 dias.

O aprendizado foi revisar a necessidade da guarda e colocar um limite concreto nela.

Aquele prazo fazia parte daquele contexto. Sessenta dias não são uma regra geral da LGPD: a definição depende da finalidade, das obrigações aplicáveis e da justificativa para conservar a informação.

Também é preciso transformar a decisão em comportamento do sistema. Uma política pode prometer descarte, mas o processo precisa alcançar as cópias pertinentes e estabelecer como lidar com backups, exportações e eventuais deveres de conservação.

A orientação da OWASP sobre logs inclui cuidados com retenção e descarte, além de alertar contra o registro direto de senhas, tokens e informações pessoais sensíveis.

É fácil cuidar do cadastro principal e esquecer o arquivo de depuração. A privacidade também mora nesses lugares pouco fotogênicos.

A “embalagem” precisa funcionar nas requisições

No trabalho com a Oombe e integrações de marketplaces, o contexto de cada conta faz parte do problema que precisamos resolver. Uma ação envolve um vendedor, uma conta conectada, determinados dados e permissões.

Imagine, como exemplo, duas empresas usando o mesmo serviço. O usuário de uma delas não deve conseguir consultar o pedido da outra apenas porque está autenticado.

É aqui que a distinção fica importante: autenticação identifica quem entrou; autorização determina o que essa pessoa pode fazer.

A OWASP recomenda conceder o menor privilégio necessário, negar acesso por padrão e verificar permissões em cada requisição. As decisões precisam acontecer em uma camada confiável do sistema.

Esconder um botão no navegador ajuda a organizar a experiência. A proteção real exige impedir também a operação correspondente quando a requisição chega à aplicação.

O mesmo raciocínio vale para documentos, imagens e relatórios. Se o arquivo é privado, o caminho usado para baixá-lo precisa respeitar essa condição.

Em serviços com várias contas, testar essa separação deve fazer parte da entrega. Um teste autorizado com duas contas de demonstração ajuda a verificar se os limites definidos realmente existem.

Senhas, segredos e o arquivo que ficou exposto

Outro exemplo que já discuti envolve credenciais escritas diretamente no código e arquivos .env disponibilizados pela web.

Um .env pode participar da configuração de uma aplicação. A proteção depende de como ele é armazenado, de quem consegue lê-lo e do que o servidor publica.

A OWASP orienta a gestão de segredos com acesso restrito e cuidado durante todo o ciclo de vida das credenciais. Se uma chave foi exposta, retirar o arquivo do ar precisa vir acompanhado da revogação ou substituição do segredo comprometido. Cópias já obtidas não desaparecem por educação.

Senhas de usuários pedem outro cuidado. Para verificá-las na autenticação, a OWASP recomenda funções próprias de hashing, como Argon2id, com salt. Guardar a senha em texto puro ou apenas aplicar uma criptografia reversível não oferece a proteção recomendada para esse uso.

São problemas relacionados, mas diferentes: uma credencial de integração precisa ser gerenciada como segredo; uma senha de login precisa de armazenamento adequado para verificação.

Uma interface bonita não consegue compensar nenhuma dessas escolhas.

OWASP e MITRE ajudam a fazer perguntas melhores

Gosto dessas referências porque elas permitem sair do “acho que está seguro” e discutir critérios verificáveis.

O OWASP Top 10:2025 apresenta riscos relevantes de aplicações web. Para aprofundar a verificação, o OWASP ASVS reúne requisitos de segurança que podem orientar desenvolvimento, revisão e contratação.

No universo MITRE, vale separar duas referências:

Referência	Para que ajuda
CWE	Descrever tipos de fraqueza de software e hardware.
ATT&CK	Entender táticas e técnicas de adversários a partir de comportamentos observados.

Além das credenciais hardcoded, o CWE-862 trata da ausência de autorização. O CWE-359 descreve a exposição de informações pessoais privadas a quem não deveria recebê-las.

Já o ATT&CK ajuda a pensar no comportamento de um invasor e na relação entre diferentes etapas de um ataque.

Essas referências apoiam o trabalho técnico. A evidência de que um produto está protegido precisa aparecer no seu projeto, na implementação, nos testes e na operação.

Para quem contrata, isso também muda a conversa: vale pedir demonstrações dos controles de acesso, da proteção dos dados e do descarte previsto. A resposta precisa ir além de “tem login”.

E quando a inteligência artificial entra no caminho?

A IA pode ajudar a revisar um formulário, explicar uma regra de autorização ou sugerir cenários de teste. Na minha avaliação, seu uso também exige atenção ao material que entregamos a ela.

Antes de colar uma planilha, um currículo ou um registro de atendimento numa ferramenta, convém verificar quais dados são necessários para a tarefa e quais condições se aplicam àquele serviço.

Muitas vezes, um exemplo fictício preserva a estrutura do problema. Para revisar uma função que formata CPF, por exemplo, precisamos entender o formato e as regras; uma lista de documentos reais de cidadãos acrescenta uma exposição evitável.

No desenvolvimento, podemos pedir à IA que explique onde uma permissão é validada, quais campos chegam aos logs e como a exclusão percorre a aplicação. Essas respostas ajudam a direcionar a revisão, mas precisam ser conferidas.

Eu gosto da velocidade que essas ferramentas oferecem. Quero que ela venha acompanhada da capacidade de entender o que estamos colocando em funcionamento.

A pessoa que usa o serviço vai confiar seus dados ao resultado dessa combinação.

Seis perguntas antes de colocar o sistema no ar

Para transformar essa conversa em trabalho concreto, eu começaria por estas perguntas:

1. Precisamos de cada dado solicitado? Cada campo deve ter uma finalidade compreensível e uma necessidade justificável.
2. Quem consegue acessar cada informação? Vale verificar permissões por usuário, função, conta e recurso.
3. Por onde os dados passam? Inclua APIs, ferramentas de análise, serviços de IA, logs e exportações.
4. Até quando precisamos guardar? Defina retenção, descarte e as exceções justificadas pela operação ou por obrigações aplicáveis.
5. O que comprova que os controles funcionam? Revise configuração, código e testes autorizados, incluindo tentativas de acesso entre contas de demonstração.
6. Quem responde quando algo foge do esperado? Defina responsáveis e um processo para investigar problemas, conter exposição e atender as pessoas afetadas.

Essas perguntas servem para um pequeno formulário e podem ganhar profundidade conforme a complexidade do serviço. O cuidado precisa acompanhar os dados e os riscos envolvidos.

Volto, então, aos pirulitos.

A embalagem deixa uma diferença visível. Nos sistemas, precisamos construir essa diferença com escolhas que nem sempre aparecem na apresentação comercial: menos coleta, acesso limitado, credenciais protegidas e prazos de guarda que sejam cumpridos.

Privacidade é poder porque estabelece limites sobre o uso da informação a nosso respeito.

Para quem desenvolve, isso significa reconhecer a responsabilidade que chega junto de cada cadastro. A pessoa veio resolver um problema. Cabe a nós entregar uma solução que mereça a confiança dela.