Modèle de responsabilité partagée

Le modèle de responsabilité partagée (en anglais : shared responsibility model) est un cadre conceptuel utilisé dans le domaine de la sécurité du cloud qui définit la répartition des obligations de sécurité entre un fournisseur de services en nuage et ses clients. Ce modèle établit une frontière claire entre ce que le prestataire doit sécuriser — généralement l'infrastructure physique, les hyperviseurs et les couches réseau de base — et ce qui incombe à l'utilisateur, tel que la gestion des identités et des accès, la protection des données et la configuration des ressources applicatives. Apparu avec l'essor de l'informatique en nuage au milieu des années 2000, il constitue aujourd'hui un pilier de la gestion des risques informatiques dans tout projet de migration vers le cloud. Sa maîtrise est désormais exigée dans de nombreux référentiels de compétences en cybersécurité.

Origine et contexte

Émergence avec l'informatique en nuage

Le modèle de responsabilité partagée s'est formalisé à partir de 2006, lorsque Amazon Web Services a lancé ses premiers services d'infrastructure à la demande (Elastic Compute Cloud, Simple Storage Service). Face aux interrogations des entreprises sur la délimitation des périmètres de sécurité dans un environnement mutualisé, les grands fournisseurs ont progressivement produit des politiques documentées de répartition des responsabilités.

Microsoft Azure, lancé commercialement en 2010, et Google Cloud Platform, dont l'offre s'est structurée entre 2011 et 2013, ont adopté des formalisations similaires. En 2014, le NIST Cybersecurity Framework a contribué à ancrer cette approche dans les pratiques professionnelles en identifiant explicitement les limites de contrôle selon le modèle de service cloud.

Facteurs d'adoption

Plusieurs facteurs ont accéléré l'adoption de ce modèle :

La multiplication des violations de données liées à des erreurs de configuration côté client, notamment des espaces de stockage laissés accessibles publiquement sans authentification ;
L'entrée en vigueur du RGPD en mai 2018, qui impose aux responsables de traitement une obligation de sécurité indépendante du recours à un prestataire technique cloud ;
Les exigences de la Directive NIS2, applicable depuis octobre 2024, qui étend les obligations de cybersécurité à un large spectre d'entités essentielles et importantes au sein de l'Union européenne ;
Le règlement DORA, applicable depuis janvier 2025, qui impose aux entités financières une cartographie précise des responsabilités avec les prestataires tiers de services TIC, notamment les fournisseurs cloud.

Principes fondamentaux

Le modèle repose sur deux axiomes complémentaires :

Le fournisseur est responsable de la sécurité du cloud (security of the cloud) : sécurité physique des centres de données, virtualisation, infrastructure réseau de base et disponibilité des services.
Le client est responsable dans le cloud (security in the cloud) : configuration des ressources, gestion des identités et des accès, protection des données, chiffrement applicatif.

Cette distinction est formulée explicitement dans les contrats et la documentation technique des principaux fournisseurs. Elle n'est pas symétrique : la part de responsabilité transférée au client varie fortement selon le modèle de service souscrit (IaaS, PaaS ou SaaS). Dans tous les cas, la responsabilité juridique ultime vis-à-vis des personnes concernées par les traitements de données reste du ressort du responsable de traitement, c'est-à-dire le client.

Déclinaisons selon le modèle de service

La répartition concrète des responsabilités dépend directement du type de service cloud utilisé.

Infrastructure as a Service

Dans le modèle Infrastructure as a Service (IaaS), le fournisseur gère l'infrastructure physique (serveurs, stockage brut, réseau, hyperviseur), mais le client prend en charge l'ensemble des couches logicielles : système d'exploitation, middleware, runtime, applications et données. La surface de responsabilité côté client est maximale.

Exemples courants : Amazon EC2, Microsoft Azure Virtual Machines, Google Compute Engine.

Responsabilités typiques du client en IaaS :

Application des correctifs de sécurité (patching) sur le système d'exploitation et les logiciels installés ;
Configuration du pare-feu et des groupes de sécurité réseau ;
Chiffrement des données au repos et en transit via TLS ;
Mise en place de l'authentification multifacteur pour les accès administrateurs ;
Sauvegarde régulière des données applicatives et test périodique de restauration.

Platform as a Service

En Platform as a Service (PaaS), le fournisseur étend sa responsabilité à l'environnement d'exécution (runtime, middleware, système d'exploitation). Le client se concentre sur les applications déployées et les données qu'elles traitent. Les responsabilités portent alors sur la sécurité du code applicatif, la gestion des dépendances et la configuration des politiques d'accès propres à l'application.

Exemples représentatifs : Azure App Service, Google App Engine.

Software as a Service

Le modèle Software as a Service (SaaS) concentre la quasi-totalité de la responsabilité technique chez le fournisseur, qui assure la disponibilité de l'application, la gestion des mises à jour et la sécurité de l'infrastructure sous-jacente. Le client reste néanmoins responsable de :

La gestion des comptes et des droits d'accès des utilisateurs, y compris la révocation rapide en cas de départ ;
La classification et la protection des données confiées au service ;
La configuration des politiques de sécurité accessibles (activation du SSO, des journaux d'audit, paramétrage des règles de partage) ;
La conformité du traitement des données au RGPD et aux réglementations sectorielles applicables, notamment via la signature d'accords de traitement des données (DPA).

Tableau récapitulatif

Couche	IaaS	PaaS	SaaS
Infrastructure physique / réseau	Fournisseur	Fournisseur	Fournisseur
Hyperviseur / virtualisation	Fournisseur	Fournisseur	Fournisseur
Système d'exploitation	Client	Fournisseur	Fournisseur
Middleware / runtime	Client	Fournisseur	Fournisseur
Application	Client	Client	Fournisseur
Données	Client	Client	Client (partiellement)
Identités et accès	Client	Client	Client
Chiffrement des données	Client	Client (partiel)	Client (partiel)

Cadre normatif et réglementaire

Plusieurs référentiels internationaux et nationaux encadrent ou précisent le modèle de responsabilité partagée :

ISO/IEC 27017 : extension de l'ISO/IEC 27001 spécifiquement dédiée au cloud computing, elle définit 37 contrôles dont 7 nouveaux propres aux relations fournisseur-client cloud et matérialise formellement la notion de responsabilités partagées.
NIST Cybersecurity Framework : identifie les fonctions Identify, Protect, Detect, Respond et Recover en précisant, pour chaque couche cloud, à qui incombe leur mise en œuvre.
RGS (Référentiel Général de Sécurité) : référentiel de l'ANSSI applicable aux systèmes d'information des autorités administratives françaises ; lorsqu'une administration recourt au cloud, ce référentiel impose une analyse formelle de la répartition des responsabilités.
Guides de l'ANSSI : l'Agence nationale de la sécurité des systèmes d'information a publié plusieurs recommandations, dont « Recommandations pour les architectures des systèmes d'information en nuage » (2021), précisant les exigences de qualification et la répartition des responsabilités selon le niveau de sensibilité des données traitées.
DORA : impose aux entités financières de documenter contractuellement la répartition des responsabilités avec chaque prestataire TIC critique dans un registre tiers dédié, révisé au moins annuellement.

Mise en œuvre opérationnelle

Cartographie et gouvernance

La mise en œuvre effective du modèle commence par une cartographie des services cloud utilisés par l'organisation (cloud inventory) et, pour chacun d'eux, une identification précise des responsabilités résiduelles côté client. Cette cartographie alimente le système de management de la sécurité de l'information (SMSI) et le registre des risques.

Le responsable de la sécurité des systèmes d'information (RSSI) coordonne généralement cette démarche, en lien avec les équipes juridiques chargées de la négociation des contrats de niveau de service et des accords de traitement des données. La cartographie est mise à jour à chaque souscription d'un nouveau service cloud ou lors de la modification substantielle d'un service existant.

Contrôles techniques prioritaires

Les contrôles relevant systématiquement de la responsabilité client, quel que soit le modèle de service :

Gestion des identités et des accès : application du principe du moindre privilège, révocation rapide des droits en cas de départ d'un collaborateur, séparation des comptes de production et de test ;
Authentification multifacteur : obligatoire pour les accès à la console d'administration cloud ;
Chiffrement des données : chiffrement au repos avec des clés gérées par le client (customer-managed keys) et en transit via TLS 1.2 minimum ;
Journalisation et détection : activation des journaux d'audit natifs (AWS CloudTrail, Azure Monitor, etc.) et intégration dans un SIEM pour la corrélation des événements ;
Gestion des vulnérabilités : analyse régulière des images de conteneurs et des instances IaaS, avec priorisation selon le score CVSS.

Audits et tests

Un audit de cybersécurité régulier permet de vérifier l'adéquation entre la répartition théorique des responsabilités et leur mise en œuvre effective. Les tests d'intrusion ciblant les configurations cloud (cloud penetration testing) constituent un complément indispensable ; les fournisseurs cloud majeurs disposent de politiques d'autorisation explicites encadrant ces tests sur leurs plateformes. Un test de configuration automatisé (cloud security posture management, CSPM) peut être déployé en continu pour détecter les dérives.

Continuité et reprise

La responsabilité du plan de continuité d'activité (PCA) et du plan de reprise d'activité informatique (PRA) incombe au client, même en mode SaaS. Le fournisseur garantit la disponibilité de son infrastructure selon les termes du contrat de niveau de service, mais ne prend pas en charge les procédures de reprise métier ni les sauvegardes des données applicatives si celles-ci ne sont pas explicitement activées et configurées par le client.

Enjeux pour les organisations et les professionnels

Compétences métier requises

La maîtrise du modèle de responsabilité partagée est désormais une compétence attendue dans plusieurs métiers de l'informatique et de la sécurité :

Architectes cloud et ingénieurs DevSecOps, chargés d'intégrer les contrôles de sécurité dès la conception (security by design) ;
RSSI et chefs de projet sécurité, responsables de la gouvernance globale et de la conformité réglementaire ;
Auditeurs et consultants en cybersécurité, amenés à évaluer l'adéquation des configurations cloud par rapport aux référentiels applicables ;
Responsables juridiques et délégués à la protection des données (DPO), qui doivent traduire les obligations du RGPD et des réglementations sectorielles en clauses contractuelles opposables aux fournisseurs.

Des certifications professionnelles reconnues évaluent cette compétence : AWS Certified Security – Specialty, Microsoft Certified: Azure Security Engineer Associate, Certified Cloud Security Professional (CCSP, délivrée par (ISC)²).

Erreurs fréquentes

L'analyse des incidents de sécurité cloud documentés depuis 2015 révèle plusieurs erreurs récurrentes liées à une mauvaise compréhension du modèle :

Hypothèse de couverture totale par le fournisseur : supposer que souscrire à un service SaaS décharge l'entreprise de toute responsabilité en matière de protection des données — inexact au regard du RGPD et des réglementations sectorielles ;
Absence de journalisation : les journaux d'audit natifs sont disponibles mais non activés par défaut chez certains fournisseurs, laissant l'organisation sans visibilité en cas d'incident ;
Sous-estimation de la misconfiguration : selon le rapport Verizon Data Breach Investigations Report 2023, 21 % des violations de données impliquent une erreur de configuration, fréquemment côté client en environnement cloud ;
Absence de tests de restauration : des sauvegardes sont réalisées mais leur restauration n'est jamais testée, rendant le PRA théoriquement conforme mais opérationnellement inopérant.

Articulation avec le modèle Zero Trust

Le modèle Zero Trust est fréquemment présenté comme complémentaire au modèle de responsabilité partagée : là où ce dernier délimite les périmètres de responsabilité entre fournisseur et client, Zero Trust impose de ne faire confiance à aucun acteur par défaut, quelle que soit sa position dans l'architecture réseau. Les deux approches convergent sur l'exigence d'une gestion stricte des identités et des accès et d'une microsegmentation réseau fine, et forment ensemble une architecture de sécurité cloud cohérente.

Voir aussi