Concepts de base
Cet article définit certains concepts de base liés à Microsoft Azure Attestation.
JSON Web Token (JWTs)
JSON Web Token (JWT) est une méthode RFC7519 de norme ouverte pour la transmission d’informations de manière sécurisée entre des tiers sous la forme d’un objet JSON (JavaScript Object Notation). Ces informations peuvent être vérifiées et approuvées, car elles sont signées numériquement. Les jetons JWT peuvent être signés à l’aide d’un secret ou d’une paire de clés publique/privée.
Clé web JSON (JWK)
JSON Web Key (JWK) est une structure de données JSON qui représente une clé de chiffrement. Cette spécification définit également une structure de données JSON JWK Set qui représente un ensemble de clés JWK.
Fournisseur d’attestations
Le fournisseur d’attestations appartient au fournisseur de ressources Azure nommé Microsoft.Attestation. Le fournisseur de ressources est un point de terminaison de service qui fournit un contrat REST Azure Attestation et qui est déployé à l’aide d’Azure Resource Manager. Chaque fournisseur d’attestations honore une stratégie spécifique et détectable. Les fournisseurs d’attestations sont créés avec une stratégie par défaut pour chaque type d’attestation (notez que l’enclave VBS n’a pas de stratégie par défaut). Pour plus d’informations sur la stratégie par défaut pour SGX, consultez Exemples de stratégie d’attestation.
Demande d’attestation
La demande d’attestation est un objet JSON sérialisé envoyé par une application cliente à un fournisseur d’attestations. L’objet de la demande pour l’enclave SGX a deux propriétés :
- « Quote » : la valeur de la propriété « Quote » est une chaîne contenant une représentation encodée Base64URL de la déclaration d’attestation.
- « EnclaveHeldData » : la valeur de la propriété « EnclaveHeldData » est une chaîne contenant une représentation encodée Base64URL des données détenues par l’enclave.
Azure Attestation valide le « Quote » fourni pour s’assurer que le hachage SHA256 des données détenues par l’enclave est exprimé dans les 32 premiers octets du champ reportData du Quote.
Stratégie d’attestation
La stratégie d’attestation est utilisée pour traiter la preuve d’attestation et peut être configurée par les clients. Le cœur d’Azure Attestation se trouve un moteur de stratégie, qui traite les revendications constituant la preuve. Les stratégies sont utilisées pour déterminer si Azure Attestation doit émettre un jeton d'attestation basé sur des preuves (ou non), et donc approuver l'Attesteur (ou non). En conséquence, si le traitement par toutes les stratégies n’est pas couronné de succès, aucun jeton JWT n’est émis.
Si la stratégie par défaut dans le fournisseur d’attestations ne répond pas aux besoins, les clients peuvent créer des stratégies personnalisées dans l’une des régions prises en charge par Azure Attestation. La gestion des stratégies est une fonctionnalité clé fournie aux clients par Azure Attestation. Les stratégies sont propres au type d’attestation et peuvent être utilisées pour identifier les enclaves, ajouter ou modifier des revendications dans un jeton de sortie.
Voir les Exemples de stratégie d’attestation.
Avantages de la signature de stratégie
Une stratégie d’attestation est ce qui détermine en dernier lieu si un jeton d’attestation est émis par Azure Attestation. La stratégie détermine également les revendications à générer dans le jeton d’attestation. Il est donc essentiel que la stratégie évaluée par le service soit de fait la stratégie écrite par l’administrateur et qu’elle n’ait pas été falsifiée ou modifiée par des entités externes.
Le modèle d’approbation définit le modèle d’autorisation du fournisseur d’attestations pour définir et mettre à jour la stratégie. Deux modèles sont pris en charge : un basé sur l’autorisation Microsoft Entra, et l’autre basé sur la possession de clés de chiffrement gérées par le client (appelé modèle isolé). Le modèle isolé permet à Azure Attestation de s’assurer que la stratégie soumise par le client n’est pas falsifiée.
Dans le modèle isolé, l’administrateur crée un fournisseur d’attestations en spécifiant un ensemble de certificats X.509 de signature approuvés dans un fichier. L’administrateur peut ensuite ajouter une stratégie signée au fournisseur d’attestations. Azure Attestation, lors du traitement de la demande d’attestation, valide la signature de la stratégie à l’aide de la clé publique représentée par le paramètre « jwk » ou « x5c » dans l’en-tête. Azure Attestation vérifie également si la clé publique dans l’en-tête de la demande figure dans la liste des certificats de signature approuvés associés au fournisseur d’attestations. De cette façon, la partie de confiance (Azure Attestation) peut approuver une stratégie signée à l’aide des certificats X.509 dont elle a connaissance.
Pour obtenir des exemples, consultez Exemples de certificat du signataire de stratégie.
Jeton d’attestation
La réponse d’Azure Attestation est une chaîne JSON dont la valeur contient un jeton JWT. Azure Attestation empaquette les revendications et génère un jeton JWT signé. L’opération de signature est effectuée à l’aide d’un certificat auto-signé dont le nom de l’objet correspond à l’élément AttestUri du fournisseur d’attestations.
L’API de récupération des métadonnées OpenID retourne une réponse de configuration OpenID telle que spécifiée par le protocole OpenID Connect Discovery. L’API récupère les métadonnées relatives aux certificats de signature utilisés par Azure Attestation.
Consultez les exemples de jeton d’attestation.
Chiffrement des données au repos
Pour protéger les données des clients, Azure Attestation conserve ses données dans Stockage Azure. Le stockage Azure assure le chiffrement des données au repos lorsque les données sont écrites dans les centres de données, et les déchiffre pour que les clients puissent y accéder. Ce chiffrement s'effectue à l'aide d'une clé de chiffrement gérée par Microsoft.
En plus de protéger les données dans Stockage Azure, Azure Attestation exploite également Azure Disk Encryption (ADE) pour chiffrer les machines virtuelles de service. Pour Azure Attestation s’exécutant dans une enclave au sein d’environnements informatiques confidentiels Azure, l’extension ADE n’est actuellement pas prise en charge. En pareil cas, pour empêcher que les données soient stockées en mémoire, le fichier d’échange est désactivé.
Les données des clients ne sont en aucun cas conservées sur les lecteurs de disque dur locaux de l’instance Azure Attestation.