Contexte et principe du Confidential Computing
Amazon Web Services propose désormais le Confidential Computing directement intégré aux instances EC2. Cette offre repose sur la capacité du matériel à chiffrer la mémoire vive et les volumes EBS de façon permanente, de sorte que les données restent protégées même lorsqu’elles sont traitées. Le principe repose sur l’isolation physique du processeur et sur des clés de chiffrement gérées par le matériel, ce qui empêche tout accès non autorisé aux données en cours d’utilisation.
Architecture Nitro et mécanisme d’isolation
Le socle technique s’appuie sur le Nitro Hypervisor, un composant minimaliste qui remplace l’hyperviseur traditionnel. Le Nitro Hypervisor ne possède aucun accès direct au système d’exploitation invité et ne propose aucune interface de connexion pour un opérateur. Ainsi, « no operator access by design » signifie que ni les équipes AWS ni un tiers ne peuvent se connecter aux hôtes Nitro, lire la mémoire d’une instance ou intercepter les blocs chiffrés d’EBS. Toutes les interactions passent par des APIs authentifiées et auditées, limitées à des fonctions de gestion d’infrastructure (démarrage, arrêt, redimensionnement) qui ne permettent pas l’extraction de données sensibles.
Cette architecture repose sur la séparation des fonctions de contrôle (CPU, réseau, stockage) dans des cartes dédiées, chacune dotée de son propre firmware signé. Le chiffrement de la mémoire utilise les extensions Intel SGX ou AMD SEV, selon le type d’instance, garantissant que les clés ne quittent jamais le processeur. Le modèle de confiance repose donc sur la chaîne d’approvisionnement matérielle et sur la validation cryptographique du firmware Nitro.
Implications de performance et limites opérationnelles
Le communiqué indique que le Nitro Hypervisor offre une performance proche du bare‑metal pour la plupart des charges de travail. Cette affirmation s’appuie sur le fait que le Nitro ne réalise pas de virtualisation complète, mais agit comme un intermédiaire de très faible empreinte, limitant les cycles CPU consommés par la couche d’isolation. En pratique, les benchmarks internes d’AWS montrent que le débit réseau, la latence d’E/S et le taux d’instructions par seconde restent comparables à ceux d’une instance non‑chiffrée, ce qui confirme que l’isolation n’entraîne pas de pénalité de bande passante notable.
Malgré ces avantages, la solution impose des contraintes. Premièrement, le chiffrement de la mémoire augmente la consommation d’énergie du processeur, ce qui peut affecter le coût total de possession sur de longues périodes. Deuxièmement, la dépendance aux APIs auditées signifie que toute fonctionnalité non exposée par l’API ne pourra pas être automatisée, limitant certaines pratiques DevOps avancées. Enfin, la transparence sur les algorithmes de chiffrement et les processus de mise à jour du firmware reste limitée, ce qui complique les évaluations de conformité pour des secteurs fortement régulés.
