Szyfrowanie danych w spoczynku na serwerze elastycznym Azure Database for PostgreSQL

Azure Database for PostgreSQL — serwer elastyczny zawsze szyfruje wszystkie przechowywane dane. Te dane obejmują wszystkie bazy danych systemu i użytkowników, dzienniki serwera, segmenty dzienników z wyprzedzeniem zapisu i kopie zapasowe. Magazyn podstawowy obsługuje szyfrowanie za pomocą szyfrowania po stronie serwera 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 serwer elastyczny usługi Azure Database for PostgreSQL.

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

Aby szyfrować dane, usługa Azure Database for PostgreSQL wykorzystuje szyfrowanie danych przechowywanych w usłudze Azure Storage. Gdy używasz klucza cmK, odpowiadasz za dostarczanie kluczy do szyfrowania i odszyfrowywania danych w usługach Blob Storage i Azure Files. Te klucze należy przechowywać w Azure Key Vault lub Azure Key Vault zarządzanym sprzętowym module zabezpieczeń (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ę) i 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

Gdy używasz klucza szyfrowania zarządzanego przez klienta, ponosisz odpowiedzialność. Musisz wdrożyć własną Azure Key Vault lub moduł HSM 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. Należy skonfigurować wszystkie aspekty sieciowe Azure Key Vault, w których jest przechowywany klucz, aby Azure Database for PostgreSQL serwer elastyczny 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 tak, aby odwoływała się do wersji klucza po rotacji.

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ższa lista zawiera opis wymagań dotyczących konfigurowania szyfrowania danych dla Azure Database for PostgreSQL:

• W przypadku jednodzierżawowych konfiguracji CMK usługi Key Vault i elastyczny serwer Azure Database for PostgreSQL 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 Key Vault wymaga ponownego skonfigurowania szyfrowania danych.
• Ustaw konfigurację Liczba dni przechowywania usuniętych sejfów dla usługi Key Vault na 90 dni. Jeśli skonfigurowano istniejącą instancję usługi Key Vault z niższą wartością, nadal jest ona prawidłowa. Jeśli jednak chcesz zmodyfikować to ustawienie i zwiększyć jego wartość, musisz 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 Key Vault, aby ułatwić ochronę przed utratą danych w przypadku przypadkowego usunięcia klucza lub wystąpienia Key Vault. 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 Azure CLI.
• Włącz ochronę przed trwałym usunięciem, aby wymusić obowiązkowy okres przechowywania usuniętych magazynów oraz obiektów magazynu.
• Przyznaj tożsamości zarządzanej przypisanej przez użytkownika serwera elastycznego usługi Azure Database for PostgreSQL dostęp do klucza w następujący sposób:
• Zalecane: Skonfiguruj usługę Azure Key Vault z modelem uprawnień RBAC i przypisz tożsamości zarządzanej rolę Key Vault Crypto Service Encryption User.
• 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. Aby uzyskać lepsze zabezpieczenia, użyj klucza 4096-bitowego.
• 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

Możesz skonfigurować klucz zarządzany przez klienta (CMK) do ręcznej rotacji i aktualizacji albo do automatycznych aktualizacji wersji klucza po ręcznej lub automatycznej rotacji klucza w usłudze Key Vault.

Aby uzyskać więcej informacji, zobacz Konfigurowanie szyfrowania danych przy użyciu klucza zarządzanego przez klienta podczas aprowizacji serwera.

Ręczne obracanie kluczy i aktualizacje

Podczas konfigurowania klucza zarządzanego przez klienta (CMK) z ręcznymi aktualizacjami klucza należy ręcznie zaktualizować wersję klucza w usłudze Azure Database for PostgreSQL — serwer elastyczny po ręcznej lub automatycznej rotacji klucza w usłudze Key Vault. Serwer będzie nadal używać starej wersji klucza, dopóki nie zostanie zaktualizowana. Ten tryb konfigurujesz, podając adres URI klucza z uwzględnieniem wersji GUID w adresie URI. Na przykład https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Do niedawna ta opcja była jedyną dostępną opcją.

Za każdym razem, gdy ręcznie obrócono klucz lub gdy AKV automatycznie obracał klucz zgodnie z jego zasadami rotacji, trzeba było zaktualizować właściwość CMK na serwerze 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. To podejście eliminuje konieczność zaktualizowania właściwości wersji klucza cmK na serwerze PostgreSQL po rotacji klucza. Usługa PostgreSQL automatycznie pobiera nową wersję klucza i ponownie szyfruje klucz szyfrowania danych. Takie podejście znacznie upraszcza zarządzanie cyklem życia kluczy, zwłaszcza w połączeniu z automatyczną rotacją kluczy w usłudze Key Vault.

Aby wdrożyć to podejście za pomocą usługi Azure Resource Manager, Bicep, narzędzia 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ć Key Vault:

• Ustaw blokadę zasobu na Key Vault, aby zapobiec przypadkowemu lub nieautoryzowanemu usunięciu tego krytycznego zasobu.
• 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.

• 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 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 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 serwera elastycznego Azure Database for PostgreSQL za pomocą klucza zarządzanego przez klienta przechowywanego w Key Vault każda nowo utworzona kopia 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 serwera podstawowego Azure Database for PostgreSQL elastycznego.
• 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 odwołanie klucza nie jest obsługiwane 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 nowego serwera elastycznego Azure Database for PostgreSQL w portalu Azure z użyciem klucza zarządzanego przez klienta możesz wybrać Azure Key Vault Managed HSM jako magazyn kluczy, jako alternatywę dla 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 Key Vault serwer wymaga ciągłego dostępu do tego klucza, aby pozostać w trybie online. Jeśli serwer utraci dostęp, zmieni jego stan na Niedostępny i rozpoczyna odmawianie wszystkich połączeń.

Oto niektóre możliwe przyczyny, dla których stan serwera stanie się niedostępny :

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

Jeśli usuniesz tożsamość zarządzaną przypisaną przez użytkownika, która uzyskuje dostęp do klucza szyfrowania przechowywanego w Key Vault w Microsoft Entra ID, wykonaj następujące kroki, aby odzyskać:

1. Odzyskaj tożsamość lub utwórz nową tożsamość zarządzanego Entra ID.
2. Jeśli utworzono nową tożsamość, nawet jeśli ma ona dokładnie taką samą nazwę jak usunięta tożsamość, zaktualizuj właściwości usługi Azure Database for flexible server, 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.

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. Następujące wymagania dotyczą 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:

• Musisz utworzyć geograficznie nadmiarowy klucz szyfrowania kopii zapasowej w wystąpieniu Key Vault, które 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 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ą, utwórz tożsamość zarządzaną 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. Musisz utworzyć tożsamość przypisaną przez użytkownika, aby uwierzytelniać się w tym wystąpieniu usługi Key Vault 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 HSM, należących do innego identyfikatora Microsoft Entra ID niż identyfikator używany przez elastyczny serwer 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ć serwer Azure Database for PostgreSQL w dzierżawie dostawcy usług i skonfigurować klucze zarządzane przez klienta przy użyciu klucza z dzierżawy klienta.

Podczas tworzenia serwera Azure Database for PostgreSQL z kluczami zarządzanymi przez klienta należy upewnić się, że ma on dostęp do kluczy używanych przez klienta. W scenariuszach z jedną dzierżawą przyznajesz bezpośredni dostęp do usługi Key Vault tożsamości zarządzanej przez użytkownika serwera 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 międzydzierżawnym identyfikatorem aplikacji służy do utworzenia międzydzierżawnego klucza zarządzanego przez klienta (CMK) dla serwera Azure Database for PostgreSQL.

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

Korzystanie z portalu Azure

Aby skonfigurować międzydzierżawowe klucze zarządzane przez klienta dla nowego serwera 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:

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>"
        }
    }
}

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

• Azure PowerShell i Azure CLI nie obsługują jeszcze tej funkcji.
• 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 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 serwera elastycznego Azure Database for PostgreSQL. Zamiast tego można 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 cofnąć zmianę, musisz przywrócić serwer na nowy serwer z szyfrowaniem danych skonfigurowanym przy użyciu klucza zarządzanego przez system.
• Zasób Azure Key Vault Managed HSM lub zasób Azure Key Vault, w którym planujesz przechowywać klucz szyfrowania, musi znajdować się w tym samym regionie, w którym tworzysz usługę Azure Database for Flexible Server.

Treści powiązane

• Konfigurowanie szyfrowania danych w usłudze Azure Database for PostgreSQL