Les buckets cloud mal configurés ont exposé 2,8 milliards d’enregistrements au T1 2026
Au premier trimestre 2026, 2,8 milliards d’enregistrements ont fui via des buckets S3, Azure Blob et Google Cloud Storage mal configurés, et 73 % des buckets exposés appartenaient à des organisations dotées d’une équipe sécurité. La réponse n’est pas un dashboard de plus : ce sont des verrous organisationnels et des garde-fous d’infrastructure as code.
Premier trimestre 2026. Des chercheurs en sécurité recensent 2,8 milliards d’enregistrements exposés par des buckets de stockage cloud mal configurés — principalement AWS S3, Azure Blob Storage et Google Cloud Storage. Le chiffre qui devrait réveiller les DSI n’est pas celui-là, mais celui qui suit : 73 % des buckets exposés appartenaient à des organisations dotées d’une équipe sécurité dédiée. La mauvaise configuration cloud n’est plus un problème de négligence des petites structures — c’est un échec structurel du modèle de responsabilité partagée, y compris chez les entreprises matures.
Et la facture suit. IBM évalue le coût moyen d’une fuite dans le cloud public à 5,17 millions de dollars — sensiblement au-dessus de la moyenne intersectorielle. Le Verizon DBIR classe les erreurs de configuration parmi les causes principales d’exposition de données confirmées dans le cloud. La CISA répète que la majorité des incidents cloud qu’elle traite remonte à une mauvaise configuration côté client, pas à une défaillance du fournisseur.
Pourquoi la porte d’entrée reste ouverte
Le basculement est structurel. Il y a dix ans, un attaquant devait traverser un périmètre, élever ses privilèges, pivoter. Aujourd’hui, une politique IAM trop permissive ou un bucket ouvert signifie que la porte d’entrée est déjà ouverte — l’attaquant n’a qu’à la trouver.
Trois facteurs convergents aggravent la situation. Le premier est la vitesse du DevOps : les équipes privilégient la vélocité de déploiement sur la configuration de sécurité. Le second est la découverte automatisée : les attaquants utilisent des scanners propulsés par IA qui testent des millions de permutations de noms de buckets par jour — company-prod-backups, app-logs-2026, customerdata-analytics — et qui s’appuient sur les logs de transparence des certificats, le DNS et les dépôts GitHub pour énumérer les URL de buckets référencées dans le code. Le troisième est la dérive de configuration : un bucket initialement sécurisé devient public à la faveur d’un changement d’infrastructure.
La conséquence chiffrée : le temps moyen de détection d’un bucket S3 exposé est de 168 jours. Un bucket public, c’est des mois d’exposition silencieuse avant que quiconque ne s’en aperçoive — souvent par un journaliste.
Trois incidents qui racontent le mécanisme
Les cas récents donnent un visage à la statistique.
Un fournisseur de soins européen a laissé un bucket S3 contenant 14 millions de dossiers patients publiquement accessible pendant 18 mois : noms, adresses, numéros d’identification nationaux, diagnostics, historiques de traitement. Sous NIS2, l’organisation encourt jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial.
Une fintech en croissance a stocké des jetons d’authentification et des identifiants d’API bancaire dans un conteneur Azure Blob non chiffré et public. Bilan : 2,3 millions de clients touchés dans 17 pays, et 47 millions de dollars de transactions frauduleuses initiées en 48 heures avec les identifiants exposés.
Un équipementier automobile allemand a exposé des plans CAO propriétaires, des contrats fournisseurs et des informations de prix dans un bucket Google Cloud Storage mal configuré. Des concurrents y ont accédé pendant six mois avant qu’un audit de routine ne le découvre.
Le point commun des trois cas n’est pas la sophistication de l’attaque — c’est la banalité de la cause. Aucun exploit, aucun zero-day : une case mal cochée, un wildcard dans une politique, un réglage qui bascule pendant une refactorisation.
Le cas d’école : un bucket qui bascule en silence
Le scénario le plus fréquent, documenté par les équipes d’intervention, tient en trois lignes. Une politique de bucket S3 bascule de private à public pendant une refactorisation Terraform, un mardi à 2 h 14 du matin. Seize mois de documents d’intégration client — permis de conduire, contrats signés, dossiers KYC — sont indexés par un service d’énumération de buckets avant que l’entreprise ne s’en rende compte.
Les variantes sont tout aussi ordinaires. Un ingénieur colle une politique de confiance trouvée sur Stack Overflow contenant "Principal": {"AWS": "*"} sans condition — n’importe quel compte AWS du monde peut alors endosser le rôle. Un module Terraform fait basculer BlockPublicAcls à false lors d’une mise à niveau, et un bucket de sauvegarde reste public onze mois. Une application OAuth orpheline, installée trois ans plus tôt par un ancien prestataire, conserve une délégation à l’échelle du domaine capable d’usurper n’importe quel utilisateur du tenant.
La leçon est la même partout : la configuration est du code, et elle dérive comme du code — sauf que personne ne la relit après le déploiement.
Ce qu’il faut faire
Le correctif n’est pas un outil de plus, c’est une chaîne de contrôle. L’ordre importe.
- Verrouiller au niveau de l’organisation, pas du bucket. Activez Block Public Access à l’échelle de l’organisation AWS, et ajoutez une SCP qui interdit les principaux wildcards (
"Principal": {"AWS": "*"}). Un bucket ne peut alors pas redevenir public par erreur, quel que soit le compte. - Mettre la sécurité dans la pipeline. Intégrez le scan IaC au CI/CD — Checkov, Terrascan, tfsec — et imposez une revue de sécurité pour tout changement d’infrastructure. Le policy-as-code (Open Policy Agent) refuse le merge d’un bucket public avant qu’il n’atteigne la production.
- Détecter la dérive en continu. AWS Config, Security Hub et Macie (côté AWS), Azure Policy et Defender for Cloud (côté Azure), Security Command Center (côté GCP) scannent les mauvaises configurations en continu et alertent quand un réglage bascule.
- Trier par criticité. Inventoriez l’exposition, corrigez l’impact maximal sous 72 heures, puis durcissez structurellement, puis validez en continu — idéalement tous les mois pour les environnements à risque.
Le tout s’inscrit dans un cadre réglementaire qui n’a plus rien de théorique : NIS2 impose une déclaration sous 24 heures et un rapport détaillé sous 72 heures, avec des amendes allant jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial. La Commission européenne en a déjà fait les frais côté cloud en 2026 — le piratage de son compte AWS a montré que même les institutions échouent au premier échelon de la responsabilité partagée.
Reste le chaînon qui fait encore défaut dans beaucoup d’équipes : le garde-fou au moment du merge. Une SCP qui interdit "Principal": {"AWS": "*"} et un bloqueur d’accès public organisationnel couvrent le présent ; mais c’est la pipeline qui empêche la récidive. Concrètement, un contrôle Open Policy Agent peut refuser le déploiement de toute ressource de stockage dont la politique n’est pas explicitement privée :
deny["bucket public"] {
input.kind == "aws_s3_bucket"
input.resource.acl == "public-read"
}Une règle de trois lignes, branchée sur le CI/CD, fait plus pour votre posture cloud que trois dashboards. C’est le vrai changement de posture : traiter la configuration comme un livrable soumis à revue, pas comme un réglage qu’on découvre après coup.
Verdict
La mauvaise configuration cloud n’est pas un incident de plus — c’est le vecteur dominant de l’exposition de données en 2026, et elle frappe d’abord les organisations qui croient être couvertes parce qu’elles ont une équipe sécurité. Le modèle de responsabilité partagée n’a pas échoué à cause des fournisseurs : il échoue parce que la configuration est traitée comme de l’hygiène, pas comme un contrôle d’ingénierie.
La recommandation est conditionnelle et tranchée : si votre seul contrôle est un dashboard de posture, vous détectez après coup — et en moyenne 168 jours trop tard. Le vrai correctif est structurel : bloqueur d’accès public au niveau de l’organisation, SCP interdisant les principaux jokers, et garde-fou IaC qui refuse le merge de toute configuration publique. Commencez cette semaine par la question que pose tout bon conseil d’administration : quels sont les trois comptes cloud qui portent vos données les plus sensibles, qui les possède, et quand un ingénieur sécurité a-t-il relu leurs politiques IAM pour la dernière fois ? Si vous ne pouvez pas répondre en 48 heures, votre patrimoine cloud a dépassé votre programme de sécurité.