Segredo não passa pelo terminal

Onde um segredo deixa rastro sem ninguém perceber?

Em quase todo lugar por onde ele passa a caminho do serviço. Uma senha digitada no terminal fica no histórico do shell. Um token passado como argumento aparece na lista de processos. Uma chave impressa por um passo de depuração fica no log do CI. Um arquivo de configuração lido por um assistente de IA vai para o contexto do modelo. Nenhum desses rastros exige ataque. Todos nascem do trabalho normal: configurar, testar, depurar com pressa.

A escala é medida todo ano. O relatório State of Secrets Sprawl 2026, da GitGuardian, publicado em março, contou 28,65 milhões de segredos novos em commits públicos do GitHub em 2025, 34% a mais do que no ano anterior. E o código é só a parte visível: segundo o mesmo relatório, cerca de 28% dos incidentes nascem fora dos repositórios, em ferramentas de colaboração como chat e gestão de chamados, muitas vezes durante uma correção urgente.

O que esses números têm em comum é o mecanismo. O segredo vaza quando a regra depende de alguém lembrar dela no meio de uma emergência. Por isso, como defendemos no texto sobre regra escrita, a regra de segredos precisa ser desenho e mecanismo: caminhos por onde o valor não passa à vista, e não uma lista de cuidados.

Por que o terminal é log?

Porque quase tudo o que se digita fica registrado, e em três lugares ao mesmo tempo. O histórico do shell grava o comando num arquivo da conta. A lista de processos mostra os argumentos de cada comando, enquanto ele roda, a quem estiver na máquina. E um servidor bem endurecido audita todo comando executado como administrador, com os argumentos, num registro que sai da máquina e é guardado por um ano.

O histórico é o rastro mais conhecido e o que mais engana. Há configurações que tiram do histórico o comando começado por espaço, e isso ajuda pouco: tira do arquivo, não da lista de processos nem do log de auditoria. Um bloco de texto colado direto no terminal para criar um arquivo vai inteiro para o histórico. E um comando com a senha como argumento, como o cliente de banco de dados que aceita a senha na própria linha, deixa o valor visível para outros usuários enquanto roda. Alguns desses clientes avisam isso toda vez, e o aviso vira paisagem como qualquer outro.

O log de auditoria cria um paradoxo que vale entender. Quanto melhor a auditoria do servidor, pior o terminal fica como lugar para um segredo. O registro de tudo o que se executa como administrador existe para não ser apagado e para estar fora da máquina antes de um incidente, como vamos detalhar no fecho da série. Um segredo digitado ali fica preservado exatamente onde o desenho garante que nada some. Auditoria boa e segredo digitado não convivem; um dos dois perde, e não deve ser a auditoria.

Na prática, quatro hábitos fecham o terminal:

1. O valor é gerado direto no gerenciador de senhas, e não no terminal.
2. O arquivo de segredos é escrito com um editor, e não com um comando que repete o valor.
3. Arquivo de credencial viaja por canal cifrado até a pasta da própria conta, recebe a permissão certa e a cópia temporária é apagada de forma segura.
4. Para conferir, confere-se a presença, e não o valor: contar quantas variáveis estão vazias, sem imprimir nenhuma.

Como o segredo chega ao serviço?

Por arquivo com permissão restrita, lido pelo serviço na partida, e não por variável de ambiente. O repositório versiona só um modelo de configuração com os nomes dos segredos e um comentário sobre o que cada um é, nunca com valor. O arquivo real é escrito no servidor a partir do gerenciador de senhas, legível só pela conta do serviço, e fica fora do Git.

Duas regras acompanham esse arquivo. A primeira: o serviço recusa subir quando um segredo obrigatório está ausente ou vazio. Subir com senha vazia ou com um valor padrão escrito no código é pior do que não subir, porque funciona e ninguém percebe. A segunda: o validador de deploy, protagonista do texto sobre o PR como único caminho, recusa no PR um segredo escrito por extenso na configuração e um modelo com valor preenchido.

A preferência por arquivo tem motivo. A variável de ambiente é herdada por todo processo filho, aparece na inspeção do contêiner, pode ser lida no diretório do processo por quem tem acesso a ele e costuma ser despejada por relatórios de erro e páginas de depuração. A documentação do systemd diz que variável de ambiente não serve para passar segredo a um serviço, porque fica exposta a clientes sem privilégio e se propaga pela árvore de processos. A versão 247, de novembro de 2020, trouxe a alternativa: o serviço recebe a credencial como arquivo, num diretório próprio, indicado a ele na partida.

No contêiner, o equivalente são os segredos do Docker, montados como arquivo dentro dele. Muitas imagens oficiais já aceitam a convenção de ler um valor de arquivo: em vez de receber API_KEY_DO_SERVICO com o valor, a aplicação recebe API_KEY_DO_SERVICO_FILE com o caminho. Quando uma aplicação só aceita variável, o ajuste é um ponto de entrada que lê o arquivo e entrega a variável só àquele processo, na hora de subir. O valor nunca aparece por extenso na configuração do serviço.

O erro comum é achar que o arquivo de ambiente ao lado da configuração resolve. Ele resolve o Git, se estiver fora dele, e não resolve o resto: se o conteúdo vira variável dentro do contêiner, o valor volta a aparecer em cada inspeção.

Por que um segredo por uso?

Porque o estrago de um vazamento é do tamanho do alcance da credencial que vazou. Um segredo por uso, com o menor escopo possível, faz o vazamento de um ponto ficar naquele ponto. O token que vazar de um workflow não pode abrir o painel de segurança.

Imagine uma empresa com um único token "de serviço", usado pelo CI, pelo script de backup e pelo monitoramento. Um passo de depuração imprime o token no log do CI. Quem o leu passa a ter o backup e o monitoramento também. E trocar esse token quebra três coisas ao mesmo tempo, então a troca é adiada. Em março de 2025, uma action de terceiros comprometida, que o texto anterior descreve, imprimia no log do workflow os segredos dos repositórios que a executavam. Num caso assim, um token por uso limita o estrago ao que aquele uso alcançava.

Com um segredo por uso, cada consumidor tem o seu. A revogação é cirúrgica, a rotação afeta um lugar e o registro de acesso do provedor diz qual uso agiu. Leitura e escrita viram credenciais diferentes: quem só baixa a imagem de produção tem um token que só lê. Automação usa conta de máquina, com validade, e não o token pessoal de quem configurou.

O segredo por uso pede um inventário, e o inventário nunca tem valor. Para cada credencial: o uso, o dono, o escopo, onde ela mora, quando vence e quando foi trocada pela última vez. É esse inventário que permite responder em minutos, num incidente, o que um vazamento alcança e o que precisa ser trocado.

Como se faz rotação sem expor o valor?

Com um procedimento em que o valor novo vai do gerenciador de senhas ao serviço sem passar por terminal, e com o registro de cada rotação num PR que tem a data e o nome da credencial, nunca o valor. No nosso desenho, tokens de serviço e chaves de integração são trocados todo semestre, no mesmo dia em que sai alguém que conhecia o valor e imediatamente quando há suspeita.

A ordem importa:

1. Gere o valor novo direto no gerenciador de senhas.
2. Crie a credencial nova no provedor, mantendo a antiga válida.
3. Entregue o valor novo pelo caminho de sempre: o arquivo no servidor ou o campo de segredo do CI, preenchido a partir do gerenciador.
4. Reinicie o serviço e confirme que ele usa a credencial nova.
5. Revogue a antiga.
6. Registre a rotação num PR, com a data e sem o valor.

Revogar antes de confirmar provoca uma queda, e uma rotação que derruba o serviço é a última que alguém faz por vontade própria.

A rotação existe porque segredo velho não morre sozinho. No relatório da GitGuardian, mais de 64% dos segredos válidos detectados em 2022 ainda funcionavam no reteste de janeiro de 2026. Um segredo que nunca é trocado transforma qualquer vazamento antigo, inclusive os que ninguém percebeu, num vazamento atual. O NIST, na recomendação de gestão de chaves SP 800-57, chama de período criptográfico o tempo durante o qual uma chave está autorizada a ser usada. O princípio vale para todo segredo: nenhum deveria valer para sempre.

O erro comum é a rotação heroica: manual, sem roteiro, feita por uma pessoa só, que ninguém quer repetir. A prova de que o procedimento existe é fazer a primeira rotação com calma, antes de precisar dela no meio de um incidente.

E a IA?

O assistente de IA é um caminho novo para o segredo, e o mais traiçoeiro, porque parece ajuda. Peça a ele para descobrir por que o serviço não conecta ao banco, e o movimento natural é ler o arquivo de configuração. O valor entra no contexto do modelo, vai ao provedor, fica no histórico da sessão e pode reaparecer numa resposta ou num comando sugerido. No nosso desenho, o assistente não lê, não imprime e não envia valor de segredo, e o arquivo de segredos fica fora do alcance dele.

Isso não é instrução; é mecanismo, em três camadas.

1. Leitura bloqueada. A configuração gerenciada nega a leitura de arquivos de segredo, numa regra aplicada pela própria ferramenta antes de qualquer outra verificação. É uma das escolhas com custo daquele texto, porque atrapalha quem depura, e aqui o custo compensa: um hook que avalia comandos não vê a leitura direta de um arquivo.
2. Saída bloqueada na máquina. O guardrail bloqueia localmente a saída de comando que mostrou um valor de segredo, sem perguntar a ninguém de fora. E tudo o que ele envia a um classificador externo vai com os valores de segredo redigidos.
3. Presença, não valor. Para depurar, o assistente confere se a variável existe e se está preenchida, listando nomes, sem ler o conteúdo.

Há um ponto específico da IA que costuma passar despercebido: a configuração dos conectores do próprio assistente. O protocolo que liga assistentes a ferramentas externas, o MCP, usa arquivos de configuração que muitas vezes levam um token. A GitGuardian encontrou 24.008 segredos únicos em arquivos de configuração ligados ao MCP no GitHub público. O token de um conector segue a mesma regra de qualquer outro: fica no gerenciador ou no ambiente protegido da máquina, nunca no arquivo que vai para o repositório.

E a regra final vale aqui como em qualquer lugar. Um segredo que chegou ao contexto de um assistente está vazado, mesmo que a trilha local o mostre mascarado. Mascarado no registro continua vazado.

Quando um segredo é considerado vazado?

Quando chegou ao Git, ao terminal, a uma tela ou ao contexto de um assistente de IA. Troque. Sem debate sobre o repositório ser privado, o commit ter sido apagado ou a tela ter sido compartilhada só com gente da casa.

Apagar o commit não desfaz o vazamento. O histórico já está em cada clone, em possíveis forks, em caches e no log do CI que rodou sobre ele, e o check de segredos, como vimos no texto anterior, só roda depois do push. Repositório privado também não é abrigo: segundo a GitGuardian, repositórios internos têm cerca de 6 vezes mais chance de conter segredo escrito no código do que os públicos.

O procedimento é curto. Primeiro, troque e revogue o antigo, pelo roteiro de rotação. Depois, consulte o registro de acesso do provedor para saber se a credencial foi usada entre o vazamento e a revogação. Por último, limpe o histórico, como higiene, e não como correção. Um segredo por uso e uma rotação ensaiada são o que tornam esse procedimento barato o bastante para ninguém hesitar.

Para começar amanhã:

1. Procure segredo no histórico do shell das contas de servidor e no histórico do Git, e troque o que achar.
2. Passe para arquivo com permissão restrita todo segredo que hoje entra por variável de ambiente escrita na configuração.
3. Faça cada serviço recusar a partida quando faltar um segredo obrigatório.
4. Separe os tokens por uso e monte o inventário, sem valores.
5. Bloqueie a leitura de arquivos de segredo pelo assistente de IA na configuração gerenciada.
6. Marque a próxima rotação e faça a primeira com calma.

Segredo bem guardado não depende de alguém lembrar. Depende de não existir caminho por onde ele passe à vista. Resta uma máquina que toca segredos o tempo todo sem ser de confiança: a que roda o código de cada PR. É o assunto do próximo texto.