Points clés
- La responsabilité de la sécurité cloud est partagée selon un modèle défini — mais les périmètres varient selon le modèle de service (IaaS, PaaS, SaaS)
- Dans un SaaS, le client est responsable des données, des accès et de l'utilisation — pas de l'infrastructure sous-jacente
- Dans un IaaS, le client est responsable du système d'exploitation, des applications, des configurations réseau — le fournisseur gère l'infrastructure physique
- La confusion sur ce modèle est la première cause d'angles morts de sécurité dans les environnements cloud
La question "qui est responsable de la sécurité dans le cloud ?" est l'une des plus fréquemment mal comprises dans les organisations qui migrent vers le cloud. La réponse courte — "les deux parties, selon des périmètres clairement définis" — n'élimine pas la confusion opérationnelle. En pratique, des angles morts de sécurité persistent dans les zones de frontière entre les responsabilités du fournisseur et celles du client.
Ces angles morts ne résultent pas de mauvaise foi — ils résultent d'une compréhension incomplète du modèle de responsabilité partagée et d'une tendance naturelle à suposer que "le cloud s'en occupe" pour tout ce qui n'est pas explicitement dans le périmètre de l'équipe. La correction de ces angles morts commence par une revue formelle du modèle de responsabilité appliqué à chaque service cloud utilisé.
Le modèle de responsabilité selon le type de service
Dans un modèle IaaS (Infrastructure as a Service — comme AWS EC2, Google Compute Engine, Azure VMs), le fournisseur est responsable de l'infrastructure physique, des hyperviseurs et du réseau sous-jacent. Le client est responsable du système d'exploitation, des middlewares, des applications, des données, des accès, et de la configuration réseau virtuelle. C'est le modèle qui laisse le plus de responsabilités au client.
Dans un modèle PaaS (Platform as a Service — comme AWS Lambda, Google App Engine, Azure Functions), le fournisseur prend en charge l'infrastructure et le runtime. Le client reste responsable des applications déployées, des données, et des accès. Dans un modèle SaaS (Software as a Service — comme Salesforce, Microsoft 365, Google Workspace), le fournisseur gère l'ensemble de la pile technologique ; le client reste responsable de la configuration du service, des données qu'il y stocke, des accès accordés, et de la conformité réglementaire.
Les zones grises pratiques
Même avec un modèle de responsabilité clairement défini, des zones grises pratiques persistent. La configuration des paramètres de sécurité disponibles dans un SaaS — activation du MFA, politique de mots de passe, gestion des droits d'accès, activation des logs d'audit — est techniquement à la portée du client mais souvent négligée parce qu'elle n'est pas activée par défaut et que sa configuration requiert des compétences spécifiques.
Une étude Gartner (2023) révèle que 80 % des organisations n'utilisent pas l'ensemble des fonctionnalités de sécurité disponibles dans les SaaS qu'elles ont adoptés. Ces fonctionnalités — journalisation des accès, alertes sur les comportements anormaux, chiffrement des données au repos — sont dans le périmètre de responsabilité du client mais restent désactivées ou non configurées.
La gouvernance des responsabilités cloud
La gouvernance de la responsabilité partagée passe par un exercice formel pour chaque service cloud significatif : identifier le modèle de service (IaaS/PaaS/SaaS), cartographier les responsabilités selon ce modèle, vérifier que chaque responsabilité côté client est effectivement couverte par une équipe ou un processus, et documenter les éventuels angles morts identifiés avec un plan de remédiation.
Ce travail, réalisé une fois lors de l'adoption d'un nouveau service cloud, doit être maintenu lors des évolutions du service (nouveaux modules, nouvelles fonctionnalités de sécurité disponibles) et lors des changements dans l'organisation (réorganisations qui modifient les équipes responsables de certains périmètres cloud).
First American, l'un des plus grands assureurs immobiliers américains, a exposé 885 millions de documents financiers via son portail web hébergé dans le cloud. Les documents — relevés bancaires, numéros de sécurité sociale, permis de conduire — étaient accessibles via des URL prévisibles sans authentification. La vulnérabilité résultait d'une configuration applicative défaillante, dans le périmètre de responsabilité du client selon le modèle de responsabilité partagée. La SEC a sanctionné First American pour des défaillances dans la gestion des contrôles de cybersécurité, dont la divulgation inadéquate aux investisseurs.
La CNIL a sanctionné plusieurs organisations pour des configurations défaillantes de leurs services cloud SaaS en matière de protection des données. Les manquements constatés — absence de chiffrement des données sensibles hébergées dans des services cloud, droits d'accès excessifs, défaut de journalisation des accès — étaient tous dans le périmètre de responsabilité des organisations sanctionnées selon le modèle de responsabilité partagée. Le fournisseur cloud (Microsoft 365, Google Workspace dans certains cas) n'était pas en cause. La CNIL a précisé dans ses communications que l'utilisation d'un service cloud certifié ne dispense pas le responsable de traitement de ses obligations RGPD.
La compromission de SingHealth, qui a exposé les données de 1,5 million de patients, a impliqué des systèmes partiellement hébergés dans le cloud. L'investigation de la Personal Data Protection Commission a établi que des configurations d'accès insuffisantes — dans le périmètre de responsabilité de SingHealth — avaient facilité la propagation latérale des attaquants. Le rapport a explicitement distingué les défaillances de SingHealth (configurations, gestion des accès, détection) des responsabilités du fournisseur d'infrastructure. Cette distinction a servi de base aux sanctions imposées à SingHealth.