Erreur SQL Server 2008 Open Master Key lors du changement de serveur physique

Question

J'ai copié une base de données SQL Server d'un système à l'autre, configuration identique, mais machine physique complètement différente. J'ai utilisé Norton Ghost et récupéré des fichiers manuellement, par exemple, le dossier SQL Server 2008 complet trouvé dans c: \ Program Files après la réinstallation de SQL Server 2008 Express.

Une de mes bases de données a le chiffrement AES_256 activé sur un nombre de ses tables, colonnes. Je resetup mon IIS7 et essayé d'exécuter l'application que l'accès à la base de données, lors de la récupération des données, je reçois cette erreur:

Server Error in '/' Application. Please create a master key in the database or open the master key in the session before performing this operation. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Data.SqlClient.SqlException: Please create a master key in the database or open the master key in the session before performing this operation.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Je l'ai fait un peu de lecture et a trouvé quelques liens sur la façon dont le cryptage AES est lié à la clé de la machine, mais je ne sais pas comment la copier sur le nouveau système. Ou peut-être même que ce n'est pas le cas.

REMARQUE: J'ai essayé de supprimer la clé symétrique, le certificat et la clé principale et de les recréer. Cela élimine l'erreur, mais les données cryptées via AES_256 n'apparaissent pas. Les colonnes qui ne sont pas cryptées, cependant.

Toute aide serait grandement appréciée. Merci d'avance!

Answer 1

La clé principale de la base de données est chiffrée à l'aide de la clé principale du serveur, qui est spécifique à la machine sur laquelle SQL Server est installé. Lorsque vous déplacez la base de données vers un autre serveur, vous perdez la possibilité de déchiffrer et d'ouvrir automatiquement la clé principale de la base de données car la clé du serveur local sera probablement différente. Si vous ne pouvez pas décrypter la clé principale de la base de données, vous ne pouvez pas décrypter quoi que ce soit d'autre (certificats, clés symétriques, etc.).

Fondamentalement, vous voulez chiffrer à nouveau la clé principale de la base de données contre la nouvelle clé de serveur, qui peut être fait avec ce script (en utilisant priviliges admin):

-- Reset database master key for server (if database was restored from backups on another server) 
OPEN MASTER KEY DECRYPTION BY PASSWORD = '---your database master key password---' 
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY 
GO 

Notez que lorsque vous créez une clé principale de base de données , vous devriez toujours fournir un mot de passe afin que vous puissiez ouvrir la clé en utilisant le mot de passe dans le scénario où la clé principale de service ne peut pas être utilisée - j'espère que vous avez ce mot de passe stocké quelque part!

Vous pouvez également restaurer une sauvegarde de la clé principale de la base de données, mais vous en avez besoin d'une qui a été créée pour le serveur cible, pas pour le serveur source. Si vous n'avez pas de sauvegarde ou de mot de passe, je ne suis pas sûr que vous serez en mesure de récupérer les données cryptées sur le nouveau serveur, car vous devrez supprimer et recréer la clé principale de base de données avec un nouveau mot de passe, qui va tuer toutes les clés dépendantes et les données.

Answer 2

J'ai juste eu une situation similaire, une reconstruction du serveur après la mort des lecteurs OS. J'ai réinstallé SQL et reconnecté à toutes mes anciennes bases de données sur les lecteurs de données intactes. Tout a fonctionné sauf pour mes colonnes cryptées. Mais mon problème était que la clé de service maître a été arrosée. J'ai été en mesure de réparer ma clé de service maître en revenant au même domaine d'identification de domaine qui avait été mon compte de service SQL Server avant le déménagement.

Ce article m'a donné le correctif (bravo à Matt Bowler pour son excellent article). Je savais que la clé de la machine locale avait changé, mais mon salut était que je pourrais utiliser le même compte de service.

Clé principale de service: La clé principale de service se trouve en haut de la hiérarchie de clés. Il y en a une par instance SQL Server, c'est une clé symétrique et elle est stockée dans la base de données master.Utilisé pour chiffrer les clés principales de la base de données, les mots de passe du serveur lié et les informations d'identification, il est généré au premier démarrage de SQL Server.

Aucun mot de passe configurable par l'utilisateur associé à cette clé - est chiffré par le compte de service SQL Server et la clé machine locale. Au démarrage, SQL Server peut ouvrir la clé principale du service avec l'une ou l'autre de ces décryptages. Si l'un d'entre eux échoue - SQL Server utilisera l'autre et 'corrigera' le décryptage échoué (si les deux échouent - SQL Server aura une erreur). Cela permet de prendre en compte des situations telles que les clusters dans lesquels la clé de la machine locale sera différente après un basculement. C'est également une raison pour laquelle les comptes de service doivent être modifiés à l'aide de SQL Server Configuration Manager, car le cryptage de la clé maîtresse de service est régénéré correctement.

http://mattsql.wordpress.com/2012/11/13/migrating-sql-server-databases-that-use-database-master-keys/