Security · 21/05/2026

Credential Decay in Cloud Environments: Por que deletar não significa revogar

Google API Keys permanecem ativos 23 minutos após exclusão, CISA expôs credenciais privilegiadas no GitHub, e Chromium vaza detalhes de RCE não-patchado. O padrão: operações de revogação em cloud não são atômicas. Arquitetos precisam assumir que credenciais deletadas continuam válidas por período indeterminado.

O que está acontecendo

Três eventos convergem em um padrão perigoso de operações de segurança em cloud:

Evento 1 — Google API Keys (Dark Reading): Um pesquisador descobriu que chaves de API deletadas no Google Cloud Console continuam funcionais por aproximadamente 23 minutos. A plataforma anunciava "deleção imediata", mas o comportamento real é uma revogação assíncrona com janela de propagação não-documentada. Qualquer cliente que capture a chave durante esse intervalo mantém acesso válido.

Evento 2 — CISA GitHub Exposure (Krebs on Security): Um contractor da Cybersecurity & Infrastructure Security Agency manteve um repositório GitHub público contendo chaves AWS GovCloud com privilégios administrativos completos. O repositório incluía documentação interna sobre pipelines CI/CD, arquitetura de deployment e acesso a "número significativo" de sistemas internos da CISA. Mesmo após descoberta e remoção, a questão permanece: por quanto tempo essas credenciais circularam antes de serem revogadas? Qual era o TTL (Time-to-Live) efetivo?

Evento 3 — Chromium RCE Background Execution (BleepingComputer): Google acidentalmente divulgou detalhes de uma vulnerabilidade não-patchada em Chromium que permite execução remota de código via JavaScript executado em background mesmo após fechamento do navegador. Embora não seja diretamente credential-related, demonstra o padrão: operações que deveriam terminar (fechar processo) permanecem ativas em estado oculto.

Insights e Riscos

• Propagação Assíncrona Não-Determinística: Revogação de credenciais em ambientes distribuídos é operação não-atômica. Google Cloud, AWS, Azure implementam mecanismos de cache e replicação que garantem "eventual consistency", não sincronização imediata. O intervalo entre DELETE e revogação efetiva varia por região, serviço e carga.

• Falta de Transparência sobre TTL de Revogação: Nem Google nem a maioria dos provedores cloud publicam SLA explícito sobre "tempo máximo até revogação total de credenciais". Documentação menciona apenas "deleção imediata" — afirmação factualmente incorreta e metodologicamente perigosa.

• Repositórios Públicos Como Vetor Principal: CISA exposure não foi sofisticada; foi negligência operacional. Mas revelou que credenciais com TTL de horas/dias em repositório público = comprometimento efetivo. A revogação posterior é tardia.

• Falta de Auditoria de Uso Pós-Deleção: Plataformas cloud raramente alertam sobre tentativas de acesso usando credenciais deletadas. Sem observabilidade, o gap entre deleção e descoberta de abuso pode ser semanas.

• Impacto em Compliance: SOC2, FedRAMP, HIPAA exigem revogação imediata de credenciais comprometidas. A realidade operacional (23+ minutos de decay) cria não-conformidade estrutural.

O que muda na prática

Para Engenheiro de Segurança

Assuma que qualquer credencial capturada em repositório público, logs ou exposições tem janela de atividade de mínimo 30 minutos mesmo após revogação. Implemente:

• Rotação contínua de secrets (não apenas em resposta a incidentes)
• Monitoramento de uso de credentials deletadas (captura denials esperados)
• Pausa operacional após detecção de exposure: bloqueie o principal/serviço associado independente de revogação, aguarde decay completo

Para Arquiteto de Plataforma

Re-avalie sua threat model para credential lifecycle:

• Nunca assuma revogação instantânea em SLA de segurança
• Implemente camada adicional: verificação de "revogação timestamp" em cada chamada de API crítica (requer overhead de latência)
• Para workloads sensíveis, use short-lived tokens com TTL de minutos, não credenciais persistentes
• Documente explicitamente o "credential decay window" esperado em sua arquitetura

Para DevOps/Ops

Gerenciamento de secrets em repositórios:

• Scanner de secrets (git-secrets, truffleHog) é insuficiente; assume que detecção é imediata
• Após descoberta em repositório público: (1) revogue, (2) aguarde 1 hora antes de assumir revogação efetiva, (3) monitore uso durante decay window
• Implemente rotação automática de credentials em repositórios (mesmo sem suspeita de exposure) com frequência ≤24h
• Para GitHub actions/CI-CD: use OIDC federado, não secrets persistentes

Conclusão direta

A revogação de credenciais em cloud não é operação instantânea—é processo assíncrono com janela de decay não-documentada e variável. Google mantém API Keys ativas 23 minutos; CISA manteve GovCloud keys ativas por semanas em repositório público. O padrão expõe falha entre modelagem de segurança (assume-se revogação imediata) e realidade operacional (revogação distribuída, com propagação eventual).

Antes de migrar workloads sensíveis para arquitetura de short-lived credentials ou federação OIDC, pergunte ao seu provedor: "Qual é o tempo máximo garantido entre DELETE de credencial e impossibilidade total de uso em qualquer região/serviço?" Se a resposta for "deleção imediata", sua threat model está baseada em ficção.

Fontes

[Fonte: Dark Reading] Google API Keys Remain Active After Deletion — API keys funcionam por 23 minutos após exclusão, apesar de plataforma afirmar deleção imediata

[Fonte: Krebs on Security] CISA Admin Leaked AWS GovCloud Keys on Github — Contractor manteve repositório público expondo credenciais privilegiadas e arquivos internos de pipeline CI/CD da agência

[Fonte: BleepingComputer] Google accidentally exposed details of unfixed Chromium flaw — Vulnerabilidade de RCE via JavaScript em background não-documentado expõe falha em operações que deveriam terminar