Le casse-tête du multicloud et du multitenant pour les MSP ISO 27001
Le multicloud et le cloud public mutualisé complexifient la conformité à la norme ISO 27001, car les couches partagées et les frontières virtuelles amplifient l'impact des erreurs. Vous exécutez les charges de travail de vos clients sur AWS, Azure et Google Cloud tout en réutilisant les équipes, les outils et les plateformes de gestion ; une seule erreur peut donc affecter simultanément de nombreux clients. Pour rester conforme, votre système de management de la sécurité de l'information (SMSI) doit refléter cette réalité, considérer les couches partagées comme des risques majeurs et démontrer comment vous assurez la séparation des environnements clients. Cette exigence est conforme aux exigences de la norme ISO 27001:2022, qui vise à comprendre le contexte organisationnel, à définir le périmètre et à planifier le traitement et le contrôle des risques de manière à refléter vos pratiques de prestation de services, telles que décrites dans la norme.
Le cloud public peut rendre vos services plus évolutifs et rentables, mais il modifie également votre rapport aux risques liés à la norme ISO 27001, d'une manière souvent sous-estimée. Lorsque vous gérez des dizaines d'environnements clients sur plusieurs plateformes, le mutualisation, le partage d'outils et la complexité des flux de données créent des risques d'erreurs de configuration que l'ancienne version sur site de votre système de gestion de la sécurité de l'information (SGSI) n'aurait peut-être jamais envisagés. Si votre système de gestion repose encore sur une séparation physique et des infrastructures sur mesure pour chaque client, il aura du mal à décrire votre fonctionnement actuel.
Presque tous les répondants à l'enquête 2025 d'ISMS.online citent l'obtention ou le maintien de certifications de sécurité telles que l'ISO 27001 ou le SOC 2 comme une priorité absolue.
Pour un fournisseur de services gérés (MSP), le terme « multitenant » ne se limite pas à un simple terme logiciel. Il décrit l'ensemble de son modèle opérationnel : de nombreux clients partagent les mêmes plateformes cloud sous-jacentes, les mêmes équipes de support, les mêmes outils de supervision et souvent la même interface de gestion. La norme ISO 27001:2022 exige que vous compreniez ces couches partagées, que vous traitiez explicitement les risques associés et que vous démontriez comment vous empêchez les problèmes rencontrés par un client d'affecter un autre. Ceci découle directement de l'importance accordée par la norme à l'identification des risques liés à la sécurité de l'information découlant de votre contexte et de vos activités de traitement, ainsi qu'à la sélection et à la mise en œuvre de contrôles permettant de gérer ces risques de manière démontrable et conforme à la norme.
Une assurance cloud solide commence par décrire la réalité telle qu'elle est, et non telle que vous souhaiteriez qu'elle soit.
Pourquoi la multilocation modifie votre profil de risque
Le multitenant modifie votre profil de risque car l'isolation est désormais logique et non plus physique, et les composants partagés peuvent engendrer des défaillances à large rayon d'action. Au lieu de s'appuyer sur du matériel distinct par client, vous dépendez de configurations, d'identités et de plateformes centralisées ; une simple erreur peut donc compromettre vos hypothèses de séparation des locataires. La norme ISO 27001 exige que ce changement soit clairement visible dans vos évaluations des risques, vos mesures de contrôle et vos preuves. Ceci est conforme à l'approche fondée sur les risques de la norme ISO 27001:2022, qui vous impose d'analyser l'impact des évolutions technologiques et de la prestation de services sur les risques, puis de documenter les mesures de contrôle mises en place et les preuves justificatives dans votre plan de traitement des risques et votre déclaration d'applicabilité.
Dans un environnement sur site, chaque client disposait généralement de matériel, de réseaux et parfois même d'outils distincts. L'isolation était principalement physique. Dans le cloud public, l'isolation est logique et repose fortement sur la configuration et la gestion des identités et des accès (IAM). Cela entraîne trois changements majeurs pour la norme ISO 27001 :
-
Les limites des locataires sont en grande partie virtuelles.
Une configuration incorrecte des rôles, des groupes de sécurité ou des stratégies de stockage peut soudainement affecter plusieurs clients. La norme ISO 27001 exige que vous analysiez ce risque dans votre évaluation et que vous conceviez des mesures de contrôle permettant de le rendre improbable et détectable. -
Les composants partagés deviennent des atouts à fort impact.
Les systèmes de journalisation, les cibles de sauvegarde, les réseaux de gestion, les outils de surveillance et les fournisseurs d'identité sont désormais utilisés par de nombreux clients. Si l'un d'eux est compromis, les conséquences peuvent être importantes ; il est donc impératif que ces actifs figurent dans votre inventaire, votre registre des risques et votre déclaration d'applicabilité. -
La responsabilité est partagée en trois parties.
Pour chaque contrôle, vous devez déterminer ce qui relève du fournisseur de services cloud, ce qui vous incombe en tant que fournisseur de services gérés (MSP) et ce que votre client doit faire. Si cette répartition n'est pas claire, votre analyse des risques est incomplète et vos justificatifs seront contestés par les auditeurs. Les recommandations du secteur concernant les modèles de responsabilité partagée dans le cloud, notamment les ressources communautaires telles que la documentation OWASP sur la responsabilité partagée dans le cloud, soulignent la nécessité d'attribuer et de documenter la responsabilité de chaque activité entre le fournisseur, le MSP et le client afin d'éviter toute lacune.
Si vous ne tenez pas compte de ces évolutions au sein de votre système de gestion de la sécurité de l'information (SGSI), vous pourrez peut-être réussir un ou deux audits, mais il vous sera plus difficile de justifier vos décisions en cas de problème dans un environnement partagé.
Les points faibles typiques que les fournisseurs de services gérés négligent
Les points faibles typiques des environnements MSP de cloud public incluent une dépendance excessive aux certifications des fournisseurs, l'oubli des plateformes partagées dans l'inventaire des actifs et le fait de laisser les connaissances critiques entre les mains des individus plutôt que d'être intégrées au système de gestion de la sécurité de l'information (SGSI). Ces lacunes fragilisent des déclarations de conformité ISO 27001 pourtant solides et apparaissent souvent en premier lieu lors d'audits ou d'incidents.
Plusieurs schémas se répètent lorsque les fournisseurs de services gérés (MSP) migrent leurs services vers le cloud public et tentent de maintenir la norme ISO 27001 :
- Si le cloud est certifié, tout va bien.
Les certifications cloud couvrent le fournisseur ; vous devez toujours configurer et exploiter chaque environnement client en toute sécurité.
- Ne pas répertorier les plateformes partagées comme des actifs.
Le fait de traiter les plateformes de journalisation, de gestion ou de bastion centralisées comme une infrastructure générique laisse les risques et les contrôles liés à la mutualisation des ressources non documentés.
- Modèles d'isolement des locataires incohérents :
Le mélange de modèles dédiés et mutualisés sans schémas ou justifications standardisés rend les décisions d'isolation difficiles à expliquer et à défendre.
- Connaissances héroïques non documentées.
S’appuyer sur quelques ingénieurs seniors au lieu de rôles, de processus et de schémas documentés déconnecte le système de gestion de l’information de la réalité.
Il n’est pas nécessaire de tout régler d’un coup. Un objectif pratique pour le premier trimestre consiste à prendre en compte les risques liés à la mutualisation des ressources dans votre évaluation des risques, à identifier les plateformes partagées comme des actifs critiques et à documenter les principaux modèles d’utilisation que vous adoptez actuellement.
Demander demoRepenser le cloud comme une extension de votre périmètre SMSI
Considérer le cloud comme une extension de votre système de gestion de la sécurité de l'information (SGSI) signifie cesser de percevoir AWS, Azure et Google Cloud comme de simples fournisseurs et les intégrer pleinement à votre environnement. Les clauses de la norme ISO 27001:2022 relatives au contexte, au périmètre, aux risques et aux parties intéressées incitent naturellement à considérer les principales plateformes cloud comme faisant partie intégrante de votre système, et non comme des éléments périphériques. Lorsque votre périmètre reflète cette réalité, tout le reste devient plus facile à expliquer et à justifier.
Si votre système de gestion de la sécurité de l'information (SGSI) donne encore l'impression de gérer un ou deux centres de données avec quelques outils SaaS, il est probablement inadapté à votre environnement cloud public actuel. Un périmètre clair et adapté au cloud permet de définir les attentes des auditeurs, des clients et des équipes internes, et évite les désaccords ultérieurs quant à l'inclusion d'un service, d'une région ou d'un compte dans le périmètre. Sans cette clarté, vous risquez de créer des lacunes cachées, notamment lorsque les charges de travail des clients ou les plateformes de support ne sont pas couvertes par votre système documenté.
Dès lors que vous considérez le cloud public comme faisant partie de votre infrastructure, chaque compte, abonnement ou projet hébergeant des charges de travail gérées devient une infrastructure supplémentaire que vous devez comprendre, documenter et contrôler. Ce changement peut sembler purement administratif, mais il a des conséquences très concrètes sur la manière dont vous rédigez vos politiques, suivez vos actifs, gérez vos fournisseurs et expliquez votre stratégie de sécurité à vos clients.
Actualisation de votre énoncé de portée pour le cloud public
Mettre à jour votre déclaration de périmètre pour le cloud public implique de préciser clairement quels services, environnements et parties sont couverts par votre SMSI. Au lieu de vous contenter de lister les centres de données, vous devez nommer les comptes cloud et décrire comment les nouveaux environnements sont inclus dans le périmètre. Cela permet aux auditeurs et aux clients de bien cerner vos responsabilités.
Votre énoncé de portée doit répondre à trois questions :
- Quels services sont couverts ?
Pour un fournisseur de services gérés (MSP), cela inclut généralement l'hébergement géré, la surveillance, la sauvegarde, les opérations de sécurité, le service d'assistance et tous les portails clients que vous hébergez ou exploitez.
- Quels environnements sont concernés ?
Au lieu de vous limiter aux centres de données, il convient de mentionner les comptes cloud, les abonnements et les projets. Dans la mesure du possible, décrivez comment les nouveaux environnements sont automatiquement inclus dans le périmètre dès lors qu'ils répondent à certains critères, comme l'hébergement de données de production client.
- Quelles parties et quels lieux sont concernés ?
Cela inclut votre propre organisation, les environnements clients que vous gérez, les principaux fournisseurs (principaux fournisseurs de cloud, outils SaaS essentiels) et, le cas échéant, des considérations géographiques telles que la résidence des données.
Une manière simple de mettre à jour votre périmètre consiste à considérer chaque compte cloud, abonnement ou projet hébergeant des charges de travail client gérées comme une « installation de traitement de l'information » au sens de la norme ISO 27001. Cette formulation permet d'aligner le périmètre sur la norme et facilite la justification de l'application de certains contrôles.
Ajustement de la gestion des risques, des actifs et des fournisseurs
Adapter la gestion des risques, les actifs et les fournisseurs au cloud implique de faire en sorte que vos processus ISO 27001 existants soient en phase avec les spécificités des comptes, des régions et des services gérés. Au lieu de dissimuler les risques liés au cloud sous l'appellation générique de risques d'externalisation, vous les intégrez explicitement à votre méthodologie, votre inventaire et vos niveaux de fournisseurs, afin que les clauses 4, 5 et 6 restent en phase avec votre mode de fonctionnement réel.
Une forte majorité d'organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information affirment que la rapidité et l'ampleur des changements réglementaires rendent la conformité plus difficile à maintenir.
Une fois que le cloud apparaît explicitement dans le périmètre, plusieurs éléments de soutien du SMSI doivent être mis à jour :
- Méthodologie des risques :
Les risques spécifiques au cloud, tels que les pannes régionales, les modifications des services gérés, les problèmes de fédération d'identité et le risque de concentration sur un seul fournisseur, doivent apparaître comme des éléments nommés, et non comme des risques génériques liés à l'externalisation.
- Inventaire des actifs :
Les services cloud, les plans de gestion partagés, les zones d'atterrissage et les configurations de référence doivent être répertoriés comme des actifs avec leurs propriétaires, leur classification et leurs états de cycle de vie.
- Gestion des fournisseurs :
Les principaux fournisseurs de services cloud appartiennent à un niveau de criticité élevé, nécessitant une diligence raisonnable plus approfondie et une surveillance continue, tandis que les outils SaaS à moindre risque se trouvent dans des niveaux moins critiques.
- Déclaration d'applicabilité :
Les contrôles comportant une dimension cloud, notamment l'annexe A 5.23 relative à l'utilisation des services cloud, doivent comporter des notes explicites sur leur application aux services et configurations cloud. Les organismes qui publient des correspondances entre les contrôles de l'annexe A et les configurations de plateformes cloud, comme les documents techniques sur la cartographie des contrôles cloud émanant d'organismes indépendants tels que MITRE, soulignent l'importance de préciser comment les objectifs, tels que l'annexe A 5.23, sont atteints dans des services et des environnements spécifiques, notamment dans des documents de cartographie des contrôles cloud. Les correspondances exactes dépendant toujours de vos architectures, il convient de considérer les exemples comme des modèles plutôt que comme des prescriptions figées.
Au cours du prochain trimestre, veillez à mettre à jour votre énoncé de portée, votre méthodologie de gestion des risques, votre inventaire des actifs et vos niveaux de fournisseurs afin qu'ils reflètent explicitement les plateformes cloud dont vous dépendez.
La norme ISO 27001 simplifiée
Une avance de 81 % dès le premier jour
Nous avons fait le plus gros du travail pour vous, en vous offrant une avance de 81 % dès votre connexion. Il ne vous reste plus qu'à remplir les champs.
Conception d'architectures multi-locataires conformes à la norme ISO 27001 (AWS, Azure, GCP)
Concevoir des architectures mutualisées conformes à la norme ISO 27001 implique de choisir un nombre restreint de modèles qui équilibrent sécurité, coût et complexité, puis de les appliquer de manière cohérente. Au lieu de laisser chaque équipe inventer son propre modèle mutualisé, vous standardisez des approches mutualisées, cloisonnées et hybrides que vous pouvez expliquer en termes ISO, documenter et relier aux risques et aux contrôles de votre système de management de la sécurité de l'information (SMSI).
Une fois le périmètre et les risques clairement définis, l'étape suivante consiste à retenir un nombre restreint de modèles mutualisés que vous pouvez justifier techniquement et lors d'un audit. Tenter de prendre en charge toutes les structures possibles engendre des exceptions, une dette technique et des difficultés d'audit. Si vous pouvez présenter une liste restreinte de modèles, expliquer leur utilisation et démontrer leur lien avec vos évaluations des risques, vos architectures cloud seront bien plus faciles à justifier.
Dans le cloud public, la conception mutualisée repose généralement sur le choix entre trois modèles principaux : mutualisé, cloisonné et hybride. La norme n’impose pas de modèle prédéfini, mais exige que vous fassiez des choix délibérés, que vous les documentiez et que vous gériez les risques résiduels. Ceci est conforme à l’approche de la norme ISO 27001:2022, qui est indépendante de toute technologie, tout en vous imposant de sélectionner et de justifier les mesures de contrôle et les traitements en fonction des risques documentés et du modèle opérationnel choisi, tel que décrit dans la norme.
Comparaison des modèles mutualisés, cloisonnés et hybrides
Comparer les modèles mutualisés, cloisonnés et hybrides vous aide à déterminer les architectures les plus adaptées à chaque service et niveau de risque. Les architectures mutualisées privilégient l'efficacité et l'isolation logique, les architectures cloisonnées privilégient des limites plus claires, et les architectures hybrides combinent outils partagés et plans de données séparés. La norme ISO 27001 n'impose aucun modèle, mais exige que vous justifiiez votre choix et gériez les risques associés.
Voici une vue simplifiée des compromis auxquels vous êtes confrontés :
| Modèle | Sécurité et assurance | Coût et effort opérationnel |
|---|---|---|
| Groupé | Dépend fortement de l'isolement logique et des tests ; plus difficile à justifier pour les données à haut risque. | Utilisation efficace des ressources ; plus simple à exploiter à plus petite échelle. |
| En silo | Des limites d'isolation plus claires ; souvent plus faciles à expliquer aux auditeurs et aux organismes de réglementation. | Coût plus élevé par locataire ; plus d'environnements à gérer. |
| Hybride | Il permet d'équilibrer l'isolation des éléments critiques et le partage des composants pour plus d'efficacité. | La complexité de la conception et de la gouvernance augmente ; des modèles robustes sont nécessaires. |
- Modèle groupé :
De nombreux clients partagent la même infrastructure, la même application et la même base de données, la séparation étant assurée par des identifiants de locataire, la sécurité au niveau des lignes, les schémas ou les espaces de noms. Vous devez démontrer comment le contrôle d'accès, les tests et la surveillance réduisent les risques d'exposition entre locataires.
- Modèle en silo.
Chaque client dispose de son propre compte, abonnement ou projet, souvent avec sa propre base de données et parfois sa propre instance des services essentiels. Cette approche est avantageuse pour les secteurs à haut risque car l'isolation est plus facile à appréhender. Il est néanmoins indispensable de démontrer comment vous garantissez des configurations de référence cohérentes et évitez les dérives de configuration.
- Modèle hybride :
Les plans de contrôle et les outils partagés alimentent des plans de données segmentés, tels que des comptes, des réseaux ou des bases de données par locataire. Vous devez démontrer comment vous protégez et surveillez les composants partagés et limitez l'impact des défaillances partagées.
La plupart des fournisseurs de services gérés (MSP) finissent par utiliser une approche mixte : des modèles mutualisés pour les services à faible risque et à volume élevé, et des modèles cloisonnés ou hybrides pour les offres à haute fiabilité. L’important, pour la norme ISO 27001, est de définir quels services utilisent quel modèle et pourquoi, de documenter les risques et les contrôles pour chacun, et d’appliquer les modèles de manière cohérente.
Utiliser des éléments constitutifs du cloud de manière compatible avec les normes ISO
Utiliser les composants du cloud de manière conforme aux normes ISO implique d'aligner les architectures AWS, Azure et Google Cloud sur les principes de contrôle de l'Annexe A, tels que le contrôle d'accès, la segmentation, la journalisation et la gestion des fournisseurs. En expliquant les comptes, les abonnements, les projets et les groupes de gestion dans ce langage, vous transformez la terminologie parfois complexe du cloud en un cadre de sécurité cohérent.
Chaque grand nuage de points possède sa propre terminologie et ses propres caractéristiques, mais les principes alignés sur l'ISO sont similaires :
- On AWSPlusieurs comptes au sein d'une même organisation, avec des garde-fous centraux, assurent l'isolation des locataires, tandis que les outils partagés résident dans des comptes de gestion distincts.
- On AzureLes locataires, les groupes de gestion et les abonnements d'Entra assurent la hiérarchie ; de nombreux MSP utilisent un modèle d'abonnement par client avec des services de gestion partagés.
- On Google CloudLes organisations, les dossiers et les projets créent des couches ; un modèle projet par locataire avec journalisation centralisée et réseau partagé est courant.
Dans tous les cas, il est essentiel de formaliser les modèles choisis dans des documents d'architecture, des diagrammes et des modèles d'infrastructure en tant que code. Vous pourrez ainsi démontrer aux auditeurs que vos conceptions étaient intentionnelles, revues, liées aux évaluations des risques et mises en œuvre de manière cohérente.
Intégrer la sécurité dans les pipelines et la documentation
L'intégration de la sécurité dans les pipelines et la documentation transforme vos modèles mutualisés en pratiques reproductibles et auditables. Au lieu de s'appuyer sur des configurations ponctuelles, vous imposez l'isolation, la journalisation et l'étiquetage du code et conservez un historique clair des modifications apportées et de leurs raisons. Ceci répond directement aux exigences de la norme ISO 27001 en matière de gestion des changements, de planification opérationnelle et d'évaluation des performances.
Étape 1 – Intégrer des garde-fous dans le code d'infrastructure
Utilisez des modèles, des politiques et des règles de configuration pour appliquer des normes de base en matière d'isolation, de chiffrement, de journalisation et d'étiquetage chaque fois que vous créez un nouvel environnement.
Étape 2 – Intégrer les contrôles de sécurité dans l’intégration continue et le déploiement continu (CI/CD)
Analysez automatiquement le code d'infrastructure et les configurations cloud pour détecter les problèmes susceptibles de compromettre la séparation des locataires ou d'autres contrôles clés avant que les modifications ne soient mises en production.
Étape 3 – Consigner les décisions et les menaces dans la documentation
Consignez les raisons de votre choix pour chaque modèle, les menaces que vous avez prises en compte et les contrôles sur lesquels vous vous appuyez, en utilisant des comptes rendus de décision concis et des modèles de menaces.
Pour le prochain trimestre, fixez-vous comme objectif réaliste de standardiser deux ou trois modèles de locataires, de les consigner dans du code et des diagrammes, et de les relier à vos évaluations des risques et aux contrôles de l'annexe A.
Mise en correspondance de l'annexe A de la norme ISO 27001:2022 avec les services et modèles cloud
L'association de l'annexe A de la norme ISO 27001:2022 aux services et modèles cloud permet d'établir un langage commun entre auditeurs et ingénieurs. Au lieu de débattre de l'applicabilité d'un contrôle, on se réfère à une matrice simple indiquant quels services AWS, Azure et Google Cloud, leurs référentiels et leurs rapports répondent à chaque objectif. Ceci fluidifie les audits et rend la gestion des changements plus prévisible.
La norme ISO 27001:2022 ne vous impose ni le service cloud à utiliser ni la configuration d'une règle de pare-feu. Elle définit des objectifs de contrôle et vous laisse le choix des moyens techniques. C'est un choix délibéré : l'ISO 27001:2022 se concentre sur le « quoi » de la sécurité de l'information (gestion des risques, objectifs de contrôle et amélioration continue) et reste technologiquement neutre. Vous pouvez ainsi décider du « comment » mettre en œuvre ces objectifs sur les plateformes de votre choix, conformément à la norme. Dans un environnement MSP complexe, la seule solution pratique pour une gestion efficace consiste à élaborer une cartographie simple des contrôles et des services, fiable pour les ingénieurs et exploitable par les auditeurs.
Cette cartographie fait le lien entre le langage utilisé par les auditeurs (contrôles de l'annexe A) et celui de vos ingénieurs (services cloud, API, configurations de référence). Sa mise à jour vous permet également de faciliter l'intégration à d'autres référentiels tels que SOC 2 ou les normes sectorielles.
Élaboration d'une matrice de contrôle et de service
L'élaboration d'une matrice de contrôles et de services consiste à identifier les contrôles de l'annexe A qui reposent fortement sur le cloud, puis à répertorier les services, configurations et processus nécessaires à leur mise en œuvre. En réalisant cette opération une fois pour toutes et en la maintenant à jour, vous simplifierez considérablement les audits et les mises en correspondance avec les référentiels ultérieurs.
Un point de départ utile consiste à se concentrer sur les thèmes de l'annexe A qui changent le plus lors du passage au cloud public, tels que :
- Contrôle d'accès et identité.
Les contrôles relatifs à l'accès des utilisateurs, à l'accès privilégié et à l'authentification correspondent aux fournisseurs d'identité, au contrôle d'accès basé sur les rôles, à l'authentification multifacteurs et aux revues d'accès dans vos plateformes cloud.
- Journalisation et surveillance :
Les contrôles relatifs à la journalisation des événements, à la surveillance et à la détection des anomalies sont associés aux services de journalisation dans le cloud, au SIEM centralisé, aux alertes et aux procédures d'exécution pour la gestion des incidents.
- Sauvegarde, restauration et suppression des données :
Les contrôles relatifs à la sauvegarde, aux tests de restauration, à la conservation et à la suppression sécurisée correspondent aux politiques de snapshots, aux outils de sauvegarde, aux règles de cycle de vie et aux procédures d'assainissement des données.
- Utilisation des fournisseurs et du cloud :
Les contrôles relatifs à l’utilisation des services cloud, y compris l’annexe A 5.23, correspondent à votre processus de sélection des services cloud, d’évaluation de la responsabilité partagée et de surveillance de l’assurance du fournisseur.
Pour chaque contrôle, vous listez ensuite les services cloud et les configurations sur lesquels vous vous appuyez.
Étape 1 – Choisissez les thèmes de contrôle axés sur le cloud
Identifiez les thèmes de contrôle de l'annexe A qui évoluent le plus dans le cloud, tels que le contrôle d'accès, la journalisation, la sauvegarde et l'utilisation du cloud, et hiérarchisez-les dans votre matrice.
Étape 2 – Relier chaque commande aux services concrets
Pour chaque contrôle prioritaire, consignez l'identité, les services de journalisation, de sauvegarde ou de gestion, ainsi que les configurations clés qui le rendent efficace dans AWS, Azure ou Google Cloud.
Étape 3 – Déterminer ce qui constitue une preuve
Définissez les captures d'écran, les exportations de configuration, les journaux, les rapports ou les enregistrements ISMS que vous utiliserez pour prouver que chaque contrôle est mis en œuvre et opérationnel. Les correspondances exactes varient selon les fournisseurs de services gérés ; utilisez donc ce guide et adaptez-le à vos architectures.
L'objectif n'est pas de créer un immense tableau Excel, mais de rendre explicite la relation entre les contrôles et la réalité du cloud, afin de pouvoir identifier les lacunes et expliquer la conception aux auditeurs.
Harmoniser les données de référence, les cadres et les preuves
En harmonisant les référentiels, les cadres de référence et les données probantes autour de votre matrice, vous en faites un outil du quotidien plutôt qu'un exercice ponctuel. Lorsque vous modifiez une configuration standard, adoptez un nouveau cadre de référence ou préparez un audit interne et une revue de direction, vous consultez la même matrice au lieu de repartir de zéro.
Une fois que vous disposez d'une matrice de base, trois avantages pratiques en découlent :
-
Les référentiels techniques deviennent plus faciles à justifier.
Lorsque vous mettez à jour une version standard (par exemple, pour exiger le chiffrement partout), vous pouvez rapidement voir quels contrôles sont affectés et mettre à jour votre documentation en conséquence. -
Les cadres externes se chevauchent plus facilement.
L'association des contrôles ISO aux référentiels cloud permet à un seul ensemble de normes techniques de satisfaire plusieurs cadres de référence, réduisant ainsi les doublons. -
Les preuves deviennent prévisibles.
Pour chaque contrôle de la matrice, vous pouvez définir les preuves que vous utiliserez : exportations de configuration, captures d’écran, journaux, documents de politique, rapports d’outils de surveillance ou résultats de votre plateforme ISMS.
Une plateforme ISMS dédiée, telle que ISMS.online, peut vous faciliter la tâche en centralisant la gestion des contrôles, des ressources cloud et des preuves, au lieu de les disperser dans des tableurs, des diagrammes et des outils de suivi des incidents. Dans les prochains mois, élaborez une première matrice pour vos services les plus importants et affinez-la au fur et à mesure de l'évolution de vos architectures.
Libérez-vous d'une montagne de feuilles de calcul
Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.
Mise en œuvre du modèle de responsabilité partagée dans les clouds
Mettre en œuvre le modèle de responsabilité partagée entre les clouds signifie transformer les schémas des fournisseurs en une appropriation concrète pour vous et vos clients. Au lieu de déclarations vagues sur la « sécurisation du cloud », vous disposez de matrices claires indiquant les responsabilités de chacun pour chaque service et vous veillez à ce que vos contrats, procédures et évaluations des risques soient alignés sur cette répartition.
Chaque grand fournisseur de cloud publie un modèle de responsabilité partagée. Des acteurs majeurs comme AWS, Microsoft Azure et Google Cloud publient chacun leur propre modèle, et des organisations sectorielles telles que la Cloud Security Alliance expliquent comment les communiquer et les mettre en œuvre concrètement, notamment via son blog dédié à la communication sur la responsabilité partagée dans le cloud. En résumé, tous ces modèles sont similaires : le fournisseur sécurise le cloud, vous sécurisez les données que vous y stockez. L’ajout des services de services gérés (MSP) et des obligations du client complexifie la situation et renforce l’importance de la norme ISO 27001.
La norme ISO 27017, extension de la norme ISO 27001 relative à la sécurité du cloud, vise principalement à clarifier ces distinctions. Les recommandations en matière de sécurité du cloud et les références relatives à la responsabilité partagée, notamment les travaux de la communauté tels que les documents de l'OWASP sur la responsabilité partagée dans le cloud, soulignent le rôle de l'ISO 27017 dans la clarification des responsabilités des fournisseurs et des clients pour les services cloud et dans l'aide apportée aux organisations pour appliquer les principes de l'ISO 27001 dans les environnements hébergés. Même sans certification formelle, les concepts de l'ISO 27017 sont utiles pour votre système de management de la sécurité de l'information (SMSI) et peuvent vous aider à expliquer plus clairement votre modèle aux auditeurs, aux clients et aux parties prenantes juridiques ou chargées de la protection des données, soucieuses d'une responsabilité justifiée.
Transformer les diagrammes de responsabilités partagées en une répartition concrète des responsabilités implique de consigner, pour chaque service géré, les tâches relevant du fournisseur, de vous et du client. Une fois ces attributions formalisées et mises à jour dans votre système de management de la sécurité de l'information (SMSI), il devient beaucoup plus simple de répondre aux questions des auditeurs concernant les responsables de chaque contrôle.
Environ 41 % des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online ont déclaré que la gestion des risques liés aux tiers et le suivi de la conformité des fournisseurs constituent l'un de leurs plus grands défis en matière de sécurité de l'information.
Pour chaque service majeur que vous proposez (hébergement géré, surveillance de la sécurité, sauvegarde, gestion des identités, gestion des terminaux), vous devriez être en mesure de répondre à trois questions :
- De quoi le fournisseur de services cloud est-il responsable ?
- De quoi êtes-vous responsable en tant que fournisseur de services gérés (MSP) ?
- De quoi le client est-il responsable ?
La méthode la plus pratique pour consigner ces informations consiste à utiliser une matrice des responsabilités simple (souvent appelée RACI : responsable, redevable, consulté, informé) pour chaque service ou catégorie de services. Cette matrice doit être alignée sur :
- Vos contrats et descriptions de services.
- Vos politiques et procédures internes.
- Vos évaluations des risques et vos plans de traitement.
- Votre modèle de contrôle et de preuves.
Lorsque les auditeurs constatent la présence d'un ensemble clair et cohérent de matrices correspondant à vos opérations et documents réels, ils acquièrent la certitude que vous comprenez et gérez la responsabilité partagée.
Intégrer la responsabilité partagée dans les contrats et le travail quotidien
L'intégration de la responsabilité partagée dans les contrats et les activités quotidiennes donne tout son sens aux matrices RACI. Au lieu de rester cantonnées à un simple tableur, les responsabilités sont désormais intégrées aux documents juridiques, aux procédures opérationnelles et aux supports de formation, garantissant ainsi que chacun agisse conformément aux engagements pris envers les clients et les auditeurs.
La responsabilité partagée doit être visible à deux endroits :
-
Engagements envers la clientèle.
Les contrats, les cahiers des charges, les descriptions de services et les annexes relatives à la sécurité de l'information doivent indiquer qui fait quoi et dans quelles conditions. -
Procédures internes et formations.
Les manuels d'exploitation, les procédures d'incident, les supports d'intégration et les réunions d'équipe doivent faire référence aux mêmes répartitions, afin que les ingénieurs et les équipes de support sachent quelles actions leur incombent et lesquelles doivent être remontées.
Votre système de gestion de la sécurité de l'information (SGSI) assure la cohérence entre ces deux visions. Lorsque le modèle de responsabilité évolue (par exemple, si vous prenez en charge une plus grande partie de la configuration de sécurité du client), votre périmètre, vos risques, vos procédures et vos contrats doivent évoluer en conséquence.
Au cours du prochain trimestre, un objectif réaliste consiste à élaborer des matrices RACI pour vos trois principaux services cloud, à mettre à jour les clauses contractuelles correspondantes et à informer vos équipes afin qu'elles comprennent les nouvelles répartitions. Pour les responsables de la protection des données et les juristes, cet alignement renforce également votre position si une autorité de régulation examine ultérieurement les responsabilités liées à un contrôle particulier.
Conformité continue : gouvernance, surveillance et preuves
La conformité continue dans le cloud public implique d'intégrer la gouvernance ISO 27001 à vos systèmes de surveillance, de reporting et d'automatisation existants. Au lieu de vous préparer à des audits annuels, concevez vos tableaux de bord, alertes et revues de manière à ce qu'ils démontrent également l'efficacité des contrôles, facilitent les audits internes et alimentent les revues de direction.
Les environnements de cloud public évoluent constamment. De nouveaux services apparaissent, les services existants s'enrichissent de nouvelles fonctionnalités, les charges de travail des clients migrent et la réglementation évolue. Un programme ISO 27001 mis en place uniquement avant un audit ne peut suivre ce rythme. Pour les fournisseurs de services gérés (MSP), la solution consiste à intégrer la gouvernance ISO 27001 aux mêmes mécanismes de surveillance, de reporting et d'automatisation utilisés pour l'exploitation des services, afin que l'assurance qualité devienne un sous-produit naturel d'une gestion efficace.
La conformité continue est plus facile lorsqu'elle repose sur des systèmes que vous utilisez déjà en toute confiance.
Concevoir un système de surveillance qui serve également de preuve
Concevoir une surveillance qui serve également de preuve implique de planifier vos indicateurs et alertes afin qu'ils démontrent le bon fonctionnement du système de contrôle tout en assurant la disponibilité des services. Si vos tableaux de bord indiquent déjà si les sauvegardes ont été effectuées, si les accès ont été vérifiés et si les incidents ont été gérés conformément au plan, vous aurez moins de travail supplémentaire à fournir pour l'évaluation des performances selon la norme ISO 27001.
La plupart des organisations interrogées dans le cadre de l'enquête 2025 d'ISMS.online sur l'état de la sécurité de l'information déclarent avoir déjà été touchées par au moins un incident de sécurité lié à un tiers ou à un fournisseur au cours de l'année écoulée.
Lors de la définition des exigences de surveillance, veillez à satisfaire à la fois les objectifs opérationnels et les objectifs ISO :
- Alertes cartographiques vers les commandes :
Pour chaque contrôle clé, assurez-vous qu'il existe une mesure ou une alerte correspondante ; des alertes fréquentes peuvent indiquer que le contrôle est inefficace.
- Centralisez soigneusement la visibilité inter-locataires.
Utilisez un système de journalisation et de surveillance centralisé pour visualiser l'activité de tous les clients, mais limitez l'accès par rôle afin de respecter l'isolement et la confidentialité.
- Saisir le contexte à travers les événements :
Enrichissez les journaux avec des informations pertinentes pour les audits, telles que la politique qui a déclenché une correction ou la demande de changement qui a approuvé une modification de configuration.
Étape 1 – Déterminer les commandes qui nécessitent une surveillance directe
Identifier les contrôles d'accès, de modification, de sauvegarde et liés aux incidents pour lesquels les indicateurs ou les alertes démontreront le mieux leur efficacité au fil du temps.
Étape 2 – Concevoir des tableaux de bord et des alertes en fonction de ces commandes
Configurez les tableaux de bord et les alertes afin qu'ils affichent l'état des contrôles, les tendances et les valeurs aberrantes dans un langage compréhensible par vos dirigeants et vos auditeurs.
Étape 3 – Réutiliser les résultats du suivi dans le cadre de l’audit interne et de la revue
Intégrez les rapports de suivi dans les audits internes et les revues de direction afin que l'évaluation des performances au titre de la clause 9 soit fondée sur des données réelles et non sur des opinions.
Si vous pouvez démontrer à un auditeur que vos tableaux de bord et vos rapports répondent déjà à ses questions sur le fonctionnement des contrôles, la frontière entre les opérations et la conformité devient agréablement ténue.
Automatisation, rapports et déclencheurs de changement
L'automatisation, le reporting et les déclencheurs de changement sont essentiels pour garantir une conformité continue et durable au sein de nombreux environnements. Au lieu de vérifier manuellement chaque environnement, vous définissez des référentiels dans le code, synthétisez l'état des contrôles pour la direction et définissez des conditions claires pour la réévaluation des risques et des contrôles.
Pour garantir que de nombreux locataires respectent vos engagements ISO 27001, un contrôle manuel ne suffit pas. Vous aurez besoin de :
- Automatisation pour faire respecter les normes de référence :
Les outils de gestion de la configuration, de la politique en tant que code et de la correction des dérives permettent de maintenir les environnements alignés sur vos normes et d'enregistrer les corrections apportées.
- Rapports réguliers de gouvernance :
Les tableaux de bord et les synthèses destinés à la direction comprennent l'état des contrôles, les exceptions, les tendances et les traitements des risques en suspens, alimentant la clause 9 et la revue de direction.
- Effacer les déclencheurs pour revenir sur les commandes :
Les nouveaux services cloud, les changements majeurs d'architecture, les alertes récurrentes ou les évolutions réglementaires doivent tous déclencher un examen de vos évaluations et contrôles des risques.
Une plateforme comme ISMS.online vous permet de relier ces signaux opérationnels à votre système de gestion de la sécurité de l'information (SGSI), en associant risques, contrôles, actions et preuves. Ainsi, votre SGSI reflète fidèlement la réalité du cloud. Dans les prochains mois, identifiez quelques contrôles clés, intégrez-les à votre système de surveillance et d'automatisation, et assurez-vous que les rapports générés alimentent vos cycles d'audit interne et de revue de direction. Pour les professionnels de l'informatique et de la sécurité, cela réduit les vérifications manuelles fastidieuses et transforme un travail d'ingénierie de qualité en résultats concrets de conformité.
Gérez toute votre conformité, en un seul endroit
ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.
Transformer « l’ISO dans le cloud » en un avantage commercial
Transformer la certification ISO dans le cloud en un avantage concurrentiel implique de considérer votre système de gestion de la sécurité de l'information (SGSI) adapté au cloud comme un élément de votre offre, et non comme un simple label de conformité. Au lieu de dissimuler vos pratiques derrière un certificat, vous mettez en avant les options d'isolation, les outils d'assurance qualité et une gouvernance réactive comme autant de fonctionnalités qui simplifient la vie de vos clients et renforcent la confiance.
De nombreux fournisseurs de services gérés (MSP) considèrent la norme ISO 27001 comme un gage de qualité indispensable pour remporter des appels d'offres. Dans un contexte de cloud public moderne, son importance va bien au-delà : elle peut devenir un moyen de différencier vos services, de fluidifier le processus de vente et d'instaurer une relation de confiance durable. Les documents sectoriels relatifs à l'utilisation de l'ISO 27001 et à la sécurité du cloud dans les appels d'offres et le marketing, notamment les recommandations de grands fournisseurs comme IBM sur le positionnement des certifications dans les cycles d'achat des entreprises, partent souvent de ce constat de « gage de qualité pour les appels d'offres » et montrent ensuite comment aller plus loin, comme en témoignent les ressources d'IBM sur les attestations de sécurité dans les appels d'offres. Lorsque votre système de gestion de la sécurité de l'information (SGSI) décrit clairement la réalité du multitenant, vous pouvez réutiliser ces éléments pour répondre plus rapidement et avec plus de crédibilité aux questions des prospects.
Les clients, notamment dans les secteurs réglementés, souhaitent de plus en plus savoir comment vous sécurisez leurs charges de travail dans le cloud, et pas seulement si vous possédez une certification. Ce constat rejoint les conclusions de nombreux guides sur la sécurité et le marketing du cloud : les acheteurs, en particulier dans les secteurs réglementés, attendent des explications détaillées sur la sécurité des charges de travail, et non une simple liste de certifications, comme le soulignent les recommandations des fournisseurs en matière de bonnes pratiques marketing pour la sécurité du cloud, telles que celles d’Oracle. Si vous parvenez à transformer vos pratiques cloud conformes aux normes ISO en options de service claires et en preuves tangibles, vous leur faciliterez la tâche pour vous choisir et justifier ce choix en interne.
L'assurance de l'emballage comme caractéristiques, et non comme simples certificats
L'assurance de l'emballage en tant que caractéristique implique d'expliquer how Vous sécurisez vos charges de travail dans le cloud, et ce n'est pas tout : vous êtes certifié ISO 27001. En présentant des niveaux d'isolation, des dossiers de preuves et une répartition claire des responsabilités dans le cadre de vos services, vous facilitez le travail de vos équipes commerciales et de réussite client.
L'enquête 2025 d'ISMS.online indique que les clients attendent de plus en plus des fournisseurs qu'ils s'alignent sur des cadres formels tels que l'ISO 27001, l'ISO 27701, le RGPD, Cyber Essentials, SOC 2 et les normes émergentes en matière d'IA.
Vous pouvez utiliser vos pratiques cloud conformes aux normes ISO pour :
- Proposer des niveaux de service clairs qui lient l'isolation des locataires et les niveaux d'assurance à des contrôles documentés conformes aux normes ISO.
- Fournir des ensembles de preuves standard que les clients peuvent réutiliser dans leurs propres audits, notamment des matrices, des mappages, des journaux et des vues synthétiques des risques.
- Raccourcissez les cycles d'approvisionnement en présentant un récit cohérent et pré-emballé sur la façon dont votre SMSI couvre le cloud public, dans un langage que les équipes de sécurité comprennent.
Pour les fondateurs et les dirigeants commerciaux, ces éléments transforment la sécurité, d'un obstacle, en un argument de vente. Pour les RSSI et les responsables de la protection des données côté client, ils offrent une analyse approfondie permettant de faire confiance à vos approches sans avoir à les décrypter. Pour vos équipes techniques, ils valident le travail d'ingénierie réalisé sur vos architectures et vos contrôles.
Le travail que vous avez effectué pour documenter la portée, les modèles, les cartographies de contrôle et la surveillance peut être réutilisé de manière sélective dans les supports de vente et les communications avec les clients, à condition de le maintenir précis et axé sur l'aide aux clients pour respecter leurs propres obligations d'assurance.
Mesurer et communiquer l'impact commercial
Mesurer et communiquer l'impact commercial de votre stratégie cloud conforme aux normes ISO permet de repositionner la conformité comme un levier de croissance. En mettant en avant des questionnaires plus rapides, des taux de réussite plus élevés et des renouvellements justifiés par la sécurité, vous facilitez grandement la justification de votre investissement dans le SMSI.
Si vous souhaitez que la norme ISO 27001 soit perçue comme un levier de croissance plutôt que comme un coût, il est utile de suivre quelques indicateurs simples :
- Taux de réussite dans les secteurs réglementés ou sensibles en matière de sécurité.
- Délai entre le questionnaire de sécurité et la signature du contrat.
- Des transactions perdues pour des raisons de sécurité ou de conformité.
- La fidélisation lorsque la sécurité et la conformité sont des raisons clés de renouvellement.
Étape 1 – Choisir un petit ensemble d'indicateurs clés de performance (KPI) en matière de sécurité commerciale
Sélectionnez deux ou trois indicateurs, tels que le délai de réponse aux questionnaires ou le taux de réussite dans les secteurs réglementés, qui sont clairement influencés par votre stratégie d'assurance.
Étape 2 – Collectez et analysez régulièrement ces indicateurs
Élaborez des rapports simples qui mettent en évidence les tendances au fil du temps et discutez-en lors des réunions commerciales et de direction, en parallèle des indicateurs de vente traditionnels.
Étape 3 – Intégrez les enseignements tirés dans votre système de gestion de la sécurité de l'information (SGSI) et vos offres.
Si vous constatez de meilleurs résultats en proposant des packs d'assurance qualité plus complets ou des options d'isolation plus robustes, tenez-en compte dans vos services et dans votre documentation SMSI.
Vous pouvez également inciter vos équipes de gestion de compte et de réussite client à aborder la valeur ajoutée continue en matière de sécurité : revues de contrôle régulières, dossiers de preuves, présentations de la feuille de route et réponses aux nouvelles menaces ou aux évolutions réglementaires. Ainsi, la norme ISO 27001 reste au cœur des discussions sur le renouvellement sans pour autant se transformer en réunions d’audit.
Réservez une démo avec ISMS.online dès aujourd'hui
ISMS.online vous aide à gérer un système de management ISO 27001 unique et adapté au cloud, qui évolue au rythme de l'utilisation d'AWS, d'Azure et de Google Cloud par votre MSP. Fini les jonglages entre feuilles de calcul, diagrammes et dossiers de preuves disparates : centralisez les risques, les contrôles, les matrices de responsabilités partagées et la documentation spécifique au cloud et intégrez-les aux activités quotidiennes de vos équipes.
Pour les fondateurs et dirigeants de fournisseurs de services gérés (MSP), cela se traduit par une vision plus claire de la façon dont leurs pratiques AWS, Azure et Google Cloud se rapportent à la norme ISO 27001:2022, et une plus grande assurance que leur certification reflète la réalité de leurs environnements. Pour les responsables de la conformité, cela offre un soutien structuré pour la mise à jour du périmètre, des évaluations des risques, des correspondances de l'annexe A et des preuves à mesure que leur infrastructure cloud s'étend, y compris les contrôles spécifiques au cloud, tels que ceux qui couvrent l'utilisation des services cloud. Pour les responsables de services, les architectes et les experts en sécurité, cela propose des moyens pratiques de relier les architectures de référence, les flux de travail de gestion des changements et les résultats de la surveillance au système de management de la sécurité de l'information (SMSI) sans créer de documentation supplémentaire.
Si vous souhaitez sérieusement utiliser des plateformes de cloud public tout en restant conforme à la norme ISO 27001 – et transformer cette capacité en un avantage concret pour vos clients – réserver une courte démonstration d'ISMS.online est une solution simple et rapide. Vous découvrirez comment vos architectures et processus cloud existants peuvent être convertis en un système de gestion de la sécurité de l'information (SGSI) dynamique et prêt pour l'audit, qui évolue avec votre activité de services gérés et allège la charge de travail de votre équipe.
Ces informations sont de nature générale et ne constituent pas un avis juridique, de certification ou d'audit ; vous devriez toujours consulter un professionnel qualifié ou un organisme de certification pour les décisions qui affectent vos obligations.
Foire aux questions
En quoi le passage des clients MSP au cloud public modifie-t-il réellement votre conformité à la norme ISO 27001 ?
Le passage des clients vers AWS, Azure ou Google Cloud modifie votre conformité à la norme ISO 27001 car votre périmètre, vos risques et vos contrôles passent des équipements physiques aux plateformes cloud, aux comptes et à l'automatisation, et votre SMSI doit prendre en compte ce changement, sinon il ne reflète plus la manière dont vous gérez réellement vos services.
Quels éléments du SMSI devez-vous mettre à jour en premier pour le cloud public ?
Il y a trois points que la plupart des fournisseurs de services gérés certifiés ISO 27001 devraient réexaminer avant toute autre chose :
- Portée et contexte :
Votre déclaration de périmètre doit clairement identifier les fournisseurs de cloud, les comptes/abonnements principaux, les régions et les plans de gestion partagés (par exemple, la journalisation centralisée, les outils de sécurité, l'intégration continue/déploiement continu, la gestion des identités). Cela permet à l'auditeur de déterminer précisément le périmètre de votre conformité à la norme ISO 27001 et les plateformes qui sous-tendent vos services gérés.
- Inventaire et classification des actifs :
Les serveurs physiques se transforment en comptes cloud, projets, services, pipelines et configurationsLes zones d'atterrissage, les configurations de référence des locataires, les abonnements de gestion, les piles de surveillance partagées et l'automatisation doivent être considérés comme des actifs informationnels, les données qu'ils traitent étant clairement classifiées. Cela permet de visualiser précisément l'emplacement des informations client dans AWS, Azure ou Google Cloud.
- Évaluation des risques et traitement :
Les menaces physiques perdent de leur importance ; les risques liés au cloud augmentent. Les erreurs de configuration, les rôles trop étendus, les interfaces de gestion exposées, les contrôles API insuffisants, l’automatisation non sécurisée et les pannes régionales des fournisseurs doivent figurer dans votre registre des risques, avec des mesures correctives associées aux contrôles de l’annexe A, tels que : A.5.23 (utilisation des services cloud) et les commandes du réseau dans A.8.20–A.8.22.
Si votre système de gestion de la sécurité de l'information (SGSI) ressemble encore à une opération sur site alors que vos clients évoluent dans le cloud public, un auditeur se demandera si votre analyse des risques et votre ensemble de contrôles sont toujours valides.
Comment le cloud public change-t-il la notion de « contrôle » en pratique ?
Dans le cloud public, de nombreux contrôles s'exercent par le biais de modèles et automatisation, et pas seulement des documents :
- Le contrôle d'accès apparaît dans les fournisseurs d'identité, les rôles, les politiques, l'accès conditionnel et les flux de travail d'accès privilégié.
- La segmentation du réseau se manifeste dans les VPC/VNets, les groupes de sécurité, les NSG, les pare-feu, les points de terminaison privés et les règles de peering.
- La sauvegarde, la surveillance et la gestion des incidents reposent sur des services natifs interconnectés via une infrastructure en tant que code, des fonctions sans serveur et des manuels d'exploitation.
Pour un prestataire de services de gestion certifié ISO 27001, le test consiste à vérifier si ces leviers sont :
- Standardisé : en modèles et en lignes de base, plutôt qu'uniques pour chaque projet.
- Possédé : grâce à des responsabilités clairement définies entre le fournisseur, vous et le client.
- Gouverné : par votre système de gestion de la sécurité de l'information (modification, tests, revue), et non pas laissé à la discrétion de l'équipe cloud.
Lorsque ces réalités du cloud sont reflétées dans une plateforme ISMS structurée telle que ISMS.online — avec une portée, des risques, des contrôles et des preuves mis à jour —, vous pouvez rassurer les auditeurs sur le fait que votre certification correspond toujours à votre mode de fonctionnement réel.
Comment un fournisseur de services gérés (MSP) doit-il concevoir des architectures cloud multi-locataires qui restent conformes à la norme ISO 27001 ?
Vous préservez vos droits à la norme ISO 27001 en vous limitant à un petit nombre de modèles multi-locataires, en reliant chacun aux risques et aux contrôles de l'annexe A, et en les appliquant de manière cohérente au lieu d'inventer une conception sur mesure pour chaque nouveau client ou charge de travail.
Quels modèles multilocataires ont tendance à bien fonctionner pour la norme ISO 27001 sur AWS, Azure et Google Cloud ?
La plupart des fournisseurs de services gérés (MSP) convergent vers deux ou trois modèles standard et considèrent tout autre modèle comme une exception nécessitant une justification plus solide :
- Location groupée pour les services à faible risque :
Plusieurs clients partagent une infrastructure sous-jacente (par exemple, des clusters Kubernetes partagés ou des solutions SaaS mutualisées), l'isolation étant assurée par des identifiants, des schémas, des espaces de noms et une autorisation. Pour garantir la conformité à une norme ISO, il convient de préciser :
- Comment les données des locataires sont séparées (segmentation du réseau, contrôles de base de données, clés par locataire).
- Comment l'isolation est testée et surveillée (contrôles automatisés, attaques simulées, journalisation).
- Comment contenir un locataire bruyant ou compromis (limites de débit, limitation de bande passante, suspension sécurisée).
- Compte/abonnement/projet dédié par locataire pour des services à assurance renforcée :
Chaque client dispose de son propre compte, abonnement ou projet, connecté à des zones d'atterrissage et des outils de gestion partagés. Ceci est conforme aux exigences de l'annexe A en matière de séparation, mais augmente le nombre d'environnements à maintenir alignés sur vos configurations de référence.
- Plan de contrôle partagé avec plans de données séparés :
Un plan de contrôle central (CI/CD, journalisation, outils de sécurité) sert plans de données séparés là où résident les charges de travail et les données des clients. Cela permet d'optimiser l'efficacité opérationnelle tout en préservant des limites d'isolation des données clairement définies.
Ce qui compte le plus, c'est que vous puissiez démontrer :
- A architecture de référence documentée pour chaque modèle, avec des diagrammes et des exemples d'infrastructure en tant que code.
- Une trace de chaque motif dans votre registre des risques et Contrôles de l'Annexe A (par exemple, A.8.20–A.8.22 pour la sécurité et la ségrégation du réseau).
- Modifier et tester les processus afin de garantir que chaque nouveau locataire suive un modèle connu plutôt que « ce qu'un ingénieur a fait sous pression ».
Lorsque ces architectures et contrôles sont intégrés à votre SMSI et que vos équipes travaillent à partir des mêmes conceptions, vous pouvez expliquer le multi-tenant aux auditeurs et aux acheteurs sans avoir à partager d'écran des consoles cloud brutes.
Comment expliquez-vous votre modèle mutualisé pour que les auditeurs et les clients lui fassent confiance ?
Les deux publics souhaitent voir un itinéraire dégagé depuis risque → conception → configuration → preuveUn récit simple fonctionne bien :
- Risque: « Accès aux données inter-locataires sur une plateforme partagée. »
- Conception: « Modèle de cluster mutualisé avec espaces de noms par locataire, politiques réseau et clés de chiffrement à portée locataire. »
- Configuration: « Des modèles de base et des garde-fous que nous appliquons via Terraform ou des pipelines de déploiement. »
- Preuve: « Les résultats des tests, les contrôles d'isolement, les journaux et les incidents qui démontrent l'efficacité des contrôles au fil du temps. »
L'intégration de cette chaîne à votre SMSI, avec des schémas et des référentiels à l'appui, vous permet de guider un auditeur ou un prospect à travers votre modèle de manière sereine et reproductible. ISMS.online vous aide à centraliser ces risques, architectures et contrôles afin que chaque nouvel environnement renforce votre argumentaire au lieu de le complexifier.
Comment un fournisseur de services gérés (MSP) peut-il faire correspondre les contrôles de l'annexe A de la norme ISO 27001:2022 aux services AWS, Azure et Google Cloud ?
Vous rendez l'annexe A utilisable sur AWS, Azure et Google Cloud en traduisant chaque thème de contrôle en services spécifiques, configurations de base et processus de supportet en consignant cela dans une cartographie contrôle-service que vos ingénieurs et vos auditeurs pourront suivre.
À quoi ressemble concrètement une cartographie commande-service ?
Une matrice simple et extensible pourrait ressembler à ceci :
| Annexe A, domaine d'intervention | Services cloud dans le périmètre | Configuration et processus de base |
|---|---|---|
| Contrôle d'accès (famille A.5, A.8.x) | IAM, Azure AD, IAM Cloud, PIM/PAM | Rôles standard, MFA, promotion à la demande |
| Journalisation et surveillance (A.8.15–A.8.16) | CloudTrail, Defender, Journalisation dans le cloud, SIEM | Centralisation, acheminement des alertes, astreintes |
| Sauvegarde et restauration (A.8.13–A.8.14) | Instantanés, coffres-forts de sauvegarde, copies interrégionales | Calendriers, rétention, tests de restauration |
| Utilisation des services cloud (A.5.23) | Catalogues des fournisseurs, processus d'intégration des services | Évaluation des fournisseurs, validation des risques, planification de la sortie |
Pour chaque ligne que vous définissez :
- Quels services : vous utilisez ce thème sur chaque plateforme.
- paramètres de base vous attendez à (chiffrement, conservation des données, accès privé, journalisation, MFA).
- preuve vous pouvez produire (IaC, rapports, tickets, journaux, captures d'écran si nécessaire).
Vous associez ensuite chaque ligne aux contrôles spécifiques de l'annexe A et indiquez si un contrôle est :
- Géré par le fournisseur : (sécurité physique du centre de données, infrastructure de base).
- Mise en œuvre et contrôlée par vos soins : (configuration, surveillance, réponse).
- Cela dépend du client : (sécurité de la couche application, certaines décisions relatives au traitement des données).
Cette cartographie devient une référence partagée entre les équipes de sécurité, d'ingénierie et d'audit, et une base sur laquelle vous pouvez vous appuyer à mesure que votre infrastructure cloud s'étend.
En quoi cette cartographie est-elle utile au-delà de la certification ISO 27001 ?
Une fois que vous avez une bonne correspondance entre les commandes et les services, vous pouvez la réutiliser de plusieurs manières :
- Étendez-le pour couvrir SOC 2, NIS 2, DORA ou ISO 27701, plutôt que de concevoir de nouvelles matrices à partir de zéro.
- Accélérez vos réponses aux questionnaires de sécurité et aux appels d'offres, car vous savez déjà quels modèles et services répondent aux exigences courantes.
- Donnez à vos équipes une source unique de vérité pour savoir comment configurer et exploiter AWS, Azure et Google Cloud afin de les intégrer à votre système de gestion de la sécurité de l'information (SMSI).
Le fait de conserver cette cartographie dans une plateforme ISMS intégrée telle que ISMS.online, aux côtés des risques, des politiques, des normes d'assurance et des audits internes, signifie que chaque modification apportée aux services cloud ou aux modèles alimente automatiquement votre référentiel d'assurance au lieu de disparaître dans une feuille de calcul oubliée.
Que signifie réellement la responsabilité partagée pour un fournisseur de services gérés (MSP) certifié ISO 27001 dans le cloud public ?
Pour un fournisseur de services gérés (MSP) certifié ISO 27001, la responsabilité partagée dans le cloud public signifie que vous avez Il a été explicitement décidé, documenté et convenu qui fait quoi. pour chaque domaine de contrôle majeur, et ce tableau est cohérent dans votre système de gestion de la sécurité de l'information (SGSI), vos contrats, vos descriptions de service et vos manuels d'exploitation.
Comment transformer une responsabilité partagée, actuellement une simple formalité, en un élément vérifiable ?
Une méthode simple consiste à maintenir un matrice de responsabilité par service, généralement en utilisant la matrice RACI :
- Responsable: qui effectue le travail (par exemple, configurer les locataires, exécuter les sauvegardes, paramétrer les alertes).
- Redevable: qui supporte le risque et le résultat (vous, le client ou parfois les deux) ?
- Consulté : qui fournit des informations (sécurité client, service juridique, propriétaires des données).
- Informé: qui a besoin de mises à jour (gestionnaires de comptes, parties prenantes clients).
Appliquez cette matrice aux thèmes de contrôle tels que :
- Sécurité des locataires, des plateformes et du réseau.
- Gestion des identités et des accès.
- Tests de sauvegarde, de restauration et de résilience.
- Journalisation, surveillance et gestion des alertes.
- Rapports de conformité et assurance auprès des clients.
Chaque matrice doit être alignée avec :
- Contrats et cahiers des charges : , donc la portée et les hypothèses sont explicites.
- Interne manuels d'exploitation et schémasLes ingénieurs suivent donc la même répartition du travail.
- Risques et contrôles : dans votre système de gestion de la sécurité de l'information (SGSI), y compris lorsque vous comptez sur vos clients pour agir.
Lorsque vous modifiez un service (par exemple, en renforçant la sécurité de la couche applicative ou en accordant au client un contrôle opérationnel accru), mettez à jour la matrice, révisez votre documentation et soumettez ce changement à des audits internes. Cet historique vous permettra de vous défendre efficacement en cas d'incident ou de litige.
Comment la norme ISO 27017 peut-elle renforcer votre modèle de responsabilité partagée ?
La norme ISO 27017 propose des recommandations de sécurité spécifiques au cloud, complémentaires aux normes ISO 27001 et ISO 27002. En l'utilisant pour définir votre modèle de responsabilité partagée, vous pouvez :
- Démontrez aux auditeurs et aux clients que votre répartition des tâches est conforme aux règles suivantes : bonnes pratiques publiées, pas seulement une vue sur une maison.
- Clarifier les zones d'ombre, notamment qui configure les pare-feu virtuels, qui gère les clés de chiffrement et qui renforce la sécurité des machines virtuelles, des conteneurs ou des fonctions sans serveur.
- Réduisez les frictions lors de l'intégration en présentant un modèle de responsabilité standardisé qui est conforme aux recommandations de l'ISO.
L'intégration de la norme ISO 27017 dans votre système de gestion de la sécurité de l'information (SGSI) et vos supports destinés aux clients transforme la responsabilité partagée, d'un simple argument marketing, en un élément essentiel lors des audits ISO 27001 et des échanges avec les autorités réglementaires. ISMS.online vous aide à maintenir la cohérence de vos modèles de responsabilité, registres des risques et cartographies des contrôles à mesure que vos services cloud évoluent.
Comment les fournisseurs de services gérés peuvent-ils générer des preuves d'audit ISO 27001 convaincantes lorsque les charges de travail s'exécutent dans le cloud public ?
Vous générez des preuves convaincantes de conformité à la norme ISO 27001 dans le cloud public en démontrant que votre Le système de gestion intègre pleinement le cloud et que votre Les plateformes cloud sont exploitées de manière cohérente avec ce système pour l'ensemble des locataires, des régions et des services.
Quels éléments de votre système de gestion de la sécurité de l'information (SMSI) doivent clairement indiquer votre utilisation d'AWS, d'Azure et de Google Cloud ?
Du côté du système de gestion, les auditeurs rechercheront la présence explicite du terme « cloud » dans :
- Votre énoncé de portée et le contexte, notamment la dépendance à l'égard de fournisseurs spécifiques et de plateformes de gestion partagées.
- Évaluations des risques: et des plans de traitement qui mettent en évidence les problèmes spécifiques au cloud tels que les erreurs de configuration, la prolifération des identités, les défaillances de régions et les dépendances de la chaîne d'approvisionnement.
- Déclaration d'applicabilité, notamment lorsque les contrôles sont mis en œuvre par les fournisseurs ou partagés avec les clients.
- Calendriers et rapports d'audit interne : qui couvrent les activités de gouvernance du cloud telles que les revues de zones d'atterrissage, les revues d'accès et les contrôles de dérive de configuration.
- Éléments d'entrée et de sortie de la revue de direction : où les incidents liés au cloud, les changements et les indicateurs de performance sont discutés et les décisions consignées.
Ces éléments démontrent que le cloud fait partie intégrante de votre cycle normal Planifier-Déployer-Contrôler-Améliorer, et non pas d'une tâche gérée de manière informelle en dehors du système de gestion de la sécurité de l'information (SGSI).
Quels éléments de preuve au niveau du nuage tendent à rassurer les auditeurs ISO 27001 ?
Sur le plan technique, les auditeurs souhaitent généralement un ensemble de documents de configuration, de surveillance et d'exploitation qui soient liés à vos contrôles, par exemple :
- Accéder aux dossiers d'examen : pour les zones d'atterrissage, les environnements locataires et les outils de gestion, y compris la manière dont l'accès privilégié est approuvé et supprimé.
- Configurations de référence et rapports de dérive : (par exemple, modèles IaC, packages de politiques, tableaux de bord de conformité de configuration) montrant comment détecter et corriger les erreurs de configuration.
- Preuves de sauvegarde et de restauration : comme les calendriers de sauvegarde, les rapports de tâches, les journaux de tests de restauration et la manière dont les tâches ayant échoué ont été gérées.
- Enregistrement et surveillance des résultats : , y compris les tableaux de bord SIEM, des exemples d'alertes, des enregistrements de réglage et des exemples de chronologies d'incidents.
- Billets de modification et d'incident : qui montrent comment des événements réels ont évolué au sein de vos processus de contrôle des changements et de gestion des incidents.
Rassembler ces informations dans un environnement structuré, plutôt que de rechercher des captures d'écran sur différentes consoles, permet de gagner du temps et de rendre votre récit plus cohérent. ISMS.online vous aide à associer chaque élément de preuve au risque, au contrôle et au service concernés, afin de pouvoir les réutiliser pour les audits et les dossiers de garantie client sans avoir à tout recréer.
Comment un fournisseur de services gérés peut-il transformer la conformité à la norme ISO 27001 axée sur le cloud en un avantage commercial ?
Vous transformez la conformité à la norme ISO 27001 adaptée au cloud en un avantage commercial en concevant et en décrivant vos services gérés de manière à ce que les clients sentent que vous réduire leur charge de travail en matière de sécurité et de conformité dans le cloud public, plutôt que de les laisser tout assembler eux-mêmes.
Comment conditionner les services de cloud public de manière à ce que vos atouts liés à la norme ISO 27001 soient évidents ?
Une approche pratique consiste à définir quelques niveaux de service nommés qui lient architecture, assurance et prix :
- Chaque niveau associe un modèle d'isolation des locataires (mis en commun, hybride, dédié) à :
- Niveau de surveillance et de reporting défini.
- Fréquence convenue des examens d'accès et des tests de restauration.
- Des engagements et des schémas de communication clairs en matière de réponse aux incidents.
Vous soutenez ensuite chaque niveau avec :
- Une référence matrice de responsabilité pour ce niveau de service, afin que les clients voient exactement ce que vous couvrez et ce qui reste avec eux.
- Une correspondance pack de contrôle et de preuves, en indiquant les thèmes de l'Annexe A que vous traitez et les éléments que les clients peuvent attendre lors de la vérification préalable.
- Réutilisable Contenu de l'appel d'offres et du questionnaireAinsi, vos équipes n'ont pas à réécrire les réponses en matière de sécurité pour chaque prospect.
À partir de là, vous pouvez suivre :
- Taux de réussite lorsque les acheteurs ont posé des questions explicites sur la norme ISO 27001 ou la sécurité du cloud public.
- Délai entre le premier questionnaire de sécurité et la signature du contrat.
- Raisons de renouvellement et d'expansion mentionnant la sécurité, la conformité ou la tranquillité d'esprit.
Ces données vous aident à prouver en interne qu'un système de gestion de la sécurité de l'information (SGSI) adapté au cloud n'est pas seulement un coût d'exploitation ; il soutient activement la croissance auprès des bons clients.
Comment une plateforme ISMS peut-elle faciliter la narration de cette histoire commerciale ?
Lorsque les risques, les contrôles, les responsabilités et les preuves sont dispersés entre les équipes et les outils, il est difficile de répondre avec assurance à des questions simples des acheteurs comme : « Comment sécurisez-vous mes données sur AWS ou Azure ? ». Une plateforme ISMS dédiée telle que ISMS.online vous aide à :
- Intégrez vos contrôles ISO 27001, vos architectures multicloud et les exigences de l'annexe A 5.23 dans un système structuré qui reflète votre mode de fonctionnement réel.
- Maintenez à jour les matrices de responsabilité partagée, les plans de gestion des risques et les cartographies de contrôle à mesure que vos services, vos régions et vos fonctionnalités cloud évoluent.
- Générez des documents cohérents et faciles à utiliser pour les auditeurs (énoncés de portée, déclarations d'applicabilité, rapports d'audit et dossiers d'assurance client) sans avoir à les reconstruire à chaque nouvelle opportunité.
Si vous souhaitez que vos prospects et vos clients actuels vous perçoivent comme le MSP qui leur retire les responsabilités liées à la conformité au cloud publicIl est donc pertinent d'explorer comment une plateforme ISMS intégrée peut connecter vos conceptions AWS, Azure et Google Cloud à vos engagements ISO 27001 et aux garanties que les acheteurs attendent désormais comme norme.
