OWASP, LGPD e hardening costumam entrar no orçamento como três iniciativas separadas, com donos diferentes e cronogramas que não conversam. Na prática, elas descrevem o mesmo trabalho visto de ângulos distintos: o catálogo de falhas, a obrigação legal e a disciplina de configuração. Tratar os três como um programa único reduz custo e evita o cenário comum de ter parecer jurídico assinado sem nenhuma mudança real no código.

O que cada um resolve, e onde se sobrepõem

O OWASP Top 10 é um catálogo de classes de falha: controle de acesso quebrado, falhas de configuração, injeção, componentes desatualizados, falhas de autenticação. Não é certificação nem selo de conformidade. Serve para nomear o problema e verificar se o time está corrigindo as classes certas, em vez de apagar incêndios isolados.

A LGPD é obrigação legal sobre dado pessoal, não checklist técnico. Para engenharia, três pontos organizam quase tudo: o art. 46, que exige medidas de segurança adequadas; o art. 48, que trata da comunicação de incidente relevante à ANPD e ao titular; e o princípio da necessidade, que obriga a justificar por que cada campo existe e por quanto tempo é guardado. Sem inventário de dados pessoais, nenhum dos três é atendido de forma verificável.

Hardening é disciplina de configuração: reduzir superfície de ataque em servidor, runtime, banco, container, dependências e painel administrativo. Desligar o que não é usado, aplicar menor privilégio, remover debug de produção.

Os três se encontram em cinco controles: gestão de acesso, criptografia em trânsito e em repouso, registro de eventos, gestão de segredos e gestão de dependências. Um trabalho bem feito nesses cinco pontos rende evidência para auditoria, reduz itens do OWASP e fecha boa parte das exigências do art. 46.

Priorizar pelo dado e pelo caminho de ataque

Antes de escolher o que corrigir, vale responder, nesta ordem:

  1. Quais dados pessoais cada funcionalidade recebe, onde ficam armazenados, quem lê e por quanto tempo.
  2. Quais telas e endpoints expõem dado pessoal ou função administrativa sem autenticação forte.
  3. Quais falhas de controle de acesso permitem que um usuário legítimo veja o registro de outro.
  4. Quais componentes de terceiros estão em produção e qual é o processo real de atualização.
  5. Quais eventos ficam registrados, e por quanto tempo, para permitir investigação depois de um incidente.

Um exemplo de clínica ajuda a fixar. O prontuário eletrônico funciona, a equipe está treinada, mas a recepção inteira usa o mesmo login, o sistema não registra quem abriu qual prontuário e o backup fica em um storage sem criptografia. Nenhum desses pontos aparece em uma varredura automatizada de vulnerabilidades. Todos aparecem em uma revisão de controle de acesso. Corrigir exige perfil individual, log de leitura de prontuário e criptografia no armazenamento. Não corrigir significa, no dia do incidente, não conseguir dizer quais titulares foram afetados, o que transforma uma notificação limitada em comunicação ampla e de alto custo reputacional.

Hardening é rotina, não projeto

Hardening não termina. Ele vive em configuração versionada e em verificação contínua:

  • cabeçalhos de segurança e política de cookies definidos na aplicação, não só no proxy;
  • TLS obrigatório e redirecionamento explícito, sem exceções esquecidas em ambiente interno;
  • debug, stack trace e consoles administrativos desabilitados em produção;
  • usuário de banco com o menor privilégio possível, sem permissão de DDL para a aplicação;
  • segredos fora do repositório, com rotação e escopo por ambiente;
  • containers sem root, com sistema de arquivos somente leitura quando possível;
  • dependências atualizadas por processo, não por varredura anual;
  • backup com teste de restauração documentado.

Na prática

Para quem mantém software em produção, o tema vira rotina de quatro hábitos.

Primeiro, transformar cada correção de segurança em teste automatizado. Um caso de teste que prova que o usuário A não acessa o pedido do usuário B vale mais do que um documento de política.

Segundo, colocar segurança no checklist de pull request: entrada validada, autorização verificada no servidor, dado pessoal novo justificado e registrado no inventário.

Terceiro, nomear um responsável por evidência. Cada controle precisa de um artefato rastreável: configuração no repositório, log de acesso, ticket de correção, resultado de teste. Auditoria e due diligence de cliente pedem isso, e a resposta precisa existir antes de ser solicitada.

Quarto, ensaiar o incidente. Simular o vazamento de um conjunto de dados e medir quanto tempo o time leva para responder quais titulares foram afetados, qual foi a causa e qual correção impede a repetição. Esse ensaio expõe mais lacunas do que qualquer relatório.