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 soutenues par des modules de plateforme sécurisée (TPMs) en plus de la possibilité d’attester de l’état des environnements d’exécution approuvés (TEE), tels que les enclaves d’extensions Intel® Software Guard (SGX), les enclaves VBS (Virtualization-based Security), les modules de plateforme sécurisée (TPMs), le lancement approuvé 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 machine virtuelle 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 approuvé SEV-SNP protégé qui isole ce groupe de conteneurs du plan de contrôle de gestion des conteneurs et d’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 effectuer cette tâche avec le conteneur side-car SKR ou le compiler directement dans votre logique d’application. Le rapport matériel peut ensuite être échangé avec des Azure Attestation et un HSM managé ou un Azure Key Vault Premium (AKV) 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 conserver Microsoft opérationnellement hors de la base de calcul approuvée (TCB), les opérations critiques de Azure Attestation telles que la validation de devis, la génération de jetons, l’évaluation de stratégie et la signature de jetons sont déplacées dans des conteneurs confidentiels basés sur AMD SEV-SNP.
Pourquoi utiliser Azure Attestation
Azure Attestation demeure le premier choix pour l’attestation des environnements TEE, car il offre les avantages suivants :
- Cadre unifié permettant l’attestation de plusieurs environnements tels que 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 en cours d’utilisation avec l’implémentation dans un TEE.
- Service hautement disponible.
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 est en cours d’exécution à l’intérieur d’un conteneur SEV-SNP : 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 est 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 rapport. Pour obtenir des exemples de code, consultez SEV-SNP.
- Valider la liaison de Azure Attestation rapport TEE 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 de rapport du rapport Azure Attestation rapport TEE. Pour plus d’informations, consultez l’exemple de code.
- 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 utilisatrice peut vérifier que le rapport provient d’Azure Attestation en comparant des valeurs spécifiques récupérées à partir des éléments collatéraux du TEE dans le certificat de signature du jeton d’attestation avec les valeurs fournies par l’équipe Azure Attestation. Pour SEV-SNP, les données HOST_DATA doivent être validées. Pour plus d’informations, consultez l’exemple de code. Si vous souhaitez effectuer cette validation, envoyez une demande sur la page support Azure. L’équipe Azure Attestation vous contacte quand ces valeurs spécifiques sont planifiées pour la rotation.
- Ayez l’assurance de la provenance des builds - Azure Attestation s’intègre à Signing Transparency (MST) de Microsoft. MST enregistre les signatures de code dans un registre immuable et infalsifiable. Le service MST fournit des reçus vérifiables par chiffrement, conformes à SCITT, qui fournissent une visibilité claire sur les déploiements de Azure Attestation, ce qui renforce la confiance, l'auditabilité et la conformité réglementaire. Pour en savoir plus sur MST et sur la validation des artefacts de build, consultez À propos de Microsoft registre de transparence de signature.
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 ce calendrier de déploiement pour chaque rotation planifiée :
- 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.
- Après la période de grâce de deux mois, Azure Attestation commence à utiliser les nouvelles valeurs.
- 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é d’activité et de la reprise d’activité (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 d’intégrité est détériorée et définit le point de terminaison sur 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 sont bloquées. Les clients ne peuvent pas créer de fournisseurs d’attestation dans la région primaire.
- Toutes les opérations du plan de données, y compris les appels d’attestation et la configuration des stratégies, sont assurées par la région secondaire. Les clients peuvent continuer à travailler sur des opérations de plan de données avec l’URI d’origine correspondant à la région primaire.