Funkcja Transparent Data Encryption usługi Azure SQL przy użyciu klucza zarządzanego przez klienta

Dotyczy:Azure SQL Database Azure SQL Managed InstanceAzure Synapse Analytics (tylko dedykowane pule SQL)

Funkcja Transparent Data Encryption (TDE) w usłudze Azure SQL z kluczem zarządzanym przez klienta (CMK) umożliwia scenariusz Bring Your Own Key (BYOK) na potrzeby ochrony danych magazynowanych i umożliwia organizacjom implementowanie rozdzielenia obowiązków w zarządzaniu kluczami i danymi. W przypadku szyfrowania TDE zarządzanego przez klienta to klient jest odpowiedzialny za zarządzanie cyklem życia klucza (tworzenie, przekazywanie, zmianę i usuwanie), uprawnienia do użycia klucza i inspekcję operacji na kluczach oraz ma nad nimi pełną kontrolę.

W tym scenariuszu klucz używany do szyfrowania klucza szyfrowania bazy danych (DEK), nazywany funkcją ochrony TDE, jest kluczem asymetrycznym zarządzanym przez klienta przechowywanym w usłudze Azure Key Vault (AKV) zarządzanym przez klienta, opartym na chmurze systemie zarządzania kluczami zewnętrznymi. Usługa Key Vault jest wysoce dostępnym i skalowalnym bezpiecznym magazynem dla kluczy kryptograficznych RSA, opcjonalnie wspieranym przez moduły zabezpieczeń sprzętu zweryfikowane na poziomie 2 (HSM) ze standardem FIPS 140-2 poziom 2. Nie zezwala na bezpośredni dostęp do przechowywanego klucza, ale zapewnia usługi szyfrowania/odszyfrowywania przy użyciu klucza do autoryzowanych jednostek. Klucz może być generowany przez magazyn kluczy, zaimportowany lub przeniesiony do magazynu kluczy z lokalnego urządzenia HSM.

W przypadku usług Azure SQL Database i Azure Synapse Analytics funkcja ochrony TDE jest ustawiana na poziomie serwera i dziedziczona przez wszystkie zaszyfrowane bazy danych skojarzone z tym serwerem. W przypadku usługi Azure SQL Managed Instance funkcja ochrony TDE jest ustawiana na poziomie wystąpienia i dziedziczona przez wszystkie zaszyfrowane bazy danych w tym wystąpieniu. Termin serwer odnosi się zarówno do serwera w usługach SQL Database, jak i Azure Synapse oraz do wystąpienia zarządzanego w usłudze SQL Managed Instance w tym dokumencie, chyba że określono inaczej.

Zarządzanie ochroną TDE na poziomie bazy danych w usłudze Azure SQL Database jest dostępne. Aby uzyskać więcej informacji, zobacz Transparent Data Encryption (TDE) z kluczami zarządzanymi przez klienta na poziomie bazy danych.

Uwaga

• Ten artykuł dotyczy usług Azure SQL Database, Azure SQL Managed Instance i Azure Synapse Analytics (dedykowanych pul SQL (dawniej SQL DW). Aby uzyskać dokumentację dotyczącą przezroczystego szyfrowania danych dla dedykowanych pul SQL w obszarach roboczych usługi Synapse, zobacz Szyfrowanie usługi Azure Synapse Analytics.
• Aby zapewnić klientom usługi Azure SQL dwie warstwy szyfrowania danych magazynowanych, szyfrowanie infrastruktury (przy użyciu algorytmu szyfrowania AES-256) z kluczami zarządzanymi platformy jest wdrażane. Zapewnia to dodatkową warstwę szyfrowania magazynowanych wraz z funkcją TDE z kluczami zarządzanymi przez klienta, która jest już dostępna. W przypadku usług Azure SQL Database i Azure SQL Managed Instance wszystkie bazy danych, w tym baza danych i inne systemowe bazy danych, będą szyfrowane po włączeniu master szyfrowania infrastruktury. Obecnie klienci muszą zażądać dostępu do tej możliwości. Jeśli interesuje Cię ta funkcja, skontaktuj się z AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Uwaga

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

Korzyści wynikające z szyfrowania TDE zarządzanego przez klienta

Uwaga

W tym artykule terminy Klucz zarządzany przez klienta (CMK) i Bring Your Own Key (BYOK) są używane zamiennie, ale stanowią pewne różnice.

• klucz zarządzany przez klienta (CMK) — klient zarządza cyklem życia klucza, w tym tworzeniem kluczy, rotacją i usuwaniem. Klucz jest przechowywany w Azure Key Vault lub w zarządzanym Modułem HSM usługi Azure Key Vault i używany do szyfrowania klucza szyfrowania bazy danych (DEK) w Azure SQL, SQL Serverze na maszynie wirtualnej platformy Azure, oraz w lokalnym SQL Serverze.
• byOK (Bring Your Own Key) — klient bezpiecznie przenosi lub importuje własny klucz z lokalnego sprzętowego modułu zabezpieczeń (HSM) do usługi Azure Key Vault lub zarządzanego modułu HSM usługi Azure Key Vault. Takie zaimportowane klucze mogą być używane jak każdy inny klucz w usłudze Azure Key Vault, w tym jako klucz zarządzany przez klienta do szyfrowania klucza szyfrowania danych (DEK). Aby uzyskać więcej informacji, zobacz Importowanie kluczy chronionych przez moduł HSM do modułu HSM zarządzanego (BYOK).

Funkcja TDE zarządzana przez klienta zapewnia następujące korzyści dla klienta:

• Pełna i szczegółowa kontrola nad użyciem i zarządzaniem ochroną TDE;

• Przejrzystość użycia funkcji ochrony TDE;

• Możliwość wdrożenia podziału obowiązków w zarządzaniu kluczami i danymi w organizacji;

• Administrator usługi Key Vault może odwołać uprawnienia dostępu do klucza, aby zaszyfrowana baza danych jest niedostępna;

• Centralne zarządzanie kluczami w usłudze AKV;

• Większe zaufanie klientów końcowych, ponieważ usługa AKV została zaprojektowana tak, aby firma Microsoft nie mogła zobaczyć ani wyodrębnić kluczy szyfrowania;

Ważne

W przypadku osób korzystających z funkcji TDE zarządzanej przez usługę, którzy chcą rozpocząć korzystanie z funkcji TDE zarządzanej przez klienta, dane pozostają zaszyfrowane podczas procesu przełączania i nie ma przestoju ani ponownego szyfrowania plików bazy danych. Zmiana klucza zarządzanego przez usługę na klucz zarządzany przez klienta wymaga tylko ponownego szyfrowania klucza szyfrowania danych, a ta operacja jest szybka i odbywa się w trybie online.

Jak działa szyfrowanie TDE zarządzane przez klienta

Aby serwer logiczny na platformie Azure używał funkcji ochrony TDE przechowywanej w usłudze AKV do szyfrowania klucza szyfrowania kluczy, administrator usługi Key Vault musi udzielić praw dostępu do serwera przy użyciu unikatowej tożsamości firmy Microsoft Entra. Istnieją dwa modele dostępu do udzielenia serwerowi dostępu do magazynu kluczy:

• Kontrola dostępu oparta na rolach (RBAC) platformy Azure — użyj kontroli dostępu opartej na rolach platformy Azure, aby udzielić użytkownikowi, grupie lub aplikacji dostępu do magazynu kluczy. Ta metoda jest zalecana w celu zapewnienia elastyczności i stopnia szczegółowości. Rola użytkownika szyfrowania usługi kryptograficznej usługi Key Vault jest wymagana przez tożsamość serwera, aby móc używać klucza do operacji szyfrowania i odszyfrowywania.

• Zasady dostępu do magazynu — użyj zasad dostępu magazynu kluczy, aby udzielić serwerowi dostępu do magazynu kluczy. Ta metoda jest prostsza i prostsza, ale mniej elastyczna. Tożsamość serwera musi mieć następujące uprawnienia w magazynie kluczy:

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

W menu Konfiguracja dostępu w witrynie Azure Portal magazynu kluczy możesz wybrać pozycję Kontrola dostępu oparta na rolach platformy Azure lub zasady dostępu do magazynu. Aby uzyskać instrukcje krok po kroku dotyczące konfigurowania konfiguracji dostępu do usługi Azure Key Vault dla funkcji TDE, zobacz Konfigurowanie rozszerzonego zarządzania kluczami TDE programu SQL Server przy użyciu usługi Azure Key Vault. Aby uzyskać więcej informacji na temat modeli dostępu, zobacz Zabezpieczenia usługi Azure Key Vault.

Administrator usługi Key Vault może również włączyć rejestrowanie zdarzeń inspekcji magazynu kluczy, dzięki czemu można je później przeprowadzić inspekcję.

Gdy serwer jest skonfigurowany do używania funkcji ochrony TDE z usługi AKV, serwer wysyła klucz szyfrowania szyfrowania poszczególnych baz danych z włączoną funkcją TDE do magazynu kluczy na potrzeby szyfrowania. Magazyn kluczy zwraca zaszyfrowany klucz szyfrowania danych, który jest następnie przechowywany w bazie danych użytkownika.

W razie potrzeby serwer wysyła chroniony klucz szyfrowania danych do magazynu kluczy na potrzeby odszyfrowywania.

Audytorzy mogą używać usługi Azure Monitor do przeglądania dzienników AuditEvent magazynu kluczy, jeśli rejestrowanie jest włączone.

Uwaga

Może upłynąć około 10 minut, aby wszelkie zmiany uprawnień zaczęły obowiązywać w magazynie kluczy. Obejmuje to odwołowanie uprawnień dostępu do funkcji ochrony TDE w usłudze AKV, a użytkownicy w tym przedziale czasu mogą nadal mieć uprawnienia dostępu.

Wymagania konfiguracji szyfrowania TDE zarządzanego przez klienta

Wymagania dotyczące konfigurowania usługi AKV

• Funkcje ochrony przed usuwaniem nietrwałym i przeczyszczania muszą być włączone w magazynie kluczy, aby chronić przed utratą danych z powodu przypadkowego usunięcia klucza (lub magazynu kluczy).

• Udziel serwerowi lub wystąpieniu zarządzanemu dostępu do magazynu kluczy (get, wrapKey, unwrapKey) przy użyciu tożsamości firmy Microsoft Entra. Tożsamość serwera może być tożsamością zarządzaną przypisaną przez system lub tożsamością zarządzaną przypisaną przez użytkownika przypisaną do serwera. W przypadku korzystania z witryny Azure Portal tożsamość usługi Microsoft Entra jest tworzona automatycznie podczas tworzenia serwera. W przypadku korzystania z programu PowerShell lub interfejsu wiersza polecenia platformy Azure tożsamość usługi Microsoft Entra musi zostać jawnie utworzona i powinna zostać zweryfikowana. Aby uzyskać szczegółowe instrukcje krok po kroku dotyczące korzystania z programu PowerShell, zobacz Konfigurowanie szyfrowania TDE za pomocą funkcji BYOK z funkcją BYOKdla usługi SQL Managed Instance .

  • W zależności od modelu uprawnień magazynu kluczy (zasady dostępu lub kontrola dostępu na podstawie ról platformy Azure) dostępu do magazynu kluczy można udzielić przez utworzenie zasad dostępu lub nowego przypisania roli RBAC platformy Azure z rolą Key Vault Crypto Service Encryption User.

• W przypadku korzystania z zapory z usługą AKV należy włączyć opcję Zezwalaj zaufanym usługi firmy Microsoft na obejście zapory, chyba że używasz prywatnych punktów końcowych dla usługi AKV. Aby uzyskać więcej informacji, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Key Vault.

Włączanie ochrony przed usuwaniem nietrwałym i przeczyszczaniem w usłudze AKV

Ważne

Zarówno usuwanie nietrwałe, jak i ochrona przed przeczyszczeniem muszą być włączone w magazynie kluczy podczas konfigurowania funkcji TDE zarządzanej przez klienta na nowym lub istniejącym serwerze lub wystąpieniu zarządzanym.

Usuwanie nietrwałe i przeczyszczanie są ważnymi funkcjami usługi Azure Key Vault, które umożliwiają odzyskiwanie usuniętych magazynów i usuniętych obiektów magazynu kluczy, co zmniejsza ryzyko przypadkowego lub złośliwego usunięcia klucza lub magazynu kluczy.

• Zasoby usunięte nietrwale są przechowywane przez 90 dni, chyba że odzyskane lub przeczyszczone przez klienta. Akcje odzyskiwania i przeczyszczania mają własne uprawnienia skojarzone z zasadami dostępu do magazynu kluczy. Funkcja usuwania nietrwałego jest domyślnie włączona dla nowych magazynów kluczy i może być również włączona przy użyciu witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure.

• Ochronę przeczyszczania można włączyć przy użyciu interfejsu wiersza polecenia platformy Azure lub programu PowerShell. Gdy ochrona przed przeczyszczaniem jest włączona, nie można przeczyścić magazynu ani obiektu w stanie usunięcia, dopóki nie upłynie okres przechowywania. Domyślny okres przechowywania wynosi 90 dni, ale można go skonfigurować z zakresu od 7 do 90 dni za pośrednictwem witryny Azure Portal.

• Usługa Azure SQL wymaga włączenia ochrony przed usuwaniem nietrwałym i przeczyszczeniem w magazynie kluczy zawierającym klucz szyfrowania używany jako funkcja ochrony TDE dla serwera lub wystąpienia zarządzanego. Pomaga to zapobiec przypadkowemu lub złośliwemu magazynowi kluczy lub usunięciu klucza, które może prowadzić do wystąpienia bazy danych w stanie Niedostępny .

• Podczas konfigurowania funkcji ochrony TDE na istniejącym serwerze lub podczas tworzenia serwera usługa Azure SQL sprawdza, czy używany magazyn kluczy ma włączoną ochronę usuwania nietrwałego i przeczyszczania. Jeśli ochrona przed usuwaniem nietrwałym i przeczyszczeniem nie jest włączona w magazynie kluczy, instalacja funkcji ochrony TDE kończy się niepowodzeniem z powodu błędu. W takim przypadku należy najpierw włączyć ochronę przed usuwaniem nietrwałym i przeczyszczeniem w magazynie kluczy, a następnie należy wykonać konfigurację funkcji ochrony TDE.

Wymagania dotyczące konfigurowania funkcji ochrony TDE

• Funkcja ochrony TDE może być tylko kluczem asymetrycznym, RSA lub RSA HSM. Obsługiwane długości kluczy to 2048 bitów i 3072 bity.

• Data aktywacji klucza (jeśli ustawiona) musi być datą i godziną w przeszłości. Data wygaśnięcia (jeśli ustawiona) musi być przyszłą datą i godziną.

• Klucz musi być w stanie Włączone .

• Jeśli importujesz istniejący klucz do magazynu kluczy, upewnij się, że jest on w obsługiwanych formatach plików (.pfx, .byok, lub .backup).

Uwaga

Obsługa usług Azure SQL i SQL Server na maszynie wirtualnej platformy Azure przy użyciu klucza RSA przechowywanego w zarządzanym module HSM jako funkcji ochrony TDE. Zarządzany moduł HSM usługi Azure Key Vault to w pełni zarządzana, wysoce dostępna, zgodna ze standardami usługa w chmurze, która umożliwia ochronę kluczy kryptograficznych dla aplikacji w chmurze przy użyciu zweryfikowanych modułów HSM fiPS 140-2 poziom 3. Dowiedz się więcej na temat zarządzanych modułów HSM i konfiguracji lub uprawnień kontroli dostępu opartej na rolach wymaganych dla programu SQL Server, korzystając z artykułu Konfigurowanie rozszerzonego zarządzania kluczami TDE programu SQL Server przy użyciu usługi Azure Key Vault.

Problem z wersjami programu CipherTrust Manager firmy Thales przed wersją 2.8.0 uniemożliwia używanie kluczy nowo zaimportowanych do usługi Azure Key Vault z usługą Azure SQL Database lub azure SQL Managed Instance na potrzeby scenariuszy TDE zarządzanych przez klienta. Więcej szczegółów na temat tego problemu można znaleźć tutaj. W takich przypadkach poczekaj 24 godziny po zaimportowaniu klucza do magazynu kluczy, aby rozpocząć korzystanie z niego jako funkcji ochrony TDE dla serwera lub wystąpienia zarządzanego. Ten problem został rozwiązany w usłudze Thales CipherTrust Manager w wersji 2.8.0.

Rekomendacje podczas konfiguracji szyfrowania TDE zarządzanego przez klienta

Zalecenia dotyczące konfigurowania usługi AKV

• Skojarz w sumie 500 baz danych ogólnego przeznaczenia lub 200 Krytyczne dla działania firmy z magazynem kluczy w jednej subskrypcji, aby zapewnić wysoką dostępność, gdy serwer uzyskuje dostęp do funkcji ochrony TDE w magazynie kluczy. Te dane są oparte na środowisku i udokumentowane w limitach usługi magazynu kluczy. Celem jest zapobieganie problemom po przejściu serwera w tryb failover, ponieważ spowoduje ono wyzwolenie jak największej liczby kluczowych operacji względem magazynu, ponieważ na tym serwerze znajdują się bazy danych.

• Ustaw blokadę zasobu dla magazynu kluczy, aby kontrolować, kto może usunąć ten krytyczny zasób i zapobiec przypadkowemu lub nieautoryzowanemu usunięciu. Dowiedz się więcej o blokadach zasobów.

• Włącz inspekcję i raportowanie dla wszystkich kluczy szyfrowania: magazyn kluczy udostępnia dzienniki, które można łatwo wprowadzać do innych narzędzi do zarządzania informacjami i zdarzeniami zabezpieczeń. Operations Management Suite Log Analytics to jeden z przykładów usługi, która jest już zintegrowana.

• Użyj magazynu kluczy z regionu platformy Azure, który może replikować zawartość do sparowanego regionu w celu zapewnienia maksymalnej dostępności. Aby uzyskać więcej informacji, zobacz Najlepsze praktyki korzystania z Azure Key Vault i Dostępność i nadmiarowość Azure Key Vault.

Uwaga

Aby zapewnić większą elastyczność konfigurowania szyfrowania TDE zarządzanego przez klienta, usługi Azure SQL Database i azure SQL Managed Instance w jednym regionie można teraz połączyć z magazynem kluczy w dowolnym innym regionie. Serwer i magazyn kluczy nie muszą być kolokowane w tym samym regionie.

Zalecenia dotyczące konfigurowania funkcji ochrony TDE

• Zachowaj kopię funkcji ochrony TDE w bezpiecznym miejscu lub deponuj ją w usłudze escrow.

• Jeśli klucz jest generowany w magazynie kluczy, utwórz kopię zapasową klucza przed użyciem klucza w usłudze AKV po raz pierwszy. Tworzenie kopii zapasowej można przywrócić tylko do usługi Azure Key Vault. Dowiedz się więcej o poleceniu Backup-AzKeyVaultKey .

• Utwórz nową kopię zapasową za każdym razem, gdy wszystkie zmiany zostaną wprowadzone w kluczu (na przykład atrybuty klucza, tagi, listy ACL).

• Zachowaj poprzednie wersje klucza w magazynie kluczy podczas rotacji kluczy, aby można było przywrócić starsze kopie zapasowe bazy danych. Gdy funkcja ochrony TDE zostanie zmieniona dla bazy danych, stare kopie zapasowe bazy danych nie są aktualizowane tak, aby korzystały z najnowszej funkcji ochrony TDE. W czasie przywracania każda kopia zapasowa wymaga funkcji ochrony TDE, za pomocą której została zaszyfrowana w czasie tworzenia. Rotacje kluczy można wykonać zgodnie z instrukcjami w temacie Obracanie funkcji ochrony przezroczystego szyfrowania danych przy użyciu programu PowerShell.

• Zachowuj wszystkie wcześniej używane klucze w usłudze AKV nawet po przełączeniu na klucze zarządzane przez usługę. Zapewni to możliwość przywrócenia kopii zapasowych baz danych przy użyciu funkcji ochrony TDE przechowywanych w usłudze AKV. Funkcje ochrony TDE utworzone za pomocą usługi Azure Key Vault muszą być przechowywane do momentu utworzenia wszystkich pozostałych przechowywanych kopii zapasowych przy użyciu kluczy zarządzanych przez usługę. Utwórz kopie zapasowe tych kluczy z możliwością odzyskania, używając polecenia Backup-AzKeyVaultKey.

• Aby usunąć potencjalnie naruszony klucz podczas zdarzenia zabezpieczeń bez ryzyka utraty danych, wykonaj kroki z sekcji Usuwanie klucza potencjalnie naruszonego.

Rotacja funkcji ochrony TDE

Rotacja funkcji ochrony TDE dla serwera oznacza przełączenie się na nowy klucz asymetryczny, który chroni bazy danych na serwerze. 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.

Rotacja funkcji ochrony TDE może być wykonywana ręcznie lub za pomocą funkcji zautomatyzowanego obracania.

Automatyczna rotacja funkcji ochrony TDE można włączyć podczas konfigurowania funkcji ochrony TDE dla serwera. Automatyczne obracanie jest domyślnie wyłączone. Po włączeniu serwer będzie stale sprawdzać magazyn kluczy pod kątem wszystkich nowych wersji klucza używanego jako funkcja ochrony TDE. Jeśli zostanie wykryta nowa wersja klucza, funkcja ochrony TDE na serwerze lub bazie danych zostanie automatycznie obracana do najnowszej wersji klucza w ciągu 24 godzin.

W przypadku użycia z automatycznym rotacją kluczy w usłudze Azure Key Vault ta funkcja umożliwia kompleksową rotację bezobsługową dla funkcji ochrony TDE w usłudze Azure SQL Database i usłudze Azure SQL Managed Instance.

Uwaga

Ustawienie funkcji TDE z kluczem CMK przy użyciu ręcznego lub zautomatyzowanego obracania kluczy zawsze będzie używać najnowszej obsługiwanej wersji klucza. Konfiguracja nie zezwala na używanie poprzedniej lub niższej wersji kluczy. Zawsze używanie najnowszej wersji klucza jest zgodne z zasadami zabezpieczeń usługi Azure SQL, które nie zezwalają na wcześniejsze wersje kluczy, które mogą zostać naruszone. Poprzednie wersje klucza mogą być potrzebne w celach tworzenia kopii zapasowych lub przywracania bazy danych, zwłaszcza w przypadku kopii zapasowych przechowywania długoterminowego, w których należy zachować starsze wersje kluczy. W przypadku konfiguracji replikacji geograficznej wszystkie klucze wymagane przez serwer źródłowy muszą być obecne na serwerze docelowym.

Zagadnienia dotyczące replikacji geograficznej podczas konfigurowania zautomatyzowanego obracania funkcji ochrony TDE

Aby uniknąć problemów podczas ustanawiania lub podczas replikacji geograficznej, gdy automatyczna rotacja funkcji ochrony TDE jest włączona na serwerze podstawowym lub pomocniczym, należy przestrzegać tych reguł podczas konfigurowania replikacji geograficznej:

• Zarówno serwery podstawowe, jak i pomocnicze muszą mieć uprawnienia Get, wrapKey i unwrapKey do magazynu kluczy serwera podstawowego (magazyn kluczy, który zawiera klucz ochrony TDE serwera podstawowego).

• W przypadku serwera z włączoną automatyczną rotacją kluczy przed zainicjowaniem replikacji geograficznej dodaj klucz szyfrowania używany jako funkcja ochrony TDE na serwerze podstawowym do serwera pomocniczego. Serwer pomocniczy wymaga dostępu do klucza w tym samym magazynie kluczy używanym z serwerem podstawowym (a nie innym kluczem z tym samym materiałem klucza). Alternatywnie przed zainicjowaniem replikacji geograficznej upewnij się, że tożsamość zarządzana serwera pomocniczego (przypisana przez użytkownika lub przypisana przez system) ma wymagane uprawnienia w magazynie kluczy serwera podstawowego, a system podejmie próbę dodania klucza do serwera pomocniczego.

• W przypadku istniejącej konfiguracji replikacji geograficznej przed włączeniem automatycznej rotacji kluczy na serwerze podstawowym dodaj klucz szyfrowania używany jako funkcja ochrony TDE na serwerze podstawowym do serwera pomocniczego. Serwer pomocniczy wymaga dostępu do klucza w tym samym magazynie kluczy używanym z serwerem podstawowym (a nie innym kluczem z tym samym materiałem klucza). Alternatywnie przed włączeniem automatycznego klucza upewnij się, że tożsamość zarządzana serwera pomocniczego (przypisana przez użytkownika lub przypisana przez system) ma wymagane uprawnienia w magazynie kluczy serwera podstawowego, a system podejmie próbę dodania klucza do serwera pomocniczego.

• Obsługiwane są scenariusze replikacji geograficznej przy użyciu kluczy zarządzanych przez klienta (CMK) dla funkcji TDE. Funkcja TDE z automatycznym obracaniem kluczy musi być skonfigurowana na wszystkich serwerach, jeśli konfigurujesz funkcję TDE w witrynie Azure Portal. Aby uzyskać więcej informacji na temat konfigurowania automatycznego obracania kluczy dla konfiguracji replikacji geograficznej za pomocą funkcji TDE, zobacz Automatyczne obracanie kluczy dla konfiguracji replikacji geograficznej.

Niedostępna funkcja ochrony TDE

Gdy szyfrowanie TDE jest skonfigurowane do korzystania z klucza zarządzanego przez klienta, wymagany jest ciągły dostęp do funkcji ochrony TDE, aby baza danych mogła pozostać w trybie online. Jeśli serwer utraci dostęp do funkcji ochrony TDE zarządzanej przez klienta w usłudze AKV, w ciągu do 10 minut baza danych zacznie odmawiać wszystkich połączeń z odpowiednim komunikatem o błędzie i zmienić jego stan na Niedostępny. Jedyną akcją dozwoloną w bazie danych w stanie Niedostępny jest usunięcie tej akcji.

Uwaga

Jeśli baza danych jest niedostępna z powodu sporadycznej awarii sieci, nie jest wymagana żadna akcja, a bazy danych zostaną automatycznie przywrócone w trybie online. Aby zminimalizować wpływ błędów sieci lub awarii podczas próby uzyskania dostępu do funkcji ochrony TDE w usłudze Azure Key Vault, przed próbą przeniesienia bazy danych do stanu niedostępnego wprowadzono 24-godzinny bufor. Jeśli przejście w tryb failover nastąpi przed osiągnięciem stanu niedostępności, baza danych stanie się niedostępna z powodu utraty pamięci podręcznej szyfrowania.

Po przywróceniu dostępu do klucza pobieranie bazy danych z powrotem do trybu online wymaga dodatkowego czasu i kroków, które mogą się różnić w zależności od czasu, który upłynął bez dostępu do klucza i rozmiaru danych w bazie danych:

Uwaga

• Jeśli dostęp do klucza zostanie przywrócony w ciągu 30 minut, baza danych zostanie automatycznie włączona w ciągu następnej godziny.
• Jeśli dostęp do klucza zostanie przywrócony po upływie ponad 30 minut, autoheal bazy danych nie jest możliwe. Przywrócenie bazy danych wymaga wykonania dodatkowych kroków w witrynie Azure Portal i może zająć dużo czasu w zależności od rozmiaru bazy danych.
• Gdy baza danych wróci do trybu online, wcześniej skonfigurowane ustawienia na poziomie serwera, które mogą obejmować konfigurację grupy trybu failover, tagi i ustawienia na poziomie bazy danych, takie jak konfiguracja elastycznych pul, skalowanie odczytu, automatyczne wstrzymywanie, historia przywracania do punktu w czasie, zasady przechowywania długoterminowego i inne zostaną utracone. W związku z tym zaleca się, aby klienci zaimplementowali system powiadomień, który identyfikuje utratę dostępu klucza szyfrowania w ciągu 30 minut. Po wygaśnięciu okna 30 minut zalecamy zweryfikowanie wszystkich ustawień na poziomie serwera i bazy danych w odzyskanej bazie danych.

Poniżej przedstawiono dodatkowe kroki wymagane w portalu w celu przywrócenia niedostępnej bazy danych w trybie online.

Przypadkowe odwołanie dostępu funkcji ochrony TDE

Może się zdarzyć, że ktoś, kto ma wystarczające uprawnienia dostępu do magazynu kluczy, przypadkowo wyłączy dostęp serwera do klucza przez:

• odwołowywanie uprawnień get, wrapKey, unwrapKey z serwera

• usuwanie klucza

• usuwanie magazynu kluczy

• zmienianie reguł zapory magazynu kluczy

• usuwanie tożsamości zarządzanej serwera w identyfikatorze Entra firmy Microsoft

Dowiedz się więcej o typowych przyczynach niedostępnych bazy danych.

Zablokowana łączność między usługą SQL Managed Instance i usługą Key Vault

Blok łączności sieciowej między usługą SQL Managed Instance i magazynem kluczy występuje głównie wtedy, gdy zasób magazynu kluczy istnieje, ale jego punkt końcowy nie może zostać osiągnięty z wystąpienia zarządzanego. Wszystkie scenariusze, w których można uzyskać dostęp do punktu końcowego magazynu kluczy, ale nastąpiła odmowa połączenia, brak uprawnień itp., spowoduje, że bazy danych zmienią stan na Niedostępny.

Najczęstsze przyczyny braku łączności sieciowej z usługą Key Vault:

• Usługa Key Vault jest uwidoczniona za pośrednictwem prywatnego punktu końcowego, a prywatny adres IP usługi AKV nie jest dozwolony w regułach ruchu wychodzącego sieciowej grupy zabezpieczeń skojarzonej z podsiecią wystąpienia zarządzanego.
• Nieprawidłowe rozpoznawanie nazw DNS, na przykład gdy nazwa FQDN magazynu kluczy nie jest rozpoznawana lub jest rozpoznawana jako nieprawidłowy adres IP.

Przetestuj łączność z usługi SQL Managed Instance do usługi Key Vault hostująca funkcję ochrony TDE.

• Punkt końcowy to nazwa FQDN magazynu, na przykład <vault_name.vault.azure.net> (bez https://).
• Port do przetestowania to 443.
• Wynik polecenia RemoteAddress powinien istnieć i być prawidłowym adresem IP
• Wynik testu TCP powinien mieć wartość TcpTestSucceeded: True.

Jeśli test zwraca wartość TcpTestSucceeded: False, przejrzyj konfigurację sieci:

• Sprawdź rozpoznany adres IP, upewnij się, że jest prawidłowy. Brak wartości oznacza, że występują problemy z rozpoznawaniem nazw DNS.
  • Upewnij się, że sieciowa grupa zabezpieczeń w wystąpieniu zarządzanym ma regułę ruchu wychodzącego obejmującą rozpoznany adres IP na porcie 443, zwłaszcza gdy rozpoznany adres należy do prywatnego punktu końcowego magazynu kluczy.
  • Sprawdź inne konfiguracje sieci, takie jak tabela tras, istnienie urządzenia wirtualnego i jego konfiguracji itp.

Monitorowanie szyfrowania TDE zarządzanego przez klienta

Aby monitorować stan bazy danych i włączyć alerty dotyczące utraty dostępu funkcji ochrony TDE, skonfiguruj następujące funkcje platformy Azure:

• Azure Resource Health. Niedostępna baza danych, która utraciła dostęp do funkcji ochrony TDE, będzie wyświetlana jako "Niedostępna" po odmowie pierwszego połączenia z bazą danych.
• Dziennik aktywności, gdy dostęp do funkcji ochrony TDE w magazynie kluczy zarządzanych przez klienta kończy się niepowodzeniem, wpisy są dodawane do dziennika aktywności. Tworzenie alertów dla tych zdarzeń umożliwia jak najszybsze przywrócenie dostępu.
• Grupy akcji można zdefiniować w celu wysyłania powiadomień i alertów na podstawie preferencji, na przykład wiadomości e-mail/sms/wypychania/głosu, aplikacji logiki, elementu webhook, itsm lub elementu Runbook automatyzacji.

Bazy danych backup i restore z TDE zarządzanym przez klienta

Po zaszyfrowaniu bazy danych za pomocą funkcji TDE przy użyciu klucza z usługi Key Vault wszystkie nowo wygenerowane kopie zapasowe są również szyfrowane przy użyciu tej samej funkcji ochrony TDE. Gdy funkcja ochrony TDE zostanie zmieniona, stare kopie zapasowe bazy danych nie są aktualizowane tak, aby korzystały z najnowszej funkcji ochrony TDE.

Aby przywrócić kopię zapasową zaszyfrowaną za pomocą funkcji ochrony TDE z usługi Key Vault, upewnij się, że materiał klucza jest dostępny dla serwera docelowego. Dlatego zalecamy zachowywanie wszystkich starych wersji funkcji ochrony TDE w magazynie kluczy, aby można było przywracać kopie zapasowe bazy danych.

Ważne

W każdej chwili nie może istnieć więcej niż jeden zestaw ochrony TDE dla serwera. Jest to klucz oznaczony jako "Ustaw klucz jako domyślną funkcję ochrony TDE" w okienku witryny Azure Portal. Jednak wiele dodatkowych kluczy można połączyć z serwerem bez oznaczania ich jako 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.

Jeśli klucz potrzebny do przywrócenia kopii zapasowej nie jest już dostępny dla serwera docelowego, w próbie przywracania zostanie zwrócony następujący komunikat o błędzie: "Serwer <Servername> docelowy nie ma dostępu do wszystkich identyfikatorów URI usługi AKV utworzonych między sygnaturą <czasową #1> i <znacznikiem czasu #2>. Ponów operację po przywróceniu wszystkich identyfikatorów URI usługi AKV".

Aby temu zapobiec, uruchom polecenie cmdlet Get-AzSqlServerKeyVaultKey dla serwera docelowego lub get-AzSqlInstanceKeyVaultKey dla docelowego wystąpienia zarządzanego, aby zwrócić listę dostępnych kluczy i zidentyfikować brakujące. Aby upewnić się, że wszystkie kopie zapasowe można przywrócić, upewnij się, że serwer docelowy przywracania ma dostęp do wszystkich potrzebnych kluczy. Te klucze nie muszą być oznaczone jako funkcja ochrony TDE.

Aby dowiedzieć się więcej o odzyskiwaniu kopii zapasowych dla usługi SQL Database, zobacz Odzyskiwanie bazy danych w usłudze SQL Database. Aby dowiedzieć się więcej o odzyskiwaniu kopii zapasowych dla dedykowanych pul SQL w usłudze Azure Synapse Analytics, zobacz Odzyskiwanie dedykowanej puli SQL. Aby uzyskać natywną kopię zapasową/przywracanie programu SQL Server za pomocą usługi SQL Managed Instance, zobacz Szybki start: przywracanie bazy danych do usługi SQL Managed Instance.

Inna kwestia dotycząca plików dziennika: kopie zapasowe plików dziennika pozostają zaszyfrowane przy użyciu oryginalnej funkcji ochrony TDE, nawet jeśli została ona obrócona, a baza danych korzysta teraz z nowej funkcji ochrony TDE. W czasie przywracania oba klucze są potrzebne do przywrócenia bazy danych. Jeśli plik dziennika korzysta z funkcji ochrony TDE przechowywanej w usłudze Azure Key Vault, ten klucz jest potrzebny w czasie przywracania, nawet jeśli baza danych została zmieniona w celu korzystania z funkcji TDE zarządzanej przez usługę w międzyczasie.

Wysoka dostępność za pomocą funkcji TDE zarządzanej przez klienta

Dzięki usłudze AKV zapewniającej wiele warstw nadmiarowości elementy TDE korzystające z klucza zarządzanego przez klienta mogą korzystać z dostępności i odporności usługi AKV oraz polegać w pełni na rozwiązaniu nadmiarowości usługi AKV.

Wiele warstw nadmiarowości usługi AKV zapewnia dostęp do klucza, nawet jeśli poszczególne składniki usługi kończą się niepowodzeniem, regionami platformy Azure lub strefami dostępności. Aby uzyskać więcej informacji, zobacz Dostępność i nadmiarowość usługi Azure Key Vault.

Usługa AKV oferuje następujące składniki dostępności i odporności, które są udostępniane automatycznie bez interwencji użytkownika:

• Replikacja danych
• Przechodzenie w tryb failover w regionie
• Przechodzenie w tryb failover między regionami

Uwaga

We wszystkich regionach par klucze usługi AKV są replikowane do obu regionów i istnieją sprzętowe moduły zabezpieczeń (HSM) w obu regionach, które mogą działać na tych kluczach. Aby uzyskać więcej informacji, zobacz Replikacja danych. Dotyczy to zarówno warstw usługi Azure Key Vault w warstwach Standardowa, jak i Premium oraz oprogramowania lub kluczy sprzętowych.

Geograficzne odzyskiwanie po awarii i funkcja TDE zarządzana przez klienta

Zarówno w scenariuszach aktywnej georeplikacji, jak i grup powrotu do stanu awaryjnego, serwery główne i zapasowe mogą być połączone z usługą Azure Key Vault znajdującą się w dowolnym regionie. Serwer i magazyn kluczy nie muszą być zlokalizowane w tym samym regionie. Dzięki temu, dla uproszczenia, serwery podstawowy i pomocniczy mogą być połączone z tym samym magazynem kluczy (w dowolnym regionie). Pomaga to uniknąć scenariuszy, w których materiał klucza może nie być zsynchronizowany, jeśli dla obu serwerów są używane oddzielne magazyny kluczy. 

Usługa Azure Key Vault ma wiele warstw nadmiarowości, aby upewnić się, że klucze i magazyny kluczy pozostają dostępne w przypadku awarii usługi lub regionu. Redundancja jest wspierana przez niesparowane, a także sparowane regiony. Aby uzyskać więcej informacji, zobacz Dostępność i nadmiarowość usługi Azure Key Vault.

Istnieje kilka opcji przechowywania klucza ochrony TDE na podstawie wymagań klientów:

• Skorzystaj z usługi Azure Key Vault oraz natywnej odporności regionu sparowanego lub odporności regionu niesparowanego.

• Korzystaj z modułu HSM klienta i kluczy ładowania w usłudze Azure Key Vault w oddzielnych modułach AKV w wielu regionach.

• Skorzystaj z zarządzanego modułu HSM i opcji replikacji między regionami.

  • Ta opcja umożliwia klientowi wybranie żądanego regionu, w którym będą replikowane klucze.

Na poniższym diagramie przedstawiono konfigurację sparowanego regionu (podstawowego i pomocniczego) dla trybu failover usługi AKV z konfiguracją usługi Azure SQL na potrzeby replikacji geograficznej przy użyciu grupy trybu failover:

Uwagi dotyczące usługi Azure Key Vault dotyczące Geo-DR

• Zarówno serwery podstawowe, jak i pomocnicze w usłudze Azure SQL uzyskują dostęp do usługi AKV w regionie podstawowym.

• Tryb failover usługi AKV jest inicjowany przez usługę AKV, a nie przez klienta.

• W przypadku przełączenia awaryjnego AKV do regionu zapasowego serwer Azure SQL nadal może uzyskać dostęp do tej samej usługi AKV. Mimo że wewnętrznie połączenie AKV jest przekierowywane do AKV w regionie pomocniczym.

• Nowe operacje tworzenia, importowania i rotacji kluczy są możliwe tylko wtedy, gdy usługa AKV w podstawowej wersji jest dostępna.

• Po przejściu w tryb failover rotacja kluczy nie jest dozwolona, dopóki usługa AKV w podstawowym regionie w ramach sparowanego regionu nie będzie ponownie dostępna.

• Klient nie może ręcznie nawiązać połączenia z regionem pomocniczym.

• Usługa AKV jest w trybie tylko do odczytu, gdy usługa AKV w regionie podstawowym jest niedostępna.

• Klient nie może wybrać lub sprawdzić, w jakim regionie znajduje się obecnie usługa AKV.

• W przypadku regionów nieparowanych dwa serwery Azure SQL uzyskują dostęp do usługi AKV w pierwszym regionie (jak wskazano na grafie), a usługa AKV używa magazynu nadmiarowego w strefie do replikowania danych w regionie, w niezależnych strefach dostępności tego samego regionu.

Aby uzyskać więcej informacji, zobacz dostępność i nadmiarowość usługi Azure Key Vault, pary regionów Azure i regiony niesparowaneoraz umowy dotyczące poziomu usług dla usługi Azure Key Vault.

Uwagi dotyczące usługi Azure SQL dotyczące Geo-DR

• Aby zwiększyć odporność, użyj opcji strefowo nadmiarowej w usługach Azure SQL MI i Azure SQL DB. Aby uzyskać więcej informacji, zobacz Co to są strefy dostępności platformy Azure?.

• Użyj grup trybu failover dla usługi Azure SQL MI i usługi Azure SQL DB na potrzeby odzyskiwania po awarii w regionie pomocniczym. Aby uzyskać więcej informacji, zobacz przegląd grup przełączania awaryjnego & najlepsze praktyki.

• Konfiguracja może wymagać bardziej złożonej strefy DNS, jeśli prywatne punkty końcowe są używane w usłudze Azure SQL (na przykład nie może utworzyć dwóch prywatnych punktów końcowych do tego samego zasobu w tej samej strefie DNS).

• Upewnij się, że aplikacje korzystają z logiki ponawiania prób.

Istnieje kilka scenariuszy, w których klienci mogą chcieć wybrać rozwiązanie Zarządzane sprzętowe moduły zabezpieczeń (HSM) zamiast usługi AKV:

• Konieczność ręcznego połączenia z zapasowym magazynem.

• Wymaganie dostępu do odczytu do magazynu, nawet jeśli wystąpi awaria.

• Elastyczność wybierania regionu, w którym jest replikowany ich kluczowy materiał

  • Wymaga włączenia replikacji między regionami, która tworzy drugą zarządzaną pulę HSM w drugim regionie.

• Użycie zarządzanego modułu HSM umożliwia klientom utworzenie dokładnej repliki modułu HSM, jeśli oryginalny moduł zostanie utracony lub niedostępny.

• Korzystanie z zarządzanego modułu HSM na potrzeby wymagań dotyczących zabezpieczeń lub przepisów.

• Możliwość tworzenia kopii zapasowej całego magazynu w porównaniu z tworzeniem kopii zapasowych poszczególnych kluczy.

Aby uzyskać więcej informacji, zobacz Włącz replikację wieloregionową w usłudze Azure Managed HSM i odzyskiwanie po awarii Managed HSM.

Usługa Azure Policy dla funkcji TDE zarządzanej przez klienta

Usługa Azure Policy może służyć do wymuszania funkcji TDE zarządzanej przez klienta podczas tworzenia lub aktualizowania serwera usługi Azure SQL Database lub usługi Azure SQL Managed Instance. Dzięki tym zasadom wszelkie próby utworzenia lub zaktualizowania serwera logicznego na platformie Azure lub w wystąpieniu zarządzanym zakończy się niepowodzeniem, jeśli nie zostanie on skonfigurowany przy użyciu klucza zarządzanego przez klienta. Usługę Azure Policy można zastosować do całej subskrypcji platformy Azure lub tylko w ramach grupy zasobów.

Aby uzyskać więcej informacji na temat usługi Azure Policy, zobacz Co to jest usługa Azure Policy i struktura definicji usługi Azure Policy.

Następujące dwie wbudowane zasady są obsługiwane w przypadku szyfrowania TDE zarządzanego przez klienta w usłudze Azure Policy:

• Serwery SQL powinny używać kluczy zarządzanych przez klienta do szyfrowania danych magazynowanych
• Wystąpienia zarządzane powinny używać kluczy zarządzanych przez klienta do szyfrowania danych magazynowanych

Zasady TDE zarządzane przez klienta można zarządzać, przechodząc do witryny Azure Portal i wyszukując usługę Policy . W obszarze Definicje wyszukaj klucz zarządzany przez klienta.

Istnieją trzy efekty dla tych zasad:

• Inspekcja — ustawienie domyślne i przechwytuje raport inspekcji tylko w dziennikach aktywności usługi Azure Policy
• Odmowa — uniemożliwia tworzenie lub aktualizowanie serwera logicznego lub wystąpienia zarządzanego bez skonfigurowanego klucza zarządzanego przez klienta
• Wyłączone — spowoduje wyłączenie zasad i nie ograniczy użytkownikom możliwości tworzenia lub aktualizowania serwera logicznego ani wystąpienia zarządzanego bez włączonej funkcji TDE zarządzanej przez klienta

Jeśli usługa Azure Policy dla funkcji TDE zarządzana przez klienta ma wartość Odmów, tworzenie serwera logicznego usługi Azure SQL lub wystąpienia zarządzanego zakończy się niepowodzeniem. Szczegóły tego błędu zostaną zarejestrowane w dzienniku aktywności grupy zasobów.

Ważne

Wcześniejsze wersje wbudowanych zasad dla zarządzanej przez klienta funkcji TDE zawierającej AuditIfNotExist efekt zostały uznane za przestarzałe. Istniejące przypisania zasad wykorzystujące przestarzałe zasady nie są w żaden sposób dotknięte i będą nadal działać jak wcześniej.

Powiązana zawartość

• Obracanie funkcji ochrony przezroczystego szyfrowania danych dla usługi SQL Database
• Usuwanie funkcji ochrony przezroczystego szyfrowania danych (TDE) dla usługi SQL Database
• Zarządzanie przezroczystym szyfrowaniem danych w usłudze SQL Managed Instance przy użyciu własnego klucza przy użyciu programu PowerShell
• Usługa Microsoft Defender dla usługi SQL