01Le modèle de responsabilité partagée selon IaaS, PaaS et SaaS
Le fournisseur cloud et le client se partagent la responsabilité de la sécurité – la répartition exacte dépend du modèle de service. En IaaS, le client est responsable du système d'exploitation, des contrôles réseau et des applications ; en PaaS, le fournisseur prend en charge le système d'exploitation, tandis que la configuration des applications et du réseau reste partagée ; en SaaS, la quasi-totalité de la pile relève du fournisseur. Quel que soit le modèle, quatre domaines restent toutefois toujours à la charge du client selon la matrice de responsabilité de Microsoft : les données, les terminaux, les comptes et la gestion des accès – de même que les configurations et les paramètres. Le malentendu le plus fréquent est « le fournisseur s'occupe de la sécurité » : en SaaS notamment, la responsabilité des accès et des configurations est régulièrement sous-estimée, et sans attribution explicite, les responsabilités partagées restent de fait sans titulaire.
02L'identité est le nouveau périmètre
Dans le cloud, le plan de gestion et les API sont accessibles via Internet – quiconque détient des identifiants valides ne se trouve pas devant le pare-feu, mais au cœur de l'environnement. La Cloud Security Alliance classe d'ailleurs l'Identity and Access Management à la 2e place de ses Top Threats 2024. Les contre-mesures efficaces sont une authentification multifacteur systématique et si possible résistante au phishing, des rôles à moindre privilège plutôt que des droits d'administrateur permanents, des comptes à privilèges séparés et particulièrement surveillés, ainsi que des identifiants de courte durée de vie. Les identités non humaines – comptes de service, clés API, identités de workload – relèvent de la même gouvernance, car elles sont souvent négligées lors des revues d'habilitations et rarement recertifiées.
03Erreurs de configuration et contrôle des changements insuffisant
« Misconfiguration and Inadequate Change Control » occupe la 1re place des CSA Top Threats to Cloud Computing 2024. Les schémas typiques sont des buckets de stockage accessibles publiquement, des rôles IAM trop larges, des accès d'administration exposés, une journalisation désactivée ainsi que des ressources de test et des ressources fantômes oubliées. La cause est rarement un manque de connaissances, mais la vitesse : le self-service et l'Infrastructure as Code génèrent chaque jour des changements que personne ne vérifie de manière cohérente en l'absence de garde-fous. Les remèdes sont des politiques définies sous forme de code (Policy as Code), le Cloud Security Posture Management (CSPM) pour détecter les écarts en continu, et un processus de gestion des changements qui s'applique expressément aussi aux ressources cloud.
04CSA Top Threats : ce que le secteur considère comme un risque
Pour sa série « Top Threats to Cloud Computing », la Cloud Security Alliance interroge régulièrement des spécialistes ; pour l'édition 2024 (publiée en août 2024), plus de 500 experts ont priorisé onze menaces. Les trois premières places reviennent aux erreurs de configuration et au contrôle des changements insuffisant, à l'Identity and Access Management ainsi qu'aux interfaces et API non sécurisées – autant de sujets qui relèvent de la responsabilité du client. Le rapport complémentaire « Top Threats to Cloud Computing - Deep Dive 2025 » (avril 2025) analyse huit incidents de sécurité réels selon cette grille de menaces et en déduit des recommandations de contrôles ; au centre figurent les erreurs humaines, les faiblesses en matière d'identité et de configuration ainsi que les risques liés à la chaîne d'approvisionnement.
05Landing zones, bases de référence et gouvernance multi-cloud
Une landing zone est un environnement cloud préstructuré dans lequel la gouvernance, le réseau, l'identité et la journalisation sont ancrés avant l'arrivée de la première workload. Le Cloud Adoption Framework de Microsoft distingue à cet effet une landing zone de plateforme centrale et, pour chaque workload, des landing zones applicatives dédiées qui héritent automatiquement des politiques de sécurité via la hiérarchie des management groups. Comme base de référence de configuration, les CIS Benchmarks, élaborés par consensus, se sont imposés – plus de 100 benchmarks pour plus de 25 familles de produits, dont AWS, Azure, Google Cloud et Oracle Cloud. Pour l'évaluation des fournisseurs sur le marché allemand, le catalogue de critères C5 du BSI est en outre pertinent ; il a été profondément remanié en 2025/26 (C5:2026). Dans les environnements multi-cloud, ce n'est pas tant l'outil individuel qui compte que la cohérence : des politiques uniformes, une gouvernance centralisée des identités et une journalisation consolidée sur l'ensemble des plateformes.
06Se lancer dans un programme de sécurité cloud
Le point de départ est la transparence : quels comptes cloud, services et données existent – y compris les environnements qui n'ont jamais fait l'objet d'une revue d'architecture ? Viennent ensuite la clarification des responsabilités par modèle de service et la sécurisation des deux plus grands leviers : les identités (MFA, accès à privilèges) et la journalisation centralisée. Une base de référence comme les CIS Benchmarks est ensuite rendue contraignante et sa conformité mesurée en continu avec des outils CSPM, au lieu d'être seulement auditée ponctuellement. La sécurité cloud est un programme inscrit dans la durée – avec des rôles définis, des indicateurs et des processus de changement – et non un projet de durcissement ponctuel.
