Table des matières
Déroulé de la séance plénière ......................................................................................... 2
1.
Introduction ............................................................................................................ 3
2. Sécurité des données dans le contexte de l’informatique en nuage ....................... 4
A.
Chiffrement des données dans le
cloud « public » ........................................... 4
B.
Outils pour la sécurité d’applications web dans le
cloud ................................. 7
3. Règles applicables au regard des transferts de données hors Union européenne 10
A.
Application de l’article 48 du RGPD à des fournisseurs soumis à des lois extra-
européennes autorisant les demandes d’accès par des autorités publiques de pays
tiers 10
B.
Les garanties appropriées dans le secteur du
cloud ........................................ 13
C.
Les dérogations ................................................................................................ 13
D.
Les possibilités liées à l’article 9.4 du RGPD ................................................... 13
4. Règles applicables pour certains acteurs ayant recours au
cloud ......................... 14
A.
Rappels concernant la qualification SecNumCloud ........................................ 14
B.
Règles applicables à l’État et aux organismes sous sa tutelle en vertu de la
circulaire « cloud au centre » .................................................................................... 15
C.
Enjeux liés au futur schéma de certification EUCS ......................................... 17
5. Éléments de réflexion sur la qualification des prestataires de
cloud et leurs clients
19
Liste des annexes .......................................................................................................... 22
1
Déroulé de la séance plénière
2
3
• Audition de la DINUM :
4
o Présentation de la feuille de route de la DINUM1 ;
5
o Mise en place des interconnexions permises par la loi 3DS pour améliorer le
6
« Dites-le-nous une fois » et permettre l’approche « aller vers »2 ;
7
o Stratégie de l’État sur l’informatique en nuage.
8
• Présentation de deux fiches relatives à la sécurité des données dans le contexte de
9
l’informatique en nuage.
10
• Discussions sur la qualification des fournisseurs de service de cloud et de leurs clients.
11
• Examen d’un projet de communication sur les règles applicables au regard des
12
transferts de données hors Union européenne.
13
14
15
16
1 https://www.numerique.gouv.fr/uploads/Feuille-de-route-DINUM.pdf
2 loi du 21 février 2022 relative à la différenciation, la décentralisation, la déconcentration et portant diverses
mesures de simplification de l’action publique locale (loi 3DS), article 162
2
17
1. Introduction
18
19
L’informatique en nuage («
cloud computing » ou «
cloud » dans la suite du document) est
20
une évolution importante de l’organisation des systèmes d’information des acteurs publics
21
ou privés, par laquelle ces systèmes tendent à reposer pour tout ou partie sur des fournisseurs
22
externes de services spécialisés de stockage, de calcul et de réseau (IaaS3), d’environnements
23
de programmation et de déploiement d’applications (PaaS4) ou d’applications spécifiques
24
(SaaS5). Ces services offrent aux entités qui y recourent l’accès à une flexibilité accrue et leurs
25
permettent de lisser leurs coûts. Toutefois, ce modèle tend à fragmenter le SI donc à rendre
26
sa maîtrise, ainsi que celles des données, plus complexe.
27
28
Le marché du
cloud connait une forte croissance (+14 % par an) et devrait atteindre 27
29
milliards d’euros en France en 20256. Au moins 29 % des entreprises françaises y recouraient
30
de manière significative en 20217 (41 % en moyenne dans l’UE), notamment pour des services
31
basiques (messagerie, stockage de fichiers, bureautique). Le marché européen est largement
32
dominé par des grands acteurs étatsuniens que sont Amazon (AWS), Microsoft (Azure) et
33
Google, qui représentent à eux trois plus de 75 % des parts de marché. Cette domination s’est
34
par ailleurs accentuée ces dernières années, emportant des risques accrus en matière de
35
concurrence et de souveraineté.
36
37
Le recours croissant à l’informatique en nuage amplifie donc les préoccupations quant à la
38
protection des données à caractère personnel, en particulier au regard des transferts
39
susceptibles d’être effectués hors de l’Union européenne et de la soumission de nombreux
40
fournisseurs à des lois extraterritoriales ouvrant l’accès aux données par des autorités de pays
41
tiers (tel le Cloud Act étasunien). La prise de conscience de ces risques par les acteurs est
42
progressive. À titre d’illustration, un livre blanc de KPMG publié en 2021 montrait que, parmi
43
un panel de 76 DSI français et allemands interrogés sur la question de la souveraineté des
44
données, 95 % d’entre eux considéraient qu’elle était caractérisée par la conformité au RGPD,
45
57 % par la localisation des centres de données dans le territoire de l’Union et 7 % seulement
46
par « l’immunité » aux accès par des autorités de pays tiers.
47
48
La présente communication a pour objet de résumer les propositions soumises au Collège sur
49
plusieurs questions qui, dans le contexte de l’informatique en nuage, revêtent un enjeu
50
particulier :
la sécurité des données, la qualification des fournisseurs et clients de
51
service de cloud et la question des transferts, notamment dans le contexte de
52
l’adoption de la décision d’adéquation concernant les États-Unis. L’objectif est de
53
publier un dossier actualisé sur l’informatique en nuage comprenant des contenus relatifs à
54
ces questions, à l’attention de tous les acteurs, privés comme publics.
3 Pour «
Infrastructure as a service ».
4 Pour «
Platform as a service ».
5 Pour «
Software as a service ».
6 Avis 23-A-08 du 29 juin 2023 portant sur le fonctionnement concurrentiel de l'informatique en nuage (« cloud »).
Disponible ici :
https://www.autoritedelaconcurrence.fr/fr/avis/portant-sur-le-fonctionnement-concurrentiel-de-
linformatique-en-nuage-cloud (page 3).
7Cloud computing - statistics on the use by enterprises. Eurostat. Disponible ici : https://ec.europa.eu/eurostat/statistics-
explained/index.php?title=Cloud computing -
statistics on the use by enterprises#Use of cloud computing: highlights.
3
55
2. Sécurité des données dans le contexte de l’informatique en nuage
56
57
Livrables publics :
58
- Fiche sur les pratiques de chiffrement dans le cloud « public »
59
- Fiche sur les outils pour la sécurité d’applications web dans le cloud
60
61
La sécurité des données dans le
cloud est un enjeu majeur, dans le contexte de migration
62
croissante des traitements de données vers cet environnement. Le fait pour des entités de
63
délocaliser des données et des systèmes informatiques auprès de tiers entraîne une perte du
64
contrôle et donc le besoin d’accorder un certain niveau de confiance dans le fournisseur, d’une
65
part pour qu’il traite les données comme espéré et, d’autre part, pour qu’il mette en œuvre les
66
mesures de sécurité adéquates.
67
68
Toutefois, dans le
cloud, la collaboration entre les fournisseurs de services
cloud et leurs
69
clients est essentielle pour maintenir un niveau élevé de sécurité des données. Dans la
70
pratique actuelle et sans préjuger de la juste qualification de ces acteurs au sens du RGPD
71
(abordée en partie 3 de ce document), les fournisseurs et les clients se partagent la
72
responsabilité de sécurité («
shared responsibility model ») :
73
74
• les fournisseurs sont chargés de la sécurité physique des serveurs, de la protection de
75
l'infrastructure réseau et de la fourniture et de la mise en place de mécanismes de
76
sécurité de base (sécurité « du »
cloud) ;
77
• les clients ont la responsabilité de protéger les données qu’ils stockent et traitent dans
78
les infrastructures de
cloud, en utilisant et en configurant les outils mis à disposition
79
par le fournisseur (sécurité « dans » le
cloud).
80
81
En particulier, cette situation engendre des préoccupations en ce qui concerne la préservation
82
de la confidentialité des données traitées dans le
cloud. Le chiffrement des données apparaît
83
à ce titre comme une mesure de protection efficace des données non seulement vis-à-vis de
84
tiers malveillants, mais aussi des fournisseurs de services
cloud eux-mêmes. Cependant, sa
85
mise en œuvre peut s’avérer complexe : les fournisseurs offrent un grand nombre de services
86
cryptographiques et les comprendre peut s’avérer fastidieux, alors qu’il est essentiel que les
87
clients choisissent la bonne approche et la bonne configuration du chiffrement. La section A
88
se penche sur les diverses approches et les critères de choix à prendre en compte en matière
89
de chiffrement des données dans le
cloud.
90
91
En outre, les clients sont pratiquement contraints d’avoir recours à des outils de sécurité (et
92
de performance) dans le
cloud tels que les pare-feu applicatifs web («
web application
93
firewall », ou WAF), les protections contre les attaques par déni de service distribuées (« Anti
94
DDoS »), les réseaux de distribution de contenu («
content delivery network », ou CDN) et
95
les répartiteurs de charge («
load balancer »). Cependant, ces outils ne sont pas exempts de
96
problématiques au regard du RGPD. La section B examine les défis liés à la configuration et
97
à la gestion de ces outils pour prévenir les accès non autorisés et les transferts de données
98
hors de l'Union européenne.
99
100
A. Chiffrement des données dans le cloud « public »
101
La protection des données dans le
cloud par le biais du chiffrement est une mesure essentielle
102
pour protéger la confidentialité des données. L’Annexe 1 de la présente communication
4
103
explore les problématiques liées au chiffrement et à la gestion des clés pour chacune des
104
différentes étapes du cycle de vie des données traitées dans un environnement
cloud.
105
106
Les données existent sous trois états distincts : au repos, en transit et en traitement. Chacun
107
de ces états présente des défis spécifiques en matière de chiffrement.
108
109
Or, le recours au
cloud, notamment quand les services sont déployés et rendus accessibles
110
aux utilisateurs via l'Internet (le cloud « public »), pose un défi particulier en termes de
111
chiffrement et de gestion des clés. En effet, les ressources physiques et logiques du
cloud
112
échappent au contrôle direct du client, soulevant des préoccupations concernant la titularité
113
des droits, la possession, le contrôle et l'accès aux clés cryptographiques. De plus, l'absence
114
de normes standardisées complique la gestion des clés dans le
cloud.
115
116
S’agissant du chiffrement des données au repos
117
118
Le chiffrement des données
au repos peut être opéré selon différentes approches :
119
120
- le
chiffrement côté serveur (c.-à-d. par le fournisseur quand il reçoit les données) :
121
o avec les clés générées et gérées par le fournisseur (approche 1) ; ou
o avec les clés générées par le fournisseur mais gérées par le client dans le KMS8
122
123
mis à disposition par le fournisseur (approche 2) ; ou
124
o avec les clés générées par le client, stockées et gérées par le client dans le KMS
125
du fournisseur (approche 3) ; ou bien
126
o avec les clés générées et gérées par le client en local ou dans un KMS tiers de
127
confiance (approche 4) ;
128
- le
chiffrement côté client (c.-à-d. par le client avant toute transmission des
129
données vers le
cloud) avec les clés générées et gérées par le client sur site ou dans un
130
KMS offert par un tiers de confiance (approche 5).
131
132
Chacune de ces approches offre un niveau de protection distinct pour protéger les données
133
au repos. L’Annexe 1 permet d’évaluer les choix que les clients ayant recours au
cloud doivent
134
opérer pour les cas où une protection contre le fournisseur et contre une communication des
135
données à des tiers sont nécessaires, notamment si le fournisseur est soumis à des lois
136
extraterritoriales.
137
138
En effet, le chiffrement est reconnu par le Comité européen pour la protection des données
139
(CEPD) comme étant une mesure supplémentaire pour encadrer les transferts de données
140
hors de l’Union européenne, sous certaines conditions notamment relatives à l’approche mise
141
en œuvre pour le chiffrement (chiffrement côté client).
142
143
Le chiffrement peut être nécessaire, en fonction des risques, même lorsque le fournisseur est
144
soumis exclusivement à la législation européenne (par exemple, pour limiter les accès
145
administrateurs non autorisés ou si le fournisseur prévoit de traiter certaines données du
146
client pour ses propres finalités).
147
148
S’agissant du chiffrement des données en transit
149
8 Pour « Key Management System » : système de gestion de clés
5
150
Le chiffrement des données en transit (que ce soit entre le client et le fournisseur ou entre
151
deux machines dans le
cloud) est considéré comme indispensable pour sécuriser les
152
informations pendant leur déplacement entre les clients et les serveurs.
153
154
La notion de chiffrement « de bout en bout » correspond au modèle de communication
155
sécurisée dans lequel seuls l’expéditeur et le destinataire des données ont accès aux données
156
en clair, sans les exposer au fournisseur du service
cloud. Ce modèle offre un plus haut niveau
157
de confidentialité que la combinaison du chiffrement des données au repos et en transit, mais
158
limite les opérations réalisables au sein du
cloud.
159
160
S’agissant du chiffrement des données en traitement
161
162
La protection des données en traitement par du chiffrement est un défi complexe. En effet,
163
les méthodes traditionnelles de chiffrement rendent, par définition, inintelligibles les
164
données chiffrées alors qu’elles doivent être en clair (c.-à-d. déchiffrées) pour être traitées.
165
Des techniques telles que le chiffrement homomorphe permet d’effectuer certaines
166
opérations sur les données chiffrées, et les enclaves sécurisées offrent des espaces réputés
167
sûrs au sein desquels les données peuvent être déchiffrées, traitées et re-chiffrées, préservant
168
ainsi leur confidentialité en cours d’utilisation. Malheureusement, ces techniques n’ont pas
169
atteint un niveau de maturité et d’efficacité suffisant, soit pour permettre d’effectuer des
170
traitements complexes (pour le chiffrement homomorphe) dans le
cloud, soit pour constituer
171
des garanties équivalentes au maintien du chiffrement (pour les enclaves sécurisées). En
172
particulier, les mécanismes à base d’enclaves sécurisées reposant sur des processeurs du type
173
Intel SGX ne sont pas exempts de vulnérabilités, comme celle mise à jour en août 2023
174
(baptisée « Downfall »9).
175
Proposition de conclusion :
S’agissant du chiffrement des données au repos :
- Le choix parmi les cinq approches du chiffrement et de la gestion des clés doit se faire
au cas par cas, en fonction des risques dont le client souhaite se prémunir ;
- Dans tous les cas, il est recommandé aux clients de :
o procéder à une analyse des risques liés au recours à un service de
cloud en
matière de protection des données ;
o déterminer les options et configurations de chiffrement des données au repos
mises en place par le fournisseur de
cloud (en dialoguant avec le fournisseur,
en examinant sa documentation, etc.) ;
o déterminer si ces options assurent un niveau de protection des données qu’ils
estiment adéquat, sur la base de l’analyse des risques (il est donc possible, sur la
base de cette évaluation, de devoir renoncer à un service cloud particulier, ou de
renoncer de migrer un traitement dans le
cloud).
9 Le Monde, « Une faille de sécurité importante découverte sur des processeurs Intel », 9 août 2023
https://www.lemonde.fr/pixels/article/2023/08/09/une-faille-de-securite-importante-decouverte-sur-des-processeurs-
intel 6184900 4408996.html
6
- Si l’objectif du chiffrement est d’éviter tout risque d’accès aux données en clair par le
fournisseur de
cloud, il sera recommandé de mettre en œuvre l’approche 5, à savoir un
chiffrement côté client, dans lequel les clés seraient conservées par le client ou par un
tiers de confiance.
S’agissant du chiffrement des données en transit :
- Les données transmises entre les ressources dans le
cloud et lors des interactions avec
les clients doivent être protégées par un chiffrement afin de préserver leur
confidentialité en cas d’interception ou d’écoute par des tiers malveillants.
S’agissant du chiffrement des données en cours d’utilisation :
- Il convient de rappeler que si les données ne sont pas chiffrées lors du traitement par
le service
cloud (ce qui est typiquement le cas pour des services SaaS), alors la
combinaison du chiffrement au repos avec le chiffrement en transit mis en œuvre par
le fournisseur ne constitue pas une mesure technique assurant une confidentialité
absolue des données, puisque le fournisseur a accès aux données en clair lorsque le
service effectue les traitements.
- La CNIL devrait encourager les clients à mettre en œuvre des techniques comme le
chiffrement homomorphe ou l’informatique confidentielle à base d’enclaves sécurisées.
Toutefois, celles-ci n’ont pas atteint un niveau de maturité et d’efficacité suffisant pour
permettre d’effectuer des traitements complexes sur les données (chiffrées) dans le
cloud. La CNIL continue à assurer une veille sur ces technologies.
176
177
B. Outils pour la sécurité d’applications web dans le cloud
178
Certains fournisseurs proposent une gamme d'outils et de services conçus pour garantir que
179
les données sont protégées contre les menaces en ligne et que les performances des services
180
en ligne sont optimales. Il s’agit notamment des outils tels que les WAF, les CDN, les
181
équilibreurs de charge et les outils anti-DDoS. Ces outils traitent inévitablement des données
182
à caractère personnel, notamment des adresses IP.
183
184
L’Annexe 2 de la présente communication explore les problématiques liées à la conformité au
185
RGPD pour ces solutions, en se concentrant sur les aspects de transferts de données, d'accès
186
extraterritorial et de déchiffrement des flux chiffrés par le protocole de sécurité Transport
187
Layer Security (TLS).
Cette analyse ne permet pas à ce stade de prendre position
188
sur l’applicabilité du RGPD pour chacune des catégories de solutions
189
concernées, question qui méritera cependant d’être instruite ultérieurement, dans une
190
perspective plus large que celle de l’informatique en nuage.
191
192
S’agissant des transferts et des accès extraterritoriaux
193
194
Les outils de sécurité et de performance doivent être pris en compte dans l'analyse des risques
195
potentiels liés aux transferts vers des pays tiers. Les traitements de données qui passent par
196
des CDN, WAF ou outils anti-DDoS offerts par des fournisseurs non-européens peuvent
197
entraîner des transferts de données hors de l'UE. Les données traitées par ces outils peuvent
198
être acheminées à travers des pays sans garanties de protection suffisantes, même si le
199
fournisseur de services
cloud et l'utilisateur sont basés dans l’Union. Les outils de sécurité ne
7
200
sont pas nécessairement soumis aux mêmes règles de localisation que les services de
cloud
201
consommés.
202
203
L’Annexe 2 recommande aux clients ayant recours à ces services de vérifier auprès du
204
fournisseur si les outils de sécurité intégrés peuvent effectuer des transferts. Il est également
205
recommandé d'utiliser des solutions de sécurité fournies par des entreprises européennes,
206
afin de limiter tout accès non autorisé aux données par des entités non-européennes.
207
208
Cas particulier de l’utilisation de CDN
209
210
Certains transferts de données sont inhérents au fonctionnement d'Internet, notamment
211
lorsque des données à caractère personnel accessibles sur Internet sont stockées dans l'UE
212
mais consultées par des internautes hors de l'UE. Les CDN, réseaux spécialisés à haut débit
213
adossés à Internet, peuvent entraîner des transferts hors de l'UE car ils stockent et
214
fournissent des copies de contenus demandés au plus près des utilisateurs.
215
216
L'ampleur de ces transferts dépend de facteurs tels que les types de contenus mis en cache
217
(c’est-à-dire stockées temporairement pour faciliter leur réutilisation ultérieure) sur les
218
serveurs du CDN (données à caractère personnel ou non) et l'emplacement des serveurs
219
utilisés (distribués géographiquement dans plusieurs parties du monde).
220
221
Les clients ayant recours à des services de CDN et leurs fournisseurs de ces services doivent
222
configurer le CDN de manière appropriée pour éviter les transferts de données non
223
conformes :
224
225
- une sélection prudente des données à placer en cache, notamment en évitant que des
226
données à caractère personnel ne soient mises en cache sur les serveurs du CDN ;
227
- une configuration du CDN pour ne pas réaliser plus de transferts que le
228
fonctionnement inhérent d’Internet standard, en privilégiant par exemple les lieux de
229
mises en cache dans des pays considérés comme adéquats.
230
231
S’agissant du déchiffrement des flux chiffrés par le protocole TLS
232
233
Le protocole TLS est largement utilisé pour fournir des communications sécurisées, en
234
particulier chiffrées, entre les clients et les serveurs accessibles sur Internet. Pour autant, le
235
chiffrement TLS, s’il a pour objectif de garantir la confidentialité des échanges, rend aussi
236
aveugles les outils de sécurité qui agissent comme un intermédiaire entre les clients et les
237
serveurs.
238
239
Certains scénarios exigent donc le déchiffrement des flux TLS afin de permettre aux outils de
240
sécurité d'inspecter les flux et de détecter les menaces potentielles. Cependant, cette nécessité
241
de déchiffrement soulève des questions en matière de conformité au RGPD.
242
243
En effet, lorsque les flux TLS sont déchiffrés, les données initialement sécurisées deviennent
244
temporairement exposées, entraînant un risque de divulgation non autorisée de données à
245
caractère personnel.
246
247
L’Annexe 2 préconise une analyse des risques et des avantages avant de recourir à un
248
déchiffrement TLS en déterminant si ce déchiffrement est vraiment nécessaire pour atteindre
249
l’objectif de sécurité recherché. Des alternatives au déchiffrement, tels que les outils anti-
250
DDoS reposant sur la limitation du nombre de requêtes, doivent être envisagées pour
8
251
maintenir un équilibre entre la sécurité du système d'information et la protection des
252
données.
253
254
Lorsque le déchiffrement est inévitable, des mesures de sécurité doivent être mises en place
255
au niveau des points de déchiffrement des flux TLS. Des contrôles d'accès stricts, une
256
authentification robuste, la configuration de bastions pour le déchiffrement, la
257
pseudonymisation des données en transit, etc., sont des mesures recommandées pour
258
atténuer les risques. D’autres mesures, telles que la minimisation des données faisant l’objet
259
d’un déchiffrement, la limitation de leur durée de conservation et l’information des personnes
260
concernées, sont également à envisager.
261
262
Dans les cas où le déchiffrement des flux TLS est déconseillé en raison des risques pour la
263
confidentialité, la CNIL a lancé des travaux sur la conformité des solutions de cybersécurité
264
avancées dont les résultats pourront dégager des recommandations pour les clients.
265
9
266
3. Règles applicables au regard des transferts de données hors Union
267
européenne
268
269
Le recours à des services de
cloud conduit généralement à des transferts de données hors de
270
l’Union européenne. Le chapitre V du RGPD (articles 44 à 49) fixe les règles applicables en
271
cas de transfert, afin que le niveau de protection des personnes physiques garanti par le RGPD
272
ne soit pas compromis lorsque des données à caractère personnel sont transférées vers un
273
pays tiers ou une organisation internationale. Les responsables de traitement et les sous-
274
traitants peuvent transférer des données hors de l’Union européenne et de l’espace
275
économique européen, à condition d’assurer un niveau de protection des données suffisant
276
et approprié.
277
278
À titre d’exemple s’agissant du secteur du
cloud, la transmission de données par un organisme
279
responsable de traitement soumis au RGPD vers un sous-traitant fournisseur de services de
280
cloud à des fins d’hébergement sur des serveurs dans un pays tiers constitue un transfert de
281
données hors de l’Union européenne. Si l’hébergement est réalisé sur des serveurs situés dans
282
l’Union, il peut tout de même y avoir des transferts sur vers des serveurs hors de l’Union
283
européenne gérés par des entités situées dans des pays tiers à des fins de réplication ou de
284
sauvegarde, ou vers des équipes localisées dans des pays tiers à des fins de support ou de
285
maintenance.
286
287
En revanche, le recours par un responsable de traitement soumis au RGPD à un fournisseur
288
de services de cloud soumis à une législation d’un pays tiers qui héberge les données sur le
289
territoire de l’Union européenne ne constitue pas en tant que tel un transfert et le chapitre V
290
du RGPD n’est pas applicable. Toutefois, si le fournisseur communique des données en
291
réponse à une demande d’accès des autorités du pays tiers en vertu de la législation à laquelle
292
il est soumis, une telle divulgation constitue un transfert en vertu du chapitre V du RGPD.
293
294
L’Annexe 3 rappelle ce qu’est un transfert de données hors de l’Union européenne, les
295
principes généraux applicables et les différents outils permettant d’encadrer ces transferts.
296
297
Un point d’attention particulier concerne la nouvelle décision d’adéquation de la Commission
298
européenne adoptée le 10 juillet 2023 constatant que, dans le cadre du nouvel accord
299
transatlantique (« EU-US Data Privacy Framework »), les États-Unis assurent un niveau de
300
protection substantiellement équivalent à celui de l’Union européenne, permettant ainsi,
301
sous certaines conditions, le transfert de données à caractère personnel vers ce pays, sans
302
exigences supplémentaires.
303
304
Les règles générales en matière de transfert s’appliquent au secteur du
cloud comme à tout
305
autre secteur. Toutefois, les points suivants sont proposés pour discussion par votre
306
rapporteur.
307
A. Application de l’article 48 du RGPD à des fournisseurs soumis à des lois
308
extra-européennes autorisant les demandes d’accès par des autorités
309
publiques de pays tiers
310
311
Même en l’absence de transfert de données à caractère personnel hors UE, une société
312
soumise à la législation d’un pays tiers peut faire l’objet d’injonctions des autorités publiques
313
de ce pays l’obligeant à leur transférer des données stockées et traitées sur le territoire de
10
314
l’Union européenne. Cette situation vise donc le recours à un fournisseur de service de
cloud
315
hébergeant les données à caractère personnel sur le territoire de l’Union européenne.
316
317
Cette situation a été spécifiquement couverte par l'article 48 du RGPD qui prévoit que :
318
«
Toute décision d'une juridiction ou d'une autorité administrative d'un pays tiers exigeant
319
d'un responsable du traitement ou d'un sous-traitant qu'il transfère ou divulgue des
320
données à caractère personnel ne peut être reconnue ou rendue exécutoire de quelque
321
manière que ce soit qu'à la condition qu'elle soit fondée sur un accord international, tel qu'un
322
traité d'entraide judiciaire, en vigueur entre le pays tiers demandeur et l'Union ou un État
323
membre, sans préjudice d'autres motifs de transfert en vertu du présent chapitre ». Une
324
demande d'un juge ou d'une autorité administrative d’un pays tiers ne peut donc être
325
exécutoire que s'il existe un cadre juridique spécifique en place convenu entre les deux pays
326
(comme un traité d’entraide judiciaire).
327
328
De telle demandes de transmission d’information peuvent ainsi être fondées sur :
329
- des traités d’entraide judiciaire, une juridiction étrangère demandant communication
330
d’information ou de document et pouvant être revêtue d’un exequatur en Europe ;
331
- des traités de coopération pénale. On peut également mentionner à ce titre le
332
deuxième protocole additionnel à la convention du Conseil de l’Europe sur la
333
cybercriminalité (Convention de Budapest10), bien que celui-ci ne soit pas encore
334
applicable car en cours de ratification ;
335
- des traités de coopération fiscale qui prévoient la communication de renseignements
336
d’une administration fiscale à une autre : si la décision est « reconnue » par
337
l’administration européenne, dans le cadre du traité, celle-ci doit communiquer les
338
données demandées.
339
340
De tels traités doivent cependant être eux-mêmes conformes aux exigences du RGPD et de la
341
jurisprudence de la CJUE.
342
343
En revanche, en dehors d’actions de coopération entre États (telles que citées ci-dessus), il
344
n’existe évidemment pas de traités prévoyant que des services de renseignement d’États
345
étrangers puissent demander aux sociétés relevant de leurs lois nationales ayant des
346
établissements en Europe de leur communiquer des données à caractère personnel
347
d’Européens (d’ailleurs généralement sans en informer les autorités européennes). Il n’en
348
existera sans doute probablement jamais.
349
350
Ce risque de divulgation non autorisée par le droit de l’Union a d’ailleurs été confirmé par le
351
Conseil d’État dans son ordonnance du 13 octobre 2020 concernant le dossier HDH précisant
352
qu’« […]
il résulte de l'instruction que les mesures techniques mises en œuvre par Microsoft
353
ou susceptibles de l'être à brève échéance n'écartent pas toute possibilité pour cette
354
entreprise d'accéder aux données traitées sous la responsabilité de la Plateforme des
355
données de santé, en dépit des précautions, limitant ce risque, qui entourent le chiffrement
356
dont elles font l'objet et le stockage des clés de chiffrement utilisées. Il ne peut ainsi être
357
totalement exclu, sur le plan technique, que Microsoft soit amenée à faire droit à une
10 Ce protocole a pour objectif d’améliorer l'accès transfrontière aux preuves électroniques à utiliser dans le cadre des
procédures pénales. Il contribuera à la lutte contre la cybercriminalité et d'autres formes de criminalité au niveau mondial
en facilitant la coopération entre les États membres et les pays tiers, tout en assurant un niveau élevé de protection des
personnes et en veillant au respect des normes de l'UE en matière de protection des données. Le protocole prévoit des
procédures visant à améliorer la coopération internationale entre autorités ainsi qu'à renforcer la coopération directe avec
les fournisseurs de services et les entités situés dans d'autres pays. Il définit également des procédures relatives à la demande
d'entraide judiciaire urgente.
11
441
4. Règles applicables pour certains acteurs ayant recours au cloud
442
A. Rappels concernant la qualification SecNumCloud
443
La qualification SecNumCloud délivrée par l’Agence nationale de la sécurité des systèmes
444
d'information (ANSSI) atteste de la qualité et de la robustesse de la prestation, de la
445
compétence du prestataire ainsi que de la confiance pouvant lui être accordée.
446
447
La version 3.2 du 8 mars 2022 du référentiel SecNumCloud explicite des
critères de
448
protection vis-à-vis de la législation extra-européenne :
449
• le « siège statutaire, administration centrale et principal établissement » du
450
prestataire dans l’UE ;
451
• des exigences sur le capital social du prestataire (le capital minimum que devraient
452
détenir des acteurs européens est de 61 %) ;
453
• l’absence de possibilité technique par toute société hors UE intervenant dans le
454
traitement d’accéder aux données traitées (y compris les données techniques).
455
456
La CNIL considère que SecNumCloud fournit
une réponse conforme par conception
457
aux exigences de la CJUE en matière de protection des données identifiés dans
458
son arrêt « Schrems 2 » et elle recommande SecNumCloud aux responsables de
459
traitement qui veulent garantir un haut niveau de protection des données à caractère
460
personnel12.
461
462
Par ailleurs, le Gouvernement a lancé fin 2022 un dispositif d’accompagnement à la
463
qualification SecNumCloud pour les petites et moyennes entreprises et les start-ups de la
464
sphère SaaS/PaaS13, piloté par la DGE et la DGRI et opéré par Bpifrance.
465
466
À ce jour, cinq fournisseurs sont qualifiés SecNumCloud :
467
• Cloud Temple : offre « Secure Temple » (IaaS) ;
468
• Oodrive : suite collaborative « Meet », « Work », et « Share » (SaaS) ;
469
• Outscale : offre « IaaS Cloud on Demand » (IaaS) ;
470
• OVH : offre « Private Cloud » (IaaS) ;
471
• Worldline : offre « Secured IaaS » (IaaS).
472
473
Selon le Gouvernement, la stratégie nationale pour le
cloud a permis aux administrations de
474
doubler leur volume de marchés passés avec des offres SecNumCloud14.
475
476
Six autres fournisseurs sont en cours de qualification :
477
• Cloud Solutions : suite collaborative « Wimi Entreprise » (SaaS) ;
478
• Idnomic : Infrastructure de clés publiques et d’identité numérique (SaaS) ;
479
• Index Education : Suite logicielle incluant Pronote (SaaS) ;
480
• Cegedim : offre « CegNumCloud « (IaaS)
481
• Whaller : suite collaborative « Donjon » (SaaS)
482
• Orange : Cloud Avenue (IaaS)
12 « L’ANSSI actualise le référentiel SecNumCloud » : https://www.ssi.gouv.fr/actualite/lanssi-actualise-le-referentiel-
secnumcloud/
13 « France 2030 : vers un renforcement de l’offre
cloud de confiance »
https://presse.economie.gouv.fr/06042023-cp-france-2030-vers-un-renforcement-de-loffre-cloud-de-confiance/
14 « Un premier bilan positif » : https://www.economie.gouv.fr/cloud-cinq-nouveaux-dispositifs-soutenir-developpement-
secteur
14
483
B. Règles applicables à l’État et aux organismes sous sa tutelle en
484
vertu de la circulaire « cloud au centre »
485
La stratégie nationale pour le
cloud, lancée le 17 mai 2021 par le Gouvernement, vise à relever
486
les enjeux de souveraineté et de protection des données. Cette stratégie repose sur trois axes :
487
488
1. le «
cloud de confiance », au travers de la qualification SecNumCloud de l’ANSSI ;
489
490
2. la doctrine «
cloud au centre », énoncée dans la circulaire 15 n° 6282/SG du
491
5 juillet 2021 et actualisée par la circulaire 16 n° 6404/SG du 31 mai 2023, qui
492
positionne le
cloud comme levier de la transformation numérique de l'État ;
493
494
3. la stratégie d’accélération
cloud impliquant un soutien à l’innovation, à l'industrie et
495
aux administrations pour accélérer l'adoption du
cloud.
496
497
En vertu de la doctrine «
cloud au centre », l’informatique en nuage est désormais le mode
498
d'hébergement et de production par défaut pour tout projet numérique de l'État. Elle
499
concerne l’usage du
cloud par les ministères et les organismes placés sous sa tutelle, « comme
500
retenus dans le décret 2019-1088 définissant le système d'information de l'État ».
501
502
La circulaire établit quinze règles auxquelles les administrations doivent se conformer,
503
notamment :
504
• elles doivent opter, en fonction de critères spécifiques qui leur sont propres, entre :
505
o le recours à l’un des deux
clouds internes interministériels de l'État, à savoir
506
l’offre Nubo opérée par Direction générale des finances publiques (DGFiP) ou
507
l’offre Pi opérée par le ministère de l’Intérieur17 ;
508
o le recours à une solution de
cloud commercial ;
509
• dans le cas du recours à une offre de
cloud commercial pour héberger un traitement
510
de données d’une sensibilité particulière, l’offre retenue devra être un
cloud de
511
confiance18 (règle R9).
512
L’actualisation de la circulaire en mai 2023 cible essentiellement le texte de cette règle R9 :
513
• une première exigence vise à assurer qu’un traitement de données à caractère
514
personnel opéré via une offre de
cloud commercial est conforme au RGPD, en attirant
515
l’attention sur la question des transferts et de l’immunité aux demandes émanant
516
d’État tiers en dehors de tout accord international ;
517
518
• une deuxième exigence rappelle que pour les traitements des données de santé, l’offre
519
de
cloud doit être conforme à la législation sur l'hébergement de données de santé (à
520
savoir d’avoir la certification HDS).
521
15 Circulaire n° 6282-SG du 5 juillet 2021 https://www.legifrance.gouv.fr/circulaire/id/45205
16 Actualisation de la doctrine d'utilisation de l'informatique en nuage par l'État
https://www.legifrance.gouv.fr/circulaire/id/45446
17 Les deux offres de
cloud internes sont considérées par la DINUM comme présentant des garanties équivalentes à celles
offertes par la qualification SecNumCloud.
18 Le terme de «
cloud de confiance » regroupe les offres de
clouds interministériels et celles ayant obtenues la qualification
SecNumCloud.
15
522
• une troisième exigence prévoit que le traitement des données d’
une sensibilité
523
particulière (qu’elles soient à caractère personnel ou non) doit être opéré avec une
524
offre de
cloud qualifiée SecNumCloud. Elle explicite deux conditions cumulatives
525
permettant aux administrations de déterminer si leur projet numérique est concerné
526
par cette exigence.
527
528
La première étape de l'analyse consiste à évaluer la sensibilité des données hébergées
529
dans leur système d’information en se basant sur deux critères alternatifs :
530
1. la sensibilité des données « par nature », c'est-à-dire les données couvertes
531
par un secret légal, notamment au titre des articles L. 311-5 et L. 311-6 du
532
code des relations entre le public et l'administration ;
533
534
2. la sensibilité des données « par destination », qui englobe les données
535
nécessaires à l'accomplissement des missions essentielles de l'État, telles
536
que la préservation de la sécurité nationale, le maintien de l'ordre public et
537
la protection de la santé.
538
Si aucun de ces critères n'est satisfait, il n'est pas nécessaire de recourir à une offre
539
qualifiée SecNumCloud. En revanche, si l'un des deux critères est respecté, les
540
administrations doivent effectuer la deuxième étape de l'analyse.
541
Celle-ci consiste à évaluer l'impact d'une violation des données sur l'ordre public, la
542
sécurité publique, la santé, la vie des personnes et la propriété intellectuelle. Les
543
impacts pris en compte incluent, entre autres, les aspects opérationnels, politiques,
544
juridiques et économiques.
545
Si un tel risque n'est pas avéré, il n'est pas nécessaire de recourir à une offre qualifiée
546
SecNumCloud. Dans le cas contraire, le recours à une offre SecNumCloud s'impose.
547
548
• Enfin, la règle R9 prévoit une dérogation transitoire pour les projets déjà engagés d’au
549
maximum 12 mois, après validation de la Première ministre, à compter de la
550
disponibilité d’une offre « acceptable ».
551
16
obligations du RGPD en matière de transferts et d’accès par des autorités de pays tiers.
568
569
570
571
Dès lors, des exigences de localisation des données sur le territoire de l’UE et d’immunité ont
572
été incluses dans le référentiel, pour le niveau d’assurance « élevé ». Cependant, des
573
divergences au sein des États membres ont ralenti l’adoption du schéma de certification. La
574
France est favorable à l’inclusion des critères stricts d’immunité, comme dans le référentiel
SecNumCloud.
582
583
584
À retenir :
Le schéma de certification pourrait conduire à
un renforcement des pratiques en
matière de sécurité des fournisseurs et services de cloud, avec un cadre
d’évaluation harmonisé.
Toutefois,
le schéma EUCS ne vise pas à vérifier la conformité d'un service cloud
au RGPD. En particulier, il s’agira de déterminer par exemple si le niveau « basique » permet
d’atteindre un minimum suffisant pour la sécurité d’un traitement des données à caractère
personnel.
Dans la situation inverse, la CNIL ne pourra pas considérer qu’une certification EUCS permet
de respecter la décision de la CJUE et de se prémunir des accès illégitimes. Elle serait donc
démunie pour orienter les responsables de traitement vers une certification ou un référentiel
approprié.
585
18
617
fournisseurs, il n’est pas vraiment en capacité de choisir d’autoriser ou non les
618
traitements de données mis en œuvre pour des finalités annexes à la finalité principale
619
recherchée. Les prestataires de
cloud réutilisent majoritairement les données de leurs
620
clients à leurs propres fins ;
621
•
La grande difficulté de donner de réelles instructions aux grands prestataires
622
de service de
cloud et notamment aux leaders étatsuniens du marché ;
623
•
Un manque de transparence de la part des prestataires vis-à-vis de leurs
624
clients, notamment concernant les traitements de données de télémétrie ou de
625
qualité de service effectués par les prestataires, qui peuvent entraîner la collecte de
626
nombreuses données sur les utilisateurs finaux du service ;
627
•
Le recrutement pratiquement unilatéral d’autres sous-traitants par les
628
prestataires : malgré l’existence de clauses contractuelles portant sur la possibilité
629
d'autoriser le recrutement des sous-traitants ultérieurs et de s'y opposer, en pratique,
630
cela se matérialise davantage par une simple information sur les sous-traitants
631
ultérieurs (aussi bien au moment de la contractualisation qu'en cas de changement de
632
sous-traitant au cours de la relation contractuelle) que véritablement par une décision
633
de la part du client responsable de traitement. Les possibilités de s'opposer restent
634
également limitées (et impliquent dans certains cas une rupture du contrat) sauf à
635
changer de fournisseur principal, dans des délais souvent incompatibles avec une
636
conduite de projet informatique rigoureuse (de l’ordre de 30 à 90 jours de délai, quand
637
une migration de fournisseurs peut requérir jusqu’à deux ans de mise en place)28.
638
Le déséquilibre induit par ces pratiques contractuelles peut éventuellement
639
avoir des conséquences sur la qualification des acteurs au sens du RGPD pour
640
les traitements de données à caractère personnel couramment mis en œuvre
641
dans ce secteur.
642
Des recommandations de 2012 à une analyse par finalité
643
Les recommandations de la CNIL relatives au
cloud datant de 201229 faisaient déjà état de
644
situations de responsabilité conjointe des prestataires de
cloud et leurs clients – bien que la
645
responsabilité conjointe ne fût pas prévue par la loi « informatique et libertés » avant le
646
RGPD – lorsque ces derniers ne disposent pas de la capacité à négocier les contrats de
647
prestation de service et de s’assurer de la mise en place par les prestataires, de garanties en
648
matière de sécurité. À cela s’ajoute le fait que le prestataire réutilise généralement les données
649
de ses clients, notamment pour améliorer les services qu’il propose. Les clients ne disposent
650
pas forcément de la capacité à consentir spécifiquement à cette réutilisation de leurs données.
651
Les lignes directrices du CEPD proposent toutefois d’analyser la qualification des acteurs par
652
finalité de traitement mis en œuvre30.
Les finalités identifiées par votre rapporteur sont les
653
suivantes :
654
•
La fourniture du service : elle peut être définie comme la mise à disposition par le
655
prestataire du service demandé par le client. Les prestataires de
cloud se qualifient
28
29 Recommandations pour les entreprises qui envisagent de souscrire à des services de Cloud computing, disponibles ici :
https://www.cnil.fr/sites/cnil/files/typo/document/Recommandations pour les entreprises qui envisagent de sousc
rire a des services de Cloud.pdf
30
20
697
Liste des annexes
698
Annexe 1
Communication sur les pratiques de chiffrement dans le
cloud « public »
Annexe 2
Communication sur les outils pour la sécurité d’applications
web dans le cloud
Annexe 3
Communication sur les règles applicables au regard de la
question des transferts de données hors Union européenne
Annexe 4
Communication sur la stratégie nationale pour le cloud
699
22