Czy mogę odzyskać certyfikat TDE, przywracając bazę danych MASTER?

(Na szczęście nie znajdujemy się obecnie w takiej sytuacji, po prostu planujemy z wyprzedzeniem zobaczyć, jakie byłyby nasze opcje, gdyby kiedykolwiek do tego doszło).

W przypadku bazy danych zaszyfrowanej przy użyciu transparentnego szyfrowania daty (TDE) kopia kopii zapasowej bazy danych jest niemożliwa do odzyskania, chyba że masz kopię zapasową certyfikatu używanego do jej szyfrowania.

Co jeśli tego nie masz? Czy są jakieś dodatkowe opcje?

Czy w przypadku całkowitej awarii serwera przywrócenie kopii zapasowej bazy danych MASTER na nowym sprzęcie również przywróci certyfikat?

Ponieważ TDE opiera się na certyfikacie przechowywanym w systemie głównym (który służy do szyfrowania klucza szyfrowania bazy danych), działałoby to tylko wtedy , gdyby można było przywrócić główną bazę danych na innym serwerze w taki sposób, aby certyfikat mógł zostać odszyfrowany.

Oto hierarchia szyfrowania TDE:

1. Klucz główny usługi (chroniony przez system Windows; powiązany z poświadczeniami konta usługi i kluczem komputera)
2. Klucz główny bazy danych (w tym przypadku ten dla głównej bazy danych)
3. Certyfikat
4. Klucz szyfrowania TDE

Pierwsze trzy elementy są przechowywane w głównej bazie danych i można wykonać kopię zapasową wszystkich. Czwarty jest przechowywany (zaszyfrowany przez certyfikat z nr 3) w nagłówku zaszyfrowanej bazy danych.

Dlatego w scenariuszu awarii trzeba przywrócić wystarczającą liczbę hierarchii szyfrowania, aby umożliwić odczytanie klucza TDE. SQL Server tworzy główny klucz usługi podczas instalacji; dlatego podczas przywracania głównej bazy danych w innej instancji zostaną również przywrócone pozycje 2 i 3, nie będą potrzebne klucze niezbędne do ich odszyfrowania. Wynik: nieczytelne dane.

Dwie najlepsze opcje to albo przywrócić certyfikat (nr 3) z kopii zapasowej (dobra opcja, jeśli nie można przywrócić wzorca z jakiegokolwiek powodu), albo przywrócić główną bazę danych i jej klucz główny (nr 2) z kopii zapasowej. Przywrócenie klucza głównego może być lepszą opcją, jeśli masz wiele certyfikatów / kluczy chronionych tym kluczem i musisz udostępnić je wszystkie jednocześnie. Zapewnia to te same środki ostrożności, które zwykle wiążą się z przywracaniem głównej bazy danych (zestawienia, loginy, nazwy baz danych i ścieżki plików itp.)

Zasadniczo polecam przywracanie wzorca tylko w scenariuszu odzyskiwania. W przypadku scenariusza migracji / skalowania w poziomie (np. Przy użyciu grup dostępności / kopii lustrzanej z bazą danych zaszyfrowaną TDE) lepiej jest wykonać kopię zapasową / przywrócić certyfikat (# 3), aby był on szyfrowany przy użyciu kluczy głównych unikalnych dla każdej poruszającej się instancji do. Konieczne będzie dołączenie klucza prywatnego do kopii zapasowej certyfikatu.

W każdym razie będziesz musiał wykonać kopie zapasowe kluczy / certyfikatów, więc chroń je dobrze i przechowuj w nadmiarowych, bezpiecznych lokalizacjach. Samo utworzenie kopii zapasowej master nie wydostanie cię z katastrofy TDE; będziesz potrzebować kopii zapasowej co najmniej jednego klucza lub certyfikatu.

1. Jeśli chcesz przywrócić zaszyfrowaną kopię zapasową na innym serwerze, jak zwykle, pojawia się następujący błąd

 Cannot find server certificate with thumbprint …...

2. Znajdź nazwę certyfikatu: w tym przykładzie vestacert

   SELECT  * FROM   sys.certificates

3. wykonaj kopię zapasową certyfikatu z serwera źródłowego (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. Utwórz nowy certyfikat główny na serwerze UAT, jeśli jeszcze nie istnieje

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

5. Przywróć kopię zapasową certyfikatów na serwerze 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.Po tym kroku przywracanie kopii zapasowej nie powoduje błędu i wszystkie dane były czytelne.

7. Ale zabawne jest to, że zwykłe usunięcie szyfrowania i zrobienie nowej kopii zapasowej i przywrócenie jej na serwerze końcowym (Final Server) nie działa i powoduje następujący błąd Plik „mydb_log” nie został poprawnie zainicjowany. Sprawdź dzienniki błędów, aby uzyskać więcej informacji.

8. Prawidłowym sposobem usunięcia szyfrowania z UAT jest usunięcie wszystkich znaków, jak poniżej, krok po kroku i od dołu do góry

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

9. Teraz utwórz nową kopię zapasową z serwera UAT i przywróć ją do serwera końcowego

dobry artykuł: http://sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/

Jeśli system ulegnie awarii i stanie się bezużyteczny, możesz zbudować nowy system i przywrócić główną bazę danych na istniejącym, aby odzyskać certyfikat TDE, o ile korzystasz z tego samego konta usługi w nowym systemie. Następnie należy ponownie uruchomić system, aby naprawić szyfrowanie klucza głównego usługi za pomocą lokalnego klucza komputera. Następnie powinieneś móc wykonać kopię zapasową certyfikatu TDE lub przywrócić bazę danych użytkowników i uzyskać dostęp do danych. Klucz główny usługi jest chroniony przez interfejs API ochrony danych serwera Windows na dwa sposoby, po pierwsze za pomocą lokalnego klucza komputera, który jest specyficzny dla systemu, a po drugie za pomocą konta usługi silnika bazy danych. Ponieważ nie będziesz już mieć lokalnego klucza komputera oryginalnego systemu z powodu awarii systemu, musisz użyć tego samego konta usługi. Kopia zapasowa certyfikatu TDE jest wykonywana z bazy danych, ale niedostępna do momentu ukończenia hierarchii szyfrowania.