Points clés
- Le fournisseur gère l’infrastructure, le client sécurise les données : les charges de travail, les données, les contrôles d’accès et la conformité relèvent du périmètre de responsabilité du client, quel que soit le fournisseur ou le modèle de service retenu.
- Le SaaS est souvent mal compris : les fournisseurs ne prennent pas en charge la sauvegarde ni la restauration, mais garantissent la disponibilité. Si des données sont supprimées ou corrompues, leur récupération dépend des dispositifs mis en place par le client.
- La responsabilité des données et des accès n’incombe pas au fournisseur : même lorsque celui-ci prend en charge une plus grande partie du stack, la gouvernance des identités, les politiques de rétention et les processus de conformité restent du ressort du client.
- Les environnements multicloud fragilisent la gouvernance quand les politiques sont gérées plateforme par plateforme : les politiques de sécurité, les modèles de GIA (gestion des identités et des accès) et les formats de journalisation diffèrent d’un fournisseur à l’autre.
- Les failles s’accumulent en l’absence d’une vue unifiée : sans visibilité centralisée, les manques et les dérives de configuration peuvent s’accumuler au fil du temps dans l’ensemble des environnements.
Aujourd’hui, la plupart des grandes entreprises transfèrent leurs charges de travail vers le cloud ou vers des environnements de travail numériques gérés par un fournisseur de services. Une idée reçue tenace accompagne ce mouvement : le fournisseur assumerait l’essentiel de la sécurité. C’est précisément là que naissent les problèmes de sécurité du cloud, avec des conséquences directes sur l’activité.
Ce guide explique le fonctionnement du modèle de responsabilité partagée. Il précise où se séparent les responsabilités du fournisseur et celles du client, et ce que les entreprises doivent faire pour préserver leur propre sécurité du cloud.
À quoi sert le modèle de responsabilité partagée ?
Le modèle de responsabilité partagée répartit les responsabilités entre le client et le fournisseur de services. Le fournisseur sécurise l’infrastructure sur laquelle repose le service cloud, tandis que le client sécurise tout ce qu’il y dépose.
Les fournisseurs sont responsables de :
- l’infrastructure physique et les centres de données : le matériel, les installations et les contrôles d’accès physiques qui soutiennent les services cloud.
- les fondations réseau et les hyperviseurs : la couche réseau centrale et le stack de virtualisation sur lesquels les clients construisent.
- la disponibilité de la plateforme : le maintien en fonctionnement des services cloud au niveau de l’infrastructure.
Les clients restent responsables de :
- l’accès utilisateur et l’identité : qui peut accéder aux ressources cloud, et dans quelles conditions.
- la configuration des charges de travail : la façon dont les machines virtuelles, les conteneurs et les services sont configurés et durcis.
- la protection des données et la gouvernance de la restauration : ce qui est sauvegardé, la durée de conservation et les modalités de restauration.
- les politiques de sécurité et l’alignement sur la conformité : garantir que les configurations et les contrôles répondent aux exigences internes et réglementaires.
À noter : la responsabilité de la sécurisation des charges de travail, des données et des droits d’accès reste au client, quel que soit le fournisseur utilisé.
Les responsabilités du client en matière de sécurité du cloud
Dans le modèle de responsabilité partagée, le fournisseur sécurise l’infrastructure. Tout ce qui est construit et exécuté par-dessus relève du client.
| Responsabilités | Détails |
| Gouvernance des identités et des accès | Contrôler qui a accès aux ressources cloud et appliquer le principe du moindre privilège à l’ensemble des comptes et des rôles. |
| MFA (authentification forte) et contrôle des accès privilégiés | Garantir que tout accès à privilèges élevés exige une vérification robuste et n’est accordé qu’en cas de besoin. |
| Configuration des charges de travail et durcissement du système d’exploitation | Mettre en place et maintenir des configurations sécurisées pour les machines virtuelles, les conteneurs et les services hébergés. |
| Rétention des données et sauvegarde | Définir ce qui est sauvegardé, la durée de conservation des données et le déroulement de la restauration le cas échéant. |
| Reporting de conformité et surveillance de la sécurité | Conserver des pistes d’audit, produire les rapports exigés et garder la visibilité sur ce qui se passe dans les environnements cloud. |
Les fournisseurs de cloud ne sécurisent pas automatiquement les charges de travail des clients et n’appliquent pas leurs processus de gouvernance : ce travail revient au client.
Le modèle de responsabilité partagée selon les types de services cloud
Il existe trois modèles de responsabilité partagée : Infrastructure as a Service (IaaS), Platform as a Service (PaaS) et SaaS.
Les responsabilités évoluent selon le modèle de service cloud utilisé. Plus le fournisseur gère, moins le client contrôle d’infrastructure. En revanche, la responsabilité fondamentale des données, des accès et de la gouvernance reste au client.
| Responsabilité | IaaS | PaaS | SaaS |
| Infrastructure physique | Fournisseur | Fournisseur | Fournisseur |
| Couche réseau et virtualisation | Fournisseur | Fournisseur | Fournisseur |
| Système d’exploitation | Client | Fournisseur | Fournisseur |
| Runtime et middleware | Client | Fournisseur | Fournisseur |
| Applications | Client | Client | Fournisseur |
| Gestion du stockage | Client | Client | Client |
| Gestion des identités et des accès | Client | Client | Client |
| Conformité et gouvernance | Client | Client | Client |
Infrastructure as a Service (IaaS)
Les fournisseurs d’IaaS offrent aux entreprises le plus haut niveau de contrôle sur leur environnement cloud, avec les responsabilités qui vont de pair. Ici, les clients gèrent :
- les systèmes d’exploitation et les mises à jour : le fournisseur fournit l’infrastructure, mais c’est au client d’installer, de configurer et de maintenir le système d’exploitation.
- les applications et la configuration des charges de travail : la manière dont les applications sont développées, déployées et sécurisées relève entièrement du client.
- la protection des données : la sauvegarde, le chiffrement et la planification de la restauration incombent au client dès le départ.
Des trois modèles de service, l’IaaS est celui qui fait peser la charge opérationnelle la plus lourde sur le client.
Platform as a Service (PaaS)
Le PaaS retire la gestion de l’infrastructure et du système d’exploitation de la liste des responsabilités du client. Celui-ci conserve toutefois :
- les applications : le client développe et déploie les applications sur la plateforme, et il lui revient de les sécuriser.
- les données : l’entreprise est responsable des données stockées, de leur protection et de leur durée de conservation.
- le contrôle des accès et la configuration des charges de travail : la gestion des autorisations d’accès à la plateforme et la façon dont les charges de travail sont configurées.
Déléguer la gestion de l’infrastructure ne revient pas à déléguer la responsabilité de ce que le client développe et exécute sur la plateforme.
SaaS (Software as a Service)
Le SaaS confie la gestion des applications et de l’infrastructure au fournisseur. D’où la confusion fréquente sur ce qui reste à la charge du client :
- la gouvernance des identités et la gestion des accès
- les politiques de rétention et la gouvernance des sauvegardes
- les processus de conformité
On suppose souvent, par exemple, que des fournisseurs SaaS comme Microsoft 365 ou Google Workspace sauvegardent automatiquement les e-mails et les fichiers. Les deux plateformes assurent la disponibilité, mais pas la sauvegarde. Si des données sont supprimées ou corrompues, la restauration dépend de l’existence d’une autre politique de sauvegarde côté client.
Découvrez NinjaOne Backup et NinjaOne Saas Backup
Simplifiez la sauvegarde de vos appareils, de vos serveurs et la sauvegarde SaaS grâce à une plateforme sécurisée qui comprend également une assistance pour la conformité pour Microsoft 365 et Google Workspace.
En savoir plus
Les difficultés de la gouvernance multicloud
Le modèle de responsabilité partagée s’applique chez tous les grands fournisseurs de cloud, mais sa mise en œuvre varie énormément. AWS, Azure et Google Cloud disposent par exemple chacun de leur propre modèle de GIA (gestion des identités et des accès), de leurs outils de journalisation, de leurs solutions de sauvegarde et de leurs contrôles de sécurité natifs.
Si vous exécutez des charges de travail chez plusieurs fournisseurs, vous devrez gérer ces différences en continu. Et c’est là que la gouvernance commence à se fissurer.
| Difficultés | Ce que cela implique |
| Journalisation fragmentée | Chaque fournisseur génère des journaux dans des formats et à des emplacements différents, ce qui rend difficile une visibilité unifiée sans outil d’agrégation centralisé. |
| Politiques incohérentes | Les politiques de sécurité configurées sur une plateforme ne se répercutent pas sur une autre. D’où des failles et des dérives de configuration lorsqu’une même norme doit s’appliquer chez plusieurs fournisseurs. |
| Prolifération des identités | Gérer des modèles de GIA (gestion des identités et des accès) distincts entre AWS, Azure et Google Cloud accroît le risque de comptes orphelins ou abandonnés, d’autorisations excessives et de contrôles d’accès incohérents. |
| Angles morts de la gouvernance | Sans visibilité centralisée via un logiciel RMM (surveillance et gestion à distance), des ressources non gérées et des erreurs de configuration sur une plateforme peuvent passer inaperçues alors que les autres environnements paraissent conformes. |
Centraliser la visibilité et les responsabilités entre les fournisseurs : voilà ce qui distingue les entreprises qui pilotent réellement leurs environnements multicloud de celles qui se contentent de les utiliser.
Les failles les plus courantes de la responsabilité partagée
La plupart des incidents de sécurité du cloud remontent aux mêmes malentendus sur ce que couvre réellement la responsabilité partagée en matière de sécurité du cloud. Voici quelques-unes des failles qui reviennent le plus souvent :
| Faille | Ce qui ne fonctionne pas |
| Croire que les fournisseurs assurent la sauvegarde et la restauration | Les fournisseurs protègent la disponibilité de l’infrastructure, pas les données du client. Sans politique de sauvegarde distincte, des données supprimées ou corrompues peuvent être irrécupérables. |
| Confondre disponibilité SaaS et capacité de restauration | Qu’une plateforme SaaS reste en ligne ne signifie pas que les données qu’elle héberge sont sauvegardées. La rétention et la restauration restent à la charge du client. |
| Négliger la gouvernance des identités | Des contrôles d’accès insuffisants, des autorisations excessives et des comptes jamais revus figurent parmi les causes les plus fréquentes d’incidents de sécurité dans le cloud. |
| Gouvernance fragmentée entre les plateformes cloud | Les politiques appliquées sur une plateforme ne se propagent pas automatiquement aux autres. Il en résulte des failles faciles à ignorer jusqu’à ce qu’un incident ou un audit les mette au jour. |
| Responsabilités opérationnelles floues | Quand personne n’a explicitement désigné le responsable d’une charge de travail ou d’un processus de gouvernance, les tâches correspondantes restent le plus souvent en suspens. |
Rendre la responsabilité cloud opérationnelle
Appliquer les bonnes pratiques de sécurité du cloud dans un environnement à responsabilité partagée suppose de définir les responsabilités avant l’apparition des problèmes, pas après.
Les entreprises matures sur le plan opérationnel privilégient :
- la gouvernance centralisée : gérer les politiques de sécurité, les contrôles d’accès et les exigences de conformité depuis un cadre unique, plutôt que de configurer chaque plateforme cloud séparément.
- la sécurité des identités : appliquer le principe du moindre privilège, revoir régulièrement les autorisations et veiller à ce que le MFA (authentification forte) soit appliqué de façon homogène à tous les comptes et rôles cloud.
- la responsabilité par charge de travail : attribuer un responsable clairement identifié à chaque charge de travail, afin que la configuration, les mises à jour et les revues de sécurité aient un référent nommé.
- la visibilité continue : surveiller les environnements cloud en temps réel pour détecter tôt les erreurs de configuration et les anomalies, au lieu de les découvrir lors d’un incident ou d’un audit.
- la préparation à la restauration : définir et tester les procédures de restauration pour chaque charge de travail et chaque jeu de données. Une sauvegarde jamais testée ne peut pas servir de garantie au moment où il faut réellement restaurer des données.
Les entreprises doivent également définir clairement :
- les obligations du fournisseur : ce dont le fournisseur de cloud est responsable au titre du contrat de service.
- les obligations du client : ce que l’entreprise prend en charge en matière de configuration, d’accès et de protection des données.
- les limites de responsabilité en matière de sécurité : là où s’arrête la responsabilité du fournisseur et où commence celle du client, pour chaque service utilisé.
- les responsabilités de gouvernance transverses : quelles équipes prennent en charge quels volets de la gouvernance du cloud, y compris la sécurité, les opérations et la conformité.
Une clarté opérationnelle sur tous ces points évite que les responsabilités ne passent entre les mailles du filet à mesure que les environnements cloud s’étendent.
Responsabilité partagée : ce que cela change pour la sécurité du cloud
Le modèle de responsabilité partagée définit qui prend en charge quoi dans un environnement cloud, et cette frontière ne se déplace pas selon l’étendue de ce que gère le fournisseur. Les entreprises restent responsables de leurs charges de travail, de leurs identités, de leurs données et de leur conformité, quel que soit le modèle de service ou le fournisseur retenu.
C’est la mauvaise lecture de ces frontières qui crée l’essentiel des failles de sécurité du cloud. Les entreprises qui définissent clairement les responsabilités et les traitent comme une charge opérationnelle permanente sont mieux placées pour maîtriser le risque cloud à mesure que leurs environnements grandissent.
Sujets connexes :
- Comment rendre opérationnel le modèle de responsabilité partagée de Microsoft 365
- Comment parler à vos clients de la responsabilité de sauvegarde dans Google Workspace
- Comment expliquer le modèle de responsabilité partagée de Microsoft 365 à vos clients
- Sauvegarde SaaS : guide complet et bonnes pratiques
