Este texto foi redigido com apoio de inteligência artificial generativa, mas resulta de um processo prévio de análise e adequação de serviços em operação. As questões discutidas surgiram da revisão de configurações reais de infraestrutura, da pesquisa de referências técnicas e jurídicas e da avaliação de diferentes alternativas de implementação. A ferramenta foi utilizada como apoio à redação e organização do conteúdo, não como fonte única das conclusões apresentadas.

Referências para leitura

Recentemente me peguei revisitando uma questão aparentemente simples: o que fazer com os logs de acesso de sites estáticos?

Meus sites são gerados com Hugo, servidos pelo Nginx, e incluem desde blogs pessoais até páginas institucionais, organizações sociais e iniciativas políticas. Nenhum deles possui login, comentários, formulários ou qualquer mecanismo de cadastro de usuários. São, em essência, sites de leitura.

Ainda assim, existe uma necessidade legítima de compreender minimamente o que acontece na infraestrutura. Quantos acessos ocorreram? Quanto tráfego foi consumido? Quais páginas despertam mais interesse? Existem robôs abusivos ou tentativas de ataque? A partir dessas perguntas surgem outras duas: o que a legislação exige e o que realmente faz sentido coletar?

O impulso de medir tudo

Quando começamos a pensar em métricas, a primeira tentação costuma ser contar visitantes únicos.

A internet moderna está cheia de ferramentas que prometem exatamente isso. Algumas utilizam cookies, outras recorrem a fingerprints de navegador, enquanto várias adotam mecanismos intermediários que parecem mais amigáveis à privacidade.

Uma possibilidade que considerei foi gerar um hash baseado em endereço IP e User-Agent. Em teoria, isso permitiria estimar visitantes únicos sem armazenar diretamente o IP.

Algo como:

IP + User-Agent
↓
SHA256
↓
identificador persistente

À primeira vista parece uma ótima ideia.

Mas existe um detalhe importante.

O problema dos hashes persistentes

Quando armazenamos um hash estável por longos períodos, acabamos criando um identificador persistente.

Não sabemos quem é a pessoa, mas sabemos que é a mesma pessoa.

Isso permite observar padrões de retorno, frequência de acesso e permanência ao longo do tempo. É possível perceber que alguém visitou o site hoje, voltou amanhã e continuou retornando durante semanas ou meses.

Do ponto de vista da privacidade, isso não é anonimização. É pseudonimização.

Paradoxalmente, a tentativa de “melhorar” a privacidade pode acabar aumentando a capacidade de rastreamento.

Percebi então que estava caminhando para uma solução mais complexa e potencialmente mais invasiva do que o problema exigia.

O que realmente preciso saber?

Quando parei para analisar os objetivos reais dos sites, percebi que eles eram muito simples. Eu queria entender o volume de acessos, identificar as páginas mais visitadas, acompanhar o tráfego transferido e detectar eventuais abusos ou problemas operacionais.

Nenhum desses objetivos exige acompanhar indivíduos ao longo do tempo.

Essa constatação muda bastante a arquitetura necessária.

O papel dos logs

Um servidor web gera logs por razões legítimas.

Eles são úteis para investigar falhas, identificar ataques, detectar robôs agressivos, compreender problemas de desempenho e verificar a disponibilidade dos serviços. Eliminar completamente os logs não parece razoável. Por outro lado, armazená-los indefinidamente também não.

A solução mais equilibrada que encontrei foi bastante simples: manter logs completos por 31 dias, restringir o acesso administrativo a esses registros, utilizá-los exclusivamente para operação, segurança e estatísticas, e removê-los automaticamente após esse período.

O request_id que não era um identificador de usuário

Outro detalhe interessante surgiu ao revisar minha configuração do Nginx.

Eu registrava o campo $request_id nos logs e, em algum momento, imaginei que ele pudesse ajudar a identificar visitantes únicos.

Mas o $request_id é gerado para cada requisição individual.

Quando alguém acessa uma página, o navegador normalmente solicita o documento HTML, as folhas de estilo, imagens, ícones e, eventualmente, scripts. Cada uma dessas requisições recebe um identificador diferente.

Ou seja, o request_id é extremamente útil para correlacionar eventos em logs e investigar problemas técnicos, mas não serve para identificar visitantes. Do ponto de vista da privacidade, ele praticamente não representa risco, mas também não contribui para a contagem de usuários.

E a LGPD?

A discussão sobre LGPD costuma gerar duas reações opostas.

De um lado, quem conclui que não se pode registrar nada. Do outro, quem entende que basta alegar interesse legítimo para armazenar tudo indefinidamente.

Nenhuma dessas posições parece muito adequada.

A legislação trabalha com princípios como finalidade, necessidade, adequação e proporcionalidade. Para um site estático sem autenticação, manter logs operacionais por um período limitado para fins de segurança e administração parece bastante justificável.

O importante é evitar a coleta excessiva e definir claramente por quanto tempo os dados serão mantidos.

E o Marco Civil?

Existe um mito persistente de que todo site deve guardar logs detalhados durante meses ou anos para cumprir o Marco Civil da Internet.

Na prática, a situação é mais complexa.

O Marco Civil estabelece obrigações específicas para diferentes tipos de atores da rede, e nem todo site institucional ou blog pessoal se encontra na mesma situação de uma rede social, de uma plataforma SaaS ou de um serviço de hospedagem.

Ainda assim, manter logs operacionais por um período razoável pode ser uma decisão prudente para fins de segurança e gestão da infraestrutura.

Estatísticas sem rastreamento

A solução que acabei adotando é bastante simples.

Os logs permanecem disponíveis por 31 dias. Durante esse período, são utilizados para operação, diagnóstico, segurança e geração de estatísticas. Depois disso, são removidos.

Não há IPs, hashes persistentes, histórico individual ou perfis de navegação.

Essa abordagem permite responder às perguntas que realmente importam sem criar um sistema de rastreamento que nunca foi necessário.

Durante esse processo, a necessidade de classificar e transformar os logs de forma consistente acabou levando ao desenvolvimento de uma ferramenta própria para processamento e análise desses registros. O que começou como uma solução voltada à operação cotidiana dos sites evoluiu gradualmente para um projeto independente e posteriormente foi disponibilizado como software livre.

O resultado foi o Quipu, uma ferramenta voltada à análise, classificação e consolidação de logs de acesso, com foco em métricas operacionais, identificação de padrões de tráfego e redução da retenção de dados potencialmente identificáveis. Em vez de funcionar como uma plataforma tradicional de analytics baseada em rastreamento de visitantes, a proposta surgiu justamente da tentativa de compreender o comportamento geral dos serviços preservando apenas as informações necessárias para operação, estatísticas e segurança.

O código-fonte do projeto está disponível em: https://codeberg.org/paulohrpinheiro/quipu

Menos dados, menos problemas

Uma conclusão interessante desse processo é que privacidade nem sempre significa adicionar mais tecnologia.

Muitas vezes significa justamente o contrário.

Em vez de criar identificadores, algoritmos e mecanismos sofisticados para tentar anonimizar dados, talvez a pergunta mais útil seja:

Eu realmente preciso armazenar isso?

No meu caso, a resposta foi não.

E isso acabou levando a uma solução mais simples, mais transparente e provavelmente mais alinhada aos princípios da própria legislação.

Considerações finais

Este texto descreve uma análise técnica pessoal realizada a partir das necessidades concretas de alguns sites estáticos e da interpretação que faço dos princípios da LGPD e do Marco Civil da Internet. Não deve ser entendido como parecer jurídico nem como orientação legal definitiva.

A legislação é frequentemente sujeita a interpretações, evoluções regulatórias e entendimentos judiciais que podem variar ao longo do tempo. Em situações que envolvam maior exposição jurídica, tratamento de dados sensíveis, plataformas interativas ou requisitos regulatórios específicos, a consulta a profissionais especializados continua sendo o caminho mais adequado.

Referências para leitura