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 Always Encrypted, 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 pour l’exécution d’instructions à l’aide d’enclaves sécurisées. Toutefois, votre connexion échoue si vous spécifiez un protocole d’attestation, mais votre instance Azure SQL Database ou votre instance SQL Server cible ne prend pas en charge les enclaves sécurisées ou est configurée de manière incorrecte.

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

Note

Cette section s’applique uniquement à Azure SQL Database avec 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

Note

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

Avant qu’un pilote client envoie une instruction T-SQL à SQL Server pour l’exécution, le pilote déclenche le flux de travail d’attestation d’enclave suivant à l’aide du service HGS (Host Guardian Service).

  1. Le pilote client appelle SQL Server pour lancer l’attestation.
  2. SQL Server collecte les preuves relatives à son enclave, à son environnement d’hébergement et au code exécuté à l’intérieur de l’enclave. SQL Server demande un certificat d’intégrité à partir de l’instance HGS, la machine avec laquelle SQL Server héberge a été inscrite. Pour plus d’informations, consultez Inscrire un ordinateur auprès du service Guardian hôte.
  3. HGS 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 pilote 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 à l’ordinateur 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 de l’application cliente pour vérifier que l’ordinateur SQL Server est inscrit auprès de la même instance SGH que l’instance 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 attester correctement, en suivant les instructions de l’étape 5 : confirmer que l’hôte peut attester correctement.
  • Votre application cliente ne peut pas se connecter à SGH et récupérer sa clé de signature publique (étape 5). La cause probable est :
    • 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