O Risco Silencioso do RGPD no Seu Stack de Logs
Atualizado para 2026
A maioria das equipes audita seu banco de dados em busca de dados pessoais. Poucas aplicam o mesmo rigor ao sistema de logs.
O artigo 5.º, n.º 1, alínea e), do RGPD limita o tempo de armazenamento de dados pessoais. Para bancos de dados, as equipes definem políticas de retenção e tarefas de exclusão. Para arquivos de log, a regra é mais simples: manter tudo por 90 dias para depuração.
O problema? Esses registros contêm dados pessoais. Entradas de requisição contêm e-mails de usuários. Capturas de erro contêm valores de entrada brutos. Entradas de acesso contêm endereços IP. Cada um desses itens é dado pessoal sob o RGPD. Sua equipe precisa de uma base legal e de um plano de retenção para cada caso.
O Que Vai Parar nos Seus Arquivos de Log
O logging padrão de aplicações web acumula uma ampla gama de PII de várias fontes.
Entradas de acesso (nginx/Apache):
- Endereços IP — dados pessoais segundo as diretrizes do EDPB
- Strings de user-agent — podem permitir identificação de dispositivos
- Tokens de sessão — se incluídos na saída
Entradas de aplicação (JSON estruturado):
- IDs de usuário e endereços de e-mail
- Erros de validação — geralmente incluem o valor inválido bruto, que pode ser um dado real do usuário
- Eventos de negócio — IDs de pedido vinculados a contas de clientes
- Consultas de pesquisa — podem conter nomes ou endereços
Entradas de API gateway:
- Cabeçalhos de autorização — parcialmente capturados em algumas configurações
- Parâmetros de consulta — podem conter IDs de usuário, nomes ou e-mails
- Corpos de requisição e resposta — presentes em configurações de nível de depuração
Entradas de auditoria de banco de dados:
- Consultas SQL com cláusulas WHERE como
email = 'user@example.com' - Valores pessoais literais em parâmetros de consulta
Esse acúmulo não é intencional. É um efeito colateral de práticas de logging criadas para depuração, não para o RGPD.
Posição do EDPB sobre Endereços IP
O Comitê Europeu para a Proteção de Dados (EDPB) considera endereços IP como dados pessoais. Os provedores de internet podem vinculá-los a assinantes. Dentro de uma organização, eles podem identificar usuários específicos.
A implicação é direta. Entradas de acesso com IPs são registros pessoais. Manter a saída do nginx por 12 meses significa manter dados pessoais por 12 meses. Isso exige uma base legal sob o artigo 6.º. Também exige que o período de retenção corresponda à finalidade declarada.
A maioria das equipes pula essa análise. "Mantemos entradas por 90 dias porque a segurança determina assim" é uma regra operacional. Não é uma análise sob o artigo 5.º, n.º 1, alínea e). Veja nossa visão geral de conformidade legal para o contexto completo.
O Caminho para a Conformidade
O caminho prático para a maioria das equipes não é reduzir os períodos de retenção. As justificativas operacionais e de segurança para períodos mais longos são reais. O melhor caminho é mascarar as entradas antes do armazenamento de longo prazo.
Um modelo em camadas funciona bem.
0–7 dias: Registros brutos completos para depuração ativa. Sete dias é curto o suficiente para a maioria das equipes.
7–90 dias: Registros mascarados para análise de tendências e monitoramento de segurança. IPs são substituídos. E-mails de usuários se tornam tokens estáveis. Números de conta são mascarados. Campos técnicos — timestamps, códigos de erro, latência, endpoints — são mantidos.
90+ dias (se necessário): Apenas saída agregada. Contagens de eventos, taxas de erro, faixas de latência. Nenhum registro individual permanece.
A retenção de dados pessoais cessa em sete dias. A saída agregada pode ser mantida sem expor ninguém. Veja Segurança e Conformidade para mais detalhes.
Preservar a Estrutura JSON para Monitoramento
Um bom mascaramento mantém a estrutura JSON intacta. Ele apenas substitui o conteúdo. Isso mantém a saída útil para depuração e alertas.
Mantido:
- Estrutura JSON e nomes de chaves
- Timestamps e sequências temporais
- Tipos de erro e códigos de status HTTP
- Métodos HTTP, caminhos e valores de latência
- Tipos de eventos de negócio
Substituído:
- Endereços de e-mail → token estável por original (ex.:
user1@example.com) - Endereços IP → intervalos RFC 5737 (
192.0.2.x) - Números de conta →
ACCT_XXXXX - Números de telefone →
+XX XXX XXX XXXX - Nomes em texto de erro →
[PERSON]
Tokens estáveis mantêm os traces úteis. Um trace para user1@example.com em 40 entradas funciona igual ao original. Métricas agregadas — taxas de erro, latência, throughput — não precisam de nenhum dado pessoal. Veja o Glossário para os termos pseudonimização e anonimização.
Três Opções de Integração
Três padrões cobrem a maioria das equipes de engenharia.
Opção 1 — Mascaramento no pipeline: Fluentd ou Logstash intercepta cada linha antes de encaminhá-la. Uma etapa de mascaramento é executada inline. Elastic ou Datadog recebe apenas registros limpos. Nenhuma alteração no código da aplicação é necessária.
Opção 2 — Processamento em lote noturno: Registros brutos chegam ao armazenamento local. Um job noturno mascara a saída do dia anterior e exclui a versão bruta. Registros mascarados vão para o armazenamento de longo prazo. A saída bruta é mantida por apenas sete dias.
Opção 3 — Mascaramento antes do compartilhamento: Registros brutos permanecem internos com controles de acesso rigorosos. Antes de compartilhar com pen testers ou contratados externos, execute um passe de mascaramento. Partes externas sempre recebem versões limpas.
Para documentação do RGPD, o mascaramento é uma "medida técnica" sob o artigo 32.º. Documente a ferramenta, sua configuração e sua política de retenção no Registro das Atividades de Tratamento (RAT) sob o artigo 30.º. Veja nosso FAQ para perguntas frequentes sobre o RAT.
Quer ver um exemplo prático? Confira os estudos de caso. Veja também os preços para saber qual plano inclui pipelines de mascaramento integrados.
Fontes
- RGPD Artigo 5.º: Princípios relativos ao tratamento — VERIFIED-EXTERNAL
- Parecer EDPB 5/2019 sobre a diretiva ePrivacy e o RGPD — VERIFIED-EXTERNAL
- Sonra.io: Mascaramento de PII em dados JSON e XML — VERIFIED-EXTERNAL