Udostępnij za pośrednictwem

Szyfrowanie danych

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Wszystkie dane zarządzane przez wystąpienie usługi Azure Database for PostgreSQL — elastyczne 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 uzyskać szyfrowanie danych, usługa Azure Database for PostgreSQL — serwer elastyczny używa szyfrowania usługi Azure Storage dla danych magazynowanych, udostępniają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.

Azure Database for PostgreSQL — serwer elastyczny 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.

Za pomocą klucza szyfrowania zarządzanego przez usługę Azure Database for PostgreSQL — serwer elastyczny zajmuje się aprowizowaniem usługi Azure Key Vault, w której są przechowywane klucze, i przejmuje całą odpowiedzialność za dostarczanie 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 serwera elastycznego usługi Azure Database for PostgreSQL w taki sposób, aby odwołuje się do obróconej wersji klucza.

Podczas konfigurowania kluczy zarządzanych przez klienta dla konta magazynu usługa Azure Storage opakowuje klucz szyfrowania danych głównych (DEK) dla konta przy użyciu klucza zarządzanego przez klienta w skojarzonym magazynie kluczy lub zarządzanym module 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 kluczy zarządzanych przez klienta jest obowiązuje natychmiast.

Usługa Azure Key Vault to oparty na chmurze, zewnętrzny system zarządzania kluczami. Jest on wysoce dostępny i zapewnia skalowalny, bezpieczny magazyn dla kluczy kryptograficznych RSA, opcjonalnie wspierany przez zweryfikowane sprzętowe moduły zabezpieczeń (HSM) ze zweryfikowaną 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 przy użyciu kluczy zarządzanych przez usługę dla usługi Azure Database for PostgreSQL — serwer elastyczny 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 jest 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 organizować je we własnych wystąpieniach 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żawami usługi Key Vault i serwera nie są obsługiwane. Przeniesienie zasobu usługi Key Vault wymaga ponownego skonfigurowania szyfrowania danych.
  • Zalecamy ustawienie dni przechowywania konfiguracji usuniętych magazynów dla usługi Key Vault na 90 dni. Jeśli skonfigurowano istniejące wystąpienie usługi Key Vault z mniejszą liczbą, nadal powinno 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 tożsamości zarządzanej serwera w usłudze 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 klucza zarządzanego przez klienta, jest wyświetlana jako Niedostępna po odmowie pierwszego połączenia z bazą danych.
  • Dziennik aktywności: gdy dostęp do klucza zarządzanego przez klienta w wystąpieniu usługi Key Vault zarządzanym 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?.

Stan klucza zarządzanego 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ł skonfigurowaną datę i godzinę wygaśnięcia oraz datę i godzinę. 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 zapomnisz zaktualizować wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL, aby wskazywać 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 klucz, pamiętaj o zaktualizowaniu wystąpienia serwera, aby wskazać nową wersję. W tym celu możesz użyć elementu , korzystając z poniższego przykładuaz postgres flexible-server update, w którym opisano "Zmiana klucza/tożsamości na potrzeby szyfrowania danych. Nie można włączyć szyfrowania danych po utworzeniu serwera. Spowoduje to tylko zaktualizowanie klucza/tożsamości. Jeśli wolisz zaktualizować go przy użyciu interfejsu API, możesz wywołać serwerów — aktualizowanie punktu końcowego usługi.
Usunięcie wystąpienia usługi Key Vault, wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL nie może uzyskać dostępu do klucza i przejście do stanu Niedostępny. Odzyskaj wystąpienie usługi Key Vault i poczekaj na okresowe ponowne uruchomienie klucza przez usługę i automatycznie przełącz stan serwera na Gotowe.
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. Usunięcie przypisania roli RBAC użytkownika RBAC usługi kryptograficznej usługi Key Vault jest usuwane z tożsamości zarządzanych skonfigurowanych 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 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. Możesz odwołać listę, pobrać, opakowować lub odpakować zasady dostępuKey z zarządzanego przypisania roli RBAC użytkownika RBAC usługi kryptograficznej usługi Key Vault z tożsamości zarządzanych skonfigurowanych 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 po usunięciu tożsamości zarządzanej

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. Odzyskaj tożsamość lub utwórz nową tożsamość zarządzanego identyfikatora entra.
  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 nowej tożsamości entra o tej samej nazwie co usunięta tożsamość nie jest odzyskiwane po usunięciu tożsamości zarządzanej.

Używanie szyfrowania danych z kluczami zarządzanymi przez klienta i funkcjami ciągłości działania geograficznie nadmiarowego

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 nadmiarowej geograficznie musi zostać utworzony w wystąpieniu usługi Key Vault, który musi istnieć w regionie, w którym jest przechowywana geograficznie nadmiarowa kopia zapasowa.
  • 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 podczas tworzenia skonfigurowana jest baza danych repliki do odczytu do szyfrowania za pomocą kluczy cmK, jego klucz szyfrowania musi znajdować się w wystąpieniu usługi Key Vault w 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 przywrócić serwer do nowego z szyfrowaniem danych skonfigurowanym przy użyciu klucza zarządzanego przez system.
  • Wystąpienie zarządzanego modułu HSM usługi Azure Key Vault lub wystąpienie usługi Azure Key Vault, na którym planujesz przechowywanie klucza szyfrowania, musi istnieć w tym samym regionie, w którym tworzone jest wystąpienie usługi Azure Database for flexible Server.

Powiązana zawartość