Sécurité cloud : responsabilités et contrôles

La sécurité du cloud repose sur une répartition explicite des tâches entre le client et le fournisseur. Il faut savoir qui configure les accès, applique les correctifs, conserve les preuves et réagit à un incident. Cette répartition opérationnelle ne suffit toutefois pas à déterminer les responsabilités juridiques au titre du RGPD.

Responsabilité partagée : partir du service réellement acheté

Les modèles IaaS, PaaS et SaaS aident à comprendre les couches gérées par chaque partie. En IaaS, le client administre généralement davantage de composants, notamment ses systèmes et applications. En SaaS, il conserve des décisions sur l’utilisation, les données et les paramètres accessibles. Le détail varie selon l’offre.

Microsoft précise d’ailleurs que son schéma de responsabilité partagée est une présentation de gouvernance, sans modifier les accords ni constituer une conclusion juridique. Il faut donc examiner le service et son contrat, plutôt que déduire toutes les obligations de son étiquette commerciale. Source : Microsoft, responsabilité partagée dans le cloud.

Qualifier séparément les traitements de données

Le fournisseur peut agir comme sous-traitant pour fournir le service, tout en étant responsable d’autres traitements poursuivant ses propres finalités. Les orientations CNIL du 28 mai 2026 distinguent notamment fourniture, amélioration du service et sécurité. La qualification dépend des faits et des décisions prises par les parties. Source : CNIL, qualifications des acteurs du cloud.

Examinez donc séparément le contenu confié, les données de compte, la télémétrie et les journaux. Une clause déclarant le fournisseur « sous-traitant » ne doit pas masquer une réutilisation pour une finalité distincte.

Pour les opérations sous-traitées, l’Art. 28(1) et (3) du RGPD exige des garanties suffisantes et un contrat conforme. L’Art. 32 prévoit des obligations de sécurité pour le responsable comme pour le sous-traitant. Source : RGPD, Art. 28 et 32.

Le guide de la sécurité des fournisseurs aide à examiner les clauses, les audits et les sous-traitants ultérieurs.

Construire une matrice des tâches et des preuves

Voici une trame de revue proposée. Pour chaque ligne, affectez un responsable d’exécution, une personne qui vérifie et une preuve disponible. Les réponses doivent correspondre à la configuration et au contrat réellement retenus.

La CNIL recommande notamment d’inventorier les services cloud, de formaliser la répartition contractuelle et de configurer les protections disponibles. Ces tâches doivent être intégrées à l’analyse des risques. Source : CNIL, sécurité du cloud.

Chiffrement et localisation : vérifier les garanties exactes

Un chiffrement côté serveur ne démontre pas que le fournisseur ne peut jamais accéder aux données. Examinez qui dispose des clés, les opérations nécessitant un accès en clair et les possibilités réelles de contrôle. La fiche CNIL souligne expressément cette limite. Source : CNIL, sécurité du cloud.

Le guide du chiffrement distingue les objectifs et les dépendances. Le seul intitulé « BYOK » ne décrit pas toute l’architecture ni les accès administratifs.

Pour les transferts de données personnelles vers des pays tiers, examinez les conditions des Art. 44 et suivants du RGPD. Une région d’hébergement européenne ne dispense pas d’identifier les destinataires, les accès de support et les transferts éventuels. Les garanties requises dépendent du flux concerné. Source : RGPD, chapitre V.

SecNumCloud : vérifier l’offre qualifiée et ses limites

La qualification vise un service et un périmètre définis. L’ANSSI indique qu’elle ne préjuge pas de la sécurité du service numérique que le client déploie dessus. Elle évalue notamment des garanties techniques et juridiques face aux menaces et aux injonctions extraterritoriales. L’appellation commerciale « souverain » ne suffit pas à établir l’existence de cette qualification. Source : ANSSI, FAQ SecNumCloud.

Le guide SecNumCloud permet de préparer cette vérification. Les exigences sectorielles ou propres à certains acteurs doivent être étudiées séparément ; il ne faut pas présenter une même obligation d’achat comme applicable à tout utilisateur du cloud.

Préparer l’exploitation et le changement de fournisseur

Pour la centralisation des événements cloud, vérifiez les sources réellement disponibles, les droits nécessaires et les frais d’ingestion. Notre comparatif SIEM permet de comparer ces paramètres avec la conservation et le travail d’analyse, sur un même périmètre de collecte.

Lors d’un changement de fournisseur, suivez aussi les clés, accès et copies pendant une migration cloud. Le plan de bascule permet d’attribuer les responsabilités à chaque étape et de vérifier la révocation des anciens accès.

Le contrat RGPD doit organiser l’assistance pertinente et, en fin de prestation, le renvoi ou la suppression des données selon l’Art. 28(3)(f) et (g). Le sous-traitant signale une violation de données dans les meilleurs délais après en avoir pris connaissance : Art. 33(2). Une clause de responsabilité partagée ne remplace pas ces obligations. Source : RGPD, Art. 28 et 33.

Relier le contrat à une tâche effectivement réalisable

Pour chaque ligne de la matrice, recherchez la pièce qui permet de comprendre l’engagement : conditions du service, annexe de sécurité, description de l’assistance ou instruction acceptée. Notez la version du document et l’offre concernée. Une présentation générale du groupe ne prouve pas que la même fonction existe dans l’abonnement acheté.

La répartition proposée peut distinguer quatre actions : décider du besoin, effectuer l’opération, fournir la preuve et examiner le résultat. Par exemple, le client peut fixer les droits nécessaires, un intégrateur les paramétrer et le fournisseur mettre à disposition un journal. Il reste à savoir qui vérifie que les droits correspondent au besoin approuvé. L’absence de cette dernière tâche peut laisser un contrôle annoncé sans suivi.

Une ambiguïté doit devenir une question précise au fournisseur. « Qui restaure la configuration des accès après une récupération ? » appelle une réponse plus exploitable que « êtes-vous conforme au RGPD ? ». Conservez les réponses avec leur périmètre, sans assimiler une explication commerciale à une modification déjà acceptée du contrat.

Examiner un service sans présumer de ses fonctionnalités

Dans un cas entièrement fictif, Orchidée envisage une application cloud pour partager les dossiers de ses interventions. Le contrat annonce une sauvegarde et l’interface présente une fonction d’export. L’équipe ignore encore si les droits de partage, les pièces jointes et l’historique utile sont couverts par ces deux mécanismes.

Le dossier de réception doit décrire ces inconnues. Demandez quels éléments seraient récupérés, dans quelle présentation et avec quelle assistance. Un export de données peut servir à poursuivre une activité sans permettre de reconstituer toute la configuration. Inversement, une restauration de la plateforme ne démontre pas que l’export répondra au besoin d’un changement de fournisseur.

Orchidée peut préparer un essai autorisé sur des données fictives : créer un dossier, attribuer des droits limités, produire l’export et examiner ce qu’il contient. Les critères seraient définis avant l’essai et le résultat resterait à constater. Cette proposition n’affirme aucune fonction disponible chez un fournisseur réel, ni aucune performance obtenue.

Préparer le dossier utile en cas d’accès inattendu

Si une ressource semble accessible à une personne non prévue, commencez par conserver les éléments disponibles : ressource, règle de partage, période observée et comptes concernés. Séparez la possibilité technique d’accès de la preuve qu’une consultation ou un téléchargement a eu lieu. L’absence d’un journal exploitable ne permet pas de conclure automatiquement à l’absence d’accès.

Demandez au fournisseur quelles informations il peut effectivement fournir et par quel canal. L’équipe métier doit, de son côté, identifier les données et les conséquences possibles pour les personnes. Cette répartition facilite l’analyse d’une éventuelle violation, sans faire dépendre toute décision d’un rapport technique final qui n’est pas encore disponible.

Le dossier doit aussi distinguer la correction immédiate du paramètre, la recherche des faits et la décision sur les communications. Fermer un lien peut réduire l’exposition future ; cela ne répond pas à toutes les questions sur la période antérieure. Les obligations respectives du responsable et du sous-traitant restent celles des Art. 32 à 34, selon leur rôle et les conditions du texte.

Garder la maîtrise lors d’une évolution de l’offre

Une nouvelle option, un changement d’intégrateur ou une migration peuvent modifier les tâches réellement exercées. Reprenez les lignes concernées de la matrice : accès administratifs, assistance, journaux, copies et sortie. Identifiez ce qui change dans le service ainsi que les décisions qui restent à prendre chez le client.

Conservez une conclusion limitée à ce qui a été examiné : offre, environnement, documents et opérations. Les réserves encore ouvertes doivent avoir un responsable et une suite prévue. Cette discipline aide à distinguer une garantie contractuelle, une fonction disponible et une protection dont le fonctionnement a effectivement été vérifié.

Ce qu’il faut retenir

• Décrivez les tâches et contrôles pour le service réellement utilisé.
• La répartition technique ne tranche pas seule les responsabilités RGPD.
• Vérifiez les clés, les accès et les flux, en plus du lieu de stockage.
• Préparez l’incident et la sortie avec des essais exploitables.

FAQ

En SaaS, le fournisseur gère-t-il toute la sécurité ?

Non. Les paramètres disponibles, les accès, les usages et les données demandent encore des décisions côté client. Le périmètre exact doit être établi pour l’offre retenue.

Une mauvaise configuration engage-t-elle uniquement le client ?

La responsabilité s’examine selon les faits, les obligations de chaque partie et les manquements éventuels. Le schéma de responsabilité partagée ne permet pas d’exonérer automatiquement le fournisseur.

Un hébergement SecNumCloud rend-il mon application conforme ?

La qualification du service cloud ne préjuge pas de la sécurité de l’application du client. Sa configuration, son code, ses accès et ses traitements restent à examiner.

Recevez nos analyses conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne, docteur en droit, travaille depuis plus de 20 ans sur la protection des données et le droit des technologies.