Partager via

Configurer l’attestation pour Always Encrypted à l’aide de l’attestation Azure

  • Article

S’applique à : Azure SQL Database

Microsoft Azure Attestation est une solution pour l’attestation des environnements d’exécution de confiance (TEE), notamment les enclaves Intel Software Guard Extensions (Intel SGX).

Afin d’utiliser Azure Attestation pour l’attestation des enclaves Intel SGX utilisées pour Always Encrypted avec enclaves sécurisées dans Azure SQL Database, vous devez :

  1. Créer un fournisseur d’attestation et le configurer selon la stratégie d’attestation recommandée.

  2. Déterminez l’URL d’attestation et partagez-la avec les administrateurs d’applications.

Important

Avec des enclaves Intel SGX dans Azure SQL Database, l’attestation est obligatoire et nécessite Microsoft Azure Attestation. Les enclaves de sécurité basée sur la virtualisation dans Azure SQL Database ne prennent pas en charge l'attestation. Cet article s'applique uniquement aux enclaves Intel SGX.

Remarque

La configuration de l’attestation est la responsabilité de l’administrateur d’attestation. Consultez Rôles et responsabilités lors de la configuration d’enclaves Intel SGX et de l’attestation.

Créer et configurer un fournisseur d’attestation

Un fournisseur d’attestation est une ressource dans Azure Attestation qui évalue les demandes d’attestation par rapport aux stratégies d’attestation et émet les jetons d’attestation.

Les stratégies d’attestation sont spécifiées à l’aide de la grammaire des règles de revendication.

Important

Un fournisseur d’attestation est créé avec la stratégie par défaut pour les enclaves Intel SGX ce qui ne valide pas le code qui s’exécute à l’intérieur de l’enclave. Microsoft vous conseille fortement de définir la stratégie recommandée utilisée dans la sortie suivante et de ne pas utiliser la stratégie par défaut pour Always Encrypted avec enclaves sécurisées.

Microsoft recommande la stratégie suivante pour l’attestation des enclaves Intel SGX utilisées pour Always Encrypted dans Azure SQL Database :

version= 1.0;
authorizationrules 
{
       [ type=="x-ms-sgx-is-debuggable", value==false ]
        && [ type=="x-ms-sgx-product-id", value==4639 ]
        && [ type=="x-ms-sgx-svn", value>= 2 ]
        && [ type=="x-ms-sgx-mrsigner", value=="e31c9e505f37a58de09335075fc8591254313eb20bb1a27e5443cc450b6e33e5"] 
    => permit();
};

La stratégie vérifie ceci :

  • L’enclave dans Azure SQL Database ne prend pas en charge le débogage.

    Il est possible de charger des enclaves quand le débogage est désactivé ou activé. La prise en charge du débogage est conçue pour permettre aux développeurs de résoudre des problèmes liés au code s’exécutant dans une enclave. Dans un système de production, le débogage peut permettre à un administrateur d’examiner le contenu de l’enclave, ce qui réduirait le niveau de protection qu’offre l’enclave. La stratégie recommandée désactive le débogage pour s’assurer que, si un administrateur malveillant tente d’activer la prise en charge du débogage en prenant le contrôle de l’ordinateur enclave, l’attestation échoue.

  • L’ID produit de l’enclave correspond à celui attribué à la fonctionnalité Always Encrypted avec des enclaves sécurisées.

    Chaque enclave a un ID produit unique qui différencie l’enclave des autres enclaves. L’ID produit attribué à l’enclave Always Encrypted est 4639.

  • Le numéro de version de sécurité de la bibliothèque est supérieur ou égal à 2.

    Il permet à Microsoft de répondre à des bogues de sécurité potentiels identifiés dans le code de l’enclave. Dans le cas où un problème de sécurité est découvert et corrigé, Microsoft déploie une nouvelle version de l’enclave avec un nouveau numéro de version de sécurité (incrémenté). La stratégie recommandée est mise à jour pour refléter le nouveau numéro de version de sécurité. En mettant à jour votre stratégie pour qu’elle corresponde à la stratégie recommandée, vous garantissez que si un administrateur malveillant tente de charger une enclave plus ancienne et non sécurisée, l’attestation va échouer.

  • La bibliothèque de l’enclave a été signée à l’aide de la clé de signature Microsoft (la valeur de la revendication x-ms-sgx-mrsigner est le code de hachage de la clé de signature).

    L’un des principaux objectifs de l’attestation est de convaincre les clients que le fichier binaire qui s’exécute dans l’enclave est celui qui est supposé s’exécuter. Les stratégies d’attestation fournissent deux mécanismes à cet effet. La première est la revendication mrenclave, qui est le hachage du binaire qui est censé s’exécuter dans une enclave. Le problème avec la revendication mrenclave est que le hachage du fichier binaire change même avec des modifications banales du code, ce qui rend difficile la révision du code s’exécutant dans l’enclave. Par conséquent, nous vous recommandons d’utiliser la revendication mrsigner, qui est un hachage d’une clé utilisée pour signer le fichier binaire de l’enclave. Quand Microsoft révise l’enclave, la revendication mrsigner reste la même tant que la clé de signature ne change pas. Ainsi, il devient possible de déployer des fichiers binaires mis à jour sans interrompre les applications des clients.

Important

Microsoft peut (à de rares occasions) devoir appliquer une rotation à la clé utilisée pour signer le fichier binaire d’enclave Always Encrypted. Avant qu’une nouvelle version du fichier binaire d’enclave, signée avec une nouvelle clé, soit déployée sur Azure SQL Database, cet article sera mis à jour pour fournir une nouvelle stratégie d’attestation recommandée et des instructions sur la façon dont vous devez mettre à jour la stratégie dans vos fournisseurs d’attestation pour assurer le fonctionnement ininterrompu de vos applications.

Pour obtenir des instructions sur la création d’un fournisseur d’attestation et la configuration avec une stratégie d’attestation, consultez :

Déterminer l’URL d’attestation pour votre stratégie d’attestation

Une fois que vous avez configuré une stratégie d’attestation, vous devez partager l’URL d’attestation avec les administrateurs d’applications qui utilisent Always Encrypted avec enclaves sécurisées dans Azure SQL Database. L’URL d’attestation est le Attest URI du fournisseur d’attestation contenant la stratégie d’attestation, qui ressemble à ceci : https://MyAttestationProvider.wus.attest.azure.net.

Utiliser le portail Azure pour déterminer l’URL d’attestation

Dans le volet de vue d’ensemble de votre fournisseur d’attestation, copiez la valeur de la propriété Attest URI dans le presse-papiers.

Utiliser PowerShell pour déterminer l’URL d’attestation

Utilisez la cmdlet Get-AzAttestation pour récupérer les propriétés du fournisseur d’attestation, notamment AttestURI.

Get-AzAttestation -Name $attestationProviderName -ResourceGroupName $attestationResourceGroupName

Pour plus d’informations, consultez Créer et gérer un fournisseur d’attestation.

Étapes suivantes

Voir aussi