Mauvaise configuration cloud.

La mauvaise configuration cloud est la principale cause racine des fuites de données : elle survient lorsqu'un administrateur, un modèle d'Infrastructure as Code ou un pipeline CI/CD configure un service en violation des bonnes pratiques. Exemples typiques : buckets d'objets lisibles publiquement, security groups ouverts à 0.0.0.0/0, chiffrement absent, journalisation désactivée, identifiants par défaut ou politiques de confiance IAM trop permissives. Comme les API cloud permettent de déployer à grande échelle, un seul mauvais modèle reproduit le même défaut sur des centaines de comptes et régions.

La fuite Capital One de 2019 est le cas d'école : un pare-feu applicatif mal configuré était vulnérable au SSRF, permettant à l'attaquant d'atteindre le service de métadonnées d'instance EC2 (IMDS), de dérober les identifiants temporaires du rôle du WAF et de s'en servir pour lister et copier les données de plus de 700 buckets S3 — environ 106 millions d'enregistrements clients. Capital One a ensuite payé une amende de 80 millions de dollars à l'OCC américain et réglé un contentieux pour 190 millions. L'IMDSv2 d'AWS (basé sur un jeton de session et à saut limité) durcit directement cette chaîne SSRF-vers-identifiants.

Détection et prévention reposent sur le CSPM, le scan d'IaC (Checkov, tfsec), le policy-as-code (OPA, AWS Config, Azure Policy), l'IAM de moindre privilège, le blocage de l'accès public au niveau du compte et des contrôles de conformité continus reliés aux flux de tickets et de remédiation.

flowchart TD
  A[Modèle IaC / changement manuel] --> B{Réglage non sûr ?}
  B -->|Non| OK[Base conforme]
  B -->|Oui| C[Bucket public / SG ouvert / IAM trop large]
  C --> D[Exposé à Internet ou SSRF]
  D --> E[Attaquant vole données ou identifiants]
  C -. détecté par .-> F[CSPM / scan IaC / policy-as-code]
  F --> G[Remédier + ticket]
  G --> OK