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 donnees ne signifie en aucun cas une externalisation de la responsabilite juridique. Le modele dit de “responsabilite partagee” – 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 securite majeures et d’une exposition juridique considerable. Cet article analyse en detail les obligations respectives des parties, le cadre legal applicable et les mesures concretes a mettre en oeuvre.

I. Le modele de responsabilite partagee : principes fondamentaux

A. Definition et logique du modele

Le modele de responsabilite partagee est un principe selon lequel la securite de l’environnement cloud est repartie entre le fournisseur de services cloud (CSP) et le client. Le CSP est responsable de la securite du cloud – c’est-a-dire de l’infrastructure physique, du reseau, de l’hyperviseur, et des couches de virtualisation. Le client est responsable de la securite dans le cloud – c’est-a-dire de ses donnees, de ses configurations, de la gestion des acces et de ses applications.

Cette repartition varie selon le modele de service utilise :

• IaaS (Infrastructure as a Service) : le client assume la responsabilite la plus large. Il gere le systeme d’exploitation, le middleware, les applications, les donnees et les configurations reseau virtuelles. Le CSP ne fournit que l’infrastructure de base.
• PaaS (Platform as a Service) : la responsabilite du client se reduit aux donnees, aux applications et a la gestion des identites. Le CSP prend en charge le systeme d’exploitation et le middleware.
• SaaS (Software as a Service) : le client ne gere essentiellement que ses donnees et les parametres d’acces. Tout le reste est sous la responsabilite du CSP.

B. Les zones grises de la repartition

En pratique, la frontiere entre les responsabilites respectives est souvent floue. Les incidents de securite cloud les plus graves surviennent precisement dans ces zones grises. La configuration des buckets de stockage (S3, Azure Blob, GCS) en est l’exemple emblematique : le CSP fournit les outils de controle d’acces, mais c’est au client de les configurer correctement. Des centaines de fuites de donnees massives ont ete causees par des buckets laisses en acces public par des clients qui pensaient que le CSP gerait cet aspect.

De meme, le chiffrement des donnees illustre cette ambiguite. Le CSP peut proposer le chiffrement au repos et en transit, mais le client doit l’activer, gerer ses cles, et s’assurer que les donnees sensibles sont effectivement couvertes. Pour approfondir les obligations en matiere de chiffrement des donnees, une analyse dediee s’impose.

II. Le cadre juridique applicable a la securite du cloud

A. Les exigences du RGPD

Le reglement general sur la protection des donnees (RGPD) impose au responsable de traitement de mettre en oeuvre des “mesures techniques et organisationnelles appropriees” pour garantir un niveau de securite adapte au risque (article 32). Cette obligation ne disparait pas lorsque le traitement est confie a un sous-traitant cloud. L’article 28 du RGPD impose que le sous-traitant presente des “garanties suffisantes quant a la mise en oeuvre de mesures techniques et organisationnelles appropriees”.

Concretement, le responsable de traitement doit :

1. Evaluer les garanties du CSP avant toute contractualisation, en examinant ses certifications, ses politiques de securite et ses mesures techniques.
2. Formaliser la relation contractuelle par un accord de sous-traitance conforme a l’article 28 du RGPD, detaillant les mesures de securite, les obligations en cas de violation de donnees, et les conditions d’audit.
3. Maintenir une supervision effective tout au long de la relation contractuelle, y compris par des audits periodiques.

La CNIL a precise dans ses recommandations que le recours au cloud ne decharge pas le responsable de traitement de son obligation de maitriser la securite des donnees. Pour une vision globale des mesures de securite exigees par la CNIL dans le cadre du RGPD, il convient d’examiner ses guidelines les plus recentes.

B. Les obligations issues de NIS2

La directive NIS2 renforce considerablement les exigences de securite pour les entites essentielles et importantes. Son article 21 impose des mesures de gestion des risques en matiere de cybersecurite qui couvrent explicitement la “securite de la chaine d’approvisionnement”, ce qui inclut directement la relation avec les fournisseurs cloud.

Les entites soumises a NIS2 doivent evaluer les risques lies a leurs prestataires cloud, integrer des clauses de securite dans les contrats, et s’assurer de la capacite du CSP a notifier rapidement tout incident affectant leurs systemes. La checklist de conformite NIS2 fournit un cadre pratique pour structurer cette demarche.

Les sanctions prevues par NIS2 sont dissuasives : jusqu’a 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entites essentielles. L’absence de maitrise de la securite cloud peut constituer un manquement caracterise.

C. Le referentiel SecNumCloud de l’ANSSI

En France, l’ANSSI a developpe le referentiel SecNumCloud, qui definit un niveau de securite exigeant pour les services cloud. Ce referentiel couvre la securite physique, la gestion des incidents, le cloisonnement, la cryptographie et la localisation des donnees. Il constitue la reference pour les administrations et les operateurs d’importance vitale, et tend a s’imposer comme un standard de marche pour les donnees sensibles.

III. Mesures contractuelles et techniques indispensables

A. Les clauses contractuelles essentielles

Le contrat avec le CSP est le principal instrument juridique de maitrise du risque. Il doit imperativement contenir :

• La description precise des mesures de securite mises en oeuvre par le CSP, avec des engagements de niveau de service (SLA) mesurables.
• Les obligations de notification d’incident : delais de notification, contenu de l’alerte, cooperation dans la gestion de l’incident. Pour approfondir les obligations de notification en cas de cyberattaque, un cadre dedie est necessaire.
• Le droit d’audit : le client doit pouvoir auditer ou faire auditer les mesures de securite du CSP, directement ou par l’intermediaire de rapports tiers (SOC 2, ISO 27001).
• Les conditions de reversibilite : la capacite a recuperer ses donnees dans un format exploitable et dans des delais raisonnables en cas de changement de prestataire.
• La localisation des donnees et les restrictions de transfert hors UE.

B. Les mesures techniques cote client

Meme dans un environnement SaaS, le client conserve des responsabilites techniques significatives :

1. Gestion des identites et des acces (IAM) : mise en oeuvre du principe du moindre privilege, authentification multifacteur obligatoire, revue periodique des droits d’acces.
2. Chiffrement : chiffrement des donnees sensibles avec des cles gerees par le client (BYOK – Bring Your Own Key), et non uniquement par le CSP.
3. Journalisation et surveillance : activation et centralisation des logs d’acces et d’activite, mise en place d’alertes sur les comportements anormaux.
4. Sauvegarde independante : ne pas dependre uniquement des mecanismes de sauvegarde du CSP. Maintenir des copies externes pour garantir la disponibilite en cas de defaillance du prestataire.
5. Tests de securite : realiser des audits de securite reguliers de l’environnement cloud, incluant des tests de penetration et des revues de configuration.

C. La gestion des incidents dans le cloud

La survenance d’un incident de securite dans un environnement cloud pose des defis specifiques. Le client depend du CSP pour une partie de l’investigation forensique, ce qui peut ralentir la reponse. La gestion des incidents de securite doit etre adaptee pour tenir compte de cette dependance.

Il est essentiel de definir a l’avance les procedures de coordination avec le CSP : points de contact, canaux de communication securises, partage des indicateurs de compromission, et cooperation dans la remediation.

IV. Erreurs courantes et bonnes pratiques

A. Les erreurs les plus frequentes

Plusieurs erreurs reviennent de maniere recurrente dans les projets cloud :

• Croire que le CSP gere tout : c’est le piege principal du modele de responsabilite partagee. Le client qui ne configure pas ses parametres de securite s’expose a des incidents majeurs.
• Negliger la gestion des acces : des comptes privilegies sans authentification forte, des droits excessifs non revises, des comptes de service avec des permissions trop larges.
• Omettre le chiffrement : stocker des donnees sensibles en clair dans le cloud en s’appuyant uniquement sur les controles d’acces, sans couche de chiffrement supplementaire.
• Ignorer les logs : ne pas activer ou ne pas surveiller les journaux d’activite, ce qui rend toute detection d’intrusion impossible.

B. Recommandations pratiques

Pour structurer la demarche de securite cloud, il convient de suivre les referentiels reconnus. La certification ISO 27001 couvre explicitement la securite 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 europeen, l’ENISA publie regulierement des guides de securite cloud qui meritent d’etre consultes et integres dans la politique de securite de l’organisation.

Le role du RSSI est central dans cette demarche : c’est a lui de piloter l’evaluation des risques cloud, de valider les mesures de securite et de maintenir une veille sur les vulnerabilites specifiques aux environnements cloud.

FAQ

Le fournisseur cloud est-il responsable en cas de fuite de donnees personnelles ?

Non, pas necessairement. Le modele de responsabilite partagee signifie que si la fuite resulte d’une mauvaise configuration cote client (buckets publics, acces non restreints), la responsabilite incombe au client en tant que responsable de traitement au sens du RGPD. Le CSP n’est responsable que des defaillances affectant les couches sous son controle. La CNIL a rappele que le responsable de traitement doit verifier et maitriser la configuration de securite 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 qualite de son systeme de management de la securite, mais elle ne couvre pas les responsabilites du client. Vous devez mettre en oeuvre vos propres mesures de securite dans le cloud, conduire vos propres evaluations de risques, et formaliser contractuellement les engagements du prestataire. La certification est un element de confiance, pas un transfert de responsabilite.

Quelles sont les consequences d’un defaut de securite cloud au regard de NIS2 ?

Les entites soumises a la directive NIS2 qui ne maitrisent pas adequatement la securite de leur environnement cloud s’exposent a des sanctions pouvant atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial. Au-dela des sanctions financieres, les autorites peuvent imposer des mesures correctives contraignantes et, pour les entites essentielles, suspendre temporairement les activites de dirigeants.

Faut-il privilegier un cloud souverain pour les donnees sensibles ?

Le choix d’un cloud souverain – ou qualifie SecNumCloud – est recommande pour les donnees les plus sensibles, en particulier pour les administrations et les operateurs d’importance vitale. Ce choix garantit que les donnees restent sous juridiction francaise et europeenne, a l’abri du Cloud Act americain et d’autres legislations extraterritoriales. Pour les autres organisations, l’analyse de risques doit guider le choix en fonction de la sensibilite des donnees traitees et des exigences reglementaires applicables.