Confidential computing : Intel TDX vs AMD SEV-SNP en 2026

Le troisième état des données, longtemps laissé sans protection

Les équipes de sécurité évoquent presque par réflexe deux états des données : au repos (chiffrement des disques) et en transit (TLS). Le troisième état — les données en cours d’utilisation, c’est-à-dire tout ce qui réside déchiffré dans la mémoire système pendant qu’un CPU le traite — est resté structurellement non protégé jusqu’à ce que les fabricants de matériel livrent des puces capables de calculer sur des données chiffrées sans jamais exposer de texte en clair au système d’exploitation hôte. Le confidential computing est cette pièce manquante du cycle de vie du chiffrement.

La question compte davantage en 2026 qu’il y a quelques années, car les charges de travail que l’on cherche à protéger ont changé. Exécuter de l’inférence ou de l’entraînement d’IA sur des données sensibles — dossiers de patients, historiques de transactions, renseignement de défense — rend l’exposition en clair sur un hôte cloud partagé inacceptable pour un nombre croissant d’organisations britanniques, quelle que soit la solidité de la sécurité périmétrique qui entoure cet hôte.

Comment fonctionnent réellement les environnements d’exécution de confiance

Un environnement d’exécution de confiance (TEE, Trusted Execution Environment) est une frontière imposée par le matériel. Les VM confidentielles reposant sur Intel TDX et AMD SEV-SNP isolent cryptographiquement la mémoire et l’état du CPU, de sorte qu’aucun administrateur de l’hôte ni aucun processus de l’hyperviseur — y compris les propres opérateurs du fournisseur cloud — ne peut les consulter ou les modifier. Le modèle de confiance est de fait inversé : au lieu de faire confiance à l’opérateur cloud, vous faites confiance au silicium.

Le mécanisme de preuve est l’attestation cryptographique. Avant qu’une charge de travail soit considérée comme digne de confiance, la plateforme signe un rapport contenant l’identité de la plateforme, les mesures du firmware et un nonce fourni par le vérificateur, ce qui permet à une partie distante de confirmer que la charge de travail exécute un code authentique et non modifié au sein d’un véritable TEE — et non dans un environnement usurpé ou altéré.

• •Chiffrement de la mémoire — des clés uniques par VM empêchent l’hôte de lire la RAM de l’invité
• •Isolation de l’état du CPU — les registres et l’état d’exécution sont soustraits à l’hyperviseur
• •Rapports d’attestation — preuve signée de l’identité de la plateforme et de l’intégrité du code
• •TPM virtuels protégés par le matériel — ils certifient l’état de santé de la VM et prennent en charge une gestion renforcée des clés, comme BitLocker sur les VM confidentielles Azure

Intel TDX vs AMD SEV-SNP : le détail technique

Intel TDX s’appuie sur Multi-Key Total Memory Encryption (MKTME) pour attribuer à chaque Trust Domain sa propre clé AES-128-XTS unique, ce qui isole la mémoire de ce domaine à la fois de l’hyperviseur et du système d’exploitation hôte. Comme TDX ne dispose pas de processeur de sécurité dédié, l’attestation se fait en deux temps : le module TDX produit un rapport à l’aide de l’instruction SEAMREPORT, puis une quoting enclave — elle-même une enclave SGX — le signe pour en faire une quote vérifiable à distance. Si vous sélectionnez des plateformes dans cette optique, il est utile de comprendre le silicium sous-jacent : les processeurs Intel Xeon 6 constituent la génération actuelle dotée de la prise en charge de TDX (également présente sur les Xeon Scalable de 5e génération).

AMD SEV-SNP emprunte une voie architecturale différente, en ajoutant Secure Nested Paging pour bloquer les attaques menées depuis l’hyperviseur contre les tables de pages de l’invité. Il chiffre la mémoire à l’exécution, restructure les tables de pages de sorte que l’hôte ne puisse ni les lire ni les altérer, et introduit une attestation au lancement pour vérifier l’intégrité de la mémoire de l’invité dès le démarrage d’une VM. Côté matériel, c’est l’ensemble de fonctions de confidential computing intégré aux processeurs AMD EPYC Turin.

En pratique, les deux ne sont pas interchangeables : ils répondent à des profils de risque différents. AMD SEV-SNP est généralement privilégié pour les charges de travail gourmandes en CPU dans les services financiers et la santé en raison de son surcoût de performance plus faible, tandis qu’Intel TDX a tendance à l’emporter pour les administrations, la défense et les charges d’IA à haute sécurité, où son modèle d’attestation est considéré comme offrant la garantie la plus solide.

Surcoût de performance en conditions réelles

Le confidential computing n’est pas gratuit, et le surcoût varie fortement selon le profil de la charge de travail — c’est le détail que la plupart des guides passent entièrement sous silence. Pour AMD SEV-SNP en particulier, les charges de travail intensives en CPU subissent un surcoût d’environ 2–5 %, tandis que les applications intensives en mémoire tournent 5–10 % plus lentement, ce qui reflète le coût supplémentaire du chiffrement et de la vérification de la mémoire à chaque accès.

Une analyse empirique distincte d’AMD SEV-SNP a relevé un surcoût d’accès mémoire allant jusqu’à 7 % dû au seul chiffrement, la latence mémoire pouvant être multipliée jusqu’à 5 fois pour certains schémas d’accès. Plus frappant encore, les pires scénarios, impliquant des changements de contexte et des copies mémoire excessifs, ont vu le surcoût grimper jusqu’à 400 % — un chiffre qui s’applique spécifiquement à ce schéma pathologique, et non aux charges de travail typiques en régime stable.

L’enseignement pratique : ne supposez pas un pourcentage de surcoût uniforme. Les charges de travail lourdes en bases de données ou en virtualisation, avec des changements de contexte fréquents, doivent faire l’objet de benchmarks avant la migration, car elles se situent à l’extrémité de cette fourchette, tandis que les tâches simples d’analytique ou d’inférence limitées par le CPU restent bien plus proches d’un surcoût à un chiffre.

Implications financières pour les acheteurs britanniques

Aucun grand fournisseur ne publie de grille tarifaire spécifique en GBP pour les instances confidentielles, mais les estimations du secteur indiquent que les VM confidentielles coûtent environ 15–25 % de plus que des instances standard équivalentes dans le cloud public. Ce surcoût doit être mis en balance avec ce qu’il apporte : une réponse technique et auditable à la question « votre fournisseur peut-il lire nos données ? » — la question que les régulateurs et les clients posent réellement, de plus en plus souvent.

Pour les enjeux de confiance transfrontalière en particulier, les acheteurs britanniques devraient interroger avec insistance les fournisseurs sur la localisation de l’attestation — en choisissant un service d’attestation déployé dans la région de leur choix (Azure Attestation, par exemple, fonctionne sous forme d’instances régionales) et, si nécessaire, une connectivité privée vers les points de terminaison d’attestation (par exemple via AWS PrivateLink) plutôt que d’accepter un point de terminaison d’attestation mondial par défaut, afin de ne pas introduire une dépendance de confiance inutile envers l’étranger dans un déploiement par ailleurs souverain.

Conformité au Royaume-Uni : RGPD et réglementation sectorielle

Le confidential computing apporte aux organisations britanniques ce que l’article 32 du RGPD a toujours demandé sans guère l’obtenir : une preuve technique et vérifiable de la sécurité du traitement, plutôt qu’une promesse contractuelle. Les rapports d’attestation fournissent aux auditeurs la preuve cryptographique qu’une charge de travail s’est exécutée dans un environnement isolé et non modifié — un élément de conformité nettement plus solide que les conditions générales standard d’un fournisseur cloud.

L’impact est le plus fort dans les secteurs réglementés. Les organismes du NHS qui appliquent l’IA à des données de santé, les entreprises financières supervisées par la FCA qui traitent des historiques de transactions et les travaux de défense liés au MOD partagent tous le même problème de fond : devoir exécuter des calculs sur des données trop sensibles pour être exposées en clair à un hôte tiers. Les obligations découlant des NIS Regulations comme, pour les entreprises britanniques qui fournissent des systèmes d’IA dans l’UE, la conformité à l’AI Act européen bénéficient de l’attestation fondée sur les TEE, qui réduit la charge d’audit pesant sur les charges de travail réglementées. Si la protection des données en cours d’utilisation s’inscrit dans une revue de sécurité plus large, il est utile de l’associer aux recommandations de nos solutions de cybersécurité couvrant le reste de la pile.

Mise en œuvre pratique : étapes et pièges

La migration d’une charge de travail sensible suit généralement un schéma similaire : identifier la charge de travail et l’exigence réglementaire qui la motive, choisir TDX ou SEV-SNP selon que la solidité de l’attestation ou un surcoût plus faible importe davantage, provisionner l’instance de VM confidentielle sur le cloud choisi, et intégrer la vérification de l’attestation au pipeline de déploiement plutôt que de la traiter comme un contrôle ponctuel. Sur Azure, cela peut être associé à un TPM virtuel protégé par le matériel pour certifier l’état de santé de la VM et prendre en charge une gestion renforcée des clés, comme BitLocker.

Sous l’abstraction de la VM, TDX et SEV-SNP sont des primitives CPU de virtualisation confidentielle assistée par le matériel : elles imposent une séparation au niveau matériel entre le logiciel système et la VM confidentielle elle-même, ce qui signifie que le noyau invité doit être compilé ou configuré pour s’exécuter dans ce mode isolé, au lieu d’être traité comme une image prête à l’emploi. AMD SEV-SNP, en particulier, restructure les tables de pages de l’invité pour en exclure l’accès de l’hôte et réalise au démarrage une attestation de l’intégrité de la mémoire de l’invité ; la chaîne de démarrage mesuré — firmware et état initial du noyau — fait donc partie de ce qui est réellement vérifié, au lieu d’être un ajout greffé après coup. L’intégration du TPM virtuel utilisée pour la gestion des clés de type BitLocker sur les VM confidentielles Azure constitue elle-même un point de contact au niveau du système d’exploitation invité, et non un mécanisme transparent opérant sous le système d’exploitation.

Les pièges sont opérationnels plutôt que conceptuels. L’attestation ajoute une étape de vérification qui doit être automatisée et surveillée, et pas seulement exécutée une fois lors du déploiement. Le débogage est réellement plus difficile : les outils de niveau hôte qui inspectaient la mémoire de l’invité à des fins de dépannage ne peuvent tout simplement pas voir l’intérieur d’une enclave chiffrée, ce qui modifie le fonctionnement de la réponse aux incidents et du diagnostic des performances. Les agents de sécurité et de supervision existants nécessitent aussi souvent des versions compatibles TEE, puisque les outils standard basés sur l’hôte n’ont aucune visibilité sur ce qu’ils sont censés protéger. Pour les organisations qui comparent les VM confidentielles dans le cloud à une infrastructure sur site ou hybride reposant sur des CPU compatibles TEE, il est utile d’étudier les options lorsque vous configurez un serveur.

• •Coût : les VM confidentielles entraînent un surcoût de 15–25 % par rapport aux instances standard du cloud public ; posséder sur site des CPU compatibles TEE (Xeon 6, EPYC Turin) évite ce surcoût récurrent pour les charges de travail réglementées en régime stable, au prix d’un investissement matériel initial
• •Maîtrise de l’attestation : les déploiements sur site conservent en interne l’intégralité de la chaîne d’attestation et la référence de mesure du firmware ; le cloud public implique de faire confiance au service d’attestation du fournisseur, sauf si vous exigez un service d’attestation situé dans la région de votre choix, joignable via une connectivité privée comme AWS PrivateLink
• •Charge d’audit : les deux modèles produisent les mêmes rapports d’attestation cryptographique comme preuves au titre de l’article 32 du RGPD, mais le déploiement sur site élimine entièrement toute question transfrontalière de résidence des données — un point pertinent pour les charges de travail liées au MOD ou au NHS
• •Adéquation à la charge de travail : associez à chaque charge de travail Intel TDX (attestation plus solide, privilégiée pour les administrations, la défense et l’IA à haute sécurité) ou AMD SEV-SNP (surcoût plus faible, privilégié pour la finance et la santé), qu’elle soit hébergée dans le cloud public ou sur site

IA confidentielle : l’avenir au-delà de 2026

Le moteur le plus évident de la dynamique du confidential computing à la mi-2026 est l’IA appliquée aux données sensibles. Exécuter des charges d’inférence ou d’entraînement sur des jeux de données réglementés sans exposer de texte en clair au fournisseur cloud devient une exigence de base plutôt qu’un simple atout, et c’est le cas d’usage qui accélère le plus l’adoption de TDX et de SEV-SNP dans les déploiements cloud au Royaume-Uni.

Il faut rester lucide sur le périmètre : le confidential computing est très efficace contre la préoccupation de confidentialité la plus courante dans le cloud — l’accès du fournisseur lui-même aux données des clients — mais il laisse subsister des risques résiduels qui exigent toujours des contrôles complémentaires, comme la sécurité réseau, la gestion des accès et la protection des terminaux. Il comble une faille précise, jusque-là ouverte, dans le cycle de vie du chiffrement ; il ne remplace pas le reste d’un programme de sécurité.

Sources

Chaque chiffre de cet article provient des sources ci-dessous.

• •Stealth Cloud — analyse approfondie du confidential computing et périmètre du modèle de menace
• •Onidel — surcoût de performance d’AMD SEV-SNP vs Intel TDX et adéquation aux charges de travail
• •Red Hat — quoting enclave d’Intel TDX et architecture d’attestation
• •Microsoft Azure Docs — FAQ sur les VM confidentielles, comparaison des fonctionnalités TDX/SEV-SNP
• •Ian Klatzco — mécanismes de l’attestation cryptographique
• •Ubuntu — explication du modèle de confiance du confidential computing
• •ServerMall — isolation des locataires par TEE et cas d’usage des charges de travail réglementées
• •Sekyourity Blog — détail des primitives matérielles d’AMD SEV-SNP et d’Intel TDX
• •1C Confidential VMs (YouTube) — chiffres empiriques de surcoût mémoire et de changement de contexte