7 pontos que TI revisa no tarjamento em lote de logs antes de compartilhar
No compartilhamento com outro órgão, o documento que mais costuma travar a equipe de TI é o pacote de logs exportados (CSV, TXT ou PDF) de firewall/IDS, anexado como “evidência” de um incidente. O momento do fluxo é crítico: o arquivo já saiu do ambiente de monitoração e está prestes a ser enviado por e-mail institucional, juntado a um processo ou transferido por canal seguro.
Nesse cenário, o problema raramente é “se deve tarjar”, e sim onde tarjar sem destruir a utilidade do material para quem vai receber. Em logs, a dificuldade é dupla: há dados sensíveis misturados em linhas repetidas e, quando o time tenta resolver “no olho”, a revisão vira um gargalo e ainda assim deixa escapar campos previsíveis.
Em exportação de logs, o vazamento mais comum está nos identificadores repetidos do cabeçalho e do rodapé do relatório, não nas linhas do evento
Quando TI exporta logs em lote a partir de consoles (SIEM, firewall, proxy, EDR) e gera um relatório em PDF, muitos produtos adicionam automaticamente metadados fora do corpo principal. É justamente aí que a informação costuma escapar: nome do usuário autenticado no console, caminho da consulta salva, nome do tenant/unidade, hostname interno e até e-mail do analista que executou a exportação.
O motivo é simples: quem revisa tende a ficar concentrado no conteúdo “útil” (as linhas com data/hora, IP e ação) e ignora cabeçalhos e rodapés que se repetem em todas as páginas. Só que, no compartilhamento com outro órgão, esses identificadores agregam informação operacional sobre a rede e sobre pessoas que não precisa ser compartilhada para o outro lado analisar o incidente. Em outras palavras: o texto que se repete em todas as páginas é o que mais vale a pena revisar primeiro.
Esse ponto é especialmente perigoso quando alguém “tampa” com um retângulo preto no editor de PDF. Se o relatório tem camada de texto, desenhar uma tarja visual não remove o conteúdo: ele pode continuar selecionável, copiável ou extraível. Para entender por que isso acontece e como evitar, vale a leitura de tarja preta não protege e do guia de apagar dados de PDF.
7 pontos que TI revisa no tarjamento em lote antes de compartilhar
A revisão abaixo assume um pacote típico: um relatório em PDF (ou vários) gerado pelo console, e um ou mais arquivos brutos (CSV/TXT/JSON) com as mesmas linhas de eventos. A ideia é reduzir o risco sem “cegar” o material para o órgão destinatário.
- Cabeçalho/rodapé com identidade do operador: procure por “Generated by”, “Exported by”, “User”, “Analyst”, e por e-mails institucionais. Em alguns consoles o rodapé inclui o login do operador em todas as páginas. Isso deve ser ocultado definitivamente quando não for necessário para a finalidade do compartilhamento.
- Nome do ambiente, tenant ou unidade: campos como “Organization”, “Domain”, “Customer”, “Site”, nomes de clusters e identificadores internos podem revelar estrutura organizacional e segmentação. Se o outro órgão precisa apenas das linhas do evento, esses rótulos não precisam ir.
- Hostnames internos e FQDNs não essenciais: é comum o relatório trazer “src_host”, “dst_host”, nome do controlador, nome do collector ou do próprio appliance (“fw-datacenter-01”). Em geral, o que o destinatário precisa é o IP e a ação. Se o hostname identifica área/unidade, tarje o hostname e mantenha o IP (ou o inverso), conforme a necessidade do caso.
- IP interno e endereçamento de rede em massa: em alguns compartilhamentos, revelar faixas (/16, /24) não é necessário. Uma prática útil é manter o último octeto ou um pseudônimo consistente (ex.: “10.20.30.X”), desde que o receptor consiga correlacionar eventos. Se a correlação exigir o IP completo, mantenha, mas revise com atenção para não incluir IPs de estações identificáveis por padrão de nomenclatura.
- Campos de autenticação e sessão: “username”, “account”, “uid”, “session_id”, “auth_token”, “cookie”, “API key”, “Authorization: Bearer …”. Em incidentes, logs podem conter tokens por erro de configuração de debug. Esses valores, quando presentes, devem ser removidos do arquivo, não apenas cobertos visualmente.
- Parâmetros de URL e strings de consulta: proxy e WAF registram URLs completas. Parâmetros podem carregar nomes, matrículas, números de processo ou identificadores de atendimento (ex.: “?usuario=…”, “?cpf=…”, “?matricula=…”). O útil costuma ser o domínio, o path e o status code; o resto pode ser tarjado.
- Metadados do PDF e propriedades do arquivo: além do texto visível, o PDF pode carregar “Author”, “Creator”, “Producer”, nome da máquina e até caminho de exportação. Antes de enviar, verifique as propriedades do PDF e aplique uma rotina que remova metadados quando não forem necessários para o compartilhamento. Isso evita que a identidade do operador volte a aparecer fora da página.
Se o pacote for grande, a palavra-chave aqui é repetição: logs são “muito do mesmo”. É o caso típico de tarjamento em lote com regras de busca por padrões (e-mail, tokens, chaves) e revisão amostral por trechos críticos (primeira/última página, páginas com sumário, páginas com “About/Report settings”). Para PDFs, um procedimento prático está em como colocar tarja preta em PDF, com o cuidado de usar recurso de remoção real do conteúdo.
Observação importante: se o “relatório” for na verdade uma captura de tela ou PDF de impressão que virou imagem (sem texto), buscar e tarjar por padrões não funciona sem OCR. Cobrir uma área na imagem apenas esconde visualmente, mas não resolve se o mesmo dado aparecer em outras páginas ou em outro arquivo do lote. Nesses casos, o caminho é aplicar OCR para localizar ocorrências e então remover/ocultar definitivamente, ou então substituir o documento por uma exportação estruturada (CSV) que permita tratamento consistente.
Quando a demanda é recorrente (por exemplo, compartilhar logs mensalmente com órgão central), uma ferramenta como o MavenDoc pode ajudar a padronizar o tarjamento em lote com regras e validações, reduzindo o retrabalho e evitando “tarjas visuais” que não removem o conteúdo. Se o seu fluxo é no SEI, vale também conferir tarjamento no SEI para organizar a juntada e a publicação/compartilhamento sem vazamentos.
Verificação prática para hoje: pegue um PDF de log já pronto para envio e tente selecionar com o mouse o texto “Generated by” (ou qualquer cabeçalho). Se der para copiar e colar em um bloco de notas, a tarja feita por “desenho” não é suficiente; revise o arquivo com método que remova o conteúdo e revalide copiando/extraindo novamente.
Perguntas frequentes
Se eu tarjar o username do log, ainda preciso tarjar o e-mail do analista no rodapé do relatório?
Sim, porque são fontes diferentes. O username pode aparecer nas linhas de evento (ex.: autenticação em VPN), enquanto o e-mail do analista costuma vir do mecanismo de exportação do console e se repete em todas as páginas. Mesmo que você trate as linhas do log, o rodapé pode continuar expondo a identidade do operador se não for revisado separadamente.
É melhor enviar CSV/TXT bruto ou o PDF do relatório para o outro órgão?
Depende da finalidade. Para análise técnica, CSV/TXT costuma ser mais útil e mais fácil de tratar em lote (inclusive para localizar padrões e aplicar regras). Para leitura administrativa, o PDF ajuda. Em muitos casos, o melhor é enviar os dois: um PDF com contexto (sem metadados e sem cabeçalhos que identifiquem operador/ambiente) e o CSV/TXT com os campos estritamente necessários.
Como tarjar em lote quando os logs trazem a URL completa com parâmetros variáveis?
Trate por padrão, não por ocorrência manual. Defina quais partes ficam (domínio, path, método, status) e quais saem (query string, fragmentos, cabeçalhos de autenticação). Em seguida, aplique regras de substituição/remoção para tudo que vier após “?” e para cabeçalhos como Authorization/Cookie, e revise amostras dos trechos com maior densidade de URLs (ex.: eventos de proxy). Se o arquivo estiver em PDF com texto, use uma rotina que remova o conteúdo, e não apenas o cubra.
Como próximo passo, transforme essa revisão em um checklist interno de compartilhamento: uma folha simples que sempre acompanha o pacote de logs, com os campos que devem ser removidos e os que devem ser preservados para manter a utilidade técnica. Isso reduz o vai-e-vem entre áreas e evita que a equipe repita a mesma triagem sob pressão de prazo.
