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