Confidential computing : l’attestation avant l’accès aux clés
Le confidential computing réduit l’exposition des données pendant leur traitement, y compris face à certains accès privilégiés à l’infrastructure. Sa valeur opérationnelle tient moins au chiffrement seul qu’à la chaîne reliant attestation, politique de confiance et remise des clés.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
Le chiffrement au repos protège les supports et les sauvegardes. Le chiffrement en transit protège les échanges. Il reste un intervalle plus difficile : celui où l’application doit lire et transformer les données. Le confidential computing s’appuie sur un environnement d’exécution de confiance, isolé matériellement, afin de limiter l’accès au contenu en mémoire depuis l’hyperviseur, le système hôte ou certaines fonctions d’administration. Selon l’architecture retenue, l’isolation porte sur une partie du processus ou sur une machine virtuelle entière. Le changement est important pour une organisation régulée : l’administrateur de l’infrastructure n’est plus nécessairement inclus par défaut dans le périmètre de confiance des données. Mais ce résultat exige une conception explicite. Activer une fonction de chiffrement mémoire sans revoir la gestion des clés ne suffit pas.
Définir la menace
Cette technologie répond à un scénario précis : empêcher qu’un acteur disposant de privilèges sur l’infrastructure puisse lire directement les données traitées par une charge de travail. Elle peut réduire le risque lié à une compromission de l’hyperviseur, à une inspection de la mémoire physique ou à un administrateur trop largement habilité. Elle ne protège pas une application qui divulgue elle-même les données, un compte métier compromis, une requête légitime mais abusive, ni tous les canaux auxiliaires. L’hôte conserve aussi une influence sur la disponibilité, les entrées-sorties et le cycle de vie de la charge. Le modèle de menace doit donc nommer les acteurs dont on cherche à se protéger, les composants qui restent dignes de confiance et les données concernées. Sans cette étape, le confidential computing devient une case d’architecture impossible à relier à un risque démontré.
Exploiter l’attestation
- Conditionner la remise des clés : l’environnement produit une preuve cryptographique sur son identité et son état initial. Un service de gestion des clés vérifie cette attestation contre une politique approuvée avant de transmettre un secret. La clé ne devrait pas être injectée simplement parce qu’une machine possède le bon nom ou se trouve sur le bon réseau.
- Versionner la politique de confiance : une mise à jour du système, du micrologiciel ou de la charge peut modifier les mesures attestées. Les valeurs autorisées, les exceptions et leurs approbations doivent être gérées comme du code. Une politique trop rigide bloque les redémarrages ; une politique trop large rend l’attestation décorative.
- Préparer les mises à jour et le retour arrière : chaque changement doit préciser quelles mesures seront acceptées pendant la transition, combien de temps l’ancien état restera autorisé et comment révoquer un état vulnérable. Le retour arrière ne peut pas signifier le rétablissement silencieux d’une configuration qui ne devrait plus recevoir les clés.
- Adapter l’observabilité : l’isolation limite volontairement certaines inspections depuis l’hôte. Les journaux, métriques et traces utiles doivent être produits depuis la charge, protégés en transit et corrélés avec les événements d’attestation. Il faut conserver assez de visibilité pour enquêter sans recréer un accès général à la mémoire.
- Tester les modes de panne : indisponibilité du vérificateur d’attestation, expiration d’un certificat, mesure inconnue ou perte du service de clés peuvent empêcher le démarrage. Le choix entre refus fermé, continuité dégradée et intervention manuelle doit être documenté, testé et compatible avec les objectifs de reprise.
Choisir les bons cas
L’adoption est cohérente lorsque la menace principale inclut réellement l’opérateur de l’infrastructure ou un niveau privilégié compromis, et lorsque les données doivent rester protégées pendant le calcul. Des traitements sensibles sur une infrastructure partagée, l’exécution d’une charge chez un prestataire ou la séparation renforcée entre équipes d’exploitation et détenteurs des données sont des cas plausibles. À l’inverse, une application monolithique peu maîtrisée, dépendante d’outils d’inspection mémoire ou dépourvue de gestion de clés solide constitue un mauvais point de départ. Un pilote doit mesurer la compatibilité des systèmes, l’impact sur les performances, les possibilités de diagnostic, la portabilité et les procédures de mise à jour. Il doit surtout démontrer le parcours complet : démarrage mesuré, attestation vérifiée, clé remise, événement journalisé, révocation appliquée et restauration testée.
Le confidential computing réduit un périmètre de confiance ; il ne le supprime pas. Le matériel, le mécanisme d’attestation, le vérificateur, la politique de remise des clés et le code applicatif restent dans la chaîne de sécurité. Les preuves d’attestation peuvent contribuer au dossier de contrôle, mais elles ne démontrent ni l’absence de vulnérabilité ni la conformité d’un traitement. Avant d’adopter cette architecture, il faut pouvoir répondre simplement à deux questions : contre quel accès privilégié protège-t-elle, et quel composant peut encore obtenir les données en clair ?
Encryption at rest protects storage media and backups. Encryption in transit protects data exchanges. A more difficult interval remains: the point at which an application must read and transform the data. Confidential computing relies on a hardware-isolated trusted execution environment to limit access to in-memory content from the hypervisor, host system or certain administrative functions. Depending on the chosen architecture, isolation may cover part of a process or an entire virtual machine. This is a material change for a regulated organisation: the infrastructure administrator is no longer necessarily included by default within the data trust boundary. Achieving this outcome, however, requires an explicit design. Enabling memory encryption without reconsidering key management is not enough.
Define the threat
This technology addresses a specific scenario: preventing an actor with infrastructure privileges from directly reading the data processed by a workload. It can reduce the risk associated with a compromised hypervisor, inspection of physical memory or an administrator with excessive privileges. It does not protect against an application that discloses the data itself, a compromised business account, a legitimate but abusive query, or every side channel. The host also retains influence over availability, input and output, and the workload lifecycle. The threat model must therefore identify the actors to defend against, the components that remain trusted and the data concerned. Without this step, confidential computing becomes an architecture checkbox that cannot be connected to a demonstrated risk.
Operate the attestation chain
- Make key release conditional: the environment produces cryptographic evidence about its identity and initial state. A key management service verifies this attestation against an approved policy before releasing a secret. A key should not be injected merely because a machine has the expected name or resides on the expected network.
- Version the trust policy: an update to the system, firmware or workload may alter the attested measurements. Approved values, exceptions and their authorisations should be managed as code. A policy that is too strict blocks restarts; one that is too broad turns attestation into decoration.
- Prepare updates and rollback: every change must state which measurements will be accepted during the transition, how long the previous state will remain authorised and how a vulnerable state will be revoked. Rollback cannot mean silently restoring a configuration that should no longer receive keys.
- Adapt observability: isolation deliberately restricts certain forms of inspection from the host. Useful logs, metrics and traces must be generated from within the workload, protected in transit and correlated with attestation events. Sufficient visibility must remain available for investigations without recreating general access to memory.
- Test failure modes: an unavailable attestation verifier, an expired certificate, an unknown measurement or loss of the key service may prevent startup. The choice between failing closed, degraded continuity and manual intervention must be documented, tested and aligned with recovery objectives.
Select the right use cases
Adoption is appropriate when the main threat genuinely includes the infrastructure operator or a compromised privileged layer, and when data must remain protected during computation. Sensitive processing on shared infrastructure, running a workload at a service provider, or stronger separation between operations teams and data owners are plausible cases. Conversely, a poorly controlled monolithic application that depends on memory inspection tools or lacks robust key management is a poor starting point. A pilot should assess system compatibility, performance impact, diagnostic options, portability and update procedures. Above all, it should demonstrate the complete path: measured startup, verified attestation, key release, recorded event, enforced revocation and tested recovery.
Confidential computing reduces a trust boundary; it does not remove it. The hardware, attestation mechanism, verifier, key-release policy and application code remain part of the security chain. Attestation evidence may support an assurance file, but it proves neither the absence of vulnerabilities nor the compliance of a processing activity. Before adopting this architecture, an organisation should be able to answer two questions plainly: which privileged access does it protect against, and which component can still obtain the data in clear text?