Sécurité du cloud : le modèle de responsabilité partagée et vos obligations légales

La migration vers le cloud est devenue un mouvement structurel pour l’ensemble des organisations, des TPE aux grands groupes. Mais cette externalisation des infrastructures et des données ne signifie en aucun cas une externalisation de la responsabilité juridique. Le modèle dit de “responsabilité partagée” – shared responsibility model – est au coeur de la relation entre le fournisseur cloud et son client. Mal compris, il est la source de failles de sécurité majeures et d’une exposition juridique considérable. Cet article analyse en détail les obligations respectives des parties, le cadre légal applicable et les mesures concrètes à mettre en oeuvre.

I. Le modèle de responsabilité partagée : principes fondamentaux

A. Définition et logique du modèle

Le modèle de responsabilité partagée est un principe selon lequel la sécurité de l’environnement cloud est répartie entre le fournisseur de services cloud (CSP) et le client. Le CSP est responsable de la sécurité du cloud – c’est-à-dire de l’infrastructure physique, du réseau, de l’hyperviseur, et des couches de virtualisation. Le client est responsable de la sécurité dans le cloud – c’est-à-dire de ses données, de ses configurations, de la gestion des accès et de ses applications.

Cette répartition varie selon le modèle de service utilise :

• IaaS (Infrastructure as a Service) : le client assumé la responsabilité la plus large. Il gère le système d’exploitation, le middleware, les applications, les données et les configurations réseau virtuelles. Le CSP ne fournit que l’infrastructure de base.
• PaaS (Platform as a Service) : la responsabilité du client se réduit aux données, aux applications et à la gestion des identités. Le CSP prend en charge le système d’exploitation et le middleware.
• SaaS (Software as a Service) : le client ne gère essentiellement que ses données et les paramètres d’accès. Tout le reste est sous la responsabilité du CSP.

B. Les zones grises de la répartition

En pratique, la frontiere entre les responsabilités respectives est souvent floue. Les incidents de sécurité cloud les plus gravés surviennent précisément dans ces zones grises. La configuration des buckets de stockage (S3, Azure Blob, GCS) en est l’exemple emblématique : le CSP fournit les outils de contrôle d’accès, mais c’est au client de les configurer correctement. Des centaines de fuites de données massives ont été causées par des buckets laissés en accès public par des clients qui pensaient que le CSP gerait cet aspect.

De même, le chiffrement des données illustré cette ambiguïté. Le CSP peut proposer le chiffrement au repos et en transit, mais le client doit l’activer, gérer ses clés, et s’assurer que les données sensibles sont effectivement couvertes. Pour approfondir les obligations en matière de chiffrement des données, une analyse dédiée s’impose.

II. Le cadre juridique applicable à la sécurité du cloud

A. Les exigences du RGPD

Le règlement général sur la protection des données (RGPD) impose au responsable de traitement de mettre en oeuvre des “mesures techniques et organisationnelles appropriées” pour garantir un niveau de sécurité adapté au risque (article 32). Cette obligation ne disparait pas lorsque le traitement est confié à un sous-traitant cloud. L’article 28 du RGPD impose que le sous-traitant présente des “garanties suffisantes quant à la mise en oeuvre de mesures techniques et organisationnelles appropriées”.

Concrètement, le responsable de traitement doit :

1. Évaluer les garanties du CSP avant toute contractualisation, en examinant ses certifications, ses politiques de sécurité et ses mesures techniques.
2. Formaliser la relation contractuelle par un accord de sous-traitance conforme à l’article 28 du RGPD, détaillant les mesures de sécurité, les obligations en cas de violation de données, et les conditions d’audit.
3. Maintenir une supervision effective tout au long de la relation contractuelle, y compris par des audits périodiques.

La CNIL a precise dans ses recommandations que le recours au cloud ne décharge pas le responsable de traitement de son obligation de maîtriser la sécurité des données. Pour une vision globale des mesures de sécurité exigées par la CNIL dans le cadre du RGPD, il convient d’examiner ses guidelines les plus récentes.

B. Les obligations issues de NIS2

La directive NIS2 renforcé considérablement les exigences de sécurité pour les entités essentielles et importantes. Son article 21 impose des mesures de gestion des risques en matière de cybersécurité qui couvrent explicitement la “sécurité de la chaîne d’approvisionnement”, ce qui inclut directement la relation avec les fournisseurs cloud.

Les entités soumises à NIS2 doivent évaluer les risques lies à leurs prestataires cloud, intégrer des clauses de sécurité dans les contrats, et s’assurer de la capacité du CSP a notifier rapidement tout incident affectant leurs systèmes. La checklist de conformité NIS2 fournit un cadre pratique pour structurer cette démarche.

Les sanctions prévues par NIS2 sont dissuasives : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles. L’absence de maîtrisé de la sécurité cloud peut constituer un manquement caractérisé.

C. Le référentiel SecNumCloud de l’ANSSI

En France, l’ANSSI a développé le référentiel SecNumCloud, qui définit un niveau de sécurité exigeant pour les services cloud. Ce référentiel couvre la sécurité physique, la gestion des incidents, le cloisonnement, la cryptographie et la localisation des données. Il constitue la référence pour les administrations et les opérateurs d’importance vitale, et tend a s’imposer comme un standard de marché pour les données sensibles.

III. Mesures contractuelles et techniques indispensables

A. Les clauses contractuelles essentielles

Le contrat avec le CSP est le principal instrument juridique de maîtrisé du risque. Il doit impérativement contenir :

• La description precise des mesures de sécurité mises en oeuvre par le CSP, avec des engagements de niveau de service (SLA) mesurables.
• Les obligations de notification d’incident : délais de notification, contenu de l’alerte, coopération dans la gestion de l’incident. Pour approfondir les obligations de notification en cas de cyberattaque, un cadre dédié est nécessaire.
• Le droit d’audit : le client doit pouvoir auditer ou faire auditer les mesures de sécurité du CSP, directement ou par l’intermédiaire de rapports tiers (SOC 2, ISO 27001).
• Les conditions de réversibilité : la capacité à récupérer ses données dans un format exploitable et dans des délais raisonnables en cas de changement de prestataire.
• La localisation des données et les restrictions de transfert hors UE.

B. Les mesures techniques cote client

Même dans un environnement SaaS, le client conservé des responsabilités techniques significatives :

1. Gestion des identités et des accès (IAM) : mise en oeuvre du principe du moindre privilège, authentification multifacteur obligatoire, revue périodique des droits d’accès.
2. Chiffrement : chiffrement des données sensibles avec des clés gérées par le client (BYOK – Bring Your Own Key), et non uniquement par le CSP.
3. Journalisation et surveillance : activation et centralisation des logs d’accès et d’activité, mise en place d’alertes sur les comportements anormaux.
4. Sauvegarde indépendante : ne pas dépendre uniquement des mécanismes de sauvegarde du CSP. Maintenir des copies externes pour garantir la disponibilité en cas de défaillance du prestataire.
5. Tests de sécurité : réaliser des audits de sécurité réguliers de l’environnement cloud, incluant des tests de pénétration et des revues de configuration.

C. La gestion des incidents dans le cloud

La survenance d’un incident de sécurité dans un environnement cloud posé des défis spécifiques. Le client dépend du CSP pour une partie de l’investigation forensique, ce qui peut ralentir la réponse. La gestion des incidents de sécurité doit être adaptée pour tenir compte de cette dépendance.

Il est essentiel de définir à l’avance les procédures de coordination avec le CSP : points de contact, canaux de communication sécurisés, partagé des indicateurs de compromission, et coopération dans la remédiation.

IV. Erreurs courantes et bonnes pratiques

A. Les erreurs les plus fréquentes

Plusieurs erreurs reviennent de manière récurrente dans les projets cloud :

• Croire que le CSP gère tout : c’est le piège principal du modèle de responsabilité partagée. Le client qui ne configure pas ses paramètres de sécurité s’expose à des incidents majeurs.
• Négliger la gestion des accès : des comptes privilégiés sans authentification forte, des droits excessifs non revises, des comptes de service avec des permissions trop larges.
• Omettre le chiffrement : stocker des données sensibles en clair dans le cloud en s’appuyant uniquement sur les contrôles d’accès, sans couche de chiffrement supplémentaire.
• Ignorer les logs : ne pas activer ou ne pas surveiller les journaux d’activité, ce qui rend toute détection d’intrusion impossible.

B. Recommandations pratiques

Pour structurer la démarche de sécurité cloud, il convient de suivre les référentiels reconnus. La certification ISO 27001 couvre explicitement la sécurité des relations avec les fournisseurs (annexe A.15) et constitue un cadre robuste. Le guide de l’ANSSI pour les TPE/PME propose des mesures directement applicables, y compris pour les environnements cloud.

Au niveau européen, l’ENISA publié régulièrement des guides de sécurité cloud qui méritent d’être consultés et intégrés dans la politique de sécurité de l’organisation.

Le rôle du RSSI est central dans cette démarche : c’est à lui de piloter l’évaluation des risques cloud, de valider les mesures de sécurité et de maintenir une veille sur les vulnérabilités spécifiques aux environnements cloud.

FAQ

Le fournisseur cloud est-il responsable en cas de fuite de données personnelles ?

Non, pas nécessairement. Le modèle de responsabilité partagée signifie que si la fuite résulte d’une mauvaise configuration cote client (buckets publics, accès non restreints), la responsabilité incombe au client en tant que responsable de traitement au sens du RGPD. Le CSP n’est responsable que des défaillances affectant les couches sous son contrôle. La CNIL a rappelé que le responsable de traitement doit vérifier et maîtriser la configuration de sécurité de ses environnements cloud.

La certification ISO 27001 du fournisseur cloud suffit-elle a couvrir mes obligations ?

Non. La certification ISO 27001 du CSP atteste de la qualité de son système de management de la sécurité, mais elle ne couvre pas les responsabilités du client. Vous devez mettre en oeuvre vos propres mesures de sécurité dans le cloud, conduire vos propres évaluations de risques, et formaliser contractuellement les engagements du prestataire. La certification est un élément de confiance, pas un transfert de responsabilité.

Quelles sont les conséquences d’un défaut de sécurité cloud au regard de NIS2 ?

Les entités soumises à la directive NIS2 qui ne maîtrisent pas adequatement la sécurité de leur environnement cloud s’exposent à des sanctions pouvant atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial. Au-delà des sanctions financières, les autorités peuvent imposer des mesures correctives contraignantes et, pour les entités essentielles, suspendre temporairement les activités de dirigeants.

Faut-il privilégier un cloud souverain pour les données sensibles ?

Le choix d’un cloud souverain – ou qualifié SecNumCloud – est recommandé pour les données les plus sensibles, en particulier pour les administrations et les opérateurs d’importance vitale. Ce choix garantit que les données restent sous juridiction française et européenne, à l’abri du Cloud Act américain et d’autres législations extraterritoriales. Pour les autres organisations, l’analyse de risques doit guider le choix en fonction de la sensibilité des données traitées et des exigences réglementaires applicables.