Udostępnij za pośrednictwem

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

  • Artykuł

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.

Uwaga

Klucz cmK TDE na poziomie bazy danych jest dostępny dla usługi Azure SQL Database (wszystkie wersje usługi SQL Database). Nie jest ona dostępna dla usługi Azure SQL Managed Instance, lokalnych programu SQL Server, maszyn wirtualnych platformy Azure i usługi Azure Synapse Analytics (dedykowane pule SQL (dawniej SQL DW)).

Uwaga

Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).

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 magazynowanych, gdzie funkcja ochrony TDE (klucz szyfrowania) jest przechowywana w usłudze Azure Key Vault, która szyfruje klucze szyfrowania bazy danych. Obecnie funkcja TDE z kluczem cmK jest ustawiana na poziomie serwera i jest dziedziczona przez wszystkie zaszyfrowane bazy danych skojarzone z tym serwerem. Ta nowa funkcja umożliwia ustawienie funkcji ochrony TDE jako klucza zarządzanego przez klienta indywidualnie dla każdej bazy danych na serwerze. Każdy Microsoft.Sql/servers/databases zasób z prawidłową właściwością nonempty encryptionProtector jest skonfigurowany z kluczami zarządzanymi przez klienta na poziomie bazy danych.

W tym scenariuszu klucz asymetryczny, który jest przechowywany w usłudze Azure Key Vault (AKV) należącym do klienta i zarządzanym przez klienta, może być używany indywidualnie dla każdej bazy danych na serwerze w celu zaszyfrowania klucza szyfrowania bazy danych (DEK), nazywanego funkcją ochrony 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 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.
  • Tożsamość klienta federacyjnego: możesz również włączyć klucz zarządzany przez klienta (CMK) z usługi Azure Key Vault w innej dzierżawie usługi Microsoft Entra, która ma być ustawiana jako funkcja ochrony TDE na poziomie bazy danych, korzystając z tożsamości klienta federacyjnego ustawionego w usłudze Azure SQL Database. Dzięki temu można zarządzać funkcją TDE przy użyciu kluczy przechowywanych w usłudze Azure Key Vault innej dzierżawy.

Uwaga

Tożsamość zarządzana przypisana przez system nie jest obsługiwana na poziomie bazy danych.

Korzyści wynikające 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. Dostawcy oprogramowania niezależnego dostawcy oprogramowania nie mogą oferować klientom prawdziwych funkcji kluczy zarządzanych przez klienta. Bez możliwości zarządzania własnymi kluczami szyfrowania klienci mogą być niezdecydowani, aby przekazać poufne dane do usługi niezależnego dostawcy oprogramowania, szczególnie jeśli przepisy dotyczące zgodności wymagają od nich pełnej kontroli nad kluczami szyfrowania.

Dzięki kluczowi cmK TDE na poziomie bazy danych dostawcy oprogramowania mogą oferować klientom funkcję CMK i zapewnić izolację zabezpieczeń, ponieważ funkcja ochrony TDE każdej bazy danych może być potencjalnie własnością odpowiedniego klienta niezależnego dostawcy oprogramowania w magazynie kluczy, którego jest właścicielem. Izolacja zabezpieczeń osiągnięta dla klientów niezależnego dostawcy oprogramowania jest zarówno pod względem klucza , jak i tożsamości używanej do uzyskiwania dostępu do klucza.

Na poniższym diagramie przedstawiono podsumowanie nowych funkcji wskazanych powyżej. Przedstawia dwie oddzielne dzierżawy firmy Microsoft Entra. Dzierżawa zawierająca Best Services serwer logiczny Usługi Azure SQL z dwoma bazami danych DB 1 i DB 2, oraz Azure Key Vault 1 z dostępem Key 1 do bazy danych DB 1 przy użyciu polecenia UMI 1. Zarówno UMI 1 , jak i Key 1 reprezentują ustawienie poziomu serwera. Domyślnie wszystkie bazy danych utworzone początkowo na tym serwerze dziedziczą to ustawienie dla funkcji TDE za pomocą klucza zarządzanego przez klienta. Dzierżawa Contoso reprezentuje dzierżawę klienta, która zawiera Key 2 Azure Key Vault 2 ocenę bazy danych DB 2 w dzierżawie w ramach obsługi między dzierżawami na poziomie bazy danych przy użyciu i Key 2 UMI 2 konfiguracji dla tej bazy danych.

Konfigurowanie i funkcjonowanie funkcji TDE zarządzanej przez klienta na poziomie bazy danych

Aby uzyskać więcej informacji na temat konfiguracji tożsamości między dzierżawami, zobacz dokument dotyczący kluczy zarządzanych przez klienta między dzierżawami z przezroczystym szyfrowaniem danych.

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 klucz 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 klucz cmk
  • Database1 — Key2 używany jako klucz cmk
  • Database2 — Key1 używany jako klucz cmk
  • Database3 — Key1 używany jako klucz cmk

Uwaga

Jeśli serwer logiczny jest skonfigurowany przy użyciu kluczy zarządzanych przez klienta dla funkcji TDE, nie można wybrać pojedynczej bazy danych na tym serwerze logicznym w celu korzystania z klucza zarządzanego przez usługę na potrzeby przezroczystego szyfrowania danych.

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

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

  • Serwer — klucz zarządzany przez usługę ustawiony jako funkcja ochrony TDE
  • Database1 — Key2 ustaw jako klucz cmk
  • Database2 — Klucz zarządzany przez usługę ustawiony jako funkcja ochrony TDE
  • Database3 — Klucz zarządzany przez usługę ustawiony jako funkcja ochrony TDE

Przywracanie do szyfrowania na poziomie serwera

Database1 program jest skonfigurowany przy użyciu klucza zarządzanego przez klienta na poziomie bazy danych dla funkcji TDE, podczas gdy serwer logiczny jest skonfigurowany przy użyciu klucza zarządzanego przez usługę. Database1 Można przywrócić klucz zarządzany przez usługę na poziomie serwera logicznego.

Uwaga

Jeśli serwer logiczny jest skonfigurowany z kluczem CMK dla funkcji TDE, baza danych skonfigurowana z kluczem CMK na poziomie bazy danych nie może zostać przywrócona do szyfrowania na poziomie serwera.

Mimo że operacja przywracania jest obsługiwana tylko wtedy, gdy serwer logiczny jest skonfigurowany z kluczem zarządzanym przez usługę podczas korzystania z funkcji TDE, bazę danych skonfigurowaną na poziomie bazy danych cmK można przywrócić do serwera skonfigurowanego za pomocą klucza zarządzanego przez klienta, pod warunkiem, że serwer ma dostęp do wszystkich kluczy używanych przez źródłową bazę danych z prawidłową tożsamością.

Wymagania dotyczące usługi Key Vault i tożsamości zarządzanej

Te same wymagania dotyczące konfigurowania kluczy usługi Azure Key Vault (AKV) i 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 na poziomie serwera( CMK), mają również zastosowanie do klucza zarządzanego na poziomie bazy danych. Aby uzyskać więcej informacji, zobacz Transparent Data Encryption (TDE) with CMK and Managed Identities with CMK (Transparent Data Encryption) and Managed Identities with CMK (Transparent Data Encryption) with CMK (Transparent Data Encryption) with CMK and Managed Identities with CMK (Transparent Data Encryption( Transparent Data Encryption) with 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. 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, -AssignIdentityi -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 usługi Azure Resource Manager Microsoft.Sql/servers/databases domyślnie pokazuje tylko funkcję ochrony TDE i tożsamość zarządzaną skonfigurowaną w bazie danych. Aby rozwinąć pełną listę kluczy, potrzebne są inne parametry, takie jak -ExpandKeyList . -KeysFilter "current" Ponadto i wartość punktu w czasie (na przykład 2023-01-01) może służyć do pobierania bieżących kluczy używanych i kluczy używanych w przeszłości w określonym punkcie w czasie.

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. Rotacja jest wyzwalana po wykryciu nowej wersji klucza i zostanie automatycznie obrócona w ciągu 24 godzin. Aby uzyskać informacje na temat konfigurowania automatycznego obracania kluczy przy użyciu witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure, zobacz Automatyczne obracanie kluczy na poziomie bazy danych.

Uprawnienie do zarządzania kluczami

W zależności od modelu uprawnień magazynu kluczy (zasad dostępu lub kontroli dostępu opartej na rolach platformy Azure) można udzielić dostępu do magazynu kluczy przez utworzenie zasad dostępu w magazynie kluczy lub utworzenie nowego przypisania roli RBAC platformy Azure.

Model uprawnień zasad dostępu

Aby baza danych korzystała z funkcji ochrony TDE przechowywanej w usłudze AKV do szyfrowania klucza szyfrowania klucza, administrator magazynu kluczy musi przyznać następujące prawa dostępu do tożsamości zarządzanej przypisanej przez użytkownika bazy danych przy użyciu unikatowej tożsamości firmy Microsoft Entra:

  • get — w celu pobrania części publicznej i właściwości klucza w usłudze Azure Key Vault.
  • wrapKey — aby móc chronić (szyfrować) klucz szyfrowania danych.
  • unwrapKey — aby można było usunąć ochronę (odszyfrować) klucz szyfrowania danych.

Model uprawnień RBAC platformy Azure

Aby baza danych korzystała z funkcji ochrony TDE przechowywanej w usłudze AKV na potrzeby szyfrowania klucza SZYFROWANIA, należy dodać nowe przypisanie roli RBAC platformy Azure z rolą Użytkownik szyfrowania usługi kryptograficznej usługi Key Vault dla tożsamości zarządzanej przypisanej przez użytkownika bazy danych przy użyciu unikatowej tożsamości firmy Microsoft Entra.

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

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

Uwaga

Jeśli aplikacja z wieloma dzierżawami nie została dodana do zasad dostępu magazynu kluczy z wymaganymi uprawnieniami (Get, Wrap Key, Unwrap Key), użycie aplikacji do federacji tożsamości w witrynie Azure Portal spowoduje wyświetlenie błędu. Przed skonfigurowaniem tożsamości klienta federacyjnego upewnij się, że uprawnienia są poprawnie skonfigurowane.

Bazę danych skonfigurowaną przy użyciu klucza zarządzanego na poziomie bazy danych można przywrócić do szyfrowania na poziomie serwera, jeśli serwer logiczny jest skonfigurowany przy użyciu klucza zarządzanego przez usługę przy użyciu polecenia 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.

Uwaga

Zarządzanie tożsamościami i kluczami dla funkcji TDE z kluczami zarządzanymi przez klienta na poziomie bazy danych opisuje szczegółowo operacje zarządzania tożsamościami i kluczami na poziomie bazy danych, a także program PowerShell, interfejs wiersza polecenia platformy Azure i przykłady interfejsu API REST.

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 zarządzanego na poziomie serwera (klucz szyfrowania szyfrowania danych bazy danych zostanie ponownie zaszyfrowany za pomocą funkcji ochrony TDE na poziomie bazy danych).
  • Wszelkie zmiany klucza na poziomie serwera logicznego lub rotacje nie mają wpływu na ustawienia klucza cmK na poziomie bazy danych, a baza danych nadal używa własnego ustawienia cmK.
  • Klucz CMK na poziomie bazy danych nie jest obsługiwany za pomocą 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 wyznaczonego interfejsu użytkownika dla klucza zarządzanego na poziomie bazy danych.
  • Ustawienia klucza zarządzanego na poziomie serwera między dzierżawami nie mają wpływu na poszczególne bazy danych skonfigurowane z kluczem cmK na poziomie bazy danych i nadal korzystają z własnej pojedynczej dzierżawy lub konfiguracji między dzierżawami.
  • Na poziomie bazy danych można ustawić tylko jedną tożsamość zarządzaną przypisaną przez użytkownika.

Uwaga

Tożsamości zarządzane w bazie danych muszą zostać ponownie przydzielone, jeśli nazwa bazy danych zostanie zmieniona.

Migracja istniejących baz danych do klucza zarządzanego na poziomie bazy danych

Nowe bazy danych można skonfigurować za pomocą klucza zarządzanego na poziomie bazy danych podczas tworzenia, a istniejące bazy danych na serwerach skonfigurowanych przy użyciu kluczy zarządzanych przez usługę można migrować do klucza zarządzanego przez klienta na poziomie bazy danych przy użyciu operacji opisanych w temacie Zarządzanie tożsamościami i kluczami dla szyfrowania TDE na poziomie bazy danych. Aby przeprowadzić migrację baz danych skonfigurowanych przy użyciu klucza cmK na poziomie serwera lub replikacji geograficznej, należy wykonać inne kroki zgodnie z opisem w poniższych sekcjach.

Baza danych skonfigurowana przy użyciu klucza zarządzanego 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. W przypadku wszystkich aktywnych plików VDF zapisz wynikvlf_encryptor_thumbprint.sys.dm_db_log_info
  3. Użyj widoku sys.dm_database_encryption_keys (Transact-SQL) — sql Server, aby sprawdzić encryptor_thumbprintbazę danych. Zarejestruj element encryptor_thumbprint.
  4. Użyj polecenia cmdlet Get-AzSqlServerKeyVaultKey, aby pobrać wszystkie klucze na poziomie serwera skonfigurowane na serwerze logicznym. Z wyników wybierz te, które mają ten sam odcisk palca zgodny z listą z powyższego wyniku.
  5. Wywołaj interfejs API bazy danych aktualizacji do bazy danych, która ma zostać zmigrowana wraz z funkcją ochrony tożsamości i szyfrowania. Przekaż powyższe klucze jako klucze na poziomie bazy danych przy użyciu parametrów Set-AzSqlDatabase przy użyciu -UserAssignedIdentityIdparametrów , , -KeyList-AssignIdentity, -EncryptionProtector (i w -FederatedClientIdrazie potrzeby).

Ważne

Tożsamość używana w żądaniu aktualizacji bazy danych musi mieć dostęp do wszystkich kluczy przekazywanych jako dane wejściowe.

Baza danych skonfigurowana z kluczem cmK na poziomie serwera z replikacją geograficzną

  1. Wykonaj kroki od (1) do (4) wymienione w poprzedniej sekcji, aby pobrać listę kluczy, które będą potrzebne do migracji.
  2. Wywołaj interfejs API aktualizacji bazy danych do podstawowej i pomocniczej bazy danych, która ma zostać zmigrowana, wraz z tożsamością i powyższymi kluczami jako kluczami na poziomie bazy danych przy użyciu polecenia Set-AzSqlDatabase i parametru -KeyList . Nie ustawiaj jeszcze funkcji ochrony szyfrowania.
  3. Klucz na poziomie bazy danych, który ma być używany jako podstawowa funkcja ochrony baz danych, musi zostać najpierw dodany do pomocniczej bazy danych. Użyj polecenia Set-AzSqlDatabase z poleceniem -KeyList , aby dodać ten klucz do pomocniczej bazy danych.
  4. Po dodaniu klucza ochrony szyfrowania do pomocniczej bazy danych użyj polecenia Set-AzSqlDatabase , aby ustawić go jako funkcję ochrony szyfrowania w podstawowej bazie danych przy użyciu parametru -EncryptionProtector .
  5. Ustaw klucz jako funkcję ochrony szyfrowania w pomocniczej bazie danych zgodnie z opisem w sekcji (4), aby ukończyć migrację.

Ważne

Aby przeprowadzić migrację baz danych skonfigurowanych przy użyciu klucza zarządzanego przez usługę na poziomie serwera i replikacji geograficznej, wykonaj kroki (3), (4) i (5) z tej sekcji.

Replikacja geograficzna i wysoka dostępność

Zarówno w scenariuszach aktywnych replikacji geograficznej, jak i grup trybu failover, bazy danych podstawowych i pomocniczych mogą być połączone z tym samym magazynem kluczy (w dowolnym regionie) lub oddzielnymi magazynami kluczy. Jeśli z serwerami podstawowymi i pomocniczymi połączone są oddzielne magazyny kluczy, klient jest odpowiedzialny za zachowanie spójności materiału klucza w magazynach kluczy, dzięki czemu pomocniczy obszar geograficzny jest zsynchronizowany i można go przejąć przy użyciu tego samego klucza z połączonego magazynu kluczy, gdy podstawowy stanie się niedostępny z powodu awarii w regionie i zostanie wyzwolony tryb failover. Można skonfigurować maksymalnie cztery sekundy, a tworzenie łańcuchów (drugich plików drugiego) nie jest obsługiwane.

Aby ustanowić aktywną replikację geograficzną dla bazy danych skonfigurowanej przy użyciu klucza zarządzanego na poziomie bazy danych, należy utworzyć replikę pomocniczą z prawidłową tożsamością zarządzaną przypisaną przez użytkownika oraz listę bieżących kluczy 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łnianie listy kluczy używanych przez podstawową bazę danych przy użyciu polecenia Get-AzSqlDatabase oraz -ExpandKeyList parametrów i -KeysFilter "current" . Wyklucz -KeysFilter , jeśli chcesz pobrać wszystkie klucze.
  2. Wybierz tożsamość zarządzaną przypisaną przez użytkownika (i identyfikator klienta federacyjnego w przypadku konfigurowania dostępu między dzierżawami).
  3. Utwórz nową bazę danych jako pomocniczą przy użyciu polecenia New-AzSqlDatabaseSecondary i podaj wstępnie wypełnioną listę kluczy uzyskanych z źródłowej bazy danych i powyższej tożsamości (i federacyjnego klienta DI w przypadku konfigurowania dostępu między dzierżawami) w wywołaniu interfejsu API przy użyciu -KeyListparametrów , , -AssignIdentity, -UserAssignedIdentityId-EncryptionProtector (i w razie potrzeby-FederatedClientId).
  4. Użyj polecenia New-AzSqlDatabaseCopy , aby utworzyć kopię bazy danych z tymi samymi parametrami w poprzednim kroku.

Ważne

Baza danych skonfigurowana z kluczem CMK na poziomie bazy danych musi mieć replikę (lub kopię) skonfigurowaną z kluczem CMK na poziomie bazy danych. Replika nie może używać ustawień szyfrowania na poziomie serwera.

Aby można było użyć bazy danych skonfigurowanej z kluczem CMK na poziomie bazy danych w grupie trybu failover, powyższe kroki tworzenia repliki pomocniczej o takiej samej nazwie jak replika podstawowa muszą być używane na serwerze pomocniczym. Po skonfigurowaniu tej repliki pomocniczej bazy danych można dodać do grupy trybu failover.

Bazy danych skonfigurowane przy użyciu klucza zarządzanego na poziomie bazy danych nie obsługują automatycznego tworzenia pomocniczego podczas dodawania do grupy trybu failover.

Aby uzyskać więcej informacji, konfigurowanie replikacji geograficznej i przywracania kopii zapasowej na potrzeby przezroczystego szyfrowania danych przy użyciu kluczy zarządzanych przez klienta opisuje sposób konfigurowania replikacji geograficznej i grup trybu failover przy użyciu interfejsów API REST, programu PowerShell i interfejsu wiersza polecenia platformy Azure.

Uwaga

Wszystkie najlepsze rozwiązania dotyczące replikacji geograficznej i wysokiej dostępności wyróżnione w funkcji Transparent Data Encryption (TDE) z kluczem CMK na poziomie serwera mają zastosowanie do klucza cmK na poziomie bazy danych.

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 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 skonfigurowanej na poziomie bazy danych, upewnij się, że materiał klucza jest dostarczany do docelowej bazy danych. Zalecamy przechowywanie wszystkich starych wersji funkcji ochrony TDE w magazynie kluczy, aby można było przywrócić kopie zapasowe bazy danych.

Ważne

Dla bazy danych można ustawić tylko jedną funkcję ochrony TDE. Jednak wiele dodatkowych kluczy można przekazać do bazy danych podczas przywracania bez oznaczania ich funkcji ochrony TDE. Te klucze nie są używane do ochrony klucza szyfrowania danych, ale mogą być używane podczas przywracania z kopii zapasowej, jeśli plik kopii zapasowej jest zaszyfrowany przy użyciu klucza z odpowiednim odciskiem palca.

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łnianie listy kluczy używanych przez podstawową bazę danych przy użyciu polecenia Get-AzSqlDatabase oraz -ExpandKeyList parametrów 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 (i identyfikator klienta federacyjnego w przypadku konfigurowania dostępu między dzierżawami).
  3. Użyj polecenia Restore-AzSqlDatabase z parametrem -FromPointInTimeBackup i podaj wstępnie wypełnioną listę kluczy uzyskanych z powyższych kroków 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 -KeyListparametrów , , -EncryptionProtector -AssignIdentity-UserAssignedIdentityId( i w razie potrzeby ). -FederatedClientId

Uwaga

Przywrócenie bazy danych bez -EncryptionProtector właściwości ze wszystkimi prawidłowymi kluczami spowoduje zresetowanie jej do używania szyfrowania na poziomie serwera. Może to być przydatne, aby przywrócić konfigurację klucza zarządzanego przez klienta na poziomie bazy danych do konfiguracji klucza zarządzanego przez klienta na poziomie serwera.

Przywracanie usuniętej bazy danych

Do przywrócenia usuniętej bazy danych skonfigurowanej przy użyciu kluczy zarządzanych przez klienta potrzebne są następujące kroki:

  1. Wstępnie wypełnia listę kluczy używanych przez podstawową bazę danych przy użyciu polecenia Get-AzSqlDeletedDatabaseBackup i parametru -ExpandKeyList . Zaleca się przekazanie wszystkich kluczy używanych przez źródłową bazę danych, ale alternatywnie można spróbować przywrócić klucze dostarczone przez czas usunięcia jako -KeysFilter.
  2. Wybierz tożsamość zarządzaną przypisaną przez użytkownika (i identyfikator klienta federacyjnego w przypadku konfigurowania dostępu między dzierżawami).
  3. Użyj polecenia Restore-AzSqlDatabase z parametrem -FromDeletedDatabaseBackup i podaj wstępnie wypełnioną listę kluczy uzyskanych z powyższych kroków i powyższej tożsamości (oraz identyfikator klienta federacyjnego w przypadku konfigurowania dostępu między dzierżawami) w wywołaniu interfejsu API przy użyciu -KeyListparametrów , , -AssignIdentity-UserAssignedIdentityId, -EncryptionProtector (i w razie potrzeby). -FederatedClientId

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łniaj listę kluczy używanych przez podstawową bazę danych przy użyciu polecenia Get-AzSqlDatabaseGeoBackup i elementu , -ExpandKeyList aby pobrać wszystkie klucze.
  • Wybierz tożsamość zarządzaną przypisaną przez użytkownika (i identyfikator klienta federacyjnego w przypadku konfigurowania dostępu między dzierżawami).
  • Użyj polecenia Restore-AzSqlDatabase z parametrem -FromGeoBackup i podaj wstępnie wypełnioną listę kluczy uzyskanych z powyższych kroków i powyższej tożsamości (oraz identyfikator klienta federacyjnego w przypadku konfigurowania dostępu między dzierżawami) w wywołaniu interfejsu API przy użyciu -KeyListparametrów , , -AssignIdentity-UserAssignedIdentityId, -EncryptionProtector (i w razie potrzeby). -FederatedClientId

Ważne

Zaleca się zachowanie wszystkich kluczy używanych przez bazę danych w celu przywrócenia bazy danych. Zaleca się również przekazanie wszystkich tych kluczy do obiektu docelowego przywracania.

Uwaga

Kopie zapasowe długoterminowego przechowywania kopii zapasowych (LTR) nie udostępniają listy kluczy używanych przez kopię zapasową. Aby przywrócić kopię zapasową LTR, wszystkie klucze używane przez źródłową bazę danych muszą zostać przekazane do obiektu docelowego przywracania LTR.

Aby dowiedzieć się więcej o odzyskiwaniu kopii zapasowych dla usługi SQL Database przy użyciu klucza zarządzanego na poziomie bazy danych przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure i interfejsów API REST, zobacz Konfigurowanie replikacji geograficznej i przywracania kopii zapasowych na potrzeby przezroczystego szyfrowania danych przy użyciu kluczy zarządzanych przez klienta.

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. W tym przypadku zgłaszany jest błąd:

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:

Przykładowa oś czasu rotacji kluczy w bazie danych skonfigurowanej przy użyciu kluczy zarządzanych przez klienta na poziomie bazy danych.

  • Time t0 = Baza danych jest tworzona bez szyfrowania
  • Time t1 = Ta baza danych jest chroniona przez usługę , która jest kluczem zarządzanym przez Thumbprint Aklienta na poziomie bazy danych.
  • Time t2 = Funkcja ochrony bazy danych jest obracana do nowego klucza zarządzanego przez klienta na poziomie bazy danych. Thumbprint B
  • Godzina t3 = zażądano zmiany Thumbprint C ochrony.
  • Jeśli aktywne funkcje VDF używają Thumbprint Apolecenia , rotacja nie jest dozwolona.
  • Jeśli aktywne funkcje VDF nie korzystają z Thumbprint Ausługi , 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 zostać wyświetlony aktywny wirtualnylf zaszyfrowany przy użyciu pierwszego klucza (na przykład Thumbprint A). Po wygenerowaniu wystarczającej liczby dzienników przez wstawienie danych ten stary wirtualnylf jest opróżniany i powinien być w stanie wykonać kolejną rotację kluczy.

Jeśli uważasz, że coś trwa dłużej niż oczekiwano, zapoznaj się z następującą dokumentacją, aby uzyskać dalsze rozwiązywanie problemów:

Następne kroki

Zapoznaj się z następującą dokumentacją dotyczącą różnych operacji cmK na poziomie bazy danych: