La sécurité du cloud a longtemps été présentée comme une affaire de fournisseur : choisir un hébergeur sérieux, vérifier ses certifications, et considérer le sujet comme traité. Cette lecture est fausse. Dans la quasi-totalité des incidents cloud constatés, la faille ne vient pas de l’infrastructure du fournisseur, mais de la configuration que le client applique par-dessus. Un bucket de stockage laissé ouvert, un groupe de sécurité trop permissif, une clé d’accès oubliée dans un dépôt de code : ces erreurs de configuration constituent aujourd’hui la première cause de compromission des environnements cloud.
C’est précisément le terrain d’une famille d’outils apparue pour répondre à ce risque : le CSPM, le CWPP, le CIEM, et leur convergence sous la bannière CNAPP. Cet article décrit ce que ces acronymes recouvrent, ce qu’ils font réellement, comment les déployer sans se noyer sous les alertes, et ce que NIS2 et DORA en attendent concrètement. La grille de lecture s’appuie sur les publications de l’ANSSI, de l’ENISA, du NIST et de la CNIL.
CSPM, CWPP, CIEM, CNAPP : de quoi parle-t-on ?
Ces quatre acronymes désignent des périmètres distincts qui répondent à des questions différentes.
Le CSPM (Cloud Security Posture Management) surveille la configuration des ressources cloud. Il interroge en continu les API du fournisseur pour vérifier que chaque ressource respecte les bonnes pratiques : chiffrement au repos activé, journalisation en place, absence d’exposition publique non justifiée, rotation des clés. Il répond à la question : mes ressources sont-elles configurées de façon sûre ?
Le CWPP (Cloud Workload Protection Platform) protège les charges de travail : machines virtuelles, conteneurs, fonctions serverless. Il détecte les vulnérabilités présentes dans les images, surveille le comportement à l’exécution et bloque les activités anormales. Il répond à la question : ce qui tourne dans mes environnements est-il sain ?
Le CIEM (Cloud Infrastructure Entitlement Management) gère les droits d’accès. Le cloud multiplie les identités humaines et machine, et les autorisations dérivent vite vers le sur-privilège. Le CIEM cartographie qui peut faire quoi, identifie les droits excessifs et propose un principe de moindre privilège applicable. Il répond à la question : qui a accès à quoi, et est-ce justifié ?
Le CNAPP (Cloud-Native Application Protection Platform) est la plateforme qui fait converger ces briques, en y ajoutant le scan du code d’infrastructure (IaC) et des images de conteneurs. Son intérêt n’est pas d’empiler des fonctions, mais de corréler leurs signaux. Une mauvaise configuration devient critique si elle expose une ressource accessible publiquement, qui héberge une charge vulnérable, accessible via une identité sur-privilégiée. Isolés, ces trois signaux sont trois alertes parmi des milliers. Corrélés, ils décrivent un chemin d’attaque réel et prioritaire.
Pourquoi la posture cloud est le maillon faible
La posture cloud est aujourd’hui le maillon faible parce que la surface de configuration a explosé pendant que les compétences et l’outillage n’ont pas suivi au même rythme. Chaque compte, chaque région, chaque service managé ajoute des dizaines de paramètres qui peuvent dériver.
Le contexte de menace confirme la pression. Dans son Panorama de la cybermenace 2025, l’ANSSI indique avoir traité 3 586 événements de sécurité, dont 1 366 incidents, et rapporte 460 événements qualifiés de possibles fuites de données, dont 42 % confirmées comme des fuites avérées [1]. L’Agence souligne par ailleurs que les équipements de bordure, très exposés et souvent vulnérables, restent des cibles privilégiées, ce qui rejoint directement la problématique des ressources cloud exposées par erreur de configuration.
À l’échelle européenne, l’ENISA a analysé 4 875 incidents entre juillet 2024 et juin 2025 dans son Threat Landscape 2025 [2], en pointant la persistance des attaques exploitant des surfaces mal maîtrisées et des chaînes d’approvisionnement complexes. Le cloud, par nature dynamique et distribué, concentre ces deux difficultés.
La cause profonde tient à trois facteurs. D’abord, la vitesse : l’infrastructure se provisionne en quelques secondes, plus vite que la revue de sécurité. Ensuite, la diffusion des responsabilités : dans une organisation où chaque équipe déploie ses ressources, personne n’a une vue d’ensemble de la posture. Enfin, l’illusion de la sécurité par défaut : beaucoup pensent que le fournisseur sécurise tout, alors que la responsabilité de la configuration leur revient. C’est le point que clarifie le modèle de responsabilité partagée.
Le modèle de responsabilité partagée : ce que vous devez sécuriser
Le modèle de responsabilité partagée décrit précisément la frontière entre ce que sécurise le fournisseur et ce que doit sécuriser le client. La règle générale est constante : le fournisseur est responsable de la sécurité du cloud (matériel, hyperviseur, réseau physique, services managés), le client est responsable de la sécurité dans le cloud (configuration, données, identités, accès).
Cette frontière se déplace selon le modèle de service :
- En IaaS, le client gère le système d’exploitation, les correctifs, le réseau applicatif, le chiffrement, les identités. Sa surface de responsabilité est maximale.
- En PaaS, le fournisseur prend en charge le système d’exploitation et le moteur d’exécution ; le client reste responsable de sa configuration, de ses données et de ses accès.
- En SaaS, le fournisseur gère presque tout, mais le client conserve la responsabilité de la configuration de son locataire, de la gestion des utilisateurs et des données qu’il y dépose.
La CNIL insiste sur ce point dans ses ressources dédiées à la sécurité du cloud : le client a un rôle à jouer pour sécuriser ses données, non seulement face à des tiers malveillants, mais aussi vis-à-vis du fournisseur lui-même, notamment par le chiffrement et une gestion appropriée des clés [5]. Le NIST formalise de son côté les enjeux de contrôle d’accès dans les architectures cloud dans sa publication SP 800-210 [3], qui rappelle que la politique d’accès est un point de responsabilité central du client.
Le CSPM et le CNAPP interviennent exactement sur cette part client : ils rendent visible et mesurable la posture que l’organisation est seule à pouvoir maîtriser. Comprendre où passe la frontière est le préalable à tout déploiement. Un même paramètre peut être hors de portée en SaaS et central en IaaS.
CSPM en détail : détecter et corriger les dérives
Le CSPM fonctionne par lecture continue de l’état déclaré des ressources via les API du fournisseur, puis comparaison avec un ensemble de règles. Ces règles proviennent de deux sources : les bonnes pratiques de sécurité (moindre exposition, chiffrement, journalisation) et les référentiels de conformité (ISO 27001, cadres réglementaires sectoriels, doctrines internes).
Les catégories de dérives les plus fréquentes que détecte un CSPM :
- Exposition publique non justifiée : stockage objet accessible sans authentification, base de données ouverte sur Internet, interface d’administration exposée.
- Chiffrement manquant : données au repos non chiffrées, communications internes en clair.
- Journalisation incomplète : absence de traces d’accès, journaux non centralisés, rétention insuffisante pour une investigation.
- Gestion des accès défaillante : comptes sans authentification multifacteur, clés d’accès anciennes jamais renouvelées, comptes de service sur-privilégiés.
- Dérive par rapport à l’état de référence : une ressource modifiée manuellement en production, hors du canal d’infrastructure as code.
L’apport d’un CSPM ne se limite pas à la détection. Il historise les dérives, ce qui permet de distinguer un incident ponctuel d’un défaut structurel, et il mappe chaque constat vers les exigences réglementaires, ce qui transforme une liste technique en preuve de conformité. Cette capacité de preuve est directement exploitable pour la gouvernance des identités et des accès et pour la gestion des vulnérabilités.
CWPP et CIEM : au-delà de la configuration
La configuration ne dit pas tout. Une ressource parfaitement configurée peut héberger une charge de travail vulnérable, et une identité légitime peut détenir des droits largement excessifs. C’est le rôle du CWPP et du CIEM de couvrir ces angles morts.
Le CWPP protège ce qui s’exécute. Il analyse les images de conteneurs et les machines virtuelles à la recherche de vulnérabilités et de secrets codés en dur, surveille le comportement à l’exécution (processus anormaux, connexions sortantes suspectes) et applique des politiques de durcissement. Sur les environnements conteneurisés, il prolonge les enjeux déjà présents au niveau de l’orchestrateur Kubernetes en production. Un CWPP bien intégré détecte par exemple une image en production dont une bibliothèque présente une vulnérabilité critique, avant que celle-ci ne soit exploitée.
Le CIEM s’attaque au sur-privilège, qui est l’une des causes majeures d’escalade lors d’une compromission cloud. Le principe est simple à énoncer et difficile à tenir : chaque identité, humaine ou machine, ne doit disposer que des droits strictement nécessaires. En pratique, les droits s’accumulent, personne n’ose les retirer, et une identité compromise ouvre alors un accès disproportionné. Le CIEM cartographie les droits effectifs, met en évidence les écarts avec les droits réellement utilisés, et propose une réduction. Ce travail rejoint directement la problématique des identités machine et des secrets, qui sont aujourd’hui plus nombreuses que les identités humaines dans la plupart des environnements cloud.
CNAPP : la convergence du code au runtime
Le CNAPP répond à un problème que la juxtaposition d’outils isolés ne résout pas : la dispersion des alertes et l’absence de priorisation. Sa valeur tient à la corrélation et à la couverture continue, du code jusqu’à l’exécution.
Concrètement, un CNAPP couvre la chaîne complète :
- À l’écriture du code d’infrastructure, il scanne les fichiers Terraform ou équivalents pour repérer une mauvaise configuration avant même le déploiement. Corriger à ce stade coûte une fraction de ce que coûte une correction en production.
- À la construction des images, il analyse les vulnérabilités et les secrets, et bloque la promotion d’une image non conforme dans la chaîne de livraison.
- En production, il maintient la vue de posture (CSPM), la protection des charges (CWPP) et la gestion des droits (CIEM), et corrèle ces signaux en chemins d’attaque hiérarchisés.
Cette approche « shift-left puis runtime » s’inscrit dans la même logique que l’intégration de la sécurité dans la chaîne de livraison DevSecOps. La différence décisive avec une pile d’outils séparés réside dans la priorisation : au lieu de traiter dix mille mauvaises configurations sans hiérarchie, l’équipe traite d’abord les quelques dizaines de chemins qui combinent exposition, vulnérabilité exploitable et accès à privilèges. C’est la seule façon de rendre le sujet gouvernable avec des effectifs de sécurité limités.
Déployer un CNAPP : une méthode en cinq temps
Un déploiement de CNAPP réussi suit une progression, pas un allumage général de toutes les fonctions. Voici une trajectoire éprouvée.
1. Inventaire et visibilité d’abord. Connecter la plateforme en lecture seule sur l’ensemble des comptes et environnements, sans activer de blocage. L’objectif est d’obtenir une carte complète des ressources et des identités. On découvre presque toujours des comptes oubliés et des ressources hors inventaire.
2. Prioriser par le contexte. Ne pas traiter les alertes par ordre de sévérité brute, mais par exploitabilité réelle : exposition publique, présence de données sensibles, chemin d’accès vers un privilège élevé. Une mauvaise configuration sur une ressource isolée sans donnée n’a pas la même urgence qu’un chemin exposé vers un compte d’administration.
3. Corriger à la source. Quand une dérive provient du code d’infrastructure, corriger le code, pas seulement la ressource en production. Sinon la dérive réapparaît au prochain déploiement. C’est la différence entre traiter le symptôme et traiter la cause.
4. Automatiser les garde-fous. Introduire des contrôles automatiques dans la chaîne de livraison pour empêcher les mauvaises configurations connues de passer en production, et intégrer les alertes critiques dans le flux de traitement du SOC et du SIEM et de la journalisation.
5. Piloter par indicateurs. Suivre un petit nombre de mesures : temps moyen de correction des chemins critiques, part des ressources conformes aux référentiels, réduction du sur-privilège. Un CNAPP qui n’est pas piloté par des indicateurs redevient vite un générateur d’alertes ignorées.
Cette montée en charge progressive évite l’écueil le plus courant : activer tout, générer un déluge d’alertes, et perdre la confiance des équipes en quelques semaines.
CNAPP et conformité : NIS2, DORA, SecNumCloud
La maîtrise de la posture cloud n’est plus seulement une bonne pratique : elle est devenue une obligation opposable pour un nombre croissant d’organisations.
NIS2. La directive (UE) 2022/2555 [7] impose aux entités essentielles et importantes, dans son article 21, une gestion des risques couvrant la sécurité de l’exploitation, la gestion des vulnérabilités et la maîtrise de la chaîne d’approvisionnement. Les environnements cloud entrent pleinement dans ce périmètre. Un CSPM ou un CNAPP fournit la surveillance continue et la traçabilité des corrections que l’autorité attend, et qui sont difficiles à démontrer autrement qu’avec un outillage dédié.
DORA. Pour le secteur financier, le règlement européen exige une surveillance continue du risque lié aux prestataires TIC et une résilience opérationnelle démontrable. La posture cloud, régulièrement mesurée et documentée, est un élément de preuve direct.
SecNumCloud. La qualification de l’ANSSI [6] engage le fournisseur sur un périmètre qualifié, mais ne dispense pas le client de sécuriser sa propre configuration à l’intérieur de ce périmètre. Le choix d’un fournisseur de cloud souverain et la maîtrise de la posture sont deux exigences complémentaires, pas alternatives.
À l’international, des cadres comme le projet SCuBA de la CISA [4] formalisent des lignes de base de configuration sécurisée pour les applications cloud, illustrant la même conviction : la sécurisation de la configuration client est un chantier à part entière, distinct de la sécurité du fournisseur.
Pièges et limites à connaître
Le CNAPP n’est pas une solution magique, et plusieurs écueils reviennent systématiquement.
Le déluge d’alertes. Sans priorisation par le contexte, un CSPM produit des milliers de constats de faible valeur. Les équipes finissent par les ignorer, et l’outil devient un coût sans bénéfice. La priorisation par exploitabilité n’est pas une option, c’est la condition de survie du dispositif.
La confusion des plans. Un CSPM agit sur le plan de contrôle, c’est-à-dire la configuration déclarée. Il ne voit pas une attaque en cours au niveau du système ni le trafic malveillant en circulation. Il complète le pare-feu, l’EDR et le SIEM ; il ne les remplace pas.
La dépendance à la couverture API. Le CSPM ne voit que ce que le fournisseur expose via ses API. Un service récent ou une configuration exotique peut échapper à la détection. La couverture réelle d’une plateforme doit être vérifiée sur les services que l’organisation utilise vraiment, pas sur une liste marketing.
Le coût et le sur-outillage. Un CNAPP complet représente un investissement financier et humain réel. Sur un périmètre modeste et mono-cloud, les outils de posture natifs du fournisseur peuvent suffire dans un premier temps. Le CNAPP se justifie par l’échelle, le multi-cloud et l’exigence de preuve réglementaire. Ce raisonnement rejoint la discipline FinOps, qui invite à dimensionner l’outillage sur le besoin réel.
Grille de choix indicative
Aucune grille ne remplace une analyse contextuelle. Le tableau ci-dessous propose une orientation selon le profil.
| Contexte | Outillage recommandé | Priorité |
|---|---|---|
| Mono-cloud, périmètre modeste | Outils de posture natifs du fournisseur | Chiffrement, exposition publique, MFA |
| Mono-cloud, données sensibles | CSPM tiers + CIEM | Conformité, moindre privilège |
| Multi-cloud | CNAPP unifié | Politique homogène, corrélation |
| Conteneurs et serverless intensifs | CNAPP avec CWPP fort | Scan images, runtime |
| Entité NIS2 ou acteur DORA | CNAPP avec mapping réglementaire | Preuve auditable continue |
Pour les charges les plus sensibles, le choix doit se faire sur la couverture réelle des services utilisés et sur la capacité de preuve réglementaire, pas sur le nombre de fonctions annoncées.
À retenir
La sécurité du cloud se joue dans la configuration côté client, pas dans l’infrastructure du fournisseur. Le CSPM détecte les mauvaises configurations, le CWPP protège les charges de travail, le CIEM maîtrise les droits d’accès, et le CNAPP fait converger ces briques du code au runtime en corrélant les signaux pour prioriser les chemins d’attaque réels. Le modèle de responsabilité partagée détermine précisément ce que l’organisation doit sécuriser, et cette part varie entre IaaS, PaaS et SaaS. Le succès d’un déploiement tient à la priorisation par le contexte et à la correction à la source, pas à l’activation de toutes les fonctions d’un coup. Enfin, NIS2 et DORA transforment la surveillance continue de la posture cloud en obligation opposable : l’outillage devient un moyen de preuve, à condition d’être piloté par des indicateurs et non par un flux d’alertes ignorées.
Sources
[1] ANSSI, Panorama de la cybermenace 2025. https://cyber.gouv.fr/actualites/panorama-de-la-cybermenace-2025/ [2] ENISA, Threat Landscape 2025. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025 [3] NIST, SP 800-210, General Access Control Guidance for Cloud Systems. https://csrc.nist.gov/pubs/sp/800/210/final [4] CISA, Secure Cloud Business Applications (SCuBA) Project. https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project [5] CNIL, Sécurité : Cloud, informatique en nuage. https://www.cnil.fr/fr/securite-cloud-informatique-en-nuage [6] ANSSI, SecNumCloud pour les fournisseurs de services cloud. https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud [7] Directive (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj