Могу ли я восстановить сертификат TDE, восстановив базу данных MASTER?

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

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

Что если у тебя этого нет? Есть ли дополнительные опции?

В случае полного отказа сервера, восстановление резервной копии базы данных MASTER на новом оборудовании также восстановит сертификат?

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

Это иерархия шифрования TDE:

1. Главный ключ службы (защищен Windows; привязан к учетным данным учетной записи службы и ключу машины)
2. Главный ключ базы данных (в данном случае один для основной базы данных)
3. сертификат
4. Ключ шифрования TDE

Первые три элемента хранятся в базе данных master и могут быть сохранены. Четвертый хранится (зашифрован сертификатом от # 3) в заголовке зашифрованной базы данных.

Таким образом, в случае сбоя вам придется восстановить достаточно иерархии шифрования, чтобы позволить вам прочитать ключ TDE. SQL Server создает главный ключ службы при установке; таким образом, при восстановлении основной базы данных в другом экземпляре также будут восстановлены элементы 2 и 3, необходимых ключей для их расшифровки не будет. Результат: нечитаемые данные.

Два лучших варианта - либо восстановить сертификат (# 3) из резервной копии (хороший вариант, если мастер не может быть восстановлен по какой-либо причине), либо восстановить базу данных master и ее главный ключ (# 2) из ​​резервной копии. Восстановление мастер-ключа может быть лучшим вариантом, если у вас есть много сертификатов / ключей, защищенных этим ключом, и вам необходимо сделать их доступными сразу. Это сопровождается теми же мерами предосторожности, которые обычно связаны с восстановлением основной базы данных (параметры сортировки, имена входа, имена баз данных и пути к файлам и т. Д.).

Обычно я рекомендую восстанавливать мастер только в сценарии восстановления. Для сценария миграции / масштабирования (такого как использование групп доступности / зеркалирование с базой данных с шифрованием TDE) лучше создать резервную копию / восстановить сертификат (# 3), чтобы он шифровался с использованием мастер-ключей, уникальных для каждого перемещаемого экземпляра. к. Вам нужно будет включить закрытый ключ в резервную копию сертификата.

В любом случае вам придется создавать резервные копии ключей / сертификатов, поэтому тщательно их защищайте и храните в избыточных безопасных местах. Простое резервное копирование мастера не избавит вас от катастрофы TDE; вам понадобится резервная копия хотя бы одного ключа или сертификата.

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

 Cannot find server certificate with thumbprint …...

2. Найдите название сертификата: в этом примере vestacert

   SELECT  * FROM   sys.certificates

3. Создайте резервную копию сертификата с исходного сервера (Source encryptedserver):

BACKUP CERTIFICATE vestacert
TO FILE = 'c:\Backup\certificate_TDE_Test_Certificate.cer'
WITH PRIVATE KEY
(FILE = 'c:\Backup\certificate_TDE_Test_Key.pvk',
ENCRYPTION BY PASSWORD = 'Password12#')

4. Создайте новый мастер-сертификат на сервере UAT, если он еще не существует

USE master GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'D1ffPa$$w0rd'

5. Восстановление резервных копий на сервере UAT (UATserver)

CREATE CERTIFICATE vestacert2
FROM FILE = 'C:\tmp\certificate_TDE_Test_Certificate.cer'     
WITH PRIVATE KEY (FILE = 'C:\tmp\LCMS\certificate_TDE_Test_Key.pvk', 
DECRYPTION BY PASSWORD = 'Passsword12#')

6. После этого шага восстановления резервной копии не было ошибок, и все данные были доступны для чтения.

7. Но самое смешное, что простое удаление шифрования и создание новой резервной копии и ее восстановление на конечном сервере (Final Server) не работает и выдает следующую ошибку: «mydb_log» не удалось правильно инициализировать. Изучите журналы ошибок для более подробной информации.

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

    USE master
    ALTER DATABASE mydb SET ENCRYPTION OFF
    USE mydb
    DROP DATABASE ENCRYPTION KEY 
    USE master
    DROP CERTIFICATE vestacert2 
    DROP MASTER KEY

9. Теперь создайте новую резервную копию с сервера UAT и восстановите ее на конечном сервере.

хорошая статья: http://sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/

Если ваша система дает сбой и становится непригодной для использования, вы можете построить новую систему и восстановить основную базу данных поверх существующей, чтобы восстановить сертификат TDE, если вы используете ту же учетную запись службы в новой системе., Затем необходимо перезагрузить систему, чтобы исправить шифрование мастер-ключа службы с помощью ключа локальной машины. После этого вы сможете сделать резервную копию сертификата TDE или восстановить базу данных пользователей и получить доступ к данным. Главный ключ службы защищен API защиты данных сервера Windows двумя способами: во-первых, с использованием ключа локальной машины, который специфичен для системы, и во-вторых, с использованием служебной учетной записи ядра базы данных. Поскольку у вас больше не будет ключа локальной машины исходной системы из-за сбоя системы, вы должны использовать ту же учетную запись службы. Резервная копия сертификата TDE хранится в базе данных, но недоступна до тех пор, пока не будет завершена иерархия шифрования.