Comment vérifier l’attestation matérielle dans Azure Confidential Computing

By Mirko Peters · 2026-10-26

Découvrez le fonctionnement de l’attestation matérielle Azure, comparez AMD SEV-SNP et Intel SGX, et apprenez à intégrer la vérification cryptographique dans vos pipelines CI/CD.

Automatically translated with AI from the original post. Read the English original

L’attestation matérielle Azure est un processus de vérification cryptographique essentiel qui prouve que votre environnement d’exécution de confiance est authentique et n’a pas été altéré avant le chargement des charges de travail sensibles. En évaluant les mesures de démarrage sécurisé et les clés matérielles par rapport aux référentiels de base de Microsoft et des fournisseurs, l’attestation comble le déficit de confiance entre les opérateurs cloud et la confidentialité des données des locataires.

Points clés

• L’attestation matérielle vérifie de manière cryptographique que votre environnement d’exécution de confiance (TEE) est authentique et non compromis.
• Le service d’attestation à distance évalue les mesures de la plateforme par rapport aux référentiels de sécurité avant de libérer les clés de déchiffrement.
• Les architectures AMD SEV-SNP et Intel SGX reposent toutes deux sur une vérification à distance pour garantir que les administrateurs cloud ne peuvent pas inspecter la mémoire en cours d’utilisation.
• Intégrer l’attestation dans vos pipelines de déploiement CI/CD automatise la validation de la confiance et empêche le démarrage de conteneurs altérés.
• Comprendre l’échange d’attestation est indispensable pour maintenir une posture zero-trust dans les environnements cloud hybrides modernes.

Le déficit de confiance dans les clouds publics

Lors de la migration de charges de travail sensibles vers le cloud public, les modèles de sécurité traditionnels protègent vos données en transit grâce à TLS et au repos grâce au chiffrement AES-256. Cependant, une vulnérabilité importante subsiste : les données en cours d’utilisation. Historiquement, chaque fois qu’un processeur exécutait du code, ces données devaient être déchiffrées et placées en clair dans la mémoire système. Dans un environnement cloud multilocataire, cela impliquait de faire confiance à l’hyperviseur, au fournisseur d’infrastructure cloud et à toute personne disposant d’un accès administrateur au matériel physique sous-jacent.

Azure Confidential Computing change ce paradigme en introduisant des environnements d’exécution de confiance (TEE) basés sur le matériel. Ces enclaves sécurisées et ces machines virtuelles isolées chiffrent le contenu de la mémoire à l’aide de clés matérielles dédiées, gérées directement par le silicium du processeur. Pourtant, disposer d’une pièce verrouillée ne résout que la moitié du problème. Il faut aussi un moyen de vérifier que la serrure n’a pas été crochetée, que la porte est correctement construite et qu’aucun logiciel non autorisé ne s’exécute à l’intérieur de la frontière sécurisée avant de remettre vos clés cryptographiques.

Fonctionnement de l’attestation à distance

L’attestation à distance est le mécanisme de vérification qui répond à une question fondamentale : comment savoir que l’environnement cloud sur lequel vous déployez est réellement sécurisé et non altéré ? Sans attestation, un attaquant disposant d’un accès au niveau de l’hyperviseur pourrait, en théorie, substituer un BIOS malveillant ou modifier le chargeur de démarrage, et intercepter vos clés de chiffrement au moment où elles sont chargées en mémoire.

Le processus d’attestation se déroule en un échange cryptographique rigoureux en plusieurs étapes :

Étape 1 : démarrage sécurisé et mesure de la plateforme

Lorsqu'une machine virtuelle confidentielle Azure ou une instance de conteneur démarre, le matériel et le micrologiciel enregistrent des mesures cryptographiques de chaque composant impliqué dans le processus de démarrage. Cela inclut le chargeur de démarrage, les images noyau et les éventuels disques RAM initiaux. Ces mesures sont stockées de manière sécurisée dans des registres matériels à l'intérieur du processeur, qui ne peuvent être modifiés ni par le système d'exploitation hôte ni par l'hyperviseur.

Étape 2 : génération du rapport cryptographique

Une fois la charge de travail initialisée dans le TEE, elle demande au processeur un rapport signé par le matériel. Le processeur signe ce rapport de mesures à l'aide d'une clé privée codée en dur et immuable, intégrée au silicium lors de la fabrication. Ce rapport joue le rôle d'un passeport numérique infalsifiable, qui représente l'état exact de la pile logicielle exécutée dans l'environnement isolé.

Étape 3 : évaluation par le service Azure Attestation

Le rapport matériel signé est transmis au service Microsoft Azure Attestation (MAA) ou à un vérificateur tiers compatible. Le service d'attestation compare les mesures reçues à une stratégie de référence de confiance définie par le locataire. Si le code exécuté dans l'enclave correspond à la stratégie autorisée, le service génère un jeton d'attestation.

Étape 4 : libération des secrets

Muni d'un jeton d'attestation valide, votre application peut demander en toute sécurité des identifiants de base de données, des certificats TLS ou des clés de chiffrement de données auprès d'un Managed HSM d'Azure Key Vault. Key Vault vérifie le jeton et ne libère les secrets que vers le TEE vérifié, garantissant qu'aucun environnement non autorisé ne peut jamais accéder à vos données en clair.

Différences d'architecture : AMD SEV-SNP et Intel SGX

Mettre en œuvre l'attestation suppose de comprendre l'architecture matérielle sous-jacente des nœuds Azure Confidential Computing que vous utilisez. Microsoft Azure prend en charge deux technologies matérielles principales, chacune gérant l'isolation et l'attestation de manière légèrement différente.

Intel Software Guard Extensions (SGX) se concentre sur l'isolation au niveau du processus. Au lieu de protéger une machine virtuelle entière, SGX permet aux développeurs d'isoler des portions de code et de structures de données spécifiques dans des enclaves à granularité fine. L'attestation avec SGX repose largement sur des enclaves de citation, qui empaquettent l'état matériel dans une citation vérifiable, laquelle est ensuite validée par l'infrastructure Enhanced Privacy ID (EPID) ou, plus récente, Data Center Attestation Primitives (DCAP) d'Intel.

À l'inverse, AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) protège des machines virtuelles entières. SEV-SNP garantit l'intégrité de la mémoire en s'appuyant sur un chiffrement de la mémoire assuré par le matériel, et empêche les hyperviseurs malveillants de remapper les adresses physiques des invités. Le rapport d'attestation généré par une VM AMD SEV-SNP inclut les configurations de stratégie de l'invité et les mesures de lancement, ce qui facilite le lift-and-shift d'applications conteneurisées existantes, sans avoir à réécrire le code pour des API spécifiques aux enclaves.

Mettre en œuvre l'attestation dans les pipelines CI/CD

Pour les architectes cloud et les ingénieurs DevOps, vérifier manuellement les rapports d'attestation n'est ni évolutif ni pratique. Pour bâtir une infrastructure cloud résiliente, l'attestation doit être profondément intégrée à vos pipelines de déploiement automatisés.

Les déploiements de conteneurs modernes s'exécutant sur Azure Kubernetes Service (AKS) avec des nœuds confidentiels peuvent utiliser des conteneurs sidecar ou des plugins de périphérique pour gérer automatiquement la négociation d'attestation. Lorsqu'un pod confidentiel démarre, le client d'attestation récupère le rapport matériel, le soumet au service Azure Attestation et met en cache le jeton obtenu. Ce n'est que lorsque le jeton est vérifié que le conteneur applicatif monte ses volumes sécurisés et commence à traiter les requêtes.

En intégrant les contrôles d'attestation à vos portes de validation des mises en production, vous garantissez que toute modification non autorisée du code, qu'elle soit accidentelle ou malveillante, invalide immédiatement les mesures matérielles. Le processus de libération des clés est alors interrompu, et la charge de travail compromise ne peut pas être lancée en production.

Conclusion : sécuriser les données en cours d'utilisation dès aujourd'hui

Azure Confidential Computing fournit le socle technique nécessaire pour protéger les charges de travail cloud sensibles contre les menaces modernes liées à l’infrastructure, mais l’isolation matérielle seule reste incomplète sans une vérification rigoureuse. En maîtrisant l’attestation à distance, les architectes cloud peuvent établir une confiance vérifiable entre le code du locataire et le matériel physique, afin que les données en cours d’utilisation soient aussi bien protégées que les données au repos et en transit. Pour écouter une analyse complète de ces concepts de sécurité cloud et explorer plus largement l’écosystème Microsoft 365 et Azure, écoutez l’épisode complet du podcast M365 FM.

Questions fréquentes

Quelle est la finalité première d’Azure Attestation ?

Azure Attestation est un service cloud unifié qui vérifie de manière cryptographique la fiabilité d’un environnement d’exécution de confiance (TEE) et valide l’intégrité du logiciel qui s’y exécute avant que des secrets ou des clés de chiffrement ne soient libérés.

Un administrateur cloud peut-il contourner l’attestation matérielle ?

Non. L’attestation matérielle repose sur des clés cryptographiques intégrées directement dans le silicium du processeur par le fabricant. Ces clés étant inaccessibles aux hyperviseurs et aux opérateurs cloud, les administrateurs ne peuvent pas forger un rapport d’attestation valide pour un environnement compromis.

Quelle est la différence entre l’attestation au niveau de la machine virtuelle et celle au niveau du processus ?

L’attestation au niveau de la machine virtuelle (par exemple AMD SEV-SNP) mesure et valide l’ensemble du système d’exploitation d’une machine virtuelle ainsi que ses charges de travail. L’attestation au niveau du processus (par exemple Intel SGX) isole et atteste des routines de code spécifiques ou des enclaves au sein d’un environnement de système d’exploitation standard.

Comment les jetons d’attestation s’intègrent-ils à Azure Key Vault ?

Une fois que la charge de travail confidentielle a réussi l’échange d’attestation, elle reçoit un jeton signé. Ce jeton peut être présenté à Azure Key Vault Managed HSM pour prouver l’intégrité de l’environnement, déclenchant la libération automatisée des clés de chiffrement et des identifiants de base de données.