Kiedy muszę wykonać kopię zapasową klucza głównego usługi?

Czytam trochę dokumentacji i oficjalnego dokumentu na temat przezroczystego szyfrowania danych. Niektóre dokumenty wspominają również o utworzeniu kopii zapasowej głównego klucza usługi (dla wyjaśnienia nie mówię o głównym kluczu bazy danych). Po prostu nie rozumiem dokładnie, dlaczego jest to konieczne, ponieważ byłem w stanie wykonać kopię zapasową / przywrócić bazę danych z szyfrowaniem TDE z serwera A (kopia zapasowa) na serwer B (przywracanie) bez użycia klucza głównego usługi.

W jakim scenariuszu muszę przywrócić klucz główny usługi?

sql-server encryption transparent-data-encryption

— gsharp
źródło

Czy na pewno masz włączone szyfrowanie w swojej bazie danych? Czy utworzyłeś kopię zapasową bazy danych po włączeniu TDE?

— Thomas Stringer

Tak. Potrzebowałem certyfikatu i klucza, aby przywrócić go na serwerze B. (zrobiłem kopię zapasową certyfikatu i klucza). Jednak w BI utworzono nowy klucz główny (nie przywrócono go z serwera A) i udało mi się przywrócić moją bazę danych.

— gsharp

Jeśli przywróciłeś certyfikat TDE i klucz prywatny na serwerze B, powinien on mieć możliwość odszyfrowania bazy danych TDE. Czy możesz wskazać dokument, w którym przeczytałeś wymóg SMK? Może jest coś bardziej dopracowanego ...

— Remus Rusanu

Zgadzam się z @RemusRusanu. Certyfikat napędza szyfrowanie. Jeśli chodzi o klucz główny usługi, to po prostu ogólną najlepszą praktyką administracyjną jest tworzenie kopii zapasowych (coś, co powinno być zrobione na początku) dla DR, tak myślę.

— Thomas Stringer

@gsharp: dokumentuje, jak wykonać kopię zapasową SMK. Interesowała mnie dokumentacja wyjaśniająca, dlaczego wymagana jest kopia zapasowa SMK podczas przesyłania DB zaszyfrowanej bazy TDE.

— Remus Rusanu,

Odpowiedzi:

Jeśli mówisz o kluczu głównym usługi SQL, zdarza się rzadkie zdarzenie, w którym naprawdę musisz go przywrócić.

Myślę o kilku scenariuszach, w których musisz przywrócić SMK ...

Jakoś się zepsuło.
Odbudowujesz serwer SQL i planujesz przywrócić każdą bazę danych, w tym systemowe bazy danych z kopii zapasowej. Zwykle w tym przypadku również nie trzeba przywracać SMK, jeśli używasz tego samego konta usługi SQL i hasła.

W TDE nie musisz przywracać SMK. Jak wszyscy mówili, wystarczy certyfikat i klucz prywatny. Nie musisz mieć tego samego klucza głównego bazy danych, ponieważ podczas tworzenia certyfikatu z kopii zapasowej jest on szyfrowany przez DMK komputera docelowego.

— Arijit
źródło

Gdy przenosisz bazę danych TDE do nowej instancji, musisz upewnić się, że odpowiedni certyfikat (lub klucz asymetryczny) znajduje się również w masterbazie danych miejsca docelowego . Jeśli tego nie zrobisz, pojawi się następujący błąd:

Msg 33111, poziom 16, stan 3, wiersz 2 Nie można znaleźć certyfikatu serwera z odciskiem palca „0xA085414434DB4A36B29 ..................”.

To nie klucz główny usługi musi być przenoszony wraz z kopią zapasową bazy danych obsługującą TDE, ale byłby to certyfikat. Załóżmy na przykład, że utworzyłeś DEK (klucz szyfrowania bazy danych) za pomocą certyfikatu mastero nazwie MyTDECert . Bez tego certyfikatu w docelowej instancji przywrócenie bazy danych nie będzie możliwe.

— Thomas Stringer
źródło

Tak, to jasne. Moje pytanie brzmi bardziej: dlaczego istnieje potrzeba (lub w jakim celu) tworzenia kopii zapasowej klucza głównego usługi. Zobacz technet.microsoft.com/en-us/library/aa337561

— gsharp

-1

Jednym z przypadków, w których należy wykonać kopię zapasową i przywrócić SMK, jest uaktualnienie topologii replikacji.

— JYatesDBA
źródło