Exposição de dados sensíveis: o que nunca deve aparecer em logs

1. Introdução ao problema: por que logs vazam dados sensíveis

Existe uma crença perigosa entre desenvolvedores: "logs são só para uso interno, ninguém de fora vai ver". Essa falsa sensação de segurança já causou alguns dos vazamentos de dados mais emblemáticos da história recente. Em 2022, a Twilio expôs tokens de autenticação de milhares de usuários do Authy devido a logs mal configurados. Em 2023, um engenheiro do GitHub commitou acidentalmente credenciais em logs de debug que foram indexados por mecanismos de busca públicos.

O problema central é que logs frequentemente transitam por múltiplos sistemas — servidores locais, serviços de cloud, ferramentas de monitoramento, sistemas de SIEM — e cada ponto de passagem é uma superfície de ataque em potencial. Um log que parece inofensivo no terminal do desenvolvedor pode se tornar um bilhete premiado para um invasor quando armazenado em um bucket S3 mal configurado.

2. Dados pessoais identificáveis (PII) – o primeiro a riscar

Dados pessoais identificáveis (PII, na sigla em inglês) são o item mais óbvio e mais frequentemente logado por engano. Exemplos comuns incluem:

Nunca logue:
- Nomes completos
- CPF, RG, passaporte ou SSN
- Endereços residenciais
- Números de telefone
- Dados biométricos (impressão digital, reconhecimento facial)

// ❌ ERRADO: logando PII completo
log.info("Usuário cadastrado: nome=Maria Silva, cpf=123.456.789-00, email=maria@email.com, endereco=Rua A, 123");

// ✅ CORRETO: apenas identificador anônimo
log.info("Usuário cadastrado: id=98765, região=SP");

As consequências legais são severas. A LGPD brasileira prevê multas de até 2% do faturamento (limitado a R$ 50 milhões por infração). O GDPR europeu pode aplicar multas de até 4% do faturamento global. Em 2024, a Meta foi multada em € 1,2 bilhão por violações relacionadas a transferência inadequada de dados pessoais.

3. Credenciais e tokens de autenticação

Credenciais em logs são o equivalente digital a deixar a chave de casa debaixo do tapete e publicar a localização no Twitter. Absolutamente nenhum tipo de credencial deve aparecer em logs, nem mesmo em formato hash.

Nunca logue:
- Senhas em texto puro (óbvio, mas ainda acontece)
- Senhas com hash (o hash pode ser quebrado offline)
- Tokens JWT, access tokens, refresh tokens
- Chaves de API (API keys)
- Cookies de sessão
- Segredos de autenticação (client secret, secret key)

// ❌ ERRADO: expondo token JWT completo
log.warn("Falha de autenticação para token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...");

// ✅ CORRETO: apenas hash parcial para correlação
log.warn("Falha de autenticação para token: prefixo=a1b2c3, user_id=456");

Um caso real emblemático: em 2019, a Tesla teve tokens de acesso de seus funcionários expostos em logs internos acessíveis por um ex-funcionário, resultando em roubo de dados proprietários.

4. Dados financeiros e de pagamento

Dados financeiros são o alvo favorito de criminosos cibernéticos. Logar qualquer informação bancária ou de cartão é uma violação direta do padrão PCI DSS, que exige que o PAN (Primary Account Number) nunca seja armazenado em logs.

Nunca logue:
- Número completo do cartão de crédito (PAN)
- CVV/CVC (código de segurança)
- Data de validade do cartão
- Dados bancários completos (agência, conta, dígito)
- Chave Pix completa
- Saldo total de contas

// ❌ ERRADO: logando dados de pagamento completos
log.info("Pagamento processado: cartao=4532-1234-5678-9012, cvv=123, valor=R$ 1.500,00");

// ✅ CORRETO: apenas últimos 4 dígitos e valor
log.info("Pagamento processado: cartao_final=9012, valor=R$ 1.500,00, transacao_id=abc-123");

O não cumprimento do PCI DSS pode resultar em multas de até US$ 500.000 por incidente, além da perda do direito de processar pagamentos com cartão.

5. Informações de infraestrutura que viram alvo

Informações aparentemente inofensivas sobre sua infraestrutura podem ser ouro puro para um invasor montar um ataque direcionado. Logs de erro que revelam caminhos de arquivos ou versões de software são particularmente perigosos.

Nunca logue:
- Caminhos absolutos do sistema de arquivos (/var/www/html/...)
- Versões exatas de bibliotecas e frameworks (ex: "Spring Boot 2.7.1")
- Endereços IP internos (192.168.x.x, 10.x.x.x)
- Nomes de servidores e domínios internos
- Portas abertas e serviços rodando

// ❌ ERRADO: expondo estrutura interna
log.error("Falha ao acessar arquivo: /opt/app/config/database_production.yml, servidor db-interno-01:5432");

// ✅ CORRETO: mensagem genérica sem detalhes de infra
log.error("Falha ao acessar arquivo de configuração: erro de permissão, arquivo_id=cfg-456");

6. Boas práticas para sanitização de logs

Implementar sanitização de logs não precisa ser complexo, mas exige disciplina e ferramentas adequadas.

Uso de bibliotecas de mascaramento

// Exemplo com Logback (Java) - configuração de padrão de mascaramento
// pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
// Adicionar filtro para CPF: (\\d{3}\\.?\\d{3}\\.?\\d{3}-?\\d{2}) -> ***.***.***-**

// Exemplo com Winston (Node.js)
const winston = require('winston');
const maskCPF = winston.format((info) => {
  info.message = info.message.replace(/\d{3}\.\d{3}\.\d{3}-\d{2}/g, '***.***.***-**');
  return info;
});

// Exemplo com Serilog (.NET)
// .Destructure.With(new MaskingOperator("CPF", @"\d{3}\.\d{3}\.\d{3}-\d{2}", "***.***.***-**"))

Implementação de "log context" controlado

Crie níveis de detalhamento que variam conforme o ambiente:
- Desenvolvimento: logs detalhados, com dados de debug (mas ainda sem PII)
- Homologação: logs moderados, sem dados sensíveis
- Produção: logs mínimos, apenas para rastreamento de erros

Revisão periódica

Estabeleça uma rotina de revisão de logs em produção usando ferramentas como ELK Stack, Splunk ou Datadog. Crie alertas específicos para padrões que indicam vazamento de dados sensíveis (ex: regex para CPF, cartão de crédito).

7. Ferramentas e frameworks que ajudam a evitar vazamentos

Detecção automática em código

// GitGuardian - detecta credenciais e secrets em commits
// Comando: ggshield scan path ./meu-projeto

// TruffleHog - escaneia repositórios Git em busca de secrets
// Comando: trufflehog git https://github.com/meu-repo

// Detect-secrets (Yelp) - plugin para CI/CD
// Comando: detect-secrets scan --update .secrets.baseline

Configuração de linters e CI/CD

Adicione verificações no pipeline de CI/CD para impedir que código com logs inseguros chegue à produção:

# Exemplo de GitHub Action para detectar padrões perigosos
name: Log Security Check
on: [pull_request]
jobs:
  check-logs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check for sensitive data in logs
        run: |
          if grep -rE "(senha|password|cpf|cartao|token)" --include="*.java" --include="*.py" --include="*.js" .; then
            echo "ERRO: Dados sensíveis encontrados em logs!"
            exit 1
          fi

Testes de segurança focados em logging

Inclua casos de teste específicos para verificar se logs não contêm dados sensíveis:

// Teste unitário (exemplo em Python com pytest)
def test_log_nao_contem_cpf():
    with patch('logging.Logger.info') as mock_log:
        processar_usuario({"cpf": "123.456.789-00", "nome": "João"})
        log_message = mock_log.call_args[0][0]
        assert "123.456.789-00" not in log_message
        assert "***.***.***-**" in log_message  # mascarado

8. Checklist final: o que nunca deve aparecer em logs

Resumo prático dos itens proibidos

Categoria Itens proibidos
PII CPF, RG, nome completo, endereço, telefone, e-mail, dados biométricos
Credenciais Senhas, tokens JWT, API keys, cookies de sessão, secrets
Financeiro Número de cartão, CVV, dados bancários, chave Pix, saldo
Infraestrutura Caminhos absolutos, versões exatas, IPs internos, portas

Exemplo de log seguro vs. log comprometedor

// ❌ LOG COMPROMETEDOR - NUNCA FAÇA ISSO
[2025-03-15 14:30:22] ERRO: Falha ao processar pagamento do cliente Maria Santos (CPF: 123.456.789-00)
  Cartão: 4532-1234-5678-9012 | CVV: 123 | Validade: 12/27
  Servidor: db-prod-01.internal.company.com:3306
  Stack: /opt/app/v2.1.3/lib/database_connector.rb:45

// ✅ LOG SEGURO - FAÇA ASSIM
[2025-03-15 14:30:22] ERRO: Falha ao processar pagamento | cliente_id=78901 | transacao_id=txn-456
  Motivo: cartão recusado | bandeira: Visa | final: 9012
  Código de erro: ERR-452 | ambiente: producao

Cultura de segurança

A tecnologia sozinha não resolve o problema. Invista em:
- Treinamento da equipe: workshops sobre boas práticas de logging seguro
- Code review obrigatório: toda inclusão de log deve passar por revisão de segurança
- Documentação viva: mantenha um guia atualizado de "o que pode e o que não pode logar"
- Resposta a incidentes: tenha um plano para quando um vazamento via logs for detectado

Lembre-se: logs são ferramentas poderosas para debugging e monitoramento, mas podem se tornar a maior vulnerabilidade da sua aplicação se não forem tratados com o cuidado que merecem. A segurança não é um destino, é um processo contínuo — e logs seguros são parte fundamental dessa jornada.

Referências