Przeczytaj w języku angielskim

Udostępnij za pośrednictwem

Szyfrowanie danych

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Wszystkie dane zarządzane przez elastyczne wystąpienie usługi Azure Database for PostgreSQL są zawsze szyfrowane w spoczynku. Te dane obejmują wszystkie bazy danych systemu i użytkowników, pliki tymczasowe, dzienniki serwera, segmenty dzienników z wyprzedzeniem zapisu i kopie zapasowe.

Aby osiągnąć szyfrowanie danych, elastyczny serwer Azure Database for PostgreSQL używa szyfrowania usługi Azure Storage dla danych w stanie spoczynku, zapewniając klucze do szyfrowania i odszyfrowywania danych w usługach Blob Storage i Azure Files. Te klucze muszą być przechowywane w usłudze Azure Key Vault lub zarządzanym module zabezpieczeń sprzętu usługi Azure Key Vault (HSM). Aby uzyskać więcej informacji, zobacz Klucze zarządzane przez klienta na potrzeby szyfrowania usługi Azure Storage.

Serwer elastyczny usługi Azure Database for PostgreSQL obsługuje konfigurowanie szyfrowania danych w dwóch różnych trybach: klucz zarządzany przez usługę i klucz zarządzany przez klienta. Tryb konfiguracji można wybrać tylko w czasie tworzenia serwera. Nie można go zmienić z jednego trybu na inny przez okres istnienia serwera.

Usługa Azure Database for PostgreSQL — elastyczny serwer z kluczem szyfrowania zarządzanego przez usługę zajmuje się aprowizowaniem usługi Azure Key Vault, w której są przechowywane klucze, i przyjmuje odpowiedzialność za dostarczenie klucza, za pomocą którego dane są szyfrowane i odszyfrowywane. Usługa zajmuje się również przechowywaniem, ochroną, inspekcją dostępu, konfigurowaniem sieci i automatycznym obracaniem klucza.

W przypadku klucza szyfrowania zarządzanego przez klienta przyjmujesz całą odpowiedzialność. W związku z tym należy wdrożyć własną usługę Azure Key Vault lub moduł HSM usługi Azure Key Vault. Musisz wygenerować lub zaimportować własny klucz. Musisz udzielić wymaganych uprawnień w usłudze Key Vault, aby serwer elastyczny usługi Azure Database for PostgreSQL mógł wykonywać niezbędne akcje na kluczu. Musisz zadbać o skonfigurowanie wszystkich aspektów sieci usługi Azure Key Vault, w których jest przechowywany klucz, aby serwer elastyczny usługi Azure Database for PostgreSQL mógł uzyskać dostęp do klucza. Inspekcja dostępu do klucza jest również twoim zadaniem. Na koniec odpowiadasz za rotację klucza i, w razie potrzeby, zaktualizowanie konfiguracji elastycznego serwera usługi Azure Database for PostgreSQL w taki sposób, aby odwoływała się do obróconej wersji klucza.

Podczas konfigurowania kluczy zarządzanych przez klienta dla konta magazynu, usługa Azure Storage owija klucz szyfrowania danych głównych (DEK) dla konta przy użyciu klucza zarządzanego przez klienta w skojarzonym magazynie kluczy lub zarządzanym sprzętowym module bezpieczeństwa (HSM). Ochrona klucza szyfrowania głównego zmienia się, ale dane na koncie usługi Azure Storage pozostają zawsze szyfrowane. Ze swojej strony nie jest wymagana dodatkowa akcja, aby upewnić się, że dane pozostają zaszyfrowane. Ochrona kluczami zarządzanymi przez klienta obowiązuje natychmiast.

Usługa Azure Key Vault to oparty na chmurze, zewnętrzny system zarządzania kluczami. Jest wysoce dostępny i zapewnia skalowalne, bezpieczne przechowywanie kluczy kryptograficznych RSA, opcjonalnie obsługiwane przez sprzętowe moduły zabezpieczeń (HSM) zgodne ze standardem FIPS 140. Nie zezwala na bezpośredni dostęp do przechowywanego klucza, ale zapewnia usługi szyfrowania i odszyfrowywania autoryzowanych jednostek. Usługa Key Vault może wygenerować klucz, zaimportować go lub odebrać go z lokalnego urządzenia HSM.

Korzyści zapewniane przez każdy tryb

Szyfrowanie danych za pomocą kluczy zarządzanych przez usługę Azure Database for PostgreSQL Flexible Server zapewnia następujące korzyści:

  • Usługa automatycznie i w pełni kontroluje dostęp do danych.
  • Usługa automatycznie i w pełni kontroluje cykl życia klucza, w tym rotację klucza.
  • Nie musisz martwić się o zarządzanie kluczami szyfrowania danych.
  • Szyfrowanie danych na podstawie kluczy zarządzanych przez usługę nie wpływa negatywnie na wydajność obciążeń.
  • Upraszcza zarządzanie kluczami szyfrowania (w tym ich regularną rotację) oraz zarządzanie tożsamościami używanymi do uzyskiwania dostępu do tych kluczy.

Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for PostgreSQL — serwer elastyczny zapewnia następujące korzyści:

  • W pełni kontrolujesz dostęp do danych. Klucz można usunąć, aby baza danych stała się niedostępna.
  • W pełni kontrolujesz cykl życia klucza, w tym rotację klucza, aby dopasować go do zasad firmy.
  • Możesz centralnie zarządzać wszystkimi kluczami szyfrowania i porządkować je we własnych instancjach usługi Azure Key Vault.
  • Szyfrowanie danych na podstawie kluczy zarządzanych przez klienta nie wpływa negatywnie na wydajność obciążeń.
  • Można zaimplementować rozdzielenie obowiązków między funkcjonariuszami zabezpieczeń, administratorami bazy danych i administratorami systemu.

Wymagania

Poniżej znajduje się lista wymagań dotyczących konfigurowania szyfrowania danych dla serwera elastycznego usługi Azure Database for PostgreSQL:

  • Usługa Key Vault i serwer elastyczny usługi Azure Database for PostgreSQL muszą należeć do tej samej dzierżawy firmy Microsoft Entra. Interakcje między dzierżawcami Key Vault i serwera nie są obsługiwane. Przeniesienie zasobu usługi Key Vault wymaga ponownego skonfigurowania szyfrowania danych.
  • Zalecamy ustawienie dni przechowywania usuniętych magazynów dla Key Vault na 90 dni. Jeśli skonfigurowano istniejące wystąpienie usługi Key Vault z mniejszą liczbą, powinno ono nadal być prawidłowe. Jeśli jednak chcesz zmodyfikować to ustawienie i zwiększyć wartość, należy utworzyć nowe wystąpienie usługi Key Vault. Po utworzeniu wystąpienia nie można zmodyfikować tego ustawienia.
  • Włącz funkcję usuwania nietrwałego w usłudze Key Vault, aby ułatwić ochronę przed utratą danych, jeśli klucz lub wystąpienie usługi Key Vault zostanie przypadkowo usunięte. Usługa Key Vault zachowuje zasoby usunięte nietrwale przez 90 dni, chyba że użytkownik odzyska je lub przeczyści je w międzyczasie. Akcje odzyskiwania i przeczyszczania mają własne uprawnienia skojarzone z rolą RBAC usługi Key Vault lub uprawnieniem zasad dostępu. Funkcja usuwania nietrwałego jest domyślnie włączona. Jeśli masz usługę Key Vault, która została wdrożona dawno temu, może ona nadal mieć wyłączone usuwanie nietrwałe. W takim przypadku można ją włączyć przy użyciu interfejsu wiersza polecenia platformy Azure.
  • Włącz ochronę przed przeczyszczeniem, aby wymusić obowiązkowy okres przechowywania usuniętych magazynów i obiektów magazynu.
  • Udziel tożsamości zarządzanej przypisanej przez użytkownika serwera elastycznego usługi Azure Database for PostgreSQL dostępu do klucza przez:
    • Preferowane: usługa Azure Key Vault powinna być skonfigurowana przy użyciu modelu uprawnień RBAC, a tożsamość zarządzana powinna mieć przypisaną rolę użytkownika szyfrowania usługi kryptograficznej usługi Key Vault.
    • Starsza wersja: Jeśli usługa Azure Key Vault jest skonfigurowana z modelem uprawnień zasad dostępu, przyznaj następujące uprawnienia tożsamości zarządzanej:
      • get: aby pobrać właściwości i publiczną część klucza w usłudze Key Vault.
      • lista: Aby wyświetlić listę i iterować klucze przechowywane w usłudze Key Vault.
      • wrapKey: aby zaszyfrować klucz szyfrowania danych.
      • unwrapKey: aby odszyfrować klucz szyfrowania danych.
  • Klucz używany do szyfrowania klucza szyfrowania danych może być tylko asymetryczny, RSA lub RSA-HSM. Obsługiwane są rozmiary kluczy 2048, 3072 i 4096. Zalecamy użycie klucza 4096-bitowego w celu zapewnienia lepszego bezpieczeństwa.
  • Data i godzina aktywacji klucza (jeśli ustawiono) muszą być w przeszłości. Data i godzina wygaśnięcia (jeśli ustawiono) muszą być w przyszłości.
  • Klucz musi być w stanie Włączone .
  • Jeśli importujesz istniejący klucz do usługi Key Vault, podaj go w obsługiwanych formatach plików (.pfx, .byok, lub .backup).

Zalecenia

Jeśli używasz klucza zarządzanego przez klienta do szyfrowania danych, postępuj zgodnie z poniższymi zaleceniami, aby skonfigurować usługę Key Vault:

  • Aby zapobiec przypadkowemu lub nieautoryzowanemu usunięciu tego krytycznego zasobu, ustaw blokadę zasobu w usłudze Key Vault.
  • Włącz inspekcję i raportowanie dla wszystkich kluczy szyfrowania. Usługa Key Vault udostępnia dzienniki, które można łatwo wprowadzać do innych narzędzi do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM). Dzienniki usługi Azure Monitor to jeden z przykładów usługi, która jest już zintegrowana.
  • Zablokuj usługę Key Vault, wybierając pozycję Wyłącz dostęp publiczny i Zezwalaj na zaufane usługi firmy Microsoft, aby pominąć tę zaporę.

Uwaga

Po wybraniu pozycji Wyłącz dostęp publiczny i Zezwalaj na zaufane usługi firmy Microsoft obejście tej zapory może wystąpić błąd podobny do poniższego podczas próby użycia publicznego dostępu do administrowania usługą Key Vault za pośrednictwem portalu: "Włączono kontrolę dostępu do sieci. Tylko dozwolone sieci mają dostęp do tego magazynu kluczy". Ten błąd nie wyklucza możliwości udostępniania kluczy podczas konfigurowania klucza zarządzanego przez klienta lub pobierania kluczy z usługi Key Vault podczas operacji serwera.

  • Zachowaj kopię klucza manged klienta w bezpiecznym miejscu lub deponuj go do usługi escrow.
  • Jeśli usługa Key Vault wygeneruje klucz, utwórz kopię zapasową klucza przed pierwszym użyciem klucza. Możesz przywrócić kopię zapasową tylko do usługi Key Vault.

Specjalne uwagi

Przypadkowe odwołanie dostępu do klucza z usługi Key Vault

Osoba mająca wystarczające prawa dostępu do usługi Key Vault może przypadkowo wyłączyć dostęp serwera do klucza przez:

  • Cofanie przypisania roli RBAC użytkownika szyfrowania usługi kryptograficznej usługi Kryptograficznej usługi Key Vault lub cofnięcie uprawnień z tożsamości użytej do pobrania klucza w usłudze Key Vault.
  • Usuwanie klucza.
  • Usuwanie wystąpienia usługi Key Vault.
  • Zmiana reguł zapory usługi Key Vault.
  • Usuwanie zarządzanej tożsamości serwera w Microsoft Entra ID.

Monitorowanie kluczy przechowywanych w usłudze Azure Key Vault

Aby monitorować stan bazy danych i włączyć alerty dotyczące utraty dostępu do funkcji ochrony szyfrowania danych, skonfiguruj następujące funkcje platformy Azure:

  • Kondycja zasobu: baza danych, która utraciła dostęp do CMK, widnieje jako Niedostępna po odmowie pierwszego połączenia z bazą danych.
  • Dziennik aktywności: Gdy dostęp do CMK w instancji Key Vault zarządzanej przez klienta kończy się niepowodzeniem, wpisy są dodawane do dziennika aktywności. Dostęp można przywrócić, jeśli utworzysz alerty dla tych zdarzeń tak szybko, jak to możliwe.
  • Grupy akcji: zdefiniuj te grupy, aby otrzymywać powiadomienia i alerty na podstawie preferencji.

Przywracanie kopii zapasowych serwera skonfigurowanego przy użyciu klucza zarządzanego przez klienta

Po zaszyfrowaniu elastycznego serwera usługi Azure Database for PostgreSQL za pomocą klucza zarządzanego przez klienta przechowywanego w usłudze Key Vault każda nowo utworzona kopia serwera jest również szyfrowana. Możesz utworzyć tę nową kopię za pomocą operacji przywracania do punktu w czasie (PITR) lub replik do odczytu.

Podczas konfigurowania szyfrowania danych za pomocą klucza zarządzanego przez klienta podczas operacji, takiej jak przywracanie kopii zapasowej lub tworzenie repliki do odczytu, można uniknąć problemów, wykonując następujące kroki na serwerach podstawowych i przywróconych lub replikowych:

  • Zainicjuj proces przywracania lub proces tworzenia repliki do odczytu z podstawowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL.
  • Na przywróconym serwerze lub replice można zmienić klucz zarządzany przez klienta i tożsamość zarządzaną przypisaną przez użytkownika, która jest używana do uzyskiwania dostępu do usługi Key Vault. Upewnij się, że tożsamość przypisana na nowo utworzonym serwerze ma wymagane uprawnienia w usłudze Key Vault.
  • Nie odwołuj oryginalnego klucza po przywróceniu. Obecnie nie obsługujemy odwoływania kluczy po przywróceniu serwera z kluczem zarządzanym przez klienta na innym serwerze.

Zarządzane moduły HSM

Sprzętowe moduły zabezpieczeń (HSM) to urządzenia sprzętowe odporne na naruszenia, które ułatwiają zabezpieczanie procesów kryptograficznych przez generowanie, ochronę i zarządzanie kluczami używanymi do szyfrowania danych, odszyfrowywania danych, tworzenia podpisów cyfrowych i tworzenia certyfikatów cyfrowych. Moduły HSM są testowane, weryfikowane i certyfikowane do najwyższych standardów zabezpieczeń, w tym FIPS 140 i Common Criteria.

Zarządzany moduł HSM usługi Azure Key Vault to w pełni zarządzana, wysoce dostępna, jednodostępna, zgodna ze standardami usługa w chmurze. Można go użyć do ochrony kluczy kryptograficznych dla aplikacji w chmurze za pośrednictwem zweryfikowanych modułów HSM ze standardem FIPS 140-3.

Podczas tworzenia nowych wystąpień serwera elastycznego usługi Azure Database for PostgreSQL w witrynie Azure Portal przy użyciu klucza zarządzanego przez klienta możesz wybrać usługę Azure Key Vault Managed HSM jako magazyn kluczy, jako alternatywę dla usługi Azure Key Vault. Wymagania wstępne, jeśli chodzi o tożsamość i uprawnienia zdefiniowane przez użytkownika, są takie same jak w usłudze Azure Key Vault (co opisano wcześniej w tym artykule). Aby uzyskać więcej informacji na temat tworzenia wystąpienia zarządzanego modułu HSM, jego zalet i różnic w stosunku do udostępnionego magazynu certyfikatów opartych na usłudze Key Vault oraz sposobu importowania kluczy do zarządzanego modułu HSM, zobacz Co to jest zarządzany moduł HSM usługi Azure Key Vault?.

Klucz zarządzany przez klienta jest niedostępny

Podczas konfigurowania szyfrowania danych przy użyciu klucza zarządzanego przez klienta przechowywanego w usłudze Key Vault wymagany jest ciągły dostęp do tego klucza, aby serwer pozostał w trybie online. Jeśli tak nie jest, serwer zmieni jego stan na Niedostępny i rozpocznie odmawianie wszystkich połączeń.

Niektóre z możliwych powodów, dla których stan serwera może stać się niedostępny , to:

Przyczyna Rozwiązanie
Każdy z kluczy szyfrowania wskazywanych przez serwer miał określoną datę i godzinę wygaśnięcia, która została już osiągnięta. Należy przedłużyć datę wygaśnięcia klucza. Następnie musisz poczekać, aż usługa zmieni klucz i automatycznie przeniesie stan serwera na Gotowe. Tylko wtedy, gdy serwer jest z powrotem w stanie Gotowe , można obrócić klucz do nowszej wersji lub utworzyć nowy klucz, a następnie zaktualizować serwer tak, aby odnosił się do tej nowej wersji tego samego klucza lub do nowego klucza.
Obracasz klucz i zapominasz zaktualizować wystąpienie elastycznego serwera Azure Database for PostgreSQL, tak aby wskazywało na nową wersję klucza. Stary klucz, do którego wskazuje serwer, wygasa i zamienia stan serwera na Niedostępny. Aby uniknąć tej sytuacji, za każdym razem, gdy obracasz lub zmieniasz klucz, pamiętaj o aktualizacji instancji serwera, aby wskazywała na nową wersję. Aby to zrobić, możesz użyć elementu az postgres flexible-server update, korzystając z przykładu, który opisuje "Zmianę klucza/tożsamości na potrzeby szyfrowania danych. Nie można włączyć szyfrowania danych po utworzeniu serwera. Spowoduje to jedynie zaktualizowanie klucza/tożsamości." Jeśli wolisz zaktualizować go przy użyciu interfejsu API, możesz wywołać endpoint Serwery – Aktualizacja usługi.
Usunięcie wystąpienia usługi Key Vault powoduje, że wystąpienie serwera elastycznego Azure Database for PostgreSQL nie może uzyskać dostępu do klucza i przechodzi do stanu Niedostępności. Odzyskaj wystąpienie Key Vault i poczekaj, aż usługa przeprowadzi okresową ponowną walidację klucza, automatycznie przełączając stan serwera na Gotowy.
Usuwasz tożsamość zarządzaną, która jest używana do pobierania dowolnego klucza szyfrowania przechowywanego w usłudze Key Vault, z identyfikatora Entra firmy Microsoft. Odzyskaj tożsamość i poczekaj na okresowe ponowne uruchomienie klucza przez usługę, a następnie automatycznie przełącz stan serwera na Gotowe.
Model uprawnień usługi Key Vault jest skonfigurowany do korzystania z kontroli dostępu opartej na rolach. Usuwasz przypisanie roli RBAC użytkownika Key Vault Crypto Service Encryption User z tożsamości zarządzanych, które są skonfigurowane do pobierania kluczy. Ponownie przyznaj rolę RBAC tożsamości zarządzanej i poczekaj, aż usługa przeprowadzi okresową ponowną walidację klucza, a stan serwera automatycznie przejdzie na Gotowe. Alternatywne podejście polega na przyznaniu roli w usłudze Key Vault innej tożsamości zarządzanej i zaktualizowaniu serwera w taki sposób, aby korzystała z tej innej tożsamości zarządzanej w celu uzyskania dostępu do klucza.
Model uprawnień usługi Key Vault jest skonfigurowany do używania zasad dostępu. Odwołujesz polityki dostępu listy, pobierania, zawijania lub odpakowania kluczy do tożsamości zarządzanych, które są skonfigurowane do pobierania dowolnego z kluczy. Ponownie przyznaj rolę RBAC tożsamości zarządzanej i zaczekaj na okresowe ponowne ponowne uruchomienie klucza przez usługę i automatycznie przełącz stan serwera na Gotowe. Alternatywne podejście polega na udzielaniu wymaganych zasad dostępu w usłudze Key Vault do innej tożsamości zarządzanej i aktualizowaniu serwera tak, aby korzystała z tej innej tożsamości zarządzanej w celu uzyskania dostępu do klucza.
Skonfigurowano zbyt restrykcyjne reguły zapory usługi Key Vault, aby serwer elastyczny usługi Azure Database for PostgreSQL nie mógł komunikować się z usługą Key Vault w celu pobrania kluczy. Podczas konfigurowania zapory usługi Key Vault upewnij się, że wybrano opcję zezwalania na zaufane usługi firmy Microsoft, aby serwer elastyczny usługi Azure Database for PostgreSQL mógł pominąć zaporę.

Uwaga

Gdy klucz jest wyłączony, usunięty, wygasł lub nieosiągalny, serwer, który ma dane zaszyfrowane za pomocą tego klucza, staje się niedostępny, jak określono wcześniej. Stan serwera nie zmienia się na Gotowe ponownie, dopóki nie będzie mógł ponownie zmienić kluczy szyfrowania.

Ogólnie rzecz biorąc, serwer staje się niedostępny w ciągu 60 minut po wyłączeniu, usunięciu, wygaśnięciu lub niedostępnym kluczu. Po udostępnieniu klucza serwer może potrwać do 60 minut, aby ponownie stać się Gotowy .

Odzyskiwanie tożsamości zarządzanej po jej usunięciu

Jeśli tożsamość zarządzana przypisana przez użytkownika używana do uzyskiwania dostępu do klucza szyfrowania przechowywanego w usłudze Key Vault zostanie usunięta w usłudze Microsoft Entra ID, wykonaj następujące kroki, aby odzyskać:

  1. Albo odzyskaj tożsamość, albo utwórz nową zarządzaną tożsamość Entra ID.
  2. Jeśli utworzono nową tożsamość, nawet jeśli ma dokładnie taką samą nazwę, jaką miała przed usunięciem, zaktualizuj usługę Azure Database for flexible server properties, aby wiedziała, że musi używać tej nowej tożsamości w celu uzyskania dostępu do klucza szyfrowania.
  3. Upewnij się, że ta tożsamość ma odpowiednie uprawnienia do operacji na kluczu w usłudze Azure Key Vault (AKV).
  4. Poczekaj około godziny, aż serwer ponownie zwaliduje klucz.

Ważne

Po prostu utworzenie nowego identyfikatora Entra ID o tej samej nazwie co usunięty identyfikator nie przywraca tożsamości po jej usunięciu.

Używanie szyfrowania danych z kluczami zarządzanymi przez klienta i funkcjami kontynuacji biznesowej z geograficzną nadmiarowością

Usługa Azure Database for PostgreSQL — elastyczny serwer obsługuje zaawansowane funkcje odzyskiwania danych, takie jak repliki i geograficznie nadmiarowe kopie zapasowe. Poniżej przedstawiono wymagania dotyczące konfigurowania szyfrowania danych przy użyciu zestawów CMKs i tych funkcji, oprócz podstawowych wymagań dotyczących szyfrowania danych przy użyciu zestawów CMKs:

  • Klucz szyfrowania kopii zapasowej z nadmiarowością geograficzną musi zostać utworzony w wystąpieniu usługi Key Vault, które musi istnieć w regionie, gdzie geograficznie nadmiarowa kopia zapasowa jest przechowywana.
  • Wersja interfejsu API REST usługi Azure Resource Manager do obsługi geograficznie nadmiarowych serwerów CMK z obsługą kopii zapasowych to 2022-11-01-preview. Jeśli chcesz użyć szablonów usługi Azure Resource Manager do zautomatyzowania tworzenia serwerów korzystających zarówno z szyfrowania za pomocą zestawów CMK, jak i funkcji geograficznie nadmiarowej kopii zapasowej, użyj tej wersji interfejsu API.
  • Nie można użyć tej samej tożsamości zarządzanej przez użytkownika do uwierzytelniania dla wystąpienia usługi Key Vault podstawowej bazy danych i wystąpienia usługi Key Vault, które przechowuje klucz szyfrowania na potrzeby geograficznie nadmiarowej kopii zapasowej. Aby zachować odporność regionalną, zalecamy utworzenie tożsamości zarządzanej przez użytkownika w tym samym regionie co geograficznie nadmiarowe kopie zapasowe.
  • Jeśli skonfigurujesz bazę danych repliki do odczytu, aby była szyfrowana za pomocą CMK podczas tworzenia, jej klucz szyfrowania musi znajdować się w instancji usługi Key Vault w tym samym regionie, w którym znajduje się baza danych repliki do odczytu. Tożsamość przypisana przez użytkownika do uwierzytelniania w tym wystąpieniu usługi Key Vault musi zostać utworzona w tym samym regionie.

Ograniczenia

Poniżej przedstawiono bieżące ograniczenia dotyczące konfigurowania klucza zarządzanego przez klienta na serwerze elastycznym usługi Azure Database for PostgreSQL:

  • Szyfrowanie kluczy zarządzanych przez klienta można skonfigurować tylko podczas tworzenia nowego serwera, a nie jako aktualizacji istniejącego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. Zamiast tego możesz przywrócić kopię zapasową PITR na nowy serwer z szyfrowaniem CMK.
  • Po skonfigurowaniu szyfrowania kluczy zarządzanych przez klienta nie można przywrócić klucza zarządzanego przez system. Jeśli chcesz przywrócić, musisz zastąpić serwer nowym i skonfigurować szyfrowanie danych z użyciem klucza zarządzanego przez system.
  • Instancja zarządzanego modułu HSM usługi Azure Key Vault albo instancja usługi Azure Key Vault, na której planujesz przechowywać klucz szyfrowania, musi znajdować się w tym samym regionie, co instancja usługi Azure Database dla elastycznych serwerów, która jest tworzona.

Powiązana zawartość