Segredos no CI/CD: menos chaves fixas, mais identidade

Uma chave de produção pode começar como uma solução rápida e terminar espalhada por variáveis, notebooks e scripts antigos. Quando ninguém sabe onde ela é usada, a rotação vira um risco operacional. O primeiro passo é recuperar o controle desse ciclo de vida.

A OWASP reúne orientações para gestão de segredos. O GitLab documenta ID tokens com OIDC, incluindo emissor, identidade, público e expiração. Quando o serviço de destino oferece federação compatível, essa identidade pode ser usada para obter acesso sem armazenar uma chave de nuvem permanente no pipeline.

Faça um inventário com finalidade e responsável

Como roteiro proposto, liste cada credencial, o serviço acessado, a finalidade, o ambiente e o responsável. Registre prazo de validade e procedimento de revogação. O inventário deve apontar para o local protegido de armazenamento, sem reproduzir o segredo.

Separe ambientes e funções. Uma etapa que publica um pacote não precisa, por consequência, de acesso ao banco de produção. Evite contas compartilhadas com privilégios amplos: elas dificultam descobrir qual processo executou uma ação.

Troque confiança ampla por uma identidade específica

Em um exemplo hipotético de deploy, o serviço de destino aceita a identidade de um job de um projeto conhecido, executado a partir da referência autorizada. O acesso concedido permite publicar naquele ambiente e não administrar toda a conta.

Para isso funcionar, o destino deve validar assinatura, emissor, público, validade e atributos usados na política de confiança. Aceitar qualquer token do mesmo provedor é amplo demais. OIDC autentica uma identidade; a política do destino continua responsável por definir o que ela pode fazer.

Credenciais temporárias também precisam de proteção

• Entregue o token apenas ao job que necessita dele.
• Não imprima credenciais em logs, relatórios ou comandos de diagnóstico.
• Revise scripts de terceiros que executam no mesmo contexto.
• Não conceda acesso de produção a contribuições não confiáveis.
• Teste se projeto, referência ou público incorretos são recusados.

Uma validade curta reduz a janela de uso, mas não impede que um job comprometido use o token enquanto ele está válido. O isolamento do runner e a revisão do código executado continuam necessários.

Planeje a transição sem interromper o serviço

Nem todo sistema aceita federação. Para os que exigem uma credencial duradoura, use armazenamento apropriado, escopo reduzido, distribuição controlada e rotação ensaiada. A escolha precisa considerar o serviço real, sem criar infraestrutura adicional que a equipe não consegue manter.

Antes de retirar uma chave antiga, identifique seus consumidores e valide o novo caminho em ambiente adequado. Depois revogue a anterior e confira se ela deixou de autenticar. Apagar a variável do CI não revoga uma credencial no provedor.

Se houver exposição, trate o segredo como comprometido e siga o procedimento de revogação e investigação. Remover o texto do último commit não desfaz cópias, logs ou versões anteriores do repositório.