Conformité de la sécurité cloud : guide RGPD et NIS2 Le transfert des systèmes, des applications et des données vers le cloud modifie l’environnement technique, mais ne supprime pas les responsabilités juridiques, réglementaires ou de sécurité de l’organisation. Un fournisseur...
Le transfert des systèmes, des applications et des données vers le cloud modifie l’environnement technique, mais ne supprime pas les responsabilités juridiques, réglementaires ou de sécurité de l’organisation. Un fournisseur de services cloud peut exploiter l’infrastructure sous-jacente, tandis que le client doit toujours comprendre quelles données sont traitées, où elles sont stockées, qui peut y accéder, quels contrôles sont activés et comment les incidents seront détectés, analysés et signalés.
Une conformité efficace de la sécurité cloud exige que les organisations articulent les obligations du RGPD en matière de protection des données avec les exigences de cybersécurité prévues par NIS2 et les contrôles techniques proposés par leurs fournisseurs de services cloud.
Pour les organisations exerçant leurs activités en France et dans l’Union européenne, cela implique de gérer des responsabilités qui se recoupent en matière de protection des données, de cybersécurité, de résilience, de risques fournisseurs et de notifications réglementaires.
Ce guide explique comment le RGPD et NIS2 s’appliquent aux environnements cloud, comment fonctionne le modèle de responsabilité partagée, quels contrôles des fournisseurs de services cloud doivent faire l’objet d’une attention particulière, comment gérer les transferts internationaux de données et les contrats fournisseurs, et comment se préparer aux incidents liés au cloud. Il examine également l’alignement avec ISO/IEC 27001 et propose une feuille de route pratique pour renforcer un programme de conformité cloud.
La conformité de la sécurité cloud consiste à s’assurer que les systèmes, les données, les fournisseurs de services cloud et les pratiques opérationnelles respectent les exigences juridiques, réglementaires, contractuelles et de sécurité applicables.
Elle ne se limite pas au choix d’un fournisseur cloud disposant de certifications reconnues. L’organisation doit également savoir quels systèmes sont exploités dans le cloud, quelles informations y sont traitées, quelles obligations réglementaires s’appliquent, quelles responsabilités incombent au fournisseur, quels contrôles doivent être configurés par le client et quels éléments probants permettent de démontrer que les risques sont effectivement maîtrisés.
Cela couvre notamment le contrôle des accès, le chiffrement, la journalisation, la résilience, la réponse aux incidents, la localisation des données, la supervision des fournisseurs et les responsabilités contractuelles.
La sécurité cloud vise principalement à protéger la confidentialité, l’intégrité et la disponibilité des systèmes et des données, à maintenir la résilience et à réduire l’exposition aux cybermenaces.
La protection des données dans le cloud concerne la licéité du traitement des données personnelles, la transparence, les droits des personnes concernées, la conservation des données, les transferts internationaux et les responsabilités entre responsables du traitement et sous-traitants.
Ces deux domaines se recoupent souvent. Le chiffrement, par exemple, peut réduire la probabilité ou l’impact d’un accès non autorisé tout en contribuant au respect des obligations de sécurité prévues par le RGPD.
Une conformité efficace de la sécurité cloud suppose donc de gérer conjointement la sécurité et la protection des données, plutôt que de les traiter comme deux programmes distincts.
Le Règlement général sur la protection des données, règlement (UE) 2016/679 s’applique lorsque des services cloud traitent des données à caractère personnel dans son champ d’application matériel et territorial. Le transfert de données vers un environnement cloud ne supprime pas la responsabilité de l’organisation qui détermine les finalités et les moyens du traitement des données personnelles.
Dans de nombreuses configurations cloud, l’organisation qui utilise la plateforme agit en tant que responsable du traitement, tandis que le fournisseur de services cloud intervient comme sous-traitant pour certaines opérations de traitement définies.
Ces rôles doivent toutefois être déterminés en fonction des traitements réellement effectués, et non simplement déduits des intitulés contractuels. Un fournisseur peut exercer des rôles différents selon les services fournis ou les finalités poursuivies.
En vertu de l’article 28, les responsables du traitement doivent faire appel à des sous-traitants présentant des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées. La relation entre le responsable du traitement et le sous-traitant doit également être encadrée par des dispositions contractuelles couvrant les éléments requis du traitement.
L’article 32 impose aux responsables du traitement et aux sous-traitants de mettre en œuvre des mesures de sécurité adaptées au niveau de risque, en tenant compte notamment de l’état des connaissances, des coûts de mise en œuvre, du contexte du traitement et de l’impact potentiel sur les personnes.
Les mesures pertinentes peuvent inclure le chiffrement, la pseudonymisation, la résilience, la disponibilité, les capacités de restauration, des tests de sécurité réguliers et une évaluation continue des risques.
Une déclaration de conformité au RGPD ou une certification du fournisseur cloud ne suffit donc pas, à elle seule. Le client doit toujours évaluer ses propres traitements, ses choix de configuration, ses contrôles d’accès, ses flux de données et ses dispositions contractuelles afin de déterminer si son utilisation du cloud respecte effectivement les exigences du RGPD.
Le Règlement général sur la protection des données, règlement (UE) 2016/679 s’applique lorsque des services cloud traitent des données à caractère personnel dans son champ d’application matériel et territorial. Le transfert de données vers un environnement cloud ne supprime pas la responsabilité de l’organisation qui détermine les finalités et les moyens du traitement des données personnelles.
Dans de nombreuses configurations cloud, l’organisation qui utilise la plateforme agit en tant que responsable du traitement, tandis que le fournisseur de services cloud intervient comme sous-traitant pour certaines opérations de traitement définies.
Ces rôles doivent toutefois être déterminés en fonction des traitements réellement effectués, et non simplement déduits des intitulés contractuels. Un fournisseur peut exercer des rôles différents selon les services fournis ou les finalités poursuivies.
En vertu de l’article 28, les responsables du traitement doivent faire appel à des sous-traitants présentant des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées. La relation entre le responsable du traitement et le sous-traitant doit également être encadrée par des dispositions contractuelles couvrant les éléments requis du traitement.
L’article 32 impose aux responsables du traitement et aux sous-traitants de mettre en œuvre des mesures de sécurité adaptées au niveau de risque, en tenant compte notamment de l’état des connaissances, des coûts de mise en œuvre, du contexte du traitement et de l’impact potentiel sur les personnes.
Les mesures pertinentes peuvent inclure le chiffrement, la pseudonymisation, la résilience, la disponibilité, les capacités de restauration, des tests de sécurité réguliers et une évaluation continue des risques.
Une déclaration de conformité au RGPD ou une certification du fournisseur cloud ne suffit donc pas, à elle seule. Le client doit toujours évaluer ses propres traitements, ses choix de configuration, ses contrôles d’accès, ses flux de données et ses dispositions contractuelles afin de déterminer si son utilisation du cloud respecte effectivement les exigences du RGPD.
Devenez Lead Implementer ISO/IEC 27001.
Développez les compétences pratiques nécessaires pour concevoir, mettre en œuvre et piloter un système de management de la sécurité de l’information (SMSI) conforme à la norme ISO/IEC 27001. Apprenez à évaluer les risques liés à la sécurité de l’information, à mettre en place les mesures de l’Annexe A, à préparer les audits de certification et à inscrire votre organisation dans une démarche d’amélioration continue. Suivez la formation à votre rythme et recevez un certificat PDF reconnu, inclus gratuitement avec la formation. À votre rythme, axée sur les compétences professionnelles et conçue pour renforcer votre employabilité.
Commencer la formation →La directive NIS2, directive (UE) 2022/2555, impose aux entités entrant dans son champ d’application des obligations en matière de gestion des risques de cybersécurité et de notification des incidents. Ses exigences couvrent notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la gestion des vulnérabilités, le chiffrement, le contrôle des accès, la gestion des actifs, l’hygiène cyber, la formation et l’authentification multifacteur.
Les services cloud peuvent affecter presque tous ces domaines. Une organisation qui dépend d’une infrastructure cloud, de plateformes SaaS ou de services managés doit donc intégrer les risques liés au cloud dans son programme global de cybersécurité au titre de NIS2.
Les fournisseurs de services d’informatique en nuage sont expressément inclus dans le cadre NIS2. Parallèlement, une organisation qui utilise un fournisseur cloud peut elle-même entrer dans le champ d’application de NIS2 en raison de son secteur, de sa taille, de son niveau de criticité ou des services qu’elle fournit.
Cela peut créer deux niveaux de responsabilité qui se recoupent : le fournisseur doit respecter ses propres obligations NIS2 applicables, tandis que le client reste responsable de la gestion des risques de cybersécurité liés à son utilisation du cloud.
Le règlement d’exécution (UE) 2024/2690 de la Commission définit des exigences techniques et méthodologiques plus détaillées pour certaines entités numériques, notamment les fournisseurs de services d’informatique en nuage.
Ces exigences couvrent notamment la gestion des risques de cybersécurité, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le contrôle des accès, la cryptographie, la gestion des actifs et les tests de sécurité.
Les organisations ne doivent toutefois pas supposer que toutes les exigences du règlement d’exécution s’appliquent directement à chaque client cloud. Leur applicabilité dépend de l’entité concernée, du service utilisé et du champ juridique applicable.
Le RGPD et NIS2 influencent tous deux la conformité de la sécurité cloud, mais ils couvrent des risques différents. Le RGPD se concentre sur la protection et le traitement licite des données à caractère personnel, tandis que NIS2 porte plus largement sur la cybersécurité, la résilience et la continuité des services essentiels ou importants.
|
Domaine |
RGPD |
NIS2 |
|
Objectif principal |
Protection des données à caractère personnel |
Cybersécurité et résilience |
|
Entités concernées |
Responsables du traitement et sous-traitants relevant du RGPD |
Entités essentielles et importantes ainsi que certains fournisseurs numériques |
|
Enjeux liés au cloud |
Traitement, sécurité, contrats, transferts, violations de données |
Gestion des risques, résilience, sécurité des fournisseurs, réponse aux incidents |
|
Relation avec le fournisseur |
Exigences de l’article 28 applicables aux sous-traitants |
Risques liés à la chaîne d’approvisionnement et aux fournisseurs |
|
Mesures de sécurité |
Mesures techniques et organisationnelles appropriées |
Mesures techniques, opérationnelles et organisationnelles proportionnées |
|
Transferts internationaux de données |
Exigences du chapitre V |
Ne constitue pas principalement un régime de transfert de données |
|
Notification des incidents |
Notification des violations de données personnelles lorsque cela est requis |
Notification des incidents significatifs |
|
Responsabilité de la direction |
Principe de responsabilité au titre du RGPD |
Supervision explicite par les organes de direction |
|
Principale autorité en France |
CNIL pour la protection des données |
Autorités compétentes en cybersécurité dans le cadre français de NIS2. |
Pour les organisations qui utilisent des services cloud, ces deux cadres doivent être évalués conjointement plutôt que gérés séparément. Un même fournisseur, système ou incident peut déclencher des obligations au titre des deux régimes.
Une attaque par rançongiciel affectant une base de données clients hébergée dans le cloud constitue un exemple pertinent. La perte de disponibilité du système peut devoir être évaluée comme un incident de cybersécurité significatif au titre de NIS2, tandis qu’un accès non autorisé, une perte, une altération ou une indisponibilité de données personnelles peut également constituer une violation de données au sens du RGPD.
Les organisations doivent donc disposer d’un processus coordonné de gestion des incidents capable d’évaluer plusieurs déclencheurs juridiques simultanément. Le confinement technique, la conservation des éléments probants, l’analyse de la violation au titre du RGPD, l’évaluation du caractère significatif de l’incident au titre de NIS2 et l’escalade réglementaire doivent être reliés afin d’identifier sans délai inutile les obligations parallèles.
Les responsabilités en matière de sécurité cloud sont réparties entre le fournisseur de services cloud et le client, mais cette répartition dépend du modèle de service, de l’architecture du fournisseur, du contrat et des contrôles choisis par le client. Les organisations doivent donc documenter les responsabilités au niveau de chaque contrôle, plutôt que de s’appuyer sur une vision simplifiée du modèle de responsabilité partagée.
Dans un modèle Infrastructure as a Service, le fournisseur gère généralement le centre de données physique, le matériel, l’infrastructure réseau et les principaux composants de la plateforme. Le client conserve habituellement une responsabilité plus importante concernant les systèmes d’exploitation, les applications, les identités, les configurations de sécurité et les données.
Dans un modèle Platform as a Service, le fournisseur prend en charge une plus grande partie de la couche technologique sous-jacente. Le client reste toutefois responsable de domaines tels que la logique applicative, les accès utilisateurs, les données, les intégrations et de nombreux choix de configuration pouvant avoir un impact direct sur la sécurité et la conformité.
Dans un modèle Software as a Service, le fournisseur exploite la majeure partie de l’infrastructure applicative. Le client reste néanmoins généralement responsable des comptes utilisateurs, des autorisations, des données saisies dans le service, des paramètres de conservation, des intégrations et de l’utilisation licite de la plateforme.
Un contrat conclu avec un fournisseur de services cloud ne supprime pas la responsabilité du client de comprendre les risques liés au cloud, de configurer les contrôles disponibles, de surveiller les accès, d’examiner les garanties fournies par le prestataire et de maintenir une gouvernance interne.
La question pratique n’est donc pas simplement de savoir qui « sécurise le cloud ». Les organisations doivent déterminer qui est responsable de chaque contrôle important, quels éléments probants permettent de démontrer sa mise en œuvre et comment les écarts ou défaillances seront gérés.
Les diligences à l’égard d’un fournisseur cloud doivent porter sur les contrôles réellement pertinents au regard du profil de risque de l’organisation, et non se limiter à collecter des certificats ou à accepter des déclarations générales de sécurité.
Les contrôles des CSP pertinents peuvent notamment inclure la gestion des identités et des accès, les accès privilégiés, le chiffrement, la gestion des clés, la journalisation, la surveillance de la sécurité, la gestion des vulnérabilités, la sécurité réseau, la sécurité physique, les sauvegardes, la résilience, la réponse aux incidents et la gestion des sous-traitants.
L’objectif est de comprendre comment chaque contrôle fonctionne, s’il s’applique au service cloud utilisé et quelles responsabilités restent à la charge du client.
Les éléments probants utiles peuvent inclure une certification ISO/IEC 27001, des rapports d’audit de sécurité indépendants, des informations sur les tests d’intrusion, des attestations de contrôle et une documentation détaillée sur la sécurité du fournisseur.
Ces éléments peuvent renforcer le niveau d’assurance, mais ils doivent être interprétés avec précaution. La certification d’un fournisseur ne prouve pas que chaque service cloud, chaque configuration ou chaque environnement client est sécurisé. L’organisation doit toujours vérifier si le périmètre certifié couvre le service concerné et si les paramètres relevant du client ont été configurés de manière appropriée.
Pour chaque exigence importante de sécurité cloud, déterminez :
Qui est responsable du contrôle
Comment le contrôle fonctionne
Quels éléments probants démontrent son efficacité
Ce que le client doit configurer ou surveiller
Ce qui se passe en cas de défaillance du contrôle
Cette cartographie au niveau des contrôles réduit le risque de zones de responsabilité mal définies dans lesquelles chaque partie suppose que l’autre prend en charge le même sujet.
Le résultat doit alimenter les évaluations des risques cloud, les décisions d’achat, les revues contractuelles, les audits internes et la surveillance continue du fournisseur, afin que l’assurance reste directement liée au risque opérationnel plutôt que de devenir un simple exercice ponctuel de diligence.
Les contrats cloud constituent un contrôle central de conformité, car ils définissent la manière dont les responsabilités, les obligations de sécurité et les activités de traitement des données sont réparties entre le client et le fournisseur de services cloud.
Lorsque le CSP agit en tant que sous-traitant au titre du RGPD, l’accord doit couvrir les exigences de l’article 28. Cela comprend notamment le traitement des données uniquement sur la base d’instructions documentées, les obligations de confidentialité, les mesures de sécurité appropriées, les règles applicables aux sous-traitants ultérieurs, l’assistance pour l’exercice des droits des personnes concernées, le soutien en cas de violation de données personnelles, la suppression ou la restitution des données, les informations nécessaires aux audits et la coopération requise pour démontrer la conformité.
Le contrat doit également refléter le fonctionnement réel du service, plutôt que de reposer sur des clauses génériques relatives au traitement des données.
Les environnements cloud reposent souvent sur plusieurs organisations, notamment des fournisseurs d’hébergement, des équipes de support, des prestataires d’analyse, des partenaires de télécommunications et d’autres fournisseurs d’infrastructure.
Les clients doivent comprendre qui sont les sous-traitants ultérieurs concernés, où ils exercent leurs activités, quels services ils fournissent, comment les changements proposés sont communiqués et quelles garanties contractuelles s’appliquent.
Cela est particulièrement important lorsque des sous-traitants ultérieurs peuvent accéder à des données personnelles depuis l’extérieur de l’EEE ou interviennent dans le fonctionnement de services critiques.
Des formulations générales telles que « sécurité conforme aux standards du secteur » offrent, à elles seules, un niveau d’assurance limité.
Les contrats cloud doivent donc être évalués conjointement avec la documentation technique, les engagements de niveau de service, les politiques de sécurité du fournisseur et les responsabilités de configuration qui restent à la charge du client.
L’objectif est de comprendre précisément les engagements pris par le fournisseur, les contrôles que le client doit activer et les recours, procédures d’escalade ou dispositifs d’assistance disponibles lorsque les obligations de sécurité ne sont pas respectées.
Pour assurer la conformité du cloud au RGPD, les organisations doivent comprendre bien plus que l’emplacement du centre de données principal. Le fait de stocker des données personnelles en France ou dans un autre pays de l’Union européenne ne signifie pas automatiquement qu’aucun transfert international n’a lieu.
Des transferts peuvent notamment intervenir via le support à distance, l’administration globale, les sous-traitants ultérieurs, les dispositifs de reprise après sinistre, la surveillance de la sécurité, les journaux techniques ou l’accès à l’environnement depuis l’extérieur de l’Espace économique européen.
Les organisations doivent documenter l’emplacement des données principales, la localisation des sauvegardes, les personnes pouvant accéder à l’environnement, les pays dans lesquels les équipes de support opèrent ainsi que les sous-traitants ultérieurs qui reçoivent des données personnelles ou peuvent y accéder.
Cette cartographie des flux de données doit refléter l’architecture réelle du service et ne pas reposer uniquement sur une déclaration générale du fournisseur concernant la résidence des données.
Lorsque des données personnelles sont transférées en dehors de l’EEE, les organisations doivent évaluer les exigences du chapitre V du RGPD. Selon les circonstances, les mécanismes applicables peuvent inclure les décisions d’adéquation, les clauses contractuelles types, les règles d’entreprise contraignantes ou certaines dérogations spécifiques.
La CNIL fournit des orientations officielles sur les transferts internationaux au titre du RGPD.
Les clauses contractuelles types de la Commission européenne pour les transferts internationaux de données constituent un mécanisme reconnu pour certains transferts de données en dehors de l’EEE.
La signature de clauses contractuelles types ne permet toutefois pas de résoudre automatiquement tous les risques liés au transfert. Les organisations doivent encore évaluer le pays de destination, les circonstances du transfert, les risques d’accès aux données ainsi que les garanties techniques ou organisationnelles complémentaires éventuellement nécessaires.
Le chiffrement constitue un contrôle essentiel de la sécurité cloud, mais son efficacité dépend de la manière dont il est mis en œuvre et gouverné. Les organisations doivent évaluer le chiffrement des données en transit, le chiffrement des données au repos, la propriété des clés, leur rotation, les accès privilégiés aux clés cryptographiques, le chiffrement des sauvegardes ainsi que les procédures de récupération.
Un chiffrement robuste peut réduire la probabilité et l’impact d’un accès non autorisé, mais une mauvaise gestion des clés peut compromettre la protection recherchée. L’accès aux clés doit donc être restreint, surveillé et aligné sur le profil de risque de l’organisation.
Les clés gérées par le fournisseur peuvent simplifier les opérations, tandis que les clés gérées par le client peuvent offrir un niveau de contrôle supplémentaire dans les environnements à risque plus élevé. Toutefois, la gestion des clés par le client entraîne également davantage de responsabilités opérationnelles, notamment en matière de stockage sécurisé, de rotation, de récupération et de continuité d’activité.
Le modèle approprié doit tenir compte de la sensibilité des données, des exigences réglementaires, du modèle de menace de l’organisation, des besoins de continuité d’activité et des capacités techniques internes.
Les données chiffrées peuvent toujours être considérées comme des données à caractère personnel au sens du RGPD. Le chiffrement peut réduire le niveau de risque, mais il ne supprime pas automatiquement les obligations du responsable du traitement, celles du sous-traitant, les exigences relatives aux transferts internationaux ou les obligations d’évaluation en cas de violation de données personnelles.
Les organisations doivent donc considérer le chiffrement comme une couche de protection au sein d’un cadre plus large de conformité de la sécurité cloud, comprenant également la gestion des identités, les contrôles d’accès, la journalisation, la surveillance et la réponse aux incidents.
De nombreux incidents de sécurité dans le cloud sont liés à des identités compromises, à des droits d’accès excessifs ou à une authentification insuffisante plutôt qu’à des attaques directes contre l’infrastructure physique. Une gestion rigoureuse des identités et des accès constitue donc un élément essentiel d’une conformité efficace de la sécurité cloud.
Les contrôles doivent notamment porter sur le principe du moindre privilège, l’authentification multifacteur, les accès fondés sur les rôles, la gestion des accès privilégiés, le cycle de vie des comptes, les comptes de service et les revues périodiques des droits d’accès. Les utilisateurs ne doivent disposer que des autorisations nécessaires à l’exercice de leurs responsabilités, et les accès devenus inutiles doivent être supprimés rapidement.
Les comptes à privilèges nécessitent des contrôles renforcés, car les administrateurs peuvent être en mesure d’accéder à de nombreux systèmes, configurations et données sensibles.
Les organisations doivent examiner la robustesse de l’authentification, les exigences d’approbation, la journalisation des activités, la surveillance des sessions, les procédures d’accès d’urgence et la rotation des identifiants. Dans la mesure du possible, les accès privilégiés doivent être limités dans le temps et faire l’objet d’une supervision renforcée.
Les droits d’accès au cloud doivent être modifiés rapidement lorsqu’un salarié rejoint l’organisation, change de fonction ou quitte l’entreprise.
Les revues d’accès doivent également inclure les prestataires, les travailleurs temporaires et les comptes de service, et ne pas se limiter aux salariés permanents. Les comptes inactifs, les autorisations inutiles et les identifiants non gérés peuvent créer une exposition importante aux risques de sécurité.
Des revues régulières des habilitations permettent de vérifier que les droits d’accès correspondent toujours aux besoins opérationnels actuels et de réduire le risque que d’anciens salariés, fournisseurs ou comptes automatisés conservent un accès inapproprié aux systèmes cloud.
La conformité de la sécurité cloud exige une visibilité suffisante sur les activités qui se déroulent dans l’environnement. Sans journalisation et surveillance fiables, les organisations peuvent rencontrer des difficultés pour détecter des comportements suspects, enquêter sur des incidents ou produire des éléments probants permettant de comprendre le déroulement d’un événement de sécurité.
Les journaux cloud pertinents peuvent notamment inclure les événements d’authentification, les actions des administrateurs, les modifications de configuration, les accès aux données, l’activité réseau, les alertes de sécurité et l’activité des API. Le périmètre de journalisation doit être adapté à la sensibilité du service, au modèle de menace et aux exigences de conformité applicables.
Les durées de conservation des journaux doivent permettre de répondre aux besoins liés aux enquêtes de sécurité, aux exigences réglementaires, aux politiques internes, à la préservation des éléments probants et à une gestion raisonnable des coûts.
La conservation doit être définie de manière intentionnelle et ne pas être illimitée. Les organisations doivent éviter de conserver indéfiniment des données personnelles inutiles simplement parce que la capacité de stockage cloud le permet. Les règles de conservation doivent également tenir compte du fait que les journaux peuvent contenir des identifiants, des informations sur l’activité des utilisateurs ou d’autres données à caractère personnel.
La collecte de journaux sans surveillance, analyse ni procédure d’escalade apporte une valeur de sécurité limitée.
Les organisations doivent définir des seuils d’alerte, les équipes responsables, les procédures d’enquête, les délais d’escalade et les exigences de conservation des éléments probants. Les événements à risque plus élevé, comme les modifications de comptes à privilèges, les schémas d’authentification inhabituels ou les changements importants de configuration, peuvent nécessiter une revue plus rapide.
La journalisation doit donc s’inscrire dans un processus actif de détection, et non fonctionner comme une simple archive technique.
La disponibilité du cloud ne garantit pas automatiquement la continuité d’activité. Même des environnements cloud très résilients peuvent être perturbés par des interruptions de service, des défaillances régionales, des rançongiciels, des suppressions accidentelles, une compromission d’identifiants, une dépendance excessive envers un fournisseur ou encore l’insolvabilité d’un prestataire et l’arrêt de ses services.
Les organisations doivent donc évaluer l’impact potentiel d’une défaillance du cloud sur leurs activités critiques et vérifier si les dispositifs de reprise répondent aux besoins opérationnels.
Les sauvegardes doivent être évaluées au regard de leur indépendance, de leur protection contre les modifications, de leur chiffrement, de leur capacité à être testées et de leur restaurabilité. Une sauvegarde existante mais impossible à restaurer dans les délais requis offre une résilience limitée.
Lorsque cela est possible, les organisations doivent également examiner si un rançongiciel ou la compromission d’identifiants administrateur pourrait affecter à la fois les systèmes de production et les copies de sauvegarde.
Les objectifs de temps de reprise et les objectifs de point de reprise doivent être définis en fonction de l’impact sur l’activité.
Ces objectifs permettent de déterminer dans quel délai les services doivent être rétablis et quel niveau de perte de données l’organisation peut accepter après un incident.
Les organisations doivent également évaluer les conséquences d’une dépendance à un seul CSP, à une seule région cloud, à une plateforme d’identité unique ou à un fournisseur SaaS unique.
Si un fournisseur critique devient indisponible, plusieurs processus métiers peuvent être interrompus simultanément.
Pour les organisations entrant dans le champ d’application de NIS2, la continuité d’activité et le risque lié à la chaîne d’approvisionnement doivent s’intégrer au cadre global de gestion des risques de cybersécurité. La résilience cloud doit donc être testée, documentée et réexaminée au même titre que les autres dépendances opérationnelles critiques.
La réponse aux incidents cloud doit traiter simultanément le confinement technique et les décisions réglementaires. Un événement de sécurité dans le cloud peut affecter à la fois la disponibilité des systèmes, les données personnelles, les obligations contractuelles et les services réglementés. Les organisations doivent donc disposer d’un processus coordonné dès la détection de l’incident.
Les contrats cloud doivent préciser dans quels délais le CSP doit informer le client, quelles informations doivent être communiquées, comment les journaux et autres éléments probants seront conservés, et de quelle manière le fournisseur apportera son soutien à l’enquête et au rétablissement des services.
Le client ne doit pas dépendre d’engagements vagues, tels qu’une notification « dans les meilleurs délais », sans comprendre comment cette obligation est mise en œuvre sur le plan opérationnel.
Lorsqu’une violation de données personnelles est susceptible d’engendrer un risque pour les personnes, le responsable du traitement peut être tenu de notifier l’autorité de contrôle compétente dans un délai de 72 heures à compter du moment où il en a connaissance. Lorsque la violation est susceptible d’engendrer un risque élevé, une communication aux personnes concernées peut également être requise.
La CNIL fournit des orientations officielles sur la notification des violations de données personnelles.
Pour les incidents significatifs, NIS2 prévoit généralement un processus de notification par étapes : une alerte précoce dans les 24 heures suivant la prise de connaissance de l’incident, une notification dans les 72 heures et un rapport final généralement dans un délai d’un mois, sous réserve des dispositions détaillées de la directive.
L’équipe chargée de la réponse aux incidents doit utiliser un processus coordonné afin de déterminer si un événement déclenche :
Une notification au titre de NIS2
Une notification de violation de données au titre du RGPD
Une notification contractuelle
Des exigences sectorielles spécifiques
Des obligations envers l’assureur
Une communication aux clients ou aux autres parties prenantes
Cette approche permet d’éviter que des équipes distinctes prennent des décisions incohérentes ou manquent certaines échéances. Le confinement technique, la préservation des éléments probants, l’analyse juridique, l’escalade auprès du fournisseur et la notification réglementaire doivent fonctionner comme des composantes coordonnées d’un même processus de réponse aux incidents.
L’examen de conformité du fournisseur cloud doit intervenir avant la signature du contrat ou le transfert de données sensibles vers le service. Une fois qu’une plateforme cloud est intégrée aux opérations de l’entreprise, il peut devenir nettement plus difficile de corriger des faiblesses contractuelles, de sécurité ou de localisation des données.
Les diligences doivent porter sur l’architecture du service, le modèle de sécurité, les certifications, la localisation des données, les sous-traitants ultérieurs, les procédures en cas de violation de données, les options de chiffrement, les contrôles d’accès, les dispositifs de sauvegarde, le processus de sortie ainsi que la capacité du fournisseur à répondre aux demandes des autorités de contrôle ou aux audits.
Le niveau d’examen doit être proportionné à l’utilisation prévue du service.
Un outil collaboratif à faible risque ne nécessite pas nécessairement le même niveau d’analyse qu’une plateforme hébergeant des données de santé, des informations financières, des dossiers de salariés ou des systèmes opérationnels critiques. Les services à risque plus élevé peuvent nécessiter un examen approfondi de la résilience, des accès privilégiés, du chiffrement, des transferts de données, de l’assistance en cas d’incident et de la continuité d’activité.
L’objectif est d’adapter le niveau d’assurance recherché à l’impact potentiel d’une défaillance ou d’une mauvaise utilisation.
Les diligences à l’égard d’un fournisseur cloud ne doivent pas s’arrêter à son intégration initiale.
Une réévaluation doit intervenir lorsque le service évolue de manière significative, que de nouveaux sous-traitants ultérieurs sont introduits, que la localisation des données change, qu’un incident de sécurité important survient ou que l’organisation étend l’utilisation du service.
Des revues périodiques permettent de confirmer que l’évaluation initiale des risques reste valable et que les contrôles contractuels, de protection des données et de sécurité continuent de répondre aux obligations de l’organisation en matière de conformité de la sécurité cloud.
Un fournisseur de services cloud sécurisé peut néanmoins être utilisé de manière non sécurisée. De nombreux incidents dans le cloud résultent de paramètres contrôlés par le client plutôt que d’une défaillance de l’infrastructure sous-jacente du fournisseur.
Les faiblesses courantes incluent des espaces de stockage exposés publiquement, des autorisations excessives, une journalisation désactivée, une authentification insuffisante, des clés API non sécurisées, des paramètres par défaut et des accès administrateur non restreints. Ces problèmes peuvent compromettre l’efficacité de contrôles de sécurité pourtant robustes mis en place par le fournisseur.
Les organisations doivent définir des standards de configuration approuvés pour les identités, les réseaux, le stockage, le chiffrement, la journalisation, les sauvegardes et l’exposition publique.
Ces configurations de référence doivent tenir compte de la sensibilité de la charge de travail et des exigences réglementaires applicables. Les systèmes à risque élevé peuvent nécessiter des contrôles d’accès plus stricts, une authentification renforcée, une surveillance supplémentaire et des restrictions plus importantes concernant l’exposition externe.
Les modifications de configuration doivent être encadrées par des procédures d’approbation des changements, des contrôles de sécurité automatisés, une revue de l’infrastructure en tant que code lorsque cela est pertinent, ainsi que des évaluations périodiques des configurations.
L’objectif est de détecter les modifications non sécurisées avant qu’elles ne créent une exposition significative.
Les équipes chargées de la conformité doivent également comprendre les limites des garanties fournies par le prestataire. Un CSP peut détenir des certifications reconnues et exploiter une plateforme sous-jacente sécurisée, mais ces certifications ne couvrent pas automatiquement les erreurs de configuration commises par le client.
Une conformité efficace de la sécurité cloud exige donc que les organisations encadrent la manière dont les services cloud sont configurés, modifiés et réexaminés tout au long de leur cycle de vie.
La norme ISO/IEC 27001:2022 définit les exigences relatives à l’établissement, à la mise en œuvre, au maintien et à l’amélioration continue d’un système de management de la sécurité de l’information, ou SMSI.
Dans le cadre de la conformité de la sécurité cloud, un SMSI peut aider les organisations à mettre en place un cadre structuré pour la gestion des risques, la responsabilité des actifs, la surveillance des fournisseurs, la réponse aux incidents, le contrôle des accès, la continuité d’activité, l’audit interne et l’amélioration continue. Cette approche est particulièrement utile lorsque les services cloud sont répartis entre plusieurs fournisseurs, unités opérationnelles ou environnements réglementaires.
ISO 27001 peut soutenir la conformité au RGPD et à NIS2 en fournissant un cadre de gouvernance, une évaluation documentée des risques, une attribution claire des responsabilités et des éléments probants démontrant que les contrôles de sécurité font l’objet de revues et d’améliorations.
Toutefois, une certification ISO 27001 ne démontre pas automatiquement la conformité au RGPD ou à NIS2. Ces deux cadres imposent des obligations juridiques qui doivent toujours être évaluées et mises en correspondance séparément avec les activités, les systèmes et le périmètre réglementaire de l’organisation.
Les environnements cloud doivent être explicitement intégrés au SMSI plutôt que considérés comme des technologies externes au programme de sécurité.
Les actifs cloud pertinents, les CSP et les sous-traitants ultérieurs doivent être pris en compte dans le périmètre du SMSI, l’évaluation des risques, l’inventaire des actifs, les contrôles fournisseurs, les processus de gestion des incidents, le programme d’audit et la revue de direction.
Cette approche permet d’établir une traçabilité entre les risques liés au cloud, les contrôles attribués, les responsabilités des fournisseurs et les éléments probants utilisés pour démontrer que ces contrôles restent efficaces dans le temps.
Une matrice de contrôle de la conformité de la sécurité cloud peut aider les organisations à relier les exigences réglementaires aux éléments probants produits dans le cadre des opérations quotidiennes. Plutôt que de créer une nouvelle liste de contrôle générale, la matrice doit montrer précisément comment chaque contrôle cloud important est attribué, mis en œuvre, démontré et amélioré.
Pour chaque contrôle significatif, il convient de consigner l’exigence juridique, réglementaire, contractuelle ou opérationnelle concernée, le responsable interne du contrôle, la responsabilité du CSP, celle du client, l’état actuel de mise en œuvre, les éléments probants disponibles, les écarts identifiés et la date cible de remédiation.
Les domaines de contrôle courants peuvent notamment inclure la gestion des accès, le chiffrement, la journalisation, les sauvegardes, la gestion des vulnérabilités, les sous-traitants ultérieurs, les transferts internationaux de données, la réponse aux incidents et la suppression sécurisée des données.
La matrice doit également refléter le modèle de responsabilité partagée. Par exemple, un CSP peut fournir une fonctionnalité de chiffrement, tandis que le client reste responsable de l’activation des paramètres appropriés, du contrôle de l’accès aux clés et de l’examen des éléments probants démontrant que la configuration fonctionne comme prévu.
Utilisée correctement, cette matrice permet d’établir une traçabilité entre le RGPD, NIS2, les obligations contractuelles et les contrôles cloud réellement mis en œuvre. Elle offre également aux équipes chargées de la conformité, de la sécurité, des achats et de l’audit une vision commune des responsabilités et des risques restant à traiter.
La matrice doit être mise à jour lorsque les services, les fournisseurs, les réglementations, les configurations ou les évaluations des risques évoluent. Cela permet de maintenir à jour les éléments probants relatifs à la conformité cloud et d’éviter que des lacunes de contrôle restent dissimulées dans les contrats ou la documentation technique.
Un programme pratique de conformité de la sécurité cloud doit relier la gouvernance, la surveillance des fournisseurs, les contrôles techniques et les éléments probants réglementaires au moyen d’une séquence de mise en œuvre claire.
Identifiez tous les services cloud utilisés, les données qu’ils traitent, les responsables métiers, les CSP, les sous-traitants ultérieurs et les exigences réglementaires applicables. Incluez les plateformes approuvées ainsi que les outils cloud relevant du shadow IT ou gérés directement par les équipes métiers.
Déterminez quels systèmes cloud traitent des données personnelles, des informations sensibles ou des charges de travail opérationnelles critiques. Cette classification doit influencer les exigences de sécurité, le niveau de diligences, les contrôles d’accès et les attentes en matière de résilience.
Examinez les clauses applicables aux sous-traitants, la localisation des données, les transferts internationaux, les sous-traitants ultérieurs, les éléments probants en matière de sécurité, les obligations de notification des incidents et les dispositions de sortie. Confirmez la répartition des responsabilités entre le fournisseur et le client.
Donnez la priorité à la gestion des identités, à l’authentification multifacteur, au principe du moindre privilège, au chiffrement, à la journalisation, aux sauvegardes, à la surveillance et aux contrôles réseau. Appliquez des configurations de référence sécurisées et documentez les exceptions.
Mettez en place un processus unique couvrant la détection, l’escalade auprès du fournisseur, la préservation des éléments probants, l’évaluation au titre du RGPD, l’évaluation au titre de NIS2 et les notifications réglementaires. Définissez les responsabilités et les délais d’escalade avant qu’un incident ne survienne.
Testez la restauration des sauvegardes, les procédures de reprise, les interruptions de service du fournisseur, les comptes compromis et les scénarios de rançongiciel. Comparez les résultats aux objectifs de continuité d’activité définis.
Examinez les changements chez les fournisseurs, les droits d’accès, les vulnérabilités, les incidents de sécurité, les conclusions d’audit, les sous-traitants ultérieurs et les évolutions réglementaires pertinentes.
Utilisez les résultats d’audit, les évaluations des risques, les incidents et les défaillances de contrôle pour mettre à jour les contrôles cloud, les priorités de remédiation et les décisions de la direction.
Cette feuille de route doit fonctionner comme un cycle continu. Les services cloud, les réglementations et les conditions de menace évoluent, et la conformité doit évoluer avec eux.
Utilisez cette liste de contrôle synthétique pour vérifier si les processus de gouvernance, de sécurité, de protection des données et d’assurance liés au cloud fonctionnent efficacement de manière coordonnée.
Gouvernance et fournisseurs : Tous les services cloud ont-ils été recensés, y compris les outils gérés directement par les équipes métiers ? Les rôles au titre du RGPD, de NIS2 et des obligations contractuelles sont-ils clairement compris ? Les contrats avec les CSP, les sous-traitants ultérieurs, la localisation des données et les éléments probants en matière de sécurité ont-ils été examinés ? Les responsabilités respectives du fournisseur et du client sont-elles formellement attribuées ?
Sécurité et protection des données : L’authentification multifacteur, le principe du moindre privilège, le chiffrement, la journalisation, les sauvegardes et la surveillance sont-ils configurés de manière appropriée ? Les flux de données personnelles sont-ils cartographiés ? Les transferts internationaux ont-ils été évalués au regard des exigences applicables du RGPD ? Les processus de conservation, de suppression et de revue des accès sont-ils définis et opérationnels ?
Incidents et résilience : L’organisation peut-elle obtenir suffisamment rapidement du fournisseur les informations relatives à un incident pour permettre l’évaluation réglementaire ? Les processus de notification au titre du RGPD et de NIS2 sont-ils documentés et coordonnés ? Des scénarios portant sur la restauration des sauvegardes, les rançongiciels, la compromission de comptes et les interruptions de services cloud ont-ils été testés ?
Assurance : Les contrôles des CSP, les certifications et les configurations relevant du client font-ils l’objet de revues périodiques ? Les écarts identifiés sont-ils attribués à des responsables et suivis jusqu’à leur remédiation ? Les risques liés au cloud sont-ils intégrés au SMSI de l’organisation, à l’audit interne, aux processus de revue des fournisseurs et à la revue de direction ?
Une liste de contrôle efficace doit conduire à des éléments probants. Lorsque la réponse est « oui », l’organisation doit être en mesure de présenter le contrat, la configuration, le journal, l’évaluation, le résultat de test ou la décision de direction correspondant.
Le recours à un grand fournisseur de services cloud ne transfère pas l’ensemble des responsabilités réglementaires au prestataire. Meilleure approche : documenter quels contrôles relèvent du CSP, lesquels restent à la charge du client et quels éléments probants permettent de démontrer chaque responsabilité.
Les certifications peuvent renforcer le niveau d’assurance, mais elles ne prouvent pas que chaque service ou chaque configuration client est sécurisé. Meilleure approche : évaluer le service concerné, son utilisation prévue, les données traitées et les configurations appliquées.
Les services cloud reposent souvent sur des prestataires supplémentaires. Meilleure approche : comprendre l’ensemble de la chaîne de services, les sous-traitants ultérieurs et les flux de données réels.
La résidence des données dans l’Union européenne n’exclut pas l’existence d’accès depuis l’étranger. Meilleure approche : examiner la localisation des équipes de support, l’administration à distance, les sauvegardes et les sous-traitants ultérieurs.
Des contrôles CSP robustes ont peu de valeur si le client ne les configure pas correctement. Meilleure approche : définir, appliquer et tester des configurations de référence sécurisées.
Des processus séparés peuvent entraîner des retards et des décisions incohérentes. Meilleure approche : utiliser un processus coordonné de gestion des incidents intégrant des évaluations juridiques distinctes.
Le risque lié à la fin de la relation avec le fournisseur est souvent pris en compte trop tard. Meilleure approche : définir les modalités d’exportation des données, de suppression, de transition et de continuité avant la fin de la relation contractuelle.
La conformité de la sécurité cloud ne repose pas uniquement sur les certifications des fournisseurs ou sur les paramètres techniques. Les organisations ont besoin d’une attribution claire des responsabilités en matière de risques, de contrôles documentés, d’une surveillance des fournisseurs, de processus de gestion des incidents et d’une démarche d’amélioration continue.
La formation ISO 27001 Lead Implementer du French Compliance Institute aide les professionnels à comprendre comment établir et mettre en œuvre un système de management de la sécurité de l’information fondé sur l’évaluation des risques, la gouvernance, la mise en œuvre des contrôles et l’amélioration continue.
Ces compétences peuvent soutenir une approche plus globale de la sécurité cloud, des obligations de sécurité prévues par le RGPD et de la préparation à NIS2, en aidant les organisations à relier les mesures techniques à des processus de management structurés et à des éléments probants.
La formation doit compléter, et non remplacer, les démarches de conformité juridique et réglementaire propres à chaque organisation.
La conformité de la sécurité cloud exige que les organisations comprennent à la fois leurs propres responsabilités et les contrôles mis en œuvre par leurs fournisseurs de services cloud. Le RGPD encadre la manière dont les données à caractère personnel sont traitées, sécurisées et transférées, tandis que NIS2 introduit des exigences plus larges en matière de cybersécurité, de résilience, de chaîne d’approvisionnement et de gestion des incidents pour les entités entrant dans son champ d’application.
Le recours à un CSP majeur ne supprime pas la responsabilité du client. Les organisations doivent cartographier leurs systèmes cloud et leurs données, examiner les fournisseurs et les contrats, configurer des contrôles techniques appropriés, évaluer les transferts internationaux, préparer des processus coordonnés de gestion des incidents et conserver des éléments probants démontrant que les contrôles fonctionnent efficacement.
ISO/IEC 27001 peut fournir une structure de système de management utile pour intégrer la gestion des risques, la surveillance des fournisseurs, la réponse aux incidents et l’amélioration continue. Toutefois, la certification ne doit pas être considérée comme une preuve automatique de conformité au RGPD ou à NIS2.
Les organisations qui associent protection des données dans le cloud, gouvernance des fournisseurs, sécurité technique et gestion continue des risques seront mieux placées pour démontrer une conformité efficace de la sécurité cloud.
Découvrez comment choisir un logiciel de conformité RGPD selon ses fonctions, sa sécurité, ses intégrations, son prix et son évolutivité.
Découvrez comment choisir le meilleur logiciel de conformité au RGPD pour les PME françaises. Comparez les fonctionnalités, les tarifs, le déploiement et les exigences de...
Découvrez comment créer un plan HACCP étape par étape : analyse des dangers, CCP, limites critiques, surveillance, actions correctives et vérification.