Souveraineté numérique : où en est Google Cloud ?
Google Cloud vient de dégainer, sous la forme d'un questionnaire, un « indicateur de souveraineté numérique ». Comment envisage-t-il la notion ?
« Est-ce que la protection de votre cloud contre les arrêts forcés ou les événements géopolitiques est pour vous une préoccupation majeure ? » Ainsi se conclut le questionnaire que Google Cloud soumet dans le cadre de son « indicateur de souveraineté numérique ».
Cette initiative vise à « accompagner la définition d'une stratégie » dans ce domaine. Ciblant, en l'état, les organisations européennes, elle met en oeuvre la vision que le groupe américain communique depuis 2020. Celle-ci s'articule en trois axes :
- Souveraineté des données (localisation, contrôle sur le chiffrement et les accès...)
- Opérationnel (visibilité et contrôle sur les actions du fournisseur)
- Logiciel (portabilité des charges de travail, usage en mode déconnecté...)
« La souveraineté numérique est définie différemment selon les pays », reconnaît Google Cloud en ouverture de son questionnaire. Aussi demande-t-il, en premier lieu, à quelle échelle on souhaite déployer des solutions. Dans la pratique, qu'on sélectionne « Toute l'Europe » ou l'un des pays listés, la suite du parcours est la même. Sauf si on choisit l'option France, auquel cas on nous interroge sur l'éventuel besoin d'un fournisseur certifié SecNumCloud.
Sensibilité des données, chiffrement et contrôle des accès
Sur la partie data, il s'agit d'abord de déterminer le degré de sensibilité des données. Quatre options sont proposées :
- Données publique soumises à aucune contrainte
- Obligation de protection conformément au RGPD et/ou aux recommandations du CEPD
- Données sensibles du point de vue des règles de l'organisation, mais non soumises à des exigences réglementaires
- Classifiées ou nécessitant un isolement physique
Étapes suivantes :
Lire aussi : IaaS : Google, plus "visionnaire" que les autres ?
- Évaluer le niveau de visibilité et de contrôle sur les accès du fournisseur cloud... ainsi que ceux d'organisations tierces
- Estimer le besoin de gestion des clés de chiffrement (par le client ou par le fournisseur ? dans l'environnement de ce dernier ou en dehors ?)
- Définition du besoin de contrôle des lieux depuis lesquels se font les accès des utilisateurs finaux
Support technique et portabilité
Sur le volet opérationnel, le principal enjeu consiste à définir si l'assistance technique doit être confiée uniquement à du personnel basé dans l'UE. Sur la partie logicielle, Google Cloud aborde essentiellement l'exécution des projets sur site, éventuellement en air gap.
En sélectionnant les critères les plus restrictifs (SecNumCloud, traitement des accès au cas par cas, assistance d'un partenaire local...), deux options ressortent. D'un côté, « Contrôles locaux avec S3NS », l'offre « intermédiaire » de la joint-venture entre Google Cloud et Thales (elle a son équivalent en Allemagne, avec T-Systems dans la boucle). De l'autre, le catalogue « cloud distribué » sur base Anthos, avec les services GDC Edge (concurrent d'Azure Stack et d'AWS Outposts) et GDC Hosted (orienté sur les workloads sensibles exécutés dans des environnements non connectés).
À consulter pour davantage de contexte :
CLOUD Act : quel degré d'exposition pour Bleu et S3NS ?
Cloud souverain : comment VMware l'envisage et l'orchestre
IT souveraine : le cloud de confiance cherche sa voie
Cloud souverain : l'EU Data Boundary de Microsoft, encore loin du compte ?
Peut-on développer un SaaS bureautique « souverain » avec 8 M€ ?
IT souveraine : 6 pépites made in France
Cloud et sécurité : les référentiels-clés selon le Clusif
Sur le même thème
Voir tous les articles Cloud