web-dev-qa-db-fra.com

Veuillez créer une clé principale dans la base de données ou ouvrir la clé principale dans la session avant d'effectuer cette opération.

L'erreur suivante s'affiche sur les répliques secondaires lorsque j'essaie de restaurer une sauvegarde chiffrée, même si la réplique possède la clé principale (dmk), la clé principale de service, les certificats et les clés privées restaurés à partir du serveur d'origine/principal ayant généré la sauvegarde.

Msg 15581, Level 16, State 7, Line 137
Please create a master key in the database or open the master key in the session before performing this operation.
Msg 3013, Level 16, State 1, Line 137
VERIFY DATABASE is terminating abnormally.

Pour contourner l'erreur, j'ouvre et ferme la clé principale autour de l'opération comme telle. Cependant, sur le primaire, je n'ai pas besoin d'ouvrir et de fermer la clé principale pour effectuer l'opération. 

OPEN MASTER KEY DECRYPTION BY PASSWORD = 'MyTest!M4st3rPass';
RESTORE VERIFYONLY FROM DISK = '\\FS1\SqlBackups\SQL01\SystemDbs\msdb_backup_2017_09_22_171915_6346240.bak' WITH FILE = 1, NOUNLOAD, NOREWIND;
CLOSE MASTER KEY ;

Je pense que cela est dû au fait que le principal possède l’historique des sauvegardes avec l’empreinte de cryptage, mais je me demande s’il manque quelque chose d’autre en ce qui concerne les secondaires.

Cependant, après tout, puisque le certificat est restauré sur les serveurs secondaires, je l’assigne aux options du plan de maintenance de sauvegarde de SystemsDB pour Backup Encryption. Cependant, le travail échoue si je conserve l’option Vérifier cochée pour la même raison. 

Source: Back Up Database Task
Executing query "BACKUP DATABASE [master] TO  DISK = N'\\FS1\SqlBac...".: 50% complete
End Progress  
Error: 2017-09-22 17:08:09.28
Code: 0xC002F210
Source: Back Up Database Task Execute SQL Task
**Description**: Executing the query "declare @backupSetId as int  select @backupSetId =..." 
failed with the following error: "Please create a master key in the database or open the master key in the session before performing this operation.
VERIFY DATABASE is terminating abnormally.".
Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
End Error 
4
Hiram

Fixé.

Référencé: https://docs.Microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-and-database-encryption-keys-database-engine

Ce paragraphe l'a donné:

La copie du DMK stockée dans la base de données système master est mise à jour en mode silencieux chaque fois que le DMK est modifié. Toutefois, cette valeur par défaut peut être modifiée à l'aide de l'option DROP ENCRYPTION BY SERVICE MASTER KEY de l'instruction ALTER MASTER KEY. Un DMK non crypté par la clé principale du service doit être ouvert à l'aide de l'instruction OPEN MASTER KEY et d'un mot de passe.

Couru ce qui suit sur mes nœuds secondaires. 

  1. Drop Certificate ...
  2. Déposer clé principale
  3. Créer une clé principale ...
  4. Créer un certificat à partir d'un fichier ...

Arrivé à la solution après avoir vérifié cela.

--on primary, output: master 
select name from sys.databases where is_master_key_encrypted_by_server=1

--on secondary, output: nothing...
select name from sys.databases where is_master_key_encrypted_by_server=1

Je me suis donc dit que si je pouvais chiffrer la clé principale par défaut avec la clé principale du service, le déchiffrement serait automatisé.

--on secondary
drop certificate [BackupCertWithPK]
drop master key

--Skipped restore master key from file.
--Instead, I ran create master key with password.
create master key encryption by password = 'MyTest!Mast3rP4ss';

--verify by open/close.
open master key decryption by password = 'MyTest!Mast3rP4ss';
close master key;

--proceed to restore/create cert from file.
create cerfiticate [BackupCertWithPK] 
from file = '\\FS1\SqlBackups\SQL1\Donot_delete_SQL1-Primary_BackupCertWithPK.cer' 
with private key (file = '\\FS1\SqlBackups\SQL1\Donot_delete_SQL1-Primary_BackupCertWithPK.key' , decryption by password = 'key_Test!prim@ryP4ss') ; 

Après cela, exécutez à nouveau la sélection ci-dessus.

--on secondary, output: master, now there was hope again!
select name from sys.databases where is_master_key_encrypted_by_server=1

Enfin, j'ai réexécuté mon travail de sauvegarde avec les options définies pour Vérifier et chiffrement avec succès. L'étape de vérification n'a pas échoué ni invité à ouvrir/fermer la clé principale.

Ce qui suit a simplement fonctionné comme prévu sans avoir à ouvrir/fermer la clé principale.

RESTORE VERIFYONLY FROM DISK = '\\FS1\SqlBackups\SQL01\SystemDbs\msdb_backup_2017_09_22_171915_6346240.bak' WITH FILE = 1, NOUNLOAD, NOREWIND;

Wohooo! Mission accomplie. 

1
Hiram

Je ne sais pas si c'est exactement ce que vous recherchez, mais les remarques de OPEN MASTER KEY avaient quelque chose qui semblait pertinent.

Vous voudrez à 100% tester ceci pas en production, mais il semble qu'une fois la clé principale ouverte, vous avez l'option de ne pas l'exiger avec la commande ALTER MASTER KEY REGENERATE.

Si la clé principale de la base de données a été chiffrée avec la clé principale du service, il sera automatiquement ouvert lorsque cela sera nécessaire pour le déchiffrement ou cryptage. Dans ce cas, il n’est pas nécessaire d’utiliser OPEN MASTER Déclaration clé. 

Quand une base de données est attachée ou restaurée pour la première fois dans un fichier .__ nouvelle instance de SQL Server, une copie de la clé principale de la base de données (crypté par la clé principale du service) n'est pas encore stocké sur le serveur.

Vous devez utiliser l'instruction OPEN MASTER KEY pour déchiffrer la base de données clé principale (DMK). Une fois le DMK déchiffré, vous avez l'option d’activer le déchiffrement automatique à l’avenir en utilisant ALTER MASTER KEY REGENERATE pour fournir au serveur une copie de le DMK, chiffré 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 pour régénérer le DMK, consultez ALTER MASTER KEY (Transact-SQL). Le temps nécessaire pour régénérer la clé DMK en vue de la mise à niveau vers AES dépend du nombre d'objets protégés par le DMK. Régénération de la clé DMK en la mise à niveau vers AES n’est nécessaire qu’une fois et n’a aucun impact sur l’avenir régénérations dans le cadre d’une stratégie de rotation clé.

https://docs.Microsoft.com/en-us/sql/t-sql/statements/open-master-key-transact-sql

0
ConstantineK

J'ai eu la même situation, mais au lieu de recréer le MDK, j'ai exécuté ce qui suit pour résoudre le problème: ALTER MASTER KEY AJOUTER LE CHIFFREMENT PAR SERVICE MASTER KEY

0
Borogal