Chaves do Google Cloud expostas: de simples identificadores a credenciais que ativam IA gerativa e poderiam custar milhares

Há alguns meses mudou silenciosamente uma suposição que muitos desenvolvedores davam por sentada: as chaves da API do Google Cloud que se colocavam em páginas web públicas para cargas como mapas ou vídeos deixaram de ser simplesmente identificadores inofensivos. Com a chegada de Gemini e a possibilidade de ativar a API de modelos gerativos em projetos, essas chaves começaram a funcionar também como credenciais que podem autorizar chamadas ao assistente de IA e, em alguns casos, a dados privados associados.

O problema foi evidenciado por uma equipe de pesquisa que rastreou o panorama público do código web: ao analisar uma imagem representativa do índice de internet, encontraram milhares de chaves do Google visíveis em código cliente. Essa pesquisa, publicada por Truffle Security, revela que cerca de 2.800 chaves vivas estavam expostas em páginas acessíveis publicamente e que, em vários casos, essas mesmas chaves podiam invocar a API de Gemini. Entre os achados, há chaves usadas por instituições financeiras, empresas de segurança e empresas de contratação, e até uma chave integrada na web pública de um produto do Google.

Tradicionalmente, muitas chaves do Google Cloud foram tratadas como algo não crítico: serviam para identificar o faturamento ou ativar serviços simples no navegador - como carregar o Google Maps, inserir vídeos do YouTube, ou usar a Firebase em uma app web - e confiava-se em que os limites de referrer ou de uso bastavam. No entanto, quando um projeto ativa a API de linguagem gerativa (Generative Language API), essa mesma chave pode adquirir privilégios adicionais e permitir a quem a possui executar modelos e acessar funcionalidades que antes não estavam disponíveis desde o código cliente.

A consequência prática é dupla. Por um lado, existe o risco de exposição de informação: ataques direcionados usando a chave podem tentar ler ou manipular dados a quem tenha acesso o serviço. Por outro lado, e talvez mais imediato para muitas organizações, está o custo econômico: as chamadas a modelos grandes não são grátis, e um agressor que abuse de uma chave exposta pode provocar facturas importantes. Como os pesquisadores apontam, saturar petições contra um modelo com contexto amplo pode traduzir-se em milhares de dólares diários carregados à conta vítima.

Os achados apoiam-se em análises sobre um conjunto massivo de páginas web e não são um caso anecdótico. Truffle Security documentou que várias chaves tinham estado embebidas em código público durante anos e, após testar chamadas a endpoints de Gemini para enumerar modelos, confirmaram que essas chaves funcionavam para o novo serviço. A pesquisa foi notificada ao Google e, após uma troca de comunicações, a empresa classificou o problema como uma forma de escalada de privilégios para um serviço específico.

A resposta do Google, segundo declarações recolhidas por meios especializados, incluiu medidas técnicas e recomendações operacionais: bloquear o acesso de chaves filtradas a Gemini, emitir notificações pró-activas quando forem detectadas fugas e ajustar o alcance por defeito de novas chaves geradas a partir de AI Studio para serem específicas de Gemini. Estas ações ajudam, mas não são sutitutas de higiene de segurança apropriada nos projetos.

Para desenvolvedores e responsáveis por produtos, isto implica uma obrigação imediata de auditoria. É imprescindível rever os projetos e verificar se a API gerativa está habilitada; se assim fosse, há que revisar todas as chaves públicas ou embebidas em código e rotará-las sem demora. Além disso, é conveniente rever licenças, aplicar restrições rigorosas de referrer ou de IP quando possível, e configurar limites de quota e alertas de facturação para detectar consumos anormais.

Há ferramentas que facilitam a detecção de segredos expostos em repositórios e código público; os próprios pesquisadores recomendam TruffleHog como ponto de partida para digitalizar e encontrar chaves acessíveis do frontend ou em histórias de commits. Também vale a pena rever os guias oficiais do Google sobre práticas de chave API e autenticação, que descrevem como mitigar riscos e configurar controles mais finos: Documentação do Google Cloud sobre chaves API.

Além da limpeza pontual, isso levanta uma reflexão mais ampla sobre como a evolução de plataformas e serviços pode mudar a sensibilidade de certos artefatos técnicos. Algo que ontem se considerava relativamente inocuo — uma chave pública usada para carregar um mapa — pode tornar-se hoje um vetor crítico se a mesma credencial começar a autorizar acesso a IA gerativa ou a funções que não tinham sido antecipadas. Por isso é fundamental rever pressupostos, aplicar o princípio de menor privilégio e profissionalizar a gestão de segredos.

No local operacional, implementar a autenticação do servidor para chamadas sensíveis, usar contas de serviço com permissões mínimas, e separar as chaves de uso público das quais têm a capacidade de invocar APIs poderosas são medidas que reduzem a exposição. Também é recomendável manter processos automáticos que monitorizem o aparecimento de segredos em commits ou no frontend e que obriguem a rotação de credenciais comprometidas. A documentação de segurança e as melhores práticas mudam com a tecnologia; a responsabilidade das equipes é mantê-las por dia.

O incidente sublinha ainda a importância da colaboração entre pesquisadores e fornecedores. A detecção e notificação responsável por terceiros ajudou a adotar bloqueios e controles em um serviço que muda rapidamente. Para quem quiser aprofundar a pesquisa original, o relatório e a entrada da equipe que detectou a exposição estão disponíveis no blog de Truffle Security, que detalha metodologia e exemplos concretos: Análise de Truffle Security. Você também pode consultar a cobertura jornalística que coleta as declarações do Google e o alcance do achado em mídia como BleepingComputer.

Se você gerencia projetos com serviços em nuvem, não o deixe para depois: verifique se o seu código cliente contém chaves visíveis, identifica quais permissões têm essas credenciais e atua com rotação e restrições. A segurança não é estática; uma chave exposta hoje pode tornar-se perigosa amanhã por mudanças nas plataformas, e a diferença entre um incidente menor e uma fuga grave muitas vezes está na rapidez com que se detecta e corrige a exposição.