Cloud Intelligence™
Détection d'anomalies de coûts cloud : les enseignements d'incidents réels
L'équipe DoiT a analysé six mois d'incidents de sécurité au sein de sa base clients. La cause première était rarement inédite : presque toujours un identifiant que quelqu'un avait oublié de verrouiller.
Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.
Co-rédigé par les équipes Customer Success et Forward Deployed Engineering de DoiT
About Kendall Wondergem
Senior Director of Customer and Partner Success at DoiT, leading teams that deliver continuous value and exceptional customer experience through our products and services. Over 20 years of experience in management consulting, SaaS, startups, and the cloud.
My personal pageTL;DR : Au cours des six derniers mois, les équipes DoiT sont intervenues sur un nombre croissant d'incidents de sécurité au sein de notre base clients, sur l'ensemble des principaux fournisseurs cloud. L'écrasante majorité remonte à une seule et même cause : un identifiant divulgué ou non restreint — généralement une clé API ou une clé d'accès IAM — qui traînait là où il n'aurait jamais dû se trouver. Certains incidents ont été détectés immédiatement, grâce à DoiT Cloud Intelligence™ Real-Time Anomaly Detection et à des notifications correctement configurées, envoyées à la bonne personne au bon moment. Là où les choses ont mal tourné, les clients ont vu des pics de dépenses allant jusqu'à plusieurs centaines de milliers de dollars avant que quiconque ne s'en aperçoive. Cet article détaille ce que nous avons observé, ce que cela a coûté, et les mesures que vous et votre équipe devriez prendre dès aujourd'hui pour prévenir ces attaques et détecter les incidents en quelques minutes plutôt qu'en plusieurs jours.
Si vous exécutez des workloads sur le cloud public, vous connaissez ce cauchemar, pour en avoir entendu parler ou l'avoir vécu : une clé collée dans un dépôt public, embarquée dans une application mobile ou oubliée dans un pipeline CI que personne n'a audité depuis un an. Quelques jours plus tard, quelqu'un côté finance demande pourquoi la facture cloud compte un zéro de plus. Ce n'est pas une hypothèse : c'est, de très loin, l'incident de sécurité le plus fréquent sur lequel nous intervenons.
Nous avons compilé les données d'incidents consignées par nos Forward Deployed Engineers au cours des six derniers mois pour identifier les tendances qui se vérifient sur une base clients large et variée. Il ne s'agit pas d'un rapport d'éditeur alertant sur des attaques théoriques. C'est ce qui arrive concrètement dans notre file d'intervention, et nous voulons vous aider à éviter la même situation dans votre entreprise.
Incidents de sécurité cloud : les tendances GCP et AWS
Les incidents Google Cloud se ramènent presque entièrement à un phénomène : l'explosion de l'utilisation de l'API Gemini et de Vertex AI au cours de l'année écoulée, et la facilité avec laquelle on laisse une clé API sans restriction quand on développe vite. Nous avons publié un article sur le correctif contre l'abus de clés API Gemini ici. Les incidents AWS suivent un schéma plus classique : des clés IAM divulguées transformées en abus de ressources de calcul, plus une poignée de prises de contrôle de comptes pures et simples. Sur les deux plateformes, la cause première n'était presque jamais une vulnérabilité de la plateforme. C'était presque toujours quelque chose qu'un humain avait fait — ou omis de faire — avec un identifiant.
Incidents de sécurité GCP : les clés API divulguées, cause n°1
| Cause première | Part |
|---|---|
| Clés API divulguées ou non restreintes (Gemini, Vertex, AI Studio) | 77 % |
| Clé de compte de service divulguée utilisée pour du minage de cryptomonnaies ou des flottes Compute Engine non autorisées | 19 % |
| Détournement de session ou de compte admin menant à une manipulation de la facturation ou à l'exclusion des administrateurs | 2 % |
| Exfiltration de données via un compte de service compromis | 2 % |
La première ligne concentre presque tout. 77 % des incidents GCP observés ces six derniers mois se résument à une clé API — souvent une clé navigateur Firebase ou une clé Maps/Gemini embarquée dans du code côté client — sans restriction de référent HTTP, sans restriction d'IP et sans limitation de périmètre d'API. Les attaquants scannent les dépôts publics et les bundles frontend exposés à la recherche de ce schéma précis, et dès qu'ils trouvent une clé fonctionnelle, ils pointent des scripts automatisés vers la Generative Language API et laissent tourner. Nous avons vu ces incidents aller de quelques centaines de dollars à plus de 200 000 $ de frais Gemini non autorisés, générés en quelques heures.
Le deuxième groupe, les clés de comptes de service divulguées, se déroule différemment mais commence de la même façon : une clé longue durée dans un dépôt GitHub, une config CI/CD ou le portable d'un développeur. Une fois en sa possession, l'attaquant ne fait pas grimper la facture d'API : il lance du compute. Dans un cas traité par nos équipes, une clé de compte de service GitLab CI divulguée a permis à un attaquant de lancer plus de 10 500 VM de minage de cryptomonnaies dans un seul projet GCP en une nuit. Et les demandes de remboursement auprès du fournisseur cloud ne sont pas toujours acceptées. C'est le point sur lequel il faut s'attarder : les fournisseurs cloud se montrent de plus en plus stricts sur les avoirs liés aux dépenses incontrôlées, surtout pour les incidents récurrents ou évitables. Le confinement et la prévention comptent plus qu'avant, car le filet de sécurité d'une contestation de facturation n'est plus garanti.
Incidents de sécurité AWS : clés IAM divulguées et prises de contrôle de comptes
| Cause première | Part |
|---|---|
| Clé d'accès IAM divulguée ou non restreinte (postes de développeurs, CI/CD, code) menant à une utilisation non autorisée d'EC2, ECS, Fargate ou Bedrock | 56 % |
| Prise de contrôle du compte root ou d'une session admin menant à une manipulation de la facturation ou à l'exclusion des administrateurs | 15 % |
| Workload ou application compromis (service exposé, trust policy mal configurée) menant à un déplacement latéral ou à une exfiltration de secrets | 15 % |
| Abus de plateforme via des comptes clients compromis, phishing ou spam envoyés via Amazon SES | 7 % |
| Attaque DDoS ou attaque réseau sans compromission d'identifiants | 7 % |
Le tableau AWS ressemble à ce que nous observons sur GCP : les identifiants divulgués représentent plus de la moitié du total. Des clés d'accès IAM divulguées depuis des postes de développeurs ou des pipelines CI se transforment en flottes EC2 ou Fargate non autorisées faisant tourner des mineurs de cryptomonnaies, ou, de plus en plus souvent, en appels non autorisés à l'API Bedrock qui accumulent des frais d'inférence de modèles.
Les cas de prise de contrôle du compte root sont ceux qui devraient le plus inquiéter les responsables sécurité, car ils sont les plus difficiles à réparer. Lors d'un incident, un attaquant a réinitialisé le mot de passe du compte root AWS d'un client, enregistré son propre appareil MFA et complètement bloqué l'accès des véritables administrateurs. De là, il a exécuté des appels massifs à l'API Bedrock, générant plus de 500 000 $ de frais avant la récupération du compte. La reprise a nécessité de travailler directement avec AWS pour revérifier la propriété du compte et reconstruire les accès de zéro. Aucune alerte de détection d'anomalies ne sera jamais assez rapide si les personnes censées y répondre ne peuvent pas accéder au compte.
Nous avons aussi observé un groupe plus restreint mais bien réel de compromissions au niveau des workloads : un load balancer exposé sur Internet donnant accès à un pod, une trust policy OIDC mal configurée, et un attaquant se déplaçant latéralement pour exfiltrer des milliers de secrets depuis Secrets Manager. Ici, il s'agit moins d'une clé divulguée que de la dette accumulée d'une configuration réseau et IAM trop permissive.
Compromission d'identité : phishing, abus OAuth et prise de contrôle de comptes
Les incidents restants suivaient un schéma différent, mais apparenté : des campagnes de phishing récoltant des identifiants, ensuite utilisés pour détourner des comptes et envoyer du spam via une identité d'expéditeur compromise, ou pour pivoter vers des outils tiers connectés via OAuth. Le compte Workspace compromis d'un client a servi à ajouter des liens de gestionnaire non autorisés à son compte Google Ads et à accumuler près de 50 000 $ de dépenses publicitaires frauduleuses. Chez un autre, l'identifiant d'un employé a été utilisé pour accorder un accès OAuth à des outils tiers, entraînant des achats non autorisés.
Le fil conducteur sur toutes les plateformes : le point faible n'était pas l'infrastructure du fournisseur cloud. C'était l'identité.
La facture, c'est la fumée — pas l'incendie
Il est tentant de considérer le pic de coûts comme le problème. Pourtant, ce pic est souvent le premier symptôme visible d'une compromission d'identifiants. Corrigez la facture et vous aurez traité le symptôme. Corrigez l'hygiène de vos identifiants et prenez la détection d'anomalies au sérieux, et vous traiterez la cause première.
C'est pourquoi notre recommandation comporte deux volets indissociables : une revue de posture qui comble les failles avant qu'elles ne soient exploitées, et une surveillance qui détecte rapidement l'exploitation si une faille passe malgré tout.
Comment prévenir les incidents de sécurité cloud : combler les failles
La recommandation de DoiT s'articule en deux volets :
Étape 1 : passez en revue votre posture de sécurité cloud
La plupart des incidents ci-dessus auraient pu être évités grâce à des pratiques figurant dans toute revue standard de posture de sécurité cloud : restreindre les clés API à des référents ou plages d'IP spécifiques, effectuer la rotation et le retrait des clés de comptes de service longue durée, remplacer les identifiants statiques par la fédération d'identité de workload ou des jetons de courte durée partout où c'est possible, imposer la MFA et des limites de durée de session au niveau du fournisseur d'identité, et restreindre strictement qui peut créer ou utiliser des liaisons IAM de niveau propriétaire. Rien d'exotique là-dedans. C'est le travail ingrat et sans éclat de l'hygiène des accès — et c'est précisément le travail dont l'absence revient incident après incident.
Étape 2 : configurez la détection d'anomalies de coûts cloud et les notifications
DoiT Cloud Intelligence™ Real-Time Anomaly Detection (disponible dans nos offres Enhanced et Enterprise) est conçue précisément pour la faille qui revient dans presque tous les incidents de ce jeu de données : le délai entre le moment où quelque chose tourne mal et celui où quelqu'un s'en aperçoit. La plupart des outils basés sur la facturation détectent un pic de dépenses des heures, voire des jours après coup, car ils lisent des exports mis à jour avec retard. Real-Time Anomaly Detection lit directement les données d'utilisation en temps réel, croisées avec les historiques de dépenses, et peut signaler une activité inhabituelle en quelques minutes, pas en plusieurs jours. Chaque alerte s'accompagne d'un score de sévérité et d'une analyse générée par IA du service, du SKU et de la ressource concernés, pour que votre équipe ne démarre pas l'enquête de zéro.
Pour les clients de notre offre Essentials, notre détection d'anomalies cloud prête à l'emploi peut et doit être configurée, avec des notifications adaptées pour identifier et signaler les anomalies. Pour passer à Real-Time Anomaly Detection, contactez votre Account Manager DoiT ou soumettez un ticket via Expert Inquiry dans la console DoiT.
Pour tirer le meilleur parti de votre détection d'anomalies :
- Vérifiez que les notifications d'anomalies sont configurées pour les bonnes personnes, via les bons canaux, au bon moment. Les notifications d'anomalies de coûts nécessitent la permission Cloud Analytics et, par défaut, elles sont envoyées aux Admins, Power Users, Finance Users et Standard Users — mais vérifiez qui, dans votre équipe, les a réellement configurées, et que chacun comprend l'importance d'y répondre rapidement.
- Ne vous arrêtez pas au seuil de sévérité par défaut. Si votre organisation exécute des workloads à forte vélocité (CI/CD, inférence GenAI, flottes en autoscaling), ajustez votre cadence de revue pour qu'une anomalie de sévérité moyenne survenue à 2 h du matin soit examinée avant le lendemain matin.
- Sollicitez votre Customer Success Manager DoiT pour configurer (ou valider) votre détection et vos notifications. Les CSM de DoiT se feront un plaisir de vous aider et peuvent apporter le regard expert nécessaire pour garantir une configuration correcte.
- Configurez des notifications pour les pics de dépenses et l'utilisation de nouveaux SKU. La détection d'anomalies sur les nouveaux SKU est sous-utilisée alors qu'elle est essentielle : elle vous prévient dès que votre organisation commence à utiliser un service ou un SKU jamais utilisé auparavant — exactement ce qui se produit quand un attaquant muni d'une clé volée se met à solliciter la Generative Language API ou à lancer de l'inférence Bedrock pour la première fois. Un nouveau SKU légitime apparaît de temps en temps quand votre équipe livre une nouveauté. Un SKU inexpliqué qui surgit à un moment inattendu mérite un examen immédiat.
- Envisagez de configurer des notifications sur l'épuisement des quotas ou l'utilisation des crédits. Bien que conçu pour un autre type de défaillance, ce dispositif complète le tableau des comportements inattendus dans vos dépenses.
- Envisagez d'utiliser des automatisations. Configurez DoiT Cloud Intelligence™ CloudFlow pour qu'il se déclenche sur les anomalies de coûts. Vous pouvez automatiser des tâches de mitigation d'incidents : publication dans Slack, création de tickets ou exécution d'étapes de remédiation. Vous ne savez pas par où commencer ? Votre Customer Success Manager DoiT peut organiser une session de travail avec un Forward Deployed Engineer DoiT pour créer vos CloudFlows.
Pour en savoir plus sur la configuration de la détection d'anomalies et des notifications, consultez la documentation d'aide DoiT sur la détection d'anomalies et les notifications, ou contactez votre Customer Success Manager DoiT.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Faites-vous accompagner par des experts en détection d'anomalies de coûts cloud
Si vous êtes client de nos offres Enhanced ou Enterprise, contactez votre Customer Success Manager ou votre Account Manager DoiT pour planifier une revue de posture de sécurité et/ou mettre en place une stratégie robuste de détection et de réponse aux anomalies. Vous ne savez pas qui est votre CSM/AM ? Connectez-vous à DoiT Cloud Intelligence™, cliquez sur l'icône d'engrenage en haut à droite et sélectionnez "Account Managers".
Si vous êtes client de notre offre Essentials, soumettez un ticket via la console (ouvrez le menu et sélectionnez "Get expert advice") : un Customer Success Manager pourra vous aider à configurer ou vérifier votre configuration d'anomalies et de notifications, et vous donner plus de détails sur une revue de posture de sécurité en autonomie ou menée par DoiT.
Check-list de réponse aux incidents de sécurité cloud
Si un incident survient dans votre environnement, voici l'ordre des opérations que nous recommandons, fondé sur notre expérience des incidents rapidement maîtrisés :
- Révoquez d'abord l'identifiant. Supprimez ou effectuez immédiatement la rotation de la clé API ou de la clé d'accès IAM compromise. N'attendez pas d'avoir cerné toute l'étendue des dégâts pour agir. Chaque heure où elle reste active, c'est plus de dépenses et plus d'exposition.
- Stoppez l'hémorragie au niveau des ressources. Mettez fin aux VM, instances et flottes de calcul lancées par l'attaquant. Si les dépenses grimpent plus vite que vous ne pouvez supprimer les ressources en toute sécurité, détacher le compte de facturation du projet concerné est un frein d'urgence légitime.
- Préservez les logs avant de tout nettoyer. Les logs d'audit et les VPC Flow Logs seront indispensables à votre fournisseur cloud et à votre propre équipe, tant pour l'analyse des causes que pour toute contestation de facturation. Effectuer la rotation de tous les identifiants et détruire toutes les ressources avant que quiconque n'ait extrait les logs complique considérablement l'enquête.
- Ouvrez un dossier auprès de votre fournisseur cloud. Pour les dépenses non autorisées, la plupart des fournisseurs disposent d'un processus de contestation des frais liés à une compromission avérée. Restez réaliste : les fournisseurs sont devenus plus stricts sur ces avoirs, surtout pour les incidents récurrents ou évitables — ne considérez donc jamais une demande d'avoir comme acquise.
- Impliquez DoiT. Soumettez un ticket via la console (ouvrez le menu et sélectionnez "Get expert advice") ou écrivez à votre Customer Success Manager. Plus nous sommes impliqués tôt, plus nous pouvons vous aider : conseils de confinement, escalade auprès du fournisseur, et vérification que la même faille ne se rouvre pas.
- Comblez la faille une fois l'incident maîtrisé. Un incident est un déclencheur : profitez-en pour planifier cette revue de posture que vous repoussez depuis trop longtemps.
FAQ
Qu'est-ce que la détection d'anomalies de coûts cloud ?
La détection d'anomalies de coûts cloud est une surveillance qui signale les schémas de dépenses ou d'utilisation inhabituels — un nouveau SKU, un pic inattendu, un service inconnu — au moment où ils se produisent, plutôt que d'attendre que la facture mensuelle les révèle. DoiT Cloud Intelligence™ Real-Time Anomaly Detection lit directement les données d'utilisation en temps réel et peut donc signaler une activité en quelques minutes, contre plusieurs heures ou jours pour les outils basés sur les exports de facturation.
Que se passe-t-il en cas de fuite d'une clé API ?
Dès qu'une clé API sans restriction de référent HTTP, d'IP ou de périmètre est exposée — dans un dépôt public, une application mobile ou une config CI —, les attaquants la trouvent généralement en quelques heures grâce au scan automatisé et pointent immédiatement des scripts vers des API facturables comme la Generative Language API ou Bedrock. Dans les incidents que nous avons suivis, les montants allaient de quelques centaines de dollars à plus de 200 000 $ de frais non autorisés générés en quelques heures.
Comment survient une prise de contrôle de compte cloud ?
La plupart des prises de contrôle que nous observons commencent par un identifiant hameçonné ou réutilisé, pas par une vulnérabilité de la plateforme. L'attaquant réinitialise un mot de passe, enregistre son propre appareil MFA et bloque l'accès de l'administrateur légitime — puis utilise cet accès pour accumuler des frais de calcul ou d'inférence de modèles, ou pour manipuler la facturation. C'est le type d'incident le plus difficile à réparer, car les personnes censées y répondre ne peuvent plus accéder au compte.
AWS ou Google Cloud remboursent-ils les frais non autorisés issus d'une fuite d'identifiants ?
Ni automatiquement, ni systématiquement. Les deux fournisseurs disposent d'un processus de contestation pour les frais liés à une compromission avérée, mais ils sont devenus plus stricts dans l'attribution des avoirs, surtout pour les incidents récurrents ou évitables. Considérez le remboursement comme possible, pas garanti — la prévention et le confinement rapide comptent plus que le filet de sécurité d'une contestation de facturation.
Quelle est la première chose à faire en cas de suspicion de fuite d'identifiants ?
Effectuez la rotation de la clé compromise ou supprimez-la immédiatement, avant même d'avoir cerné toute l'étendue des dégâts — chaque heure où elle reste active accroît l'exposition. Stoppez ensuite l'hémorragie au niveau des ressources (mettez fin aux instances malveillantes, ou détachez la facturation comme frein d'urgence), et préservez les logs d'audit avant tout nettoyage : vous en aurez besoin pour l'analyse des causes et toute contestation de facturation.
En combien de temps la détection d'anomalies de coûts cloud repère-t-elle une clé compromise ?
Avec une détection en temps réel configurée pour alerter sur l'utilisation de nouveaux SKU et sur les pics de dépenses avec score de sévérité, les équipes peuvent repérer une clé compromise dans les minutes suivant sa première utilisation. La détection d'anomalies standard, fondée sur les exports de facturation, accuse généralement un retard de plusieurs heures à plusieurs jours — précisément la fenêtre qui, dans nos données, a transformé des incidents mineurs en incidents à six chiffres.
