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

  • Artykuł

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

Funkcja Transparent Data Encryption (TDE) usługi Azure SQL z kluczem zarządzanym przez klienta (CMK) umożliwia korzystanie ze scenariusza "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

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

Jeśli rozważasz przejście z szyfrowania TDE zarządzanego przez usługę na szyfrowanie TDE zarządzane przez klienta, pamiętaj, że dane pozostają zaszyfrowane w trakcie procesu zmiany i nie ma żadnego przestoju ani nie jest przeprowadzane ponowne szyfrowanie 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

Konfigurowanie i funkcjonowanie funkcji TDE zarządzanej przez klienta

Aby serwer logiczny na platformie Azure używał funkcji ochrony TDE przechowywanej w usłudze AKV do szyfrowania klucza szyfrowania klucza, administrator magazynu kluczy musi udzielić następujących praw dostępu do serwera przy użyciu unikatowej tożsamości firmy Microsoft Entra:

  • 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

Administrator magazynu kluczy 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. 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

Usługa Azure SQL obsługuje teraz używanie 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 o zarządzanych modułach HSM.

Uwaga

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 zaczekaj 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

Rekomendacje podczas 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ż istnieją bazy danych na tym serwerze.

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

  • Połącz każdy serwer z dwoma magazynami kluczy, które znajdują się w różnych regionach i przechowują ten sam materiał klucza, aby zapewnić wysoką dostępność zaszyfrowanych baz danych. Oznacz klucz z jednego z magazynów kluczy jako funkcję ochrony TDE. System automatycznie przełączy się do magazynu kluczy w drugim regionie z tym samym materiałem klucza, jeśli wystąpi awaria wpływająca na magazyn kluczy w pierwszym regionie.

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ą znajdować się w tym samym regionie.

Rekomendacje podczas 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 do celów 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.

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.

Niedostępna baza danych TDE BYOK

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

W usłudze SQL Managed Instance błędy sieci podczas próby uzyskania dostępu do funkcji ochrony TDE w usłudze Azure Key Vault mogą nie spowodować, że bazy danych zmienią stan na Niedostępny , ale spowodują, że wystąpienie będzie później niedostępne. Dzieje się tak głównie wtedy, gdy zasób magazynu kluczy istnieje, ale nie można uzyskać dostępu do jego punktu końcowego 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.

Tworzenie i przywracanie kopii zapasowych za pomocą funkcji TDE zarządzanej 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 będą potrzebne do przywrócenia bazy danych. Jeśli plik dziennika używa funkcji ochrony TDE przechowywanej w usłudze Azure Key Vault, ten klucz będzie 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

Nawet w przypadkach, gdy nie skonfigurowano nadmiarowości geograficznej dla serwera, zdecydowanie zaleca się skonfigurowanie serwera pod kątem używania dwóch różnych magazynów kluczy w dwóch różnych regionach z tym samym materiałem klucza. Klucz w pomocniczym magazynie kluczy w innym regionie nie powinien być oznaczony jako funkcja ochrony TDE i nie jest nawet dozwolony. Jeśli wystąpi awaria magazynu kluczy podstawowych, a dopiero wtedy system automatycznie przełączy się do innego połączonego klucza z tym samym odciskiem palca w pomocniczym magazynie kluczy, jeśli istnieje. Należy pamiętać, że przełącznik nie będzie występować, jeśli funkcja ochrony TDE jest niedostępna z powodu odwołanych praw dostępu lub ponieważ klucz lub magazyn kluczy jest usuwany, ponieważ może to wskazywać, że klient celowo chciał ograniczyć serwerowi dostęp do klucza. Udostępnienie tego samego materiału klucza dwóm magazynom kluczy w różnych regionach można wykonać, tworząc klucz poza magazynem kluczy i importując je do obu magazynów kluczy.

Alternatywnie można to zrobić, generując klucz przy użyciu podstawowego magazynu kluczy w jednym regionie i klonując klucz do magazynu kluczy w innym regionie świadczenia usługi Azure. Użyj polecenia cmdlet Backup-AzKeyVaultKey, aby pobrać klucz w formacie zaszyfrowanym z podstawowego magazynu kluczy, a następnie użyć polecenia cmdlet Restore-AzKeyVaultKey i określić magazyn kluczy w drugim regionie, aby sklonować klucz. Alternatywnie użyj witryny Azure Portal, aby utworzyć kopię zapasową i przywrócić klucz. Operacja tworzenia/przywracania klucza jest dozwolona tylko między magazynami kluczy w ramach tej samej subskrypcji platformy Azure i lokalizacji geograficznej platformy Azure.

Wysoka dostępność pojedynczego serwera

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

Zarówno w scenariuszach aktywnych replikacji geograficznej, jak i grup trybu failover, serwery podstawowe i pomocnicze mogą być połączone z tym samym magazynem kluczy (w dowolnym regionie) lub oddzielnymi magazynami kluczy. Jeśli oddzielne magazyny kluczy są połączone z serwerami podstawowymi i pomocniczymi, klient jest odpowiedzialny za utrzymywanie spójnego materiału klucza w magazynach kluczy, dzięki czemu geograficzna pomocnicza jest zsynchronizowana i może przejąć użycie tego samego klucza z połączonego magazynu kluczy, jeśli 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 uniknąć problemów podczas ustanawiania lub podczas replikacji geograficznej z powodu niekompletnego materiału klucza, należy przestrzegać tych reguł podczas konfigurowania funkcji TDE zarządzanej przez klienta (jeśli oddzielne magazyny kluczy są używane dla serwerów podstawowych i pomocniczych):

  • Wszystkie zaangażowane magazyny kluczy muszą mieć te same właściwości i te same prawa dostępu dla odpowiednich serwerów.

  • Wszystkie zaangażowane magazyny kluczy muszą zawierać identyczny materiał klucza. Dotyczy to nie tylko bieżącej funkcji ochrony TDE, ale wszystkich poprzednich funkcji ochrony TDE, które mogą być używane w plikach kopii zapasowej.

  • Najpierw należy najpierw najpierw skonfigurować początkową i rotację funkcji ochrony TDE, a następnie na serwerze podstawowym.

Grupy trybu failover i geograficzne odzyskiwanie po awarii

Aby przetestować tryb failover, wykonaj kroki opisane w temacie Omówienie aktywnej replikacji geograficznej. Testowanie pracy w trybie failover powinno odbywać się regularnie, aby sprawdzić, czy usługa SQL Database utrzymuje uprawnienia dostępu do obu magazynów kluczy.

Serwer usługi Azure SQL Database i wystąpienie zarządzane SQL w jednym regionie można teraz połączyć z magazynem kluczy w dowolnym innym regionie. Serwer i magazyn kluczy nie muszą znajdować się 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 w celu zapewnienia, że klucze i magazyny kluczy pozostaną dostępne w przypadku awarii usługi lub regionu. Dostępność i nadmiarowość usługi Azure Key Vault

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 używające przestarzałych zasad nie mają wpływu i będą nadal działać tak jak wcześniej.

Następne kroki

Możesz również sprawdzić następujące przykładowe skrypty programu PowerShell dotyczące typowych operacji za pomocą funkcji TDE zarządzanej przez klienta:

Ponadto włącz usługę Microsoft Defender for SQL , aby zabezpieczyć bazy danych i ich dane przy użyciu funkcji odnajdywania i ograniczania potencjalnych luk w zabezpieczeniach bazy danych oraz wykrywania nietypowych działań, które mogą wskazywać na zagrożenie dla baz danych.