Radar Tech: cofre de credenciais de plataforma exposto e a conta que ninguém fez do blast radius

O que aconteceu

Duas coisas aconteceram na mesma semana e, juntas, explicam por que a resposta a incidente de credencial continua sendo o ponto fraco da maioria dos times.

Na quarta (21/10), uma plataforma de deploy avisou que detectou atividade anômala em sistemas que armazenam variáveis de ambiente de clientes. A investigação inicial indica que um terceiro não autorizado pode ter acessado variáveis cifradas e, para parte delas, obtido o conteúdo em claro. A recomendação foi das mais honestas e das mais desesperadoras: rotacionem todas as variáveis, incluindo chaves de API e credenciais de banco e de registry. Deploys pausados. E a mesma nota liga o episódio a uma série de ataques contra empresas de plataforma com o objetivo de chegar a provedores de inferência de IA — quem rouba chave de infraestrutura hoje não quer o servidor, quer o orçamento de tokens e o acesso aos modelos.

No mesmo dia, um pacote popular de biblioteca de LLM apareceu em versão comprometida no índice público, com roubo de credencial e backdoor. Dois incidentes, um mesmo efeito: chaves válidas, reutilizáveis e sem dono claro circulando em ambientes que ninguém inventariou.

O problema não é o aviso, é o que não se sabe

Um aviso de fornecedor chega sempre na mesma forma: "um subconjunto de usuários pode ter sido afetado". Ele não diz qual subconjunto, não diz quais chaves, e não pode dizer uma coisa que só você sabe: quais das suas credenciais estavam lá.

A partir daí, o incidente vira um problema de arquitetura, com quatro perguntas que se respondem com evidência — ou não se respondem:

• Quais chaves existiam? Não as que deveriam existir, as que existem. Uma mesma credencial normalmente mora em cinco lugares ao mesmo tempo: no pipeline de build, na variável injetada pela plataforma, dentro da imagem do container, no state da infraestrutura como código e num .env esquecido numa máquina de staging.
• O que cada uma abre? Um banco de dados abre um schema. Uma chave de nuvem com permissão herdada abre a conta inteira — e é comum encontrar chaves que carregam permissões administrativas de um papel antigo que ninguém revisou.
• O que continua funcionando depois de rotacionada? Um segredo de assinatura de sessão, quando trocado, não invalida os tokens já emitidos: quem capturou a chave continua entrando até o último token expirar. Rotacionar sem invalidar dá a sensação de resolvido e mantém a porta aberta.
• O que quebra se rodar na ordem errada? Rotacionar a credencial que o serviço usa para ler o cofre que guarda as outras derruba tudo de uma vez. Rotacionar uma chave compartilhada por dois serviços sem janela coordenada derruba um dos dois.

Por que "rotaciona tudo" é a resposta mais cara

Com três engenheiros e 120 credenciais mapeadas, um pedido de "tudo em quatro horas" não é um plano: é uma conta. Descontando preparação, sobra pouco mais de uma credencial por pessoa por hora — o suficiente para as que não têm consumidor externo, insuficiente para as que dependem de outro time ou de um parceiro.

Pior: rotação sem revogação comprovada deixa a chave antiga viva. E rotação sem varredura de cópias garante que a chave volta. A imagem antiga no registry, o cache da build, o log de job com a variável ecoada sistematicamente, o histórico do repositório — cada um desses lugares é o próximo incidente do mesmo tipo. É o padrão que se repete: o incidente é resolvido, o mecanismo que o permitiu não.

O caminho que fecha a classe de falha

A decisão de arquitetura que encerra esse ciclo não é "rotacionar mais rápido". É eliminar a chave reutilizável:

• Identidade de workload de curta duração — a carga assume um papel federado (OIDC) ou usa service account com token efêmero. Não há chave estática para vazar.
• Segredo dinâmico — o banco entrega credencial com TTL curto por serviço, revogável de forma central.
• Escopo mínimo e usuário por serviço — quando a chave estática for inevitável, expor uma delas deixa de significar expor o ambiente.

O critério para escolher é único e desconfortável: com esta opção, um incidente igual a este ainda expõe uma chave reutilizável? Se a resposta é sim, o plano é paliativo — e quem decide precisa saber disso por escrito.

O que fazer hoje com o dossiê que você tem

1. Liste as credenciais por superfície (build, plataforma, imagem, repo/state, config externa), uma linha por lugar. Credencial em dois lugares são duas exposições.
2. Marque cada linha com a fonte: dado do fornecedor, cálculo seu, ou suposição declarada. Aviso de fornecedor não é prova.
3. Para as expostas, calcule alcance em três saltos — concedido, assumido, lateral (cofre, banco de configuração, repositório de CI).
4. Ordene a rotação por dependência, com o que quebra em cada onda, janela relativa e critério de pronto verificável.
5. Registre a decisão de arquitetura, o risco que fica e o dono de cada lacuna. Credencial órfã é um risco com nome.

Nada disso é resposta a um incidente específico. É o mesmo raciocínio para cofre vazado, .env em imagem, chave no commit ou token de CI exfiltrado — e é por isso que vale ter o documento pronto antes do próximo aviso.