Microsoft Azure Attestation

  • Article

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. Les clients ont demandé à pouvoir vérifier indépendamment la localisation d’un ordinateur, la posture d’une machine virtuelle sur cet ordinateur et l’environnement dans lequel les enclaves s’exécutent sur cette machine virtuelle. Azure Attestation permet de répondre à ces demandes et à celles de bien d’autres clients.

Azure Attestation reçoit des preuves des entités de calcul, les transforme en un ensemble de revendications, les valide par rapport à des stratégies configurables et génère des preuves cryptographiques pour les applications basées sur les 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 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 régulièrement une approbation dans l’enclave et utiliser 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.

Notes

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 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é.

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 AMD SEV-SNP

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. Quand une CVM démarre, un rapport SNP contenant les mesures du microprogramme de la 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 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.

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 éloigner le fonctionnement de Microsoft de TCB (Truster Computing Base), les opérations critiques d’Azure Attestation telles que la validation de devis, la génération de jetons, l’évaluation de la stratégie et la signature de jeton 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

  1. Vérifiez si le jeton d’attestation est généré par Azure Attestation : 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. La partie de confiance peut récupérer les certificats de signature et vérifier la signature du jeton d’attestation. Pour plus d’informations, consultez des exemples de code
  2. Vérifier si Azure Attestation s’exécute à l’intérieur d’une enclave SGX : les certificats de signature de jeton incluent une citation SGX de l’environnement TEE dans lequel Azure Attestation s’exécute. Si la partie de confiance préfère 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 des exemples de code
  3. Valider la liaison du devis SGX Azure Attestation 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 Azure Attestation devis SGX. Pour plus d’informations, consultez des exemples de code
  4. Vérifiez si les mesures de code Azure Attestation correspondent aux valeurs publiées Azure : le Quote SGX incorporé dans les certificats de signature de jeton d’attestation inclut des mesures de code d’Azure Attestation, comme MRSIGNER. Si la partie de confiance souhaite vérifier si le Quote SGX appartient à Azure Attestation s’exécutant dans Azure, la valeur MRSIGNER peut être récupérée à partir du Quote SGX dans le certificat de signature de jeton d’attestation et comparée à la valeur fournie par l’équipe Azure Attestation. Si vous souhaitez effectuer cette validation, envoyez une demande sur page de support Azure. L’équipe Azure Attestation vous contacte quand nous prévoyons de permuter la valeur MRSIGNER.

Mrsigner de Azure Attestation est censé changer lors de la rotation des certificats de signature de code. L’équipe Azure Attestation suit le calendrier de déploiement ci-dessous pour chaque rotation de mrsigner :

i. L’équipe Azure Attestation informe la valeur MRSIGNER à venir avec une période de grâce de deux mois pour apporter des modifications de code pertinentes

ii. Après la période de grâce de deux mois, Azure Attestation commencera à utiliser la nouvelle valeur MRSIGNER

iii. Trois mois après la date de notification, Azure Attestation cessera d’utiliser l’ancienne valeur MRSIGNER

Prise en charge de la BCDR (continuité de l’activité et reprise d’activité)

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 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.

Étapes suivantes