5 erreurs de configuration cloud invisibles jusqu'à l'incident

Selon un rapport Gartner souvent cité dans le milieu, la majorité des failles de sécurité cloud d'ici 2025 devaient être imputables non pas à des vulnérabilités logicielles, mais à des erreurs de configuration commises par les utilisateurs eux-mêmes. En 2026, ce constat se vérifie chaque semaine dans l'actualité.

Le problème n'est pas que le cloud soit intrinsèquement dangereux. C'est que sa nature même, dynamique et élastique, crée un terrain fertile pour des erreurs silencieuses. Chaque jour, des machines virtuelles, des conteneurs et des bases de données apparaissent et disparaissent dans votre infrastructure AWS, Azure ou GCP. Chaque création laisse une trace : une règle de pare-feu, une politique d'accès, un rôle IAM. Et quand personne ne vérifie que ces traces sont cohérentes avec la réalité du moment, les brèches s'accumulent.

Je vois régulièrement des dirigeants de PME convaincus que leur hébergeur cloud "gère la sécurité". C'est un malentendu coûteux. AWS, Azure et Google Cloud sécurisent leur infrastructure. La configuration de votre environnement reste votre responsabilité. Voici cinq catégories d'erreurs que je rencontre de manière récurrente, et qui restent invisibles jusqu'au jour où elles ne le sont plus.

Le bucket de stockage resté public par accident

Le scénario est classique et pourtant il se reproduit chaque trimestre quelque part. Une équipe crée un bucket S3 sur AWS (ou un Blob Storage sur Azure) pour un projet temporaire. Pour simplifier les tests, l'accès est configuré en public. Le projet avance, le bucket est réutilisé pour un autre besoin, mais la politique d'accès d'origine n'est jamais révisée.

Résultat : des données clients, des sauvegardes de base ou des fichiers internes se retrouvent accessibles à quiconque dispose de l'URL. Ce n'est pas un scénario théorique. Les fuites de données massives liées à des buckets S3 mal configurés ont touché des organisations de toutes tailles ces dernières années.

Pour une TPE ou une PME, le risque est aggravé par l'absence fréquente d'un processus de revue systématique. Quand une seule personne gère l'infrastructure, la vérification des politiques d'accès passe souvent après les urgences du quotidien.

Le réflexe à adopter : activer les alertes natives de votre fournisseur cloud (AWS Config, Azure Policy) qui détectent automatiquement les ressources de stockage exposées publiquement. C'est gratuit ou presque, et cela prend moins d'une heure à configurer. Certaines de ces brèches silencieuses rejoignent d'ailleurs la logique décrite dans l'article sur les 10 portes dérobées qui coûtent une fortune à votre entreprise : des vulnérabilités banales mais dont le coût cumulé est considérable.

Les permissions excessives qui s'accumulent sans bruit

Dans un environnement cloud, chaque service, chaque utilisateur et chaque pipeline d'intégration continue (CI/CD) dispose d'un rôle IAM (Identity and Access Management) qui définit ce qu'il peut faire. Le problème commence quand un développeur, pressé par un déploiement urgent, attribue des droits administrateur "temporaires" à un pipeline de build. Le déploiement fonctionne. Le ticket est fermé. Les droits restent.

Six mois plus tard, ce pipeline dispose toujours d'un accès complet à l'ensemble des ressources du compte cloud. Si un attaquant compromet le dépôt de code source ou la plateforme CI/CD, il hérite de ces permissions. Ce vecteur d'attaque a d'ailleurs été exploité dans des incidents documentés, comme celui de l'application TEA analysé dans cet article sur les leçons de sécurité à l'ère de l'IA.

Le principe du moindre privilège (least privilege) est simple à énoncer : chaque entité ne devrait avoir accès qu'aux ressources strictement nécessaires à sa fonction. En pratique, son application exige une discipline continue. Les outils comme AWS IAM Access Analyzer ou Azure AD Privileged Identity Management permettent d'identifier les permissions inutilisées et de les révoquer.

Mon conseil : planifiez une revue trimestrielle des rôles IAM. C'est fastidieux, mais c'est l'un des contrôles de sécurité cloud les plus efficaces en rapport effort/impact.

La base de test oubliée en production

Voici un cas que j'ai rencontré personnellement : une base de données PostgreSQL créée pour tester une nouvelle fonctionnalité. Pour accélérer les tests, l'équipe y a importé un extrait de données clients réelles. La fonctionnalité a été abandonnée. La base, elle, est restée active pendant plus d'un an, sans surveillance, sans mises à jour de sécurité, et avec les identifiants par défaut.

Ce type de ressource orpheline est un angle mort classique de la gestion d'infrastructure cloud. Les ressources de test ne figurent généralement pas dans les inventaires de production. Elles échappent aux politiques de sauvegarde, de chiffrement et de monitoring. Elles constituent pourtant une cible de choix : moins surveillées, souvent moins protégées, et parfois connectées au même réseau que les systèmes critiques.

Le risque est d'autant plus sérieux pour les PME soumises au RGPD. Une base de test contenant des données personnelles réelles est soumise aux mêmes obligations qu'une base de production. En cas de fuite, la CNIL ne fera pas de distinction.

Action concrète : mettez en place un inventaire automatisé de vos ressources cloud (AWS Resource Explorer, Azure Resource Graph). Taguer chaque ressource avec son propriétaire, sa date de création et son environnement (test, staging, production) permet d'identifier rapidement ce qui ne devrait plus exister. C'est un principe qui prend tout son sens dans le cadre de la protection globale des secrets et données sensibles, un sujet approfondi dans cet article sur les risques liés aux secrets mal protégés.

La dérive de conformité que personne ne détecte

Une infrastructure cloud peut être parfaitement configurée le jour de son audit. Le problème, c'est que cette conformité a une durée de vie limitée. Un développeur modifie une règle de pare-feu pour débloquer un problème. Un administrateur désactive temporairement le chiffrement sur un volume pour un diagnostic. Ces micro-changements, pris individuellement, semblent anodins. Accumulés sur des mois, ils créent une dérive significative entre l'état documenté de votre infrastructure et sa réalité.

Cette dérive de configuration est d'autant plus dangereuse qu'elle est invisible sans outillage adapté. Les audits ponctuels, réalisés une fois par an, capturent un instantané qui peut être obsolète dès le lendemain. Les entreprises qui gèrent sérieusement ce risque utilisent des outils de conformité continue : AWS Config Rules, Azure Policy, ou des solutions tierces comme Prisma Cloud ou Lacework.

Il faut toutefois être honnête sur un point : ces outils ont un coût, en licences et en temps de configuration. Pour une TPE avec trois serveurs cloud, l'investissement peut sembler disproportionné. Dans ce cas, une alternative pragmatique consiste à définir un ensemble réduit de règles critiques (chiffrement actif, pas d'accès public, MFA activé sur tous les comptes admin) et à les vérifier manuellement chaque mois. C'est moins élégant, mais c'est mieux que rien.

La robustesse d'une telle démarche de surveillance continue est d'ailleurs un pilier central lors d'un Audit & Sécurité, où l'objectif est précisément de mesurer l'écart entre la configuration attendue et la configuration réelle.

Le multi-cloud sans visibilité centralisée

Beaucoup de PME se retrouvent en situation de multi-cloud sans l'avoir planifié. Le site web est hébergé chez un prestataire, l'ERP tourne sur Azure, les sauvegardes sont sur AWS, et quelqu'un a un jour créé un projet sur Google Cloud pour tester un service de machine learning. Chaque environnement a sa propre console, ses propres journaux d'événements, ses propres alertes.

Dans cette configuration, personne n'a une vue d'ensemble. Un accès suspect sur AWS ne sera pas corrélé avec une activité anormale sur Azure. Une ressource exposée sur GCP ne déclenchera pas d'alerte dans le tableau de bord principal. Cette fragmentation de la visibilité est un problème de sécurité en soi.

Les solutions CSPM (Cloud Security Posture Management) comme Wiz, Orca Security ou les outils natifs multi-cloud de Microsoft Defender for Cloud existent précisément pour répondre à ce besoin. Mais soyons clairs : leur mise en place demande des compétences spécifiques et un budget qui n'est pas anodin.

Pour les structures plus petites, le premier pas consiste à dresser un inventaire exhaustif de tous les comptes cloud actifs dans l'organisation. C'est souvent là que les surprises commencent. J'ai vu des entreprises de 15 personnes découvrir qu'elles avaient sept comptes cloud différents, dont trois créés par d'anciens collaborateurs avec des cartes bancaires personnelles.

La question du déploiement maîtrisé sur des environnements multiples rejoint d'ailleurs les problématiques abordées dans l'article sur les stratégies de déploiement en production, où la cohérence entre environnements est un enjeu central.

Ce que ces cinq erreurs ont en commun

Aucune de ces failles n'est causée par un logiciel défectueux ou un pirate sophistiqué. Elles résultent toutes d'un même mécanisme : une action ponctuelle raisonnable qui devient un risque permanent faute de suivi. Un accès temporaire non révoqué, un bucket réutilisé sans vérification, une base de test oubliée. Ce sont des décisions humaines normales dans un environnement qui évolue trop vite pour la mémoire humaine.

La réponse n'est pas de recruter une armée d'ingénieurs sécurité. Pour la plupart des PME, trois mesures suffisent à couvrir l'essentiel du risque :

• Automatiser la détection : activer les services natifs de votre fournisseur cloud (AWS Config, Azure Policy, GCP Security Command Center). Ils sont inclus ou peu coûteux et détectent les erreurs de configuration les plus courantes.
• Inventorier et taguer : chaque ressource cloud doit avoir un propriétaire identifié et une date d'expiration prévue. Ce qui n'a pas de propriétaire n'a pas de raison d'exister.
• Planifier des revues régulières : une vérification trimestrielle des permissions IAM et des ressources actives prend quelques heures et peut éviter des mois de crise.

Ces mesures ne garantissent pas l'absence totale de risque. Aucune mesure ne le peut. Mais elles transforment des angles morts permanents en risques gérés et visibles.

Conclusion

Les erreurs de configuration cloud ne sont pas des bugs. Ce sont des oublis humains amplifiés par la vitesse et l'élasticité d'une infrastructure qui ne pardonne pas l'approximation. La bonne nouvelle, c'est que la majorité de ces risques se corrigent avec des outils déjà disponibles dans votre abonnement cloud et quelques heures de rigueur par trimestre.

Votre infrastructure cloud a été configurée il y a combien de temps ? Et surtout : quelqu'un a-t-il vérifié depuis que tout est encore conforme à ce qui était prévu ?


Sources : Ministère de l'Économie - Espace Entreprises Bpifrance Création Les Echos - PME & Régions