Cover do episódio 88: Subi credencial no Git. Aqui está o que eu fiz depois.
#0888 de julho, 20193 min leituraBastidores do CódigoS3 · 2018–2019

Subi credencial no Git. Aqui está o que eu fiz depois.

Aconteceu em 2019, meu primeiro projeto real com cliente pagando. API key de pagamento no histórico do Git. Aprendi sobre variável de ambiente da pior forma.

SegurançaGitConfiguraçãoBackend

Foi um projeto de integração com gateway de pagamento.

Precisava testar local, configurei a API key direto no código — "depois eu tiro antes de commitar", aquela mentira clássica. Commitei. Pushei. Só percebi quando fui olhar o repositório no GitHub e vi a chave lá, no diff público.

Chave de sandbox, graças a deus. Mas o padrão estava estabelecido no projeto e o próximo passo seria apontar para produção.


O que você faz quando isso acontece

Rotaciona a credencial imediatamente. Antes de qualquer outra coisa. Não adianta apagar o arquivo do Git se a chave ainda está ativa — qualquer bot que indexou o repositório nas últimas horas já tem ela.

Depois limpa o histórico com git filter-repo (não com git filter-branch, que é legado e tem bugs). Mas se o repositório é privado e você sabe quem teve acesso, às vezes rotacionar a credencial é suficiente — limpar histórico é mais trabalho do que protege nesse caso.

O .gitignore com .env entra antes do primeiro commit. Não depois.


Variável de ambiente não é magia

É só uma convenção: em vez de colocar valor no código, você lê de uma variável que o sistema operacional fornece.

# ruim
API_KEY = "sk-live-abc123"

# bom
import os
API_KEY = os.environ.get("PAYMENT_API_KEY")

O arquivo .env local fica fora do Git. O arquivo .env.example com as chaves sem valor vai no Git — documenta o que precisa ser configurado.

# .env.example (vai no Git)
PAYMENT_API_KEY=
DATABASE_URL=
JWT_SECRET=

Parece óbvio depois que você aprende. Antes de aprender parece burocracia.


A parte que demora mais para internalizar

Variável de ambiente resolve desenvolvimento e projetos pequenos.

Em produção de verdade você vai querer algo como AWS Secrets Manager ou HashiCorp Vault — a aplicação busca o segredo em runtime de um lugar central, com auditoria de acesso e rotação automática.

Em 2019 eu não tinha isso. Configurava manualmente no servidor e rezava para não esquecer de atualizar quando trocava credencial. Funcionava. Mas uma vez eu deployei sem atualizar a chave no servidor e o sistema de pagamento parou em produção por 15 minutos enquanto eu procurava o problema.

Gerenciamento de segredo de verdade vem depois. O .gitignore com .env vem agora, antes do primeiro commit de qualquer projeto.

Essa semana: verifica o .gitignore do seu projeto principal. Tem .env lá? Se não tem, adiciona antes de qualquer outra coisa. Se já commitou alguma vez um arquivo com credencial, verifica se a credencial foi rotacionada.