Odporność między regionami dla funkcji TDE SQL przy użyciu zarządzanego modułu HSM usługi Azure Key Vault

Wystąpienie zarządzane Azure SQL

Azure Key Vault

Pomysły dotyczące rozwiązań

W tym artykule opisano pomysł rozwiązania. Architekt chmury może użyć tych wskazówek, aby ułatwić wizualizowanie głównych składników dla typowej implementacji tej architektury. Skorzystaj z tego artykułu jako punktu wyjścia, aby zaprojektować dobrze zaprojektowane rozwiązanie zgodne z konkretnymi wymaganiami obciążenia.

W tym rozwiązaniu opisano bezpieczny i odporny wzorzec wdrażania dla usługi Azure SQL Managed Instance. Przedstawia ona sposób użycia zarządzanego modułu HSM usługi Azure Key Vault do przechowywania kluczy ochrony transparent data encryption (TDE) zarządzanych przez klienta.

Architektura

Diagram zawiera trzy sekcje: region podstawowy, region pomocniczy i sekcję zasobów globalnych. Każdy z regionów zawiera dwie podsieci, a regiony są identyczne. Każda podsieć w każdym regionie jest ujęta w sieć wirtualną. W górnej części każdej podsieci znajduje się ikona grup zasobów. Każda podsieć ma sieciową grupę zabezpieczeń. Jedna podsieć w każdym regionie zawiera SQL Managed Instance wdrożone w różnych strefach dostępności i Azure Policy na granicy podsieci. Druga podsieć w każdym regionie zawiera prywatny punkt końcowy zarządzanego modułu HSM, drugi prywatny punkt końcowy i moduł równoważenia obciążenia oraz zarządzaną pulę HSM poza podsiecią. Po lewej stronie każdego regionu znajduje się ikona prywatnej strefy DNS dla zarządzanego modułu HSM. Sekcja zasobów globalnych zawiera usługę Traffic Manager. Obszar roboczy Log Analytics znajduje się między dwoma regionami. Strzałki wskazują ten obszar roboczy z puli zarządzanych modułów HSM w każdym regionie. Pięć kroków numerowanych identyfikuje przepływ pracy. W kroku 1 strzałka reprezentująca replikację danych między regionami łączy SQL Managed Instance w regionie podstawowym z SQL Managed Instance w regionie pomocniczym. W kroku 2 strzałka reprezentująca replikację między regionami łączy zarządzaną pulę modułów HSM w regionie podstawowym z pulą zarządzanych modułów HSM w regionie pomocniczym. Krok 3 ma etykietę płaszczyzny danych. W tym kroku w każdym regionie strzałka pokazuje ruch przepływujący z SQL Managed Instance przez prywatny punkt końcowy zarządzanego modułu HSM do usługi Traffic Manager. W kroku 4 usługa Traffic Manager przekierowuje do najbliższego zarządzanego modułu HSM: strzałka z punktu usługi Traffic Manager wskazuje pulę zarządzanych modułów HSM w każdym regionie. Krok 5 ma etykietę Płaszczyzna zarządzania. W tym kroku w każdym regionie strzałka pokazuje SQL Managed Instance wysyłania żądań płaszczyzny zarządzania bezpośrednio do usługi Traffic Manager.

Pobierz plik programu Visio tej architektury.

Workflow

Poniższy przepływ pracy odpowiada poprzedniemu diagramowi:

1. Grupa trybu failover w podstawowym wystąpieniu zarządzanym SQL replikuje wszystkie bazy danych użytkowników do pomocniczego wystąpienia zarządzanego SQL w innym regionie na potrzeby odzyskiwania po awarii.

2. Zarządzany moduł HSM jest skonfigurowany z pulą międzyregionalną. Ta pula automatycznie replikuje materiał klucza i uprawnienia do magazynu w regionie pomocniczym.

3. Ruch płaszczyzny danych z usługi SQL Managed Instance przepływa przez prywatny punkt końcowy zarządzanego modułu HSM.

4. Zarządzany moduł HSM używa wystąpienia Azure Traffic Manager zarządzanego Microsoft do kierowania ruchu do najbliższego magazynu operacyjnego.

5. Jeśli zarządzane wystąpienie musi sprawdzić uprawnienia do klucza, wysyła żądanie warstwy zarządzania za pośrednictwem sieci szkieletowej Azure.

Komponenty

• SQL Managed Instance to oferta platformy jako usługi (PaaS), która jest prawie całkowicie zgodna z najnowszym aparatem bazy danych SQL Server Enterprise Edition. Zapewnia natywną implementację sieci wirtualnej, która poprawia bezpieczeństwo i zapewnia korzystny model biznesowy dla istniejących klientów programu SQL Server. Usługa SQL Managed Instance umożliwia migrowanie aplikacji lokalnych do chmury przy minimalnych modyfikacjach aplikacji i baz danych.

  SQL Managed Instance oferuje również kompleksowe funkcje paaS, w tym automatyczne stosowanie poprawek i aktualizacje wersji, automatyczne kopie zapasowe i możliwości ciągłości działania. Te funkcje znacznie zmniejszają nakłady pracy związane z zarządzaniem i całkowity koszt posiadania. W tej architekturze usługa SQL Managed Instance jest bazą danych używającą kluczy ochrony TDE.

• Zarządzany HSM to w pełni zarządzana usługa w chmurze, która zapewnia wysoką dostępność, jednodzierżawność i zgodność ze standardami branżowymi. Zarządzany moduł HSM jest przeznaczony do ochrony kluczy kryptograficznych dla aplikacji w chmurze. Używa on federalnych standardów przetwarzania informacji 140-3 poziom 3 zweryfikowanych modułów HSM. Zarządzany moduł HSM to jedno z kilku rozwiązań do zarządzania kluczami w Azure. W tej architekturze zarządzany moduł HSM bezpiecznie przechowuje klucze ochrony TDE i zapewnia odporność między regionami.

• Prywatny punkt końcowy Azure udostępnia prywatną ścieżkę IP z sieci wirtualnej do usług, takich jak Azure Storage, Azure SQL Database i Key Vault. W przypadku tej architektury wyłącz dostęp do sieci publicznej w zarządzanym module HSM i używaj prywatnych punktów końcowych w obu regionach, aby ruch płaszczyzny danych pozostał w sieci szkieletowej Microsoft.

• Azure Prywatna strefa DNS zapewnia rozpoznawanie nazw dla prywatnych punktów końcowych, co umożliwia zasobom w sieci wirtualnej dostęp do usług Azure prywatnie. Po utworzeniu prywatnego punktu końcowego odpowiedni rekord systemu nazw domen (DNS) jest automatycznie rejestrowany w połączonej prywatnej strefie DNS. Prywatna strefa DNS zapewnia, że ruch do usługi pozostaje w sieci szkieletowej platformy Azure. Takie podejście zwiększa bezpieczeństwo, wydajność i zgodność, unikając narażenia na publiczny Internet. Jeśli wystąpi awaria usługi regionalnej, usługa Azure Prywatna strefa DNS zapewnia natywną odporność rozpoznawania nazw między regionami dla zarządzanego modułu HSM. W tej architekturze usługi używają prywatnej usługi DNS platformy Azure do komunikowania się ze sobą za pośrednictwem ich prywatnych adresów sieciowych.

• Azure Policy ocenia zasoby i akcje w Azure, porównując właściwości tych zasobów z regułami biznesowymi. Te reguły biznesowe, opisane w formacie JSON, są nazywane definicjami zasad. W tym rozwiązaniu użyj Azure Policy, aby wymusić szyfrowanie TDE zarządzane przez klienta podczas tworzenia lub aktualizowania bazy danych Azure SQL lub wystąpienia zarządzanego Azure SQL zgodnie z udokumentowanymi wskazówkami.

• Log Analytics obszar roboczy to magazyn danych, w którym można zbierać dane dziennika dowolnego typu ze wszystkich Azure i nie Azure zasobów i aplikacji. Opcje konfiguracji obszaru roboczego umożliwiają zarządzanie wszystkimi danymi dziennika w jednym obszarze roboczym w celu spełnienia wymagań dotyczących operacji, analizy i inspekcji różnych osób w organizacji. W tym rozwiązaniu obszar roboczy Log Analytics otrzymuje kompleksowe rejestrowanie i dane telemetryczne z zarządzanego modułu HSM.

Szczegóły scenariusza

W tym rozwiązaniu zespół ds. obciążeń chce spełnić ścisłe progi celu poziomu usług (SLO) dla swojego systemu o krytycznym znaczeniu, zapewniając jednocześnie pełną funkcjonalność wymaganych usług. Aby osiągnąć ten cel, używają usługi SQL Managed Instance z kluczem ochrony TDE zarządzanym przez klienta. Klucz jest przechowywany w zarządzanej puli modułów HSM, która obsługuje używane regiony i spełnia wszystkie wymagania dotyczące zgodności i zabezpieczeń. Dostęp do prywatnego punktu końcowego jest również wymuszany, aby ograniczyć narażenie na działanie sieci.

W przypadku odzyskiwania po awarii między regionami preferowana jest grupa trybu failover z zasadami trybu failover zarządzanymi przez klienta, dzięki czemu klient może kontrolować czas pracy w trybie failover. Grupa trybu failover replikuje bazy danych użytkowników jako jednostkę, dlatego powiązane obiekty i ustawienia na poziomie wystąpienia muszą być synchronizowane oddzielnie.

Potencjalne przypadki użycia

• Organizacja używa dwóch sparowanych lub niepairowanych regionów. Podstawowe wystąpienie zarządzane SQL znajduje się w jednym regionie, a grupy trybu failover są skonfigurowane do łączenia go z wystąpieniem zarządzanym SQL w regionie pomocniczym.

  Ten projekt używa punktów końcowych odbiornika grupy trybu failover, dzięki czemu aplikacje mogą zachować stabilne parametry połączenia podczas pracy w trybie failover. Grupy trybu failover aktualizują rekord DNS odbiornika automatycznie po przejściu w tryb failover geograficznego. Jednak zaobserwowany czas ponownego nawiązywania połączenia od klienta zależy od czasu wygaśnięcia pamięci podręcznej DNS klienta i logiki ponawiania prób aplikacji.

• Organizacja używa wystąpienia zarządzanego modułu HSM w regionie podstawowym z repliką między regionami w regionie pomocniczym. Po włączeniu repliki między regionami tworzone jest wystąpienie usługi Traffic Manager. Wystąpienie usługi Traffic Manager obsługuje routing ruchu do magazynu lokalnego, jeśli oba magazyny działają lub do magazynu operacyjnego, jeśli jeden magazyn jest niedostępny.

  Replikacja materiału klucza i uprawnień jest asynchroniczna i może potrwać kilka minut. Wstępne rozszerzenie do regionu pomocniczego wymaga dodatkowego czasu aprowizacji. Przed sfinalizowaniem projektu odporności zweryfikuj dostępność i pojemność zarządzanego modułu HSM w żądanych regionach.

• Organizacja używa dwóch niestandardowych stref DNS do obsługi prywatnego punktu końcowego dla wystąpienia zarządzanego modułu HSM w każdym regionie.

  We wdrożeniach z wieloma regionami prywatny punkt końcowy i prywatna integracja DNS w każdym regionie pomagają zachować ruch na płaszczyźnie nazw i płaszczyzny danych w każdym regionie.

• Organizacja włącza funkcję TDE w bazach danych użytkowników przy użyciu klucza zarządzanego przez klienta i przechowuje klucz ochrony w zarządzanym module HSM.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• Laura Grob | Główny menedżer programu
• Armen Kaleshian | Główny architekt rozwiązań w chmurze
• Michael Piskorski | Starszy architekt rozwiązań w chmurze

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Dalsze kroki

• Kontrolowanie danych w chmurze przy użyciu zarządzanego modułu HSM
• Włączanie replikacji wieloregionowej w zarządzanym module HSM
• Konfigurowanie zarządzanego modułu HSM z prywatnymi punktami końcowymi
• Przegląd odzyskiwania zarządzanego HSM
• Niezależność klucza, dostępność, wydajność i skalowalność w zarządzanym module HSM
• Najlepsze rozwiązania dotyczące zabezpieczania zarządzanego modułu HSM
• Przegląd zabezpieczeń Key Vault
• Generowanie i przesyłanie kluczy chronionych przez moduł HSM
• Dostępność i nadmiarowość usługi Key Vault
• Przezroczyste szyfrowanie danych w usłudze Azure SQL przy użyciu klucza zarządzanego przez klienta
• Omówienie i najlepsze rozwiązania dotyczące grup failover — Azure SQL Managed Instance

Pomysły dotyczące rozwiązań

W tym artykule opisano pomysł rozwiązania. Architekt chmury może użyć tych wskazówek, aby ułatwić wizualizowanie głównych składników dla typowej implementacji tej architektury. Skorzystaj z tego artykułu jako punktu wyjścia, aby zaprojektować dobrze zaprojektowane rozwiązanie zgodne z konkretnymi wymaganiami obciążenia.

W tym rozwiązaniu opisano bezpieczny i odporny wzorzec wdrażania dla usługi Azure SQL Managed Instance. Przedstawia ona sposób użycia zarządzanego modułu HSM usługi Azure Key Vault do przechowywania kluczy ochrony transparent data encryption (TDE) zarządzanych przez klienta.

Architektura

Diagram zawiera trzy sekcje: region podstawowy, region pomocniczy i sekcję zasobów globalnych. Każdy z regionów zawiera dwie podsieci, a regiony są identyczne. Każda podsieć w każdym regionie jest ujęta w sieć wirtualną. W górnej części każdej podsieci znajduje się ikona grup zasobów. Każda podsieć ma sieciową grupę zabezpieczeń. Jedna podsieć w każdym regionie zawiera SQL Managed Instance wdrożone w różnych strefach dostępności i Azure Policy na granicy podsieci. Druga podsieć w każdym regionie zawiera prywatny punkt końcowy zarządzanego modułu HSM, drugi prywatny punkt końcowy i moduł równoważenia obciążenia oraz zarządzaną pulę HSM poza podsiecią. Po lewej stronie każdego regionu znajduje się ikona prywatnej strefy DNS dla zarządzanego modułu HSM. Sekcja zasobów globalnych zawiera usługę Traffic Manager. Obszar roboczy Log Analytics znajduje się między dwoma regionami. Strzałki wskazują ten obszar roboczy z puli zarządzanych modułów HSM w każdym regionie. Pięć kroków numerowanych identyfikuje przepływ pracy. W kroku 1 strzałka reprezentująca replikację danych między regionami łączy SQL Managed Instance w regionie podstawowym z SQL Managed Instance w regionie pomocniczym. W kroku 2 strzałka reprezentująca replikację między regionami łączy zarządzaną pulę modułów HSM w regionie podstawowym z pulą zarządzanych modułów HSM w regionie pomocniczym. Krok 3 ma etykietę płaszczyzny danych. W tym kroku w każdym regionie strzałka pokazuje ruch przepływujący z SQL Managed Instance przez prywatny punkt końcowy zarządzanego modułu HSM do usługi Traffic Manager. W kroku 4 usługa Traffic Manager przekierowuje do najbliższego zarządzanego modułu HSM: strzałka z punktu usługi Traffic Manager wskazuje pulę zarządzanych modułów HSM w każdym regionie. Krok 5 ma etykietę Płaszczyzna zarządzania. W tym kroku w każdym regionie strzałka pokazuje SQL Managed Instance wysyłania żądań płaszczyzny zarządzania bezpośrednio do usługi Traffic Manager.

Pobierz plik programu Visio tej architektury.

Workflow

Poniższy przepływ pracy odpowiada poprzedniemu diagramowi:

1. Grupa trybu failover w podstawowym wystąpieniu zarządzanym SQL replikuje wszystkie bazy danych użytkowników do pomocniczego wystąpienia zarządzanego SQL w innym regionie na potrzeby odzyskiwania po awarii.

2. Zarządzany moduł HSM jest skonfigurowany z pulą międzyregionalną. Ta pula automatycznie replikuje materiał klucza i uprawnienia do magazynu w regionie pomocniczym.

3. Ruch płaszczyzny danych z usługi SQL Managed Instance przepływa przez prywatny punkt końcowy zarządzanego modułu HSM.

4. Zarządzany moduł HSM używa wystąpienia Azure Traffic Manager zarządzanego Microsoft do kierowania ruchu do najbliższego magazynu operacyjnego.

5. Jeśli zarządzane wystąpienie musi sprawdzić uprawnienia do klucza, wysyła żądanie warstwy zarządzania za pośrednictwem sieci szkieletowej Azure.

Komponenty

• SQL Managed Instance to oferta platformy jako usługi (PaaS), która jest prawie całkowicie zgodna z najnowszym aparatem bazy danych SQL Server Enterprise Edition. Zapewnia natywną implementację sieci wirtualnej, która poprawia bezpieczeństwo i zapewnia korzystny model biznesowy dla istniejących klientów programu SQL Server. Usługa SQL Managed Instance umożliwia migrowanie aplikacji lokalnych do chmury przy minimalnych modyfikacjach aplikacji i baz danych.

  SQL Managed Instance oferuje również kompleksowe funkcje paaS, w tym automatyczne stosowanie poprawek i aktualizacje wersji, automatyczne kopie zapasowe i możliwości ciągłości działania. Te funkcje znacznie zmniejszają nakłady pracy związane z zarządzaniem i całkowity koszt posiadania. W tej architekturze usługa SQL Managed Instance jest bazą danych używającą kluczy ochrony TDE.

• Zarządzany HSM to w pełni zarządzana usługa w chmurze, która zapewnia wysoką dostępność, jednodzierżawność i zgodność ze standardami branżowymi. Zarządzany moduł HSM jest przeznaczony do ochrony kluczy kryptograficznych dla aplikacji w chmurze. Używa on federalnych standardów przetwarzania informacji 140-3 poziom 3 zweryfikowanych modułów HSM. Zarządzany moduł HSM to jedno z kilku rozwiązań do zarządzania kluczami w Azure. W tej architekturze zarządzany moduł HSM bezpiecznie przechowuje klucze ochrony TDE i zapewnia odporność między regionami.

• Prywatny punkt końcowy Azure udostępnia prywatną ścieżkę IP z sieci wirtualnej do usług, takich jak Azure Storage, Azure SQL Database i Key Vault. W przypadku tej architektury wyłącz dostęp do sieci publicznej w zarządzanym module HSM i używaj prywatnych punktów końcowych w obu regionach, aby ruch płaszczyzny danych pozostał w sieci szkieletowej Microsoft.

• Azure Prywatna strefa DNS zapewnia rozpoznawanie nazw dla prywatnych punktów końcowych, co umożliwia zasobom w sieci wirtualnej dostęp do usług Azure prywatnie. Po utworzeniu prywatnego punktu końcowego odpowiedni rekord systemu nazw domen (DNS) jest automatycznie rejestrowany w połączonej prywatnej strefie DNS. Prywatna strefa DNS zapewnia, że ruch do usługi pozostaje w sieci szkieletowej platformy Azure. Takie podejście zwiększa bezpieczeństwo, wydajność i zgodność, unikając narażenia na publiczny Internet. Jeśli wystąpi awaria usługi regionalnej, usługa Azure Prywatna strefa DNS zapewnia natywną odporność rozpoznawania nazw między regionami dla zarządzanego modułu HSM. W tej architekturze usługi używają prywatnej usługi DNS platformy Azure do komunikowania się ze sobą za pośrednictwem ich prywatnych adresów sieciowych.

• Azure Policy ocenia zasoby i akcje w Azure, porównując właściwości tych zasobów z regułami biznesowymi. Te reguły biznesowe, opisane w formacie JSON, są nazywane definicjami zasad. W tym rozwiązaniu użyj Azure Policy, aby wymusić szyfrowanie TDE zarządzane przez klienta podczas tworzenia lub aktualizowania bazy danych Azure SQL lub wystąpienia zarządzanego Azure SQL zgodnie z udokumentowanymi wskazówkami.

• Log Analytics obszar roboczy to magazyn danych, w którym można zbierać dane dziennika dowolnego typu ze wszystkich Azure i nie Azure zasobów i aplikacji. Opcje konfiguracji obszaru roboczego umożliwiają zarządzanie wszystkimi danymi dziennika w jednym obszarze roboczym w celu spełnienia wymagań dotyczących operacji, analizy i inspekcji różnych osób w organizacji. W tym rozwiązaniu obszar roboczy Log Analytics otrzymuje kompleksowe rejestrowanie i dane telemetryczne z zarządzanego modułu HSM.

Szczegóły scenariusza

W tym rozwiązaniu zespół ds. obciążeń chce spełnić ścisłe progi celu poziomu usług (SLO) dla swojego systemu o krytycznym znaczeniu, zapewniając jednocześnie pełną funkcjonalność wymaganych usług. Aby osiągnąć ten cel, używają usługi SQL Managed Instance z kluczem ochrony TDE zarządzanym przez klienta. Klucz jest przechowywany w zarządzanej puli modułów HSM, która obsługuje używane regiony i spełnia wszystkie wymagania dotyczące zgodności i zabezpieczeń. Dostęp do prywatnego punktu końcowego jest również wymuszany, aby ograniczyć narażenie na działanie sieci.

W przypadku odzyskiwania po awarii między regionami preferowana jest grupa trybu failover z zasadami trybu failover zarządzanymi przez klienta, dzięki czemu klient może kontrolować czas pracy w trybie failover. Grupa trybu failover replikuje bazy danych użytkowników jako jednostkę, dlatego powiązane obiekty i ustawienia na poziomie wystąpienia muszą być synchronizowane oddzielnie.

Potencjalne przypadki użycia

• Organizacja używa dwóch sparowanych lub niepairowanych regionów. Podstawowe wystąpienie zarządzane SQL znajduje się w jednym regionie, a grupy trybu failover są skonfigurowane do łączenia go z wystąpieniem zarządzanym SQL w regionie pomocniczym.

  Ten projekt używa punktów końcowych odbiornika grupy trybu failover, dzięki czemu aplikacje mogą zachować stabilne parametry połączenia podczas pracy w trybie failover. Grupy trybu failover aktualizują rekord DNS odbiornika automatycznie po przejściu w tryb failover geograficznego. Jednak zaobserwowany czas ponownego nawiązywania połączenia od klienta zależy od czasu wygaśnięcia pamięci podręcznej DNS klienta i logiki ponawiania prób aplikacji.

• Organizacja używa wystąpienia zarządzanego modułu HSM w regionie podstawowym z repliką między regionami w regionie pomocniczym. Po włączeniu repliki między regionami tworzone jest wystąpienie usługi Traffic Manager. Wystąpienie usługi Traffic Manager obsługuje routing ruchu do magazynu lokalnego, jeśli oba magazyny działają lub do magazynu operacyjnego, jeśli jeden magazyn jest niedostępny.

  Replikacja materiału klucza i uprawnień jest asynchroniczna i może potrwać kilka minut. Wstępne rozszerzenie do regionu pomocniczego wymaga dodatkowego czasu aprowizacji. Przed sfinalizowaniem projektu odporności zweryfikuj dostępność i pojemność zarządzanego modułu HSM w żądanych regionach.

• Organizacja używa dwóch niestandardowych stref DNS do obsługi prywatnego punktu końcowego dla wystąpienia zarządzanego modułu HSM w każdym regionie.

  We wdrożeniach z wieloma regionami prywatny punkt końcowy i prywatna integracja DNS w każdym regionie pomagają zachować ruch na płaszczyźnie nazw i płaszczyzny danych w każdym regionie.

• Organizacja włącza funkcję TDE w bazach danych użytkowników przy użyciu klucza zarządzanego przez klienta i przechowuje klucz ochrony w zarządzanym module HSM.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• Laura Grob | Główny menedżer programu
• Armen Kaleshian | Główny architekt rozwiązań w chmurze
• Michael Piskorski | Starszy architekt rozwiązań w chmurze

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Dalsze kroki

• Kontrolowanie danych w chmurze przy użyciu zarządzanego modułu HSM
• Włączanie replikacji wieloregionowej w zarządzanym module HSM
• Konfigurowanie zarządzanego modułu HSM z prywatnymi punktami końcowymi
• Przegląd odzyskiwania zarządzanego HSM
• Niezależność klucza, dostępność, wydajność i skalowalność w zarządzanym module HSM
• Najlepsze rozwiązania dotyczące zabezpieczania zarządzanego modułu HSM
• Przegląd zabezpieczeń Key Vault
• Generowanie i przesyłanie kluczy chronionych przez moduł HSM
• Dostępność i nadmiarowość usługi Key Vault
• Przezroczyste szyfrowanie danych w usłudze Azure SQL przy użyciu klucza zarządzanego przez klienta
• Omówienie i najlepsze rozwiązania dotyczące grup failover — Azure SQL Managed Instance