Informatique confidentielle pour les charges de travail classifiées : enclaves et attestation

Les données classifiées ont historiquement été protégées dans deux de leurs trois états. Le chiffrement au repos les protège sur le disque ; le chiffrement en transit les protège sur le réseau. Le troisième état – les données en cours d'utilisation, déchiffrées dans les registres CPU et la RAM afin d'être réellement traitées – a toujours été le maillon faible. Tout code disposant de privilèges suffisants sur l'hôte, y compris le système d'exploitation, l'hyperviseur et un opérateur cloud disposant d'un accès physique au bus mémoire, peut lire ce texte en clair. L'informatique confidentielle comble cette lacune en exécutant la charge de travail dans un environnement d'exécution de confiance (TEE) isolé par le matériel, où le CPU maintient la mémoire chiffrée et illisible pour tout ce qui se trouve en dehors de l'enclave. Pour les charges de travail classifiées, cela modifie qui doit être digne de confiance – et c'est précisément le but recherché.

Le problème des données en cours d'utilisation et le modèle de menace de l'informatique confidentielle

La prémisse fondamentale de l'informatique confidentielle est une base de calcul de confiance réduite. Dans un déploiement cloud conventionnel, le locataire est contraint de faire confiance à toute la pile sous-jacente à l'application : le noyau du système d'exploitation invité, l'hyperviseur, le firmware de l'hôte, le plan de contrôle du cloud et les personnes qui exploitent le centre de données. Chacun de ces éléments constitue un chemin vers le texte en clair pendant l'exécution de la charge de travail. Pour une charge de travail Secret ou à compartiments sensibles, cette surface de confiance est inacceptable.

Un TEE inverse le modèle. Le CPU lui-même applique une frontière d'isolation, chiffrant la mémoire de l'enclave avec des clés générées et conservées dans le module de sécurité matériel du processeur et jamais exposées aux logiciels. Le système d'exploitation hôte peut ordonnancer l'enclave, lui allouer des pages et l'arrêter – mais il ne peut pas lire ce qu'elle contient. Un hyperviseur compromis par un attaquant, ou un administrateur malveillant qui connecte un débogueur ou vide la mémoire physique, ne voit que du texte chiffré. La frontière de confiance se réduit à deux éléments : le matériel du fournisseur de silicium et le code que vous chargez délibérément dans l'enclave.

C'est précisément cette propriété qui permet aux organisations de défense d'envisager d'héberger des charges de travail sensibles sur une infrastructure qu'elles ne contrôlent pas physiquement. Elle ne rend pas en elle-même une région commerciale accréditée pour les données classifiées – cela nécessite l'ensemble complet des contrôles analysés dans notre étude de l'architecture zéro confiance pour les réseaux militaires – mais elle retire l'opérateur de la frontière de confiance pour les données en cours d'utilisation, ce qui modifie substantiellement le calcul des risques.

Environnements d'exécution de confiance : SGX, SEV-SNP, TDX et CCA

Il existe deux familles architecturales de TEE, et le choix entre elles est la première décision de conception la plus lourde de conséquences.

Enclaves au niveau du processus (Intel SGX). Software Guard Extensions délimite une petite région de mémoire définie par l'application – l'enclave – au sein d'un processus et l'isole de tout le reste, y compris du noyau. La base de calcul de confiance est minimale : seul le code placé dans l'enclave est considéré comme fiable, pas l'OS environnant. Le coût est que l'application doit être partitionnée en deux moitiés de confiance et non fiable, avec une interface d'appel contrôlée entre elles, et la mémoire de l'enclave est contrainte. SGX est le bon outil lorsque vous souhaitez la surface d'attaque la plus petite possible autour d'une routine spécifique de gestion des secrets – un service d'encapsulation de clés, un signataire cryptographique, un petit moteur de politique.

Confidentialité au niveau de la VM (AMD SEV-SNP, Intel TDX, Arm CCA). Secure Encrypted Virtualization with Secure Nested Paging, Trust Domain Extensions et Arm's Confidential Compute Architecture Realms protègent tous une machine virtuelle entière. La mémoire de l'invité est chiffrée de manière transparente et protégée en intégrité, et l'hyperviseur est retiré de la frontière de confiance, mais la charge de travail interne s'exécute sans modification. Une application classifiée existante peut être migrée vers une VM confidentielle sans modification du code. La base de calcul de confiance est plus grande – elle inclut tout l'OS invité – mais le coût d'adoption est considérablement plus faible. Pour la plupart des charges de travail de défense migrées plutôt qu'écrites depuis zéro, la confidentialité au niveau de la VM est le choix pragmatique.

SEV-SNP et TDX ont ajouté une fonctionnalité qui manquait à la première génération de SGX et qui est cruciale pour les données classifiées : la protection de l'intégrité de la mémoire, se défendant contre un attaquant qui rejoue ou remappe des pages chiffrées plutôt que de simplement les lire. Tout TEE sélectionné pour un usage classifié doit fournir à la fois la confidentialité et l'intégrité ; la confidentialité seule laisse la charge de travail ouverte aux attaques actives de corruption mémoire depuis l'hôte.

Attestation distante : prouver l'enclave avant de lui faire confiance

L'isolation matérielle est nécessaire mais pas suffisante. La partie qui détient les données classifiées – ou la clé qui les déchiffre – a besoin de la preuve que l'enclave avec laquelle elle s'apprête à communiquer est un matériel TEE authentique exécutant exactement le code attendu, et non un émulateur, une image altérée ou une plateforme à microcode rétrogradé prétendant être sécurisée. Cette preuve est l'attestation distante, et c'est le mécanisme qui rend l'informatique confidentielle digne de confiance plutôt que simplement plausible.

Fonctionnement d'un flux d'attestation

Lorsqu'une enclave démarre, le CPU mesure le code et la configuration chargés dans un registre matériel et, sur demande, produit un attestat signé : une structure contenant ces mesures, les numéros de version de sécurité du TEE et une signature remontant jusqu'à une clé fusionnée dans le silicium lors de la fabrication. L'enclave envoie cet attestat à un vérificateur – un service que le propriétaire des données contrôle ou approuve. Le vérificateur valide la chaîne de signatures jusqu'au certificat racine du fournisseur, confirme que la plateforme utilise un microcode actuel et non révoqué, et compare les mesures déclarées avec une liste d'autorisation du code qu'il est disposé à approuver. Ce n'est que si tous les contrôles sont passés que le vérificateur autorise l'étape suivante.

La discipline d'ingénierie critique ici est la mesure reproductible. L'enclave ou l'image invitée doit être construite de manière déterministe afin que sa mesure soit identique bit par bit à chaque fois, car la politique d'attestation est une liste d'autorisation de valeurs de mesure exactes. Une construction non reproductible signifie une mesure qui change constamment, ce qui oblige les opérateurs à commettre le péché cardinal d'assouplir la politique jusqu'à ce qu'elle accepte presque tout – annulant ainsi l'objectif visé. Traitez la mesure de lancement comme un artefact de version, enregistré et versionné aux côtés des versions de firmware et de microcode dont il dépend.

La politique d'attestation comme véritable frontière de sécurité

Le matériel effectue la cryptographie, mais la politique prend les décisions, et une politique faible annule un matériel solide. Une politique d'attestation de qualité défense stipule explicitement : quels types de TEE sont acceptés ; la version minimale de la base de calcul de confiance, avec des vérifications du numéro de version de sécurité qui rejettent le microcode rétrogradé après une divulgation de vulnérabilité ; l'ensemble exact des mesures de code autorisées ; et des exigences de fraîcheur afin qu'un ancien attestat ne puisse pas être rejoué. Le mode d'échec le plus courant dans les déploiements réels n'est pas une enclave défectueuse – c'est une politique trop permissive qui accepte des mesures qu'elle ne devrait pas, ou qui ne vérifie jamais le statut de révocation de la plateforme. L'attestation n'est aussi bonne que les règles appliquées par le vérificateur.

Libération des clés : lier les secrets à un environnement vérifié

L'attestation devient opérationnellement utile lorsqu'elle conditionne l'accès aux secrets. Le schéma est la libération de clés liée à l'attestation : le service de gestion des clés est configuré de sorte qu'une clé de chiffrement de données classifiées n'est communiquée qu'après confirmation d'une attestation réussie par le vérificateur. L'enclave demande la clé, présente des preuves récentes et le KMS communique la clé encapsulée dans un canal terminé à l'intérieur du TEE, de sorte que la clé en clair n'existe jamais en dehors de l'enclave. Un hôte non attesté, une plateforme rétrogradée ou une image altérée ne reçoit tout simplement jamais le matériel nécessaire pour déchiffrer quoi que ce soit.

Cela inverse la relation habituelle entre identité et autorisation. Au lieu de communiquer une clé parce qu'un appelant présente un identifiant qui pourrait être volé, la clé est communiquée parce que l'environnement d'exécution a prouvé cryptographiquement son intégrité. Pour les charges de travail qui doivent faire circuler des données entre des frontières, cela se compose naturellement avec les contrôles décrits dans notre article sur les solutions interdomaines pour la défense : l'enclave effectuant le transfert peut être tenue d'attester avant de se voir confier des données d'un niveau de classification supérieur.

Schémas de déploiement cloud pour les charges de travail classifiées

Toutes les grandes régions cloud gouvernementales exposent désormais des SKU de VM confidentielles basées sur SEV-SNP ou TDX, ainsi que des services gérés d'enclave et d'attestation pour les accompagner. Trois schémas de déploiement reviennent dans les programmes classifiés et sensibles.

Traitement confidentiel des données. La charge de travail qui touche aux données classifiées – un système analytique, un moteur de fusion, un service d'inférence de modèle – s'exécute entièrement dans des VM confidentielles. Les données arrivent chiffrées, les clés ne sont communiquées qu'aux enclaves attestées et les données déchiffrées n'existent que dans la mémoire protégée. C'est le schéma de migration directe : les applications existantes bénéficient d'une protection des données en cours d'utilisation avec des modifications minimales, retirant l'opérateur cloud de la frontière de confiance sans restructuration.

Gestion et courtage confidentiels des clés. Une petite enclave de type SGX agit comme ancre de confiance : elle détient les clés d'encapsulation, effectue la vérification de l'attestation pour d'autres charges de travail et gère les clés de chiffrement des données vers des VM confidentielles attestées. Concentrer la logique la plus sensible dans une enclave minimale maintient la base de calcul de confiance pour la gestion des clés à un niveau réduit, même lorsque les charges de travail principales s'exécutent en tant que VM confidentielles complètes.

Calcul confidentiel multipartite et en coalition. Deux organisations qui ne peuvent pas partager de données brutes – des partenaires de coalition, ou des agences à différents niveaux de classification – contribuent chacune des entrées chiffrées à une VM confidentielle qui calcule un résultat conjoint. Puisqu'aucune partie, y compris l'hôte, ne peut lire les entrées des autres, l'enclave devient un terrain neutre. L'attestation permet à chaque contributeur de vérifier exactement quel code traitera ses données avant de les communiquer.

Risques résiduels et discipline opérationnelle

L'informatique confidentielle réduit considérablement la surface de menace mais ne l'élimine pas. Les attaques par canal auxiliaire contre les TEE sont un domaine de recherche actif, et plusieurs ont nécessité des correctifs de microcode – c'est pourquoi l'application des numéros de version de sécurité dans la politique d'attestation n'est pas facultative. Le code de l'enclave lui-même se trouve à l'intérieur de la frontière de confiance, donc une vulnérabilité là est une vulnérabilité dans la charge de travail protégée ; une base de calcul de confiance minimale limite le rayon d'explosion. Et la chaîne d'approvisionnement en silicium est, en fin de compte, approuvée. Aucun de ces points ne remet en cause le modèle, mais ils définissent la discipline opérationnelle : corriger le microcode rapidement, maintenir l'enclave petite, réattester en continu plutôt qu'uniquement au lancement, et enregistrer chaque décision d'attestation dans un stockage immuable à des fins d'audit.

L'informatique confidentielle est un contrôle solide au sein d'une architecture accréditée plus large, et non un substitut à l'accréditation. Elle s'inscrit aux côtés des contrôles de résidence des données, d'une autorisation d'exploitation au niveau d'impact approprié, d'une gestion des clés auditée et des contrôles de réseau zéro confiance et interdomaines couverts ailleurs dans cette série. Ce qu'elle fournit de manière unique est une protection auditable pour les données en cours d'utilisation – l'état qui était, jusqu'à récemment, simplement supposé être exposé.