Protéger la propriété intellectuelle sur les machines virtuelles Azure avec une version de clé sécurisée contrôlée par attestation

Cet article décrit un modèle réutilisable pour protéger une ressource sensible( par exemple, les pondérations de modèle Machine Learning propriétaires, un jeu de données sous licence ou une configuration secrète) qui doivent s'exécuter sur une machine virtuelle à l'intérieur de l'abonnement Azure d'une autre personne. La partie propriétaire de la ressource ( l’éditeur) est différente de la partie propriétaire de l’abonnement où la machine virtuelle s’exécute (le consommateur). Le client dispose d’un accès complet au plan de contrôle Azure pour cette machine virtuelle, mais ne doit pas pouvoir extraire l’actif.

Le modèle combine plusieurs fonctionnalités Azure documentées en couches de défense. Son cœur cryptographique repose sur la libération sécurisée de clés (SKR) contrôlée par attestation d’Azure Key Vault, conditionnée par l’attestation vTPM de Trusted Launch. Il ne nécessite pas d’informatique confidentielle, bien que l’informatique confidentielle puisse être ajoutée en tant que couche facultative lorsque le modèle de menace le demande.

Note

Secure Key Release est une fonctionnalité du plan de données d’Azure Key Vault Premium et de Managed HSM. Il vérifie un jeton Microsoft Azure Attestation (MAA) signé au regard de la stratégie de divulgation d’une clé, indépendamment du type de calcul. Les machines virtuelles confidentielles sont une source courante de ces jetons, mais elles ne sont pas requises : les machines virtuelles de lancement approuvé produisent également des jetons MAA. Pour connaître les exigences relatives aux jetons, consultez la grammaire de la stratégie de publication sécurisée des clés d’Azure Key Vault.

Scénario et modèle de menace

Un éditeur distribue une charge de travail basée sur une machine virtuelle dans l'abonnement d'un consommateur (par exemple, via Place de marché Azure en tant que modèle de solution ou en tant qu'image partagée). La charge de travail nécessite une clé de déchiffrement pour déverrouiller la ressource de l’éditeur à l’exécution. La clé ne doit être divulguée que pour l’image authentique et non modifiée de l’éditeur, jamais directement à l’utilisateur final, ni pour une image falsifiée ou substituée.

Le modèle se défend contre deux directions distinctes des menaces. Les nommer explicitement est ce qui rend les décisions de superposition claires.

Direction des menaces Adversaire Capacités Défendu par
A — le consommateur (propriétaire de machine virtuelle/d’abonnement) Le propriétaire de l’abonnement disposant d’un contrôle d’accès en fonction du rôle (Azure RBAC) complet sur l’ensemble des ressources déployées az vm run-command, extensions de script personnalisées, capture instantanée de disque de système d’exploitation et échange, console série, vol de jeton d’identité managée via IMDS, tous sans SSH Couches 1 à 3
B — le fournisseur cloud (hôte/hyperviseur) Opérateur disposant d’un accès au niveau de l’hôte à la mémoire de machine virtuelle Lecture de la mémoire invité à partir de l’extérieur de la machine virtuelle Couche 4 (facultatif)

La direction des menaces A est la principale menace et celle qui forme l’architecture. Dans le modèle de base, la direction de menace B est un risque accepté explicitement : la plateforme est considérée comme fiable, ce qui correspond à l’approche courante consistant à faire confiance à l’hyperviseur du fournisseur de cloud. Ajoutez Layer 4 uniquement lorsque l’hyperviseur lui-même ne doit pas être considéré comme fiable (par exemple, une charge de travail soumise à des exigences réglementaires imposant le chiffrement de la mémoire).

Quand ajouter l’informatique confidentielle (couche 4)

L’informatique confidentielle n’est pas une alternative à ce modèle : il s’agit de la couche 4 facultative que vous ajoutez. Le modèle de base (couches 1 à 3) conditionne déjà la libération de la clé sur l’attestation, protège la ressource contre le consommateur et fonctionne sur n’importe quelle référence SKU avec lancement fiable Gen2, au tarif standard. L’ajout de l’informatique confidentielle ne modifie pas le fonctionnement du modèle : SKR, l’image renforcée et l’isolation réseau restent toutes identiques, et le flux de mise en production est identique. Les seules différences sont que la politique de publication repose sur les attestations du TEE matériel au lieu des attestations de démarrage mesuré du vTPM, et que la charge de travail s’exécute sur une SKU de machine virtuelle confidentielle. Vous bénéficiez d’une protection contre le vecteur de menace B (l’hôte/l’hyperviseur), en contrepartie d’un choix plus limité de SKU, de GPU et de couverture régionale, moyennant un surcoût.

Le tableau suivant montre ce que la couche 4 ajoute et ce qu’elle coûte, et non pas un choix entre deux modèles :

Considérations Modèle de base (couches 1–3, Trusted Launch) Avec la couche 4 ajoutée (informatique confidentielle)
Protège la ressource contre le consommateur (menace A) Oui Oui (inchangé)
Protège l’actif contre l’hôte / l’hyperviseur (menace B) Non (risque accepté) Oui (chiffrement de la mémoire)
Libération de la clé conditionnée par l’attestation Attestations de démarrage mesuré du vTPM Revendications matériel TEE
Disponibilité de la référence SKU GPU Toutes les SKU Gen2 Limité aux références SKU et quotas GPU confidentiels
Étendue de la région et de la référence SKU Large Plus étroit
Coût relatif Tarification des machines virtuelles standard Premium

Commencez par le modèle de base. Ajoutez la couche 4 uniquement lorsque vous ne pouvez pas faire confiance à l’hyperviseur — par exemple, pour une charge de travail soumise à des contraintes réglementaires imposant le chiffrement de la mémoire — en acceptant un choix plus limité de références (SKU), une disponibilité plus restreinte des GPU et selon les régions, ainsi qu’un surcoût.

Éléments du modèle

Le modèle repose sur une défense en profondeur par couches. Chaque couche défend une direction de menace spécifique : les couches 1 à 3 se défendent contre le consommateur (direction de la menace A) et la couche 4 facultative défend contre l’hôte (direction de la menace B). La ressource protégée se trouve au cœur, accessible uniquement par chaque couche englobante.

Diagramme des couches concentriques de défense en profondeur protégeant l’actif, et de la direction des menaces contre laquelle chaque couche protège.

Les couches défendent la ressource au repos et en cours d’utilisation. Au moment de l’exécution, la machine virtuelle du consommateur et les ancres d’approbation de l’éditeur interagissent comme suit :

Schéma du flux d’attestation de l’environnement d’exécution et de remise de clé entre le locataire consommateur et le locataire éditeur.

Couche 1 : Remise sécurisée de clé conditionnée par l’attestation (le verrou cryptographique)

Cette couche est la base. Une machine virtuelle de lancement approuvé démarre avec le démarrage sécurisé et un module TPM virtuel (vTPM). VTPM mesure la chaîne de démarrage dans les registres de configuration de plateforme (PCR), créant une empreinte de chiffrement de ce qui a démarré exactement. L’invité demande un jeton MAA qui comprend ces mesures, telles que la revendication secureboot et x-ms-azurevm-attested-pcr-values.pcr0 jusqu’à pcr7. Il appelle ensuite le point de terminaison /release de Key Vault et présente le jeton. Key Vault valide la signature du jeton et l'évalue par rapport à la stratégie de mise en production de la clé. Si les revendications de la stratégie correspondent, Key Vault libère la clé, encapsulée à la clé éphémère de vTPM afin que seule la machine virtuelle attestée puisse la décompresser. S’ils ne correspondent pas, la version renvoie AccessDenied.

Ce que cela bloque (menace A) : Une machine virtuelle falsifiée, réimagée ou dont le disque a été remplacé présente des valeurs PCR différentes et ne peut pas obtenir la clé. Un instantané du disque du système d’exploitation monté sur une autre machine virtuelle échoue également.

Stratégie de publication type pour une machine virtuelle Trusted Launch :

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

Couche 2 : Image renforcée (protéger la ressource déchiffrée)

La couche 1 contrôle si la clé est libérée ; il ne protège pas la ressource une fois qu’elle est déchiffrée dans l’invité en cours d’exécution. Renforcer l’image pour réduire la surface d’attaque au sein de l’invité et du plan de contrôle : intégrité du système de fichiers (par exemple, dm-verity), système de fichiers racine en lecture seule, aucun démon SSH, aucune connexion interactive et aucun agent dans l’invité pouvant exécuter des commandes fournies par un opérateur.

Ce qu’il bloque (menace A) : Exploitation au sein de l’invité d’une machine virtuelle attestée en cours d’exécution — processus malveillants, élévation de privilèges, extraction de l’actif déchiffré depuis la mémoire du processus via une vulnérabilité au niveau du système d’exploitation.

Couche 3 : Isolation réseau (réduire la surface)

Limitez la façon dont la machine virtuelle communique avec les ancres de confiance et les données. Utilisez des points de terminaison privés pour Key Vault, le stockage et tout registre ; un chemin privé vers le fournisseur d’attestation ; dns privé ; sans sortie publique inutile. Lorsque le mécanisme de déploiement le permet — par exemple, une application gérée —, les affectations de refus peuvent également retirer au consommateur ses autorisations RBAC sur les ressources de capacité de calcul, bloquant ainsi purement et simplement les attaques du plan de contrôle (run-command, opérations sur disque, console série, usurpation d’identité). Dans le cadre d’une livraison basée sur un modèle de solution, le client conserve le RBAC sur les ressources déployées, de sorte que le renforcement du plan de contrôle n’est pas disponible ; dans ce cas, les couches 1 et 2 assurent la défense contre la menace A : un instantané ou un disque remplacé ne réussit pas l’attestation (couche 1), et l’image renforcée (couche 2) empêche l’extraction de l’actif déchiffré depuis le système invité.

Ce qu’il bloque (menace A) : Réduit la surface exposée pour les attaques de plan de contrôle et de plan de données et empêche les chemins d’exfiltration de l’invité attesté.

Couche 4 (facultatif) : Informatique confidentielle (défend la direction des menaces B)

Tout ce qui précède fait confiance à l’hôte. Si vous ne pouvez pas approuver l’hyperviseur, exécutez la charge de travail sur une machine virtuelle confidentielle (AMD SEV-SNP ou Intel TDX). Le chiffrement de la mémoire empêche l’hôte de lire la mémoire de la machine virtuelle invitée, et SKR fait passer les attestations de démarrage mesuré du vTPM à des attestations TEE matérielles dans la stratégie de libération. Cette couche est la seule couche qui défend la direction des menaces B. Elle est désactivée par défaut, car elle réduit la disponibilité de la référence SKU, du GPU et de la région et ajoute des coûts.

Identité inter-locataires

L’éditeur détient les ancres de confiance — Key Vault (ou HSM managé) et le fournisseur d’attestation — au sein du locataire de l’éditeur, en dehors du RBAC du consommateur. La machine virtuelle attestée s’exécute dans le locataire du client et doit accéder à Key Vault au-delà de cette délimitation. Deux contraintes de plateforme excluent les approches évidentes :

  • Une identité managée existe dans un seul locataire. Le locataire de l’éditeur ne reconnaîtra pas et n’émettra pas de jetons pour une identité managée qui appartient au locataire du consommateur.
  • Une attribution de rôle RBAC Azure ne peut cibler qu’une identité dans le locataire auquel appartient la ressource ; vous ne pouvez donc pas accorder à l’identité managée du consommateur un rôle sur le coffre de clés de l’éditeur.

Les informations d’identification d’identité fédérée (FIC) ne peuvent pas combler directement l’écart : Entra ID n’autorise pas un FIC à approuver les jetons émis par un autre locataire Entra. Par conséquent, une application appartenant à un éditeur ne peut pas fédérer l’identité managée du consommateur au-delà de la limite.

Le modèle qui fonctionne place l’identité intermédiaire — une application multilocataire — du côté du consommateur :

  1. Le client enregistre une application multilocataire dans son tenant et y configure un FIC du même tenant qui fait confiance à l’identité managée de la VM. Un FIC qui fait confiance à une identité dans le même tenant est autorisé.
  2. L’éditeur intègre cette application dans son propre locataire en provisionnant un principal de service pour celle-ci et en attribuant à ce principal le rôle Key Vault Crypto Service Release User sur la clé. Cette étape d’intégration délibérée, propre à chaque consommateur, est celle où l’éditeur accorde à un acteur externe l’accès à son environnement locataire.
  3. Lors de l’exécution, l’identité managée de la machine virtuelle obtient un jeton auprès d’IMDS, l’échange via le FIC pour s’authentifier en tant qu’application multilocataire, puis appelle le point de terminaison /release de Key Vault avec le jeton MAA dans le corps de la requête.

Important

L’échange d’identité n’est pas la limite de sécurité. Étant donné que le consommateur possède l’enregistrement de l’application multilocataire, un administrateur côté consommateur peut lui ajouter un autre justificatif d’authentification (tel qu’un secret client) et exécuter ce flux manuellement ; la couche d’identité n’offre donc aucune garantie à l’éditeur contre un consommateur malveillant. La véritable frontière est SKR + attestation (couche 1) : même avec un jeton valide du locataire de l’éditeur, Key Vault refuse de divulguer la clé à moins qu’un jeton MAA valide ne satisfasse à la stratégie de divulgation, et seule l’image authentique et attestée de l’éditeur peut en générer un. La couche d’identité achemine uniquement la requête vers le coffre-fort approprié.

Procédure pas à pas

  1. Configurez les ancres d’approbation (locataire de l’éditeur). Créez un Key Vault Premium ou un Managed HSM. Créez une clé de RSA-HSM exportable . Joignez une stratégie de lancement qui fixe votre autorité MAA et les revendications à lancement fiable (secureboot, x-ms-azurevm-attested-pcr-values.pcrN sélectionnées).
  2. Déterminez les valeurs RPC attendues. Attestez une fois une instance fiable de votre image, puis lisez x-ms-azurevm-attested-pcr-values à partir du jeton MAA renvoyé. Épinglez les PCR à vos mesures de chaîne de démarrage, généralement pcr4 (chargeur de démarrage/noyau) et pcr7 (état de démarrage sécurisé).
  3. Déployez la charge de travail (locataire client). Déployez une machine virtuelle de lancement approuvé (Gen2) exécutant l’image renforcée. Attribuez-lui une identité managée et fédérez cette identité à l’application multilocataire appartenant au consommateur décrite dans l’identité inter-locataire, dont l’éditeur a attribué au principal de service le rôle Key Vault Crypto Service Release User sur la clé.
  4. Attestez et libérez au moment de l’exécution. L’invité obtient un jeton MAA, puis appelle POST /keys/{key-name}/release. Key Vault valide et retourne la clé encapsulée ; le système invité la désencapsule dans la machine virtuelle.
  5. Vérifiez le cas négatif. Remplacez un PCR fixé dans la stratégie de lancement par une valeur non correspondante (ou démarrez une image modifiée) et confirmez que la libération renvoie AccessDenied.

Pour obtenir du code exécutable, consultez les exemples dans le contenu associé.

Contenu connexe

  • Dernière mise à jour :