Чи можу я відновити сертифікат TDE, відновивши базу даних MASTER?

(Ми, на щастя, зараз не перебуваємо в цій ситуації, просто плануємо заздалегідь, щоб побачити, які були б наші варіанти, якщо вони коли-небудь відбудуться.)

Для бази даних, зашифрованої за допомогою Transparent Date Encryption (TDE), копія резервної копії бази даних не може бути відновлена, якщо у вас немає резервної копії сертифіката, використовуваного для її шифрування.

Що робити, якщо у вас цього немає? Чи є додаткові варіанти?

У разі повного збою сервера, чи відновлення резервної копії бази даних MASTER на новому обладнанні також відновить сертифікат?

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

Це ієрархія шифрування TDE:

1. Головний ключ служби (захищений Windows; прив’язаний до облікових даних службового облікового запису та машинного ключа)
2. Основний ключ бази даних (у цьому випадку той, який використовується для основної бази даних)
3. Свідоцтво
4. Ключ шифрування TDE

Перші три елементи зберігаються в головній базі даних, і всі вони можуть бути резервними копіями. Четвертий зберігається (зашифрований сертифікатом №3) у заголовку зашифрованої бази даних.

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

Два найкращі варіанти - або відновити сертифікат (№3) з резервної копії (хороший варіант, якщо майстра неможливо відновити з будь-якої причини), або відновити головну базу даних та її головний ключ (№2) із резервної копії. Відновлення головного ключа може бути кращим варіантом, якщо у вас є багато сертифікатів / ключів, захищених цим ключем, і вам потрібно зробити їх доступними відразу. Це пов'язано з тими ж застереженнями, які зазвичай пов’язані з відновленням основної бази даних (зіставлення, логіни, назви бази даних та шляхи до файлів тощо)

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

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

1. Якщо ви хочете відновити зашифровану резервну копію на іншому сервері, як зазвичай, ви зіткнулися з наступною помилкою

 Cannot find server certificate with thumbprint …...

2.Знайдіть назву cert: у цьому прикладі vestacert

   SELECT  * FROM   sys.certificates

3.Завантажте cert з вихідного сервера (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.Створіть новий Master Cert на сервері 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 , доки ви використовуєте той самий обліковий запис служби в новій системі. Потім слід перезапустити систему, щоб виправити шифрування Service Master ключа за допомогою локального ключа машини. Після цього ви маєте змогу створити резервну копію сертифіката TDE або відновити базу даних користувачів та отримати доступ до даних. Основний сервісний ключ захищений API захисту даних сервера Windows двома способами, спочатку використовуючи локальний ключ машини, який є специфічним для системи, а другий за допомогою службового облікового запису двигуна бази даних. Оскільки ви більше не матимете локальний ключ машини оригінальної системи через збої системи, ви повинні використовувати той самий обліковий запис служби. Сертифікат TDE резервного копіювання в базі даних, але недоступний до завершення ієрархії шифрування.