je me suis réveillé avec une facture de plus de 18 000

Le nuage est quelque peu invisible jusqu’à l’arrivée de la facture. Nous construisons une application, testons une API, laissons un budget configuré et continuons notre vie en pensant que le système nous avertira si quelque chose ne va pas comme prévu. Le problème est qu’avertir n’est pas la même chose qu’arrêter. Et cette différence, qui peut ressembler à une nuance technique, est exactement ce qui différencie un test contrôlé d’une dette énorme lorsqu’une clé est exposée, que quelqu’un l’utilise et que les frais commencent à s’accumuler sans que nous le remarquions.

C’est ce qui, selon lui, est arrivé à Venturaxi, un utilisateur de Reddit qui a raconté son histoire. Selon GRYOnline.pl, il s’est endormi avec une alerte budgétaire réglée à 10 dollars australiens (environ 7,15 dollars américains) et s’est réveillé avec une facture de 25 672,86 dollars australiens dans Google Cloud, soit un peu plus de 18 000 dollars américains au taux de change. L’utilisateur affirme que, dans la nuit, quelque 60 000 requêtes non autorisées ont été effectuées via une clé API qu’il n’a pas pu identifier initialement. L’histoire, il faut le souligner dès le début, vient de son témoignage public et non d’une enquête indépendante.

Une alerte peut retentir alors que la facture continue de s’alourdir

La clé est une nuance que Google explique dans sa propre documentation budgétaire : une alerte budgétaire n’arrête pas la consommation, elle n’envoie des notifications que lorsque certains seuils sont atteints. Autrement dit, il sert à nous informer que la dépense est proche ou dépasse un chiffre, mais il ne fonctionne pas comme un interrupteur qui coupe automatiquement le service. En utilisation normale, cela peut suffire pour réagir à temps. Cependant, dans un scénario avec des demandes automatisées et une clé compromise, le compteur peut continuer à fonctionner même si la notification a déjà été envoyée.

La partie la plus délicate de cette histoire est mieux comprise si l’on laisse un instant de côté le jargon. Une clé API est, concrètement, une clé qui permet à une application de s’identifier auprès d’un service et de dire : je suis ce compte, laissez-moi entrer. Tant qu’elle est bien stockée, elle remplit sa fonction. S’il est exposé, une autre personne peut l’utiliser pour générer des demandes qui seront facturées sur ce compte. Google recommande de protéger ces clés, de les alterner et de les restreindre par domaine ou IP. Venturaxi affirme que la clé utilisée provenait d’une ancienne application de jardinage créée pour sa mère dans Cloud Run.

Il apparaît que c’est l’une des parties les plus confuses de l’affaire. L’utilisateur explique qu’au début, il n’a pas trouvé cette clé dans la liste habituelle des clés AI Studio, bien que Google l’ait indiquée comme source de consommation. Plus tard, selon sa mise à jour sur Reddit, il a réussi à le localiser dans une autre section du tableau de bord Google Cloud grâce au conseil d’un autre utilisateur. La clé correspondait au nom visible, et non à la clé complète, ce qui rendait difficile le suivi.

Le plus frustrant est survenu lorsqu’il a essayé de demander de l’aide. Dans sa publication, il raconte avoir d’abord eu affaire à des agents automatisés, puis à différents membres du support, et plus tard à des gestionnaires d’escalade, sans avoir une seule personne pour suivre le dossier du début à la fin pendant des jours. Il soutient également qu’au fur et à mesure que les demandes se poursuivaient, il a dû insister à plusieurs reprises sur le fait que son compte avait été compromis avant d’obtenir une escalade.

L’autre point délicat se situe au niveau du compte. Venturaxi soutient que son compte de facturation a été automatiquement élevé à un niveau supérieur en fonction de son âge et de son historique de paiement, même si le projet concerné était beaucoup plus récent. Selon l’explication qu’il dit avoir reçue de Google, ce changement répondait à une relation de confiance associée au compte, pas nécessairement au projet spécifique. Le résultat, toujours selon son récit, a été qu’il a pu consommer plus que prévu, sans notification claire ni consentement spécifique.

L’affaire a une longue histoire précisément parce qu’elle n’apparaît pas isolée dans la conversation. Sur Reddit, d’autres utilisateurs affirment avoir vécu des frayeurs similaires avec des frais inattendus, des clés compromises ou des litiges de facturation difficiles à résoudre. Cela ne fait pas de chaque histoire une preuve vérifiée, mais cela nous donne une idée de ce qui pourrait se passer. En même temps, cela permet de comprendre pourquoi le message de Venturaxi a trouvé un écho : il souligne une préoccupation partagée par plusieurs développeurs.

Selon le développeur, la facture de 25 672,86 dollars australiens a fini par être annulée et Google aurait également restitué les 9 800 dollars qui, toujours selon son récit, avaient été distribués en cinq tentatives de recouvrement croissantes. Le résultat économique aurait donc été résolu en leur faveur. Malgré cela, l’utilisateur maintient qu’il n’a toujours pas de réponses claires sur plusieurs points de l’incident : comment la clé a été exposée, ce qui a activé le saut de niveau du compte ou d’où exactement provenait le trafic.

La chose la plus frappante dans cette histoire n’est pas seulement le chiffre, mais aussi la facilité avec laquelle une chose comme celle-ci peut devenir incontrôlable. Nous ne parlons pas d’un déploiement à grande échelle ou d’une immense infrastructure, mais plutôt d’une clé, d’une ancienne application et d’une alerte qui n’ont pas fait ce que de nombreux utilisateurs pouvaient imaginer. Il y a un avertissement pour quiconque travaille avec ces services, même dans de petits tests : il vaut la peine de revoir ce qui reste ouvert, quelles limites sont réelles et quels outils nous informent seulement que le problème est déjà en cours.

Images | Simseo avec Grok | charlesdeluvio

À Simseo | Vous recevez une offre d’emploi de Spotify et une autre de Disney. Ce qui se cache derrière c’est une escroquerie de phishing qui attend