Configurer l’attestation pour Always Encrypted à l’aide de l’attestation Azure
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 :
Créer un fournisseur d’attestation et le configurer selon la stratégie d’attestation recommandée.
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();
[ 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=="a0f8e7f72092fb6a5d5752ffccd47fb3af7027ffb589b24e921e81f5703f3a9a"]
=> 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émarrage rapide : Configurer Azure Attestation avec le portail Azure
Important
Quand vous configurez votre stratégie d’attestation avec le portail Azure, définissez Type d’attestation sur
SGX-IntelSDK
. - Démarrage rapide : Configurer Azure Attestation avec Azure PowerShell
Important
Quand vous configurez votre stratégie d’attestation avec Azure PowerShell, définissez le paramètre
Tee
surSgxEnclave
. - Démarrage rapide : Configurer Azure Attestation avec Azure CLI
Important
Quand vous configurez votre stratégie d’attestation avec Azure CLI, définissez le paramètre
attestation-type
surSGX-IntelSDK
.
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.