Udostępnij za pośrednictwem

Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL

Dzięki szyfrowaniu danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL, możesz przynieść własny klucz (BYOK) dla ochrony danych w spoczynku i wdrożyć rozdzielenie obowiązków związanych z zarządzaniem kluczami i danymi. W przypadku kluczy zarządzanych przez klienta (CMK) klient jest odpowiedzialny za zarządzanie cyklem życia kluczy (tworzenie kluczy, przekazywanie, rotacja, usuwanie), uprawnienia użycia klucza i operacje inspekcji kluczy na kluczach.

Uwaga

Zarządzany moduł HSM usługi Azure Key Vault (sprzętowy moduł zabezpieczeń) jest obecnie obsługiwany w przypadku kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL.

Świadczenia

Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL zapewnia następujące korzyści:

  • Możesz w pełni kontrolować dostęp do danych przez możliwość usunięcia klucza i uniemożliwić dostęp do bazy danych
  • Pełna kontrola nad cyklem życia klucza, w tym rotacją klucza w celu dostosowania do zasad firmy
  • Centralne zarządzanie i organizacja kluczy w usłudze Azure Key Vault lub zarządzanym module HSM
  • Możliwość wdrożenia separacji obowiązków między funkcjonariuszami ochrony, administratorami bazy danych i administratorami systemu

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

Tożsamości zarządzane w usłudze Microsoft Entra ID zapewniają usługom platformy Azure alternatywę do przechowywania poświadczeń w kodzie przez aprowizowanie automatycznie przypisanej tożsamości, która może służyć do uwierzytelniania w dowolnej usłudze obsługującej uwierzytelnianie w usłudze Microsoft Entra, takiej jak Azure Key Vault (AKV). Usługa Azure Database for MySQL obecnie obsługuje tylko tożsamość zarządzaną przypisaną przez użytkownika (UMI). Aby uzyskać więcej informacji, zobacz Typy tożsamości zarządzanych na platformie Azure.

Aby skonfigurować klucz zarządzany przez klienta (CMK) dla Azure Database for MySQL, należy połączyć Użytkownika zarządzającego (UMI) z serwerem i określić magazyn kluczy Azure Key Vault oraz klucz do użycia.

Interfejs użytkownika musi mieć następujący dostęp do magazynu kluczy:

  • Get: służy do pobrania części publicznej i właściwości klucza w magazynie kluczy.
  • Lista wersji: Wymień wersje klucza przechowywanego w usłudze Key Vault.
  • Zawijanie klucza: aby można było zaszyfrować klucz szyfrowania danych. Zaszyfrowany klucz szyfrowania danych jest przechowywany w wystąpieniu serwera elastycznego usługi Azure Database for MySQL.
  • Odpakuj klucz: aby można było odszyfrować DEK. Usługa Azure Database for MySQL wymaga odszyfrowanego klucza (DEK) do szyfrowania/odszyfrowania danych.

Jeśli kontrola dostępu oparta na rolach jest włączona, należy również przypisać następującą rolę:

  • Użytkownik szyfrowania usługi Kryptograficznej usługi Key Vault lub rola z uprawnieniami:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/rozpakowanie/akcja
    • Microsoft.KeyVault/vaults/keys/read jak "Użytkownik szyfrowania usługi Kryptograficznej usługi Key Vault"
  • W przypadku zarządzanego modułu HSM przypisz rolę użytkownika zarządzanego szyfrowania usługi kryptograficznej HSM

Terminologia i opis

Klucz szyfrowania danych (DEK): symetryczny klucz AES256 używany do szyfrowania partycji lub bloku danych. Szyfrowanie każdego bloku danych przy użyciu innego klucza sprawia, że ataki analizy kryptograficznej są trudniejsze. Dostęp do zestawów SZYFROWANIA jest wymagany przez dostawcę zasobów lub wystąpienie aplikacji, które szyfruje i odszyfrowuje określony blok. 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 DES. 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 być inna niż jednostka, która wymaga klucza szyfrowania danych. Ponieważ klucz KEK jest wymagany do odszyfrowywania kluczy szyfrowania, klucz KEK jest skutecznie pojedynczym punktem, za pomocą którego można skutecznie usuwać elementy SZYFROWANIA przez usunięcie klucza szyfrowania kluczy. Zestawy SZYFROWANIA szyfrowane przy użyciu zestawów KEK są przechowywane oddzielnie. Tylko jednostka z dostępem do klucza KEK może odszyfrować te klucze SZYFROWANIA. Aby uzyskać więcej informacji, zobacz Zabezpieczenia szyfrowania danych w stanie spoczynku.

Jak to działa

Szyfrowanie danych za pomocą zestawów CMKs jest ustawione na poziomie serwera. W przypadku danego serwera klucz cmK nazywany kluczem 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. Usługa Key Vault to bezpieczny, wysoce dostępny i skalowalny magazyn dla kluczy kryptograficznych RSA, opcjonalnie wspierany przez sprzętowe moduły zabezpieczeń (HSM) walidowane przez standard FIPS 140. Usługa Key Vault nie zezwala na bezpośredni dostęp do przechowywanego klucza, ale zamiast tego zapewnia usługi szyfrowania/odszyfrowywania przy użyciu klucza do autoryzowanych jednostek. Zaimportowany magazyn kluczy może wygenerować klucz lub przenieść go do magazynu kluczy z lokalnego urządzenia HSM.

Podczas konfigurowania serwera elastycznego do używania klucza zarządzanego przez klienta przechowywanego w magazynie kluczy serwer wysyła klucz szyfrowania do magazynu kluczy na potrzeby szyfrowania. Usługa Key Vault zwraca zaszyfrowany klucz szyfrowania danych przechowywany w bazie danych użytkownika. Podobnie serwer elastyczny wysyła chroniony klucz szyfrowania danych (DEK) do magazynu kluczy w celu odszyfrowania w razie potrzeby.

Diagram przedstawiający sposób działania szyfrowania danych przy użyciu klucza zarządzanego przez klienta.

Po włączeniu rejestrowania audytorzy mogą przeglądać dzienniki zdarzeń inspekcji usługi Key Vault za pomocą usługi Azure Monitor. Aby włączyć rejestrowanie zdarzeń inspekcji usługi Key Vault, zobacz Monitorowanie usługi Key Vault za pomocą szczegółowych informacji usługi Key Vault.

Uwaga

Zmiany uprawnień mogą potrwać do 10 minut, aby wpłynąć na magazyn kluczy. Obejmuje to odwołanie uprawnień dostępu do funkcji ochrony TDE w usłudze AKV, a użytkownicy w tym przedziale czasu mogą nadal mieć uprawnienia dostępu.

Wymagania dotyczące konfigurowania szyfrowania danych dla usługi Azure Database for MySQL

Przed podjęciem próby skonfigurowania usługi Key Vault lub zarządzanego modułu HSM należy spełnić następujące wymagania.

  • Wystąpienie serwera elastycznego usługi Key Vault i usługi Azure Database for MySQL musi należeć do tej samej dzierżawy firmy Microsoft Entra. Interakcja między dzierżawami usługi Key Vault i elastycznych serwerów musi być obsługiwana. W przypadku przenoszenia zasobów usługi Key Vault po wykonaniu konfiguracji należy ponownie skonfigurować szyfrowanie danych.
  • Wystąpienie serwera elastycznego usługi Key Vault i usługi Azure Database for MySQL musi znajdować się w tym samym regionie.
  • Włącz funkcję miękkiego usuwania w usłudze Key Vault z okresem przechowywania ustawionym na 90 dni, aby chronić przed utratą danych, jeśli dojdzie do przypadkowego usunięcia klucza (lub samego Key Vault). Akcje odzyskiwania i przeczyszczania mają własne uprawnienia w zasadach dostępu usługi Key Vault. Funkcja miękkiego usuwania jest domyślnie wyłączona, ale można ją włączyć za pośrednictwem portalu Azure lub przy użyciu PowerShell lub interfejsu wiersza polecenia Azure.
  • Włącz funkcję Ochrona przed usunięciem w magazynie kluczy i ustaw okres przechowywania na 90 dni. Gdy ochrona przed przeczyszczeniem jest włączona, magazyn lub obiekt w stanie usuniętym nie może zostać przeczyszczone do momentu upływu okresu przechowywania. Tę funkcję można włączyć przy użyciu programu PowerShell lub interfejsu wiersza polecenia platformy Azure i dopiero po włączeniu usuwania nietrwałego.

Przed podjęciem próby skonfigurowania klucza zarządzanego przez klienta upewnij się, że spełnisz następujące wymagania.

  • Klucz zarządzany przez klienta do szyfrowania klucza szyfrowania może być tylko asymetryczny, RSA\RSA-HSM(magazyny z jednostkami SKU w warstwie Premium) 2048 3072 lub 4096.
  • Data aktywacji klucza (jeśli ustawiona) musi być datą i godziną w przeszłości. Data wygaśnięcia nie jest ustawiona.
  • Klucz musi być w stanie Włączone .
  • Klucz musi mieć miękkie usuwanie z okresem przechowywania na 90 dni. Spowoduje to niejawne ustawienie wymaganego atrybutu klucza RecoveryLevel: "Możliwe do odzyskania".
  • Klucz musi mieć włączoną ochronę przed usuwaniem.
  • Jeśli importujesz istniejący klucz do magazynu kluczy, upewnij się, że został on w obsługiwanych formatach plików (.pfx, .byok, .backup).

Uwaga

Aby uzyskać szczegółowe instrukcje krok po kroku dotyczące konfigurowania szyfrowania dat dla usługi Azure Database for MySQL za pośrednictwem witryny Azure Portal, zobacz Szyfrowanie danych dla usługi Azure Database for MySQL — serwer elastyczny przy użyciu witryny Azure Portal.

Zalecenia dotyczące konfigurowania szyfrowania danych

Podczas konfigurowania usługi Key Vault lub zarządzanego modułu HSM do używania szyfrowania danych przy użyciu klucza zarządzanego przez klienta należy pamiętać o poniższych zaleceniach.

  • 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ń. Azure Monitor Log Analytics to jeden z przykładów usługi, która jest już zintegrowana.
  • 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. Aby uzyskać więcej informacji na temat polecenia tworzenia kopii zapasowej, zobacz Backup-AzKeyVaultKey.

Uwaga

Zaleca się, aby magazyn kluczy był używany z tego samego regionu, ale w razie potrzeby można użyć magazynu kluczy z innego regionu, określając informacje "wprowadź identyfikator klucza". Zarządzany moduł HSM magazynu kluczy musi znajdować się w tym samym regionie co serwer elastyczny MySQL.

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 elastyczny 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 elastyczny wystawia odpowiedni komunikat o błędzie i zmienia stan serwera na Niedostępny. Serwer może osiągnąć ten stan z różnych powodów.

  • Jeśli usuniesz Key Vault, instancja elastycznego serwera Azure Database for MySQL traci dostęp do klucza, a jej status przechodzi w stan Niedostępny. Odzyskaj magazyn kluczy i ponownie potwierdź szyfrowanie danych, aby elastyczne wystąpienie serwera w usłudze Azure Database dla MySQL było dostępne.
  • Jeśli usuniesz klucz z magazynu kluczy, instancja elastycznego serwera bazy danych Azure Database for MySQL nie będzie mogła uzyskać dostępu do klucza i przejdzie do stanu Niedostępny. Odzyskaj klucz i ponownie potwierdź szyfrowanie danych, aby wystąpienie elastycznego serwera usługi Azure Database for MySQL było dostępne.
  • Jeśli klucz przechowywany w usłudze Azure Key Vault wygaśnie, utraci ważność, a instancja elastycznego serwera usługi Azure Database for MySQL przejdzie w stan Niedostępny. Przedłuż datę wygaśnięcia klucza przy użyciu interfejsu wiersza polecenia, a następnie ponownie zatwierdź szyfrowanie danych, aby wystąpienie elastycznego serwera usługi Azure Database for MySQL było dostępne.

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

Może się zdarzyć, że ktoś, kto ma wystarczające uprawnienia dostępu do usługi Key Vault, przypadkowo wyłączy elastyczny dostęp serwera do klucza przez:

  • Odwoływania uprawnień do pobierania, wyświetlania listy, zawijania klucza i rozpakuj klucz z serwera
  • Usuwanie klucza
  • Usuwanie magazynu kluczy
  • Zmienianie reguł zapory magazynu kluczy
  • Usuwanie tożsamości zarządzanej użytkownika używanej do szyfrowania na serwerze elastycznym przy użyciu klucza zarządzanego przez klienta 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 funkcji ochrony przezroczystego szyfrowania danych, skonfiguruj następujące funkcje platformy Azure:

  • Dziennik aktywności: w przypadku niepowodzenia dostępu do klucza klienta w zarządzanym przez klienta usłudze Key Vault wpisy są dodawane do dziennika aktywności. Dostęp można przywrócić tak szybko, jak to możliwe, jeśli utworzysz alerty dla tych zdarzeń.
  • Grupy akcji: zdefiniuj te grupy, aby wysyłać powiadomienia i alerty na podstawie preferencji.

Replika z kluczem zarządzanym przez klienta w usłudze Key Vault

Gdy wystąpienie serwera elastycznego usługi Azure Database for MySQL jest szyfrowane przy użyciu klucza zarządzanego klienta przechowywanego w usłudze Key Vault, każda nowo utworzona kopia serwera jest również szyfrowana. Podczas próby zaszyfrowania wystąpienia serwera elastycznego Azure Database for MySQL przy użyciu klucza zarządzanego przez klienta, który ma już replikę, zalecamy skonfigurowanie jednej lub więcej replik poprzez dodanie tożsamości zarządzanej i klucza. Załóżmy, że wystąpienie serwera elastycznego usługi Azure Database for MySQL jest skonfigurowane z kopią zapasową nadmiarowości geograficznej. W takim przypadku replika musi być skonfigurowana przy użyciu tożsamości zarządzanej i klucza, do którego tożsamość ma dostęp i który znajduje się w sparowanym geograficznie regionie serwera.

Przywracanie przy użyciu klucza zarządzanego przez klienta w usłudze Key Vault

Podczas próby przywrócenia wystąpienia serwera elastycznego usługi Azure Database for MySQL można wybrać tożsamość zarządzaną przez użytkownika i klucz, aby zaszyfrować serwer przywracania. Załóżmy, że wystąpienie serwera elastycznego usługi Azure Database for MySQL jest skonfigurowane z kopią zapasową nadmiarowości geograficznej. W takim przypadku należy skonfigurować serwer przywracania przy użyciu tożsamości zarządzanej i klucza, do którego tożsamość ma dostęp i który znajduje się w sparowanym geograficznie regionie serwera.

Aby uniknąć problemów podczas konfigurowania szyfrowania danych zarządzanych przez klienta podczas przywracania lub tworzenia repliki do odczytu, należy wykonać następujące kroki na serwerach źródłowych i przywróconych/replikach:

  • Zainicjuj proces tworzenia przywracania lub repliki do odczytu ze źródłowego wystąpienia serwera elastycznego usługi Azure Database for MySQL.
  • Na przywróconym/replikowym serwerze ponownie zweryfikuj klucz zarządzany przez klienta w ustawieniach szyfrowania danych, aby upewnić się, że tożsamość zarządzana przez użytkownika ma uprawnienia Get, List, Wrap key i Unwrap key do klucza przechowywanego w Key Vault.

Uwaga

Używanie tej samej tożsamości i klucza co na serwerze źródłowym nie jest obowiązkowe podczas wykonywania przywracania.

Powiązana zawartość