SFIO CRACHO - stock.adobe.com
Digital Sovereignty Pledge : AWS brouille les pistes entre contrôle et souveraineté
En marge de sa conférence annuelle, AWS a annoncé Digital Sovereignty Pledge, un engagement international pour offrir « des outils et des fonctionnalités de contrôle au service de la souveraineté ». Une conception difficile compatible avec la notion de souveraineté numérique à la française.
Cet engagement tient en quatre points : le contrôle de l’emplacement de données, de l’accès aux données, la possibilité de chiffrer les données « partout » et sur la « résilience », c’est-à-dire la haute disponibilité des services cloud et la disponibilité de capacités spécifiques pour le stockage de données hors ligne.
Le communiqué en question a été publié en anglais, en français, en allemand, en italien, en japonais, en coréen, en espagnole et en indonésien. Hormis quelques rappels et des promesses vagues, AWS ne prend pas de nouvelles mesures en faveur de la souveraineté numérique.
Et pourtant, l’auteur du document originel, Matt Garman, Senior Vice-President et directeur des ventes, du marketing et des services d'AWS, va plus loin en écrivant– sans broncher – que le cloud AWS est « souverain dès la conception », un processus continu, selon lui.
« Nous avons développé des compétences en matière de chiffrement et de gestion des données, obtenu des certifications de conformité et pris des engagements contractuels pour répondre aux besoins de nos clients », écrit Matt Garman.
« Depuis la conception d’AWS, nous savons que nous devons protéger les données et la confidentialité des données de nos clients », avance Julien Groues, Directeur Général d’AWS France, lors d’un entretien avec la presse française à re:Invent 2022. « En revanche, nous pensions que c’était important de renforcer encore une fois notre volonté d’aller plus loin autour de la souveraineté ».
« In fine, la souveraineté numérique, c’est une question de contrôle »
Encore faut-il savoir ce qu’AWS entend par souveraineté numérique.
« Des définitions de la souveraineté, il y en a un peu de tous les côtés », remarque Julien Groues. « In fine, la souveraineté numérique, c’est une question de contrôle. […] Nous voulons permettre à nos clients, aux entreprises, aux développeurs, à nos partenaires d'avoir le contrôle de leur assets digitaux », ajoute-t-il.
« Cette souveraineté est au cœur de notre priorité et nous allons continuer de se développer et d'investir là-dessus pour que tous nos clients aient un contrôle complet de leurs assets digitaux, que personne ne puisse y avoir accès sans leur accord », vante Julien Groues.
Ce flou concernant la notion de souveraineté numérique résulte des débats en France, aux États-Unis, en Europe, en Chine ou en Russie. Selon Pauline Türk, Professeur de droit public à l’Université Côte d’Azur, au sens légal, il existe trois approches majeures de la souveraineté numérique.
L’une correspond à la souveraineté numérique des utilisateurs, une approche selon laquelle les usagers auraient la capacité à s’autodéterminer. « Le pouvoir envisagé ici peut être exercé collectivement, dans le cadre de communautés d’utilisateurs (transnationales), ou à titre individuel. Il se traduit aussi, concrètement, par des droits et garanties, en cours de consécration, tels le droit à la protection des données personnelles, à la portabilité des données, à l’oubli ou au déréférencement », avance l’auteur.
Une deuxième approche, mieux comprise en France, correspond à la souveraineté des Etats. Elle consiste « dans le droit pour l’État de protéger ses citoyens et leurs libertés contre les entités malveillantes ou mues par des intérêts purement commerciaux ». C’est La troisième approche serait « celle des opérateurs économiques (GAFAM) qui disposent de facto du pouvoir d’imposer des règles ».
« Quelques multinationales bénéficient d’une suprématie, grâce à leur domination sur les marchés, et exercent un véritable pouvoir de commandement et de réglementation dans le cyberespace », écrit Pauline Türk.
Ces fournisseurs cloud ont tendance à brouiller les pistes, en jouant sur les trois tableaux. Avant AWS, Microsoft avait annoncé son offre Cloud for Sovereignty. GCP a présenté trois solutions « souveraines » : Sovereign Controls, Supervised Control et Hosted Control. Finalement, la plus souveraine des trois – au sens français du terme – se nomme Supervised Control : elle correspond au lancement futur de S3NS avec Thales.
Chiffrement contre lois extraterritoriales
Tout comme Microsoft, la tentative de réponse d’AWS est avant tout technique, et non légale. En la matière, AWS a récemment ajouté des « data residency guardrails », des garde-fous pour assurer la localisation du stockage et des traitements des données dans une ou des régions spécifiques. Dans la documentation, ces garde-fous sont nommés « contrôles ». Ceux-ci sont accessibles depuis le service AWS Control Tower. Ils servent à refuser l’accès ou interdire des opérations dans certains services. Par exemple, il est possible de limiter les traitements dans les huit régions cloud situées en Europe. Pour l’instant, les données opérationnelles, c’est-à-dire les « informations relatives à l’identité et à la facturation des clients » ne sont pas soumis aux mêmes vérifications. Le géant du cloud prévoit de localiser le stockage de ces données dans les régions européennes plus tard, sans toutefois communiquer un calendrier prédéfini.
En outre, le géant du cloud aime à mettre en avant Nitro, l’hyperviseur de ses instances EC2. Selon AWS, c’est le centre de contrôle « logique et matériel » de la protection des données dans son cloud. Nitro doit principalement empêcher l’accès aux données stockées dans les instances EC2.
Via son module TPM, l’hyperviseur protège les clés de chiffrement des SSD. Il peut également utiliser des ressources KMS pour chiffrer des ressources VPS, EBS et donc EC2. « Les clés de chiffrement utilisées pour EBS, le stockage des instances locales et la mise en réseau des VPC ne sont jamais présentes en clair que dans la mémoire volatile protégée des cartes Nitro », précise AWS. Et « aucun opérateur AWS » n’a accès à ces clés pour la bonne raison que les API pour y accéder n’existeraient pas.
« Il n'y a pas [d’interface] de programmation pour faire sortir les clés ou les contrôles d'accès », assure Julien Groues.
Encore une fois, comme tout fournisseur cloud américain, AWS est soumis aux lois extraterritoriales de son pays (CLOUD Act, FISA Act, Patriot Act). Dans la fiche « caractéristiques de la confidentialité des services AWS », un grand nombre de services cloud n’auraient « pas d’accès à distance ». Or le petit astérisque en haut de la colonne renvoie à la phrase suivante : « sauf si vous demandez à y accéder, [l’accès] est requis pour prévenir la fraude et les abus ou pour se conformer à la loi ».
Pour AWS, le chiffrement des données est la véritable réponse à cette potentielle menace extraterritoriale. Comme il ne détiendrait pas les clés de chiffrements, lors de demande d’accès des autorités et tribunaux américains, « en dernier recours », il pourrait livrer les données chiffrées sans mode d’emploi ou moyens pour les déchiffrer.
Or ce chiffrement n’est pas activé par défaut. C’est au client de le mettre en place. Concernant Nitro, tous les services ne sont pas protégés par l’hyperviseur. « Nous allons poursuivre les développements de nos services, notamment autour de Nitro, pour que l’hyperviseur soit disponible nativement depuis différents services », affirme le directeur général d’AWS France.
AWS a aussi développé des VM confidentielles, des « enclaves » Nitro. Jusqu’alors, il n’était possible de créer uniquement des enclaves sur EC2. Lors de re:Invent 2022, AWS annoncé la possibilité de déployer des enclaves Nitro sur EC2 depuis EKS et Kubernetes.
En matière de chiffrement, AWS a bien conscience que certains clients, ceux les plus régulés, ne souhaitent pas utiliser les mécanismes proposés par le fournisseur cloud. Les clés maîtresses demeurent par défaut dans les systèmes du géant du cloud. C’est la raison pour laquelle il a présenté – à contrecœur semble-t-il – l’option XKS pour AWS KMS. Celle-ci doit permettre aux clients de détenir, de gérer et de maintenir ses propres clés dans leurs propres modules matériels de sécurité.
Une somme de situations particulières
« En France, on a effectivement besoin de continuer d'éduquer, d'informer et de former », affirme Julien Groues. « Les directions techniques et de sécurité de nos grands clients, une fois qu'elles comprennent comment ça fonctionne, elles sont rassurées. C'est pour ça qu'on travaille avec 80 % du CAC40, avec toutes les FinTech françaises, avec les banques parce qu'elles se sentent plus protégées chez AWS que par d'autres moyens. Et c'est vrai que XKS permet de répondre à un besoin de clarté ».
Pour autant, le directeur général d’AWS France sait bien que cette notion de contrôle ne correspond pas à la définition de souveraineté défendue par les pouvoirs publics français. « Il y a beaucoup de confusions entre la souveraineté, la confidentialité et la sécurité », défend Julien Groues.
Et si le fournisseur aime bien évoquer la confiance qu’il entretient avec ses clients et ses partenaires, il ne peut pas employer le terme aussi aisément que cela. Le label « Cloud de Confiance » issu de l’initiative « Cloud au Centre » définit un cloud hors d’atteinte des lois extraterritoriales. AWS ne peut pas prétendre à cette appellation.
En France, la doctrine de l’Etat s’est traduite par la publication du référentiel SecNumCloud 3.2 par l’ANSSI. Celui-ci lie des exigences de sécurité à la provenance européenne du capital du fournisseur. Là aussi, AWS ne peut pas directement prétendre à son obtention, ce qui pourrait lui empêcher de contracter avec les organes rattachés à l’Etat Français et une partie des acteurs du secteur public.
« Nous continuons de travailler sur les sujets de SecNumCloud 3.2. Nous savons que c’est un sujet important pour nos clients. Et nous nous reverrons quand nous pourrons faire des annonces », répète Julien Groues.
