Boas práticas de logging seguro: o que nunca deve aparecer nos logs

1. Por que logging seguro é um pilar da segurança da informação

O logging seguro não é apenas uma boa prática de engenharia de software — é uma exigência legal e regulatória em praticamente todos os países com leis de proteção de dados. Leis como a LGPD (Lei Geral de Proteção de Dados Pessoais) no Brasil, o GDPR na União Europeia e o PCI DSS para dados de pagamento impõem sanções severas para vazamentos de dados sensíveis.

Quando um log contém informações pessoais ou credenciais, ele se torna um vetor de ataque. Um invasor que acesse um sistema de logs mal configurado pode extrair senhas, tokens de autenticação, números de cartão de crédito e dados biométricos sem precisar sequer comprometer o banco de dados principal. As consequências práticas incluem multas milionárias (a LGPD prevê multas de até 2% do faturamento), danos irreparáveis à reputação da empresa e processos judiciais.

É fundamental entender a diferença entre logging operacional (que registra eventos técnicos para depuração e monitoramento) e logging de auditoria segura (que registra eventos de segurança sem expor dados sensíveis). Enquanto o primeiro pode conter detalhes técnicos internos, o segundo deve ser rigorosamente sanitizado.

2. Dados pessoais e identificáveis (PII) — o maior vilão

Dados pessoais identificáveis (PII) são a categoria mais crítica e mais frequentemente vazada em logs. Nunca devem aparecer em logs:

  • CPF, RG, CNH, passaporte e outros documentos oficiais
  • E-mails completos (especialmente quando combinados com outros dados)
  • Números de telefone e endereços residenciais completos
  • Dados biométricos (impressões digitais, reconhecimento facial)
  • Informações de saúde (histórico médico, exames, diagnósticos)
  • Nomes completos combinados com data de nascimento ou outros identificadores

Exemplo de log inseguro:

2025-03-15 14:30:22 ERRO Usuário João Silva (CPF: 123.456.789-00, email: joao.silva@email.com) 
tentou acessar recurso restrito. Data de nascimento: 15/05/1985

Exemplo de log seguro:

2025-03-15 14:30:22 ERRO Usuário ID: a3f8b2c1 (perfil: admin) tentou acessar recurso restrito. 
Motivo: permissão insuficiente

3. Credenciais e segredos de autenticação

Credenciais em logs são um dos erros mais graves que um desenvolvedor pode cometer. Absolutamente nunca devem aparecer:

  • Senhas em texto claro (nem mesmo hashes devem ser logados em ambientes de produção)
  • Tokens de acesso (Bearer tokens, JWT completos)
  • Chaves de API e refresh tokens
  • Segredos de sessão e cookies de autenticação
  • Códigos de autenticação de dois fatores (2FA)

Exemplo de log inseguro:

2025-03-15 14:31:05 INFO Login realizado com sucesso. Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Exemplo de log seguro:

2025-03-15 14:31:05 INFO Login realizado com sucesso. Usuário ID: 12345. 
Sessão iniciada em: 14:31:05

4. Informações financeiras e de pagamento

Dados financeiros são altamente sensíveis e regulados pelo PCI DSS. Nunca devem ser logados:

  • Números completos de cartão de crédito (PAN) e CVV
  • Dados bancários completos (agência, conta, dígito)
  • Chaves PIX completas
  • Histórico de transações com valores exatos combinados a identificadores pessoais
  • Saldos de contas e extratos bancários

Exemplo de log inseguro:

2025-03-15 14:32:10 INFO Pagamento processado. Cartão: 4532 1234 5678 9012, CVV: 123, 
Valor: R$ 1.500,00, Cliente: Maria Oliveira

Exemplo de log seguro:

2025-03-15 14:32:10 INFO Pagamento processado. Transação ID: TXN-20250315-001, 
Valor: R$ 1.500,00, Método: cartão de crédito (mascarado)

5. Dados de infraestrutura que facilitam ataques

Informações de infraestrutura podem ser usadas por invasores para planejar ataques direcionados:

  • Senhas de banco de dados e strings de conexão completas
  • Endereços IP internos e topologia de rede
  • Versões exatas de bibliotecas e frameworks (facilitam mapeamento de CVEs)
  • Nomes de servidores internos e domínios não públicos
  • Portas de serviço e configurações de firewall

Exemplo de log inseguro:

2025-03-15 14:33:00 ERRO Falha na conexão com banco MySQL 8.0.32 no servidor interno 
192.168.1.100:3306 usando usuário 'root' com senha 'admin123'

Exemplo de log seguro:

2025-03-15 14:33:00 ERRO Falha na conexão com banco de dados. 
Serviço: banco_principal. Código do erro: DB_CONN_TIMEOUT

6. Headers HTTP e metadados de requisição perigosos

Headers HTTP frequentemente contêm informações sensíveis que não devem ser logadas:

  • Authorization headers (Bearer tokens, Basic Auth credentials)
  • Cookies de sessão e CSRF tokens
  • User-Agent com informações detalhadas de sistema operacional e navegador
  • Referer headers que podem expor URLs internas
  • Headers personalizados que contenham dados sensíveis

Exemplo de log inseguro:

2025-03-15 14:34:00 INFO Requisição recebida. Headers: 
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Cookie: session_id=abc123; csrf_token=xyz789
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

Exemplo de log seguro:

2025-03-15 14:34:00 INFO Requisição recebida. 
Headers registrados: Content-Type, Accept, X-Request-ID

7. Técnicas de sanitização e mascaramento em logs

A implementação de sanitização deve ser automatizada e aplicada em toda a cadeia de logging:

Filtros automáticos com regex:

Exemplo de regex para mascarar CPF:
(\d{3})\.(\d{3})\.(\d{3})-(\d{2}) → $1.***.***-$4

Exemplo de regex para mascarar e-mail:
([a-zA-Z0-9._%+-]+)@([a-zA-Z0-9.-]+\.[a-zA-Z]{2,}) → $1@***.com

Substituição por placeholders:

Senha: [REDACTED]
Token: [REDACTED]
Cartão: **** **** **** 1234
CPF: ***.***.***-00

Log estruturado em JSON com campos explicitamente permitidos:

{
  "timestamp": "2025-03-15T14:35:00Z",
  "level": "INFO",
  "event": "user_login",
  "user_id": "a3f8b2c1",
  "ip": "***.***.***.***",
  "action": "login_success"
}

8. Monitoramento contínuo e revisão de logs

O logging seguro não é uma configuração única — requer monitoramento contínuo:

  • Auditoria periódica dos logs para detectar vazamentos acidentais
  • Ferramentas de análise de logs com alertas para padrões suspeitos (ex.: sequências de dígitos que parecem CPF, padrões de e-mail)
  • Cultura de "security by design": revisão de logging em code review, checklist obrigatório antes de deploy
  • Testes automatizados que verificam se logs não contêm dados sensíveis
  • Rotação e retenção segura de logs com criptografia em repouso

Referências