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 na przykład scenariusz Bring Your Own Key (BYOK) na potrzeby ochrony danych w czasie spoczynku i pozwala organizacjom na wdrażanie 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 asymetryczny zarządzany przez klienta, używany do szyfrowania klucza szyfrowania bazy danych (DEK) i nazywany „protektorem TDE”, jest przechowywany w usłudze Azure Key Vault (AKV), czyli w chmurowym systemie zarządzania kluczami zewnętrznymi zarządzanym przez klienta. Usługa Key Vault jest wysoce dostępnym i skalowalnym bezpiecznym magazynem dla kluczy kryptograficznych RSA, opcjonalnie wspieranym przez sprzętowe moduły zabezpieczeń zweryfikowane zgodnie z poziomem 2 standardu FIPS 140-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 przechowalnię kluczy, zaimportowany lub przeniesiony do przechowalni kluczy z urządzenia HSM na miejscu.

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 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 w stanie spoczynku, wdrażane jest szyfrowanie infrastrukturalne (przy użyciu algorytmu AES-256) z kluczami zarządzanymi przez platformę. Zapewnia to dodatkową warstwę szyfrowania danych 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 master i inne systemowe bazy danych, będą szyfrowane po włączeniu 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 zarządzanego przez klienta szyfrowania TDE (Transparent Data Encryption)

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 mechanizmem ochronnym 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 stała się 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 mógł używać protektora TDE przechowywanego w usłudze AKV do szyfrowania DEK, Administrator Key Vault musi udzielić serwerowi praw dostępu przy użyciu unikatowej tożsamości 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 usługi szyfrowania Key Vault Crypto Service jest wymagana dla tożsamości serwera, aby móc używać klucza do operacji szyfrowania i odszyfrowywania.

• Zasady dostępu do skarbca — użyj zasad dostępu do skarbca kluczy, aby udzielić serwerowi dostępu do skarbca kluczy. Ta metoda jest prostsza i bardziej bezpośrednia, 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 danych
  • unwrapKey — aby można było usunąć ochronę (odszyfrować) DEK (klucz danych)

W menu Konfiguracja dostępu w portalu Azure magazynu kluczy, masz opcję wybrania kontroli dostępu opartej na rolach Azure lub polityki 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 Key Vault, aby można je było później skontrolować.

Gdy serwer jest skonfigurowany do używania protektora TDE z Azure Key Vault (AKV), serwer wysyła klucz szyfrowania DEK 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ć Azure Monitor do przeglądania dzienników zdarzeń audytowych magazynu kluczy, jeśli logowanie 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 dotyczące konfiguracji zarządzanego przez klienta szyfrowania TDE

Wymagania dotyczące konfigurowania usługi AKV

• Funkcje miękkiego usuwania i ochrony przed czyszczeniem muszą być włączone dla magazynu kluczy, aby chronić przed utratą danych z powodu przypadkowego usunięcia klucza (lub samego magazynu kluczy).

• Przyznaj dostęp serwerowi lub wystąpieniu zarządzanemu do magazynu kluczy (get, wrapKey, unwrapKey) korzystając z tożsamości 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 oraz Konfigurowanie szyfrowania TDE z użyciem funkcji BYOK dla usługi SQL Managed Instance.

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

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

Włącz ochronę usuwania tymczasowego i ochronę przed trwałym usunięciem w usłudze AKV

Ważne

Zarówno miękkie usuwanie, jak i ochrona przed wyczyszczeniem muszą być włączone w magazynie kluczy podczas konfigurowania funkcji TDE zarządzanej przez użytkownika na nowym lub istniejącym serwerze lub zarządzanym wystąpieniu.

Nietrwałe usuwanie i ochrona przed czyszczeniem są ważnymi funkcjami usługi Azure Key Vault, które umożliwiają odzyskiwanie usuniętych skarbców i usuniętych obiektów skarbca kluczy, co zmniejsza ryzyko przypadkowego lub złośliwego usunięcia klucza lub skarbców kluczy.

• Zasoby tymczasowo usunięte są przechowywane przez 90 dni, chyba że zostaną odzyskane lub trwale usunięte przez klienta. Akcje odzyskiwania i usuwania mają własne uprawnienia skojarzone z polityką dostępu do magazynu kluczy. Funkcja miękkiego usuwania jest domyślnie włączona dla nowych magazynów kluczy i może być również włączona przy użyciu portalu Azure, programu PowerShell lub Azure CLI.

• 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 tymczasowym i ochrony przed opróżnieniem w magazynie kluczy zawierającym klucz szyfrowania używany jako ochroniarz TDE dla serwera lub instancji zarządzanej. Pomaga to zapobiec przypadkowemu lub złośliwemu usunięciu magazynu kluczy lub klucza, co może prowadzić do przejścia bazy danych w stan niedostępności.

• Podczas konfigurowania mechanizmu ochrony TDE na istniejącym serwerze lub podczas tworzenia serwera usługa Azure SQL sprawdza, czy używany magazyn kluczy ma włączoną ochronę miękkiego usuwania i ochronę przed czyszczeniem. Jeśli funkcje miękkiego usuwania i ochrony przed przeczyszczeniem nie są włączone w magazynie kluczy, instalacja ochrony TDE kończy się błędem. W tym przypadku należy najpierw włączyć funkcje usuwania nietrwałego i ochrony przed przeczyszczeniem w magazynie kluczy, a następnie wykonać konfigurację ochrony TDE.

Wymagania dotyczące konfigurowania funkcji ochrony TDE

• Ochrona TDE może być tylko kluczem asymetrycznym, kluczem RSA lub kluczem 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 HSM i konfiguracji lub uprawnień RBAC 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.

Zalecenia dotyczące konfiguracji zarządzanego przez klienta szyfrowania Transparent Data Encryption (TDE)

Zalecenia dotyczące konfigurowania usługi AKV

• Skojarz maksymalnie 500 baz danych ogólnego przeznaczenia lub 200 biznesowo krytycznych z sejfem kluczy w jednej subskrypcji, aby zapewnić wysoką dostępność, gdy serwer uzyskuje dostęp do protektora TDE w sejfie kluczy. Te dane są oparte na doświadczeniu i udokumentowane w limitach usługi magazynu kluczy. Celem jest zapobieganie problemom po przełączeniu serwera na tryb failover, ponieważ spowoduje to wykonanie tylu kluczowych operacji względem skarbca, ile jest baz danych na tym serwerze.

• Ustaw blokadę zasobu dla magazynu kluczy, aby kontrolować, kto ma możliwość 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ę protektora TDE w bezpiecznym miejscu lub przekaż ją do usługi escrow.

• Jeśli klucz jest generowany w magazynie kluczy, utwórz jego kopię zapasową przed pierwszym użyciem w Azure Key Vault (AKV). Kopię zapasową 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 wymiany 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 AKV, nawet po przejściu na klucze zarządzane przez usługę. Zapewnia możliwość przywrócenia kopii zapasowych baz danych przy użyciu ochron TDE przechowywanych w Azure Key Vault (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 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 ochrony TDE może być wykonywana ręcznie lub za pomocą funkcji zautomatyzowanego obracania.

Automatyczna rotacja ochraniacza TDE można włączyć podczas konfigurowania ochraniacza TDE dla serwera. Automatyczne obracanie jest domyślnie wyłączone. Po włączeniu serwer będzie stale sprawdzać Key Vault w poszukiwaniu nowych wersji klucza używanego jako ochrona 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 automatyczną rotacją kluczy w usłudze Azure Key Vault, ta funkcja umożliwia kompleksową, bezobsługową rotację dla ochrony TDE w usłudze Azure SQL Database i usłudze Azure SQL Managed Instance.

Uwaga

Ustanowienie TDE z użyciem klucza CMK przy ręcznym lub zautomatyzowanym obrotem kluczy zawsze będzie korzystać z najnowszej wersji klucza, która jest obsługiwana. 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 główne, jak i zapasowe, muszą mieć uprawnienia Get, wrapKey oraz unwrapKey do magazynu kluczy serwera głównego (to jest magazynu kluczy, który zawiera klucz ochrony TDE serwera głównego).

• 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, który jest używany z serwerem podstawowym (a nie do innego klucza 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 z użyciem kluczy zarządzanych przez klienta (CMK) dla 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. Jedynym działaniem dozwolonym na bazie danych znajdującej się w stanie Niedostępności jest jej usunięcie.

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 przełączenie awaryjne 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 naprawiona 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ś posiadający wystarczające uprawnienia dostępu do magazynu kluczy przypadkowo wyłączy dostęp serwera do tego klucza poprzez:

• cofanie uprawnień key vault "get", "wrapKey", "unwrapKey" z serwera

• usuwanie klucza

• usuwanie magazynu kluczy

• zmienianie reguł zapory magazynu kluczy

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

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

Przerwa w łączności sieciowej między usługą SQL Managed Instance a 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 przez wystąpienie zarządzane. Wszystkie scenariusze, w których można dotrzeć do punktu końcowego kluczy, ale następuje odmowa połączenia, brak uprawnień itp., spowodują, że bazy danych zmienią swój stan na Niedostępny.

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

• Usługa Key Vault jest udostępniana za pośrednictwem prywatnego punktu końcowego, a prywatny adres IP usługi Key Vault nie jest uwzględniony w regułach ruchu wychodzącego sieciowej grupy zabezpieczeń powiązanej 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 dla 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/powiadomień push/głosowe, Logic App, webhook, ITSM lub Automation Runbook.

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 kluczem o odpowiednim odcisku 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 URI 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 ochrona 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 temu, że usługa AKV zapewnia wiele warstw nadmiarowości, TDE używające klucza zarządzanego przez klienta mogą w pełni korzystać z dostępności i odporności usługi AKV oraz polegać na jej rozwiązaniu nadmiarowości.

Wiele warstw nadmiarowości w usłudze AKV zapewnia dostęp do klucza, nawet jeśli poszczególne składniki usługi ulegają awarii, a regiony platformy Azure lub strefy dostępności są niedostępne. 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 awaryjny w regionie
• Przełączanie awaryjne 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 usługi Azure Key Vault, zarówno w wersji Standard, jak i Premium, jak również kluczy oprogramowania lub 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 zapasowy mogą być połączone z tą samą skrytką na klucze (w dowolnym regionie). Pomaga to uniknąć scenariuszy, w których kluczowe materiały mogą być niesynchronizowane, jeśli dla obu serwerów używane są osobne 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 ładuj klucze w usłudze Azure Key Vault w oddzielnych instancjach 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 w usłudze AKV jest inicjowany przez serwis 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 skarbca, nawet w przypadku awarii.

• 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 sejfu 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.

Zasady Azure dla zarządzanej przez klienta funkcji TDE

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 zasady wbudowane są obsługiwane w przypadku zarządzanego przez klienta szyfrowania TDE w usłudze Azure Policy.

• Serwery SQL powinny używać kluczy zarządzanych przez klienta do szyfrowania danych w stanie spoczynku.
• Wystąpienia zarządzane powinny używać kluczy zarządzanych przez klienta do szyfrowania danych spoczynkowych

Zasadami TDE zarządzanymi przez klienta można zarządzać, przechodząc do portalu Azure 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 i aktualizację serwera logicznego lub instancji zarządzanej bez skonfigurowanego klucza zarządzanego przez klienta
• Wyłączone — Wyłączy politykę, i nie będzie ograniczać użytkownikom możliwości tworzenia lub aktualizowania serwera logicznego ani zarządzanego wystąpienia bez włączonej funkcji TDE zarządzanej przez klienta

Jeśli zasady usługi Azure dla funkcji TDE zarządzane przez klienta są ustawione na Odmów, tworzenie logicznego serwera Azure SQL lub zarządzanego wystąpienia 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 TDE zarządzanego przez klienta, zawierające AuditIfNotExist działanie, 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ść

• Obróć klucz ochrony przezroczystego szyfrowania danych dla bazy danych SQL
• 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