Cet article fournit des réponses à certaines des questions les plus courantes sur Azure Attestation.
Si votre problème Azure n’est pas traité dans cet article, vous pouvez également envoyer une demande de support Azure sur la page du support Azure.
Qu’est-ce que le THIM (Trusted Hardware Identity Management) et son rôle dans l’attestation d’enclave ?
Trusted Hardware Identity Management (THIM) récupère la ligne de base an matière de sécurité Azure pour les nœudsInformatique confidentielle Azure (ACC) d’Intel et met en cache les données. Azure Attestation utilise également les informations mises en cache dans la validation des environnements d’exécution approuvés (TEE).
THIM est recommandé pour les raisons suivantes :
- Offre une haute disponibilité.
- Réduit la dépendance vis-à-vis des services hébergés à l’extérieur et de la connectivité Internet.
- Récupère périodiquement les versions les plus récentes des certificats Intel, des listes de révocation de certificats, des informations TCB (Trusted Computing Base) et de l’identité Quoting Enclave des nœuds ACC auprès d’Intel. Le service confirme la ligne de base de sécurité Azure à laquelle doit se référer Azure Attestation lors de la validation des TEE, ce qui réduit considérablement les échecs d’attestation dus à l’invalidation ou à la révocation des certificats Intel.
L’attestation SGX (Software Guard Extensions) est-elle prise en charge par Azure Attestation dans des environnements non-Azure ?
Non. L’attestation Azure dépend de la ligne de base de sécurité indiquée par THIM (Trusted Hardware Identity Management) pour valider les TEE. THIM est actuellement conçu pour prendre en charge uniquement les nœuds Informatique confidentielle Azure.
Quelles sont les validations effectuées par Azure Attestation pour attester des enclaves SGX ?
Pendant le processus d’attestation SGX, Azure Attestation effectue les validations suivantes :
- Valide si la racine approuvée d’un devis d’enclave signé appartient à Intel
- Valide si le devis TEE est conforme à la ligne de base de sécurité Azure, comme défini par THIM (Trusted Hardware Identity Management)
- Si le client a créé un fournisseur d’attestation et configuré une stratégie personnalisée, en plus des validations ci-dessus, Azure Attestation évalue le devis TEE par rapport à la stratégie d’attestation. Les clients peuvent utiliser les stratégies d’attestation pour définir des règles d’autorisation pour TEE et dicter les règles de délivrance pour la génération du jeton d’attestation.
Comment un vérificateur peut-il obtenir la documentation relative à l’attestation SGX prise en charge par Azure Attestation ?
En général, pour les modèles d’attestation ayant Intel comme racine de confiance, le client d’attestation parle aux API d’enclave pour extraire la preuve de l’enclave. Les API d’enclave appellent en interne le service caching Intel PCK pour extraire les certificats Intel du nœud à attester. Les certificats sont utilisés pour signer la preuve de l’enclave, générant ainsi une documentation pouvant être attestée à distance.
Le même processus peut être implémenté pour Azure Attestation. Toutefois, pour tirer parti des avantages offerts par Trusted Hardware Identity Management (THIM), après l’installation de la machine virtuelle ACC, il est recommandé d’installer la bibliothèque Azure DCAP. Selon l’accord conclu avec Intel, lors de l’installation de la bibliothèque Azure DCAP, les demandes de génération de preuve d’enclave sont redirigées du service caching Intel PCK vers THIM. La bibliothèque Azure DCAP est prise en charge dans les environnements Windows et Linux.
Comment puis-je passer à Azure Attestation à partir d’autres modèles d’attestation SGX ?
- Après l’installation de la machine virtuelle Informatique confidentielle Azure, installez la bibliothèque Azure DCAP (Windows/Linux) pour tirer parti des avantages offerts par Trusted Hardware Identity Management (THIM).
- Un client d’attestation à distance doit être créé pour pouvoir récupérer la preuve de l’enclave et envoyer des demandes à Azure Attestation. Référez-vous aux exemples de code.
- Les demandes d’attestation peuvent être envoyées au point de terminaison de l’API REST des fournisseurs par défaut ou des fournisseurs d’attestations personnalisés.
- Dans la version d’API 2018-09-01-preview, le client doit envoyer un jeton d’accès Microsoft Entra avec la preuve au point de terminaison de l’API d’attestation SGX. Le jeton d’accès Microsoft Entra n’est pas un paramètre obligatoire pour effectuer l’attestation SGX dans la version d’API 2020-10-01.
Comment la partie de confiance peut-elle vérifier l’intégrité du jeton d’attestation et confirmer qu’Azure Attestation est exécuté dans une enclave ?
Le jeton d’attestation généré par Azure Attestation est signé à l’aide d’un certificat auto-signé. Les certificats de signature sont exposés via un point de terminaison de métadonnées OpenID. La partie de confiance peut récupérer les certificats de signature à partir de ce point de terminaison et vérifier la signature du jeton d’attestation. Le certificat de signature comprend également la citation SGX du TEE dans lequel Azure Attestation est exécuté. Si la partie de confiance préfère également vérifier si Azure Attestation s’exécute au sein d’une enclave SGX valide, la citation SGX peut être récupérée à partir du certificat de signature et validée localement. Pour plus d’informations, consultez les exemples de code.
Quelle est la durée de validité d’un jeton d’attestation ?
La durée de validité du jeton d’attestation est de 8 heures. Il n’existe actuellement aucune provision pour personnaliser la valeur.
Comment identifier le certificat à utiliser pour la vérification de la signature dans le point de terminaison de métadonnées OpenID ?
Plusieurs certificats exposés dans le point de terminaison de métadonnées OpenID correspondent à différents cas d’utilisation (par exemple, l’attestation SGX) pris en charge par Azure Attestation. Conformément aux critères spécifiés par la norme RFC 7515, le certificat dont l’ID de clé (kid) correspond au paramètre Kid dans l’en-tête du jeton d’attestation doit être utilisé pour la vérification de la signature. Si aucune correspondance kid n’est trouvée, vous devez essayer tous les certificats exposés par le point de terminaison de métadonnées OpenID.
Est-il possible pour la partie de confiance de partager des secrets avec les environnements d’exécution approuvés (TEE) validés ?
Au moment de la création de preuves TEE, le code exécuté à l’intérieur de l’environnement d’exécution de confiance peut inclure des informations arbitraires dans la preuve. Par exemple, le TEE peut créer une ou plusieurs paires de clés asymétriques, sérialiser les composants de clé publique de ces paires de clés en tant que chaîne JSON JWKS et inclure la chaîne JSON JWKS dans la preuve TEE en tant que RunTimeData { citation, chaîne JSON JWKS }. Azure Attestation vérifie si la synthèse SHA256 de RuntimeData correspond à la valeur inférieure de 32 octets de l’attribut « données de rapport » du devis. Après avoir évalué la preuve TEE, Azure Attestation génère JWT avec le JWKS disponible en tant que revendication nommée « clés » sous la revendication « x-ms-runtime ». RunTimeData peut être utilisé par la partie de confiance pour établir un canal sécurisé et transmettre en toute sécurité des données au TEE.
Où Azure Attestation stocke-t-il les données client ?
Azure Attestation stocke les données client au repos, au cours du traitement et de la réplication à des fins de continuité d’activité et reprise d’activité à l’intérieur de la zone géographique dans laquelle le client déploie l’instance de service.