Dados pessoais se escondem nos registros
Os registros de aplicações são uma das superfícies RGPD mais negligenciadas em engenharia. Não porque os engenheiros ignoram a lei. Mas porque dados de usuários entram nos arquivos de log por acidente.
Um único registro de solicitação JSON pode conter quatro campos PII:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
Essa única entrada contém um e-mail, um IP e um número de telefone. Multiplique isso por milhões de chamadas de API diárias. O resultado é uma atividade PII importante. Ela precisa de base legal, limites e controles.
Compartilhar com terceiros aumenta o risco RGPD
Equipes compartilham arquivos de log com partes externas o tempo todo:
- Empresas de teste de penetração que recebem registros para mapear o comportamento da aplicação
- Consultores externos que usam amostras de log para diagnosticar problemas de desempenho
- Plataformas de log (Elastic, Datadog, Splunk) que recebem fluxos de saída completos
- Contratantes SRE que acessam registros durante incidentes
- Equipes de desenvolvimento em outras entidades legais que recebem arquivos para depuração
Cada compartilhamento levanta questões do Artigo 28 do RGPD. O destinatário é um processador? Existe um Acordo de Processamento de Dados? Eles têm base legal para ver dados de usuários nesses arquivos?
Plataformas de log são uma lacuna comum. Enviar saídas com e-mails reais e IPs de usuários para o Elastic Cloud ou Datadog cria um vínculo de processamento. Esse vínculo precisa de um DPA, cláusulas padrão e um mecanismo de transferência se a plataforma estiver fora da UE. Tudo isso leva tempo e revisão jurídica.
O caminho mais simples: remover dados de usuários antes que os arquivos saiam do seu sistema. Leia nossa visão geral de conformidade para o framework completo do Artigo 28.
Por que a estrutura JSON dificulta a detecção
Arquivos de log JSON variam em estrutura. O escaneamento de texto genérico não é suficiente.
Profundidade de aninhamento: Dados de usuários aparecem em qualquer profundidade. O campo request.headers.x-forwarded-for contém endereços IP. O campo response.body.errors[0].field_value pode conter entradas de usuários de erros. Um escaneamento de texto plano perde campos em caminhos aninhados.
Esquemas inconsistentes: Cada endpoint de API produz uma forma de saída própria. Arquivos de autenticação parecem diferentes dos arquivos de pagamento. Arquivos de atualização de perfil parecem diferentes de ambos. Uma abordagem de caminho fixo perde dados de usuários que aparecem em caminhos inesperados em contextos de erro.
Valores técnicos misturados com PII: Rastreamentos de pilha, códigos de erro e carimbos de data/hora devem permanecer intactos. A remoção global apaga campos necessários e torna o arquivo inútil.
A abordagem correta é a detecção baseada em conteúdo. Encontre dados de usuários pelo que eles são — padrão de e-mail, formato IP, entidade nomeada — não por onde estão. Isso lida com esquemas variáveis sem configuração por endpoint.
Substituição consistente mantém os logs úteis
O requisito principal é a integridade referencial. Se sarah.johnson@company.com aparece em 47 entradas de uma cadeia de solicitações, todas as 47 devem mapear para o mesmo valor.
Regras de mapeamento:
sarah.johnson@company.com→user1@example.com(mesmo valor em todo o arquivo)82.123.45.67→192.0.2.1(IP de documentação RFC 5737 — claramente não real)+49 176 1234 5678→+49 XXX XXX XXXX(mascarado)
Com esse mapeamento, um desenvolvedor pode rastrear user1@example.com em 47 entradas, reconstruir a cadeia de solicitações e corrigir o bug — sem ver dados reais de usuários.
Esses campos de metadados permanecem inalterados:
- Carimbos de data/hora (não são dados de usuários)
- Códigos e tipos de erro (não são dados de usuários)
- Rastreamentos de pilha (podem conter IDs técnicos, não dados de usuários)
- Métodos HTTP, caminhos, códigos de status (não são dados de usuários)
- Valores de métricas e latência (não são dados de usuários)
O resultado é um arquivo que funciona para depuração. Não contém dados reais de usuários. Consulte nosso glossário para a diferença entre anonimização e pseudonimização de acordo com o RGPD.
Caso de uso: Compartilhamento de logs para teste de penetração
Uma empresa SaaS realizou uma revisão de segurança trimestral com uma equipe externa de teste de penetração. O escopo exigia 90 dias de saída de API de produção para mapear fluxos de autenticação e analisar padrões de erro.
Volume bruto: 180 MB de arquivos JSON. Contagem PII: 4.200 e-mails únicos de usuários, 1.800 IPs únicas, 340 números de conta parciais em contextos de erro.
Sem remover primeiro os dados de usuários, compartilhar esses arquivos exigiria:
- Um DPA com a empresa de teste de penetração
- Um mecanismo de transferência do Artigo 46 do RGPD (a empresa estava fora da UE)
- Uma análise de notificação de titulares de dados
Cada ponto implica trabalho jurídico e tempo.
Com remoção de PII aplicada:
- Tempo de processamento: 25 minutos para 180 MB
- Saída: 180 MB de arquivos estruturalmente idênticos, todos os e-mails e IPs substituídos por valores seguros
- Resultado: a equipe de teste recebeu contexto completo; nenhum dado real de usuário chegou a eles
- Resultado RGPD: sem DPA necessário — saída depurada não são dados de usuários sob o RGPD
Consulte nossa FAQ para perguntas frequentes sobre o que conta como anônimo sob o RGPD.
Integrar a remoção de PII no CI/CD
Para equipes que compartilham saídas regularmente, esta etapa pode ser executada dentro dos pipelines existentes.
Rotação de logs:
- Script de rotação executa diariamente
- Etapa de remoção executa antes de arquivar ou enviar para qualquer plataforma de log
- Arquivos depurados vão para sistemas externos
- Arquivos originais permanecem internos com retenção completa
Script de pré-compartilhamento:
- Engenheiro precisa compartilhar uma amostra com um contratante
- Executa o script:
input=raw-logs/ output=clean-logs/ - Compartilha a pasta
clean-logs/ - Sem revisão manual de PII necessária
Abordagem sidecar:
- Sidecar depura o fluxo de saída antes de encaminhar
- Remoção em tempo real mantém utilidade para análise de logs
- A plataforma não recebe dados reais de usuários
Integração na política de retenção
O Artigo 5(1)(e) do RGPD exige limitação de armazenamento. A remoção de PII se encaixa em qualquer política de retenção.
- Saída bruta retida por 7 dias (para trabalho de depuração diário)
- Versões depuradas retidas por 90 dias (para análise de tendências e revisão de incidentes)
- Etapa de remoção executa no dia 7
Isso satisfaz a limitação de armazenamento. Elimina o risco de manter saídas brutas por longo prazo.