Même Google ne peut pas suivre ─ La sécurité à l'ère de l'IA est devenue une bataille "à la seconde près"

Même Google est entré dans l'ère de "protéger en courant"

L'IA est à la fois un outil pour augmenter la productivité des entreprises et une nouvelle surface d'attaque pour les responsables de la sécurité. L'IA générative, les agents internes, les données d'apprentissage, les invites, les SaaS externes, l'environnement multi-cloud. Autrefois, il suffisait de se concentrer sur les frontières du réseau, les terminaux, les serveurs et la gestion des identités pour la défense, mais maintenant, la cible s'étend à "tout ce que l'IA touche".

Les propos de Francis de Souza, COO de Google Cloud, rapportés par TechCrunch, symbolisent ce changement. Il a souligné que si une entreprise adopte l'IA, la sécurité ne doit pas être ajoutée après coup, mais intégrée dès le début dans la conception de la plateforme. L'usage non autorisé d'outils d'IA externes par les employés, la gestion des données sur plusieurs clouds, l'auditabilité, la gouvernance. Ces enjeux ne concernent plus seulement le département des systèmes d'information, mais deviennent des risques à traiter par la direction et le conseil d'administration.

Ce qui est particulièrement important, c'est que l'adoption de l'IA ne se limite pas à "ajouter de nouvelles fonctionnalités pratiques". Lorsque les agents IA commencent à fonctionner à travers les systèmes internes, ils peuvent exhumer des anciens dépôts de données oubliés, des droits d'accès non mis à jour, des SharePoint abandonnés et des anciens fichiers professionnels. Les données qui n'étaient pas problématiques parce que "personne ne les trouvait" deviennent soudainement visibles grâce à l'IA. En d'autres termes, l'IA découvre rapidement non seulement les attaquants, mais aussi les "lacunes de gestion passées" au sein de l'entreprise.

Les attaques progressent en "secondes", pas en "temps"

De Souza a expliqué que le temps moyen pour passer de la compromission à la prochaine étape de l'attaque est passé de quelques heures à quelques secondes. Cela a une signification extrêmement lourde pour les responsables de la sécurité. Pendant que les humains regardent les alertes, vérifient la situation, rassemblent les parties concernées, prennent des décisions et bloquent manuellement, l'attaque a déjà progressé à l'étape suivante.

Dans ce contexte, la réponse de Google Cloud est la "défense native à l'IA". Au lieu que les humains contrôlent tout directement, les agents IA surveillent, défendent et réagissent initialement, tandis que les humains supervisent. Si les attaques progressent à la vitesse des machines, la défense doit également se déplacer à la vitesse des machines.

Cette approche est rationnelle en soi. Cependant, il y a aussi une grande contradiction. Pour se protéger avec l'IA, cette IA elle-même doit être sécurisée. Les données auxquelles l'IA se réfère, les API appelées par l'IA, les informations d'authentification utilisées par l'IA, le système de facturation qui gère les frais d'utilisation de l'IA. Si ces bases ont des failles, la défense par l'IA devient un nouveau risque plutôt qu'une protection.

L'effondrement des "anciennes hypothèses" révélé par le problème des clés API Gemini

Ce qui est intéressant dans l'article de TechCrunch, c'est qu'il ne se contente pas de présenter les recommandations de sécurité de Google Cloud, mais aborde également les problèmes auxquels Google lui-même est confronté. L'un des points particulièrement remarqués est la série de problèmes de facturation élevés autour de l'API Gemini.

Le problème central est la gestion des clés API de Google Cloud. Pendant de nombreuses années, dans des services comme Google Maps ou Firebase, il n'était pas rare que les clés API soient intégrées dans le code côté client. Pour les développeurs, cela ne signifiait pas nécessairement "publier un mot de passe". Elles étaient parfois traitées comme des clés pouvant être publiées pour l'identification du service et la facturation.

Cependant, lorsque des services d'inférence IA coûteux comme l'API Gemini sont activés dans le même projet, les clés API existantes peuvent être utilisées pour les requêtes IA. Si ces clés restent dans un ancien site Web, un dépôt public ou des paramètres passés, un attaquant peut les trouver et envoyer de nombreuses requêtes à Gemini ou aux modèles de génération d'images et de vidéos, entraînant des coûts énormes pour le compte de facturation du développeur.

Ce n'est pas simplement une question de "développeurs négligents dans la gestion des clés". Car certains développeurs utilisaient les clés conformément aux documents et pratiques courantes de l'époque. Un identifiant considéré comme publiable a ensuite pris un rôle proche de l'authentification pour des services IA coûteux. C'est là que réside la difficulté de la sécurité à l'ère de l'IA. Une conception qui était sûre hier peut devenir dangereuse avec l'ajout de nouvelles fonctionnalités aujourd'hui.

La méfiance envers les "limites" qui ne sont pas des limites

Ce qui a encore renforcé la méfiance des développeurs, ce sont les problèmes liés aux limites d'utilisation et de facturation. Selon un rapport de The Register, certains développeurs de Google Cloud ont reçu des factures allant de milliers à des dizaines de milliers de dollars en raison d'une utilisation non autorisée des API. Dans certains cas, une utilisation mensuelle d'environ quelques dizaines de dollars a grimpé à plus de 10 000 dollars en peu de temps, ou une limite de 250 dollars a été automatiquement augmentée en fonction de l'historique du compte.

La logique de Google est d'éviter l'arrêt du service et de permettre aux clients en croissance d'élargir leur utilisation en douceur. Certes, pour un service légitime dont le trafic augmente soudainement, des limites rigides peuvent être un obstacle. À l'ère de la croissance rapide des applications IA, l'expansion automatique des limites d'utilisation peut améliorer l'expérience des développeurs.

Cependant, dès qu'un usage abusif se produit, cette conception fonctionne dans le sens inverse. Pour un attaquant, cela élargit l'espace pour utiliser plus avec une clé volée. Pour l'utilisateur, cela donne l'impression que "la limite que j'avais fixée ne s'arrête pas". Les réactions les plus fortes sur les réseaux sociaux se concentraient également sur ce point. Les développeurs réclament "une limite qui s'arrête réellement, pas seulement une alerte".

La colère et la peur qui se sont répandues sur Reddit

Sur le subreddit r/googlecloud de Reddit, les publications concernant les factures élevées liées à l'API Gemini et Google Cloud se sont multipliées. Un utilisateur a expliqué que, bien qu'il gère un SaaS B2B et que sa facture Google Cloud soit habituellement d'environ 50 dollars par mois, elle a grimpé à plus de 10 000 dollars en raison des jetons de sortie d'images Veo 3 et Gemini. Il n'utilisait pas ces services dans son produit et a signalé une utilisation abusive à l'assistance de Google, mais on lui a d'abord dit qu'"aucune preuve de fraude n'avait été trouvée".

Dans une autre publication, il est rapporté qu'une ancienne clé API Google Maps a été exploitée après l'activation de l'API Gemini, entraînant une facture d'environ 36 800 euros. Dans les commentaires, on pouvait lire des réactions de surprise telles que "Ce problème aurait déjà dû être signalé, mais le comportement n'a pas encore changé" et "Google Cloud Console me fait peur. Je ne peux pas faire confiance à une clé qui peut générer des dizaines de milliers de dollars".

Un utilisateur se présentant comme une petite entreprise japonaise a également fait état d'un risque de facture d'environ 128 000 dollars en raison d'une utilisation abusive de l'API Gemini, mentionnant même la possibilité de faillite. Dans les commentaires, l'opinion selon laquelle Google devrait offrir un arrêt dur, c'est-à-dire un mécanisme qui arrête effectivement le projet ou l'API une fois un certain montant dépassé, était prédominante. Avec la popularisation des outils de codage IA, plus de développeurs touchent à Google Cloud, ce qui rend irréaliste l'hypothèse que "tout le monde peut protéger parfaitement les clés".

Les réactions sur Reddit incluaient non seulement de la colère, mais aussi des solutions pratiques pour éviter le problème. Des suggestions telles que passer des clés API aux comptes de service ou à des méthodes d'authentification plus restreintes, désactiver l'API Gemini au niveau de l'organisation, séparer les services publics et l'utilisation de l'IA dans des projets distincts, et toujours définir des restrictions d'API, ont été proposées. En d'autres termes, la communauté est devenue un lieu de partage de mesures d'auto-défense tout en critiquant la réponse de Google.

Sur Hacker News, les critiques se concentrent sur la "philosophie de conception"

Sur Hacker News, les discussions ont davantage porté sur la philosophie de conception. Dans un fil de discussion autour de l'enquête de Truffle Security, le fait que les clés API de Google aient longtemps été traitées comme des "identifiants pouvant être publiés", mais soient devenues avec Gemini des clés pour l'utilisation d'IA coûteuse et l'accès aux données, a été critiqué.

Un commentaire a comparé la situation en disant qu'il devrait être possible de placer des limites de dépenses claires, comme 10 dollars ou 100 dollars par clé API. Il a été noté que des plateformes comme OpenAI ou OpenRouter facilitent la gestion des dépenses par clé ou par compte, et que les alertes de facturation de Google Cloud ont un retard, ce qui les empêche d'être un véritable rempart.

De plus, des critiques ont comparé cela à "utiliser un nom d'utilisateur comme mot de passe". Bien sûr, rejeter toute la responsabilité sur Google serait une simplification excessive. L'API Gemini n'est pas activée par défaut pour tous les projets, et le propriétaire du projet doit l'activer. Par conséquent, il est fortement conseillé de séparer les projets, de restreindre les clés et de respecter le principe du moindre privilège.

Cependant, dans l'ensemble, l'opinion dominante est que l'IA a rendu dangereuses les "anciennes pratiques cloud". Les clés supposées publiables, l'inférence IA coûteuse, les données de facturation retardées, les limites d'utilisation automatiquement étendues. Individuellement, ces spécifications peuvent être expliquées, mais combinées, elles deviennent un risque fatal pour les petits développeurs.

Le problème des "23 minutes" qui ne se termine pas même après la suppression des clés

L'enquête d'Aikido Security a soulevé une autre inquiétude. Selon leur vérification, même après la suppression d'une clé API Google, certaines requêtes peuvent continuer à être authentifiées pendant environ 23 minutes. Dans les grands systèmes distribués, il n'est pas rare que les modifications de configuration prennent du temps à se propager à tous les serveurs. Cependant, en ce qui concerne l'expiration des informations d'authentification, ce retard devient du temps d'attaque.

Si un attaquant possède une clé divulguée et que l'utilisateur la supprime précipitamment, il est possible que l'attaquant continue à envoyer de nombreuses requêtes pendant un certain temps. Si l'API Gemini est activée, cela pose non seulement un problème de facturation, mais aussi un risque d'accès aux fichiers téléchargés ou aux contenus de conversation mis en cache.

Ce point est au cœur de la sécurité de l'IA. Dans les ressources cloud traditionnelles, un retard de quelques minutes pouvait être toléré dans certaines situations. Cependant, les requêtes aux modèles IA sont coûteuses et les données sont hautement confidentielles. En quelques minutes, un attaquant peut exécuter de nombreuses inférences. À l'ère de l'IA, l'idée d'une authentification "finalement cohérente" est risquée tant sur le plan des coûts que de la protection des données.

Les recommandations de Google sont correctes. C'est pourquoi elles sont remises en question

Il est important de noter que les recommandations du COO de Google Cloud ne sont pas erronées. Une stratégie IA nécessite des stratégies de données et de sécurité, et l'IA fantôme ne doit pas être laissée de côté. Une posture de sécurité cohérente doit être adoptée à travers le multi-cloud, les SaaS, les partenaires externes et les agents internes. Puisque les attaques se déroulent à la vitesse des machines, la défense doit également utiliser l'IA.

Le problème est de savoir dans quelle mesure les fournisseurs de plateformes peuvent offrir une base sécurisée pour mettre en œuvre ces recommandations correctes. Si l'on dit aux entreprises de "ne pas ajouter la sécurité après coup", le côté cloud doit également éviter que "l'ajout de fonctionnalités IA rende la conception d'authentification et de facturation existante dangereuse".

Cette agitation n'est pas seulement un problème pour Google. C'est un avertissement commun à tous les fournisseurs de cloud, plateformes IA et entreprises SaaS. Lors de l'intégration successive de fonctionnalités IA dans les services existants, les hypothèses de conception passées doivent être systématiquement réévaluées. Les clés pouvant être publiées, les clés utilisées uniquement en interne, les limites de facturation, les portées d'accès aux données, les processus d'expiration, les journaux d'audit, le support. Si l'on réutilise les notions d'avant l'IA telles quelles, cela finira par échouer quelque part.

Ce que les entreprises et les développeurs doivent revoir immédiatement

Les enseignements pratiques tirés de ce problème sont clairs. Premièrement, séparer les projets qui activent l'IA de ceux qui utilisent des interfaces publiques comme Maps ou Firebase. Deuxièmement, définir des restrictions d'API et d'application pour toutes les clés API et désactiver les API inutiles. Troisièmement, vérifier non seulement les alertes de facturation, mais aussi les limites de dépenses ou de quotas qui arrêtent réellement l'utilisation. Quatrièmement, faire l'inventaire des clés restantes sur les anciens sites Web, dépôts ou applications mobiles. Cinquièmement, dans l'utilisation de l'IA, privilégier les comptes de service, OAuth et la conception d'authentification à privilèges minimaux plutôt que les clés API.

Et la direction doit traiter l'adoption de l'IA non pas comme un "outil pratique sur le terrain", mais comme un changement d'infrastructure impliquant des risques financiers et de fuite d'informations. Si la fuite d'une seule clé peut entraîner des factures de plusieurs millions de yens ou la fuite de données confidentielles, cela devient un sujet pour le CISO, l'équipe de développement, le CFO, le service juridique et les réunions de direction.

Le véritable défi de la sécurité IA n'est pas la "différence de vitesse", mais la "conception de la responsabilité"

La sécurité à l'ère de l'IA est effectivement en train de devenir en temps réel. Les attaques sont rapides, et la défense doit l'être aussi. Cependant, le véritable défi ne réside pas seulement dans la vitesse. Qui assume le risque, qui a le pouvoir d'arrêter, ce qui est sûr par défaut, quelle conception prioriser entre éviter les pannes et arrêter les abus. En d'autres termes, la "conception de la responsabilité" est en question.

Même Google avance à tâtons dans cette période de transition. C'est pourquoi il est dangereux pour d'autres entreprises de progresser sans défense dans l'adoption de l'IA. L'IA peut protéger, détecter, automatiser. Avant ces attentes, il