Toda PME que trata dado de cliente chega, mais cedo ou mais tarde, à mesma pergunta desconfortável: “e se vazar?”. Ela costuma aparecer depois de uma notícia de incidente, de uma cláusula de contrato ou de uma pergunta do jurídico que ninguém sabe responder. E quase sempre a conversa trava no mesmo ponto — a LGPD vira um documento de advogado, cheio de “titular”, “controlador” e “tratamento”, que não diz uma linha sobre o que o time de engenharia precisa construir.
Este texto faz a tradução que falta. Vou pegar os princípios da Lei 13.709/2018 e transformá-los em decisões concretas de arquitetura para um time pequeno: onde criptografar, como segregar acesso, o que fazer com dados de produção no ambiente de dev, quanto tempo guardar cada coisa e quais logs manter. Sem juridiquês, sem prometer uma sala-cofre que você não vai construir. O objetivo é um desenho de referência que cabe de verdade num time de três ou quatro pessoas.
Arquitetura segura para dados sensíveis é o conjunto de decisões técnicas — criptografia, controle de acesso, minimização, mascaramento e auditoria — que reduz a chance de um vazamento e limita o estrago quando ele acontece.
O que a LGPD realmente pede de engenharia
O Art. 46 da LGPD exige que quem trata dado adote “medidas de segurança, técnicas e administrativas” capazes de proteger o dado contra acesso não autorizado e situações de destruição, perda ou vazamento. A lei não lista tecnologias — de propósito. Ela descreve o resultado esperado e deixa o “como” para você. O texto oficial está no portal do Planalto, e vale ler os artigos que viram requisito em vez de depender de resumos.
Para engenharia, isso é bom e ruim. Bom porque você não precisa de um produto certificado específico — precisa de controles razoáveis para o risco. Ruim porque “razoável” é subjetivo até você traduzir em decisões. E a primeira decisão é saber o que você está protegendo. A conexão entre o texto legal e o código é o mesmo desafio que abordo em LGPD e GDPR no software — aqui o foco é só a arquitetura de dados.
Dado comum, dado pessoal e dado sensível
Nem todo dado merece o mesmo nível de proteção, e tratar tudo igual é caro e ineficaz. A LGPD separa em camadas:
- Dado pessoal comum: nome, e-mail, telefone. Identifica alguém, mas é de baixo risco isolado.
- Dado sensível (Art. 5º, II): saúde, biometria, dado genético, origem racial, convicção religiosa, opinião política, vida sexual. Vazamento aqui é grave e pode discriminar.
- Dado que não é seu problema: o que você coleta sem precisar. Esse é o mais fácil de proteger — porque a proteção é não coletar.
O erro clássico de PME é proteger tudo com o mesmo cadeado fraco. O caminho certo é classificar e concentrar o esforço onde o risco mora.
O diagrama de referência que cabe num time pequeno
Antes dos controles, o desenho. Uma arquitetura segura para uma PME não precisa de dez zonas de rede e um SOC. Precisa de camadas claras, cada uma com uma responsabilidade:
- Borda: TLS obrigatório, WAF na frente, rate limiting. Nada trafega em texto claro.
- Aplicação: valida entrada, aplica regra de negócio, nunca confia no cliente. É aqui que o controle de acesso por perfil vive.
- Dados: banco com criptografia em repouso, credenciais rotacionadas, acesso só pela aplicação — nunca direto do laptop de alguém.
- Segredos: um cofre (Vault, AWS Secrets Manager, KMS) fora do código e fora do
.envversionado. - Observabilidade: logs de auditoria centralizados, com retenção definida e acesso restrito.
O ponto não é a marca de cada peça. É que cada dado sensível atravesse todas as camadas e que nenhuma pessoa tenha uma linha reta do laptop até a tabela de saúde do cliente. Subir isso sem esse desenho é um dos riscos de publicar apps em produção que mais custam caro depois.
Criptografia em repouso e em trânsito
Criptografia em trânsito (TLS) é inegociável e hoje é quase gratuita — não há desculpa para tráfego em texto claro. A parte que PME esquece é a criptografia em repouso: o dado gravado no disco, no backup, na réplica.
A regra prática é em camadas:
- Disco/volume criptografado: protege contra roubo físico ou snapshot vazado. É o piso, e a maioria dos provedores de nuvem entrega com um clique.
- Criptografia em nível de coluna: para os campos sensíveis de verdade (CPF, dado de saúde, token). Mesmo quem consegue ler o banco não lê a coluna sem a chave.
- Gestão de chaves separada: a chave não pode morar ao lado do dado que ela protege. Um KMS resolve isso sem você escrever criptografia à mão — e escrever cripto à mão é quase sempre um erro.
Cuidado com o falso conforto: criptografar o disco não protege contra uma credencial de aplicação vazada, porque a aplicação descriptografa para funcionar. Por isso cripto sozinha não basta — ela é uma camada num conjunto.
Segregação de acesso e IAM sem burocracia
Aqui mora o controle que mais previne incidente por real gasto: ninguém acessa o que não precisa para trabalhar. É o princípio do menor privilégio, e ele vale para humanos e para serviços.
Na prática, para um time pequeno:
- Perfis, não exceções. Defina papéis (suporte, financeiro, engenharia, admin) e amarre permissão ao papel. Permissão individual “só para essa pessoa” é dívida que ninguém revoga.
- Acesso a produção é evento, não rotina. Desenvolvedor não vive logado no banco de produção. Acesso temporário, com justificativa e log, quando precisar.
- Serviço tem identidade própria. Cada serviço usa sua credencial, com o escopo mínimo. Se um vazar, o estrago é contido àquele escopo.
- Revisão periódica. A cada trimestre, alguém olha “quem tem acesso admin?” e corta o que sobrou. Acesso concedido e esquecido é a porta preferida de quem ataca.
| Papel | Acesso a dado sensível | Acesso a produção | Precisa de admin? |
|---|---|---|---|
| Suporte | Só o do ticket, mascarado | Não | Não |
| Financeiro | Só faturamento | Não | Não |
| Engenharia | Temporário, com log | Sob demanda | Não por padrão |
| Admin/infra | Sim, auditado | Sim, auditado | Sim |
A tabela é chata de manter — e é exatamente por isso que ela protege. Acesso amplo por conveniência é a decisão que você lamenta às três da manhã.
Mascaramento em dev e staging
Esta é a falha silenciosa mais comum e mais subestimada: copiar o banco de produção para o ambiente de desenvolvimento. Funciona lindamente para reproduzir um bug — e coloca o CPF, o e-mail e o dado de saúde de clientes reais no laptop de todo mundo, num ambiente sem os controles de produção.
O caminho seguro tem duas opções:
- Mascaramento (data masking): você copia a estrutura e transforma os valores sensíveis. O e-mail vira
user1234@exemplo.com, o CPF vira um número válido no formato mas falso, a data de nascimento é embaralhada. O desenvolvedor tem dado realista sem dado real. - Dados sintéticos: você gera do zero um conjunto que parece produção mas nunca foi ninguém. Mais trabalho, proteção máxima.
O que o desenvolvedor precisa é do formato e do volume certos para testar — nunca da identidade verdadeira de um cliente. Essa disciplina se paga na primeira vez que um laptop é perdido ou um repositório de dump vaza. Vale embutir esse cuidado desde o MVP do zero à produção, porque migrar depois é retrabalho puro.
Minimização e retenção: o dado que você não guarda não vaza
O controle de segurança mais barato do mundo é não ter o dado. A LGPD chama isso de minimização e finalidade: você só coleta o que precisa, pelo tempo que precisa, para o que declarou.
Traduzido em engenharia:
- Colete menos. Aquele campo “por via das dúvidas” no formulário é passivo, não ativo. Se não tem uso definido, não pede.
- Defina retenção por tipo de dado. Log de acesso, dado de conta, dado de saúde — cada um com um prazo. Sem prazo, o banco só cresce e o risco só sobe.
- Automatize o expurgo. Retenção que depende de alguém lembrar de rodar um script não existe. Vira rotina agendada, com log do que foi apagado.
- Anonimize quando deletar quebra. Quando você precisa da estatística mas não do indivíduo, anonimização irreversível costuma ser a saída — e dado anonimizado sai do escopo da lei.
Logs de auditoria: ver sem virar passivo
Quando algo dá errado, a primeira pergunta é “quem acessou o quê e quando?”. Sem log de auditoria, a resposta é arqueologia — e a LGPD espera que você consiga responder. Mas log é uma faca de dois gumes: ele próprio costuma conter dado pessoal (IP, ID de usuário, ação).
O equilíbrio para PME:
- Registre o acesso a dado sensível: quem, quando, qual registro, qual ação. Não o conteúdo do dado — o acesso a ele.
- Centralize e proteja. Log espalhado em cada máquina não serve para investigação e é difícil de proteger. Um destino central, com acesso restrito.
- Dê retenção ao log também. Log não é eterno. Ele tem prazo, como qualquer dado, e some depois.
- Nunca logue segredo. Senha, token e o próprio dado sensível não entram no log. É o vazamento que você mesmo cria sem perceber.
Observabilidade e privacidade puxam em direções opostas, e o ajuste fino aparece também quando você mede custo de IA em produção — logar prompt e resposta pode significar logar dado pessoal sem querer.
Checklist de arquitetura segura para PME
Se você quer sair deste texto com uma lista acionável, é esta — em ordem de retorno sobre esforço:
- Classifiquei meus dados em comum, sensível e desnecessário
- TLS obrigatório em todo tráfego, sem exceção
- Criptografia em repouso no banco e nos backups
- Campos sensíveis com criptografia em nível de coluna
- Chaves em um cofre, separadas do dado
- Acesso por perfil, com menor privilégio
- Acesso a produção é temporário e logado
- Dev e staging usam dados mascarados ou sintéticos
- Política de retenção por tipo de dado, com expurgo automático
- Logs de auditoria centralizados, com retenção e sem segredos
- Revisão trimestral de quem tem acesso admin
Nenhum item pede um time grande. Todos pedem disciplina e a decisão de tratar segurança como requisito, não como remendo. Se você quer um par técnico para desenhar e operar essa base sem transformar em projeto de um ano, é exatamente o tipo de trabalho que fazemos em engenharia e DevOps.
A verdade honesta é que segurança de dados raramente falha por falta de tecnologia de ponta. Falha por acesso amplo demais concedido por conveniência, por dado de produção no laptop errado e por retenção que ninguém definiu. Acerte o básico com intenção e você já está à frente da maioria — e muito mais longe do incidente das três da manhã.
Perguntas frequentes
Preciso de um time enorme para ter arquitetura segura?
Não. A maioria dos controles que a LGPD espera — criptografia em repouso, segregação de acesso por perfil, mascaramento em dev e logs de auditoria — são configuração e disciplina, não headcount. Um time de três ou quatro pessoas implementa o essencial se tratar segurança como requisito desde o início, e não como retrabalho depois do incidente.
Criptografia em repouso já me deixa em conformidade?
Não sozinha. Criptografar o banco protege o dado contra quem rouba o disco, mas não contra credencial vazada, query maliciosa ou desenvolvedor com acesso amplo demais. Cripto é uma camada. Conformidade exige também base legal, minimização, retenção definida e trilha de auditoria — o conjunto, não uma peça isolada.
O que é dado sensível na LGPD, na prática de engenharia?
O Art. 5º, II da Lei 13.709/2018 define dado sensível como origem racial ou étnica, convicção religiosa, opinião política, dado de saúde, vida sexual, dado genético ou biométrico. Na engenharia, isso significa colunas e tabelas que merecem criptografia mais forte, acesso mais restrito e retenção mais curta do que um e-mail comum.
Posso usar dados de produção no ambiente de desenvolvimento?
Não com os dados reais expostos. Copiar o banco de produção para o dev é a fonte mais comum de vazamento silencioso. O caminho seguro é mascarar ou gerar dados sintéticos: o desenvolvedor precisa de dados com o formato certo, não do CPF verdadeiro de um cliente real.
Quanto tempo devo guardar os dados?
Só enquanto houver finalidade e base legal. A LGPD trabalha com minimização: dado que não serve mais precisa ser deletado ou anonimizado. Na prática, isso vira uma política de retenção por tipo de dado, com rotina automática de expurgo — não um banco que só cresce para sempre.
Logs de acesso também são dado pessoal?
Frequentemente sim. IP, ID de usuário e ação registrada podem identificar uma pessoa. Logs são essenciais para auditoria e resposta a incidente, mas precisam de retenção definida e acesso controlado como qualquer outro dado — senão viram um passivo de privacidade escondido dentro da sua observabilidade.