Konfigurowanie szyfrowania danych w usłudze Azure Database for PostgreSQL

Ten artykuł zawiera instrukcje krok po kroku dotyczące konfigurowania szyfrowania danych dla elastycznego wystąpienia serwera usługi Azure Database for PostgreSQL.

Ważne

Jedynym punktem, w którym można zdecydować, czy chcesz użyć klucza zarządzanego przez system lub klucza zarządzanego przez klienta na potrzeby szyfrowania danych, jest tworzenie serwera. Po podjęciu tej decyzji i utworzeniu serwera nie można przełączać się między dwiema opcjami.

Z tego artykułu dowiesz się, jak utworzyć nowy serwer i skonfigurować opcje szyfrowania danych. W przypadku istniejących serwerów, których szyfrowanie danych jest skonfigurowane do używania klucza szyfrowania zarządzanego przez klienta, uczysz się:

• Jak wybrać inną tożsamość zarządzaną przypisaną przez użytkownika, za pomocą której usługa uzyskuje dostęp do klucza szyfrowania.
• Jak określić inny klucz szyfrowania lub sposób rotacji klucza szyfrowania używanego obecnie na potrzeby szyfrowania danych.

Aby dowiedzieć się więcej na temat szyfrowania danych w kontekście usługi Azure Database for PostgreSQL, zobacz szyfrowanie danych.

Konfigurowanie szyfrowania danych przy użyciu klucza zarządzanego przez system podczas aprowizacji serwera

Portal

Korzystanie z portalu Azure:

1. Przy przygotowywaniu nowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL, szyfrowanie danych jest konfigurowane na karcie Zabezpieczenia. W polu Klucz szyfrowania danych wybierz przycisk opcji Klucz zarządzany przez usługę.

   

2. Jeśli włączysz aprowizację geograficznie nadmiarowego magazynu kopii zapasowych wraz z serwerem, aspekt karty Zabezpieczenia zmieni się nieznacznie, ponieważ serwer używa dwóch oddzielnych kluczy szyfrowania. Jeden dla regionu podstawowego, w którym wdrażasz serwer, i jeden dla sparowanego regionu, w którym kopie zapasowe serwera są replikowane asynchronicznie.

   

CLI

Szyfrowanie danych można włączyć za pomocą klucza szyfrowania przypisanego przez system, a jednocześnie aprowizować nowy serwer za pomocą polecenia az postgres flexible-server create .

az postgres flexible-server create \
  --resource-group <resource_group> \
  --name <server> ...

Uwaga / Notatka

W poprzednim poleceniu nie ma specjalnego parametru, aby określić, że serwer musi zostać utworzony przy użyciu klucza przypisanego przez system na potrzeby szyfrowania danych. Przyczyną jest to, że szyfrowanie danych przy użyciu klucza przypisanego przez system jest opcją domyślną. Należy również zauważyć, że należy wykonać polecenie dostarczone z innymi parametrami, których obecność i wartości różnią się w zależności od tego, jak chcesz skonfigurować inne funkcje aprowizowanego serwera.

Konfigurowanie szyfrowania danych przy użyciu klucza zarządzanego przez klienta podczas aprowizacji serwera

Portal

Korzystanie z portalu Azure:

1. Utwórz tożsamość zarządzaną przypisaną przez jednego użytkownika, jeśli jeszcze jej nie masz. Jeśli serwer ma włączone geograficznie nadmiarowe kopie zapasowe, musisz utworzyć w różnych tożsamościach. Każda z tych tożsamości jest używana do uzyskiwania dostępu do każdego z dwóch kluczy szyfrowania danych.

Uwaga / Notatka

Chociaż nie jest to wymagane, aby zachować odporność regionalną, zalecamy utworzenie tożsamości zarządzanej przez użytkownika w tym samym regionie co serwer. Jeśli serwer ma włączoną nadmiarowość geograficzną kopii zapasowej, zalecamy utworzenie drugiej tożsamości zarządzanej przez użytkownika używanej do uzyskiwania dostępu do klucza szyfrowania danych dla geograficznie nadmiarowych kopii zapasowych w sparowanym regionie serwera.

1. Utwórz jedną usługę Azure Key Vault lub utwórz jeden zarządzany moduł HSM, jeśli jeszcze nie masz utworzonego magazynu kluczy. Upewnij się, że spełniasz wymagania. Ponadto przed skonfigurowaniem magazynu kluczy postępuj zgodnie z zaleceniami i przed utworzeniem klucza i przypisz wymagane uprawnienia do tożsamości zarządzanej przypisanej przez użytkownika. Jeśli serwer ma włączone geograficznie nadmiarowe kopie zapasowe, należy utworzyć drugi magazyn kluczy. Ten drugi magazyn kluczy służy do przechowywania klucza szyfrowania danych, za pomocą którego kopie zapasowe skopiowane do sparowanego regionu serwera są szyfrowane.

Uwaga / Notatka

Magazyn kluczy używany do przechowywania klucza szyfrowania danych musi być wdrożony w tym samym regionie co serwer. Jeśli serwer ma włączoną nadmiarowość geograficzną kopii zapasowej, magazyn kluczy, który przechowuje klucz szyfrowania danych dla geograficznie nadmiarowych kopii zapasowych, należy utworzyć w sparowanym regionie serwera.

1. Utwórz jeden klucz w magazynie kluczy. Jeśli serwer ma włączone geograficznie nadmiarowe kopie zapasowe, potrzebny jest jeden klucz w każdym z magazynów kluczy. Za pomocą jednego z tych kluczy szyfrujemy wszystkie dane serwera (w tym wszystkie bazy danych systemu i użytkowników, pliki tymczasowe, dzienniki serwera, segmenty dzienników z wyprzedzeniem zapisu i kopie zapasowe). Za pomocą drugiego klucza szyfrujemy kopie kopii zapasowych, które są asynchronicznie kopiowane w sparowanym regionie serwera.

2. Podczas aprowizowania nowego elastycznego serwera usługi Azure Database for PostgreSQL szyfrowanie danych jest konfigurowane na karcie Zabezpieczenia. W przypadku Klucza szyfrowania danych wybierz radio button Klucz zarządzany przez klienta.

   

3. Jeśli włączysz aprowizację geograficznie nadmiarowego magazynu kopii zapasowych wraz z serwerem, aspekt karty Zabezpieczenia zmieni się nieznacznie, ponieważ serwer używa dwóch oddzielnych kluczy szyfrowania. Jeden dla regionu podstawowego, w którym wdrażasz serwer, i jeden dla sparowanego regionu, w którym kopie zapasowe serwera są replikowane asynchronicznie.

   

4. W obszarze Tożsamość zarządzana przypisana przez użytkownika wybierz pozycję Zmień tożsamość.

   

5. Spośród listy tożsamości zarządzanych przypisanych przez użytkownika wybierz tę, której serwer ma używać do uzyskiwania dostępu do klucza szyfrowania danych przechowywanego w usłudze Azure Key Vault.

   

6. Wybierz Dodaj.

   

7. Wybierz pozycję Użyj automatycznej aktualizacji wersji klucza, jeśli wolisz zezwolić usłudze na automatyczne aktualizowanie odwołania do najnowszej wersji wybranego klucza, za każdym razem, gdy bieżąca wersja jest obracana ręcznie lub automatycznie. Aby zrozumieć zalety korzystania z automatycznych aktualizacji wersji klucza, zobacz automatyczna aktualizacja wersji klucza.

   

8. Wybierz pozycję Wybierz klucz.

   

9. Subskrypcja jest wypełniana automatycznie nazwą subskrypcji, na której ma zostać utworzony serwer. Magazyn kluczy, który przechowuje klucz szyfrowania danych, musi istnieć w tej samej subskrypcji co serwer.

   

10. W polu Typ magazynu kluczy wybierz przycisk radiowy odpowiadający typowi magazynu kluczy, w którym planujesz przechowywać klucz szyfrowania danych. W tym przykładzie wybieramy magazyn kluczy, ale środowisko jest podobne w przypadku wybrania zarządzanego modułu HSM.

    

11. Rozwiń węzeł Magazyn kluczy (lub zarządzany moduł HSM, jeśli wybrano ten typ magazynu), a następnie wybierz wystąpienie, w którym istnieje klucz szyfrowania danych.

    

    Uwaga / Notatka

    Po rozwinięciu pola listy rozwijanej zostanie wyświetlona pozycja Brak dostępnych elementów. Wyświetlenie listy wszystkich wystąpień magazynu kluczy wdrożonych w tym samym regionie co serwer zajmuje kilka sekund.

12. Rozwiń węzeł Klucz i wybierz nazwę klucza, którego chcesz użyć do szyfrowania danych.

    

13. Jeśli nie wybrano opcji Użyj automatycznej aktualizacji wersji klucza, musisz również wybrać określoną wersję klucza. W tym celu rozwiń węzeł Wersja i wybierz identyfikator wersji klucza, którego chcesz użyć do szyfrowania danych.

    

14. Wybierz pozycję Wybierz.

    

15. Skonfiguruj wszystkie inne ustawienia nowego serwera i wybierz pozycję Przejrzyj i utwórz.

    

CLI

Szyfrowanie danych można włączyć przy użyciu klucza szyfrowania przypisanego przez użytkownika, a jednocześnie aprowizować nowy serwer za pomocą polecenia az postgres flexible-server create .

Jeśli serwer nie ma włączonych geograficznie nadmiarowych kopii zapasowych:

az postgres flexible-server create \
  --resource-group <resource_group> \
  --name <server> \
  --geo-redundant-backup Disabled \
  --identity <managed_identity_to_access_primary_encryption_key> \
  --key <resource_identifier_of_primary_encryption_key> ...

Uwaga / Notatka

Poprzednie polecenie musi zostać wykonane z innymi parametrami, których obecność i wartości różnią się w zależności od tego, jak chcesz skonfigurować inne funkcje aprowizowanego serwera.

Jeśli serwer ma włączone geograficznie nadmiarowe kopie zapasowe:

az postgres flexible-server create \
  --resource-group <resource_group> \
  --name <server> \
  --geo-redundant-backup Enabled \
  --identity <managed_identity_to_access_primary_encryption_key> \
  --key <resource_identifier_of_primary_encryption_key> \
  --backup-identity <managed_identity_to_access_geo_backups_encryption_key> \
  --backup-key <resource_identifier_of_geo_backups_encryption_key> ...

Uwaga / Notatka

Poprzednie polecenie musi zostać wykonane z innymi parametrami, których obecność i wartości różnią się w zależności od tego, jak chcesz skonfigurować inne funkcje aprowizowanego serwera.

Konfigurowanie szyfrowania danych przy użyciu klucza zarządzanego przez klienta na istniejących serwerach

Jedynym punktem, w którym można zdecydować, czy chcesz użyć klucza zarządzanego przez system lub klucza zarządzanego przez klienta na potrzeby szyfrowania danych, jest tworzenie serwera. Po podjęciu tej decyzji i utworzeniu serwera nie można przełączać się między dwiema opcjami. Jedyną alternatywą, jeśli chcesz zmienić jedną z nich na drugą, wymaga przywrócenia dowolnej kopii zapasowej dostępnej na nowym serwerze. Podczas konfigurowania przywracania można zmienić konfigurację szyfrowania danych nowego serwera.

W przypadku istniejących serwerów wdrożonych przy użyciu szyfrowania danych przy użyciu klucza zarządzanego przez klienta można wykonać kilka zmian konfiguracji. Elementy, które można zmienić, to odwołania do kluczy używanych do szyfrowania oraz odwołania do tożsamości zarządzanych przypisanych przez użytkownika używanych przez usługę do uzyskiwania dostępu do kluczy przechowywanych w magazynach kluczy.

Należy zaktualizować odwołania, które musi zawierać wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL:

• Gdy klucz przechowywany w magazynie kluczy jest aktualizowany ręcznie lub automatycznie, a elastyczne wystąpienie serwera Azure Database for PostgreSQL odwołuje się do określonej wersji tego klucza. Jeśli wskazujesz klucz, ale nie na określoną wersję klucza (gdy jest włączona opcja Użyj automatycznej aktualizacji wersji klucza ), usługa automatycznie odwołuje się do najnowszej wersji klucza zawsze, gdy klucz jest ręcznie lub automatycznie obracany.
• Jeśli chcesz użyć tego samego lub innego klucza przechowywanego w innym magazynie kluczy.

Należy zaktualizować zarządzane tożsamości przypisane użytkownikowi, które są używane przez elastyczne wystąpienie serwera bazy danych Azure for PostgreSQL, aby uzyskać dostęp do kluczy szyfrowania za każdym razem, gdy zamierzasz użyć innej tożsamości.

Portal

Korzystanie z portalu Azure:

1. Wybierz swoją instancję elastycznego serwera usługi Azure Database dla PostgreSQL.

2. W menu zasobów w obszarze Zabezpieczenia wybierz pozycję Szyfrowanie danych.

   

3. Aby zmienić tożsamość zarządzaną przypisaną przez użytkownika, za pomocą której serwer uzyskuje dostęp do magazynu kluczy, w którym jest przechowywany klucz, rozwiń listę rozwijaną Tożsamość zarządzana przypisana przez użytkownika i wybierz dowolną z dostępnych tożsamości.

   

   Uwaga / Notatka

   Tożsamości wyświetlane w polu kombi to tylko te, które zostały przypisane Twojemu wystąpieniu elastycznego serwera usługi Azure Database dla PostgreSQL. Mimo że nie jest to wymagane, aby zachować odporność regionalną, zalecamy wybranie tożsamości zarządzanych przez użytkownika w tym samym regionie co serwer. Jeśli serwer ma włączoną nadmiarowość geograficzną kopii zapasowej, zalecamy, aby druga tożsamość zarządzana przez użytkownika używana do uzyskiwania dostępu do klucza szyfrowania danych dla geograficznie nadmiarowych kopii zapasowych istniała w sparowanym regionie serwera.

4. Jeśli tożsamość zarządzana przypisana przez użytkownika, której chcesz użyć do uzyskania dostępu do klucza szyfrowania danych, nie jest przypisana do wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL i nawet nie istnieje jako zasób platformy Azure z odpowiednim obiektem w Microsoft Entra ID, możesz ją utworzyć, wybierając pozycję Utwórz.

   

5. W panelu Tworzenie przypisanej przez użytkownika tożsamości zarządzanej wypełnij szczegóły dotyczące tożsamości, którą chcesz utworzyć, a następnie automatycznie przypisz ją do elastycznego wystąpienia serwera Azure Database for PostgreSQL, aby uzyskać dostęp do klucza szyfrowania danych.

   

6. Jeśli tożsamość zarządzana przypisana przez użytkownika, której chcesz użyć do uzyskiwania dostępu do klucza szyfrowania danych, nie jest przypisana do wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL, ale istnieje jako zasób platformy Azure z odpowiednim obiektem w identyfikatorze Entra firmy Microsoft, możesz go przypisać, wybierając pozycję Wybierz.

   

7. Spośród listy tożsamości zarządzanych przypisanych przez użytkownika wybierz tę, której serwer ma używać do uzyskiwania dostępu do klucza szyfrowania danych przechowywanego w usłudze Azure Key Vault.

   

8. Wybierz Dodaj.

   

9. Wybierz pozycję Użyj automatycznej aktualizacji wersji klucza, jeśli wolisz zezwolić usłudze na automatyczne aktualizowanie odwołania do najnowszej wersji wybranego klucza, za każdym razem, gdy bieżąca wersja jest obracana ręcznie lub automatycznie. Aby zrozumieć korzyści wynikające z używania automatycznych aktualizacji wersji klucza, zobacz [automatyczna aktualizacja wersji klucza](concepts-data-encryption.md##CMK aktualizacje wersji klucza).

   

10. Jeśli obrócisz klucz i nie masz włączonej automatycznej aktualizacji wersji klucza . Jeśli chcesz użyć innego klucza, musisz zaktualizować wystąpienie elastycznego serwera Azure Database dla PostgreSQL, aby wskazywało na nową wersję klucza lub nowy klucz. W tym celu możesz skopiować identyfikator zasobu klucza i wkleić go w polu Identyfikator klucza .

    

11. Jeśli użytkownik, który uzyskuje dostęp do witryny Azure Portal, ma uprawnienia dostępu do klucza przechowywanego w magazynie kluczy, możesz użyć alternatywnego podejścia, aby wybrać nowy klucz lub nową wersję klucza. Aby to zrobić, w metodzie Wyboru klucza wybierz przycisk radiowy Wybierz klucz .

    

12. Wybierz pozycję Wybierz klucz.

    

13. Subskrypcja jest wypełniana automatycznie nazwą subskrypcji, na której ma zostać utworzony serwer. Magazyn kluczy, który przechowuje klucz szyfrowania danych, musi istnieć w tej samej subskrypcji co serwer.

    

14. W polu Typ magazynu kluczy wybierz przycisk radiowy odpowiadający typowi magazynu kluczy, w którym planujesz przechowywać klucz szyfrowania danych. W tym przykładzie wybieramy magazyn kluczy, ale środowisko jest podobne w przypadku wybrania zarządzanego modułu HSM.

    

15. Rozwiń węzeł Magazyn kluczy (lub zarządzany moduł HSM, jeśli wybrano ten typ magazynu), a następnie wybierz wystąpienie, w którym istnieje klucz szyfrowania danych.

    

    Uwaga / Notatka

    Po rozwinięciu pola listy rozwijanej zostanie wyświetlona pozycja Brak dostępnych elementów. Wyświetlenie listy wszystkich wystąpień magazynu kluczy wdrożonych w tym samym regionie co serwer zajmuje kilka sekund.

16. Rozwiń węzeł Klucz i wybierz nazwę klucza, którego chcesz użyć do szyfrowania danych.

    

17. Jeśli nie wybrano opcji Użyj automatycznej aktualizacji wersji klucza, musisz również wybrać określoną wersję klucza. W tym celu rozwiń węzeł Wersja i wybierz identyfikator wersji klucza, którego chcesz użyć do szyfrowania danych.

    

18. Wybierz pozycję Wybierz.

    

19. Gdy zmiany zostały wprowadzone, wybierz pozycję Zapisz.

    

CLI

Szyfrowanie danych można skonfigurować przy użyciu klucza szyfrowania przypisanego przez użytkownika dla istniejącego serwera za pomocą polecenia az postgres flexible-server update .

az postgres flexible-server update \
  --resource-group <resource_group> \
  --name <server> \
  --identity <managed_identity_to_access_primary_encryption_key> \
  --key <resource_identifier_of_primary_encryption_key> ...

Uwaga / Notatka

Poprzednie polecenie może wymagać wykonania z innymi parametrami, których obecność i wartości różnią się w zależności od tego, jak chcesz skonfigurować inne funkcje istniejącego serwera.

Niezależnie od tego, czy chcesz zmienić tylko tożsamość zarządzaną przypisaną przez użytkownika w celu uzyskania dostępu do klucza, czy chcesz zmienić tylko klucz używany do szyfrowania danych, czy chcesz zmienić obie te tożsamości jednocześnie, musisz podać parametry --identity i --key (lub --backup-identity dla --backup-key geograficznie nadmiarowych kopii zapasowych). Jeśli podasz jeden, ale nie oba te błędy, wystąpią następujące błędy:

User assigned identity and keyvault key need to be provided together. Please provide --identity and --key together.

User assigned identity and keyvault key need to be provided together. Please provide --backup-identity and --backup-key together.

Jeśli klucz wskazywany przez wartość przekazaną do parametru --key (lub --backup-key dla kopii zapasowych geograficznie nadmiarowych) nie istnieje lub jeśli tożsamość zarządzana przypisana przez użytkownika, którego identyfikator zasobu jest przekazywany do --identity parametru (ruda --backup-identity dla geograficznie nadmiarowych kopii zapasowych) nie ma wymaganych uprawnień dostępu do klucza, zostanie wyświetlony następujący błąd:

Code: AzureKeyVaultKeyNameNotFound
Message: The operation could not be completed because the Azure Key Vault Key name '<key_vault_resource>' does not exist or User Assigned Identity does not have Get access to the Key (/azure/postgresql/flexible-server/concepts-data-encryption#requirements-for-configuring-data-encryption-for-azure-database-for-postgresql-flexible-server).

Jeśli serwer ma włączone geograficznie nadmiarowe kopie zapasowe, możesz skonfigurować klucz używany do szyfrowania geograficznie nadmiarowych kopii zapasowych oraz tożsamość używana do uzyskiwania dostępu do tego klucza. W tym celu można użyć parametrów --backup-identity i --backup-key .

az postgres flexible-server update \
  --resource-group <resource_group> \
  --name <server> \
  --backup-identity <managed_identity_to_access_georedundant_encryption_key> \
  --backup-key <resource_identifier_of_georedundant_encryption_key> ...

Jeśli przekażesz parametry --backup-identity i --backup-key do az postgres flexible server update polecenia i odwołasz się do istniejącego serwera, który nie ma włączonej geograficznie nadmiarowej kopii zapasowej, zostanie wyświetlony następujący błąd:

Geo-redundant backup is not enabled. You cannot provide Geo-location user assigned identity and keyvault key.

Tożsamości przekazane do parametrów --identity i --backup-identity, jeśli istnieją i są prawidłowe, są automatycznie dodawane do listy tożsamości zarządzanych przypisanych przez użytkownika, które są skojarzone z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL. Tak jest, nawet jeśli polecenie później zakończy się niepowodzeniem z innym błędem. W takich przypadkach możesz użyć poleceń az postgres flexible-server identity do wyświetlania, przypisywania lub usuwania zarządzanych tożsamości przypisanych przez użytkownika do instancji elastycznego serwera bazy danych Azure Database for PostgreSQL. Aby dowiedzieć się więcej na temat konfigurowania tożsamości zarządzanych przypisanych przez użytkownika w wystąpieniu elastycznego serwera usługi Azure Database for PostgreSQL, zapoznaj się z tematem Kojarzenie tożsamości zarządzanych przypisanych przez użytkownika z istniejącymi serwerami, rozłączanie tożsamości zarządzanych przypisanych przez użytkownika z istniejącymi serwerami oraz wyświetlanie skojarzonych tożsamości zarządzanych przypisanych przez użytkownika.

Treści powiązane

• Szyfrowanie danych