Szyfrowanie danych w spoczynku 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 bazowy magazyn danych przy użyciu funkcji szyfrowania po stronie serwera w usłudze Azure Disk Storage.

Szyfrowanie danych magazynowanych 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. Możesz usunąć klucz, aby uniemożliwić dostęp do bazy danych.
  • 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 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 szyfruje główny klucz szyfrowania danych (DEK) tego konta przy użyciu klucza zarządzanego przez klienta w powiązanym 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 wysoce dostępny i zapewnia skalowalną, bezpieczną pamięć masową dla kluczy kryptograficznych RSA, opcjonalnie opartą na sprzętowych modułach zabezpieczeń (HSM) zweryfikowanych zgodnie 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.

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

  • W przypadku konfiguracji CMK w środowisku jednodzierżawnym usługi Key Vault i wystąpienie usługi Azure Database for PostgreSQL Flexible Server muszą należeć do tej samej dzierżawy Microsoft Entra. Aby zapoznać się ze scenariuszami między dzierżawami, zobacz Cross-tenant customer-managed keys (Klucze zarządzane przez klienta między dzierżawami). Przeniesienie zasobu usługi Key Vault wymaga ponownego skonfigurowania szyfrowania danych.
  • Zalecamy ustawienie w usłudze Key Vault parametru Days to retain deleted vaults na 90 dni. Jeśli skonfigurowałeś istniejącą instancję usługi Key Vault na mniejszą wartość, nadal powinno to 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 nieostatecznego w usłudze Key Vault, aby pomóc chronić dane przed utratą, jeśli klucz lub magazyn Key Vault zostanie przypadkowo usunięty. Usługa Key Vault zachowuje miękko usunięte zasoby przez 90 dni, chyba że użytkownik w międzyczasie je odzyska lub trwale usunie. Operacje przywracania i trwałego usuwania mają własne uprawnienia powiązane z usługą Key Vault, definiowane przez rolę RBAC lub uprawnienie w ramach zasad dostępu. Funkcja miękkiego usunięcia jest domyślnie włączona. Jeśli masz jakiś Key Vault, który został wdrożony dawno temu, może on 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 trwałym usunięciem, aby wymusić obowiązkowy okres przechowywania usuniętych magazynów oraz 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.
  • list: Aby wyświetlić i przeglądać 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ądzany przez klienta (CMK) można skonfigurować z ręczną rotacją klucza i aktualizacjami lub z automatycznymi aktualizacjami wersji klucza po ręcznej lub automatycznej rotacji klucza 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

W przypadku rotacji klucza do nowej wersji należy zachować stary klucz dostępny, aby ponowne szyfrowanie zakończyło się pomyślnie. 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, dopóki nie zostanie zaktualizowana. Ten tryb konfigurujesz, podając identyfikator URI klucza zawierający wersję GUID. 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 obracano klucz lub gdy AKV automatycznie obracał go zgodnie z zasadami rotacji, należało zaktualizować właściwość CMK w instancji PostgreSQL. Takie podejście okazało się podatne na błędy po stronie operatorów lub wymagało niestandardowego skryptu do obsługi rotacji, zwłaszcza podczas korzystania z funkcji automatycznej rotacji w usłudze Key Vault.

Automatyczne aktualizacje wersji klucza

Aby włączyć automatyczne aktualizacje wersji klucza, użyj identyfikatora URI klucza bez wersji. Takie podejście eliminuje konieczność aktualizowania właściwości wersji klucza CMK w wystąpieniu PostgreSQL po rotacji klucza. Usługa PostgreSQL automatycznie pobiera nową wersję klucza i ponownie szyfruje klucz szyfrowania danych. To znacznie upraszcza zarządzanie cyklem życia kluczy, zwłaszcza w połączeniu z automatyczną rotacją w usłudze Key Vault.

Aby wdrożyć to przy użyciu Azure Resource Manager, Bicep, Terraform, Azure PowerShell lub Azure CLI, pomiń wersję GUID w identyfikatorze 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.

Rekomendacje

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 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:

  • Stan zasobu: baza danych, która utraciła dostęp do klucza CMK, pojawia się jako Niedostępna po odrzuceniu pierwszej próby połączenia z bazą danych.
  • Dziennik aktywności: gdy dostęp do klucza CMK w wystąpieniu usługi Key Vault zarządzanym przez klienta się nie powiedzie, do dziennika aktywności są dodawane wpisy. 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ę przez operację przywracania do punktu w czasie (PITR) lub za pomocą 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 w portalu Azure nowych wystąpień serwera elastycznego usługi Azure Database for PostgreSQL z użyciem klucza zarządzanego przez klienta możesz wybrać usługę Azure Key Vault Managed HSM jako magazyn kluczy zamiast 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 usługi Managed HSM, jej zalet i różnic w porównaniu ze współdzielonym magazynem certyfikatów opartym na usłudze Key Vault oraz importowania kluczy do usługi Managed HSM, zobacz Co to jest usługa Azure Key Vault Managed HSM?.

Stan niedostępności klucza zarządzanego przez klienta

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, a ta data i godzina już nadeszła. 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.
Przeprowadzasz rotację klucza i zapominasz zaktualizować wystąpienie usługi Azure Database for PostgreSQL Flexible Server 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 dokonujesz rotacji klucza, pamiętaj, aby zaktualizować instancję serwera tak, aby wskazywała na nową wersję. Aby to zrobić, użyj az postgres flexible-server update, zgodnie z przykładem opisującym "Zmień klucz/tożsamość używane do szyfrowania danych. Nie można włączyć szyfrowania danych po utworzeniu serwera; spowoduje to jedynie aktualizację klucza/tożsamości.". Jeśli wolisz zaktualizować to za pomocą interfejsu API, możesz wywołać punkt końcowy usługi Servers - Update.
Po usunięciu wystąpienia usługi Key Vault wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL nie może uzyskać dostępu do tego klucza i przechodzi 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 z usługi Microsoft Entra ID tożsamość zarządzaną, która jest używana do pobierania któregokolwiek z kluczy szyfrowania przechowywanych w usłudze Key Vault. 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ą weryfikację klucza i automatycznie zmieni 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 przypisz rolę RBAC tożsamości zarządzanej i zaczekaj, aż usługa przeprowadzi okresową ponowną weryfikację klucza i automatycznie przełączy 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 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ą zarządzaną tożsamość Entra ID.
  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żywaj szyfrowania danych przy użyciu kluczy zarządzanych przez klienta oraz funkcji ciągłości działania z redundancją geograficzną

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 dla kopii zapasowej z nadmiarowością geograficzną musi zostać utworzony w magazynie kluczy Key Vault, który znajduje się w regionie, w którym jest przechowywana ta 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 w wystąpieniu usługi Key Vault dla podstawowej bazy danych oraz w wystąpieniu usługi Key Vault, które przechowuje klucz szyfrowania dla 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 skonfigurujesz bazę danych repliki do odczytu jako szyfrowaną przy użyciu kluczy CMK, jej klucz szyfrowania musi znajdować się w wystąpieniu usługi Key Vault w regionie, w którym znajduje się ta baza danych repliki do odczytu. Tożsamość przypisana przez użytkownika używana do uwierzytelniania względem tego wystąpienia usługi Key Vault musi zostać utworzona w tym samym regionie.

Międzydzierżawowe klucze zarządzane przez klienta (CMK) (wersja zapoznawcza)

Międzydzierżawowe klucze zarządzane przez klienta umożliwiają używanie kluczy szyfrowania przechowywanych w magazynie Key Vault lub zarządzanym wystąpieniu modułu HSM, należących do innego identyfikatora Microsoft Entra ID niż wystąpienie serwera elastycznego Azure Database for PostgreSQL. Konfiguracja CMK między dzierżawami wymaga dodatkowej konfiguracji i koordynacji między dzierżawami. W scenariuszu obejmującym wiele dzierżaw zasób Azure Database for PostgreSQL znajduje się w dzierżawie zarządzanej przez niezależnego dostawcę oprogramowania (ISV), określanego mianem dostawcy usług. Klucz używany do szyfrowania zasobu Azure Database for PostgreSQL znajduje się w magazynie kluczy w innej dzierżawie zarządzanej przez klienta.

Omówienie konfiguracji

W dzierżawie niezależnego dostawcy oprogramowania

  • Tworzenie aplikacji wielodostępnej

    • Skonfiguruj tożsamość zarządzaną przypisaną przez użytkownika jako federacyjne poświadczenie w aplikacji

Dla klienta

  1. Zainstaluj aplikację wielodostępną

  2. Tworzenie lub używanie istniejącego magazynu kluczy lub zarządzanego modułu HSM i udzielanie uprawnień klucza do aplikacji wielodostępnych

    1. Tworzenie nowego lub używanie istniejącego klucza

    2. Pobieranie klucza z usługi Azure Key Vault lub zarządzanego modułu HSM platformy Azure i rejestrowanie identyfikatora klucza

W dzierżawie niezależnego dostawcy oprogramowania

Do tego momentu skonfigurowałeś aplikację wielodostępną na dzierżawie dostawcy usług. Zainstalowałeś również aplikację w dzierżawie klienta oraz skonfigurowałeś magazyn kluczy i klucz w dzierżawie klienta. Następnie możesz utworzyć wystąpienie usługi Azure Database for PostgreSQL w dzierżawie dostawcy usług i skonfigurować klucze zarządzane przez klienta za pomocą klucza z dzierżawy klienta.

Podczas tworzenia wystąpienia Azure Database for PostgreSQL z kluczami zarządzanymi przez klienta należy upewnić się, że wystąpienie ma dostęp do kluczy użytych przez klienta. W scenariuszach z jedną dzierżawą uzyskujesz bezpośredni dostęp magazynu kluczy do tożsamości zarządzanej przez użytkownika wystąpienia Azure Database for PostgreSQL. W scenariuszu obejmującym wiele dzierżaw nie można już polegać na bezpośrednim dostępie do magazynu kluczy, ponieważ znajduje się on w innej dzierżawie zarządzanej przez klienta. To ograniczenie jest powodem, dla którego w poprzednich sekcjach utworzono aplikację międzydzierżawową i zarejestrowano w niej tożsamość zarządzaną, aby zapewnić jej dostęp do magazynu kluczy klienta. Ta tożsamość zarządzana w połączeniu z identyfikatorem aplikacji międzytenantowej to elementy używane podczas tworzenia międzytenantowego klucza CMK dla instancji Azure Database for PostgreSQL.

Za każdym razem, gdy nowa wersja klucza jest dostępna w magazynie kluczy, wystąpienie Azure Database for PostgreSQL automatycznie pobiera nową wersję.

Korzystanie z portalu Azure

Aby skonfigurować klucze zarządzane przez klienta między dzierżawami dla nowego wystąpienia Azure Database for PostgreSQL w portalu Azure, wykonaj następujące kroki:

  1. W obszarze tworzenia zasobu Azure Database for PostgreSQL w witrynie Azure portal wybierz kartę Security, a następnie wybierz pozycję Klucz zarządzany przez klienta.

  2. Przypisz utworzoną tożsamość zarządzaną przypisaną przez użytkownika jako tożsamość zarządzana przypisana przez użytkownika.

  3. Przypisz aplikację wielodostępną przy użyciu nazwy aplikacji.

  4. Wprowadź identyfikator klucza w metodzie Wyboru klucza przy użyciu identyfikatora klucza klienta uzyskanego z dzierżawy klienta.

Użyj szablonów JSON usługi Azure Resource Manager i interfejsu API REST

Wdróż szablon usługi ARM z następującymi określonymi parametrami:

Uwaga / Notatka

Jeśli ponownie utworzysz ten przykład w jednym z szablonów Azure Resource Manager, użyj apiVersion2025-03-15-privatepreview lub nowszych wersji.

Parametr Description Przykładowa wartość
primaryKeyUri Identyfikator klucza zarządzanego przez klienta znajdującego się w magazynie kluczy dostawcy usług. https://my-vault.vault.azure.com/keys/my-key
primaryUserAssignedIdentity Obiekt określający, że tożsamość zarządzana powinna zostać przypisana do instancji Azure Database for PostgreSQL. "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}
primaryFederatedIdentityClientId Identyfikator klienta wielodostępnej aplikacji Microsoft Entra. application-client-id

Oto przykład interfejsu API REST ze skonfigurowanymi trzema parametrami:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Przykład treści żądania:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Oto przykład interfejsu API REST na potrzeby rotacji kluczy. Przykład PATCH aktualizuje tylko adres URI klucza CMK, aby dokonać rotacji klucza szyfrowania bez konieczności ponownego tworzenia serwera.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Treść żądania (przykład obracania klucza):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Ważne

Nawet jeśli zaktualizujesz tylko identyfikator primaryKeyUri, musisz określić wszystkie właściwości szyfrowania danych w treści żądania. Jeśli nie podasz identyfikatora primaryFederatedIdentityClientId w treści żądania, żądanie będzie traktowane jako konfiguracja CMK nieobejmująca wielu dzierżaw.

Ograniczenia dotyczące kluczy zarządzanych przez klienta między dzierżawami (CMK) w wersji zapoznawczej

  • Ta funkcja nie jest jeszcze obsługiwana w Azure PowerShell ani w Azure CLI.
  • Tworzenie serwera z geograficznie nadmiarowymi kopiami zapasowymi i włączanie długoterminowych operacji przechowywania kopii zapasowych nie jest obecnie obsługiwane.
  • Wersja zapoznawcza jest obecnie obsługiwana tylko w następujących regionach:
    • Wschodnie stany USA 2
    • Zachodnie stany USA 2
    • Środkowe stany USA
    • Australia Południowo-Wschodnia
    • Australia Wschodnia
    • Europa Północna

Ograniczenia kluczy zarządzanych przez klienta (CMK)

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