Compliance e LGPD para infraestrutura

A LGPD (Lei 13.709/2018) não é um documento jurídico distante da infraestrutura: metade das obrigações dela vira decisão técnica — onde o dado mora, quem consegue ler, por quanto tempo fica e como se prova o que aconteceu. Esta página cobre a parte que é do time de engenharia. As decisões de base legal, contrato e comunicação com a ANPD são do jurídico e do encarregado; alinhe com eles antes de mudar arquitetura.

O que a lei pede da sua stack

Traduzindo os artigos que mais afetam o dia a dia:

Obrigação	O que significa em infraestrutura
Segurança e prevenção (art. 46)	Criptografia em trânsito e repouso, acesso mínimo, hardening
Necessidade e minimização (art. 6)	Não colete nem replique o que você não usa
Eliminação (art. 15 e 16)	Conseguir apagar de verdade — inclusive de backup e réplica
Direitos do titular (art. 18)	Localizar, exportar e corrigir dados de uma pessoa em prazo razoável
Relatório e rastreabilidade	Registro de tratamento e trilha de auditoria confiável
Incidente (art. 48)	Detectar, avaliar e comunicar em prazo razoável, com evidência

Nenhuma delas se resolve com uma ferramenta. Todas se resolvem com decisões repetidas de arquitetura.

Mapeie o dado pessoal antes de proteger

Você não protege o que não sabe que tem. O mapa mínimo, mantido em código junto do serviço:

# dados.yaml — versionado no repositório do serviço, revisado no PR
servico: pedidos
dados_pessoais:
  - campo: cliente.email
    classificacao: pessoal
    finalidade: notificacao_de_pedido
    retencao_dias: 1825          # 5 anos, exigência fiscal
    destinos: [postgres-prod, datalake, gateway-email]
  - campo: cliente.cpf
    classificacao: pessoal
    finalidade: emissao_fiscal
    retencao_dias: 1825
    mascarar_em: [logs, ambiente_de_homologacao]

Dado pessoal vaza pelas cópias, não pela origem: réplica de leitura, data lake, backup, dump para homologação, planilha exportada por alguém. Toda cópia herda as mesmas obrigações — e é por isso que “só” copiar produção para homologação é uma decisão de compliance, não de conveniência.

Ambiente de homologação com dado real

É a violação mais comum e a mais fácil de corrigir: anonimize ou gere dado sintético na restauração. Se o time precisa de volume realista, mascare de forma irreversível na própria pipeline de cópia — e restrinja quem pode executá-la.

Logs contêm dado pessoal

Log é o lugar onde dado pessoal aparece sem ninguém decidir: corpo de requisição, header, mensagem de erro com o registro inteiro, URL com identificador. Redija na origem — filtro no logger da aplicação — e mantenha uma segunda camada no Collector, porque a primeira vai falhar em algum serviço.

# OpenTelemetry Collector: rede antes de exportar
processors:
  attributes/lgpd:
    actions:
      - { key: http.request.header.authorization, action: delete }
      - { key: usuario.cpf, action: delete }
      - { key: usuario.email, action: hash }

Vale a mesma regra para atributo de span e para label de métrica. E lembre: log com dado pessoal herda prazo de retenção e regra de acesso do dado que ele contém.

Retenção e eliminação de verdade

Defina prazo por classe de dado, implemente como automação e prove que ela roda:

• Tabelas com dado pessoal: rotina de expurgo com registro do que foi apagado (contagem, não conteúdo).
• Logs e traces: retenção curta por padrão, com exceção explícita e justificada.
• Backup: o ponto difícil. Não dá para apagar uma linha dentro de um backup íntegro — o caminho aceito é retenção limitada do backup, criptografia, e registro de que o dado será eliminado no ciclo. Documente isso, porque vai ser perguntado.
• Ao encerrar um serviço, apague os dados dele; volume órfão e bucket esquecido são passivo.

Trilha de auditoria e evidência

Auditoria é o que transforma “nós temos controle” em prova. O mínimo:

• Quem acessou dado pessoal: log de acesso ao banco e à API, com identidade individual — conta compartilhada destrói a trilha inteira.
• Quem mudou o quê: audit log do Kubernetes e da nuvem (CloudTrail e equivalentes), enviado para conta ou projeto separado, com escrita apenas em anexação.
• Aprovação de mudança: o histórico do Git e do pull request já é evidência boa, desde que exista revisão obrigatória.

# audit log do Kubernetes: quem leu Secret em produção
jq -r 'select(.objectRef.resource=="secrets" and .verb=="get")
  | "\(.requestReceivedTimestamp) \(.user.username) \(.objectRef.namespace)/\(.objectRef.name)"' \
  audit.log | tail -20

Guarde o log de auditoria fora do alcance de quem opera o sistema auditado, e monitore a sua ausência: parar de receber log é o primeiro sintoma tanto de falha quanto de adulteração.

Transferência internacional

Servidor fora do Brasil não é proibido, mas exige base legal e salvaguarda adequada; a ANPD regulamentou cláusulas-padrão para isso. Do lado técnico, o que muda é o que você precisa saber e conseguir mostrar: em qual região cada dado está, quais subprocessadores tocam nele (inclusive SaaS de observabilidade, e-mail e suporte) e como você impede que uma réplica apareça em outra região por padrão de serviço gerenciado.

Escolher sa-east-1 ou outra região brasileira simplifica a conversa. Se você usa serviço com processamento fora, registre e leve ao encarregado — a decisão é dele, a informação é sua.

Como isso vira rotina

Compliance sustentável parece com o resto da engenharia: dados.yaml revisado no pull request, política automatizada barrando bucket público e volume sem criptografia, retenção implementada como código, e uma revisão trimestral com o encarregado. Auditoria vira uma exportação de evidência, e não um mês de trabalho parado.

Próximo passo: você fechou a trilha de DevSecOps. Reforce a base técnica em Hardening e leve as práticas ao pipeline com Segurança no pipeline.