Sécurité cloud : les erreurs de configuration qu'on trouve
depuis l'extérieur

Une seule commande, sans identifiant, sans compte AWS : aws s3 ls s3://acme-backups --no-sign-request. La réponse tombe en moins d'une seconde : 2024-11-03 prod-db-dump.sql.gz, 2025-02-17 clients-export.csv, une arborescence terraform/ avec ses fichiers d'état. Le bucket n'est dans aucun inventaire, un prestataire l'a créé il y a trois ans pour une migration, et le nom se devinait à partir de la marque. Vue depuis Internet, la sécurité cloud se résume souvent à une liste de ce genre, lisible par quiconque a deviné juste, pendant que la console du compte affiche ses voyants verts.

L'angle tenu ici est celui de quelqu'un qui n'a aucun droit sur vos comptes. Il suffit à trouver beaucoup de choses, parce que le modèle de responsabilité partagée vous laisse la configuration sur les bras et que la configuration finit toujours par se voir de dehors. Un CSPM lit ces réglages depuis l'intérieur du compte, un EASM depuis la place de l'attaquant, et les deux ne trouvent pas les mêmes erreurs.

Le modèle de responsabilité partagée, relu depuis l'extérieur

Les trois grands fournisseurs disent la même chose avec des mots différents. AWS distingue la sécurité du cloud, qui lui revient (matériel, logiciel, réseau, installations), de la sécurité dans le cloud, qui vous revient : système invité et ses correctifs, applications installées, et la configuration du pare-feu fourni par AWS. Microsoft publie une matrice par modèle de déploiement, et trois lignes y restent au client en IaaS, PaaS comme SaaS : les données, les configurations et réglages, les identités. La prose qui accompagne le tableau y ajoute les terminaux et la gestion des accès. Google l'admet noir sur blanc dans sa page sur le shared fate : la plupart des compromissions cloud résultent directement d'une mauvaise configuration, d'où ses blueprints et politiques d'organisation aux réglages sûrs par défaut.

Vu de l'extérieur, cette matrice a une conséquence simple. Un attaquant ne s'attaque presque jamais à la partie du fournisseur : l'hyperviseur d'AWS ou le réseau physique d'Azure sont hors de sa portée. Il travaille dans les lignes marquées "Client". Un bucket public, un rôle IAM trop large, une base Firebase en lecture ouverte, un port 22 exposé à tout Internet : ce sont des choix, ou des absences de choix, qui vous appartiennent contractuellement. Quand l'incident arrive, le fournisseur n'a rien à corriger, et le régulateur le sait. Après la fuite de 2019, l'OCC a infligé à Capital One une amende de 80 millions de dollars pour n'avoir pas mis en place d'évaluation des risques avant de migrer vers le cloud public, pas pour une faille d'AWS.

Les erreurs de configuration de sécurité cloud qu'on exploite sur le terrain

Chaque famille qui suit a produit au moins un incident public et documenté, et la plupart se repèrent sans le moindre droit sur le compte visé. L'ordre n'a rien d'un classement de gravité : c'est celui de la fréquence à laquelle on tombe dessus en partant de dehors.

Le stockage public : S3, Azure Blob, GCS, et les jetons qui donnent tout

C'est l'erreur la plus connue, et elle a évolué. Côté AWS, par défaut, les nouveaux buckets, points d'accès et objets n'autorisent pas l'accès public : un bucket devient public parce que quelqu'un a posé une ACL AllUsers ou une politique avec "Principal": "*" sans condition. Azure interdit l'accès anonyme aux blobs par défaut au niveau du compte de stockage, et il faut le réactiver explicitement. Google Cloud offre le verrou symétrique avec la contrainte d'organisation storage.publicAccessPrevention, qui fait échouer toute requête autorisée via allUsers ou allAuthenticatedUsers.

Le stock de buckets publics existants ne disparaît pas parce que les défauts ont changé, et une URL signée trop généreuse fait aujourd'hui autant de dégâts qu'une ACL ouverte. En septembre 2023, Wiz a révélé que des chercheurs en IA de Microsoft avaient exposé 38 To de données privées via un jeton SAS Azure publié dans un dépôt GitHub. Le lien devait servir à télécharger des modèles open source ; le jeton couvrait le compte de stockage entier en contrôle total, avec une expiration repoussée à 2051. Dedans : des sauvegardes de postes de travail, des clés privées, des mots de passe et plus de 30 000 messages Teams. Commité le 20 juillet 2020, invalidé le 24 juin 2023. Près de trois ans d'exposition, sans un seul bucket "public" au sens des consoles.

Les snapshots et les images machine partagés avec tout le monde

Un snapshot EBS ou une AMI marqués public sont des disques entiers offerts à n'importe quel compte AWS : on les monte, on lit /etc/shadow, les fichiers .env, les clés SSH, l'historique shell. AWS a fini par ajouter deux verrous distincts. Block public access for AMIs est activé par défaut pour les nouveaux comptes et pour ceux qui n'avaient aucune AMI publique au 15 juillet 2023. Block public access for snapshots se règle par Région, n'est pas activé de lui-même, et son mode block all sharingest le seul qui rende privés les snapshots déjà partagés. La documentation prévient que bloquer les snapshots ne bloque pas les AMI EBS-backed : il faut poser les deux réglages, dans chaque Région utilisée.

Les métadonnées d'instance et la SSRF vers 169.254.169.254

Voilà l'erreur qu'on raconte le plus mal. Capital One, mars 2019, n'est pas une histoire de bucket public. D'après le communiqué de la banque, l'accès a eu lieu les 22 et 23 mars 2019 et a touché environ 100 millions de personnes aux États-Unis et 6 millions au Canada, dont 140 000 numéros de sécurité sociale. Cause déclarée : une "configuration vulnerability", signalée par un chercheur externe le 17 juillet. Techniquement, l'analyse de Brian Krebs décrit un pare-feu applicatif mal configuré, forcé par SSRF à relayer des requêtes vers le service de métadonnées de l'instance. Ce service rend les identifiants temporaires du rôle IAM de la machine, et ce rôle pouvait lister tous les buckets et lire chacun de leurs objets.

La réponse d'AWS est arrivée le 19 novembre 2019 avec IMDSv2. Une session s'ouvre par une requête PUT qui renvoie un jeton secret, et ce jeton doit accompagner chaque GET suivant. Une SSRF classique ne contrôle que l'URL d'un GET, et la grande majorité des proxys inverses ouverts ne relaient pas les PUT. Deux garde-fous s'ajoutent : aucun jeton n'est délivré à une requête portant un en-tête X-Forwarded-For, et le paquet de réponse part avec un TTL IP de 1. Azure et Google Cloud avaient pris une autre route dès le départ : leur service de métadonnées exige un en-tête, Metadata: true sur Azure et Metadata-Flavor: Google sur GCP, qu'une SSRF ne peut pas poser sans contrôler aussi les en-têtes. Sur AWS, IMDSv2 ne protège que si IMDSv1 est désactivé. Selon l'AMI, le type d'instance et le chemin de lancement, une instance peut encore accepter les deux : c'est toujours le cas en API ou en CLI avec une AMI sans imds-support v2.0, alors que la console, Amazon Linux 2023 et les types sortis depuis mi-2024 lancent en IMDSv2 seul. Le parc existant, lui, ne change pas tout seul.

Les clés d'accès dans du code public

Une clé AKIA... dans un dépôt GitHub, un jeton de service dans un Dockerfile, une chaîne de connexion Azure commitée par erreur. Le cas Microsoft en est un exemple, mais c'est un phénomène de masse, au point que GitHub bloque désormais par défaut les pushs de secrets reconnus vers les dépôts publics (push protection for users). Ce filet ne couvre ni les formats non reconnus ni l'historique déjà publié. Ce sujet a son propre article sur les fuites de secrets, clés d'API et credentials exposés ; dans le cloud, une clé fuitée court-circuite toutes les autres protections. Peu importe que vos buckets soient privés si la clé qui les lit est dans un commit.

Cognito, Firebase et les back-ends "sans serveur" trop confiants

Un identity pool Cognito peut délivrer des identifiants AWS temporaires à des identités non authentifiées : c'est documenté, c'est le mode invité. Le problème est le rôle IAM qu'on lui attache. S'il peut lister un bucket ou écrire dans une table DynamoDB, n'importe qui avec l'identifiant du pool (qui est dans l'application, donc public) obtient ces droits. Côté Firebase, la documentation elle-même montre la règle ".read": true, ".write": true et précise qu'elle permet à quiconque devine l'identifiant du projet de voler, modifier ou supprimer les données. Elle se teste de l'extérieur en une requête sur https://<projet>.firebaseio.com/.json.

Les groupes de sécurité ouverts à 0.0.0.0/0

Rien de spécifique au cloud, sauf que le cloud le rend trivial : une règle avec source 0.0.0.0/0 se pose en un clic, et l'instance a une IP publique dès sa création. SSH, RDP, une console Redis sans mot de passe, une base PostgreSQL de préproduction. Prowler consacre un contrôle de sévérité haute rien qu'au port 22 (ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_22). De l'extérieur, cette exposition se lit dans les résultats d'un scan de ports ou dans l'index d'un moteur comme Shodan, souvent avant que l'équipe qui a créé l'instance ne s'en souvienne.

Comment on les découvre sans aucun accès

Presque toutes ces erreurs laissent une trace visible depuis Internet. On part de votre nom et de vos domaines, on lit les certificats émis pour vous, et chaque réponse fournit les mots-clés de la requête suivante. C'est le travail décrit dans l'article sur la découverte d'actifs sur une surface d'attaque externe, appliqué aux services de stockage et aux comptes qu'on ne s'attendait pas à trouver.

L'étape pivot tient en quelques commandes, qui sont aussi le test le plus rapide sur votre propre périmètre.

# Enumeration multi-cloud a partir d'un mot-cle (S3, Azure Blob, GCS, Firebase...)
uv run cloud_enum -k acme -k acme-corp

# Un candidat trouve : listing anonyme, sans identifiants AWS
aws s3 ls s3://acme-backups --no-sign-request

# Meme test cote Azure : le conteneur repond-il sans en-tete Authorization ?
curl -s "https://acmeprod.blob.core.windows.net/backups?restype=container&comp=list"

Cette découverte ne dépend pas de votre inventaire, et c'est ce qui la rend efficace. Le bucket créé par un prestataire, le projet Firebase d'une appli événementielle, le compte AWS ouvert par une filiale avec une carte d'entreprise : c'est du shadow IT au sens strict, et aucun CSPM ne le verra puisque personne ne lui a donné les droits de s'y connecter. Les certificats partagés sont une des meilleures façons de remonter ces comptes oubliés, comme le détaille l'article sur Certificate Transparency et le shadow IT.

CSPM ou EASM : deux points de vue sur la même erreur

Deux familles d'outils s'occupent de ces réglages. Un CSPM (Cloud Security Posture Management) se connecte à vos comptes avec un rôle en lecture et compare chaque ressource à un référentiel. Les trois outils open source de référence sont Prowler (AWS, Azure, GCP, Kubernetes et d'autres, environ 1 500 contrôles dont 639 pour AWS dans la version courante), ScoutSuite de NCC Group et CloudSploit d'Aqua Security. Ils trouvent ce qu'on ne voit pas de dehors : une instance encore en IMDSv1, un rôle avec s3:*, un journal CloudTrail désactivé. Un EASM part dans l'autre sens : de vos domaines, sans aucun droit, il reconstitue votre surface d'attaque telle qu'un attaquant la voit, comptes oubliés compris.

Mon avis tranché : les deux sont nécessaires, et l'ordre compte. Commencer par l'extérieur donne la liste des comptes à brancher sur le CSPM. L'inverse, un CSPM impeccable sur trois comptes connus pendant qu'un quatrième héberge un bucket public, est le scénario que je rencontre le plus souvent. Ce qu'un EASM fait, et ne fait pas, est détaillé dans l'article de fond sur la gestion de surface d'attaque externe.

Les réglages qui ferment la porte

Les correctifs sont documentés, gratuits, et pour la plupart applicables au niveau du compte ou de l'organisation plutôt que ressource par ressource. C'est ce niveau-là qu'il faut viser : un réglage par bucket sera oublié au prochain bucket.

# 1. Forcer IMDSv2 sur une instance existante (IMDSv1 refuse alors avec un 401)
aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-endpoint enabled

# 2. Bloquer l'acces public S3 pour TOUT le compte (les quatre reglages)
aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 3. Bloquer le partage public des snapshots EBS et des AMI, Region par Region
aws ec2 enable-snapshot-block-public-access --state block-all-sharing --region eu-west-3
aws ec2 enable-image-block-public-access --image-block-public-access-state block-new-sharing --region eu-west-3

# 4. Azure : interdire l'acces anonyme au niveau du compte de stockage
az storage account update --name acmeprod --resource-group rg-prod --allow-blob-public-access false

Trois précisions que les consoles ne donnent pas. Les quatre réglages Block Public Access de S3 sont indépendants, s'appliquent au compte entier, et S3 retient toujours la combinaison la plus restrictive entre compte et bucket ; AWS recommande d'activer les quatre au niveau du compte. Les blocages pour snapshots et AMI sont régionaux, donc à répéter dans chaque Région où vous avez déjà déployé. Et pour empêcher qu'un administrateur de compte membre ne défasse tout ça, il y a les SCP (service control policies) d'AWS Organizations : elles ne donnent aucun droit, elles bornent le maximum de ce qu'un utilisateur ou un rôle d'un compte membre peut faire, root compris. Une SCP qui refuse s3:PutAccountPublicAccessBlock et ec2:ModifyInstanceMetadataOptions hors d'un rôle d'administration verrouille les réglages ci-dessus. Elles ne s'appliquent pas au compte de gestion, qui doit rester vide de ressources pour cette raison.

Pour la liste complète, ne réinventez rien : les CIS Benchmarks existent pour chaque fournisseur, et les trois CSPM cités les implémentent. En septembre 2026, les éditions courantes sont la CIS Amazon Web Services Foundations Benchmark 7.0.0, la CIS Microsoft Azure Foundations Benchmark 6.0.0 et la CIS Google Cloud Platform Foundation Benchmark 5.0.0. Reste la rotation des clés d'accès, qui n'est pas un réglage mais une discipline : une clé statique qui a fuité reste valable jusqu'à sa révocation, alors qu'un rôle IAM assumé par une instance ou un pipeline n'a pas ce problème.

Le cloud vu par NIS2, le ReCyF et SecNumCloud

La directive NIS2 ne contient pas d'article "cloud", mais son article 21, paragraphe 2 liste dix familles de mesures dont trois au moins sont en jeu ici. Le point (i) impose des politiques de contrôle d'accès et une gestion des actifs : un bucket que vous ne savez pas posséder n'est pas un actif géré. Le point (e) couvre la sécurité de l'acquisition, du développement et de la maintenance des systèmes, donc la configuration des services qu'on achète. Le point (f) exige des procédures pour évaluer l'efficacité des mesures, et une évaluation qui n'a jamais regardé le périmètre depuis l'extérieur n'évalue pas grand-chose. L'obligation d'inventaire est traitée dans l'article sur NIS2 et l'inventaire de la surface exposée.

En France, l'ANSSI a présenté le 17 mars 2026 le Référentiel Cyber France (ReCyF), qui décline les objectifs de NIS2 en mesures proportionnées à la maturité de l'entité. Au moment de la rédaction (septembre 2026), il reste un document de travail, sans version définitive tant que la transposition n'est pas achevée, donc sans valeur contraignante. C'est tout de même la grille par laquelle l'ANSSI lira votre maîtrise des systèmes d'information, cloud compris ; il est décortiqué objectif par objectif dans l'article sur le référentiel ReCyF de l'ANSSI. Pour les données les plus sensibles, le choix du fournisseur pèse autant que le réglage, et la qualification SecNumCloud encadre le prestataire lui-même. Elle muscle la colonne "Fournisseur" du tableau du début et laisse la colonne "Client" telle quelle.

À retenir

• AWS, Microsoft et Google sont unanimes : données, identités et configuration restent au client, en IaaS comme en SaaS. Un attaquant ne travaille que dans ces lignes-là.
• Les deux incidents de référence ont la même forme, celle d'un enchaînement de deux réglages. Capital One 2019 combine une SSRF vers IMDSv1 et un rôle IAM trop large ; Microsoft 2023, un jeton SAS commité sur GitHub avec une expiration en 2051. Aucune console ne les affichait comme "publics".
• La découverte se fait sans aucun accès, en enchaînant mots-clés, Certificate Transparency, CNAME vers les endpoints de stockage et dépôts publics, avant l'énumération avec cloud_enum ou S3Scanner et le test de listing anonyme.
• CSPM et EASM ne voient pas la même chose : l'un lit vos comptes de l'intérieur, l'autre reconstitue ce qu'un attaquant voit, comptes oubliés compris. Commencer par l'extérieur.
• Les correctifs sont gratuits et se posent au niveau du compte ou de l'organisation : IMDSv2 en required, Block Public Access (S3, snapshots, AMI, Région par Région), accès anonyme désactivé sur Azure, storage.publicAccessPrevention sur GCP, SCP pour que personne ne les défasse, CIS Benchmarks pour le reste.
• NIS2 article 21(2) exige gestion des actifs, sécurité de la maintenance et évaluation de l'efficacité : un compte cloud inconnu de l'inventaire ne satisfait aucun des trois.

Si vous voulez savoir ce que votre cloud montre à quelqu'un qui n'a aucun droit dessus, c'est ce que fait le module de surveillance de surface d'attaque de l'EASM own2pwn : à partir de vos domaines, il remonte buckets, endpoints de stockage, services exposés et certificats qui trahissent un compte oublié, en continu et sans accès à vos consoles. Pour tester l'exploitation d'une SSRF ou d'un back-end trop confiant sur un périmètre défini, un pentest web en boîte noire est l'étape suivante.

Questions fréquentes sur la sécurité cloud et les erreurs de configuration