De chave de faturamento para porta de Gemini: o risco crescente das APIs keys expostas no Google Cloud

Há pouco tempo, uma pesquisa de segurança tirou à luz uma falha que revela como um elemento aparentemente inofensivo - as chaves API do Google Cloud - pode se tornar uma porta de entrada em funções avançadas de inteligência artificial e, consequentemente, a dados privados e facturas desorientação. O relatório, publicado por Truffle Security, mostra que milhares dessas chaves estavam visíveis em código cliente em páginas web e, por uma mudança na forma como o Google habilita suas APIs, começaram a funcionar como credenciais para os endpoints de Gemini (a API Generative Language do Google).

Tradicionalmente, as chaves com prefixo "AIza" foram usadas principalmente como identificadores de projeto para fins de faturamento, por exemplo para serviços como mapas embebidos. Truffle Security encontrou cerca de 2.900 chaves expostas publicamente em JavaScript de sites que as utilizavam abertamente. O preocupante não é apenas a exposição: é que quando um projeto ativa a API de Gemini, essas chaves deixam de ser meramente tokens de faturamento e começam a autorizar chamadas à API de geração de linguagem sem que os desenvolvedores o adviertam.

O efeito prático é fácil de explicar e difícil de mitigar após o fato. Um atacante que raspe a web e recolhe uma dessas chaves pode fazer pedidos a Gemini, consumir quota de inferência que será cobrado ao proprietário da chave e, em alguns casos, acessar conteúdos privados através de endpoints como /files e /cachedContents. Ou seja, a mesma chave que antes só figurava em facturas pode agora permitir baixar arquivos subidos ou recuperar dados armazenados em cache.

Além disso, Truffle Security documentou que a criação de uma nova chave API no Google Cloud vem normalmente com uma configuração por defeito muito permisiva: "Unrestricted", o que significa que a chave fica associada a qualquer API ativa no projeto, incluindo Gemini. O resultado, em palavras dos pesquisadores, é que muitas chaves consideradas seguras porque eram usadas apenas para faturamento passaram a atuar como credenciais de Gemini e apareceram na superfície pública.

Este problema é magnifica quando o ecossistema móvel é considerado: a assinatura Quokka realizou um barrido de 250 mil aplicativos Android e encontrou mais de 35.000 chaves únicas do Google incorporadas nesses apps. O panorama completo sugere que não é um caso isolado, mas um padrão de exposição massiva que, com a chegada de APIs de IA, muda o perfil de risco de forma significativa.

Diante da divulgação do relatório, o Google respondeu que estava trabalhando com os pesquisadores para mitigar o problema e que havia implementado medidas proativas para detectar e bloquear chaves filtradas que tentem acessar a API de Gemini. Essa comunicação pública do Google pode ser consultada juntamente com os detalhes técnicos e recomendações na documentação oficial do Google Cloud sobre chaves API e nas páginas que descrevem a sua oferta gerativa: o relatório do Truffle Security, a entrada técnica de Quokka e documentação do Google Cloud sobre autenticação e API gerativa ( API keys e Gerador AI).

Não está claro se estas chaves foram amplamente aproveitadas em ataques direcionados, mas já apareceram relatos anedóticos que mostram o potencial impacto econômico: no Reddit circulou uma publicação onde um usuário afirma ter recebido cargos de mais de 80.000 dólares em 48 horas após o roubo de uma chave do Google Cloud e uso da API de Gemini. Embora esse caso individual não tenha sido verificado publicamente, ilustra o tipo de abuso que preocupa a comunidade de segurança ( ver publicação no Reddit).

A lição aqui é dupla. Por um lado, os riscos associados às chaves API são dinâmicos: uma peça de infraestrutura considerada de baixo risco pode tornar-se crítica quando os serviços vinculados ao projeto mudam. Por outro lado, a higiene de segurança básica — limitação de chaves, restrições por IP ou referrer, e evitar incluir chaves em código cliente ou repositórios públicos — deixa de ser uma recomendação e passa a ser uma necessidade urgente.

Se você gerencia projetos no Google Cloud, você precisa rever suas APIs e serviços já ativados e identificar chaves acessíveis do cliente (JavaScript público, repositórios públicos ou apps móveis). Prioriza a rotação das chaves mais antigas, que são as mais propensas a terem sido implantadas sob práticas prévias menos rigorosas. Por sua vez, limita o seu alcance aplicando restrições sobre quais as APIs podem usá-las e desde que origens podem ser invocadas; a documentação do Google Cloud oferece guias e controles para isso.

Além de ações pontuais, este incidente sublinha a necessidade de vigilância contínua: digitalização de segurança, detecção de comportamentos anormais no uso de APIs e bloqueios automáticos quando se detecta atividade suspeita. Como vários especialistas apontam, a adoção da IA em infra-estruturas cloud agrega novos vetores que não existiam quando muitas destas chaves foram consideradas inofensivas, pelo que a abordagem de “configurar e esquecer” já não funciona.

Em resumo, o que parecia um token de faturamento pode hoje ser a chave de uma API que processa prompts, armazena resultados e dá acesso a conteúdos. Rever projetos, aplicar restrições de uso, rotar e remover chaves expostas e monitorar padrões de consumo são passos imprescindíveis para reduzir a superfície de ataque. Para quem precisar de começar, tanto a análise da Truffle Security como do Quokka e a documentação oficial do Google oferecem pontos de partida claros e técnicos para entender o alcance e remédio: Truffle Security, Quokka e Documentação do Google Cloud.