Le modèle de responsabilité partagée dans le cloud est l'un des concepts les plus importants en matière de sécurité du cloud, mais aussi l'un des plus souvent mal compris. Cette incompréhension suit un schéma bien précis : les entreprises partent du principe que le passage au cloud transfère au fournisseur une responsabilité en matière de sécurité plus importante qu'elle ne l'est en réalité. Cette hypothèse engendre des failles de sécurité que les pirates exploitent activement.
Gartner estime que d’ici 2026, 99 % des défaillances en matière de sécurité dans le cloud seront imputables aux clients, principalement en raison d’erreurs de configuration. Ce chiffre ne constitue pas une mise en cause de la sécurité du cloud. Il s’agit simplement d’une indication quant à la limite de la responsabilité. L’infrastructure du fournisseur de cloud est généralement bien sécurisée. Les erreurs de configuration, les compartiments de stockage exposés, les rôles IAM dotés de permissions excessives et les machines virtuelles non mises à jour relèvent presque tous de la responsabilité du client.
Ce guide précise clairement quelles sont les responsabilités des fournisseurs de services cloud, celles des clients et de leurs MSP, ainsi que la manière dont ces limites varient selon les différents modèles de services cloud. La plateforme de Kaseya couvre la partie client du modèle de responsabilité partagée pour plus de 50 000 MSP et équipes informatiques à travers le monde.
Le principe fondamental
Tous les grands fournisseurs de services cloud – AWS, Microsoft Azure et Google Cloud – publient un modèle de responsabilité partagée qui définit la répartition des tâches en matière de sécurité. Le principe est le même pour tous : le fournisseur assure la sécurité du cloud ; le client assure la sécurité de ce qui s'y trouve.
Les responsabilités du fournisseur couvrent l'infrastructure physique (centres de données, serveurs, matériel réseau), la couche d'hyperviseur, la structure réseau, ainsi que la disponibilité et la fiabilité des managed services propose. Tout ce qu'un client déploie au sein de l'environnement cloud – systèmes d'exploitation, applications, données, configuration des identités, contrôles d'accès au réseau – relève de la responsabilité du client ou de celle de son MSP.
En pratique, cela signifie qu'un environnement cloud n'est pas sécurisé par défaut. Sa sécurité dépend entièrement de la manière dont le client le configure. Une instance EC2 dont le système d'exploitation n'est pas mis à jour relève de la responsabilité du client. Un compartiment S3 dont l'accès public est activé relève de la responsabilité du client. Un rôle IAM doté de droits d'administrateur et associé à un service qui ne nécessite qu'un accès en lecture seule relève de la responsabilité du client. Le fournisseur de services cloud n'identifiera ni ne corrigera aucun de ces problèmes.
Comment la responsabilité varie selon le modèle de service
La délimitation exacte varie en fonction du modèle de service cloud utilisé. Plus le service se situe en amont de la pile, plus le fournisseur prend en charge de tâches, et moins le client a à gérer au niveau de l'infrastructure. Cependant, les données, l'identité et le contrôle d'accès restent de la responsabilité du client, quel que soit le modèle.
Infrastructure en tant que service (IaaS)
Le fournisseur gère l'infrastructure physique et la couche de virtualisation. Le client gère tout ce qui se trouve au-dessus : système d'exploitation, intergiciels, environnement d'exécution, applications, données et configuration réseau. C'est le modèle utilisé pour les machines virtuelles hébergées dans le cloud, telles que AWS EC2, Azure VM et Google Compute Engine.
Parmi tous les modèles de service, l'IaaS est celui qui confère la plus grande responsabilité au client. Un MSP qui gère l'environnement IaaS d'un client est entièrement responsable de l'ensemble des mesures de sécurité au-dessus de l'hyperviseur. Cela comprend les correctifs du système d'exploitation et des applications, la configuration des règles de pare-feu et des groupes de sécurité, le chiffrement des données au repos et en transit, la configuration de l'IAM (gestion des identités et des accès) et la journalisation. Aucune de ces tâches n'est prise en charge par le fournisseur.
Plateforme en tant que service (PaaS)
Le fournisseur gère également le système d'exploitation, les intergiciels et l'environnement d'exécution. Le client est responsable des applications et des données. Les services de bases de données gérés, Azure SQL Database, AWS RDS et les plateformes d'hébergement d'applications fonctionnent selon ce modèle.
Le PaaS allège considérablement la charge administrative. Les clients n'ont pas besoin d'appliquer des correctifs au système d'exploitation sous-jacent ni de gérer le moteur de base de données. Ils restent toutefois responsables de la sécurité des données, du contrôle d'accès, de la configuration au niveau des applications et de la sécurité du code des applications.
Logiciel en tant que service (SaaS)
Le fournisseur gère l'ensemble de la pile, de l'infrastructure jusqu'à l'application. Le client est responsable des données, de la gestion des accès et de la configuration des contrôles de sécurité de l'application.
Microsoft 365, Google Workspace et Salesforce sont tous des services SaaS. L'idée fausse la plus répandue à ce sujet est la suivante : comme le fournisseur gère l'application, les clients supposent qu'il assure également la protection des données. Or, ce n'est pas le cas. Microsoft est responsable de la disponibilité et de la fiabilité de la plateforme Microsoft 365. Les données contenues dans chaque tenant, ainsi que leur récupérabilité, relèvent de la responsabilité du client.
Une entreprise qui perd des données Microsoft 365 à la suite d'une suppression accidentelle en masse, d'une action malveillante d'un administrateur ou d'un ransomware chiffrant des fichiers OneDrive synchronisés ne peut pas compter sur les outils de conservation de Microsoft pour les récupérer. Ces outils sont axés sur la conformité et prévoient des délais de conservation courts ; ils ne sont pas conçus pour permettre une restauration opérationnelle à un moment précis.
Les lacunes les plus courantes en matière de partage des responsabilités
Comprendre le principe est une chose. Les failles qui apparaissent dans les environnements réels sont spécifiques et prévisibles. Ces cinq failles se retrouvent dans presque tous les environnements cloud qui n’ont pas fait l’objet d’une évaluation formelle.
Sauvegarde SaaS. L'idée fausse la plus répandue parmi tous les modèles de service. Microsoft et Google ne sauvegardent pas les données de Microsoft 365 ou de Google Workspace de manière à permettre une reprise opérationnelle en cas de suppression accidentelle, d'attaque par ransomware ou de compromission de compte. Datto SaaS Protection directement SaaS Protection ce besoin en sauvegardant les données de Microsoft 365 et de Google Workspace trois fois par jour vers un référentiel Datto Cloud indépendant et immuable, offrant une conservation illimitée et une restauration granulaire.
Configuration IAM. La gestion des identités et des accès, c'est-à-dire la définition des autorisations accordées à chaque utilisateur dans les environnements cloud, relève toujours de la responsabilité du client, quel que soit le modèle de service. Une mauvaise configuration IAM est la principale cause des violations de données dans le cloud. Un petit fournisseur de services gérés (MSP) qui prend en charge l'environnement AWS d'un nouveau client constate généralement que les rôles IAM disposent d'autorisations bien plus étendues que ne l'exigent les services qu'ils couvrent. La correction de ce problème est un travail fastidieux et peu gratifiant, mais qui s'impose dans presque tous les environnements.
Mise à jour des systèmes d'exploitation et des applications pour les charges de travail IaaS. Les machines virtuelles dans le cloud ne se mettent pas à jour automatiquement. Une instance AWS EC2 ou une machine virtuelle Azure exécutant un système d'exploitation non mis à jour est tout aussi vulnérable qu'un serveur sur site se trouvant dans la même situation. VSA et Datto RMM étendent la gestion automatisée des mises à jour aux terminaux hébergés dans le cloud en utilisant le même déploiement basé sur des agents et la même automatisation pilotée par des règles que ceux utilisés pour les serveurs sur site.
Configuration de la sécurité réseau. Les groupes de sécurité, les listes de contrôle d'accès réseau et la configuration des VPC/VNet relèvent de la responsabilité du client dans les environnements IaaS. Lors des évaluations d'environnements cloud, on constate régulièrement la présence de groupes de sécurité autorisant un accès entrant illimité sur les ports 22 ou 3389 ; ceux-ci sont systématiquement présents car ils ont été laissés ouverts à des fins de dépannage et n'ont jamais été fermés. Ces problèmes sont faciles à résoudre et doivent être traités en priorité.
Journalisation et surveillance. Les fournisseurs de services cloud mettent à disposition des journaux d'audit (AWS CloudTrail, Azure Monitor Activity Logs, Google Cloud Audit Logs), mais c'est au client qu'il incombe d'activer la journalisation, de stocker correctement les données et de surveiller les événements de sécurité. Un environnement cloud dans lequel la journalisation n'est pas activée constitue une impasse pour les enquêtes sur les incidents. La solution SIEM de Kaseya intègre les journaux des plateformes cloud ainsi que les données de télémétrie des terminaux et des e-mails, normalisant ainsi les événements de sécurité de tous les fournisseurs au sein d'une couche de détection unique.
Ce que cela implique pour la conception des services MSP
Le modèle de responsabilité partagée n'est pas seulement un concept de sécurité. Il s'agit d'un cadre de conception des services. Les MSP qui élaborent leurs offres de services en s'appuyant explicitement sur les catégories de responsabilité qu'ils couvrent sont en mesure de présenter clairement la valeur ajoutée à leurs clients. Ceux qui ne comprennent pas ce modèle risquent de présenter des lacunes non documentées dans leur couverture et de se retrouver confrontés à des discussions délicates lorsqu'un incident les mettra en évidence.
Une liste de contrôle pratique pour la mise en service de tout nouvel environnement cloud client, structurée autour du modèle de responsabilité partagée :
Pour les charges de travail IaaS :
- Déployez l'agent VSA ou Datto RMM sur toutes les machines virtuelles dans le cloud et intégrez-les aux politiques de gestion des correctifs existantes
- Vérifier les rôles IAM et les comptes de service ; répertorier et corriger les autorisations excessives
- Vérifier les configurations des groupes de sécurité et des listes de contrôle d'accès réseau ; fermer tout accès non restreint aux ports de gestion
- Vérifiez que la journalisation des audits est activée dans toutes les régions et que les journaux sont acheminés vers une destination indépendante et surveillée
- Vérifiez que la sauvegarde est configurée indépendamment du compte cloud et testez la restauration
Pour les environnements SaaS :
- Déployez Datto SaaS Protection Microsoft 365 et Google Workspace
- Vérifier les autorisations des comptes administrateur et appliquer l'authentification à deux facteurs (MFA) à tous les comptes privilégiés via Kaseya 365
- Répertorier les données stockées sur chaque plateforme SaaS et indiquer la procédure de restauration pour chacune d'entre elles
Pour tous les environnements cloud :
- Préciser et consigner par écrit les responsabilités couvertes par le MSP dans le contrat de service
- Vérifier les exigences de conformité (HIPAA, PCI DSS, CMMC, CCPA) applicables aux données hébergées dans le cloud et les mettre en correspondance avec les mesures de contrôle en place
- Ajouter l'architecture de l'environnement cloud et la structure IAM dans IT Glue le client
La phase de documentation revêt une importance qui va au-delà de la simple valeur opérationnelle. Lorsqu’un client doit faire face à une demande d’indemnisation au titre d’une cyberassurance ou à un audit de conformité, c’est souvent la capacité du MSP à fournir des preuves des contrôles de sécurité mis en place, ainsi que de la date à laquelle ils l’ont été, qui détermine l’issue de la situation.
Comment Kaseya 365 le côté client
Kaseya 365 propose des outils adaptés à chaque niveau de responsabilité du client dans les domaines IaaS, PaaS et SaaS.
VSA et Datto RMM automatisent la gestion des correctifs du système d'exploitation et des applications pour les machines virtuelles hébergées dans le cloud ainsi que pour les terminaux sur site, permettant ainsi de gérer l'application des correctifs IaaS à partir d'une seule console.
La solution Datto SaaS Protection prend en charge la protection des données SaaS pour Microsoft 365 et Google Workspace, avec trois sauvegardes quotidiennes, une durée de conservation illimitée et un stockage immuable géré de manière indépendante.
Kaseya 365 prend en charge la gestion des identités et des accès dans Microsoft 365 et les environnements cloud connectés, notamment l'application de l'authentification multifactorielle (MFA) et la surveillance Dark Web ID .
La solution SIEM de Kaseya prend en charge la journalisation et la surveillance, en intégrant les journaux d'audit des plateformes cloud ainsi que les données de télémétrie des terminaux et des e-mails au sein d'une couche de détection de sécurité unifiée.
IT Glue prend en charge la gestion de la documentation, en stockant l'architecture de l'environnement cloud, la structure IAM et les guides de reprise, avec une isolation par client et un accès contrôlé.
Kaseya Intelligence applique une reconnaissance automatique des modèles et une réponse automatisée dans les environnements cloud gérés, détectant les écarts de configuration du côté client de la frontière de responsabilité partagée et exécutant les mesures correctives sans attendre de vérification manuelle.
