Le modèle de responsabilité partagée dans le cloud expliqué aux MSP

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 de ceux qui font le plus souvent l'objet d'une incompréhension. 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 part de 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 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 d’un constat sur la délimitation des responsabilités. 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 d’autorisations excessives, 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 la répartition des responsabilités évolue 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é de l'managed services s qu'il 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.

Conséquence pratique : un environnement cloud n’est pas sécurisé par défaut. Sa sécurité dépend 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é évolue 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 dans 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, les machines virtuelles Azure 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 de la pile de sécurité située au-dessus de l'hyperviseur. Cela inclut les correctifs du système d'exploitation et des applications, les règles de pare-feu et la configuration des groupes de sécurité, le chiffrement au repos et en transit, la configuration de la gestion des identités et des accès (IAM), ainsi que la journalisation. Aucun de ces aspects n'est pris 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 réduit 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 partent du principe 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’un administrateur malveillant 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é, avec des durées de conservation courtes, et ne sont pas conçus pour une restauration opérationnelle à un instant donné.

Les lacunes les plus courantes en matière de responsabilité partagée

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 n'assurent pas la sauvegarde des données de Microsoft 365 ou de Google Workspace d'une manière permettant une reprise opérationnelle en cas de suppression accidentelle, d'attaque par ransomware ou de compromission de compte. La solution Datto SaaS Protection répond directement à ce problème 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 (IAM ), 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 de l'IAM est la principale cause des fuites de données dans le cloud. Un petit prestataire de services gérés (MSP) chargé de prendre en charge l'environnement AWS d'un nouveau client constatera généralement que les rôles IAM disposent d'autorisations bien plus étendues que ne l'exigent les services qu'ils couvrent. Remédier à ce problème est un travail fastidieux et peu gratifiant, mais qui s'avère nécessaire dans presque tous les environnements.

Application des correctifs aux systèmes d'exploitation et aux applications pour les charges de travail IaaS. Les machines virtuelles (VM) dans le cloud ne s'appliquent pas automatiquement les correctifs. Une instance AWS EC2 ou une VM Azure exécutant un système d'exploitation non mis à jour est tout aussi vulnérable qu'un serveur sur site se trouvant dans le même état. VSA et Datto RMM étendent la gestion automatisée des correctifs 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 politiques 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. Les groupes de sécurité autorisant un accès entrant illimité sur les ports 22 ou 3389 sont systématiquement identifiés lors des évaluations d'environnements cloud ; leur présence récurrente s'explique par le fait qu'ils ont été laissés ouverts à des fins de dépannage et n'ont jamais été fermés. Ces problèmes sont faciles à corriger 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 les surveiller afin de détecter 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 télémétriques 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 peuvent présenter avec précision la valeur ajoutée qu'ils apportent à leurs clients. Les MSP 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éployer l'agent VSA ou Datto RMM sur toutes les machines virtuelles dans le cloud et les intégrer aux politiques de gestion des correctifs existantes
Auditer les rôles IAM et les comptes de service ; recenser les autorisations excessives et y remédier
Vérifier les configurations des groupes de sécurité et des listes de contrôle d'accès réseau (ACL) ; 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 une restauration

Pour les environnements SaaS :

Déployer Datto SaaS Protection pour Microsoft 365 et Google Workspace
Vérifiez les autorisations des comptes administrateur et imposez l'authentification à deux facteurs (MFA) pour tous les comptes privilégiés via l'utilisateur « Kaseya 365 ».
Répertorier les données stockées sur chaque plateforme SaaS et définir la procédure de restauration pour chacune d'entre elles

Pour tous les environnements cloud :

Définir et consigner les responsabilités prises en charge 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 à IT Glue pour le client

L'étape de documentation revêt une importance qui va au-delà de la simple valeur opérationnelle. Lorsqu'un client est confronté à 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 de leur mise en œuvre, qui détermine l'issue de la situation.

Comment « Kaseya 365 » couvre les besoins des clients

La plateforme « Kaseya 365 » propose des outils qui couvrent chaque niveau de responsabilité du client dans les environnements 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 La solution « User » prend en charge la gestion des identités et des accès au sein de Microsoft 365 et des environnements cloud connectés, notamment l’application de l’authentification à plusieurs facteurs (MFA) et la surveillance des identifiants d’ 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 couvre les obligations en matière de documentation, le stockage de 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 schémas et une réponse automatisée dans l'ensemble des environnements cloud gérés, en détectant les écarts de configuration du côté client de la frontière de responsabilité partagée et en mettant en œuvre des mesures correctives sans attendre une vérification manuelle.

Découvrez « Kaseya 365 » pour les environnements cloud et hybrides