Si vous souhaitez restaurer sur un autre serveur, vous devriez pouvoir le faire avec le certificat, la clé privée et les fichiers de sauvegarde de la base de données.
Lorsqu'un certificat est créé dans une base de données dans SQL Server, il fait partie d'une hiérarchie de chiffrement . Le certificat dans la base de données master elle-même ne contient qu'une clé publique, qui n'a pas besoin de protection, cependant, la base de données master contiendra également une clé privée distincte mais mathématiquement liée qui doit être protégée. La méthode de protection de la clé privée consiste à la crypter à l'aide de la clé principale de base de données que vous avez créée dans la base de données principale avant de créer le certificat. La couche suivante de la hiérarchie de chiffrement est que le DMK est chiffré par la clé principale du service. Il n'y a qu'un seul SMK sur le système et il se trouve dans la base de données master.
Même si vous n'avez pas besoin du DMK et du SMK pour restaurer une sauvegarde chiffrée sur un autre serveur, je voudrais quand même sauvegarder ces deux clés car cela rend la récupération beaucoup plus flexible.
Lorsque vous restaurez le certificat de chiffrement de sauvegarde dans la base de données principale, ce qui se passe en arrière-plan est que la clé privée est lue à partir du fichier, déchiffrée à l'aide du mot de passe que vous fournissez dans la commande de restauration, puis chiffrée à l'aide de la clé principale de la base de données et enregistrée. Comme vous le savez, la clé privée du certificat peut ensuite être utilisée pour déchiffrer la clé de chiffrement de la base de données dans le fichier de sauvegarde et restaurer correctement la base de données.
Je n'ai pas de recommandation spécifique pour le stockage du certificat et des fichiers de sauvegarde de clés, mais ils doivent être disponibles pour vous et pour quiconque effectue la récupération après sinistre dans votre organisation.
Michael Keleher
la source