2026-08-20
Como Limpar Dados Sensíveis de Logs e JSON Antes de Partilhar.
Sempre que cola um log, uma resposta de API ou um dump de erros num ticket ou num chat, corre o risco de expor tokens, emails, IPs e segredos. Eis como limpá-los primeiro.
Na altura em que cola um ficheiro de log, uma resposta de API ou um dump de erros num ticket do Jira, num canal do Slack ou numa issue do GitHub, pode estar a partilhar mais do que pensa. Emails, tokens de autenticação, endereços IP internos, números de telefone, IDs de utilizador — tudo em texto simples, enterrado em JSON aninhado ou escondido em stack traces. Acontece todos os dias, e a maioria das pessoas só dá por isso depois.
O que provavelmente está a expor sem dar por isso
Os dados sensíveis escondem-se em sítios onde não os espera:
- Tokens JWT em cabeçalhos
Authorization— parecem-se comeyJhbGciOi...e podem ser descodificados em segundos para revelar claims de utilizador e a data de expiração - Chaves de API em query strings e cabeçalhos —
sk_live_...,AKIA...,xoxb-...— qualquer uma delas num log partilhado é uma fuga de credenciais - Endereços de email em objetos de utilizador, mensagens de erro e logs de auditoria
- Endereços IP internos em logs de rede —
10.x.x.x,192.168.x.x,172.16.x.x— revelam a topologia da sua rede interna - UUIDs que apontam para registos reais de utilizadores na sua base de dados
- Números de telefone em formato internacional —
+44...,+1...— em objetos de contacto ou logs de SMS - Sequências hexadecimais longas que na verdade são IDs de sessão, refresh tokens ou caminhos de ficheiros com nomes de utilizador reais
O problema não é que um destes seja difícil de detetar. É que um dump de erros de produção pode conter dezenas deles, aninhados em vários objetos, e está a tentar partilhá-lo depressa porque algo se partiu.
Porque é que a redação manual falha
Abre o log, procura @ e mascara os cinco endereços de email que encontra. Falta-lhe o sexto, enterrado três níveis abaixo num objeto metadata.contact_info aninhado. Procura sequências com aspeto de token e apanha o cabeçalho Authorization, mas perde o refresh token no corpo da resposta. Mascara o email mas deixa o user_id que aponta diretamente para ele na sua base de dados.
A redação manual falha porque:
- Está com pressa — a produção está em baixo e só precisa de ajuda
- Os logs reais têm estruturas profundamente aninhadas onde o mesmo tipo de valor aparece em níveis diferentes
- Os stack traces referenciam caminhos de ficheiros com nomes de utilizador reais —
/home/jsmith/app/src/handler.py - Encontra os valores óbvios mas perde os menos óbvios que continuam a apontar para dados reais
Como funciona o Removedor de Dados Sensíveis
O Removedor de Dados Sensíveis funciona inteiramente no seu navegador. Nada é enviado para um servidor — cole o seu texto, ele processa-o localmente e devolve-lhe uma versão limpa para copiar.
Eis o que faz:
- Deteta JSON automaticamente quando a entrada pode ser interpretada como JSON e processa-a de forma estrutural — percorre a árvore de objetos e substitui os valores sensíveis mantendo as chaves e a estrutura intactas
- Recai no modo texto para CSV, XML, logs brutos e qualquer outro formato — procura padrões e substitui as correspondências em linha
- Mascara os padrões sensíveis mais comuns:
- Endereços de email
- Números de telefone (formatos internacional e dos EUA)
- Endereços IP (IPv4 e IPv6)
- Tokens JWT (
eyJ...) - Chaves de API e tokens (sequências alfanuméricas longas que correspondem a formatos comuns)
- UUIDs
- Sequências hexadecimais longas com aspeto de IDs de sessão ou segredos
- Etiqueta o que substitui — a saída mostra
[REDACTED-EMAIL],[REDACTED-TOKEN],[REDACTED-IP], etc., para que veja o que foi apanhado
Modo JSON vs modo texto — o que muda
O modo JSON preserva a estrutura e a validade. Os valores são substituídos, mas as chaves e o aninhamento ficam intactos. A saída continua a ser um JSON válido que pode colar num ticket, e outro programador consegue perceber a forma da resposta sem ver os dados reais.
O modo texto substitui as correspondências em linha onde quer que apareçam. A estrutura do seu log ou CSV é preservada tal como está, mas os valores sensíveis são trocados por etiquetas de redação. É melhor para:
- Entradas de log de várias linhas com texto e dados estruturados misturados
- Exportações CSV onde quer manter as colunas intactas
- XML com valores em linha
- Stack traces com caminhos de ficheiros e nomes de utilizador
A ferramenta deteta automaticamente o modo a usar, mas consegue perceber pela saída — se vir JSON estruturado com valores [REDACTED-*], estava em modo JSON. Se vir substituições em linha em texto livre, estava em modo texto.
Quando é que a saída limpa é segura para partilhar
O removedor apanha os padrões comuns — emails, tokens, IPs, UUIDs, números de telefone e sequências com aspeto de segredo. Mas não conhece o seu domínio. Antes de colar a saída, procure:
- Nomes de código de projetos internos — a ferramenta não sabe que “Projeto Sundance” é um nome interno confidencial
- IDs de clientes que não são UUIDs — um campo
customer_id: 847291não é apanhado porque parece um número inteiro normal - Caminhos de ficheiros com nomes de utilizador reais —
/home/jsmith/ou/Users/sarah.chen/em stack traces - Mensagens de erro que referem pessoas reais — “Erro ao processar o pagamento de John Smith” não é sinalizado porque a ferramenta não sabe que John Smith é um cliente
O removedor é uma primeira passada forte. Acrescente por cima o seu próprio conhecimento do domínio antes de partilhar.
Cenários reais
Relatório de bug no Jira: cola a resposta completa da API, limpa-a e partilha a estrutura sem os dados. O programador consegue ver a forma da resposta, o código de erro e o aninhamento — sem ver emails nem tokens reais.
Mensagem no Slack durante um incidente: em vez de tirar uma captura de ecrã de um log (difícil de pesquisar e impossível de copiar e colar), cole o texto, limpe-o e partilhe a versão limpa. Os seus colegas recebem texto pesquisável e não expõe credenciais num chat que fica arquivado.
Issue no GitHub para uma biblioteca de terceiros: depara-se com um bug num cliente de API e quer colar o pedido e a resposta. Limpe primeiro — quem mantém a biblioteca não precisa da sua chave de API real para reproduzir o problema, e uma vez num issue público, os motores de busca indexam-no.
Integração de um fornecedor ou prestador de serviços: precisa de partilhar uma exportação de dados de exemplo para que possam criar uma integração. Cole-a, limpe-a e partilhe a forma — cabeçalhos de colunas, nomes de campos, estrutura de aninhamento — sem os registos reais de clientes.
Limpe antes de partilhar — todas as vezes
O Removedor de Dados Sensíveis leva cerca de cinco segundos a usar. Cole, clique, copie, partilhe. É mais rápido do que procurar e substituir à mão, apanha os campos aninhados que perderia e nunca envia nada para um servidor.
Guarde-o nos marcadores. Da próxima vez que a produção estiver em baixo e precisar de colar um log num ticket, vai agradecer por o ter feito.