Udostępnij za pomocą

Szyfrowanie danych magazynowanych w usłudze Azure Database for PostgreSQL

Wszystkie dane zarządzane przez wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL są zawsze szyfrowane w spoczynku. Te dane obejmują wszystkie bazy danych systemu i użytkowników, dzienniki serwera, segmenty dzienników z wyprzedzeniem zapisu i kopie zapasowe. Szyfrowanie jest obsługiwane przez magazyn podstawowy za pomocą szyfrowania po stronie serwera usługi Azure Disk Storage.

Szyfrowanie magazynowane przy użyciu kluczy zarządzanych przez usługę (SMK) lub kluczy zarządzanych przez klienta (CMK)

Usługa Azure Database for PostgreSQL obsługuje dwa tryby szyfrowania danych magazynowanych: klucze zarządzane przez usługę (SMK) i klucze zarządzane przez klienta (CMK). Szyfrowanie danych przy użyciu kluczy zarządzanych przez usługę jest trybem domyślnym dla serwera elastycznego usługi Azure Database for PostgreSQL. W tym trybie usługa automatycznie zarządza kluczami szyfrowania używanymi do szyfrowania danych. Nie musisz podejmować żadnych działań w celu włączenia szyfrowania ani zarządzania nim w tym trybie.

W trybie kluczy zarządzanych przez klienta możesz wprowadzić własny klucz szyfrowania w celu zaszyfrowania danych. Ten tryb zapewnia większą kontrolę nad procesem szyfrowania, ale wymaga również samodzielnego zarządzania kluczami szyfrowania. Musisz wdrożyć własną usługę Azure Key Vault lub zarządzany sprzętowy moduł zabezpieczeń usługi Azure Key Vault (HSM) i skonfigurować go do przechowywania kluczy szyfrowania używanych przez wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL.

Tryb można wybrać tylko w czasie tworzenia serwera. Nie można go zmienić z jednego trybu na inny przez okres istnienia serwera.

Aby osiągnąć szyfrowanie danych, usługa Azure Database for PostgreSQL używa szyfrowania usługi Azure Storage dla danych magazynowanych. W przypadku korzystania z klucza cmK klient jest odpowiedzialny za dostarczanie kluczy 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.

Korzyści zapewniane przez każdy tryb (SMK lub CMK)

Szyfrowanie danych przy użyciu kluczy zarządzanych przez usługę dla usługi Azure Database for PostgreSQL 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 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 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 dotyczące Klienta Zarządzającego Kluczem

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 elastyczne wystąpienie serwera usługi Azure Database for PostgreSQL mogło wykonywać niezbędne operacje na kluczu. Musisz zadbać o skonfigurowanie wszystkich aspektów sieci usługi Azure Key Vault, w której jest przechowywany klucz, tak aby instancja elastycznego serwera usługi Azure Database for PostgreSQL mogła uzyskać dostęp do tego klucza. Inspekcja dostępu do klucza jest również twoim zadaniem. Na koniec jesteś odpowiedzialny za rotację klucza i, w razie potrzeby, za aktualizację konfiguracji elastycznego serwera usługi Azure Database for PostgreSQL, aby odwoływała się do zaktualizowanej 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 kluczami zarządzanymi przez klienta 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.

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

  • Usługa Key Vault i wystąpienie serwera elastycznego 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 miękkiego usunięcia 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 użytkownikowi tożsamości zarządzanej przypisanej przez użytkownika wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL dostęp 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).

Aktualizacje wersji klucza cmK

Klucz zarządzania kluczami można skonfigurować za pomocą ręcznego obrotu i aktualizacji klucza lub aktualizacji automatycznej wersji klucza po ręcznym lub automatycznym rotacji kluczy w usłudze Key Vault.

Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie szyfrowania danych przy użyciu klucza zarządzanego przez klienta podczas aprowizacji serwera.

Ważne

Podczas obracania klucza do nowej wersji należy zachować stary klucz dostępny do pomyślnego ponownego zaszyfrowania. Podczas gdy większość ponownych operacji szyfrowania powinna nastąpić w ciągu 30 minut, zalecamy odczekanie co najmniej 2 godzin przed wyłączeniem dostępu do starej wersji klucza.

Ręczne obracanie kluczy i aktualizacje

Podczas konfigurowania klucza zarządzanego przez klienta z ręcznymi aktualizacjami kluczy należy ręcznie zaktualizować wersję klucza w wystąpieniu elastycznego serwera Azure Database for PostgreSQL po ręcznym lub automatycznym obrocie kluczem w usłudze Key Vault. Serwer będzie nadal używać starej wersji klucza do momentu jego zaktualizowania. Ten tryb można aprowizować, określając identyfikator URI klucza, w tym wersję GUID w identyfikatorze URI. Na przykład https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Do niedawna była to jedyna dostępna opcja.

Za każdym razem, gdy ręcznie obracasz klucz lub automatycznie obraca klucz na podstawie zasad rotacji, trzeba było zaktualizować właściwość CMK w wystąpieniu bazy danych PostgreSQL. Takie podejście okazało się podatne na błędy dla operatorów lub wymaga niestandardowego skryptu do obsługi rotacji, zwłaszcza w przypadku korzystania z funkcji automatycznego obracania usługi Key Vault.

Automatyczne aktualizacje wersji klucza

Aby włączyć automatyczne aktualizacje wersji klucza, użyj identyfikatora URI klucza bez wersji. Eliminuje to konieczność zaktualizowania właściwości wersji klucza cmK w wystąpieniu bazy danych PostgreSQL po rotacji klucza. Usługa PostgreSQL automatycznie pobierze nową wersję klucza i ponownie zaszyfruje klucz szyfrowania danych. Jest to ogromne uproszczenie zarządzania cyklem życia klucza, zwłaszcza w połączeniu z automatycznym obracaniem usługi Key Vault.

Aby zaimplementować przy użyciu usługi ARM, Bicep, Terraform, programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure, po prostu pomiń wersję GUID z identyfikatora URI klucza.

W portalu zaznacz pole wyboru, aby kierować interfejsem użytkownika w celu pomijania identyfikatorów GUID wersji podczas wyboru interakcyjnego i sprawdzania poprawności identyfikatora URI.

Recommendations

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 zaufanym usługom firmy Microsoft na obejście tej zapory.
  • Włącz automatyczne aktualizacje wersji klucza.

Uwaga / Notatka

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 zarządzanego przez 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.

Uwagi specjalne

Przypadkowe odwołanie dostępu do klucza z usługi Azure 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 wystąpienia serwera usługi Azure Database for PostgreSQL za pomocą klucza zarządzanego przez klienta przechowywanego w Key Vault, każda nowo utworzona kopia tego 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 Rezolucja
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. 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 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. 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, przez co serwer elastycznego wystąpienia usługi Azure Database for PostgreSQL nie może komunikować się z usługą Key Vault w celu pobrania kluczy. Podczas konfigurowania zapory sieciowej usługi Key Vault upewnij się, że wybrano opcję zezwalania na zaufane usługi firmy Microsoft, aby instancja elastycznego serwera Azure Database for PostgreSQL mogła pominąć zaporę sieciową.

Uwaga / Notatka

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. Odzyskaj tożsamość lub utwórz nową tożsamość zarządzanego identyfikatora entra.
  2. Jeśli utworzyłeś nową tożsamość, nawet jeśli ma dokładnie taką samą nazwę, jak przed jej usunięciem, zaktualizuj właściwości instancji elastycznego serwera bazy danych Azure, aby system poprawnie rozpoznał, że powinien używać tej nowej tożsamości do 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 ciągłości działania geograficznie nadmiarowego

Usługa Azure Database for PostgreSQL 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

Są to bieżące ograniczenia dotyczące konfiguracji klucza zarządzanego przez klienta w elastycznym serwerze Azure Database for PostgreSQL.

Treści powiązane

  • Last updated on