Ошибка открытия главного ключа SQL Server 2008 при смене физического сервера

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

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

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

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

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

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

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

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

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


encryption aes sql sql-server-2008
person Tomasz Iniewicz    schedule 07.01.2010    source источник

Ответы (2)


arrow_upward
71
arrow_downward

Главный ключ базы данных шифруется с помощью главного ключа сервера, специфичного для машины, на которой установлен 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

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

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

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

person Sam    schedule 07.01.2010
comment
СВЯТАЯ ДЕРЬМО! Ты мой спаситель! Если бы я мог щелкнуть эту стрелку вверх тысячу раз, я бы это сделал! Спасибо! - person Tomasz Iniewicz; 08.01.2010

arrow_upward
4
arrow_downward

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

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

Главный ключ службы. В верхней части иерархии ключей находится главный ключ службы. На каждый экземпляр 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/

person wruckie    schedule 03.01.2015