Ошибка открытого главного ключа SQL Server 2008 при переключении физического сервера - PullRequest
23 голосов
/ 07 января 2010

Я скопировал базу данных SQL Server из одной системы в другую, идентичную настройку, но совершенно другую физическую машину. Я использовал Norton Ghost и восстановил файлы вручную, например, всю папку SQL Server 2008, находящуюся в папке c: \ Program Files после переустановки SQL Server 2008 Express.

В одной из моих баз данных включено шифрование AES_256 для нескольких столбцов таблиц. Я перезагружал свой IIS7 и пытался запустить приложение, которое обращается к базе данных, после получения данных я получаю эту ошибку:

Ошибка сервера в «/» приложении. Пожалуйста, создайте мастер-ключ в базы данных или откройте главный ключ в сессия перед выполнением этого операция. Описание: необработанный исключение произошло во время выполнение текущего веб-запроса. Пожалуйста, просмотрите трассировку стека для более информация об ошибке и где он возник в коде.

Сведения об исключении: System.Data.SqlClient.SqlException: Пожалуйста, создайте мастер-ключ в базы данных или откройте главный ключ в сессия перед выполнением этого работа.

Ошибка источника:

Создано необработанное исключение во время исполнения текущего веб-запрос. Информация относительно Происхождение и место исключения можно определить с помощью исключения трассировка стека ниже.

Я немного прочитал и нашел несколько ссылок о том, как шифрование AES связано с ключом машины, но затрудняюсь, как его скопировать в новую систему. Или, возможно, это даже не тот случай.

ПРИМЕЧАНИЕ. Я попытался удалить симметричный ключ, сертификат и мастер-ключ и воссоздать их. Это избавляет от ошибки, но данные, зашифрованные с помощью AES_256, не отображаются. Однако столбцы, которые НЕ зашифрованы, делают.

Любая помощь будет высоко ценится. Заранее спасибо!

Ответы [ 2 ]

68 голосов
/ 07 января 2010

Главный ключ базы данных шифруется с использованием главного ключа сервера, который зависит от компьютера, на котором установлен SQL Server. Когда вы перемещаете базу данных на другой сервер, вы теряете возможность автоматически расшифровывать и открывать главный ключ базы данных, поскольку ключ локального сервера, скорее всего, будет другим. Если вы не можете расшифровать главный ключ базы данных, вы не можете расшифровать все, что от него зависит (сертификаты, симметричные ключи и т. Д.).

Как правило, вы хотите повторно зашифровать главный ключ базы данных по новому ключу сервера, что можно сделать с помощью этого сценария (с правами администратора):

-- 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

Обратите внимание, что при создании главного ключа базы данных вы также должны всегда указывать пароль, чтобы вы могли открыть ключ с помощью пароля в сценарии, где мастер-ключ службы не может быть использован - возможно, вы получили этот пароль где-то хранится!

Кроме того, вы можете восстановить резервную копию главного ключа базы данных - но вам нужен тот, который был создан для целевого сервера, а не исходного сервера.

Если у вас нет ни резервной копии, ни пароля, я не уверен, что вы сможете восстановить зашифрованные данные на новом сервере, поскольку вам придется удалить и заново создать главный ключ базы данных с помощью новый пароль, который уничтожит все зависимые ключи и данные.

3 голосов
/ 04 января 2015

У меня просто была похожая ситуация, перестроение сервера после того, как диски ОС умерли. Я переустановил SQL и снова подключил его ко всем моим старым базам данных на нетронутых дисках с данными. Все работало, кроме моих зашифрованных столбцов. Но моя проблема заключалась в том, что главный сервисный ключ был проложен. Мне удалось восстановить мой главный служебный ключ, вернувшись к учетным данным домена , которые были моей учетной записью службы сервера SQL до переезда.

Эта статья дала мне исправление (спасибо Мэтту Боулеру за его отличную статью). Я знал, что ключ локальной машины изменился, но мое спасение заключалось в том, что я мог использовать ту же учетную запись службы.

Главный ключ службы. В верхней части иерархии ключей находится главный ключ службы. Существует один экземпляр для каждого экземпляра SQL Server, это симметричный ключ, который хранится в базе данных master. Используется для шифрования главных ключей базы данных, паролей и учетных данных связанного сервера, которые генерируются при первом запуске SQL Server.

С этим ключом не связаны настраиваемые пользователем пароли - он зашифрован служебной учетной записью SQL Server и ключом локального компьютера. При запуске SQL Server может открыть главный ключ службы с помощью любого из этих расшифровок. В случае сбоя одного из них - SQL Server будет использовать другой и «исправить» неудачное дешифрование (при сбое обоих - произойдет ошибка SQL Server). Это необходимо для учета ситуаций, подобных кластерам, когда ключ локального компьютера будет отличаться после аварийного переключения. Это также одна из причин, по которой учетные записи служб следует изменять с помощью диспетчера конфигурации SQL Server - поскольку тогда шифрование главного ключа службы восстанавливается правильно.

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

...