Szyfrowanie danych usługi Azure Database for MySQL przy użyciu klucza zarządzanego przez klienta

DOTYCZY: Azure Database for MySQL — pojedynczy serwer

Ważne

Pojedynczy serwer usługi Azure Database for MySQL znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do serwera elastycznego usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do serwera elastycznego usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MySQL — pojedynczy serwer?

Szyfrowanie danych za pomocą kluczy zarządzanych przez klienta w usłudze Azure Database for MySQL umożliwia korzystanie z własnego klucza (Bring Your Own Key, BYOK) na potrzeby ochrony danych w spoczynku. Umożliwia to również organizacjom rozdzielanie obowiązków związanych z zarządzaniem kluczami i danymi. W przypadku szyfrowania zarządzanego przez klienta odpowiadasz za cykl życia klucza, uprawnienia do użycia klucza i inspekcję operacji na kluczach.

Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL jest ustawiane na poziomie serwera. W przypadku danego serwera klucz zarządzany przez klienta nazywany kluczem szyfrowania klucza (KEK) jest używany do szyfrowania klucza szyfrowania danych (DEK) używanego przez usługę. Klucz KEK jest kluczem asymetrycznym przechowywanym w wystąpieniu usługi Azure Key Vault należącym do klienta i zarządzanym przez klienta. Klucz szyfrowania kluczy (KEK) i klucz szyfrowania danych (DEK) opisano bardziej szczegółowo w dalszej części tego artykułu.

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.

Uwaga

Ta funkcja jest obsługiwana tylko w przypadku magazynu ogólnego przeznaczenia w wersji 2 (obsługa do 16 TB)" dostępnego w warstwach cenowych Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci. Aby uzyskać więcej informacji, zapoznaj się z tematem Pojęcia dotyczące magazynu. Aby zapoznać się z innymi ograniczeniami, zapoznaj się z sekcją dotyczącą ograniczeń .

Świadczenia

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

  • Dostęp do danych jest w pełni kontrolowany przez użytkownika przez możliwość usunięcia klucza i niedostępnego 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
  • Możliwość wdrożenia separacji obowiązków między funkcjonariuszami ochrony a administratorami systemu i administratorami systemu

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 usługi DEKs 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 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 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 usunąć szyfrowania kluczy sieciowych 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 w szyfrowaniu magazynowanych.

Jak działa szyfrowanie danych przy użyciu klucza zarządzanego przez klienta

Diagram that shows an overview of Bring Your Own Key

Aby serwer MySQL używał kluczy zarządzanych przez klienta przechowywanych w usłudze Key Vault na potrzeby szyfrowania klucza szyfrowania kluczy, administrator usługi Key Vault zapewnia następujące prawa dostępu do serwera:

  • get: Aby pobrać część publiczną i właściwości klucza w magazynie kluczy.
  • wrapKey: aby można było zaszyfrować klucz szyfrowania danych. Zaszyfrowany klucz szyfrowania danych jest przechowywany w usłudze Azure Database for MySQL.
  • unwrapKey: aby móc odszyfrować klucz szyfrowania danych. Usługa Azure Database for MySQL wymaga odszyfrowanego klucza szyfrowania danych w celu szyfrowania/odszyfrowania danych

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

Gdy serwer jest skonfigurowany 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, który jest przechowywany w bazie danych użytkownika. Podobnie, w razie potrzeby serwer wysyła chroniony klucz szyfrowania danych do magazynu kluczy na potrzeby 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 usługi Azure Database for MySQL

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

  • Usługi Key Vault i Azure Database for MySQL 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.
  • Włącz funkcję usuwania nietrwałego w magazynie kluczy z okresem przechowywania ustawionym na 90 dni, aby chronić przed utratą danych w przypadku przypadkowego usunięcia klucza (lub usługi Key Vault). Zasoby usunięte nietrwale są domyślnie przechowywane przez 90 dni, chyba że okres przechowywania jest jawnie ustawiony na <=90 dni. 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 (pamiętaj, że nie można go włączyć za pośrednictwem witryny Azure Portal).
  • Włącz funkcję przeczyszczania ochrony w magazynie kluczy z okresem przechowywania ustawionym na 90 dni. Ochronę przeczyszczania można włączyć tylko po włączeniu usuwania nietrwałego. Można ją włączyć za pomocą interfejsu wiersza polecenia platformy Azure lub programu PowerShell. Jeśli ochrona przed przeczyszczeniem jest włączona, magazyn lub obiekt w stanie usuniętym nie może zostać przeczyszczone do momentu, gdy okres przechowywania nie zostanie przekazany. Magazyny i obiekty usunięte nietrwale mogą być nadal odzyskiwane, dzięki czemu będą przestrzegane zasady przechowywania.
  • Udziel usłudze Azure Database for MySQL dostępu do magazynu kluczy przy użyciu uprawnień get, wrapKey i unwrapKey przy użyciu unikatowej tożsamości zarządzanej. W witrynie Azure Portal unikatowa tożsamość "Usługa" jest tworzona automatycznie po włączeniu szyfrowania danych w programie MySQL. Zobacz Konfigurowanie szyfrowania danych dla programu MySQL , aby uzyskać szczegółowe instrukcje krok po kroku podczas korzystania z witryny Azure Portal.

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

  • Klucz zarządzany przez klienta do szyfrowania klucza szyfrowania może być tylko asymetryczny, RSA 2048.
  • 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ć usuwanie nietrwałe z okresem przechowywania ustawionym na 90 dni. Spowoduje to niejawne ustawienie wymaganego atrybutu klucza RecoveryLevel: "Recoverable". Jeśli okres przechowywania jest ustawiony na < 90 dni, wartość recoveryLevel: "CustomizedRecoverable", która nie jest wymagana, dlatego upewnij się, że dla ustawienia okresu przechowywania ustawiono wartość 90 dni.
  • Klucz musi mieć włączoną ochronę przed przeczyszczaniem.
  • Jeśli importujesz istniejący klucz do magazynu kluczy, upewnij się, że został on w obsługiwanych formatach plików (.pfx, .byok, .backup).

Zalecenia

Jeśli używasz szyfrowania danych przy użyciu klucza zarządzanego przez klienta, 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ń. Azure Monitor Log Analytics to jeden z przykładów usługi, która jest już zintegrowana.

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

  • Zablokuj usługę Azure KeyVault tylko do prywatnego punktu końcowego i wybranych sieci oraz zezwól tylko zaufanym usługom firmy Microsoft na zabezpieczanie zasobów.

    trusted-service-with-AKV

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

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

Niedostępny warunek klucza zarządzanego przez klienta

Podczas konfigurowania szyfrowania danych przy użyciu 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 wystawia odpowiedni komunikat o błędzie i zmienia stan serwera na Niedostępny. Oto niektóre przyczyny, dla których serwer może osiągnąć ten stan:

  • Jeśli utworzymy serwer przywracania do punktu w czasie dla usługi Azure Database for MySQL z włączonym szyfrowaniem danych, nowo utworzony serwer będzie w stanie Niedostępny . Ten problem można rozwiązać za pośrednictwem Azure Portal lub interfejsu poziomu wywołania.
  • Jeśli utworzymy replikę do odczytu dla usługi Azure Database for MySQL, która ma włączone szyfrowanie danych, serwer repliki będzie w stanie Niedostępny . Ten problem można rozwiązać za pośrednictwem Azure Portal lub interfejsu poziomu wywołania.
  • Jeśli usuniesz usługę KeyVault, usługa Azure Database for MySQL nie będzie mogła uzyskać dostępu do klucza i przejdzie do stanu Niedostępny . Odzyskaj usługę Key Vault i zrewiduj szyfrowanie danych, aby udostępnić serwer.
  • Jeśli usuniemy klucz z usługi KeyVault, usługa Azure Database for MySQL nie będzie mogła uzyskać dostępu do klucza i przejdzie do stanu Niedostępny . Odzyskaj klucz i zrewiduj szyfrowanie danych, aby udostępnić serwer.
  • Jeśli klucz przechowywany w usłudze Azure KeyVault wygaśnie, klucz stanie się nieprawidłowy, a usługa Azure Database for MySQL przejdzie do stanu Niedostępny . Rozszerz datę wygaśnięcia klucza przy użyciu interfejsu wiersza polecenia, a następnie zrewiduj szyfrowanie danych, aby udostępnić serwer.

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 dostęp serwera do klucza przez:

  • Odwołując uprawnienia , wrapKeyi unwrapKey magazynu getkluczy z serwera.
  • Usuwanie klucza.
  • Usunięcie magazynu kluczy.
  • Zmiana reguł zapory magazynu kluczy.
  • 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 funkcji ochrony przezroczystego szyfrowania danych, skonfiguruj następujące funkcje platformy Azure:

  • Azure Resource Health: niedostępna baza danych, która utraciła dostęp do klucza klienta, jest wyświetlana jako "Niedostępna" po odmowie pierwszego połączenia z bazą danych.

  • Dziennik aktywności: gdy dostęp do klucza klienta w zarządzanym przez klienta usłudze Key Vault kończy się niepowodzeniem, 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.

Przywracanie i replikowanie za pomocą klucza zarządzanego klienta w usłudze Key Vault

Po zaszyfrowaniu usługi Azure Database for MySQL 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 lokalnego lub geograficznego albo za pomocą replik do odczytu. Można jednak zmienić kopię, aby odzwierciedlić klucz zarządzany nowego klienta na potrzeby szyfrowania. Po zmianie klucza zarządzanego przez klienta stare kopie zapasowe serwera zaczynają używać najnowszego klucza.

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łowej usługi Azure Database for MySQL.
  • Zachowaj nowo utworzony serwer (przywrócony/replika) w stanie niedostępnym, ponieważ jego unikatowa tożsamość nie otrzymała jeszcze uprawnień do usługi Key Vault.
  • Na przywróconym/replikowym serwerze zrewiduj klucz zarządzany przez klienta w ustawieniach szyfrowania danych, aby zagwarantować, że nowo utworzony serwer zostanie przekazany i odpakuj uprawnienia do klucza przechowywanego w usłudze Key Vault.

Ograniczenia

W przypadku usługi Azure Database for MySQL obsługa szyfrowania danych magazynowanych przy użyciu klucza zarządzanego przez klientów (CMK) ma kilka ograniczeń —

  • Obsługa tej funkcji jest ograniczona do warstw cenowych Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci.

  • Ta funkcja jest obsługiwana tylko w regionach i serwerach, które obsługują magazyn ogólnego przeznaczenia w wersji 2 (do 16 TB). Aby uzyskać listę regionów świadczenia usługi Azure obsługujących magazyn do 16 TB, zapoznaj się z sekcją magazynu w dokumentacji tutaj

    Uwaga

    • Wszystkie nowe serwery MySQL utworzone w regionach świadczenia usługi Azure obsługują magazyn ogólnego przeznaczenia w wersji 2, obsługa szyfrowania przy użyciu kluczy menedżera klienta jest dostępna. Serwer przywrócony do punktu w czasie (PITR) lub replika do odczytu nie kwalifikują się, choć teoretycznie są one "nowe".
    • Aby sprawdzić, czy aprowizowany magazyn ogólnego przeznaczenia serwera w wersji 2 można przejść do bloku warstwy cenowej w portalu i wyświetlić maksymalny rozmiar magazynu obsługiwany przez aprowizowany serwer. Jeśli możesz przesunąć suwak do 4 TB, serwer znajduje się w magazynie ogólnego przeznaczenia w wersji 1 i nie będzie obsługiwał szyfrowania za pomocą kluczy zarządzanych przez klienta. Jednak dane są szyfrowane przy użyciu kluczy zarządzanych przez usługę przez cały czas. Skontaktuj się z tobą, AskAzureDBforMySQL@service.microsoft.com jeśli masz jakiekolwiek pytania.
  • Szyfrowanie jest obsługiwane tylko w przypadku klucza kryptograficznego RSA 2048.

Następne kroki