Segredos gravados em repositórios, arquivos de configuração ou variáveis de execução expõem equipes de desenvolvimento, operações e segurança a acessos difíceis de atribuir e revogar. O problema afeta qualquer pipeline que publique aplicações, imagens ou infraestrutura; a ação prioritária é retirar credenciais permanentes do fluxo, impedir que novos valores cheguem ao código e limitar cada execução ao recurso que realmente precisa.
O erro mais comum é tratar o segredo como um detalhe de configuração. Uma chave de nuvem, senha de banco, token de registro ou certificado é uma credencial operacional. Quando ela aparece em um commit, em um artefato ou em um log, a equipe precisa assumir que pode ter sido copiada. Remover o arquivo da versão mais recente não elimina cópias no histórico, em forks, caches, espelhos, máquinas de trabalho ou sistemas de backup.
O segredo precisa de dono
A primeira decisão é estabelecer centralização e ciclo de vida para cada credencial. O inventário deve registrar o serviço que usa o segredo, o ambiente, o proprietário, a finalidade, a forma de emissão, o prazo de validade, o procedimento de rotação e o caminho de revogação. Um valor sem proprietário não deve permanecer ativo apenas porque uma aplicação antiga pode depender dele.
A orientação da OWASP para gestão de segredos recomenda centralizar armazenamento, provisionamento, auditoria, rotação e administração. A recomendação não exige que toda a organização use uma única ferramenta. O ponto é padronizar como as aplicações se autenticam, como recebem o valor, quem pode acessá-lo e quais registros ficam disponíveis para investigação.
Separe os ambientes. Uma credencial de validação não deve ler dados de produção, e um pipeline de publicação não deve herdar permissões administrativas por conveniência. A mesma regra vale para serviços diferentes: compartilhar uma chave entre aplicações transforma um incidente local em um problema de atribuição e contenção muito mais amplo.
O proprietário também precisa definir o que acontece quando o segredo é suspeito. A resposta deve incluir preservação dos registros, identificação dos consumidores, bloqueio ou revogação, emissão de uma nova credencial e busca por uso indevido. Trocar o valor sem investigar onde ele apareceu pode interromper o serviço e deixar uma segunda cópia ativa.
Bloqueie antes do repositório
O segundo controle é colocar o bloqueio no ponto de entrada. A análise no repositório é necessária, mas chega tarde: o valor já pode ter sido replicado para o histórico e notificado a outros sistemas. O pipeline deve combinar detecção local, verificação no servidor e revisão de exceções.
O push protection documentado pelo GitHub bloqueia o envio quando identifica credenciais codificadas antes que elas cheguem ao repositório. O mecanismo também fornece uma mensagem para que o responsável remova o dado e tente novamente. Esse padrão é útil mesmo em plataformas diferentes: a prevenção deve ocorrer antes da persistência, não somente depois de um alerta.
Configure a verificação em pelo menos três pontos do fluxo: no gancho local para feedback rápido, no servidor de controle de versão para impedir o recebimento e no processo de construção para examinar arquivos, imagens e pacotes produzidos. A última barreira é relevante porque um segredo pode ser introduzido por uma dependência, um template, uma etapa de empacotamento ou uma ferramenta que reescreve arquivos durante a execução.
Não transforme o bypass em um botão sem responsabilidade. Toda exceção precisa exigir motivo, responsável e revisão. Um falso positivo pode ser tratado com uma regra específica; um token de teste deve ser revogado ou claramente inutilizado; a justificativa “corrigir depois” deve gerar uma pendência aberta, não um encerramento automático.
| Ponto | Controle | Evidência |
|---|---|---|
| Desenvolvimento | Detector local e revisão antes do commit | Resultado do verificador e alteração aprovada |
| Repositório | Bloqueio de credenciais e registro de bypass | Evento de bloqueio, motivo e responsável |
| Construção | Busca em artefatos, imagens e dependências | Relatório associado à versão produzida |
| Execução | Permissão mínima e identidade separada | Política aplicada e teste de negação |
Prefira identidade temporária
Armazenar uma chave com mais cuidado ainda deixa uma chave permanente no desenho. Quando a plataforma oferece federação ou identidade de carga, o pipeline deve provar quem está executando e receber acesso temporário, em vez de consultar um valor fixo guardado no sistema de integração.
A documentação do Google Cloud Secret Manager recomenda o princípio do menor privilégio e indica mecanismos de identidade de carga ou federação como alternativa à exportação de credenciais de contas de serviço. A vantagem operacional é reduzir a quantidade de material secreto que precisa ser armazenado fora do provedor e facilitar a associação entre uma execução e suas permissões.
Federação não é autorização automática. A política ainda deve restringir o repositório, o projeto, o ramo, o ambiente ou outro atributo que diferencie uma execução legítima de uma alteração não confiável. Um token emitido para uma verificação de código não deve conseguir publicar em produção. A identidade usada para construir uma imagem também não precisa alterar políticas de acesso.
Desenhe a confiança a partir do recurso protegido. Para publicar uma imagem, permita somente a operação de escrita no registro correspondente. Para executar uma migração, separe a identidade e exija uma etapa de aprovação. Para acessar dados sensíveis, associe a identidade ao ambiente e mantenha registros suficientes para demonstrar quem iniciou a ação e qual recurso foi consultado.
Quando a federação não for possível, trate a credencial persistente como exceção temporária. Restrinja o escopo, elimine permissões administrativas, monitore o uso e registre uma data de revisão. O plano de migração deve ter proprietário e critério de encerramento; sem isso, a exceção tende a virar arquitetura permanente.
Evite vazamento nos logs
Um pipeline pode proteger o repositório e ainda expor o segredo durante a execução. Comandos verbosos, mensagens de erro, arquivos temporários, relatórios de teste e variáveis de ambiente podem ser coletados por sistemas de observabilidade. O controle deve impedir que o valor seja impresso e deve limitar quem pode consultar registros de uma execução.
Revise scripts que exibem comandos completos, desative rastreamento detalhado em etapas que manipulam credenciais e aplique mascaramento no sistema de CI. Não considere o mascaramento suficiente: valores transformados, codificados, fragmentados ou incluídos em mensagens de erro podem escapar da regra. A melhor proteção é reduzir a quantidade de processos que recebem o segredo e evitar passá-lo por arquivos e variáveis quando a integração suporta uma chamada autenticada diretamente ao gerenciador.
Registre eventos de emissão, leitura, alteração de política, falha e revogação sem registrar o conteúdo secreto. O objetivo é responder a perguntas defensivas: qual identidade acessou, qual aplicação solicitou, em qual ambiente, em que momento e qual operação ocorreu. Um registro que contém a senha para explicar que a senha foi usada falha justamente no controle que deveria sustentar a investigação.
Também teste o caminho de erro. Force uma falha de autenticação em ambiente controlado e examine mensagens, artefatos e logs produzidos. Verifique se o pipeline deixa arquivos temporários, se o relatório de testes inclui cabeçalhos de requisição e se a ferramenta de diagnóstico copia o ambiente completo.
Prove que o acesso cabe
O controle só está concluído quando a equipe consegue demonstrar que a aplicação funciona com permissões restritas e que ações fora do escopo são negadas. Para cada pipeline, documente o recurso permitido, a operação esperada e o evento que comprova a execução. Depois tente ler outro ambiente, alterar uma política, acessar um recurso fora da aplicação e reutilizar a identidade em uma etapa diferente.
Um teste de negação deve produzir uma recusa atribuída à identidade correta. Se o fluxo somente funciona com uma permissão ampla, não amplie o papel automaticamente. Descubra qual chamada é necessária, restrinja a política ao recurso concreto e repita o teste funcional. A exceção deve ser revisada por alguém que não seja o autor da mudança.
Use o artigo sobre autoridade para decisões durante incidentes como referência para definir quem pode revogar uma credencial, interromper uma publicação e aprovar a recuperação. Se o acesso for abusado, a equipe precisa agir sem negociar responsabilidades durante a crise.
Os sinais prioritários incluem leitura de segredos por uma identidade inédita, uso fora do horário ou ambiente esperado, falhas repetidas seguidas de sucesso, criação de permissões adicionais e acesso a vários recursos em sequência. Relacione esses eventos com os registros de implantação. A investigação fica mais rápida quando a identidade, a versão publicada e o responsável pela execução aparecem no mesmo quadro.
Priorize a migração
Em P1, retire credenciais compartilhadas de produção, ative bloqueio de segredos no fluxo de código, preserve logs de acesso e defina um procedimento de revogação. Em P2, migre pipelines para identidade temporária, separe permissões por ambiente, crie testes de negação e elimine exceções sem prazo.
Comece pelo pipeline que combina maior privilégio, execução automática e acesso a dados sensíveis. Faça o inventário, estabeleça a política mínima, teste o caminho normal e o caminho negado, e só então remova a chave antiga. O critério de conclusão é concreto: não há credencial permanente desnecessária, novos vazamentos são bloqueados antes do repositório, os logs permitem atribuição e a revogação pode ser executada sem derrubar serviços não relacionados.