O problema da proliferação de segredos

A proliferação de segredos é a disseminação descontrolada de credenciais sensíveis por uma organização. Um segredo é qualquer elemento que conceda acesso: chaves de API, senhas de bancos de dados, credenciais de acesso OAuth, chaves privadas TLS, chaves SSH e chaves de criptografia.

A proliferação ocorre quando esses segredos acabam espalhados por lugares onde nunca deveriam estar:

• Código-fonte e arquivos de configuração
• Fluxos de CI/CD e variáveis de ambiente
• Imagens de contêiner e infraestrutura como código
• Mensagens de bate-papo, páginas colaborativas e sistemas de chamados

Quando um segredo existe em muitos lugares, perde-se a capacidade de rastreá-lo, renová-lo ou revogá-lo de forma confiável.

A causa-raiz mais comum é o secret codificado diretamente, uma credencial escrita diretamente no código-fonte. Isso parece conveniente durante o desenvolvimento, mas se torna um risco permanente.

Veja como uma senha de banco de dados codificada diretamente aparece no código da aplicação:

Qualquer pessoa com acesso de leitura a este arquivo agora tem a senha de produção. Isso inclui cada desenvolvedor, cada executor de integração contínua e qualquer pessoa que posteriormente clone o repositório.

Um perigo crítico dos secrets codificados diretamente é o histórico do controle de versões. Mesmo que você exclua um secret em um registro posterior, ele permanece permanentemente no histórico de versões de cada cópia.

Você pode recuperar um secret vazado do histórico a qualquer momento:

Por isso, excluir um secret do registro mais recente não corrige o vazamento. O secret deve ser considerado comprometido e substituído imediatamente.

Quando um repositório com secrets codificados diretamente é enviado para um servidor público, como o GitHub, robôs automatizados o coletam em segundos ou minutos.

As consequências no mundo real incluem:

• Explosões na conta de nuvem chaves AWS vazadas usadas para criar frotas de mineração de criptomoedas, gerando dezenas de milhares de dólares em cobranças durante a noite.
• Vazamentos de dados credenciais de banco de dados expostas que levaram à exfiltração completa dos dados.
• Movimentação lateral um token vazado usado para avançar mais profundamente pela infraestrutura.

Os provedores de nuvem e o GitHub agora executam varredura de secret, que detecta automaticamente e, às vezes, revoga automaticamente as chaves vazadas, mas você não pode depender disso como rede de segurança.

Os contêineres introduzem um vetor sutil de proliferação. Segredos incorporados a uma imagem durante a compilação são armazenados em camadas da imagem e enviados a todos os repositórios e servidores que baixam a imagem.

Um erro comum é copiar um arquivo de secret e depois excluí-lo em uma camada posterior: o secret ainda existe na camada anterior:

Qualquer pessoa que baixe a imagem pode extrair essa camada e ler a chave. Em vez disso, use secrets de compilação ou injeção em tempo de execução.

Tirar os secrets do código e colocá-los em variáveis de ambiente é uma melhoria, mas não é uma solução completa. As variáveis de ambiente resolvem o problema da codificação direta, mas introduzem novos caminhos de exposição:

• Vazamento em despejos de falhas e rastreamentos de pilha de erros
• Visibilidade para outros processos por meio de /proc/<pid>/environ no Linux
• Registro por ferramentas de depuração que exibem todo o ambiente
• Armazenamento em arquivos .env de texto simples que são incluídos no repositório por acidente

As variáveis de ambiente são aceitáveis para configurações de baixa sensibilidade, mas secrets de alto valor devem ficar em um gerenciador de segredos dedicado, com controle de acesso e auditoria.

A proliferação torna a resposta a incidentes quase impossível. Quando um secret está em toda parte, duas perguntas não podem ser respondidas:

• Onde ele está? Você não pode substituir o que não consegue encontrar.
• Quem o usou? Sem registros de acesso centralizados, você não consegue delimitar o alcance de uma violação.

O raio de impacto de uma única credencial vazada cresce com a proliferação. Uma senha compartilhada e reutilizada em dez serviços significa que um único vazamento compromete todos os dez. A centralização e os secrets exclusivos e de curta duração reduzem esse raio drasticamente.

O lugar mais barato para interromper um vazamento é antes de ele entrar no controle de versões. As ferramentas de varredura de secrets antes do registro inspecionam as alterações preparadas e bloqueiam registros que contenham padrões de credenciais.

Entre as ferramentas populares de código aberto estão gitleaks, trufflehog e detect-secrets. Um gancho típico executado antes do registro roda localmente:

Combine isso com uma varredura no servidor durante a integração contínua, para que um desenvolvedor que contorne o gancho local ainda seja detectado.

Se um secret chegar a um lugar onde não deveria estar, siga esta ordem. A substituição vem primeiro; limpar o histórico é secundário, pois talvez já existam cópias.

• 1. Substitua revogue o secret vazado e emita um novo imediatamente.
• 2. Audite analise os registros de acesso para identificar qualquer uso não autorizado durante o período de exposição.
• 3. Elimine remova o secret do histórico (por exemplo, git filter-repo) e faça um envio forçado.
• 4. Previna adicione varredura e mova o secret para um gerenciador, para que isso não volte a acontecer.

Nunca pule a etapa 1. Um secret que tocou uma superfície pública está comprometido, sem exceção.

A proliferação piora quando os segredos têm privilégios excessivos e são compartilhados em excesso. Aplicar o menor privilégio limita os danos quando ocorre um vazamento:

• Dê a cada serviço sua própria credencial, nunca uma compartilhada.
• Limite cada secret às permissões mínimas de que ele precisa, como somente leitura em vez de administração.
• Prefira credenciais de curta duração que expirem automaticamente.
• Separe os secrets por ambiente: as chaves de desenvolvimento nunca devem conceder acesso à produção.

Esses hábitos transformam uma violação catastrófica em um incidente contido e recuperável.

As ferramentas sozinhas não resolvem a proliferação; a cultura resolve. Uma organização madura trata o gerenciamento de segredos como uma disciplina contínua:

• Postura padrão: nenhum secret jamais no código-fonte.
• Centralize o armazenamento em um cofre gerenciado, com controle de acesso e registros de auditoria.
• Automatize a varredura em todas as etapas: antes do registro, na integração contínua e no repositório de imagens.
• Faça da substituição uma rotina, não um evento reservado apenas para emergências.
• Treine todas as pessoas da engenharia para reconhecer e comunicar exposições sem culpabilização.

O objetivo é ter um sistema no qual vazar um secret seja difícil e a recuperação seja fácil.

Teste sua compreensão de por que excluir um secret vazado não é suficiente.

Você aprendeu por que secrets dispersos e codificados diretamente estão entre as vulnerabilidades de segurança mais comuns e prejudiciais.

• A proliferação de segredos é a disseminação descontrolada de credenciais pelo código, pelos fluxos de execução, pelas imagens e pelas conversas.
• Os secrets codificados diretamente permanecem para sempre no histórico de versões; excluí-los não corrige um vazamento.
• Repositórios públicos são coletados em minutos, levando a explosões na conta de nuvem e a violações.
• Variáveis de ambiente e camadas de imagem são contêineres que vazam informações, não armazenamento seguro.
• A proliferação aumenta o raio de impacto e torna a substituição e a resposta a incidentes impossíveis.
• A solução: fazer a varredura antes do registro, substituir primeiro quando houver vazamento, centralizar em um cofre e aplicar o menor privilégio.

Em seguida, vamos centralizar os secrets corretamente usando cofres e repositórios de segredos.