Transparent Data Encryption (TDE) z kluczami zarządzanymi przez klienta na poziomie bazy danych

Dotyczy:Azure SQL Database

W tym artykule opisano przezroczyste szyfrowanie danych (TDE) przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych dla usługi Azure SQL Database.

Omówienie

Usługa Azure SQL oferuje klientom możliwość szyfrowania danych magazynowanych za pośrednictwem funkcji Transparent Data Encryption (TDE). Rozszerzanie funkcji TDE przy użyciu klucza zarządzanego przez klienta (CMK) umożliwia ochronę danych w stanie spoczynku, gdzie protektor TDE (klucz szyfrowania) jest przechowywany w Azure Key Vault lub zarządzanym module HSM platformy Azure, który szyfruje klucze szyfrowania bazy danych. Szyfrowanie TDE z kluczem cmk można ustawić na poziomie serwera i jest dziedziczone przez wszystkie zaszyfrowane bazy danych skojarzone z tym serwerem. Funkcję ochrony TDE można również ustawić jako klucz zarządzany przez klienta indywidualnie dla każdej bazy danych na serwerze. Każdy zasób Microsoft.Sql/servers/databases, który ma prawidłową, niepustą właściwość encryptionProtector, jest skonfigurowany do używania kluczy zarządzanych przez klienta na poziomie bazy danych. Klucze zarządzane przez klienta obsługują zarówno klucze asymetryczne (RSA), jak i symetryczne (AES), w zależności od wybranego magazynu kluczy.

W tym scenariuszu asymetryczny lub symetryczny klucz przechowywany w należącym do klienta i zarządzanym przez klienta Azure Key Vault lub w należącej do klienta i zarządzanej przez klienta usłudze Azure Managed HSM może być używany oddzielnie dla każdej bazy danych na serwerze do szyfrowania klucza szyfrowania bazy danych (DEK), nazywanego protektorem TDE. Istnieje możliwość dodawania kluczy, usuwania kluczy i zmieniania tożsamości zarządzanej przypisanej przez użytkownika dla każdej bazy danych. Aby uzyskać więcej informacji na temat tożsamości, zobacz Typy tożsamości zarządzanych na platformie Azure.

Dostępne są następujące funkcje:

• Tożsamość zarządzana przypisana przez użytkownika: do bazy danych można przypisać tożsamość zarządzaną przypisaną przez jednego użytkownika. Ta tożsamość może służyć do uzyskiwania dostępu do usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure i zarządzania kluczami szyfrowania.
• Zarządzanie kluczami szyfrowania: można włączyć co najmniej jeden klucz szyfrowania, który ma zostać dodany na poziomie bazy danych, i ustawić jeden z dodanych kluczy jako funkcję ochrony TDE. Dodawane klucze szyfrowania używają przypisanej przez użytkownika tożsamości zarządzanej przypisanej już do bazy danych w celu uzyskania dostępu do usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure.
• Tożsamość klienta federacyjna: Możesz również włączyć klucz zarządzany przez klienta (CMK) z usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure w innej dzierżawie Microsoft Entra, aby został ustawiony jako ochrona TDE na poziomie bazy danych, korzystając z tożsamości klienta federacyjnej ustawionej w Azure SQL Database. Dzięki temu można zarządzać funkcją TDE przy użyciu kluczy przechowywanych w Azure Key Vault należącym do innej dzierżawy lub Azure Managed HSM.

Korzyści z szyfrowania TDE zarządzanego przez klienta na poziomie bazy danych

Ponieważ coraz więcej dostawców usług, znanych również jako niezależni dostawcy oprogramowania (ISV), usługa Azure SQL Database służy do tworzenia swoich usług, wiele z nich zwraca się do elastycznych pul jako sposobu efektywnego dystrybuowania zasobów obliczeniowych między wieloma bazami danych. Dzięki wykorzystaniu baz danych poszczególnych klientów w udostępnionej elastycznej puli dostawcy oprogramowania mogą korzystać z możliwości optymalizacji wykorzystania zasobów przez pulę, jednocześnie zapewniając, że każda baza danych ma odpowiednie zasoby.

Istnieje jednak jedno istotne ograniczenie tego podejścia. Jeśli wiele baz danych jest hostowanych na tym samym serwerze logicznym usługi Azure SQL, współużytkuje funkcję ochrony TDE na poziomie serwera. Niezależni dostawcy oprogramowania (ISV) nie mogą oferować swoim klientom rzeczywistych możliwości korzystania z kluczy zarządzanych przez klienta (CMK). Bez możliwości zarządzania własnymi kluczami szyfrującymi klienci mogą być niechętni powierzeniu wrażliwych danych usłudze ISV, zwłaszcza jeśli przepisy wymagają pełnej kontroli nad kluczami szyfrowania.

TDE CMK na poziomie bazy danych pozwala dostawcom oprogramowania oferować możliwość zarządzania kluczami klienta swoim klientom i osiągać izolację zabezpieczeń, ponieważ każdy TDE protector bazy danych może potencjalnie należeć do odpowiedniego klienta dostawcy ISV w magazynie kluczy lub zarządzanym module HSM, którego klient jest właścicielem. Izolacja zabezpieczeń osiągnięta dla klientów ISV dotyczy zarówno klucza, jak i tożsamości używanej do uzyskania dostępu do klucza.

Na poniższym diagramie przedstawiono podsumowanie nowych funkcji wskazanych powyżej. Przedstawia dwa odrębne tenanty Microsoft Entra. Tenant Best Services, który zawiera logiczny serwer Azure SQL z dwiema bazami danych, DB 1 i DB 2, oraz element Azure Key Vault 1 z elementem Key 1, który uzyskuje dostęp do bazy danych DB 1 za pomocą UMI 1. Zarówno UMI 1 , jak i Key 1 reprezentują ustawienie poziomu serwera. Domyślnie wszystkie bazy danych początkowo utworzone na tym serwerze dziedziczą to ustawienie TDE z kluczem zarządzanym przez klienta (CMK). Tenant Contoso reprezentuje dzierżawę klienta, która zawiera Azure Key Vault 2 z elementem Key 2, oceniającym bazę danych DB 2 w całym tenancie w ramach międzytenantowej obsługi CMK na poziomie bazy danych przy użyciu konfiguracji Key 2 i UMI 2 dla tej bazy danych.

Aby uzyskać więcej informacji na temat konfiguracji tożsamości międzydzierżawowej, zobacz dokumentację na poziomie serwera Klucze zarządzane przez klienta między dzierżawami z funkcją Transparent Data Encryption.

Obsługiwane scenariusze zarządzania kluczami

W poniższej sekcji załóżmy, że istnieje serwer składający się z trzech baz danych (na przykład Database1, Database2i Database3).

Istniejący scenariusz

Key1 jest konfigurowany jako klucz zarządzany przez klienta na poziomie serwera logicznego. Wszystkie bazy danych na tym serwerze dziedziczą ten sam klucz.

• Serwer — Key1 ustawiony jako CMK
• Database1 – Key1 używany jako klucz CMK
• Database2 – Key1 używany jako klucz CMK
• Database3 – Key1 używany jako klucz CMK

Nowy obsługiwany scenariusz: serwer logiczny skonfigurowany przy użyciu klucza zarządzanego przez klienta

Key1 jest konfigurowany jako klucz zarządzany przez klienta na poziomie serwera logicznego. Na poziomie bazy danych można skonfigurować inny klucz zarządzany przez klienta (Key2).

• Serwer — Key1 ustawiony jako CMK
• Database1 – Key2 używany jako klucz CMK
• Database2 – Key1 używany jako klucz CMK
• Database3 – Key1 używany jako klucz CMK

Nowy obsługiwany scenariusz: serwer logiczny skonfigurowany przy użyciu klucza zarządzanego przez usługę

Serwer logiczny jest skonfigurowany do korzystania z klucza zarządzanego przez usługę (SMK) dla TDE. Na poziomie bazy danych można skonfigurować inny klucz zarządzany przez klienta (Key2).

• Serwer — klucz zarządzany przez usługę ustawiony jako protektor TDE
• Database1 — Key2 ustawiony jako CMK
• Database2 — Klucz zarządzany przez usługę ustawiony jako protektor TDE
• Database3 — Klucz zarządzany przez usługę ustawiony jako protektor TDE

Przywracanie do szyfrowania na poziomie serwera

Database1 skonfigurowano do używania klucza zarządzanego przez klienta na poziomie bazy danych na potrzeby TDE, podczas gdy serwer logiczny skonfigurowano do używania klucza zarządzanego przez usługę. Database1 można przywrócić do używania klucza zarządzanego przez usługę na poziomie serwera logicznego.

Transparent Data Encryption z kluczami zarządzanymi przez klienta wykorzystuje zewnętrzny klucz, zwany TDE protector, przechowywany w Azure Key Vault lub Azure Managed HSM do ochrony klucza szyfrowania bazy danych (DEK).

Obsługiwane typy kluczy i rozmiary

W zależności od oferty Azure SQL i konfiguracji TDE funkcja ochrony TDE może być wspierana za pomocą kluczy asymetrycznych lub symetrycznych przechowywanych w Azure Key Vault lub zarządzanym module HSM Azure Key Vault.

• Klucze asymetryczne (RSA lub RSA HSM)

  • Obsługiwane przez Azure Key Vault i Azure Key Vault Managed HSM
  • Obsługiwane rozmiary kluczy: 2048-bitowe i 3072-bitowe
  • Obsługiwane w przypadku Azure SQL Database, Azure SQL Managed Instance i Azure Synapse Analytics

• Klucze symetryczne (AES)

  • Wspierane w Azure Key Vault Premium (preview) oraz Azure Key Vault Managed HSM
  • Obsługiwane rozmiary kluczy: 128-bitowe, 192-bitowe i 256-bitowe
  • Obsługiwane tylko w przypadku Azure SQL Database, obecnie w publicznej wersji zapoznawczej. Ta możliwość może pojawić się w czasie w zależności od regionu i stanu wdrożenia usługi.

Ograniczenia dotyczące kluczy symetrycznych (AES)

Przy użyciu kluczy symetrycznych (AES) jako ochrony TDE, obsługiwane są tylko klucze przechowywane w Azure Key Vault Premium (podgląd) lub Azure Key Vault Managed HSM dla bieżących operacji cyklu życia klucza. Klienci mogą zaimportować klucz z lokalnego modułu bezpieczeństwa sprzętu (HSM) raz do Azure Key Vault Premium (podgląd) lub Azure Key Vault Managed HSM. Po początkowym imporcie wszystkie kolejne operacje cyklu życia klucza, w tym odzyskiwanie w momencie rzeczywistym, odzyskiwanie po awariach geograficznych oraz ponowna walidacja klucza, muszą opierać się na infrastrukturze Azure Key Vault Premium (przegląd) lub Azure Key Vault Managed HSM. Klienci są odpowiedzialni za obsługę lokalnych kopii zapasowych importowanych kluczy w celu obsługi scenariuszy odzyskiwania i ponownej instalacji. Te ograniczenia dotyczą tylko kluczy symetrycznych (AES) i nie mają zastosowania do kluczy asymetrycznych (RSA).

Wymagania dotyczące stanu klucza i jego ważności

• Jeśli określono datę aktywacji klucza, należy ustawić ją na datę i godzinę w przeszłości.
• Jeśli określono datę wygaśnięcia klucza, musi być ustawiona na datę i godzinę w przyszłości.
• Klucz musi być w stanie Włączone .

Kluczowe wymagania dotyczące importu

W przypadku importowania istniejącego klucza do Azure Key Vault klucz musi być podany w jednym z następujących obsługiwanych formatów:

• .pfx
• .byok
• .Kopia zapasowa

Aby zaimportować klucze chronione przez moduł HSM do zarządzanego modułu HSM platformy Azure, zobacz Importowanie kluczy chronionych przez moduł HSM do zarządzanego modułu HSM (BYOK).

Azure Key Vault i Azure Managed HSM - wymagania dotyczące zarządzanej tożsamości

Takie same wymagania dotyczące konfigurowania kluczy Azure Key Vault, kluczy zarządzanych modułem HSM platformy Azure oraz tożsamości zarządzanych, w tym ustawień kluczy i uprawnień przyznanych tożsamości, które mają zastosowanie do funkcji klucza zarządzanego przez klienta (CMK) na poziomie serwera, mają również zastosowanie do klucza zarządzanego przez klienta (CMK) na poziomie bazy danych. Aby uzyskać więcej informacji, zobacz Transparent Data Encryption (TDE) z użyciem CMK oraz Tożsamości zarządzane z użyciem CMK.

Zarządzanie kluczami

Rotacja funkcji ochrony TDE dla bazy danych oznacza przełączenie się na nowy klucz asymetryczny, który chroni bazę danych. Rotacja kluczy jest operacją online i powinna potrwać tylko kilka sekund. Operacja odszyfrowuje i ponownie szyfruje klucz szyfrowania bazy danych, a nie całą bazę danych.

Ochronę TDE można zmienić, modyfikując konfigurację tak, aby używała nowego klucza przechowywanego w usłudze Azure Key Vault lub Azure Key Vault Managed HSM. W zależności od oferty Azure SQL i obsługiwanej konfiguracji może to obejmować:

• Przełączanie na nową wersję tego samego klucza
• Przełączanie na inny klucz
• Przełączanie między obsługiwanymi typami kluczy, takimi jak asymetryczne (RSA) i klucze symetryczne (AES)

Po przypisaniu prawidłowej tożsamości zarządzanej przypisanej przez użytkownika do bazy danych obracanie klucza na poziomie bazy danych jest operacją CRUD bazy danych, która obejmuje aktualizowanie właściwości ochrony szyfrowania bazy danych. Set-AzSqlDatabase i właściwość -EncryptionProtector mogą służyć do obracania kluczy. Aby utworzyć nową bazę danych skonfigurowaną przy użyciu klucza CMK na poziomie bazy danych, można użyć polecenia New-AzSqlDatabase z parametrami -EncryptionProtector, -AssignIdentity i -UserAssignedIdentityId.

Nowe klucze można dodawać, a istniejące klucze można usunąć z bazy danych przy użyciu podobnych żądań i zmodyfikować właściwość keys dla zasobu bazy danych. Set-AzSqlDatabase z parametrem -KeyList i -KeysToRemove może służyć do tych operacji. Aby pobrać ustawienie funkcji ochrony szyfrowania, tożsamości i kluczy, można użyć polecenia Get-AzSqlDatabase . Zasób Azure Resource Manager Microsoft.Sql/servers/databases domyślnie wyświetla tylko ochronę TDE i tożsamość zarządzaną skonfigurowane dla bazy danych. Aby rozwinąć pełną listę kluczy, potrzebne są inne parametry, takie jak -ExpandKeyList . Ponadto -KeysFilter "current" oraz wartość określająca punkt w czasie (na przykład 2023-01-01) mogą służyć do pobierania aktualnie używanych kluczy oraz kluczy używanych w przeszłości w określonym momencie.

Automatyczne obracanie kluczy

Automatyczna rotacja kluczy jest dostępna na poziomie bazy danych i może być używana z kluczami usługi Azure Key Vault lub zarządzanym modułem HSM platformy Azure. Rotacja jest wyzwalana po wykryciu nowej wersji klucza, a protektor TDE jest automatycznie rotowany w ciągu 24 godzin. Aby uzyskać informacje o konfiguracji automatycznej rotacji kluczy za pomocą PowerShell lub Azure CLI, zobacz Automatyczna rotacja kluczy na poziomie bazy danych.

Uprawnienie do zarządzania kluczami

Wybierz typ magazynu kluczy, którego chcesz użyć.

Klucze zarządzane przez klienta między dzierżawcami

Klucze zarządzane przez klienta między dzierżawami z transparentnym szyfrowaniem danych opisuje sposób konfigurowania sfederowanego identyfikatora klienta dla kluczy CMK na poziomie serwera. Podobną konfigurację należy przeprowadzić dla klucza zarządzanego przez klienta na poziomie bazy danych, a identyfikator klienta federacyjnego należy dodać w ramach żądań interfejsu API Set-AzSqlDatabase lub New-AzSqlDatabase.

Bazę danych skonfigurowaną za pomocą klucza zarządzanego przez klienta (CMK) na poziomie bazy danych można przywrócić do szyfrowania na poziomie serwera, jeśli serwer logiczny jest skonfigurowany za pomocą klucza zarządzanego przez usługę, przy użyciu polecenia cmdlet Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

W przypadku niedostępnej funkcji ochrony TDE zgodnie z opisem w artykule Transparent Data Encryption (TDE) z kluczem CMK po skorygowaniu dostępu do klucza można użyć metody Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation w celu udostępnienia bazy danych.

Uwagi dodatkowe

• Jeśli funkcja TDE z kluczem CMK jest już włączona na poziomie serwera, ustawienie klucza CMK dla określonej bazy danych zastępuje ustawienie klucza CMK na poziomie serwera (klucz szyfrowania bazy danych, DEK, zostaje ponownie zaszyfrowany przy użyciu protektora TDE na poziomie bazy danych).
• Wszelkie zmiany lub rotacja klucza na poziomie serwera logicznego nie wpływają na ustawienia CMK na poziomie bazy danych, a baza danych nadal korzysta z własnego ustawienia CMK.
• CMK na poziomie bazy danych nie jest obsługiwany przy użyciu języka Transact-SQL (T-SQL).
• Tożsamość zarządzana przypisana przez użytkownika serwera logicznego (UMI) może być używana na poziomie bazy danych. Zaleca się jednak użycie dedykowanego identyfikatora UMI dla klucza CMK zarządzanego przez klienta na poziomie bazy danych.
• Ustawienia CMK na poziomie serwera w wielu dzierżawach nie wpływają na poszczególne bazy danych skonfigurowane z użyciem CMK na poziomie bazy danych i nadal korzystają z własnej konfiguracji dla pojedynczej dzierżawy lub wielu dzierżaw.
• Na poziomie bazy danych można ustawić tylko jedną tożsamość zarządzaną przypisaną przez użytkownika.

Migracja istniejących baz danych do CMK na poziomie bazy danych

Nowe bazy danych można skonfigurować z użyciem CMK na poziomie bazy danych podczas ich tworzenia, a istniejące bazy danych na serwerach skonfigurowanych z użyciem kluczy zarządzanych przez usługę można migrować do CMK na poziomie bazy danych przy użyciu operacji opisanych w temacie Zarządzanie tożsamościami i kluczami dla szyfrowania TDE przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych. Aby przeprowadzić migrację baz danych skonfigurowanych z kluczem CMK na poziomie serwera lub z replikacją geograficzną, wymagane są dodatkowe kroki, zgodnie z opisem w poniższych sekcjach.

Baza danych skonfigurowana z użyciem CMK na poziomie serwera bez replikacji geograficznej

1. Użyj sys.dm_db_log_info (Transact-SQL) — sql Server dla bazy danych i poszukaj plików dziennika wirtualnego (VLFs), które są aktywne.
2. Dla wszystkich aktywnych plików VLF zapisz vlf_encryptor_thumbprint z wyniku sys.dm_db_log_info.
3. Użyj widoku sys.dm_database_encryption_keys (Transact-SQL) — SQL Server dla swojej bazy danych, aby sprawdzić encryptor_thumbprint. Zarejestruj element encryptor_thumbprint.
4. Użyj polecenia cmdlet Get-AzSqlServerKeyVaultKey, aby pobrać wszystkie klucze na poziomie serwera skonfigurowane na serwerze logicznym. Spośród wyników wybierz te, które mają ten sam odcisk kciuka odpowiadający Twojej liście z poprzedniego kroku.
5. Wykonaj wywołanie interfejsu API aktualizacji bazy danych dla bazy danych, którą chcesz zmigrować, wraz z ochroną tożsamości i ochroną szyfrowania. Przekaż powyższe klucze jako klucze na poziomie bazy danych, używając Set-AzSqlDatabase z parametrami -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (a jeśli to konieczne, -FederatedClientId).

Baza danych skonfigurowana przy użyciu klucza CMK na poziomie serwera z replikacją geograficzną

1. Postępuj zgodnie z krokami od 1 do 4 wspomnianymi w poprzedniej sekcji, aby pobrać listę kluczy potrzebnych do migracji.
2. Wykonaj wywołanie interfejsu API aktualizacji bazy danych dla podstawowej i pomocniczej bazy danych, które chcesz zmigrować, wraz z tożsamością i poprzednimi kluczami jako kluczami na poziomie bazy danych, używając polecenia Set-AzSqlDatabase i parametru -KeyList. Nie ustawiaj jeszcze funkcji ochrony szyfrowania.
3. Dodaj klucz na poziomie bazy danych, którego chcesz używać jako główny ochronnik w bazach danych, do bazy drugoplanowej. Użyj polecenia Set-AzSqlDatabase z poleceniem -KeyList , aby dodać ten klucz do pomocniczej bazy danych.
4. Po dodaniu klucza ochronnego szyfrowania do bazy wtórnej, użyj Set-AzSqlDatabase , aby ustawić go jako ochronę szyfrowania w bazie głównej, używając parametru -EncryptionProtector .
5. Ustaw klucz jako ochronę szyfrowania w drugiej bazie danych, jak opisano w kroku 4, aby zakończyć migrację.

Replikacja geograficzna i wysoka dostępność

Zarówno w scenariuszach aktywnych replikacji geograficznej, jak i grupów przełączania awaryjnego, bazy danych podstawowe i pomocnicze mogą być połączone z tym samym magazynem kluczy lub zarządzanym modułem HSM (w dowolnym regionie), albo z osobnymi magazynami kluczy lub zarządzanymi modułami HSM. Jeśli oddzielne magazyny kluczy lub zarządzane moduły HSM są połączone z serwerami podstawowymi i pomocniczymi, klient jest odpowiedzialny za utrzymywanie jednolitego materiału klucza w tych magazynach lub zarządzanych modułach HSM, aby geo-secondary było zsynchronizowane i mogło przejąć klucz do użycia z połączonego magazynu kluczy lub zarządzanego modułu HSM, jeśli serwer podstawowy stanie się niedostępny z powodu awarii w regionie, a tryb failover zostanie wyzwolony. Można skonfigurować maksymalnie cztery elementy podrzędne, a łańcuchowanie (elementy podrzędne elementów podrzędnych) nie jest obsługiwane.

Aby skonfigurować aktywną replikację geograficzną dla bazy danych skonfigurowanej z użyciem CMK na poziomie bazy danych, należy utworzyć replikę wtórną z prawidłową tożsamością zarządzaną przypisaną przez użytkownika oraz z listą kluczy aktualnie używanych przez podstawową bazę danych. Listę bieżących kluczy można pobrać z podstawowej bazy danych przy użyciu niezbędnych filtrów i parametrów zapytania lub programu PowerShell i interfejsu wiersza polecenia platformy Azure. Kroki wymagane do skonfigurowania repliki geograficznej takiej bazy danych to:

1. Wstępnie wypełnij listę kluczy używanych przez podstawową bazę danych przy użyciu polecenia Get-AzSqlDatabase oraz parametrów -ExpandKeyList i -KeysFilter "current". Wyklucz -KeysFilter , jeśli chcesz pobrać wszystkie klucze.
2. Wybierz tożsamość zarządzaną przypisaną przez użytkownika (oraz sfederowany identyfikator klienta w przypadku konfigurowania dostępu między dzierżawcami).
3. Utwórz nową bazę danych jako pomocniczą przy użyciu polecenia New-AzSqlDatabaseSecondary i w wywołaniu interfejsu API podaj wstępnie wypełnioną listę kluczy uzyskaną ze źródłowej bazy danych oraz powyższą tożsamość (a także sfederowany identyfikator klienta, jeśli konfigurujesz dostęp między dzierżawami), używając parametrów -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (oraz, w razie potrzeby, -FederatedClientId).
4. Użyj polecenia New-AzSqlDatabaseCopy , aby utworzyć kopię bazy danych z tymi samymi parametrami w poprzednim kroku.

Aby uzyskać więcej informacji, Konfiguracja replikacji geograficznej i przywracania kopii zapasowych w celu przezroczystego szyfrowania danych z kluczami zarządzanymi przez klienta na poziomie bazy danych opisuje, jak skonfigurować replikację geograficzną i grupy failover przy użyciu REST API, programu PowerShell i interfejsu wiersza polecenia platformy Azure.

Tworzenie kopii zapasowych i przywracanie baz danych przy użyciu funkcji TDE z kluczem zarządzanym przez klienta na poziomie bazy danych

Po zaszyfrowaniu bazy danych za pomocą funkcji TDE przy użyciu klucza z usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure wszystkie nowo wygenerowane kopie zapasowe są również szyfrowane przy użyciu tej samej funkcji ochrony TDE. Po zmianie funkcji ochrony TDE stare kopie zapasowe bazy danych nie są aktualizowane w celu korzystania z najnowszej funkcji ochrony TDE. Aby przywrócić kopię zapasową zaszyfrowaną za pomocą funkcji ochrony TDE z usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure skonfigurowanego na poziomie bazy danych, upewnij się, że materiał klucza jest dostarczany do docelowej bazy danych. Zalecamy zachowanie wszystkich starych wersji ochraniacza TDE w magazynie kluczy lub zarządzanym module HSM, co umożliwia przywracanie kopii zapasowych bazy danych.

przywracanie do punktu w czasie

W przypadku przywracania bazy danych skonfigurowanej przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych są wymagane następujące kroki:

1. Wstępnie wypełnij listę kluczy używanych przez podstawową bazę danych przy użyciu polecenia Get-AzSqlDatabase oraz parametrów -ExpandKeyList i -KeysFilter "2023-01-01". 2023-01-01 to przykład punktu w czasie, do którego chcesz przywrócić bazę danych. Wyklucz -KeysFilter , jeśli chcesz pobrać wszystkie klucze.
2. Wybierz tożsamość zarządzaną przypisaną przez użytkownika (oraz sfederowany identyfikator klienta w przypadku konfigurowania dostępu między dzierżawcami).
3. Użyj Restore-AzSqlDatabase z parametrem -FromPointInTimeBackup i podaj uprzednio wypełnioną listę kluczy uzyskanych w powyższych krokach oraz powyższą tożsamość (i identyfikator klienta federacyjnego, jeśli konfigurujesz dostęp między dzierżawami) w wywołaniu interfejsu API przy użyciu parametrów -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (a w razie potrzeby także -FederatedClientId).

Przywracanie usuniętej bazy danych

Do przywracania usuniętej bazy danych skonfigurowanej z kluczami zarządzanymi przez klienta na poziomie bazy danych wymagane są następujące kroki:

1. Wstępnie wypełnij listę kluczy używanych przez główną bazę danych, uruchamiając Get-AzSqlDeletedDatabaseBackup z parametrem -ExpandKeyList . Przekaż wszystkie klucze, których używała baza danych źródłowa. Alternatywnie możesz spróbować przywrócenia, używając kluczy udostępnionych podczas usuwania jako .-KeysFilter
2. Wybierz tożsamość zarządzaną przypisaną przez użytkownika (oraz sfederowany identyfikator klienta w przypadku konfigurowania dostępu między dzierżawcami).
3. Użyj Restore-AzSqlDatabase z parametrem -FromDeletedDatabaseBackup i podaj w wywołaniu interfejsu API, przy użyciu parametrów -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (oraz, w razie potrzeby, -FederatedClientId), wstępnie wypełnioną listę kluczy uzyskanych w powyższych krokach oraz z powyższej tożsamości (a także identyfikator klienta federacyjnego, jeśli konfigurujesz dostęp między dzierżawami).

Przywracanie geograficzne

W przypadku przywracania geograficznego bazy danych skonfigurowanej przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych są wymagane następujące kroki:

• Wstępnie wypełnić listę kluczy używanych przez podstawową bazę danych za pomocą polecenia Get-AzSqlDatabaseGeoBackup i elementu -ExpandKeyList, aby pobrać wszystkie klucze.
• Wybierz tożsamość zarządzaną przypisaną przez użytkownika (oraz sfederowany identyfikator klienta w przypadku konfigurowania dostępu między dzierżawcami).
• Użyj Restore-AzSqlDatabase z parametrem -FromGeoBackup i podaj w wywołaniu interfejsu API, przy użyciu parametrów -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (oraz, w razie potrzeby, -FederatedClientId), wstępnie wypełnioną listę kluczy uzyskanych w powyższych krokach oraz z powyższej tożsamości (a także identyfikator klienta federacyjnego, jeśli konfigurujesz dostęp między dzierżawami).

Ograniczenia

Funkcja kluczy zarządzanych przez klienta na poziomie bazy danych nie obsługuje rotacji kluczy, gdy pliki dziennika wirtualnego bazy danych są szyfrowane przy użyciu starego klucza, który różni się od bieżącej podstawowej ochrony bazy danych. Błąd zgłaszany w tym przypadku to:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Rotacja kluczy funkcji ochrony TDE na poziomie bazy danych jest blokowana, gdy aktywne transakcje przechowują dziennik zaszyfrowany przy użyciu starych kluczy.

Aby lepiej zrozumieć ten scenariusz, rozważmy następującą oś czasu:

• Time t0 = Baza danych jest tworzona bez szyfrowania
• Time t1 = Ta baza danych jest chroniona przez Thumbprint A, który jest kluczem zarządzanym przez klienta na poziomie bazy danych.
• Czas t2 = Ochraniacz bazy danych jest zmieniany na nowy klucz zarządzany przez klienta na poziomie bazy danych, Thumbprint B.
• Czas t3 = zażądano zmiany zabezpieczenia na Thumbprint C.
• Jeśli aktywne VLF-y używają Thumbprint A, obrót jest niedozwolony.
• Jeśli aktywne VLF-y nie używają Thumbprint A, rotacja jest dozwolona.

Możesz użyć sys.dm_db_log_info (Transact-SQL) — widok programu SQL Server dla bazy danych i wyszukać aktywne pliki dziennika wirtualnego. Powinien być widoczny aktywny plik VLF zaszyfrowany pierwszym kluczem (na przykład Thumbprint A). Gdy w wyniku wstawiania danych zostanie wygenerowana odpowiednia ilość wpisów dziennika, ten stary plik VLF zostanie opróżniony i powinno być możliwe przeprowadzenie kolejnej rotacji kluczy.

Jeśli uważasz, że coś opóźnia przetwarzanie dziennika dłużej, niż oczekiwano, zapoznaj się z poniższą dokumentacją, aby uzyskać więcej informacji na temat rozwiązywania problemów:

• sys.dm_db_log_stats (Transact-SQL) dla możliwych log_truncation_holdup_reason wartości.
• Rozwiązywanie problemów z błędem 9002 związanym z pełnym dziennikiem transakcji.

Treści powiązane

Zapoznaj się z poniższą dokumentacją dotyczącą różnych operacji CMK na poziomie bazy danych:

• Zarządzanie tożsamościami i kluczami dla funkcji TDE przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych
• Konfigurowanie replikacji geograficznej i przywracania kopii zapasowych na potrzeby przezroczystego szyfrowania danych przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych