Partager via

Erreur 33111 lors de la restauration de sauvegardes à partir de versions antérieures de connecteur SQL Server pour Microsoft Azure Key Vault

  • Article

Numéro de la base de connaissances d’origine : 4470999

Cet article décrit une erreur qui se produit lorsque vous essayez de restaurer une sauvegarde Transparent Data Encryption (TDE) effectuée sur des serveurs qui utilisent des versions antérieures de SQL Server Connector pour microsoft Azure Key Vault.

Symptômes

Vous rencontrez des problèmes lorsque vous essayez de restaurer une sauvegarde de base de données à partir de SQL Server qui utilise SQL Server Connector pour Key Vault 1.0.4.0 ou une version antérieure vers connecteur SQL Server pour Microsoft Azure Key Vault 1.0.5.0.

Supposons que vous déployiez les instances suivantes de Microsoft SQL Server :

  • sql1 SQL Server instance a SQL Server Connector pour Key Vault 1.0.4.0 déployé.

  • sql2 SQL Server instance a SQL Server Connector pour Key Vault 1.0.5.0 déployé.

  • Utilisez la requête suivante pour déployer une clé asymétrique sur les sql1 instances et sql2 à partir de la même source de clé asymétrique dans Key Vault :

    CREATE ASYMMETRIC KEY TDE_KEY 
FROM PROVIDER AzureKeyVaultProvider 
WITH PROVIDER_KEY_NAME = 'key1', 
CREATION_DISPOSITION = OPEN_EXISTING

Si vous passez en revue la valeur des empreintes numériques sur les deux serveurs, vous remarquerez que les longueurs des empreintes numériques diffèrent bien qu’elles soient créées à partir de la même source. L’empreinte numérique de la version 1.0.5.0 est plus longue que la version 1.0.4.0.

Exemple d’empreinte 1.0.4.0 :

0x2C5677D76F76D77F80

Exemple d’empreinte 1.0.5.0 :

0x373B314B78E8D59A0925494558FEF14B726216C5

La modification provoque des problèmes lors des opérations de sauvegarde et de restauration.

Exemple :

Vous disposez d’une sauvegarde de base de données chiffrée par une clé asymétrique dans Key Vault dans le sql1 instance.

Le sql2 instance a une clé asymétrique créée.

Si vous essayez de restaurer la sauvegarde sur le sql2 instance, l’opération échoue et retourne un message d’erreur semblable au message suivant :

Msg 33111, Niveau 16, État 4, LineNumber <>

Impossible de trouver la clé asymétrique du serveur avec l’empreinte numérique « 0x2C5677D76F76D77F80 ».

Remarques :

La requête permettant de récupérer l’empreinte numérique de chaque clé est la suivante :

SELECT thumbprint, * FROM master.sys.asymmetric_keys

La requête permettant de récupérer l’empreinte numérique de chaque base de données TDE est la suivante :

SELECT DatabaseName(ddek.database_id) AS DatabaseName, ak.name
AS [Asymmetric key Name], ak.thumbprint FROM
sys.dm_database_encryption_keys ddek INNER JOIN
master.sys.asymmetric_keys ak ON
ak.thumbprint = ddek.encryptor_thumbprint

Cause

Une mise à jour a été introduite dans la version 1.0.5.0 de SQL Server Connector pour Key Vault qui change la façon dont le programme calcule les empreintes numériques. Dans la version 1.0.5.0, ce calcul correspond à la logique utilisée par le moteur de programme pour prendre en charge le scénario de migration suivant :

À partir de : Microsoft SQL Server local qui utilise la gestion de clés extensible (EKM)

À : Microsoft Azure SQL Database qui utilise la prise en charge byOK (Bring Your Own Key) pour Transparent Data Encryption (TDE)

En raison de cette modification, vous pouvez rencontrer des problèmes lorsque vous essayez de restaurer des sauvegardes de base de données à partir de la version 1.0.4.0 ou d’une version antérieure.

Résolution

  1. Copiez le connecteur SQL Server pour Key Vault 1.0.4.0 ou une version antérieure sur le sql2 serveur instance.

  2. Exécutez la requête suivante sur le sql2 serveur pour passer à la CRYPTOGRAPHIC PROVIDER version 1.0.4.0 :

    ALTER CRYPTOGRAPHIC PROVIDER AzureKeyVaultProvider
FROM FILE =
'FilePath\FileName\SQL Server Connector for Microsoft Azure Key Vault\1.0.4.0\Microsoft.AzureKeyVaultService.EKM.dll'

    1. Redémarrez SQL Server.

    2. Créez une clé asymétrique à l’aide CRYPTOGRAPHIC PROVIDER de 1.0.4.0.

        CREATE ASYMMETRIC KEY TDE_KEY_1040 
  FROM PROVIDER AzureKeyVaultProvider 
  WITH PROVIDER_KEY_NAME = 'key1', 
  CREATION_DISPOSITION = OPEN_EXISTING

  3. Vous pouvez confirmer l’existence des deux clés asymétriques à l’aide de la requête suivante :

    SELECT thumbprint,* FROM master.sys.asymmetric_keys

  4. Ajoutez des informations d’identification à la connexion mappée à clé asymétrique (TDE_Login dans l’exemple suivant) à l’aide d’une requête similaire à la requête suivante :

    ALTER LOGIN [Contoso\DomainUser] DROP CREDENTIAL sysadmin_ekm_cred; 
ALTER LOGIN TDE_Login ADD CREDENTIAL sysadmin_ekm_cred;

  5. Vous devriez maintenant être en mesure de restaurer la sauvegarde.

  6. Exécutez la requête suivante sur sql2 pour rétablir la CRYPTOGRAPHIC PROVIDER version 1.0.5.0 :

    ALTER CRYPTOGRAPHIC PROVIDER AzureKeyVaultProvider 
FROM FILE =
'FilePath\FileName\SQL Server Connector for Microsoft Azure Key Vault\1.0.5.0\Microsoft.AzureKeyVaultService.EKM.dll'

  7. Redémarrez SQL Server.

  8. Pour utiliser la nouvelle empreinte numérique, exécutez la requête suivante à l’aide de la même clé asymétrique ou de la nouvelle clé asymétrique de version.

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER ASYMMETRIC KEY <KeyName_1.0.5.0_version>