Todo mundo sabe que senha não deveria estar no repositório. E, ainda assim, ela está — num arquivo de ambiente que alguém comitou "só para testar", numa variável de pipeline copiada entre três projetos, num playbook com a senha do banco em texto claro. O motivo não é desleixo: é que a alternativa parece complicada e o prazo é hoje. Vale desmontar essa impressão, porque existe um caminho gradual que não exige parar tudo para implantar um cofre.

Por que remover não resolve

O primeiro reflexo ao encontrar uma credencial comitada é apagar o arquivo e comitar a remoção. Isso não resolve nada.

O Git guarda histórico. A credencial continua acessível em qualquer commit anterior, em qualquer clone que alguém tenha feito, em qualquer fork, no cache do serviço de hospedagem, em backups do repositório. Reescrever o histórico ajuda, mas não alcança os clones que já existem por aí.

A conclusão é incômoda e inegociável: credencial que entrou no repositório está comprometida e precisa ser rotacionada. A remoção é higiene; a rotação é a correção. Tratar os dois como equivalentes é o erro mais caro dessa área — e a rotação, feita com pressa e sem plano, é justamente o que costuma quebrar o deploy.

As opções reais, do mais simples ao mais completo

Não existe uma resposta única. A escolha depende do tamanho da equipe, do que você já opera e de quanto quer manter.

Vale destacar duas linhas. SOPS é o meio-caminho subestimado: ele cifra apenas os valores do arquivo, deixando as chaves legíveis, então o arquivo continua versionado no Git e o diff continua fazendo sentido — mas o conteúdo sensível está cifrado. Para equipe pequena, é uma melhoria enorme com esforço de uma tarde.

Vault é a opção completa, e é importante ser honesto: ele é um serviço a mais para operar, com o seu próprio processo de inicialização, disponibilidade e recuperação. Vale quando você precisa do que só ele dá — segredo dinâmico e auditoria detalhada — e é excessivo para quem tem quinze segredos e três serviços.

Segredo estático e segredo dinâmico

Essa distinção é o que faz o Vault valer o esforço em ambientes maiores.

Um segredo estático é a senha do banco, guardada em algum lugar e lida por quem precisa. Ela existe por meses, é conhecida por vários sistemas e rotacioná-la exige coordenação.

Um segredo dinâmico não existe até ser pedido. A aplicação solicita acesso ao banco, o cofre cria uma credencial exclusiva com validade curta, e ela expira sozinha. Ninguém guarda nada permanente.

A diferença prática é grande. Com credencial de vida curta, um vazamento tem janela de exploração pequena, a rotação é automática por construção, e a auditoria mostra exatamente qual aplicação acessou o quê e quando. É o modelo que mais reduz risco — e o que exige mais maturidade para operar.

O problema de bootstrap

Toda arquitetura de cofre encontra a mesma pergunta: se os segredos estão no cofre, qual é o segredo para entrar no cofre? Se ele também for uma senha guardada em variável de ambiente, você só mudou o problema de lugar.

A resposta moderna é identidade em vez de senha. Em vez de a aplicação provar quem é com uma senha, ela prova com algo que o ambiente atesta:

• Identidade federada do pipeline. Serviços de CI emitem um token de identidade assinado, e o provedor de nuvem confia nele diretamente. Isso elimina a chave de acesso de longa duração guardada no pipeline — que é, de longe, a credencial mais perigosa que a maioria das empresas tem.
• Identidade da carga de trabalho em Kubernetes, onde a conta de serviço do pod é a prova de identidade.
• Atestação da máquina, em ambiente de VM, usando um mecanismo do provedor ou do próprio cofre.

Se você for fazer uma única mudança nessa área, faça esta: elimine as chaves de nuvem de longa duração do seu CI e troque por identidade federada. É a mudança com melhor relação entre esforço e risco removido.

Escopo e menor privilégio

Um segredo com permissão ampla transforma qualquer vazamento pequeno em incidente grande. Três disciplinas contêm o dano:

1. Uma credencial por consumidor. A mesma senha usada pela aplicação, pelo relatório e pelo script de manutenção não pode ser rotacionada sem coordenar três times — então não é rotacionada.
2. Permissão mínima de verdade. O serviço que só lê não precisa de credencial que escreve. O relatório não precisa de acesso a todas as tabelas.
3. Separação por ambiente. Credencial de desenvolvimento que funciona em produção é um acidente à espera de acontecer, e acontece justamente quando alguém testa algo rapidamente.

Rotação: planeje antes de precisar

A rotação de emergência quebra o deploy quando ninguém sabe onde a credencial é usada. O que torna a rotação tranquila:

• Inventário de onde cada segredo é consumido. Sem isso, rotacionar é adivinhar.
• Suporte a duas credenciais válidas ao mesmo tempo durante a transição. É o que permite trocar sem janela de indisponibilidade: cria a nova, migra os consumidores, revoga a antiga.
• Rotação exercitada em ambiente de teste, para o procedimento não ser escrito durante a crise.
• Prazo de validade conhecido, com alerta antes do vencimento — vale para credencial e para certificado.

Detecção: assuma que vai acontecer

Prevenção falha. Vale ter as duas linhas de defesa:

• Verificação antes do commit, na máquina de quem desenvolve, que bloqueia o envio de algo que pareça credencial. É a barreira mais eficaz porque age antes de o problema existir.
• Varredura do histórico do repositório, para encontrar o que já entrou. A primeira execução costuma revelar coisas esquecidas há anos — e cada achado é uma credencial a rotacionar, não só a apagar.

Vale também combinar um procedimento simples e sem culpabilização para quando alguém comitar um segredo. Se a reação esperada for punição, a tendência natural é esconder, e credencial vazada em silêncio é muito pior que credencial vazada e rotacionada em vinte minutos.

Um caminho gradual que cabe no prazo

Não é preciso implantar um cofre completo para melhorar muito:

1. Varra o histórico e faça uma lista do que está exposto.
2. Rotacione o que apareceu, começando pelo que dá acesso mais amplo — chave de nuvem, credencial de banco de produção.
3. Instale a verificação antes do commit para estancar o fluxo.
4. Tire as chaves de longa duração do CI, trocando por identidade federada.
5. Adote SOPS ou o cofre do seu provedor para os segredos de configuração.
6. Só então avalie Vault, e apenas se você precisar de segredo dinâmico ou de auditoria detalhada.

Os quatro primeiros passos removem a maior parte do risco real e cabem em poucos dias.

Erros comuns

• Apagar o arquivo e considerar resolvido, sem rotacionar.
• Chave de nuvem de longa duração guardada no pipeline.
• A mesma credencial compartilhada por vários consumidores.
• Credencial de desenvolvimento com acesso a produção.
• Cofre implantado sem resolver o problema de bootstrap.
• Nenhum inventário de onde cada segredo é usado.
• Rotação nunca testada, escrita durante o incidente.
• Cultura de punição, que faz o vazamento ser escondido.
• Vault implantado por completude, sem necessidade de segredo dinâmico.

Onde a Solvefy/Cloud entra

Fazemos esse trabalho na ordem que reduz risco mais rápido: varredura do histórico, rotação priorizada pelo alcance da credencial, verificação antes do commit e eliminação das chaves de longa duração do pipeline. Depois, implantamos o cofre adequado ao seu tamanho — e dizemos quando Vault é excessivo, porque cofre mal operado é um ponto único de falha novo. Também documentamos e exercitamos a rotação com a sua equipe, para o procedimento existir antes da emergência.

Quer saber o que está exposto no seu repositório hoje? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.