Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL — serwer elastyczny
DOTYCZY: 
Azure Database for MySQL — serwer elastyczny
Dzięki szyfrowaniu danych za pomocą kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL — elastyczny serwer, możesz stosować własny klucz (BYOK) na potrzeby ochrony danych magazynowanych i implementować 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 dla kluczy zarządzanych przez klienta dla serwera elastycznego usługi Azure Database for MySQL.
Świadczenia
Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta dla usługi Azure Database for MySQL — serwer elastyczny 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 — elastyczny serwer 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 cmK dla serwera elastycznego usługi Azure Database for MySQL, należy połączyć interfejs użytkownika z serwerem i określić magazyn kluczy i klucz usługi Azure Key Vault do użycia.
Interfejs użytkownika musi mieć następujący dostęp do magazynu kluczy:
- Get: aby pobrać część publiczną i właściwości klucza w magazynie kluczy.
- Lista: lista wersji 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ć klucz szyfrowania danych. Usługa Azure Database for MySQL — elastyczny serwer wymaga odszyfrowanego klucza szyfrowania danych w celu 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/unwrap/action
- 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 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 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 w spoczynku szyfrowania.
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 jest wysoce dostępnym i skalowalnym bezpiecznym magazynem dla kluczy kryptograficznych RSA, opcjonalnie wspieranym przez zweryfikowane sprzętowe moduły zabezpieczeń (HSM) ze zweryfikowaną standardem 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 wyśle chroniony klucz szyfrowania szyfrowania danych do magazynu kluczy w celu odszyfrowywania w razie potrzeby.
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łowanie 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 — serwer elastyczny
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 usługi Key Vault i usługi Azure Database for MySQL — serwer elastyczny 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 usługi Key Vault i usługi Azure Database for MySQL — serwer elastyczny musi znajdować się w tym samym regionie.
- Włącz funkcję usuwania nietrwałego w magazynie kluczy z okresem przechowywania ustawionym na 90 dni, aby chronić przed utratą danych, jeśli wystąpi przypadkowe usunięcie klucza (lub usługi Key Vault). Akcje odzyskiwania i przeczyszczania mają własne uprawnienia w zasadach dostępu usługi Key Vault. Funkcja usuwania nietrwałego jest domyślnie wyłączona, ale można ją włączyć za pośrednictwem witryny Azure Portal lub za pomocą programu PowerShell lub interfejsu wiersza polecenia platformy Azure.
- Włącz funkcję przeczyszczania ochrony 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ć usuwanie nietrwałe z okresem przechowywania ustawionym na 90 dni. Spowoduje to niejawne ustawienie wymaganego atrybutu klucza RecoveryLevel: "Możliwe do odzyskania".
- Klucz musi mieć włączoną ochronę przed przeczyszczaniem.
- Jeśli importujesz istniejący klucz do magazynu kluczy, upewnij się, że jest 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 serwera elastycznego usługi Azure Database for MySQL za pośrednictwem witryny Azure Portal, zobacz Konfigurowanie szyfrowania danych dla usługi Azure Database for MySQL — elastyczny serwer.
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ę użycie magazynu kluczy 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 magazyn kluczy, wystąpienie serwera elastycznego usługi Azure Database for MySQL nie będzie mogło uzyskać dostępu do klucza i przejdzie do stanu Niedostępny . Odzyskiwanie magazynu kluczy i ponowne aktywowanie szyfrowania danych w celu udostępnienia wystąpienia serwera elastycznego usługi Azure Database for MySQL.
- Jeśli usuniesz klucz z magazynu kluczy, wystąpienie serwera elastycznego usługi Azure Database for MySQL nie będzie mogło uzyskać dostępu do klucza i przejdzie do stanu Niedostępny . Odzyskiwanie klucza i ponowne aktywowanie szyfrowania danych w celu udostępnienia wystąpienia serwera elastycznego usługi Azure Database for MySQL.
- Jeśli klucz przechowywany w usłudze Azure Key Vault wygaśnie, klucz stanie się nieprawidłowy, a wystąpienie serwera elastycznego usługi Azure Database for MySQL przejdzie w stan Niedostępny . Rozszerz datę wygaśnięcia klucza przy użyciu interfejsu wiersza polecenia, a następnie zrewiduj szyfrowanie danych, aby udostępnić wystąpienie serwera elastycznego usługi Azure Database for MySQL.
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łowywanie uprawnień pobierania, wyświetlania listy, zawijania klucza i odpakowywania klucza 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
Po zaszyfrowaniu wystąpienia serwera elastycznego 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. Podczas próby zaszyfrowania wystąpienia serwera elastycznego usługi Azure Database for MySQL przy użyciu klucza zarządzanego przez klienta, który ma już repliki, zalecamy skonfigurowanie replik przez 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 zrewiduj 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 usłudze 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.