Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Microsoft Azure Attestation est une solution unifiée permettant de vérifier à distance la fiabilité d’une plateforme et l’intégrité des ressources binaires qui s’y exécutent. Le service prend en charge l’attestation des plateformes reposant sur des modules de plateforme sécurisée (TPM), en plus de la possibilité d’attester de l’état des environnements d’exécution de confiance (TEE), tels que les enclaves Intel® Software Guard Extensions (SGX), les enclaves Sécurité basée sur la virtualisation (VBS), les modules de plateforme sécurisé (TPM), le lancement fiable pour les machines virtuelles Azure et les machines virtuelles confidentielles Azure.
L’attestation est un processus permettant de démontrer que les binaires logiciels ont été correctement instanciés sur une plateforme approuvée. Les parties de confiance distantes peuvent alors avoir l’assurance que seuls des logiciels de ce type s’exécutent sur du matériel approuvé. Azure Attestation est un framework et un service orientés client unifiés pour l’attestation.
Azure Attestation permet des paradigmes de sécurité de pointe tels que l’informatique confidentielle Azure et la protection de périphérie intelligente. Le service reçoit des preuves d’entités de calcul, les transforme en un ensemble de revendications, les valide par rapport aux stratégies configurables et produit des preuves de chiffrement pour les applications basées sur des revendications (par exemple, les parties de confiance et les autorités d’audit).
Azure Attestation prend en charge l’attestation de plateforme et l’attestation d’invité des machines virtuelles confidentielles basées sur AMD SEV-SNP. L’attestation de plateforme basée sur Azure Attestation se produit automatiquement pendant le chemin de démarrage critique des machines virtuelles confidentielles, sans aucune action du client. Pour plus d’informations sur l’attestation d’invité, consultez Annonce de la disponibilité générale de l’attestation d’invité pour les machines virtuelles confidentielles.
Cas d’utilisation
Azure Attestation fournit des services d’attestation complets pour plusieurs environnements et des cas d’usage distincts.
Attestation SEV-SNP d'AMD sur des machines virtuelles confidentielles
La machine virtuelle confidentielle Azure est basée sur des processeurs AMD avec la technologie SEV-SNP. Une CVM offre une option de chiffrement de disque de système d’exploitation de machine virtuelle avec des clés gérées par la plateforme ou des clés gérées par le client et lie les clés de chiffrement de disque au module de plateforme sécurisée (TPM) de la machine virtuelle. Lorsqu’une machine virtuelle CVM démarre, le rapport SNP contenant les mesures de microprogramme de machine virtuelle invitée est envoyé à Azure Attestation. Le service valide les mesures et émet un jeton d’attestation qui est utilisé pour émettre des clés à partir de Managed-HSM ou Azure Key Vault. Ces clés sont utilisées pour déchiffrer l’état vTPM de la machine virtuelle invitée, déverrouiller le disque du système d’exploitation et démarrer la CVM. Le processus d’attestation et de publication de clés s’effectue automatiquement au démarrage de chaque CVM, et le processus garantit que la CVM démarre uniquement en cas de réussite de l’attestation du matériel.
Attestation AMD SEV-SNP sur des conteneurs confidentiels
Les conteneurs confidentiels Azure sont basés sur des processeurs AMD avec la technologie SEV-SNP. Les conteneurs confidentiels, hébergés sur Azure Container Instances et sur Azure Kubernetes Service (en préversion) offrent la possibilité d’exécuter des groupes de conteneurs dans un environnement d’exécution de confiance protégé SEV-SNP qui isole ce groupe de conteneurs du plan de contrôle de gestion des conteneurs et des autres conteneurs en cours d’exécution. L’attestation dans des conteneurs confidentiels implique la récupération du rapport sur l’attestation matérielle AMD directement auprès du processeur. Vous pouvez réaliser cette opération avec notre conteneur sidecar SKR ou l'intégrer directement dans la logique de votre application. Le rapport matériel peut ensuite être intégré au service Azure Attestation et au service HSM managé ou à Azure Key Vault (AKV) Premium pour récupérer des secrets. Vous pouvez également fournir le rapport matériel de votre propre système de coffre de clés selon vos besoins.
Attestation de lancement fiable
Les clients Azure peuvent empêcher des infections de bootkit et de rootkit en activant le lancement fiable pour leurs machines virtuelles. Lorsque la machine virtuelle est à démarrage sécurisé et que vTPM est activé avec l’extension d’attestation d’invité installée, les mesures de vTPM sont soumises régulièrement à l’attestation Azure pour la surveillance de l’intégrité du démarrage. Un échec d’attestation indique un logiciel malveillant potentiel qui est exposé aux clients via Microsoft Defender pour le cloud, via des alertes et des recommandations.
Attestation TPM
L’attestation basée sur le module de plateforme sécurisée (TPM) est essentielle pour fournir la preuve de l’état d’une plateforme. Le TPM joue le rôle de racine de confiance et de coprocesseur de sécurité pour fournir la validité du chiffrement aux mesures (preuve). Les appareils disposant d’un TPM peuvent s’appuyer sur l’attestation pour prouver que l’intégrité du démarrage n’est pas compromise, et utiliser les revendications pour détecter les capacités d’activation des états de fonctionnalités au démarrage.
Les applications clientes peuvent être conçues pour tirer parti de l’attestation TPM en déléguant les tâches sensibles à la sécurité afin qu’elles aient lieu uniquement après qu’une plateforme a été validée comme étant sécurisée. De telles applications peuvent ensuite utiliser Azure Attestation pour établir régulièrement une approbation dans la plateforme et utiliser sa capacité à accéder aux données sensibles.
Attestation d’enclave SGX
Intel® Software Guard Extensions (SGX) fait référence à l’isolation matérielle, qui est prise en charge sur certains modèles de processeur Intel. SGX permet au code de s’exécuter dans des compartiments assainis appelés enclaves SGX. Les autorisations d’accès et de mémoire sont ensuite gérées par le matériel pour garantir une surface d’attaque minimale avec une isolation appropriée.
Les applications clientes peuvent être conçues pour tirer parti des enclaves SGX, en y déléguant l’exécution des tâches sensibles à la sécurité. De telles applications peuvent ensuite utiliser Azure Attestation pour établir de manière routinière la confiance dans l’enclave et confirmer sa capacité à accéder aux données sensibles.
Les processeurs Intel® Xeon® Scalable prennent uniquement en charge les solutions d’attestation basées sur ECDSA pour l’attestation à distance des enclaves SGX. Avec le modèle d’attestation basé sur ECDSA, Azure Attestation prend en charge la validation des processeurs Intel® Xeon® E3 et des plateformes de serveur Intel® Xeon® évolutives.
Remarque
Pour effectuer l’attestation des plateformes de serveur à processeur Intel® Xeon® Scalable à l’aide d’Azure Attestation, les utilisateurs doivent installer Azure DCAP version 1.10.0 ou supérieure.
Attestation d'Open Enclave
Open Enclave (OE) est un ensemble de bibliothèques ciblant la création d’une seule abstraction d’enclavement unifiée permettant aux développeurs de créer des applications basées sur un environnement TEE. Il offre un modèle d’application sécurisé universel qui réduit les spécificités de la plateforme. Microsoft le considère comme une étape essentielle pour la démocratisation des technologies d’enclave basée sur le matériel, telles que SGX, et leur adoption croissante sur Azure.
OE standardise des exigences spécifiques en matière de vérification d’une preuve d’enclave. Cela fait d’OE un consommateur d’Azure Attestation approprié.
Azure Attestation s’exécute dans un environnement TEE
Azure Attestation est essentiel aux scénarios d’informatique confidentielle, car il effectue les actions suivantes :
- Il vérifie si la preuve de l’enclave est valide.
- Il évalue la preuve de l’enclave par rapport à une stratégie définie par le client.
- Il gère et stocke les stratégies propres au locataire.
- Il génère et signe un jeton qui est utilisé par les parties de confiance pour interagir avec l’enclave.
Pour garder Microsoft opérationnellement en dehors de la TCB (Trusted Computing Base), les opérations critiques d'Azure Attestation telles que la validation des attestations, la génération de jetons, l'évaluation de la stratégie et les signatures de jetons sont déplacées dans une enclave SGX.
Pourquoi utiliser Azure Attestation
Azure Attestation demeure le premier choix pour l’attestation des environnements TEE, car il offre les avantages suivants :
- Framework unifié pour l’attestation de plusieurs environnements comme les TPM, les enclaves SGX et les enclaves VBS.
- Permet la création de fournisseurs d’attestation personnalisés et la configuration de stratégies pour limiter la génération de jetons.
- Protège ses données pendant l’utilisation avec l’implémentation dans une enclave SGX ou une machine virtuelle confidentielle basée sur AMD SEV-SNP.
- Service haute disponibilité
Comment établir une confiance avec Azure Attestation
- Vérifiez si le jeton d’attestation est généré par Azure Attestation : un jeton d’attestation généré par Azure Attestation est signé à l’aide d’un certificat auto-signé. L’URL des certificats de signature est exposée via un point de terminaison de métadonnées OpenID. Une partie de confiance peut récupérer le certificat de signature et effectuer la vérification de signature du jeton d’attestation. Pour plus d’informations, consultez les exemples de code .
- Vérifiez si Azure Attestation s’exécute à l’intérieur d’une enclave SGX : les certificats de signature de jeton incluent des informations sur l’environnement TEE à l’intérieur duquel Azure Attestation s’exécute. Cette garantie TEE peut être une cotation SGX ou un rapport SEV-SNP. La partie de confiance peut vérifier si Azure Attestation s’exécute à l’intérieur d’un TEE valide en validant localement le devis ou le rapport. Pour plus d’informations, consultez les exemples de code – SGX, SEV-SNP
- Valider la liaison d’un devis AZURE Attestation SGX avec la clé qui a signé le jeton d’attestation – La partie de confiance peut vérifier si le hachage de la clé publique qui a signé le jeton d’attestation correspond au champ de données du rapport Azure Attestation TEE. Pour plus d’informations, reportez-vous ici.
- Vérifiez si les mesures de code Azure Attestation correspondent aux valeurs publiées par Azure : la garantie TEE incorporée dans les certificats de signature de jeton d’attestation inclut des mesures de code TEE d’Azure Attestation. Une partie de confiance peut valider que le devis ou le rapport appartient à Azure Attestation en comparant des valeurs spécifiques récupérées à partir de la garantie TEE dans le certificat de signature de jeton d’attestation avec les valeurs fournies par l’équipe Azure Attestation. Pour SGX, MRSIGNER doit être validé. Pour SEV-SNP, les données HOST_DATA doivent être validées. Pour plus d’informations, reportez-vous ici. Si vous souhaitez effectuer cette validation, envoyez une demande sur la page de support Azure. L’équipe Azure Attestation vous contacte quand ces valeurs spécifiques sont planifiées pour la rotation.
Les valeurs identifiant les instances Azure Attestation valides sont censées changer lorsque les certificats de signature de code sont pivotés ou lorsque les mises à jour de sécurité nécessitent de nouvelles versions de stratégie. L’équipe Azure Attestation suit le calendrier de déploiement ci-dessous pour chaque rotation planifiée :
i. L’équipe Azure Attestation informe les consommateurs des nouvelles valeurs avec une période de grâce de deux mois pour implémenter des modifications de code pertinentes
ii. Après la période de grâce de deux mois, Azure Attestation commence à utiliser les nouvelles valeurs.
iii. Trois mois après la date de notification, Azure Attestation cesse d’utiliser les anciennes valeurs.
Pour les rotations non planifiées, y compris celles requises par les mises à jour de sécurité, l’équipe Azure Attestation communique de nouvelles valeurs avec une période de grâce d’un mois.
Prise en charge de la continuité des activités et de la reprise après sinistre (BCDR).
La continuité d’activité et reprise d’activité (BCDR) pour Azure Attestation vous permet de limiter les interruptions de service résultant de problèmes de disponibilité ou d’événements de sinistre importants dans une région.
Les clusters déployés dans deux régions fonctionnent indépendamment dans des conditions normales. Dans le cas d’une défaillance ou d’une panne d’une région, voici ce qui se produit :
- La BCDR d’Azure Attestation fournit un basculement continu dans lequel les clients n’ont pas besoin d’effectuer d’étape supplémentaire pour la récupération.
- Azure Traffic Manager pour la région détecte que la sonde de santé est détériorée et redirige le point de terminaison vers la région associée.
- Les connexions existantes ne fonctionnent pas et reçoivent une erreur serveur interne ou connaissent des problèmes de délai d’attente.
- Toutes les opérations du plan de contrôle seront bloquées. Les clients ne sont pas en mesure de créer des fournisseurs d’attestations dans la région primaire.
- Toutes les opérations de plan de données, y compris les appels d’attestation et la configuration de stratégie, seront traitées par la région secondaire. Les clients peuvent continuer à travailler sur les opérations de plan de données avec l’URI d’origine correspondant à la région primaire.