Votre base de données est chiffrée. Vos connexions sont en TLS. Vos sauvegardes sont chiffrées. Chaque case du questionnaire de conformité est cochée.
Et puis le processeur déchiffre tout pour faire le moindre travail réel — c'est-à-dire la plupart du temps —, et à cet instant les données reposent en mémoire en clair, où quiconque a un accès suffisant à l'hôte peut les lire.
Le troisième état que personne n'a chiffré
Les données existent dans trois états, et l'industrie a passé vingt ans à en résoudre deux à fond.
Au repos — sur disque — résolu. En transit — sur le réseau — résolu. En usage — chargées en mémoire pendant qu'un programme opère dessus — a toujours été l'exception, parce que le calcul sur données chiffrées n'était pas praticable.
Pour la plupart des charges de travail, cet écart est acceptable. Vous faites confiance à votre fournisseur cloud, à son personnel et à son hyperviseur — et cette confiance est raisonnable vu ce qu'il investit pour la mériter.
Pour certaines charges, il ne l'est pas — et de plus en plus, la question n'est pas de savoir si vous faites confiance au fournisseur, mais si vous pouvez prouver que le fournisseur n'a pas pu voir les données. Ce sont des affirmations différentes, et une seule des deux satisfait un régulateur.
Ce que fait réellement un environnement d'exécution de confiance
Le confidential computing ferme l'écart dans le matériel. Les processeurs serveurs modernes savent créer une région de mémoire chiffrée — une enclave — où les données ne sont déchiffrées qu'à l'intérieur du processeur lui-même.
Conséquence pratique : tout ce qui est hors de cette frontière voit du chiffré. Le système d'exploitation voit du chiffré. L'hyperviseur voit du chiffré. Un ingénieur cloud avec les droits root sur l'hôte physique voit du chiffré. Quelqu'un qui retire physiquement le module mémoire et le lit directement obtient du chiffré.
La seconde moitié, c'est l'attestation — et c'est la partie qui compte le plus pour la conformité. Avant d'envoyer des données, vous pouvez demander au matériel de prouver — cryptographiquement, signé par le fabricant — exactement quel code tourne dans l'enclave. Si quelqu'un a remplacé le binaire, l'attestation échoue — et vous n'envoyez jamais les données.
Voilà la capacité réellement nouvelle. Pas seulement de la mémoire chiffrée — une preuve vérifiable de ce qui traite vos données, avant qu'elles n'arrivent.
Fig. — La frontière de confiance passe du personnel du fournisseur au silicium.
Où ça mérite son coût
Le calcul multipartite sans confiance mutuelle. Plusieurs banques veulent faire tourner une détection de fraude sur leurs données de transactions combinées. Aucune ne remettra ses données aux autres ni à un tiers. Une enclave leur permet à toutes de contribuer des entrées chiffrées à un calcul dont elles ont toutes vérifié le code — et de ne recevoir que le résultat. C'était auparavant une négociation contractuelle qui n'aboutissait jamais.
Les charges régulées dans le cloud public. Les données de santé et financières que le juridique refusait de laisser sortir deviennent souvent acceptables quand le fournisseur est cryptographiquement exclu de l'accès. Cela débloque des migrations cloud gelées depuis des années.
Protéger le modèle plutôt que les données. Si vous avez lourdement investi dans l'entraînement d'un modèle propriétaire et devez le déployer là où vous ne contrôlez rien, une enclave le fait tourner sans exposer les poids au propriétaire de la machine.
La gestion de clés. Toute opération impliquant des clés privées en bénéficie — c'est pourquoi cette technologie sous-tend discrètement une grande partie de la conservation d'actifs numériques.
Les coûts et les réserves
La performance n'est plus l'objection d'avant. Le chiffrement mémoire a un coût — couramment un pourcentage modeste à un chiffre pour les charges typiques, parfois pire pour les gourmandes en mémoire — et la génération actuelle est assez bonne pour que cela ne décide plus grand-chose.
La complexité est le vrai prix. L'attestation doit s'intégrer à votre chaîne de déploiement — votre build devient donc partie de votre frontière de sécurité. Changez le code et la mesure change ; les processus de release doivent en tenir compte. Le débogage est plus dur par conception, puisque tout l'intérêt est qu'on ne peut pas inspecter la mémoire.
La portabilité est imparfaite. Les grands fournisseurs cloud proposent tous du confidential computing — et les implémentations matérielles diffèrent assez pour qu'un déménagement ne soit pas un changement de configuration.
Et la réserve honnête : les enclaves protègent de l'infrastructure, pas de votre propre code. Une application vulnérable à l'intérieur de l'enclave fait fuiter des données parfaitement chiffrées jusqu'au moment où votre bug les a tendues. Cela relève le plancher du risque d'infrastructure. Cela ne fait rien pour la sécurité applicative.
À quoi ressemble l'adoption
Le chemin d'adoption se divise selon le contrôle voulu — et les deux bouts sont des projets très différents.
La voie gérée, c'est la VM confidentielle : votre charge tourne dans une machine virtuelle à mémoire chiffrée, et vous ne changez presque rien à l'application. Les trois grands fournisseurs la proposent, la migration est souvent proche d'un changement de configuration, et le bénéfice du chiffrement mémoire est immédiat. Ce que vous obtenez moins, c'est l'attestation fine — vous attestez une image machine entière plutôt qu'un morceau de code précis, ce qui satisfait certaines exigences et pas d'autres.
La voie profonde, c'est l'enclave applicative : vous partitionnez votre code pour que seule la partie sensible tourne dans la région protégée. Vous obtenez une base de confiance petite et précisément attestable — ce qu'un auditeur exigeant veut voir. Cela signifie aussi restructurer l'application autour d'une frontière, décider ce qui la traverse — et accepter que tout ce qui est dedans soit plus dur à observer et à déboguer.
La plupart des équipes devraient commencer par la VM confidentielle. Elle répond à la version courante de la question — votre fournisseur peut-il lire nos données ? — par un non défendable, pour une fraction de l'effort. Ne passez aux enclaves que lorsque quelqu'un de précis a demandé quelque chose que la réponse VM ne couvre pas.
En avez-vous besoin ?
La plupart des équipes, non — et les vendeurs ne commenceront pas par vous le dire.
Le test : pouvez-vous nommer un adversaire précis contre lequel ceci — et seulement ceci — défend ? « Un administrateur malveillant ou compromis chez notre fournisseur cloud » est une réponse légitime. « Une meilleure sécurité en général » n'en est pas une — et produira beaucoup de dépense pour aucune réduction mesurable du risque.
Le signal le plus clair est réglementaire. Si un régulateur, un auditeur ou la revue de sécurité d'un grand client a précisément demandé comment vous protégez les données en usage, vous avez une exigence concrète — et ceci en est la réponse. Cette question se pose plus souvent chaque année, en particulier dans la finance et la santé — c'est pourquoi la technologie passe de la recherche aux dossiers d'achat.
Si personne n'a demandé, dépensez l'effort d'abord sur le contrôle d'accès et la sécurité applicative. Ils défendent contre les attaques qui arrivent réellement aux entreprises de votre taille — et ils coûtent nettement moins cher.
