Google Clés Cloud exposées : des identifiants simples aux identifiants qui activent IA générative et qui pourraient vous coûter des milliers

Il y a quelques mois, il a changé silencieusement une hypothèse que de nombreux développeurs ont pris pour acquis: les clés API Google Cloud qui ont été placés sur des sites publics pour des charges telles que des cartes ou des vidéos ont cessé d'être simplement des identifiants inoffensifs. Avec l'arrivée de Gemini et la possibilité de permettre l'API de modèles génériques dans les projets, ces clés ont également commencé à fonctionner comme des identifiants qui peuvent autoriser les appels à l'assistant IA et, dans certains cas, aux données privées associées.

Le problème a été souligné par une équipe de recherche qui a suivi l'image publique du code Web : en analysant un instantané représentatif de l'index Internet, ils ont trouvé des milliers de clés Google visibles dans le code client. Cette enquête, publiée par Sécurité des truffes, révèle qu'environ 2 800 clés en direct ont été exposées sur des pages accessibles au public et que dans plusieurs cas ces mêmes clés pourraient invoquer l'API de Gemini. Parmi les résultats figurent les clés utilisées par les institutions financières, les sociétés de sécurité et les entreprises adjudicatrices, et même une clé intégrée dans le web public d'un produit Google.

Traditionnellement, de nombreux Google Les clés Cloud ont été traitées comme non critiques : elles ont servi à identifier la facturation ou à activer des services simples dans le navigateur - comme télécharger Google Maps, insérer des vidéos YouTube ou utiliser Firebase sur une application Web - et étaient convaincues que les limites de référence ou d'utilisation étaient suffisantes. Cependant, lorsqu'un projet active l'API Generative Language, la même clé peut acquérir des privilèges supplémentaires et permettre à quiconque peut exécuter des modèles et accéder à des fonctionnalités qui n'étaient pas auparavant disponibles à partir du code client.

La conséquence pratique est double. D'une part, il y a le risque d'exposition à l'information : les attaques ciblées utilisant la clé peuvent essayer de lire ou de manipuler des données auxquelles le service a accès. D'autre part, et peut-être plus immédiatement pour de nombreuses organisations, il y a le coût économique: les appels à de grands modèles ne sont pas gratuits, et un agresseur qui abuse d'une clé exposée peut causer des factures importantes. Comme le soulignent les chercheurs, la saturation des demandes par rapport à un modèle ayant un contexte général peut donner lieu à des milliers de dollars par jour imputés au compte de la victime.

Les résultats sont basés sur l'analyse d'un ensemble massif de pages Web et ne sont pas un cas anecdotique. Truffle Security a documenté que plusieurs clés étaient en code public depuis des années et, après avoir testé les appels aux terminaux Gemini pour lister les modèles, a confirmé que ces clés fonctionnaient pour le nouveau service. L'enquête a été notifiée à Google et, après un échange de communications, l'entreprise a classé le problème comme une forme d'escalade des privilèges pour un service spécifique.

La réponse de Google, selon les déclarations recueillies par des médias spécialisés, comprenait des mesures techniques et des recommandations opérationnelles: bloquer l'accès des clés fuites à Gemini, émettre des notifications proactives lorsque des fuites sont détectées et ajuster la gamme par défaut des nouvelles clés générées par AI Studio pour être spécifique à Gemini. Ces actions aident, mais ne se substituent pas à une hygiène de sécurité appropriée dans les projets.

Pour les développeurs et les gestionnaires de produits, il s'agit d'une obligation de vérification immédiate. Il est essentiel d'examiner les projets et de vérifier si l'API generative est activée; dans l'affirmative, toutes les clés publiques ou boissons codées doivent être revues et tournées sans délai. En outre, il convient de revoir les autorisations, d'appliquer des restrictions strictes de référence ou de PI dans la mesure du possible et de fixer des limites de quota et des alertes de facturation pour détecter une consommation anormale.

Les outils facilitent la détection des secrets exposés dans les dépôts et les codes publics; les chercheurs eux-mêmes recommandent Truffe comme point de départ pour la numérisation et la recherche de clés accessibles depuis le front ou dans l'histoire de la mission. Il convient également d'examiner les guides officiels de Google sur les pratiques clés de l'API et l'authentification, qui décrivent comment atténuer les risques et mettre en place des contrôles plus fins: Documentation Google Cloud sur les clés API.

Au-delà du nettoyage ponctuel, cela soulève une réflexion plus large sur la façon dont l'évolution des plateformes et des services peut changer la sensibilité de certains appareils techniques. Quelque chose qui a été considéré comme relativement sûr hier - une clé publique utilisée pour charger une carte - peut maintenant devenir un vecteur critique si le même titre commence à autoriser l'accès à l'AI générique ou à des fonctions qui n'avaient pas été prévues. Il est donc essentiel d'examiner les hypothèses, d'appliquer le principe de moins de privilège et de professionnaliser la gestion des secrets.

Dans le domaine opérationnel, mettre en œuvre l'authentification du serveur pour les appels sensibles, utiliser des comptes de service avec des autorisations minimales, et séparer les clés d'utilisation publique de celles qui ont la capacité d'invoquer des API puissantes sont des mesures qui réduisent l'exposition. Il est également recommandé de maintenir des processus automatiques qui surveillent l'apparition de secrets dans le commun ou le front et qui nécessitent la rotation des titres de compétence engagés. La documentation sur la sécurité et les pratiques exemplaires changent avec la technologie; la responsabilité des équipes est de les tenir à jour.

L'incident souligne également l'importance de la collaboration entre les chercheurs et les fournisseurs. La détection et la déclaration responsables par des tiers ont contribué à l'adoption de blocages et de contrôles dans un service en évolution rapide. Pour ceux qui veulent approfondir la recherche originale, le rapport et l'entrée de l'équipe qui a détecté l'exposition sont disponibles sur le blog Truffle Security, qui détaille la méthodologie et des exemples concrets: Analyse de la sécurité des truffes. La couverture médiatique des déclarations de Google et la portée de la recherche dans les médias tels que Calculateur.

Si vous gérez des projets avec des services cloud, ne le laissez pas pour plus tard : vérifiez si votre code client contient des clés visibles, identifiez les autorisations qui possèdent ces identifiants et agissez avec rotation et restrictions. La sécurité n'est pas statique; une clé exposée aujourd'hui peut devenir dangereuse demain par des changements dans les plates-formes et la différence entre un incident mineur et une fuite grave est souvent à la vitesse à laquelle l'exposition est détectée et corrigée.