Face aux enjeux de souveraineté auxquels font face les entreprises, notre chroniqueur Michel Juvin explore le concept de « Confidential Computing », son fonctionnement technique et ses limites.
La souveraineté des données se compose de deux parties : la limitation des données en accès et la non dépendance vis-à-vis d’une organisation dont les objectifs ou intérêts ne sont pas nationaux. Dans cette chronique ; on ne traitera pas de la dépendance mais bien d’identifier des solutions techniques ou des moyens qui permettent de protéger nos données alors qu’elles sont stockées dans un Cloud non souverain et donc accessibles par l’hébergeur.
Actuellement, près de 70% des données des entreprises sont stockées sur des Cloud de nationalité étrangères (américains ou chinois) et on ne peut pas ignorer la guerre économique qui conduit à voler ou détruire des informations. C’est pourquoi le principe de « Confidential Computing » attire l’attention.
A lire aussi : [Chronique] Move-to-cloud : quelles règles du jeu pour créer son datacenter virtuel ?
Le « Confidential Computing », comment ça fonctionne ?
Le principe est simple : Au-delà d’une protection contractuelle, l’objectif est de ne pas autoriser l’administrateur hébergeur des données à accéder aux données, y compris lorsqu’elles sont traitées par le processeur de la machine. Pour mémoire, le fonctionnement de nos chiffrements font que les « data at rest » et « data in transit » sont protégés, alors que le « data in use » ouvre à des possibilités de hacking de l’hébergeur.
En effet, les données peuvent être stockées chiffrées sur le lieu d’hébergement mais, pour pouvoir les utiliser, elles doivent être déchiffrées pour leur traitement ; elles se retrouvent alors sur la RAM – mémoire vive du serveur – et de fait peuvent être accédées soit à cause d’une usurpation d’identité de l’administrateur de la machine, soit par des techniques de hacking tel que le memory scrapping.
Un groupement de sociétés dont IBM, Intel (SGX enclaves), Google et Huawei ont proposé dès 2016 une technologie pour protéger ces données : le « Confidential Computing ».
Celui-ci vise à interdire l’accès à ces données lorsqu’elles sont en traitement en utilisant une architecture hardware appelée TEE (Trusted Execution Environment) qui est un co-processeur à l’intérieur de la CPU de la machine. Les droits d’accès administrateur au TEE sont protégés et seul le propriétaire du traitement bénéficie de droits spécifiques pour accéder aux données. De plus en cas de tentative d’accès frauduleux, le TEE bloque l’accès et stop le traitement des données (pour éviter qu’elles ne soient écrites en mémoire)[1].
Dans les faits, les données sont traitées uniquement par le co-processeur qui peut alors les déchiffrer, appliquer le traitement voulu et les rechiffrer pour les retransmettre au processeur hôte qui les renverra au demandeur.
Mais pourquoi aussi peu d’exemple de mise en œuvre ?
Dès lors, on pourrait se dire que tout est bien qui finit bien. Mais non. Lors de mes recherches, j’ai constaté que très peu d’entreprise ont réellement utilisé cette technologie. Il est vrai que certain rapportent une surconsommation de ressource et de temps de traitement. Mes contacts m’informent aussi que certaines sociétés utilisent cette pratique, mais ne souhaitent pas partager leur expérience.
On constate aussi que bien souvent, la sécurité lorsqu’elle n’est pas implicite, est souvent en contradiction avec des objectifs business. Ainsi, force est de constater que malgré les risques identifiés (et à priori compris par les responsables métiers), une entreprise ne prend nombre de fois pas le temps de protéger ses données pour apporter une réponse.
De plus, la mise en place du « Confidential Computing » impose la classification précise des données, avec le niveau de sensibilité indiqué dans le temps. C’est un projet qui prend du temps et souvent n’aboutit pas. Les données sont aux mieux simplement classées sur un indice de 1 à 5 sans grande précision. L’estimation du risque de perte d’information n’est pas valorisée à sa juste mesure.
Enfin, l’utilisation de clefs de chiffrement est complexe et nécessite une grande rigueur. Comme le rappelle un de mes collègues (Directeur de recherche chez Tenable), il faut bien vérifier que toutes les vulnérabilités techniques proche du poste de travail ainsi que les erreurs des utilisateurs et administrateurs sont réduites avant d’investir dans le Confidential Computing.
Difficile en ce sens de mesurer l’impact réel que le « Confidential Computing » peut avoir sur notre économie.
Quelques recommandations, tout de même…
Malgré cette situation mitigée, quelques bonnes pratiques sont toujours à rappeler. N’oublions pas de bien sécuriser les clefs d’accès aux données et de gérer ses clefs. Le HYOK est donc à privilégier avec une gestion on-premise dans un HSM des clefs ainsi que le choix d’un algorithme de chiffrement doit être fait en fonction de la sensibilité de la donnée. La résistance dans le temps de la protection de l’information doit être à la hauteur de la protection apportée.
Concernant le « Confidential Computing » lui-même, un bon conseil serait déjà d’estimer le surcoût en temps et en ressource avant de mettre en place ce type de technologie auprès de l’hébergeur de vos données.
[1] Plus de détail dans l’article ici : https://www.fortinet.com/fr/resources/cyberglossary/confidential-computing