Szyfrowanie danych przy użyciu klucza zarządzanego przez klienta w usłudze Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Serwer elastyczny usługi Azure Database for PostgreSQL domyślnie szyfruje dane magazynowane przy użyciu kluczy zarządzanych przez firmę Microsoft. W przypadku użytkowników serwera elastycznego usługi Azure Database for PostgreSQL jest on podobny do przezroczystego szyfrowania danych w innych bazach danych, takich jak SQL Server.

Wiele organizacji wymaga pełnej kontroli dostępu do danych przy użyciu klucza zarządzanego przez klienta (CMK). Szyfrowanie danych za pomocą zestawów CMKs dla elastycznego serwera usługi Azure Database for PostgreSQL umożliwia przenoszenie klucza (BYOK) na potrzeby ochrony danych magazynowanych. Umożliwia to również organizacjom rozdzielanie obowiązków związanych z zarządzaniem kluczami i danymi. W przypadku szyfrowania cmK odpowiadasz za cykl życia klucza, uprawnienia do użycia klucza i inspekcję operacji na kluczach.

Szyfrowanie danych za pomocą zestawów CMKs dla elastycznego serwera usługi Azure Database for PostgreSQL jest ustawiane na poziomie serwera. W przypadku określonego serwera klucz szyfrowania klucza (KEK) jest używany do szyfrowania klucza szyfrowania danych (DEK) usługi. Klucz KEK jest kluczem asymetrycznym przechowywanym w wystąpieniu usługi Azure Key Vault należącym do klienta i zarządzanym przez klienta. W dalszej części tego artykułu opisano klucz KEK i deK.

Usługa 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 przenieść z lokalnego urządzenia HSM.

Świadczenia

Szyfrowanie danych za pomocą zestawów CMKs dla elastycznego serwera 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 w celu dostosowania do zasad firmy.

  • Klucze można centralnie zarządzać i organizować w usłudze Key Vault.

  • Włączenie szyfrowania nie wpływa na wydajność z użyciem lub bez zestawów CMKs, ponieważ usługa PostgreSQL opiera się na warstwie usługi Azure Storage na potrzeby szyfrowania danych w obu scenariuszach. Jedyną różnicą jest to, że w przypadku używania klucza CMK klucz szyfrowania usługi Azure Storage (który wykonuje rzeczywiste szyfrowanie danych) jest szyfrowany.

  • Można zaimplementować rozdzielenie obowiązków między funkcjonariuszami zabezpieczeń, administratorami bazy danych i administratorami systemu.

Terminologia

Klucz szyfrowania danych (DEK): symetryczny klucz AES 256 używany do szyfrowania partycji lub bloku danych. Szyfrowanie każdego bloku danych przy użyciu innego klucza sprawia, że ataki kryptograficzne są trudniejsze. Dostawca zasobów lub wystąpienie aplikacji, które szyfruje i odszyfrowuje określony blok, wymaga dostępu do usługi DEKs. Po zastąpieniu klucza szyfrowania danych nowym kluczem tylko dane w skojarzonym bloku muszą zostać ponownie zaszyfrowane przy użyciu nowego klucza.

Klucz szyfrowania kluczy (KEK): klucz szyfrowania używany do szyfrowania kluczy szyfrowania. Klucz KEK, który nigdy nie opuszcza usługi Key Vault, pozwala na szyfrowanie i kontrolowanie tokenów szyfrowania. Jednostka, która ma dostęp do klucza KEK, może różnić się od jednostki wymagającej tokenów SZYFROWANIA. Ponieważ klucz KEK jest wymagany do odszyfrowywania kluczy szyfrowania, klucz KEK jest skutecznie pojedynczym punktem, za pomocą którego można usunąć elementy DEKs (przez usunięcie klucza KEK).

Zestawy SZYFROWANIA szyfrowane przy użyciu klucza KEK są przechowywane oddzielnie. Tylko jednostka, która ma dostęp do klucza KEK, może odszyfrować te klucze SZYFROWANIA. Aby uzyskać więcej informacji, zobacz Zabezpieczenia w szyfrowaniu magazynowanych.

Jak działa szyfrowanie danych za pomocą klucza zarządzanego przez klienta

Diagram przedstawiający przegląd funkcji Bring Your Own Key.

Tożsamość zarządzana przypisana przez użytkownika firmy Microsoft jest używana do nawiązywania połączenia i pobierania klucza zarządzanego przez klienta. Aby utworzyć tożsamość, wykonaj czynności opisane w tym samouczku.

Aby serwer PostgreSQL używał kluczy zarządzanych przechowywanych w usłudze Key Vault do szyfrowania klucza szyfrowania klucza, administrator usługi Key Vault zapewnia następujące prawa dostępu do utworzonej tożsamości zarządzanej:

  • get: aby pobrać część publiczną i właściwości klucza w usłudze Key Vault.

  • list: Aby wyświetlić listę i iterować za pomocą kluczy w usłudze Key Vault.

  • wrapKey: do szyfrowania klucza szyfrowania klucza szyfrowania. Zaszyfrowany klucz szyfrowania danych jest przechowywany w usłudze Azure Database for PostgreSQL.

  • unwrapKey: do odszyfrowywania klucza szyfrowania danych. Usługa Azure Database for PostgreSQL wymaga odszyfrowanego klucza szyfrowania danych w celu szyfrowania i odszyfrowania danych.

Administrator usługi Key Vault może również włączyć rejestrowanie zdarzeń inspekcji usługi Key Vault, aby można je było przeprowadzić później.

Ważne

Brak podania poprzednich praw dostępu do tożsamości zarządzanej w celu uzyskania dostępu do usługi Key Vault może spowodować niepowodzenie pobrania klucza szyfrowania i nie skonfigurowanie funkcji cmK.

Podczas konfigurowania serwera do używania klucza zarządzanego przez klienta przechowywanego w usłudze Key Vault serwer wysyła klucz szyfrowania do usługi Key Vault na potrzeby szyfrowania. Usługa Key Vault zwraca zaszyfrowany klucz szyfrowania danych przechowywany w bazie danych użytkownika. W razie potrzeby serwer wysyła chroniony klucz szyfrowania szyfrowania do usługi Key Vault w celu odszyfrowywania. Audytorzy mogą używać usługi Azure Monitor do przeglądania dzienników zdarzeń inspekcji usługi Key Vault, jeśli rejestrowanie jest włączone.

Wymagania dotyczące konfigurowania szyfrowania danych dla serwera elastycznego usługi Azure Database for PostgreSQL

Poniżej przedstawiono wymagania dotyczące konfigurowania usługi Key Vault:

  • Usługa Key Vault i serwer elastyczny usługi Azure Database for PostgreSQL muszą należeć do tej samej dzierżawy firmy Microsoft Entra. Interakcje między dzierżawami usługi Key Vault i serwera nie są obsługiwane. Przeniesienie zasobu usługi Key Vault wymaga ponownego skonfigurowania szyfrowania danych.

  • Ustawienie Dni przechowywania usuniętych magazynów dla usługi Key Vault musi mieć wartość 90. Jeśli skonfigurowano istniejące wystąpienie usługi Key Vault z mniejszą liczbą, należy utworzyć nowe wystąpienie usługi Key Vault, ponieważ nie można zmodyfikować wystąpienia po utworzeniu.

  • Zaleca się ustawienie opcji Days ( Dni), aby zachować konfigurację usuniętych magazynów dla usługi Key Vault na 90 dni. W przypadku skonfigurowania istniejącego wystąpienia usługi Key Vault z mniejszą liczbą powinna być nadal prawidłowa. Jeśli jednak chcesz zmodyfikować to ustawienie i zwiększyć wartość, konieczne jest utworzenie nowego wystąpienia usługi Key Vault. Po utworzeniu wystąpienia nie można zmodyfikować jego konfiguracji.

  • Włącz funkcję usuwania nietrwałego w usłudze Key Vault, aby chronić przed utratą danych w przypadku przypadkowego usunięcia klucza lub wystąpienia usługi Key Vault. 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 zasadami dostępu usługi Key Vault.

    Funkcja usuwania nietrwałego jest domyślnie wyłączona, ale można ją włączyć za pomocą programu PowerShell lub interfejsu wiersza polecenia platformy Azure. Nie można go włączyć za pośrednictwem witryny Azure Portal.

  • Włącz ochronę przed przeczyszczeniem, aby wymusić obowiązkowy okres przechowywania usuniętych magazynów i obiektów magazynu.

  • Udziel elastycznemu wystąpieniu serwera usługi Azure Database for PostgreSQL dostępu do usługi Key Vault przy użyciu uprawnień get, list, wrapKey i unwrapKey przy użyciu unikatowej tożsamości zarządzanej.

Poniżej przedstawiono wymagania dotyczące konfigurowania klucza zarządzanego przez klienta na serwerze elastycznym usługi Azure Database for PostgreSQL:

  • Klucz cmK, który ma być 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.

  • 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 *Enabled- stanie .

  • Jeśli importujesz istniejący klucz do usługi Key Vault, podaj go w obsługiwanych formatach plików (.pfx, .byok, lub .backup).

Zalecenia

Jeśli używasz klucza zarządzanego przez klienta na potrzeby szyfrowania danych, poniżej przedstawiono zalecenia dotyczące konfigurowania usługi Key Vault:

  • Ustaw blokadę zasobu w usłudze Key Vault, aby kontrolować, kto może usunąć ten krytyczny zasób i zapobiec przypadkowemu lub nieautoryzowanemu usunięciu.

  • 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.

  • Upewnij się, że usługa Key Vault i serwer elastyczny usługi Azure Database for PostgreSQL znajdują się w tym samym regionie, aby zapewnić szybszy dostęp do operacji zawijania i odpakowania szyfrowania plików DEK.

  • Zablokuj usługę Key Vault, wybierając pozycję Wyłącz dostęp publiczny i Zezwalaj na zaufane usługi firmy Microsoft, aby pominąć tę zaporę.

    Zrzut ekranu przedstawiający opcje sieciowe wyłączające dostęp publiczny i zezwalające tylko na zaufane usługi firmy Microsoft.

Uwaga

Po wybraniu pozycji Wyłącz dostęp publiczny i Zezwalaj na zaufane usługi firmy Microsoft obejście tej zapory może wystąpić błąd podobny do poniższego podczas próby użycia publicznego dostępu do administrowania usługą Key Vault za pośrednictwem portalu: "Włączono kontrolę dostępu do sieci. Tylko dozwolone sieci będą miały dostęp do tego magazynu kluczy". Ten błąd nie wyklucza możliwości udostępniania kluczy podczas instalacji klucza zarządzanego przez klienta lub pobierania kluczy z usługi Key Vault podczas operacji serwera.

Poniżej przedstawiono zalecenia dotyczące konfigurowania klucza zarządzanego przez klienta:

  • Zachowaj kopię klucza zarządzanego przez klienta w bezpiecznym miejscu lub deponuj ją 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.

Przypadkowe odwołanie dostępu do klucza z usługi Key Vault

Osoba mająca wystarczające prawa dostępu do usługi Key Vault może przypadkowo wyłączyć dostęp serwera do klucza przez:

  • Odwołowywanie listy, pobieranie, zawijanie i odpakowywanie uprawnieńKey z tożsamości używanej do pobierania 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 klucza zarządzanego przez klienta w usłudze Key Vault

Aby monitorować stan bazy danych i włączyć alerty dotyczące utraty dostępu do funkcji ochrony przezroczystego 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 za pomocą klucza zarządzanego klienta w usłudze Key Vault

Po zaszyfrowaniu elastycznego serwera usługi Azure Database for PostgreSQL za pomocą klucza zarządzanego klienta przechowywanego w usłudze Key Vault każda nowo utworzona kopia serwera jest również szyfrowana. Możesz utworzyć tę nową kopię za pomocą operacji przywracania do punktu w czasie (PITR) lub replik do odczytu.

Podczas konfigurowania szyfrowania danych zarządzanych przez klienta podczas przywracania lub tworzenia repliki do odczytu można uniknąć problemów, wykonując następujące kroki na serwerach podstawowych i przywróconych/repliki:

  • Zainicjuj proces przywracania lub proces tworzenia repliki do odczytu z podstawowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL.

  • Na przywróconym lub replikowym serwerze można zmienić klucz zarządzania kluczami i/lub tożsamość firmy Microsoft Entra, która jest używana do uzyskiwania dostępu do usługi Key Vault w ustawieniach szyfrowania danych. Upewnij się, że nowo utworzony serwer ma uprawnienia listy, zawijania i odpakowywania do klucza przechowywanego 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 włączoną obsługą klucza zarządzania kluczami 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 za pomocą funkcji klucza zarządzanego modułu HSM usługi Azure Key Vault można wybrać 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?.

Niedostępny warunek klucza zarządzanego przez klienta

Podczas konfigurowania szyfrowania danych za pomocą klucza zarządzanego przez klienta w usłudze Key Vault wymagany jest ciągły dostęp do tego klucza, aby serwer pozostał w trybie online. Jeśli serwer utraci dostęp do klucza zarządzanego przez klienta w usłudze Key Vault, serwer zacznie odmawiać wszystkich połączeń w ciągu 10 minut. Serwer wysyła odpowiedni komunikat o błędzie i zmienia stan serwera na Niedostępny.

Niektóre z powodów, dla których stan serwera staje się niedostępny, to:

  • Jeśli usuniesz wystąpienie usługi Key Vault, wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL nie będzie mieć dostępu do klucza i przejdzie do stanu Niedostępny . Aby udostępnić serwer, odzyskaj wystąpienie usługi Key Vault i zrewiduj szyfrowanie danych.
  • Jeśli usuniesz klucz z usługi Key Vault, wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL nie będzie mieć dostępu do klucza i przejdzie do stanu Niedostępny . Aby udostępnić serwer, odzyskaj klucz i zrewiduj szyfrowanie danych.
  • Jeśli usuniesz z usługi Microsoft Entra ID tożsamość zarządzaną używaną do pobierania klucza z usługi Key Vault, wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL nie może uzyskać dostępu do klucza i zostanie przeniesione do stanu Niedostępny . Aby udostępnić serwer, odzyskaj tożsamość i zrewiduj szyfrowanie danych.
  • Jeśli odwołasz listę usługi Key Vault, pobierz, zawijaj i odpakuj zasady dostępuKey z tożsamości zarządzanej używanej do pobierania klucza z usługi Key Vault, elastyczne wystąpienie serwera usługi Azure Database for PostgreSQL nie może uzyskać dostępu do klucza i zostanie przeniesione do stanu Niedostępny. Dodaj wymagane zasady dostępu do tożsamości w usłudze Key Vault.
  • Jeśli skonfigurujesz zbyt restrykcyjne reguły zapory usługi Key Vault, elastyczny serwer usługi Azure Database for PostgreSQL nie może komunikować się z usługą Key Vault w celu pobrania kluczy. Podczas konfigurowania zapory usługi Key Vault należy wybrać opcję zezwalania zaufanym usługi firmy Microsoft na obejście zapory.

Uwaga

Gdy klucz jest wyłączony, usunięty, wygasł lub nieosiągalny, serwer, który ma dane zaszyfrowane za pośrednictwem tego klucza, staje się niedostępny, jak określono wcześniej. Serwer nie będzie dostępny do momentu ponownego włączenia klucza lub przypisania nowego klucza.

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ę dostępny .

Korzystanie z szyfrowania danych za pomocą zestawów CMKs i funkcji ciągłości działania geograficznie nadmiarowego

Serwer elastyczny usługi 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 w regionie, w którym jest przechowywana geograficznie nadmiarowa kopia zapasowa.
  • Wersja interfejsu API REST usługi Azure Resource Manager do obsługi geograficznie nadmiarowych serwerów CMK z obsługą kopii zapasowych to 2022-11-01-preview. Jeśli chcesz użyć szablonów usługi Azure Resource Manager do zautomatyzowania tworzenia serwerów korzystających zarówno z szyfrowania za pomocą zestawów CMK, jak i funkcji geograficznie nadmiarowej kopii zapasowej, użyj tej wersji interfejsu API.
  • Nie można użyć tej samej tożsamości zarządzanej przez użytkownika do uwierzytelniania dla wystąpienia usługi Key Vault podstawowej bazy danych i wystąpienia usługi Key Vault, które przechowuje klucz szyfrowania na potrzeby geograficznie nadmiarowej kopii zapasowej. Aby zachować odporność regionalną, zalecamy utworzenie tożsamości zarządzanej przez użytkownika w tym samym regionie co geograficznie nadmiarowe kopie zapasowe.
  • Jeśli podczas tworzenia skonfigurowana jest baza danych repliki do odczytu do szyfrowania za pomocą kluczy cmK, jego klucz szyfrowania musi znajdować się w wystąpieniu usługi Key Vault w regionie, w którym znajduje się baza danych repliki do odczytu. Tożsamość przypisana przez użytkownika do uwierzytelniania w tym wystąpieniu usługi Key Vault musi zostać utworzona w tym samym regionie.

Ograniczenia

Poniżej przedstawiono bieżące ograniczenia dotyczące konfigurowania klucza zarządzanego przez klienta na serwerze elastycznym usługi Azure Database for PostgreSQL:

  • Szyfrowanie CMK można skonfigurować tylko podczas tworzenia nowego serwera, a nie jako aktualizacji istniejącego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL. Zamiast tego możesz przywrócić kopię zapasową pitr na nowy serwer z szyfrowaniem CMK.

  • Po skonfigurowaniu szyfrowania CMK nie można go usunąć. Jeśli chcesz usunąć tę funkcję, jedynym sposobem jest przywrócenie serwera do serwera innego niż CMK.

Następne kroki