web-dev-qa-db-fra.com

Comment vérifier que le cryptage de la clé principale de la base de données est valide?

J'ai un scénario où je restaure une base de données d'un serveur à un autre. Sur le serveur source, la clé principale de base de données (DMK) est chiffrée à la fois avec un mot de passe et la clé principale de service (SMK). Lorsque je vais le restaurer sur le nouveau serveur, la ligne dans sys.key_encryptions dit toujours qu'il est chiffré par le SMK. Ce n'est pas vrai cependant car les SMK ne correspondent pas entre les deux serveurs. Existe-t-il un moyen programmatique de vérifier que le DMK est bien chiffré avec celui de ce serveur SMK?

sql-serverencryptionencryption-key
7
Ben Thul

Afin de déterminer par programme si le SMK actuel a été utilisé pour protéger le DMK, vous devriez pouvoir simplement tenter une opération qui nécessiterait le DMK. Une telle opération devrait d'abord décrypter le DMK afin de l'utiliser. En supposant que vous n'avez pas ouvert le DMK explicitement (en utilisant le mot de passe fourni lors de sa création), le décryptage du DMK nécessitera le SMK. Si le SMK actuel n'est pas le correct SMK, le DMK ne sera pas automatiquement déchiffré et l'opération échouera. Donc:

  • Si vous avez un certificat dont l'existence est garantie dans la base de données en cours de restauration, essayez de l'utiliser:

    SELECT SIGNBYCERT( CERT_ID( '{certificate_name}' ), 'test' );

    Cela devrait renvoyer une valeur nonNULL VARBINARY. Si la valeur de retour est NULL, alors le DMK doit être régénéré (selon les instructions ci-dessous).

  • Si aucun certificat n'est garanti dans la base de données en cours de restauration, essayez d'en créer un. Si le SMK peut être utilisé pour décrypter automatiquement le DMK, le certificat sera créé, sinon l'opération échouera:

    BEGIN TRY
  CREATE CERTIFICATE [TestCert] WITH SUBJECT = 'yadda yadda yadda';
  DROP CERTIFICATE [TestCert];
  PRINT 'All good, yo!';
END TRY
BEGIN CATCH
  PRINT ERROR_MESSAGE();
END CATCH;

Cependant, puisque vous venez de restaurer une base de données provenant d'une autre instance et n'a pas restauré le SMK de cette autre instance dans la nouvelle instance, il est sûr de supposer que la réponse est: "non, le DMK est pas chiffré avec ceci SMK du serveur. "

Il s'agit d'un scénario attendu qui nécessite les étapes suivantes pour y remédier:

USE [newly_restored_db];
OPEN MASTER KEY DECRYPTION BY PASSWORD = '{password}'; -- password used to protect DMK
ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = '{password}';
CLOSE MASTER KEY;

La page MSDN pour CREATE MASTER KEY indique (emphase ajoutée):

Pour SQL Server et Parallel Data Warehouse, la clé principale est généralement protégée par la clé principale du service et au moins un mot de passe. En cas de déplacement physique de la base de données vers un autre serveur (envoi de journaux, restauration de la sauvegarde, etc.), la base de données contiendra une copie de la clé principale chiffrée par la clé principale de service du serveur d'origine (sauf si ce chiffrement a été explicitement supprimé à l'aide d'ALTER. MASTER KEY DDL), et une copie de celui-ci chiffrée par chaque mot de passe spécifié lors des opérations CREATE MASTER KEY ou ALTER MASTER KEY DDL suivantes. Afin de récupérer la clé principale et toutes les données chiffrées en utilisant la clé principale comme racine dans la hiérarchie de clés après le déplacement de la base de données, l'utilisateur devra [à] soit utiliser [la] CLÉ MAÎTRE OUVERTE en utilisant l'un des mots de passe utilisés pour protéger la clé principale, restaurer une sauvegarde de la clé principale ou restaurer une sauvegarde de la clé principale de service d'origine sur le nouveau serveur.

La page MSDN pour OPEN MASTER KEY indique:

Lorsqu'une base de données est attachée ou restaurée pour la première fois à une nouvelle instance de SQL Server, une copie de la clé principale de la base de données (chiffrée par la clé principale du service) n'est pas encore stockée sur le serveur. Vous devez utiliser l'instruction OPEN MASTER KEY pour déchiffrer la clé principale de la base de données (DMK). Une fois le DMK décrypté, vous avez la possibilité d'activer le décryptage automatique à l'avenir en utilisant l'instruction ALTER MASTER KEY REGENERATE pour approvisionner le serveur avec un copie du DMK, chiffrée avec la clé principale de service (SMK). Lorsqu'une base de données a été mise à niveau à partir d'une version antérieure, le DMK doit être régénéré pour utiliser le nouvel algorithme AES. Pour plus d'informations sur la régénération du DMK, consultez ALTER MASTER KEY (Transact-SQL) . Le temps nécessaire pour régénérer la clé DMK pour effectuer une mise à niveau vers AES dépend du nombre d'objets protégés par le DMK. La régénération de la clé DMK pour la mise à niveau vers AES n'est nécessaire qu'une seule fois et n'a aucun impact sur les régénérations futures dans le cadre d'une stratégie de rotation des clés.

La page MSDN pour ALTER MASTER KEY indique:

L'option REGENERATE recrée la clé principale de la base de données et toutes les clés qu'elle protège. Les clés sont d'abord déchiffrées avec l'ancienne clé principale, puis chiffrées avec la nouvelle clé principale. Cette opération gourmande en ressources doit être planifiée pendant une période de faible demande, sauf si la clé principale a été compromise.

7
Solomon Rutzky