Microsoft lance le nébuleux Cloud for Sovereignty

Qu’est-ce que Microsoft Cloud for Sovereignty ?

Cette solution adressée au service public du monde entier devrait inclure Microsoft 365, Dynamics 365 et les services Azure. Le fournisseur prétend qu’elle s’appuiera sur son infrastructure existante, l’expertise de ses entités et de ses partenaires locaux, dont Capgemini et Orange, ainsi qu’un ensemble de mécanismes de sécurité et de confidentialité.

Pour établir cette offre dite souveraine, Microsoft reprend encore une fois l’argument de la résidentialité des données. « La fondation de Microsoft Cloud for Sovereignty reposera sur nos centres de données régionaux Azure », écrit Corey Sanders, Vice-président corporate Microsoft for Industry and Global Expansion Team. Azure s’étend sur 60 data centers installés dans 35 pays.

Cette résidentialité sera combinée à des méthodes de contrôle existantes et d’autres en cours de développement.

Par exemple, Microsoft a présenté les futures Sovereign Landing zone, dérivées des Azure Landing Zone. Ce sont des principes d’architecture permettant de définir des règles de conformité et de sécurité en utilisant l’infrastructure as code et le Policy as Code.

De son côté, Corey Sanders rappelle la disponibilité d’ici à la fin de l’année du programme EU Data Boundary. Il doit assurer que les données et les traitements y afférents demeurent au sein de l’Union européenne, même pour des besoins de support. Cela ne veut pas dire que les opérations de maintenance seront forcément effectuées depuis l’espace économique européen (EEE).

« Nous nous appuierons sur des technologies telles que le VDI (Virtual Desktop Infrastructure) », écrivent les auteurs d’un rapport de progression sur la mise en place d’EU Data Boundary, publié le 16 décembre 2021.

« La VDI évite de devoir transférer ou stocker des données physiques en dehors de la frontière de l’UE, ce qui nous permet de déployer à tout moment les meilleures ressources d’assistance et d’ingénierie possibles pour nos clients à l’intérieur de la frontière de l’UE ».

Ces accès contrôlés aux données des entreprises sont également au cœur des offres estampillées « Customer Lockbox » pour Microsoft 365, Azure, Power Platform et « et bientôt pour Dynamics 365 ». Ces lockbox doivent assurer que Microsoft n’accède aux données des clients à des fins de maintenance qu’avec leur accord explicite.

Plus de chiffrement et d’informatique confidentielle

L’autre argument phare de Microsoft en faveur de son offre Cloud for Sovereignty est très populaire chez les fournisseurs de cloud. « Nous fournirons aux clients des couches supplémentaires pour protéger et chiffrer les données sensibles », promet Corey Sanders.

Le responsable mentionne notamment le système de chiffrement à double clé (DKE) rattaché à la licence E5 de Microsoft 365. Le service est pensé pour protéger les documents produits avec les versions desktop de Word, Excel et PowerPoint. Avec DKE, une des clés est administrée par Microsoft, l’autre par le client dans l’emplacement de son choix. Cela doit empêcher le fournisseur de déchiffrer les fichiers, même une fois transférés sur OneDrive ou Sharepoint. Pour les usages les plus sensibles, le fournisseur recommande tout de même d’opter pour un HSM d’Entrust ou de Thales, dans un mode BYOK (Bring Your Own Key).

Microsoft mise aussi sur l’informatique confidentielle. Ici, il ne s’agit plus seulement de protéger les données au repos et en transit, mais en plein traitement. L’éditeur peut appliquer cette technique à des machines virtuelles, des conteneurs et Azure SQL.

Les données manipulées résident alors dans des Trusted Execution Environnement (TEE), qui reposent le plus souvent sur les TPM (Trusted Platform Module), des zones isolées au sein des processeurs AMD et Intel.

« Les clés de chiffrement appartenant au client sont libérées de manière confidentielle et sécurisée directement à partir d’un module de sécurité matérielle (HSM) managé dans les TEE qui exécutent les données chiffrées du client », explique Corey Sanders. « [Cela] permet de protéger les données et les clés contre de nombreux risques de sécurité et d’accès par les opérateurs ».

Débat sur le BYOK

Les HSM managés, bien que gérés par Microsoft, sont dits monolocataires. Même s’ils appartiennent et sont maintenus par le géant du cloud, un mécanisme de gestion des accès (RBAC) doit permettre qu’un client en ait le contrôle total, promet la documentation d’Azure. Là encore, le BYOK est une option.

Le fait d’administrer ses propres clés et de les transférer vers le cloud est une pratique mise en avant par certains fournisseurs de cloud, dont Microsoft, et leurs partenaires fabricants de HSM ou éditeurs de KMS.

Le sujet fait toutefois débat. Dans un billet de blog publié le 10 avril 2021, Barbara Vieira, Senior Security Engineer chez AWS – alors Principal Security Engineer chez TomTom – insiste sur le fait que le « BYOK n’est pas un moyen de résoudre le problème du contrôle des clés en ce qui concerne les exigences de conformité ni le problème du contrôle des clés dans les solutions SaaS ».

Barbara Vieira évoque plus particulièrement l’utilisation des KMS (Key Management System), qui n’offrent qu’un chiffrement logiciel. Mais au regard des recommandations du comité européen de la protection des données (EDPB) après l’invalidation du Privacy Shield, « utiliser un HSM, un KMS ou du BYOK déléguant le stockage, le contrôle ou l’utilisation de la clé au sous-traitant hors de l’EEE n’est pas une mesure supplémentaire suffisante » pour protéger les données contre leurs transferts vers les États-Unis, selon l’analyse de l’éditeur français Seald.

Azure Arc, pour les usages les plus sensibles

En ce sens, pour contenir les traitements des données aux environnements locaux, Microsoft recommande le recours à Azure Arc. Arc permet d’étendre les outils de gestion Azure à des ressources sur site, multicloud et Edge tant qu’elles fonctionnent sous Windows, Linux ou Kubernetes. Les clients peuvent utiliser des systèmes Stacks certifiés fabriqués par des équipementiers tiers.

Ici, les instances sur site sont connectées à Azure via deux modes : direct ou indirect. Le mode de connexion indirecte doit « envoyer une quantité minimale de données à Azure à des fins d’inventaire et de facturation uniquement », selon la documentation de Microsoft.

Une liaison privée via Azure Private Link est disponible depuis peu pour gérer des serveurs Windows et Linux « sans envoyer le trafic réseau via l’Internet public ». Cela permettrait d’éviter les exfiltrations de données. Dans ce cas-là, le réseau local d’un data center est connecté à un réseau virtuel Azure via un VPN site à site ou via ExpressRoute.

Le fournisseur mentionne bien un mode « jamais connecté » pour Arc avec lequel « aucune donnée ne peut être envoyée vers ou à partir d’Azure », mais il n’est actuellement pas pris en charge.

Une transparence elle aussi confidentielle

Comme le prouve cet article, l’éditeur maintient une documentation particulièrement fournie. D’ailleurs, la plupart des composants de Cloud for Sovereignty sont d’ores et déjà disponibles. Mais le doute subsiste sur certains aspects. C’est pourquoi l’éditeur projette d’étendre son Government Security Program (GSP).

Ce programme a été conçu pour fournir aux personnels qualifiés des gouvernements « les informations de sécurité confidentielles dont ils ont besoin pour faire confiance aux produits et services de Microsoft », rappelle Corey Sanders, lors d’une session virtuelle de l’événement Inspire. « Nous prévoyons d’étendre ce programme aux éléments critiques de nos offres de cloud, en commençant par les composants clés de l’infrastructure Azure ».

« [Le programme] offrira un accès contrôlé au code source, l’échange d’informations sur les menaces et les vulnérabilités, l’engagement sur le contenu technique des produits et services de Microsoft, et l’accès aux centres de transparence pour des niveaux approfondis d’inspection et d’analyse du code source. En outre, nous offrirons aux clients des droits d’audit renforcés pour examiner les processus, les preuves et l’accès physique aux centres de données de Microsoft sous NDA [accord de non-divulgation N.D.L.R.] ».

Cloud for Sovereignty suscite la confusion

Cette volonté de transparence n’évacue pas certaines questions parmi les participants de l’événement Inspire 2022. La plus importante d’entre elles étant : « comment différencier Microsoft Cloud for Sovereignty des offres comme Bleu en France ? ».

«  Nous et nos partenaires pensons que c’est le modèle avec lequel nous pouvons apporter le plus de valeurs à long terme à nos clients plutôt que de construire des centaines de clouds souverains partout dans le monde ».

« Les Government Cloud ou Bleu sont essentiellement des clouds totalement séparés où nous déployons une nouvelle instance d’Azure », indique Nathan Johnson, Principal Program Manager chez Microsoft.

Cloud for Sovereignty n’est pas un environnement cloud à proprement parler, mais une combinaison des meilleures pratiques de sécurité et de confidentialité recommandées par Microsoft et ses partenaires à appliquer suivant le type de workload dans Azure.

« En analysant les données en fonction de leur sensibilité et de leur classification, vous serez en mesure de sélectionner la meilleure approche pour chaque charge de travail dans le cloud ou en Edge », affirme Nathan Johnson.

« En fin de compte, nous et nos partenaires pensons que c’est le modèle avec lequel nous pouvons apporter le plus de valeurs à long terme à nos clients, plutôt que de construire des centaines de clouds souverains partout dans le monde », ajoute-t-il.

Or Bleu est né pour répondre à un enjeu essentiel des acteurs du secteur public français : l’immunité aux législations non européennes. Selon la doctrine Cloud au centre, sauf exception, l’Administration française ne peut plus recourir à une offre telle que Cloud for Sovereignty. Et, sans équivoque, le cloud Azure demeure soumis aux lois extraterritoriales américaines, dont le CLOUD Act, le Patriot Act et le FISA Act.