Udostępnij za pośrednictwem

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 funkcja ochrony Transparent Data Encryption (TDE) — klucz asymetryczny zarządzany przez klienta używany do zabezpieczania klucza szyfrowania bazy danych (DEK) — jest przechowywany w usłudze Azure Key Vault lub zarządzanym module HSM usługi Azure Key Vault. Są to bezpieczne, oparte na chmurze usługi zarządzania kluczami zaprojektowane pod kątem wysokiej dostępności i skalowalności. Usługa Azure Key Vault obsługuje klucze RSA i może być wspierana przez zweryfikowane moduły HSM ze standardem FIPS 140–2 poziom 2. W przypadku klientów wymagających większej gwarancji zarządzany moduł HSM usługi Azure Key Vault oferuje zweryfikowany sprzęt FIPS 140-2 poziom 3. Klucz można wygenerować w usłudze, zaimportować lub bezpiecznie przenieść z lokalnych modułów HSM. Bezpośredni dostęp do kluczy jest ograniczony — autoryzowane usługi wykonują operacje kryptograficzne bez ujawniania materiału klucza.

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 ochraniacz TDE jest ustawiany na poziomie instancji i dziedziczony przez wszystkie zaszyfrowane bazy danych na tej instancji. 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.

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 usłudze Azure Key Vault lub zarządzanym module HSM platformy Azure i używany do szyfrowania klucza szyfrowania bazy danych (DEK) w usłudze Azure SQL, programie SQL Server na maszynie wirtualnej platformy Azure i lokalnym programie SQL Server.
  • Bring Your Own Key (BYOK) — 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 platformy Azure. 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 protektora TDE.

  • Możliwość zaimplementowania rozdzielenia obowiązków w zarządzaniu kluczami i danymi w organizacji.

  • Administrator usługi Azure 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 Azure Key Vault.

  • Większe zaufanie klientów końcowych, ponieważ usługa Azure Key Vault 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.

Uprawnienia do konfigurowania funkcji TDE zarządzanej przez klienta

Diagram przedstawiający konfigurację i funkcjonowanie funkcji TDE zarządzanej przez klienta.

Wybierz typ usługi Azure Key Vault, którego chcesz użyć.

Aby serwer logiczny na platformie Azure mógł używać protektora TDE przechowywanego w usłudze Azure Key Vault do szyfrowania DEK, administrator usługi Key Vault musi udzielić uprawnień dostępu do serwera przy użyciu unikatowej 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. 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 skrytce kluczy.

    • get — do pobierania części publicznej i właściwości klucza z usługi Azure 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, serwer wysyła klucz szyfrowania danych (DEK) poszczególnych baz danych TDE do magazynu kluczy do szyfrowania. Magazyn kluczy zwraca zaszyfrowany DEK, 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łanie uprawnień dostępu do ochrony TDE w usłudze Azure Key Vault (AKV), a użytkownicy w tym okresie czasu mogą nadal posiadać uprawnienia dostępu.

Wymagania dotyczące konfigurowania funkcji TDE zarządzanej przez klienta

  • Funkcje miękkiego usuwania i ochrony przed usunięciem muszą być włączone w usłudze Azure Key Vault. 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.

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

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 podany w jednym z obsługiwanych formatów plików: .pfx, lub .byok.backup. Aby zaimportować klucze chronione przez moduł HSM do zarządzanego modułu HSM platformy Azure, zobacz Importowanie kluczy chronionych przez moduł HSM do zarządzanego modułu HSM (BYOK).

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 usługi Azure Key Vault, 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)

  • 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 Azure Key Vault. 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 wszystkich kluczy szyfrowania: usługa Azure Key Vault 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 funkcji TDE zarządzanej przez klienta, usługi Azure SQL Database i azure SQL Managed Instance w jednym regionie można teraz połączyć z usługą Azure Key Vault 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 kopię zapasową klucza przed użyciem klucza w usłudze Azure Key Vault po raz pierwszy. Kopię zapasową można przywrócić tylko do usługi Azure Key Vault. Dowiedz się więcej o poleceniu Backup-AzKeyVaultKey . Zarządzany moduł HSM platformy Azure obsługuje tworzenie pełnej kopii zapasowej całej zawartości modułu HSM, w tym wszystkich kluczy, wersji, atrybutów, tagów i przypisań ról. Aby uzyskać więcej informacji, zobacz Pełne tworzenie kopii zapasowej i przywracanie i selektywne przywracanie klucza.

  • 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 lub zarządzanym module HSM 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.

  • Zachowaj wszystkie wcześniej używane klucze w usłudze Azure Key Vault lub zarządzanym module HSM platformy Azure, nawet po przełączeniu do kluczy zarządzanych przez usługę. Zapewnia to przywrócenie kopii zapasowych bazy danych za pomocą funkcji ochrony TDE przechowywanych w usłudze Azure Key Vault lub zarządzanym module HSM platformy Azure. Funkcje ochrony TDE utworzone za pomocą usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure 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ć magazyn kluczy lub Zarządzany HSM, czy są dostępne nowe wersje klucza używanego jako protektor 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 obracaniem kluczy w usłudze Azure Key Vault lub autorotyzacją w zarządzanym module HSM platformy Azure ta funkcja umożliwia kompleksową rotację bezobsługową dla funkcji ochrony TDE w usługach Azure SQL Database i 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 zautomatyzowanej rotacji osłony 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 lub zarządzanym systemie HSM, który jest używany z serwerem podstawowym (a nie innego klucza 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 do magazynu kluczy serwera podstawowego lub zarządzanego modułu HSM, 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 lub zarządzanym urządzeniu HSM używanym z serwerem podstawowym (a nie do innego klucza o tym samym materiale 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 Azure Key Vault lub zarządzanym module HSM platformy Azure, 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.

Stan niedostępny

Jeśli baza danych jest niedostępna z powodu sporadycznej awarii sieci (na przykład błędu 5XX), nie jest wymagana żadna akcja, ponieważ bazy danych zostaną automatycznie przywrócone w trybie online. Aby zmniejszyć wpływ błędów sieci lub awarii podczas uzyskiwania dostępu do funkcji ochrony TDE w usłudze Azure Key Vault lub zarządzanym module HSM platformy Azure, 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.

Jeśli serwer utraci dostęp do funkcji ochrony TDE zarządzanej przez klienta w usłudze Azure Key Vault lub zarządzanym module HSM platformy Azure z powodu dowolnego błędu usługi Azure Key Vault (takiego jak błąd 4XX), baza danych zostanie przeniesiona do stanu niedostępnego po 30 minutach.

Przywracanie dostępu do bazy danych po błędzie Azure Key Vault lub zarządzanego modułu HSM na platformie Azure

Po przywróceniu dostępu do klucza przywrócenie bazy danych w trybie online wymaga dodatkowego czasu i kroków, które mogą się różnić w zależności od czasu niedostępności klucza i rozmiaru danych w bazie danych.

Jeśli dostęp do klucza zostanie przywrócony w ciągu 30 minut, baza danych zostanie automatycznie przywrócona w ciągu kolejnej godziny. Jeśli jednak dostęp do klucza zostanie przywrócony po ponad 30 minutach, automatyczne naprawianie bazy danych nie jest możliwe. W takich przypadkach przywracanie bazy danych obejmuje dodatkowe procedury za pośrednictwem witryny Azure Portal i może być czasochłonne, w zależności od rozmiaru bazy danych.

Gdy baza danych znów będzie dostępna online, wcześniej skonfigurowane ustawienia serwera, w tym konfiguracje grup failover, tagi i ustawienia bazy danych, takie jak konfiguracje elastycznej puli, 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ę zaimplementowanie przez klientów systemu powiadomień w celu wykrycia utraty dostępu do klucza szyfrowania w ciągu 30 minut. Po wygaśnięciu 30-minutowego okna 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ś, mający wystarczające prawa dostępu do magazynu kluczy lub zarządzanego modułu HSM, przypadkowo wyłączy dostęp serwera do klucza przez:

  • Cofanie uprawnień get, wrapKey, unwrapKey z serwera lub zarządzanego magazynu kluczy HSM.

  • usuwanie klucza

  • usuwanie magazynu kluczy lub zarządzanego modułu HSM

  • zmienianie reguł zapory modułu HSM lub 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ą Azure Key Vault lub zarządzanym modułem HSM platformy Azure

Blok łączności sieciowej między usługą SQL Managed Instance i magazynem kluczy lub zarządzanym modułem HSM występuje głównie wtedy, gdy istnieje magazyn kluczy lub zarządzany zasób HSM, 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 magazynu kluczy lub zarządzanego punktu końcowego modułu HSM, ale 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ą Azure Key Vault lub zarządzanym modułem HSM platformy Azure to:

  • Usługa Azure Key Vault lub zarządzany moduł HSM platformy Azure jest uwidaczniona za pośrednictwem prywatnego punktu końcowego, a prywatny adres IP usługi Azure Key Vault lub usługi Azure Managed HSM 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 FQDN usługi Key Vault lub zarządzanego HSM nie jest rozpoznawany lub jest rozpoznawany jako nieprawidłowy adres IP.

Przetestuj łączność z SQL Managed Instance do Azure Key Vault lub Azure Managed HSM hostujących TDE protector.

  • 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 lub zarządzanego prywatnego punktu końcowego modułu HSM.
    • Sprawdź inne konfiguracje sieci, takie jak tabela tras, istnienie urządzenia wirtualnego i jego konfiguracji itp.

Monitorowanie 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 jest aktualizowany, gdy dostęp do ochraniacza TDE w magazynie kluczy zarządzanych przez klienta kończy się niepowodzeniem. 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 Azure Key Vault lub zarządzanego modułu HSM platformy Azure wszystkie nowo wygenerowane kopie zapasowe są również szyfrowane przy użyciu tej samej funkcji ochrony TDE. 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 Azure Key Vault lub zarządzanego modułu HSM platformy Azure, upewnij się, że materiał klucza jest dostępny dla serwera docelowego. Dlatego zalecamy zachowanie wszystkich starych wersji ochrony TDE w skrytce kluczy lub zarządzanym module HSM, aby można było przywrócić kopie zapasowe bazy danych.

Ważne

W każdej chwili nie można ustawić więcej niż jednej funkcji ochrony TDE dla serwera. Klucz oznaczony jako Ustaw klucz jako domyślny protektor TDE w okienku portalu Azure jest protektorem TDE. Jednak wiele 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 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 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 lub zarządzanym module HSM platformy Azure, 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

Usługa Azure Key Vault lub Azure Managed HSM zapewniają wiele warstw nadmiarowości. TDE z kluczem zarządzanym przez klienta mogą korzystać z dostępności i odporności tych usług, w pełni polegając na rozwiązaniu redundancji zapewnianym przez Azure Key Vault lub Azure Managed HSM.

Wiele warstw nadmiarowości usługi Azure Key Vault zapewnia dostęp do klucza, nawet jeśli poszczególne składniki usługi zawodzą lub gdy regiony platformy Azure bądź strefy dostępności są niedostępne. Aby uzyskać więcej informacji, zobacz Dostępność i nadmiarowość usługi Azure Key Vault.

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

Uwaga

W przypadku wszystkich regionów par klucze usługi Azure Key Vault 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.

Replikacja wieloregionowa zarządzanego modułu HSM platformy Azure umożliwia rozszerzenie puli zarządzanego modułu HSM platformy Azure z jednego regionu platformy Azure (nazywanego regionem podstawowym) do innego regionu świadczenia usługi Azure (nazywanego regionem rozszerzonym). Po skonfigurowaniu oba regiony są aktywne, mogą obsługiwać żądania i, za pomocą replikacji automatycznej, współużytkować ten sam materiał, role i uprawnienia klucza. Aby uzyskać więcej informacji, zobacz Włączanie replikacji w wielu regionach w zarządzanym module HSM platformy Azure.

Odzyskiwanie danych po awarii na poziomie geograficznym i TDE zarządzane przez klienta

Zarówno w scenariuszach aktywnej replikacji geograficznej, jak i grupach awarii, serwery podstawowe i pomocnicze mogą być połączone z usługą Azure Key Vault lub zarządzanym modułem HSM Azure znajdującym się w dowolnym regionie. Serwer i magazyn kluczy lub zarządzany moduł HSM nie muszą znajdować się w tym samym regionie. Dzięki temu dla uproszczenia serwery podstawowe i pomocnicze mogą być połączone z tym samym magazynem kluczy lub zarządzanym modułem HSM (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 lub zarządzane moduły HSM. 

Usługa Azure Key Vault i zarządzany moduł HSM platformy Azure mają wiele warstw nadmiarowości, aby upewnić się, że klucze i magazyny kluczy pozostają dostępne w przypadku awarii usług lub regionów. 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 klienckiego modułu HSM i ładowania kluczy w oddzielnych magazynach Azure Key Vault w wielu regionach.

  • Skorzystaj z zarządzanego modułu HSM platformy Azure 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 zapasowego) dla usługi Azure Key Vault z mechanizmem cross-failover i konfiguracją usługi Azure SQL do replikacji geograficznej za pomocą grupy trybu failover.

diagram przedstawiający obsługę trybu failover usługi Azure Key Vault w wielu regionach dla sparowanego regionu.

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 Azure Key Vault w regionie podstawowym.

  • Przełączenie awaryjne usługi Azure Key Vault jest inicjowane przez usługę Azure Key Vault, a nie przez klienta.

  • W przypadku przełączenia awaryjnego usługi Azure Key Vault do regionu zapasowego, serwer w usłudze Azure SQL nadal może uzyskać dostęp do tego samego magazynu kluczy Azure. Mimo że wewnętrznie połączenie usługi Azure Key Vault jest przekierowywane do usługi Azure Key Vault w regionie pomocniczym.

  • Nowe operacje tworzenia kluczy, ich importowanie i rotacja są możliwe tylko wtedy, gdy Azure Key Vault w głównym regionie jest dostępny.

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

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

  • Usługa Azure Key Vault jest w stanie tylko do odczytu, gdy usługa Azure Key Vault w regionie podstawowym jest niedostępna

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

  • W przypadku niepairowanych regionów zarówno serwery Azure SQL uzyskują dostęp do usługi Azure Key Vault w pierwszym regionie (jak wskazano na grafie), a usługa Azure Key Vault używa magazynu strefowo nadmiarowego do replikowania danych w regionie w niezależnych strefach dostępności w tym samym regionie.

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 z nadmiarowością strefową w usługach Azure SQL Managed Instance i Azure SQL Database. 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.

  • Gdy baza danych jest częścią aktywnej replikacji geograficznej lub grup przełączenia awaryjnego i staje się niedostępna, płaszczyzna sterowania SQL przerywa łącze i konwertuje bazę danych na bazę danych niezależną. Po naprawieniu uprawnień klucza podstawowa baza danych może być zwykle przywracana w trybie online. Nie można przywrócić pomocniczej bazy danych w trybie online, ponieważ usługa Azure SQL nie wykonuje pełnych kopii zapasowych pomocniczych baz danych zgodnie z projektem. Zaleca się usunięcie pomocniczych baz danych i ponowne ustanowienie linku.

  • 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 azure Managed HSM za pośrednictwem usługi Azure Key Vault:

  • 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ą pulę modułu HSM zarządzanego przez platformę Azure w drugim regionie.

  • Korzystanie z zarządzanego modułu HSM platformy Azure umożliwia klientom utworzenie dokładnej repliki dla modułu HSM, jeśli oryginał zostanie utracony lub niedostępny.

  • Korzystanie z zarządzanego modułu HSM platformy Azure 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ść