O problema real dos segredos no código
Você já deve ter visto um arquivo .env com a chave de API do Stripe exposta no GitHub, ou uma senha de banco de dados colada num commit que já foi puxado por três microserviços diferentes. Isso acontece porque o padrão da maioria dos projetos é pegar qualquer credencial e injetá-la diretamente no código ou num arquivo de configuração versionado. O resultado é sempre o mesmo: alguém descobre, o token é revogado, o deploy quebra, e todo mundo corre para corrigir. O conceito por trás dos segredos inconfessáveis não é nenhum ferramenta nova ou mágica. É simplesmente a prática de tratar credenciais — chaves de API, certificados, senhas, tokens JWT, strings de conexão — como algo que nunca deve residir no repositório, no código-fonte ou nos logs. E quando eu digo "nunca", quero dizer literalmente. Um único commit com uma chave válida e você tem que revogar todas as instâncias dessa chave, mesmo as que já estão em produção há meses.
segredos inconfessáveis na prática
Aqui está como isso funciona de verdade, não a versão de blog post. Primeiro, você separa o que é código do que é configuração sensível. Código vai pro Git. Configuração sensível vai pra um gerenciador de segredos ou pra variáveis de ambiente provisionadas pelo pipeline de CI/CD. Não tente ser criativo com isso. Escolha uma ferramenta e use até virar rotina. As opções mais comuns são AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager, ou soluções mais simples como SOPS com.age para criptografia de arquivos no repositório. Para projetos pequenos, SOPS com age resolve 90% dos casos sem burocracia. Para ambientes corporativos com múltiplos times, Vault ou o serviço nativo da cloud que você já usa.
O erro mais frequente que eu vejo é tentar usar variáveis de ambiente diretamente sem rotação. Variáveis de ambiente funcionam perfeitamente para desenvolvimento local. Em produção, elas viram um problema porque não há controle de acesso granular, não há histórico de alterações, e não há forma fácil de revogar um segredo específico sem derrubar o serviço inteiro. Se o seu ambiente de produção depende de variáveis de ambiente sem um gerenciador por trás, você já tem um problema.
Como configurar isso sem dor de cabeça
Vou usar um exemplo prático com SOPS e age, que é o que eu recomendo para a maioria dos projetos que não estão em escala enterprise. Primeiro, gere um par de chaves age: age-keygen -o key.txt
Essa chave pública vai pro arquivo .sops.yaml do projeto. A chave privada fica em um local seguro, idealmente num cofre compartilhado do time ou num gerenciador de segredos do CI. Depois, você cria um arquivo YAML ou JSON com os segredos e criptografa: sops --encrypt --age publicKey --input-type yaml --output-type yaml config/secrets.yaml > config/secrets.enc.yaml
👉 Clique no botão abaixo para saber mais sobre o assunto!
O arquivo criptografado vai pro Git normalmente. O arquivo de chave nunca. Quando o pipeline de CI precisar dos segredos, ele descriptografa usando a chave privada armazenada de forma segura — seja num secret do GitHub Actions, num artefato do GitLab CI, ou num executor com acesso ao cofre. Eu vi um caso reciente onde uma equipe usava variáveis de ambiente do Heroku para todos os segredos. Doze serviços diferentes. Quando a chave de pagamento foi comprometida por um log esquecido num repositório antigo, eles levaram quatro horas para identificar todos os serviços que usavam aquela chave e revogá-la individualmente. Se tivessem usado um gerenciador centralizado, teria levado quinze minutos.
Erros que eu cometi e que você provavelmente vai cometer também
O primeiro erro é confiar que "só não vou fazer commit". Git é persistente. Branches, forks, pulls, mirrors. Uma vez que o segredo entrou no histórico, ele está lá para sempre. A única solução real é revogar e rotacionar. O segundo erro é não limitar o escopo dos segredos. Cada serviço deve ter acesso apenas ao que precisa. Um serviço de notificação não precisa da string de conexão do banco de dados principal. Se você passar tudo como variável de ambiente genérica, qualquer container comprometido terá acesso a tudo. Outro problema que muita gente subestima é a rotação. Segredos que nunca mudam são segredos que vão vazar eventualmente. Configure TTLs. Use tokens com validade curta quando possível. Para chaves de API, prefira scopes mínimos e expirença automática. Eu recomendo pelo menos uma rotação trimestral para qualquer segredo que persista por mais de noventa dias.
Tem também a questão dos logs. Muitos frameworks e bibliotecas logam configuração por padrão. Se o seu logger imprime objetos de configuração sem filtrar campos sensíveis, você acabou de colocar segredos em cada linha do log. Configure filtros de log explicitamente para campos como password, secret, key, token. Teste. Eu costumo rodar um grep por padrões conhecidos de segredos nos logs de CI antes de qualquer deploy de produção.
Quando essa abordagem não funciona
SOPS com age funciona bem para equipes pequenas e médias. Não escala bem para dezenas de times com requisitos diferentes de compliance. Nesse caso, Vault ou o gerenciador nativo da cloud é mais adequado, embora introduza complexidade adicional de infraestrutura e governança. Para projetos single-player ou pessoais, o custo de operar Vault geralmente não vale a pena. Um .env bem protegido localmente e variáveis de ambiente no ambiente de deploy já resolvem. Também há situações onde a criptografia no repositório simplesmente não é suficiente. Se o seu projeto é open source e você precisa compartilhar segredos com colaboradores externos, um serviço gerenciado com controle de acesso por identidade é a única opção viável. Arquivos criptografados compartilham o mesmo problema de qualquer arquivo no repositório: se o commit já foi feito, o segredo já esteve visível para quem tem acesso ao histórico.
Resumo do que funciona
Nunca coloque segredos no código ou em arquivos versionados. Use um gerenciador de segredos adequado à escala do projeto. Limite escopo por serviço. Rote segredos periodicamente. Filtre segredos dos logs. Teste antes de deploy rodando buscas por padrões sensíveis. E quando algo vazar — porque vai vazar — a resposta rápida de revogação é mais importante do que a prevenção perfeita.
