tl;dr Quando você exclui uma chave de API do Google, é informado que ela é excluída imediatamente. Nossos testes indicam ~23 minutos. Durante essa janela, um invasor com uma chave vazada mantém acesso aos seus dados e APIs habilitadas (incluindo Gemini). Você não tem como revogá-la mais rapidamente ou confirmar quando ela para de funcionar. O Google encerrou nosso relatório original como “não será corrigido”.
Atualização em sexta-feira, 22 de maio de 2026: O Google reabriu nosso relatório e está tratando isso como um bug P0.
Ao excluir uma chave de API, você espera que o acesso seja encerrado imediatamente.
As chaves de API do Google não funcionam assim. A revogação se propaga gradualmente pela infraestrutura do Google. Alguns servidores rejeitam a chave em segundos, enquanto outros continuam a aceitá-la por 23 minutos.
Um invasor com sua chave excluída pode continuar enviando requisições até que uma delas atinja um servidor que ainda não foi atualizado. Se o Gemini estiver habilitado no projeto, eles podem extrair arquivos que você carregou e exfiltrar conversas em cache.
O console do GCP não exibirá a chave e não informará que a chave ainda está funcionando. Você está confiando na infraestrutura do Google para que ela seja eventualmente atualizada.
A autenticação não deve ser eventualmente consistente
Muitos dos serviços do Google Cloud são eventualmente consistentes por design. Nesse modelo, as atualizações se propagam gradualmente pelos servidores, em vez de ocorrerem todas de uma vez. Essa compensação permite que o Google escale globalmente e permaneça rápido, e para a maioria dos serviços, o atraso é imperceptível. Mas para a autenticação, essa compensação é mais difícil de justificar.
Atrasos na revogação de credenciais são exploráveis. Há alguns meses, Eduard Agavriloae divulgou um atraso de 4 segundos que permitiu que chaves de acesso AWS excluídas criassem novas credenciais. Quatro segundos foram suficientes para ser relevante na AWS.
Dada a atenção recente às chaves de API do Google usadas para acessar o Gemini, decidimos medir por quanto tempo a janela de revogação de chaves de API do Google permanece aberta.
O que é uma janela de revogação?
A janela de revogação é o tempo entre a exclusão de uma chave e a última autenticação bem-sucedida.
Se a janela for de alguns microssegundos, o comportamento corresponde ao que os usuários esperam. Se for mais longa, cada segundo adicional dá aos invasores mais tempo para usar indevidamente uma chave roubada.
Medindo a janela de revogação
Para medir a janela de revogação de chaves de API do Google, realizamos 10 testes ao longo de dois dias.
Em cada teste, criamos uma chave de API, a excluímos e enviamos 3-5 requisições autenticadas por segundo até que nenhuma resposta válida retornasse por vários minutos.
Escolhemos essa taxa porque não controlamos como o Google roteia nossas requisições para diferentes servidores de autenticação ao redor do mundo. O volume tinha como objetivo rotacionar o maior número possível deles por teste, ainda respeitando a infraestrutura do Google. Não podemos afirmar se uma taxa de requisições mais alta estenderia a janela observada. Um invasor não tem motivos para limitar a taxa como fizemos, então vale a pena notar que nossos números podem não representar o pior cenário.
Para complementar, também fizemos uma verificação pontual do nosso trabalho algumas semanas depois para garantir que o comportamento observado não fosse devido a problemas de rede transitórios.
23 minutos
Ao longo de dez testes, a janela mais longa foi de quase 23 minutos! Esse é um tempo incrivelmente longo para que uma chave excluída ainda autentique com sucesso.
A janela mais curta foi de quase 8 minutos, e a mediana foi de cerca de 16 minutos. Ao longo dos testes, a taxa de sucesso foi altamente imprevisível: um minuto após a exclusão, um teste registrou 79% de sucesso nas requisições, enquanto outro registrou apenas 5%.
Um atacante com uma chave roubada não vê um corte limpo ou uma degradação previsível. O acesso continua funcionando, de forma irregular, até que eventualmente pare.
Rastreando um único teste no console do GCP
Para ilustrar a inconsistência na infraestrutura do Google, monitoramos um de nossos testes usando o gráfico "Tráfego por Credencial" no GCP. A linha inferior (azul) mostra autenticações bem-sucedidas e reflete a duração da janela de revogação.
Não esperávamos ver outros dados, mas uma segunda linha apareceu. A linha superior (verde) exibe requisições rejeitadas e é rotulada como apikey:UNKNOWN. Havíamos (erroneamente) assumido que requisições inválidas seriam simplesmente descartadas sem qualquer atribuição de projeto. Em vez disso, o GCP as inclui neste gráfico.
Para entender melhor o misterioso apikey:UNKNOWN valor, tentamos autenticar com uma chave de API excluída há dias. Surpreendentemente, essas requisições apareceram no mesmo gráfico, agrupadas na mesma apikey:UNKNOWN categoria.
Nossa melhor suposição é que o Google preserva a atribuição de projeto após a exclusão da chave, caso os usuários decidam restaurar a credencial.
Para equipes de IR investigando uma credencial vazada, o apikey:UNKNOWN valor pode ser confuso. Qualquer requisição feita com qualquer chave de API do Google excluída é agrupada na mesma categoria UNKNOWN, dificultando a identificação de quais requisições se relacionam a uma credencial específica. Uma requisição nessa categoria pode significar que um ator de ameaça ainda está tentando autenticar com a chave excluída, ou pode ser um serviço legítimo rodando com uma chave desatualizada e não relacionada.
Se você estiver dentro da janela de revogação de 23 minutos, procure por autenticações válidas usando a chave vazada. Se você estiver fora dessa janela, o risco parece extremamente baixo.
Diferenças regionais na consistência
Executamos o primeiro experimento a partir de um endereço IP residencial na Costa Leste dos EUA. Hipótese: executar um experimento similar em VMs em diferentes regiões do GCP poderia expor inconsistências adicionais.
Configuramos uma VM em três regiões: us-east1, europe-west1, e asia-southeast1. Em seguida, executamos 5 testes. Para cada teste, excluímos uma única chave de API e enviamos requisições de cada uma das três VMs em paralelo.
Duas coisas se destacaram. Primeiro, imediatamente após a exclusão de uma chave, as VMs em diferentes regiões apresentaram taxas de sucesso de autenticação muito distintas. A tabela abaixo mostra a porcentagem de requisições válidas no primeiro minuto por região.
Observe o teste 1: us-east1 82%, europe-west1 60%, asia-southeast1 32%. As VMs mais distantes dos EUA detectaram a exclusão mais rapidamente, o que é o oposto do esperado. Não podemos dizer exatamente o porquê de fora. O roteamento de requisições do Google é mais complexo do que "região da VM é igual à região do servidor", e uma VM em Singapura não está necessariamente se comunicando com servidores em Singapura. Mas o padrão foi consistente em todos os testes, o que aponta para algo relacionado à infraestrutura regional, cache ou afinidade de roteamento impulsionando a diferença.
Segundo, a diferença regional não foi apenas uma questão do primeiro minuto. Ao longo da janela completa, asia-southeast1 teve uma taxa mediana de sucesso de autenticação de requisições de 22%, enquanto us-east1 e europe-west1 ambos ficaram em torno de 49%. A Ásia permaneceu mais baixa minuto a minuto, não apenas no início.
Seja o que for que esteja impulsionando essas diferenças, a localização do servidor claramente molda o comportamento de uma chave excluída após a exclusão.
Outras credenciais do Google
Todos os nossos testes usaram chaves com acesso ao Gemini, mas observamos o mesmo comportamento com chaves com escopo para outras APIs do GCP, como BigQuery e Maps. O atraso é uma propriedade do tipo de credencial, não das APIs habilitadas no projeto.
Para completar, testamos outros dois tipos de credenciais do Google:
- Novas chaves de API Gemini (prefixo AQ.). A exclusão se propagou em ~1 minuto.
- Chaves de Conta de Serviço do Google. A exclusão se propagou em ~5 segundos.
Ambos operam na escala do Google, e ambos revogam muito mais rápido do que os 23 minutos que medimos para as chaves de API do Google.
Divulgação ao Google
Reportamos isso ao Google. O Google encerrou o relatório como "não será corrigido". A posição da equipe, conforme entendemos, é que o atraso na propagação é uma propriedade conhecida do sistema e não um problema de segurança.
Embora o Google documente publicamente que sua API IAM é eventualmente consistente, eles não documentam especificamente esse comportamento para chaves de API do Google.
[Legenda: Captura de tela da página de documentação da API IAM do Google.]
Expectativas do Usuário Quebradas
Sistemas distribuídos na escala do Google são complexos, e esta não é uma crítica à equipe de IAM do GCP. No entanto, uma janela de revogação de 23 minutos está fundamentalmente em desacordo com o que os usuários esperam de um botão de exclusão. A lacuna entre essa expectativa e o comportamento do Google destaca quatro problemas:
1. A interface do usuário é extremamente enganosa.
Ao excluir a chave, o Google a remove da sua visualização e informa: "Uma vez excluída, ela não poderá mais ser usada para fazer requisições de API." Essa afirmação é comprovadamente falsa. O usuário não tem como saber se a chave ainda está ativa, não tem como acelerar a revogação e não tem como confirmar quando ela parou de funcionar completamente.
2. O Google desenvolveu revogação mais rápida para outros tipos de credenciais.
As revogações de credenciais de contas de serviço se propagam em cerca de 5 segundos. O formato mais recente de chave de API do Gemini se propaga em cerca de um minuto. Ambos operam na escala do Google. Ambos sugerem que isso é tecnicamente solucionável também para as chaves de API do Google.
3. Janelas de consistência longas não são compatíveis com autenticação.
A expectativa ao excluir uma credencial é que ela esteja inativa. Mesmo alguns segundos de atraso importam, como a pesquisa da AWS de Eduard mostrou no ano passado.
4. Longas janelas de revogação prejudicam a criação de credenciais Just-in-Time.
Um provedor de serviços que deseja criar dinamicamente chaves de API do Google precisa incorporar um buffer de 23 minutos após a revogação antes que a chave seja garantidamente inativa. Isso é incompatível com a forma como o JIT deveria funcionar.
Contornando a janela
Até que o Google implemente uma revogação mais rápida, a responsabilidade de fechar essa lacuna recai sobre os usuários. Duas coisas ajudam.
1. Trate a exclusão de chaves como uma operação de 30 minutos, não instantânea.
Se você estiver respondendo a uma chave de API do Google vazada, assuma que a chave estará ativa por 30 minutos após clicar em excluir. Isso oferece uma pequena margem de segurança além dos 23 minutos máximos que observamos. Planeje o restante da sua resposta a incidentes em torno dessa janela.
2. Monitore o uso durante a janela.
Em "APIs e serviços ativados" no console do GCP, revise as requisições de API por credencial. Se você notar uso inesperado dessa credencial após a exclusão, alguém pode estar explorando-a ativamente.
Grandes janelas de consistência eventual são a escolha de design errada para a revogação de credenciais. Até que o Google mude isso, trate cada exclusão de chave como uma operação de 30 minutos e monitore a janela para uso indevido.
