Points clés
- Les mauvaises configurations cloud sont la première cause d'incidents dans les environnements cloud — responsables de 99 % des incidents selon Gartner (jusqu'en 2025)
- Les types les plus fréquents : buckets de stockage publics, règles de pare-feu trop permissives, journalisation désactivée, MFA non activé sur les comptes cloud
- Les outils CSPM (Cloud Security Posture Management) détectent automatiquement les configurations non conformes — mais nécessitent une équipe pour traiter les alertes
- Verizon DBIR 2024 : les erreurs de configuration cloud représentent 21 % de toutes les violations de données analysées
Les mauvaises configurations des services cloud constituent la vulnérabilité la plus documentée et la plus répandue dans les environnements cloud d'entreprise. Contrairement aux vulnérabilités logicielles qui nécessitent un attaquant sophistiqué pour les exploiter, les erreurs de configuration exposent souvent des données ou des systèmes directement accessibles à toute personne qui sait où chercher — sans attaque particulièrement technique.
Les moteurs de recherche spécialisés comme Shodan, Censys ou GreyNoise indexent en permanence les ressources cloud mal configurées exposées sur Internet. Des buckets S3 publics, des interfaces Elasticsearch sans authentification, des bases de données MongoDB accessibles depuis Internet — ces ressources sont découvertes et exploitées en quelques heures à quelques jours après leur exposition accidentelle.
Les configurations les plus dangereuses
Plusieurs configurations cloud présentent un niveau de risque particulièrement élevé : le stockage objet public (buckets S3, Azure Blob Storage, Google Cloud Storage configurés comme accessibles sans authentification), les règles de pare-feu autorisant l'accès depuis "0.0.0.0/0" (tout Internet) sur des ports sensibles (SSH, RDP, bases de données), l'absence de journalisation (CloudTrail sur AWS, Activity Log sur Azure — l'absence de logs rend la détection et l'investigation post-incident impossibles), et les comptes de service avec des droits d'administration complets (violation du principe de moindre privilège).
Ces configurations dangereuses surviennent souvent dans des contextes précis : lors des déploiements initiaux (configuration rapide pour tester), lors des migrations (paramètres temporaires jamais corrigés), ou lors de l'utilisation d'Infrastructure as Code (IaC) dont les templates contiennent des configurations non sécurisées réutilisées sans révision.
La détection automatisée comme réponse à l'échelle
À l'échelle des environnements cloud modernes — des centaines ou des milliers de ressources déployées — la vérification manuelle des configurations est impossible. Les outils CSPM (Cloud Security Posture Management) automatisent cette vérification en comparant en continu les configurations déployées avec les politiques de sécurité définies par l'organisation. Ils génèrent des alertes lorsqu'une déviation est détectée et peuvent, dans certains cas, corriger automatiquement les configurations non conformes.
Ces outils sont nécessaires mais insuffisants : ils génèrent des alertes qui doivent être triées et traitées par des équipes. Sans processus et ressources pour traiter les alertes CSPM, ces outils deviennent une source supplémentaire de fatigue d'alerte sans réduction réelle du risque.
La prévention par l'Infrastructure as Code sécurisée
L'Infrastructure as Code (IaC) — le déploiement d'infrastructure cloud via des fichiers de configuration (Terraform, CloudFormation, Bicep) — permet d'intégrer la sécurité dès la définition de l'infrastructure. Des outils comme tfsec, Checkov, ou Semgrep analysent les fichiers IaC avant déploiement pour identifier les configurations non sécurisées. Cette approche "shift left" permet de détecter les problèmes de configuration avant qu'ils ne soient déployés en production.
Le NIST a intégré les pratiques de sécurisation de l'IaC dans ses guidelines sur le développement sécurisé (SSDF), reconnaissant que l'infrastructure cloud est désormais du code qui doit être soumis aux mêmes pratiques de revue et de test que le code applicatif.
UpGuard a découvert que des portails Microsoft Power Apps (outil de développement d'applications low-code) étaient configurés par défaut pour exposer publiquement leurs données. Plus de 38 millions d'enregistrements contenant des informations personnelles d'entités gouvernementales et d'entreprises (American Airlines, Ford, J.B. Hunt Transport, Maryland Department of Health) étaient accessibles sans authentification. La configuration par défaut de Power Apps, qui activait l'accès public aux tables de données, était dans le périmètre de responsabilité du client. Microsoft a modifié le paramètre par défaut après la divulgation.
Une base de données de localisation contenant les données de déplacements de 800 000 véhicules électriques du groupe Volkswagen (VW, Audi, SEAT, Skoda) a été exposée pendant plusieurs mois via un bucket de stockage cloud mal configuré. Les données, suffisamment précises pour établir les habitudes de déplacement des conducteurs, incluaient des localisations à plusieurs mètres de précision. Le Chaos Computer Club (CCC) allemand a découvert l'exposition et l'a signalée. L'incident a relancé le débat en Europe sur la sécurité des données générées par les véhicules connectés.
Toyota Motor Corporation a révélé qu'un environnement cloud contenant les données de localisation et d'utilisation de 2,15 millions de véhicules japonais avait été mal configuré depuis 2013 — soit dix ans d'exposition potentielle. La cause était une erreur dans la configuration des droits d'accès au service cloud Toyota Connected, accessible par une personne connaissant la clé de données. Toyota a publié une déclaration d'excuse et engagé un audit complet de l'ensemble de ses environnements cloud pour identifier d'autres configurations non conformes.