Customer-managed TDE for Azure Synapse Analytics

Dotyczy: Dedykowane pule SQL dla Azure Synapse Analytics (poprzednio SQL DW)

Wskazówka

Microsoft Fabric Data Warehouse to magazyn relacyjny w skali przedsiębiorstwa na podstawie bazy danych data lake z architekturą gotową do użycia w przyszłości, wbudowaną sztuczną inteligencją i nowymi funkcjami. Jeśli dopiero zaczynasz korzystać z magazynowania danych, zacznij od Fabric Data Warehouse. Istniejące obciążenia dedykowanej puli SQL mogą zostać zaktualizowane do Fabric, aby uzyskać dostęp do nowych możliwości w zakresie nauki o danych, analizy w czasie rzeczywistym i raportowania.

Transparentne szyfrowanie danych (TDE) z kluczem zarządzanym przez klienta (CMK) umożliwia scenariusz Bring Your Own Key (BYOK) do ochrony danych w spoczynku oraz umożliwia organizacjom wdrożenie rozdziału obowiązków w zarządzaniu kluczami i danymi. Korzystając z TDE zarządzanego przez klienta, bierzesz odpowiedzialność i pełną kontrolę nad zarządzaniem cyklem życia kluczy (tworzenie, przesyłanie, rotacja, usuwanie kluczy), uprawnieniami do korzystania z kluczy oraz audytem operacji nad kluczami.

W tym scenariuszu ochroniarz Transparent Data Encryption (TDE) jest kluczem zarządzanym przez klienta, który zabezpiecza Klucz Szyfrowania Bazy Danych (DEK). Protektor TDE przechowujesz w Azure Key Vault lub Azure Key Vault Managed HSM, czyli bezpiecznych, chmurowych usługach zarządzania kluczami, zaprojektowanych z myślą o wysokiej dostępności i skalowalności. Obie usługi obsługują klucze kryptograficzne chronione przez sprzęt zweryfikowany według FIPS 140-2: Azure Key Vault obsługuje FIPS 140-2 poziom 2, a Azure Key Vault Managed HSM obsługuje FIPS 140-2 poziom 3. Obie usługi obsługują również asymetryczne i symetryczne typy kluczy, a obsługiwane algorytmy i wykorzystanie zależą od modelu wdrożenia TDE. Możesz wygenerować klucz w usłudze, zaimportować go lub bezpiecznie przenieść z lokalnych HSM. Bezpośredni dostęp do kluczy jest ograniczony, więc autoryzowane usługi wykonują operacje kryptograficzne bez ujawniania materiału klucza.

Note

Ten artykuł dotyczy samodzielnych dedykowanych pul SQL (dawniej SQL DW).

  • Dla dedykowanych pul SQL w Azure Synapse Analytics (dawniej SQL DW) ustaw protektor TDE na poziomie serwera. Wszystkie zaszyfrowane bazy danych powiązane z tym serwerem dziedziczą ochronę TDE.
  • Szyfruj dane w dedykowanych pulach SQL oraz bezserwerowych pulach SQL w przestrzeni roboczej Synapse, używając klucza zarządzanego przez klienta skonfigurowanego na poziomie przestrzeni roboczej. Aby uzyskać więcej informacji na temat przezroczystego szyfrowania danych dla dedykowanych pul SQL w obszarach roboczych usługi Synapse, zobacz Szyfrowanie usługi Azure Synapse Analytics.

Klucz zarządzany przez klienta (CMK) i Bring Your Own Key (BYOK)

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) – Zarządzasz cyklem życia klucza, w tym tworzeniem, rotacją i usuwaniem klucza. Przechowuj klucz w Azure Key Vault lub Azure Managed HSM i używaj go do szyfrowania Database Encryption Key (DEK).

  • Bring Your Own Key (BYOK) – Bezpiecznie przenosisz lub importujesz własny klucz z lokalnego modułu zabezpieczeń sprzętowych (HSM) do 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).

Korzyści wynikające z zarządzanego przez klienta szyfrowania TDE (Transparent Data Encryption)

TDE zarządzane przez klienta zapewnia następujące korzyści:

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

Important

Dla osób korzystających z TDE zarządzanego przez usługi, które chcą zacząć korzystać z TDE zarządzanego przez klienta, dane pozostają zaszyfrowane podczas procesu przełączania, a nie występuje przestój ani 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.

Uprawnienia do konfigurowania TDE zarządzanego przez klienta w Azure Key Vault

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

Aby logiczny serwer SQL w Azure mógł korzystać z ochrony TDE przechowywanej w Azure Key Vault do szyfrowania DEK, administrator Key Vault musi przyznać prawa dostępu do serwera, używając unikalnej 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. Tożsamość serwera wymaga roli Key Vault Crypto Service Encryption User, aby używać tego klucza do operacji szyfrowania i deszyfrowania.

  • 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 wymaga następujących uprawnień do magazynu 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 dostępu do usługi Azure Key Vault dla funkcji TDE, zobacz Set up SQL Server TDE Extensible Key Management by using 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 konfigurujesz serwer do korzystania z protektora TDE z usługi Azure Key Vault, serwer wysyła klucz DEK każdej bazy danych z włączonym mechanizmem TDE do usługi Azure Key Vault w celu jego zaszyfrowania. Sejf kluczy zwraca zaszyfrowany DEK, który serwer przechowuje w bazie danych użytkowników.

W razie potrzeby serwer wysyła zabezpieczony DEK do magazynu kluczy w celu odszyfrowania.

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

Note

Może minąć około 10 minut, zanim jakiekolwiek zmiany uprawnień dla usługi Key Vault wejdą w życie. Ten czas obejmuje cofnięcie uprawnień dostępu do protektora TDE w AKV, a użytkownicy mogą nadal mieć uprawnienia dostępu.

Wymagania do konfiguracji TDE zarządzanego przez klienta w Azure Key Vault

  • Włącz funkcje usuwania nietrwałego i ochrony przed usunięciem trwałym w usłudze Azure Key Vault. Ta konfiguracja pomaga zapobiegać przypadkowemu lub złośliwemu usuwaniu magazynu kluczy lub klucza, które może doprowadzić do przejścia bazy danych w stan Niedostępny. Gdy konfigurujesz ochronę TDE na istniejącym serwerze lub podczas tworzenia serwera, Azure SQL sprawdza, czy magazyn kluczy, którego używasz, ma włączoną ochronę przed nietrwałym usunięciem i przeczyszczeniem. 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 takim przypadku włącz usuwanie nietrwałe i ochronę przed przeczyszczeniem w usłudze magazyn kluczy, a następnie skonfiguruj protektor 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.

Kluczowe wymagania dotyczące konfigurowania funkcji ochrony TDE

Transparent Data Encryption z kluczami zarządzanymi przez klienta wykorzystuje zewnętrzny klucz, nazywany protektorem TDE, przechowywany w Azure Key Vault do ochrony klucza szyfrowania bazy danych (DEK).

Obowiązują następujące wymagania.

Obsługiwane typy kluczy i rozmiary

Protektor TDE może być wspierany asymetrycznymi kluczami przechowywanymi w Azure Key Vault. Obsługiwane rozmiary kluczy to 2 048 bitów i 3 072 bitów.

Wymagania dotyczące stanu klucza i jego ważności

  • Jeśli podasz datę aktywacji klucza, ustaw ją na datę i godzinę w przeszłości.
  • Jeśli podasz datę wygaśnięcia klucza, ustaw ją na datę i godzinę w przyszłości.
  • Klucz musi być w stanie Włączone .

Kluczowe wymagania dotyczące importu

Jeśli importujesz istniejący klucz do Azure Key Vault, podaj go w jednym z następujących obsługiwanych formatów:

  • .pfx
  • .byok
  • .backup

Rekomendacje dotyczące konfiguracji TDE zarządzanego przez klienta w Azure Key Vault

Aby zachować wysoką dostępność i uniknąć problemów z ograniczaniem przepustowości, postępuj zgodnie z następującymi wytycznymi dotyczącymi subskrypcji:

  • Aby zapewnić optymalną wydajność i niezawodność, używaj dedykowanego Azure Key Vault dla Azure SQL. Nie dziel się tym sejfem kluczy z innymi usługami. Jeśli skarbiec kluczy jest pod dużym obciążeniem z powodu współdzielonego użycia lub nadmiernych operacji z kluczem, może to negatywnie wpłynąć na wydajność bazy danych, zwłaszcza podczas dostępu do klucza szyfrowanego. Usługa Azure Key Vault wymusza limity ograniczania przepustowości. Po przekroczeniu tych limitów operacje mogą być opóźnione lub nie powiodły się. To ryzyko jest największe podczas awaryjnego przełączania serwera, które uruchamia kluczowe operacje dla każdej bazy danych na serwerze.

    Więcej informacji o zachowaniu ograniczania przepustowości można znaleźć w wskazówkach dotyczących ograniczania przepustowości w usłudze Azure Key Vault.

    • Liczba baz danych Hyperscale, które możesz powiązać z jednym Azure Key Vault, zależy od liczby serwerów stron. Każdy serwer stron jest połączony z plikiem danych logicznych. Aby znaleźć liczbę serwerów stron, uruchom następujące zapytanie.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Nie kojarz serwerów więcej niż 500 stron z jednym Azure Key Vault. W miarę zwiększania się bazy danych liczba serwerów stron zwiększa się automatycznie, dlatego ważne jest regularne monitorowanie rozmiaru bazy danych. Jeśli liczba serwerów stron przekracza 500, używaj dedykowanego Azure Key Vault dla każdej bazy danych Hyperscale i nie udostępniaj tego sejfu z innymi zasobami Azure SQL.

    • Monitorowanie i konfigurowanie alertów usługi Azure Key Vault. Więcej informacji o monitorowaniu i alertach można znaleźć w artykułach Monitorowanie usługi Azure Key Vault oraz Konfigurowanie alertów dla usługi Azure Key Vault.

  • Ustaw blokadę zasobu dla magazynu kluczy, aby kontrolować, kto ma możliwość usunąć ten krytyczny zasób i zapobiec przypadkowemu lub nieautoryzowanemu usunięciu. Aby dowiedzieć 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.

Zalecenia dotyczące konfigurowania funkcji ochrony TDE

  • Zachowaj kopię zabezpieczenia TDE w bezpiecznym miejscu lub zdeponuj je w usłudze escrow.

  • Jeśli wygenerujesz klucz w magazynie kluczy, utwórz kopię zapasową klucza przed pierwszym użyciem klucza w usłudze Azure Key Vault. Możesz przywrócić kopię zapasową tylko do Azure Key Vault. Aby dowiedzieć się więcej, zobacz polecenie Backup-AzKeyVaultKey . Azure Managed HSM obsługuje tworzenie pełnej kopii zapasowej całej zawartości 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 wprowadzasz jakiekolwiek zmiany w kluczu (na przykład atrybuty klucza, tagi, listy ACL).

  • Zachowaj wcześniejsze wersje klucza w sejfie kluczy lub w Managed HSM podczas rotacji kluczy, aby móc przywrócić starsze kopie zapasowe bazy danych. Gdy zmieni się protektor TDE dla bazy danych, stare kopie zapasowe bazy danych nie są aktualizowane, tak aby używały najnowszego protektora TDE. W czasie przywracania każda kopia zapasowa wymaga funkcji ochrony TDE, za pomocą której została zaszyfrowana w czasie tworzenia. Aby przeprowadzić rotację kluczy, postępuj zgodnie z instrukcjami zawartymi w artykule Obracanie protektora funkcji Transparent Data Encryption (TDE).

  • Zachowaj wszystkie wcześniej używane klucze w Azure Key Vault nawet po przejściu na klucze zarządzane usługami. Zapewnia możliwość przywrócenia kopii zapasowych bazy danych przy użyciu protektorów TDE przechowywanych w Azure Key Vault. Protektory TDE utworzone w usłudze Azure Key Vault muszą być utrzymywane do czasu utworzenia wszystkich pozostałych przechowywanych kopii zapasowych przy użyciu kluczy zarządzanych przez usługę. Utwórz kopie zapasowe możliwe do odzyskania tych kluczy, używając Backup-AzKeyVaultKey.

  • Aby usunąć potencjalnie naruszony klucz podczas zdarzenia zabezpieczeń bez ryzyka utraty danych, wykonaj kroki opisane w artykule Usuwanie ochrony funkcji Transparent Data Encryption (TDE) przy użyciu programu PowerShell. Przed usunięciem lub wyłączeniem naruszonego klucza należy zawsze obracać do nowej funkcji ochrony TDE i sprawdzić, czy wszystkie bazy danych używają nowego klucza. Usunięcie lub wyłączenie klucza bez wcześniejszego obrotu powoduje, że wszystkie zaszyfrowane bazy danych stają się niedostępne i nie unieważnia żadnych kopii kluczy, które wcześniej były kopiowane i przywracane do innego skarbca.

Rotacja ochrony TDE

Gdy dokonujesz rotacji protektora TDE, wymieniasz klucz chroniący klucz szyfrujący bazy danych (DEK). Rotacja kluczy to operacja online i trwa tylko kilka sekund. Operacja ta odszyfrowuje i ponownie szyfruje tylko klucz szyfrujący bazy danych, a nie całą bazę danych.

Możesz przeprowadzić rotację protektora TDE, zmieniając konfigurację tak, aby używała nowego klucza przechowywanego w Azure Key Vault. W zależności od oferty i obsługiwanej konfiguracji, klucz ten może być:

  • Przełączanie na nową wersję tego samego klucza
  • Przełączanie na inny klucz

Obrót ochronnika TDE można wykonać ręcznie lub za pomocą funkcji automatycznego obrotu.

Możesz włączyć automatyczną rotację protektora TDE podczas konfiguracji protektora TDE dla serwera. Automatyczna rotacja jest domyślnie wyłączona. Po włączeniu serwer nieustannie sprawdza usługę Key Vault pod kątem nowych wersji klucza używanego jako protektor TDE. Jeśli serwer wykryje nową wersję klucza, automatycznie przeprowadza rotację protektora TDE na serwerze lub w bazie danych do najnowszej wersji klucza w ciągu 24 godzin.

Note

Kiedy ustawiasz TDE za pomocą CMK, używając ręcznej lub automatycznej rotacji kluczy, zawsze używasz najnowszej wersji klucza, którą system obsługuje. 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.

Niedostępna funkcja ochrony TDE

Gdy konfigurujesz TDE do używania klucza zarządzanego przez klienta, baza danych potrzebuje ciągłego dostępu do protektora TDE, aby pozostać online. Jeśli serwer straci dostęp do protektora TDE zarządzanego przez klienta w Azure Key Vault, baza danych zaczyna odrzucać wszystkie połączenia w ciągu 10 minut, wyświetla komunikat o błędzie i zmienia 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 automatycznie wracają do trybu online. Aby zmniejszyć wpływ błędów sieciowych lub awarii podczas uzyskiwania dostępu do protektora TDE w Azure Key Vault, usługa wprowadza 24-godzinny bufor przed próbą przeniesienia bazy danych do stanu niedostępnego. 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 protektora TDE zarządzanego przez klienta w usłudze Azure Key Vault z powodu jakiegokolwiek błędu Azure Key Vault (na przykład błędu 4XX), baza danych przechodzi do stanu niedostępności po 30 minutach.

Przywróć dostęp do bazy danych po błędzie Azure Key Vault

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 automatycznie zregeneruje się 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 wróci do stanu online, wcześniej skonfigurowane ustawienia na poziomie serwera, w tym konfiguracje grupy przełączeniowej, tagi i ustawienia na poziomie bazy danych, takie jak konfiguracje elastycznej puli, skalowanie odczytu, automatyczne wstrzymywanie, historia przywracania do punktu w czasie, zasada przechowywania długoterminowego i inne, zostają 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 widok dodatkowych kroków wymaganych 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ś, 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 SQL Managed Instance a Azure Key Vault

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 HSM, ale połączenie zostało odrzucone, brakuje uprawnień itp., powoduje, że bazy danych zmienią stan na Niedostępny.

Najczęstsze przyczyny braku łączności sieciowej z Azure Key Vault to:

  • Azure Key Vault jest udostępniany przez prywatny punkt końcowy, a prywatny adres IP usługi Azure Key Vault nie jest dozwolony w wychodzących regułach Network Security Group (NSG) powiązanych z zarządzaną podsiecią instancji.

  • 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 z usługą Azure Key Vault hostującą protektor 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 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.

Monitoruj TDE zarządzane 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 protektora TDE, jest wyświetlana jako "Niedostępna" po odrzuceniu pierwszej próby 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. Tworząc alerty dotyczące tych wydarzeń, możesz jak najszybciej przywrócić dostęp.

  • Grupy akcji mogą być zdefiniowane, aby wysyłać powiadomienia i alerty na podstawie Twoich preferencji, na przykład e-mail, SMS, Push, Voice, Logic App, Webhook, ITSM lub Automation Runbook.

Kopia zapasowa i przywracanie bazy danych z TDE zarządzanym przez klienta

Po zaszyfrowaniu bazy danych za pomocą TDE przy użyciu klucza z Azure Key Vault, wszelkie nowo wygenerowane kopie zapasowe również są szyfrowane tym samym protektorem TDE. Po zmianie funkcji ochrony TDE stare kopie zapasowe bazy danych nie są aktualizowane w celu korzystania z najnowszej funkcji ochrony TDE.

Aby przywrócić kopię zapasową zaszyfrowaną za pomocą protektora TDE z usługi Azure Key Vault, upewnij się, że materiał klucza jest dostępny na serwerze docelowym. Dlatego wszystkie stare wersje protektora TDE trzymaj w Key Vault lub zarządzanym HSM, aby kopie zapasowe mogły być przywrócone.

Important

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żą do ochrony DEK, ale mogą być używane podczas przywracania z kopii zapasowej, jeśli plik kopii zapasowej jest zaszyfrowany kluczem z odpowiadającym 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 dedykowanych pul SQL w usłudze Azure Synapse Analytics, zobacz Odzyskiwanie dedykowanej puli SQL.

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 logu korzysta z ochrony TDE przechowywanej w Azure Key Vault, ten klucz jest potrzebny podczas przywracania, nawet jeśli baza danych została zmieniona na usługowo zarządzane TDE w międzyczasie.

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

Dzięki wykorzystaniu wielowarstwowej redundancji Azure Key Vault, TDE korzystające z klucza zarządzanego przez klienta mogą korzystać z dostępności i odporności Azure Key Vault. Mogą w pełni polegać na rozwiązaniu redundancji Azure Key Vault.

Wiele warstw redundancji Azure Key Vault zapewnia dostęp do kluczy nawet w przypadku awarii poszczególnych komponentów usług lub awarii regionów czy stref dostępności Azure. Aby uzyskać więcej informacji, zapoznaj się z dostępnością i nadmiarowością usługi Azure Key Vault.

Azure Key Vault oferuje następujące elementy dostępności i odporności automatycznie bez ingerencji użytkownika:

Treści powiązane

  • Ostatnia aktualizacja o