Da triagem à publicação: tarjamento de PDF em TI e SI

No momento de publicar um relatório de auditoria em transparência ativa, a equipe de TI e Segurança da Informação costuma entrar no fluxo como “última barreira”: conferir se o PDF que vai ao portal realmente corresponde ao que pode ser divulgado. É um ponto crítico porque, mesmo quando o texto está aparentemente “coberto”, o conteúdo pode continuar extraível.

Neste cenário, o documento é o relatório de auditoria (com anexos e evidências) e o momento é a triagem final antes da publicação. O problema típico não é a falta de decisão sobre o que deve sair, e sim a forma como isso foi aplicado no arquivo: anexos “esquecidos”, camadas ocultas do PDF e links internos que mantêm dados restritos acessíveis.

Em relatório de auditoria, o vazamento mais comum não está no corpo: está nos anexos incorporados e nos links internos do PDF

Relatórios de auditoria frequentemente circulam como um único PDF “bonito”, com sumário clicável, marcadores e anexos de evidências. É aí que a informação restrita costuma escapar: não no parágrafo do achado, mas em anexos incorporados (spreadsheets, imagens, PDFs menores) e em links internos que abrem o anexo original sem tarjamento.

Na prática, a equipe revisa o texto do relatório e aplica tarjas em páginas específicas, mas o arquivo final ainda pode conter: (1) um anexo embutido com planilha de coleta, (2) um PDF de evidência com dados integrais, (3) metadados do documento, (4) uma camada de texto (OCR) preservando o conteúdo “coberto”. Em transparência ativa, isso vira publicação oficial: qualquer pessoa pode baixar e extrair.

A consequência é objetiva: o relatório “parece” publicável, mas o pacote digital inclui informação restrita acessível por extração de anexos ou por seleção/cópia. É por isso que, em TI e Segurança da Informação, a revisão precisa tratar o PDF como contêiner, não como imagem estática.

Da triagem à publicação: um fluxo de revisão que fecha o PDF como contêiner

O que segue é um fluxo de ponta a ponta para relatórios de auditoria em PDF antes da transparência ativa. Ele não substitui a análise de sigilo (que vem das áreas demandantes), mas reduz o risco de deixar “rastro digital” no arquivo final. Para contexto institucional, vale manter as referências de transparência ativa e tratamentos no portal em linha com a Lei de Acesso à Informação (Lei 12.527/2011) e com as hipóteses legais de restrição de acesso quando aplicáveis.

1. Comece pelo inventário de partes do documento (não apenas páginas).
   • Identifique se o relatório tem anexos incorporados no próprio PDF (evidências, planilhas, capturas, logs).
   • Verifique se há sumário com links para páginas e para anexos.
   • Liste apêndices: “Anexo I – Base de amostra”, “Anexo II – Evidências”, “Anexo III – Logs”.
2. Separe “versão de trabalho” e “versão de publicação”.
   • A versão de trabalho pode manter comentários, marcações e anexos para validação interna.
   • A versão de publicação deve ser um PDF final com conteúdo permitido e sem material incorporado indevido.
3. Não confie em retângulo/desenho como se fosse tarjamento.
   • Se alguém “cobriu” com um retângulo preto no editor, o texto pode continuar na camada digital e voltar ao ser selecionado, copiado ou extraído. Isso é um erro recorrente em revisão de relatório.
   • O tarjamento só é seguro quando o conteúdo é removido do arquivo, não apenas escondido visualmente. Uma boa referência interna para alinhar a equipe é: tarja preta não protege.
4. Trate evidências digitalizadas como imagem: sem OCR não há localização; com OCR há camada de texto para remover.
   • Em anexos digitalizados (prints, ofícios escaneados, fotos), “cobrir a área” não remove o conteúdo da imagem.
   • Se o documento passou por OCR, pode existir texto selecionável por trás da imagem; nesse caso, a revisão precisa garantir que o conteúdo restrito foi removido também dessa camada.
5. Revise os pontos típicos de restrição de acesso em relatório de auditoria de TI.
   • Credenciais e segredos: chaves, tokens, trechos de configuração, arquivos “.env”, prints de console com segredos.
   • Topologia e detalhes operacionais: endereços IP internos, nomes de host, portas e diagramas com caminhos de rede.
   • Logs e rastros: linhas de log com identificadores, sessões, e-mails funcionais ou identificadores de usuário.
   • Listas de amostras: planilhas de coleta com identificadores que não precisam ir a público.
   • Indícios de vulnerabilidade explorável: passos reprodutíveis detalhados que não são necessários para transparência do achado.
6. Elimine anexos incorporados que não vão à transparência ativa.
   • Se o relatório estiver com “arquivos anexados” dentro do PDF, remova-os da versão de publicação.
   • Quando a evidência for necessária, publique uma evidência reduzida (recortada e tarja aplicada com remoção de conteúdo), não o arquivo bruto.
   • Em caso de dúvida, prefira anexar evidências por processo administrativo interno e publicar apenas a descrição no relatório.
7. Padronize a forma de tarjar no PDF (com remoção do conteúdo).
   • Se a equipe precisa alinhar procedimento operacional, mantenha um guia interno consistente; um ponto de partida é como colocar tarja preta em PDF, com foco em métodos que removem o conteúdo.
   • Quando a exigência for remover definitivamente o trecho, trate como “apagar do PDF” e não como “pintar por cima”: apagar dados de PDF.
8. Finalize a versão de publicação “achatando” o que for necessário e revalidando extração.
   • Exporte/feche o PDF de forma que comentários, camadas desnecessárias e objetos ocultos não sejam levados adiante.
   • Reabra o arquivo final e faça testes de seleção, cópia e pesquisa por termos que deveriam ter saído.
   • Teste também a estrutura: links do sumário, anexos, marcadores e “arquivos anexados”.
9. Registre a decisão e o rastro do que foi removido.
   • Mantenha, no processo interno, a lista de elementos removidos (ex.: “Anexo II – Logs completos: não publicável; publicado apenas extrato com campos suprimidos”).
   • Isso ajuda auditoria posterior do próprio órgão: por que o PDF público não contém a evidência bruta.

Ferramenta pode ajudar quando a demanda é volume e consistência: se a TI recebe muitos relatórios/anexos e precisa aplicar ocultação definitiva de forma repetível, o MavenDoc pode apoiar o fluxo de tarjamento com foco em remoção do conteúdo, especialmente quando há padronização de campos e trechos a suprimir.

Verificação prática para hoje: pegue o PDF final do relatório de auditoria e tente (1) pesquisar no documento por um termo que deveria ter sido suprimido (ex.: um hostname interno), (2) selecionar e copiar um trecho “tarjado”, e (3) verificar se o visualizador mostra “anexos” ou “arquivos incorporados”. Se qualquer um desses passos recuperar conteúdo indevido, o arquivo ainda não está pronto para transparência ativa.

Perguntas frequentes

O relatório tem sumário clicável. Isso pode apontar para um anexo com dados integrais?

Sim. Em muitos modelos, o sumário e os “Anexos” são links internos para objetos do PDF. Se o anexo foi incorporado como arquivo, o link pode abrir o original sem qualquer supressão. A revisão de TI deve testar os links na versão final e garantir que anexos não publicáveis foram removidos do contêiner.

Temos capturas de tela de console e arquivos de configuração no anexo. Tarjar só a parte visível resolve?

Depende do tipo de anexo. Em imagem pura (print colado como imagem), tarjar visualmente não remove o conteúdo original da imagem; apenas esconde a área. Em PDF que passou por OCR, pode haver texto selecionável por trás. Para publicação, o caminho seguro é gerar uma versão em que a informação restrita tenha sido removida do arquivo (inclusive de camadas de texto), e então validar por pesquisa e cópia.

Podemos publicar a evidência bruta e “confiar” que ninguém vai extrair?

Em transparência ativa, a presunção é de acesso amplo. Se a evidência bruta contém informação restrita, ela não deve estar no arquivo público. Uma alternativa é publicar extratos mínimos (ex.: trecho do log com campos suprimidos) e manter o material completo apenas no processo interno, com controle de acesso, registrando no processo o motivo da restrição conforme as hipóteses legais aplicáveis.

Como próximo passo, escolha um relatório recente que esteja para publicação e rode o fluxo acima no arquivo final, não no rascunho. Se a sua dor hoje é repetição (muitos anexos e várias versões), vale estruturar um padrão de revisão e centralizar a execução para evitar variações entre unidades. Quando a equipe precisar escalar o processo com consistência, o MavenDoc pode ser o ponto único para preparar a versão publicável sem carregar anexos e camadas indevidas.

Quero padronizar a revisão do PDF antes de publicar