Partage via

Résoudre les problèmes courants relatifs à Always Encrypted avec enclaves sécurisées

  • Article

S’applique à : SQL Server 2019 (15.x) et versions ultérieures - Windows uniquement Azure SQL Database

Cet article explique comment identifier et résoudre les problèmes courants qui peuvent se présenter lors de l’exécution d’instructions TSQL (Transact-SQL) utilisant Always Encrypted avec enclaves sécurisées.

Pour plus d’informations sur l’exécution de requêtes utilisant des enclaves sécurisées, consultez Exécuter des instructions Transact-SQL utilisant des enclaves sécurisées.

Database connection errors (Erreurs de connexion de base de données)

Pour exécuter des instructions à l’aide d’une enclave sécurisée, vous devez activer l’option Always Encrypted. Ensuite, vous devez spécifier un protocole d’attestation et, le cas échéant, une URL d’attestation pour la connexion de base de données, comme expliqué dans Conditions préalables à l’exécution d’instructions à l’aide d’enclaves sécurisées. Cependant, votre connexion échoue si vous spécifiez un protocole d’attestation, alors que votre base de données Azure SQL ou votre instance SQL Server cible ne prend pas en charge les enclaves sécurisées ou est mal configurée.

Erreurs d’attestation lors de l’utilisation de Microsoft Azure Attestation

Remarque

Cette section s’applique uniquement à la base de données Azure SQL équipée d’enclaves Intel SGX.

Avant d’envoyer une instruction T-SQL au serveur logique Azure SQL pour exécution, le pilote client déclenche le workflow d’attestation d’enclave suivant à l’aide de Microsoft Azure Attestation.

  1. Le pilote client passe l’URL d’attestation, spécifiée dans la connexion de base de données, au serveur logique Azure SQL.
  2. Le serveur logique Azure SQL collecte les preuves relatives à l’enclave, à son environnement d’hébergement et au code s’exécutant dans l’enclave. Le serveur envoie ensuite une demande d’attestation au fournisseur d’attestation, référencé dans l’URL d’attestation.
  3. Le fournisseur d’attestation valide les preuves par rapport à la stratégie configurée et émet un jeton d’attestation au serveur logique Azure SQL. Le fournisseur d’attestation signe le jeton d’attestation avec sa clé privée.
  4. Le serveur logique Azure SQL envoie le jeton d’attestation au pilote client.
  5. Le client contacte le fournisseur d’attestation à l’URL d’attestation spécifiée pour récupérer sa clé publique et vérifie la signature dans le jeton d’attestation.

Des erreurs peuvent se produire à différentes étapes du workflow ci-dessus en raison de configurations incorrectes. Voici les erreurs d’attestation courantes, leurs causes principales et les étapes de résolution des problèmes recommandées :

  • Votre serveur logique Azure SQL ne peut pas se connecter au fournisseur d’attestation spécifié dans l’URL d’attestation dans Azure Attestation (étape 2 du workflow ci-dessus). Les causes probables sont les suivantes :
    • L’URL d’attestation est incorrecte ou incomplète. Pour plus d’informations, consultez Déterminer l’URL d’attestation de votre stratégie d’attestation.
    • Le fournisseur d’attestation a été accidentellement supprimé.
    • Le pare-feu a été configuré pour le fournisseur d’attestation, mais il n’autorise pas l’accès aux services Microsoft.
    • Une erreur réseau intermittente entraîne l’indisponibilité du fournisseur d’attestation.
  • Votre serveur logique Azure SQL n’est pas autorisé à envoyer des demandes d’attestation au fournisseur d’attestation. Vérifiez que l’administrateur de votre fournisseur d’attestation a ajouté le serveur de base de données au rôle Lecteur d’attestation.
  • La validation de la stratégie d’attestation échoue (étape 3 du workflow ci-dessus).
    • La cause racine probable est une stratégie d’attestation incorrecte. Veillez à utiliser la stratégie recommandée par Microsoft. Pour plus d’informations, consultez Créer et configurer un fournisseur d’attestation.
    • La validation de la stratégie peut également échouer en raison d’une violation de sécurité compromettant l’enclave côté serveur.
  • Votre application cliente ne peut pas se connecter au fournisseur d’attestation et récupérer la clé de signature publique (étape 5). Les causes probables sont les suivantes :
    • La configuration de pare-feux entre votre application et le fournisseur d’attestation peut bloquer les connexions. Pour résoudre les problèmes de connexion bloquée, vérifiez que vous pouvez vous connecter au point de terminaison OpenId de votre fournisseur d’attestation. Par exemple, utilisez un navigateur web sur l’ordinateur hébergeant votre application pour voir si vous pouvez vous connecter au point de terminaison OpenID. Pour plus d’informations, consultez Configuration des métadonnées - Get.

Erreurs d’attestation lors de l’utilisation du service Guardian hôte

Remarque

Cette section s’applique uniquement à SQL Server 2019 (15.x) et aux versions ultérieures.

Avant qu’un gestionnaire client ne soumette une instruction T-SQL au SQL Server pour exécution, le gestionnaire déclenche le flux de travail d’attestation d’enclave suivant à l’aide du Service Guardian hôte (SGH).

  1. Le gestionnaire client appelle SQL Server pour lancer l’attestation.
  2. SQL Server recueille des preuves sur son enclave, son environnement d’hébergement, ainsi que le code qui s’exécute dans l’enclave. SQL Server demande un certificat d’intégrité à l’instance SGH, l’ordinateur qui héberge SQL Server a été enregistrée. Pour plus d’informations, consultez Inscrire un ordinateur auprès du service Guardian hôte.
  3. SGH valide les preuves et émet le certificat d’intégrité à SQL Server. SGH signe le certificat d’intégrité avec sa clé privée.
  4. SQL Server envoie le certificat d’intégrité au gestionnaire client.
  5. Le pilote client contacte SGH à l’URL d’attestation, spécifiée pour la connexion de base de données, afin de récupérer la clé publique SGH. Le pilote client vérifie la signature dans le certificat d’intégrité.

Des erreurs peuvent se produire à différentes étapes du workflow ci-dessus en raison de configurations incorrectes. Voici les erreurs d’attestation courantes, leurs causes racines et les étapes de résolution recommandées :

  • SQL Server ne peut pas se connecter à SGH (étape 2 du flux de travail ci-dessus) en raison d’une erreur réseau intermittente. Pour résoudre le problème de connexion, l’administrateur de l’ordinateur SQL Server doit vérifier que l’ordinateur peut se connecter à la machine SGH.
  • La validation à l’étape 3 échoue. Pour résoudre le problème de validation :
    • L’administrateur de l’ordinateur SQL Server doit travailler avec l’Administrateur d’application cliente pour vérifier que l’ordinateur SQL Server est inscrit auprès de la même instance SGH que celle référencée dans l’URL d’attestation côté client.
    • L’administrateur de l’ordinateur SQL Server doit confirmer que l’ordinateur SQL Server peut être convenablement certifié, en suivant les instructions de l’étape 5 : confirmer que l’hôte peut être convenablement certifié.
  • Votre application cliente ne peut pas se connecter à SGH et récupérer sa clé de signature publique (étape 5). La cause la plus probable est la suivante :
    • La configuration de l’un des pare-feux entre votre application et le fournisseur d’attestation peut bloquer les connexions. Vérifiez que la machine hébergeant votre application peut se connecter à la machine SGH.

Erreurs de chiffrement sur place

Cette section liste les erreurs courantes que vous pouvez rencontrer lors de l’utilisation de ALTER TABLE/ALTER COLUMN pour le chiffrement sur place (en plus des erreurs d’attestation décrites dans les sections précédentes). Pour plus d’informations, consultez Configurer le chiffrement de colonne sur place en utilisant Always Encrypted avec enclaves sécurisées.

  • La clé de chiffrement de colonne que vous essayez d’utiliser pour chiffrer, déchiffrer ou rechiffrer des données n’est pas une clé prenant en charge les enclaves. Pour plus d’informations sur les prérequis du chiffrement sur place, consultez les prérequis. Pour plus d’informations sur le provisionnement des clés prenant en charge les enclaves, consultez Provisionner des clés prenant en charge les enclaves.
  • Vous n’avez pas activé Always Encrypted et les calculs d’enclave pour la connexion de base de données. Consultez les prérequis pour l’exécution d’instructions utilisant des enclaves sécurisées.
  • Votre instruction ALTER TABLE/ALTER COLUMN déclenche une opération de chiffrement et change le type de données de la colonne ou définit un classement avec une page de codes différente de celle du classement actuel. La combinaison d’opérations de chiffrement avec des changements de type de données ou de page de classement n’est pas autorisée. Pour résoudre le problème, utilisez des instructions distinctes : une pour changer le type de données ou la page de codes de classement, une autre pour le chiffrement sur place.

Erreurs lors de l’exécution de requêtes DML confidentielles utilisant des enclaves sécurisées

Cette section liste les erreurs courantes que vous pouvez rencontrer lors de l’utilisation de requêtes DML confidentielles utilisant des enclaves sécurisées (en plus des erreurs d’attestation décrites dans les sections précédentes).

Étapes suivantes

Voir aussi