Chaves de API do Google continuam válidas por até 23 minutos após exclusão, alerta Aikido Security

Chaves de API do Google permanecem válidas e autenticáveis por até 23 minutos depois de serem deletadas via console do GCP, com janela mediana de 16 minutos, segundo testes da Aikido Security divulgados nesta semana — comportamento que afeta credenciais escopadas para Gemini, BigQuery, Maps e demais APIs do Google Cloud Platform, e que a empresa classifica como “propriedade conhecida do sistema” e não como problema de segurança.

O que aconteceu

Pesquisadores da Aikido Security executaram dez ciclos controlados de criação, exclusão e tentativa de autenticação contra a infraestrutura de chaves de API do Google. Em cada ciclo, a equipe gerava uma chave, removia o recurso via console do GCP e disparava de três a cinco requisições autenticadas por segundo até que o servidor finalmente passasse a rejeitar a credencial. O resultado foi consistente: a chave continuava aceita após o que a interface descreve como exclusão imediata.

A janela observada variou, mas nunca foi inferior ao que se esperaria de uma revogação em tempo real. O atraso máximo registrado foi de 23 minutos; a mediana, 16 minutos. Os pesquisadores também voltaram aos mesmos cenários semanas depois para descartar transientes de rede como explicação, e a métrica permaneceu estável — sinal de que se trata de comportamento estrutural, não de incidente pontual.

Por que a chave continua viva

O Google Cloud opera em larga escala um modelo de consistência eventual: alterações como exclusão de credenciais propagam gradualmente entre servidores de autenticação espalhados globalmente, não atomicamente. Para a maior parte das operações de catálogo de recursos, esse trade-off é aceitável e até desejável — reduz latência e melhora resiliência. Para revogação de credenciais, porém, ele cria um intervalo durante o qual a chave “oficialmente excluída” continua autenticando chamadas reais.

“Em cada ensaio, criamos uma chave de API, a excluímos e enviamos de três a cinco requisições autenticadas por segundo até que nenhuma resposta válida fosse retornada por vários minutos”, relatam os pesquisadores da Aikido. “Para completar, repetimos as observações semanas depois para confirmar que o comportamento não era resultado de problemas transitórios de rede.”

A confusão é agravada pela própria interface: o diálogo de exclusão do GCP afirma que a chave “não poderá mais ser usada para fazer requisições à API”, mensagem que entra em contradição com o que os testes demonstram. Não existe, segundo a Aikido, mecanismo no console para confirmar quando a chave realmente parou de responder, nem qualquer botão para acelerar a propagação.

O comportamento é uma propriedade do tipo de credencial, não do escopo. Os pesquisadores observaram a mesma janela com chaves restritas a Gemini, a BigQuery e a Google Maps. Em contraste, chaves de Service Account são revogadas em torno de 5 segundos, e o novo formato de chave de API específico para Gemini cai em aproximadamente 1 minuto — evidência de que revogação rápida é tecnicamente viável na escala do Google quando existe vontade arquitetural para isso.

Quem é afetado

Equipes de resposta a incidentes que dependem de exclusão imediata da credencial para conter exfiltração — o que assume incorretamente que o atacante perde acesso assim que a chave é deletada.
Organizações que rotacionam chaves de API automaticamente em pipelines de SOAR ou EDR após detecção de vazamento.
Times de SecOps que tratam exclusão de chave como evento de “corte” em playbooks de contenção.
Aplicações que conectam Gemini, BigQuery, Maps e demais APIs do GCP via API keys (em vez de Service Account ou Workload Identity).
Auditorias de compliance que documentam revogação como instantânea sem janela de tolerância.

Análise

O problema descrito pela Aikido é menos sobre uma vulnerabilidade técnica e mais sobre o gap entre o modelo mental que defensores constroem em cima de UIs e o comportamento real do sistema distribuído por trás. Quando o console diz “a chave foi excluída”, a expectativa razoável é uma propriedade booleana: a credencial vale ou não vale. Em sistemas de larga escala como o GCP, essa booleano se traduz em uma probabilidade que cai conforme a propagação avança — o tipo de detalhe que normalmente fica enterrado em documentação de arquitetura interna.

O paralelo evidente é com o sistema de tokens da AWS antes da introdução do IAM Identity Center, onde credenciais comprometidas podiam permanecer ativas por minutos mesmo após exclusão dos usuários — comportamento que motivou a maioria das organizações maduras a abandonarem chaves de longa duração em favor de credenciais efêmeras assumidas por papel. A recomendação se aplica diretamente ao GCP: Service Accounts via Workload Identity Federation, com tokens de curta duração e revogação rápida, mitigam tanto a janela de exclusão quanto o risco de vazamento.

A postura do Google de tratar o comportamento como “propriedade conhecida do sistema” é defensável tecnicamente, mas problemática operacionalmente. Em um cenário de breach ativo — credencial vazando no GitHub, sendo abusada por um atacante em tempo real para criar instâncias de mineração ou exfiltrar dados via Gemini — 23 minutos de janela é exatamente o intervalo em que um time de SOC bem treinado planeja seu corte. Documentar a propriedade no diálogo de exclusão, ou expor uma API para confirmar revogação efetiva, seria avanço razoável independente da arquitetura de fundo.

Recomendações práticas

Tratar exclusão de chave de API do Google como operação assíncrona com janela de até 30 minutos — adicionar essa expectativa explicitamente em runbooks de IR.
Após excluir uma chave suspeita, monitorar uso da API no console GCP em “APIs e serviços habilitados” durante 30 a 45 minutos.
Migrar autenticação de aplicações de API keys para Service Accounts com Workload Identity Federation sempre que viável — revogação cai para faixa de 5 segundos.
Para casos em que a chave precisa ser cortada agora, combinar exclusão com restrição de IPs no nível da chave, restrição de aplicação, e quota=0 para forçar bloqueio mesmo durante a janela de propagação.
Implementar detecção de uso anômalo (volume, geografia, padrão de API) em vez de depender exclusivamente do controle de credencial.
Documentar essa propriedade em training para SOC e DFIR — não assumir cortes instantâneos.
Para chaves voltadas a Gemini, considerar migração para o novo formato específico de Gemini API key, com revogação na faixa de 1 minuto.

Fonte: Help Net Security