Udostępnij przez

Rozwiązywanie problemów z szyfrowaniem danych za pomocą klucza zarządzanego przez klienta (CMK) w usłudze Azure DocumentDB

Ten przewodnik jest przeznaczony do rozwiązywania typowych problemów podczas korzystania z klucza zarządzanego przez klienta (CMK) do szyfrowania danych w stanie spoczynku za pomocą usługi Azure DocumentDB. Oferuje praktyczne rozwiązania do rozwiązywania problemów z różnymi składnikami uczestniczyć w konfiguracji klucza zarządzanego przez klienta.

Tożsamość zarządzana, magazyn kluczy, klucz szyfrowania w magazynie kluczy i odpowiednie uprawnienia przyznane tożsamości zarządzanej są wymagane do skonfigurowania klucza szyfrowania zarządzanego przez klienta (CMK) w klastrze usługi Azure DocumentDB.

Jeśli tożsamość zarządzana, magazyn kluczy, klucz lub uprawnienia i nie są konfigurowane zgodnie z wymaganiami, podczas aprowizacji klastra może nie być możliwe włączenie klucza zarządzanego. Jeśli właściwa konfiguracja stanie się nieprawidłowa w klastrze z obsługą klucza zarządzanego przez klienta, dane w tym klastrze staną się niedostępne ze względu na podstawowe wymaganie zabezpieczeń szyfrowania za pomocą klucza zarządzanego przez klienta.

Wykonaj kroki opisane w tej sekcji, aby rozwiązać problemy ze wszystkimi składnikami wymaganymi do prawidłowej konfiguracji klucza zarządzanego przez klienta.

Przyczyny odwołania dostępu klucza z usługi Azure Key Vault

Ktoś, kto ma wystarczające prawa dostępu do usługi Key Vault, może przypadkowo wyłączyć dostęp klastra do klucza przez:

  • Cofanie przypisania roli RBAC użytkownika szyfrowania usługi kryptograficznej usługi Kryptograficznej usługi Key Vault lub cofnięcie uprawnień z tożsamości użytej do pobrania klucza w usłudze Key Vault.
  • Usuwanie klucza.
  • Usuwanie wystąpienia usługi Key Vault.
  • Zmiana reguł zapory usługi Key Vault lub błędne skonfigurowanie ustawień sieci usługi Key Vault.
  • Usuwanie tożsamości zarządzanej klastra w identyfikatorze Entra firmy Microsoft.

Te akcje powodują, że klucz zarządzany przez klienta używany do szyfrowania danych staje się niedostępny.

Rozwiązywanie problemów z niedostępnym warunkiem klucza zarządzanego przez klienta

Podczas konfigurowania szyfrowania danych przy użyciu klucza zarządzanego przez klienta przechowywanego w magazynie kluczy wymagany jest ciągły dostęp do tego klucza, aby klaster pozostał w trybie online. Jeśli tak nie jest, klaster zmieni jego stan na Niedostępny i rozpocznie odmawianie wszystkich połączeń.

Niektóre z możliwych powodów, dla których stan klastra może stać się niedostępny :

Przyczyna Rezolucja
Klucz szyfrowania wskazywany przez klaster miał skonfigurowaną datę i godzinę wygaśnięcia oraz datę i godzinę. Należy przedłużyć datę wygaśnięcia klucza. Następnie musisz poczekać, aż usługa zmieni klucz i automatycznie przeniesie stan klastra do gotowego. Tylko wtedy, gdy klaster powróci do stanu Gotowe , można obrócić klucz do nowszej wersji lub utworzyć nowy klucz, a następnie zaktualizować klaster tak, aby odwołył się do tej nowej wersji tego samego klucza lub do nowego klucza.
Usunięcie wystąpienia usługi Key Vault powoduje, że wystąpienie usługi Azure DocumentDB nie może uzyskać dostępu do klucza i przechodzi do stanu Niedostępny. Odzyskaj wystąpienie usługi Key Vault i poczekaj na okresowe ponowne uruchomienie klucza przez usługę i automatycznie przełącz stan klastra na Gotowe.
Usuwasz tożsamość zarządzaną , która jest używana do pobierania dowolnego z kluczy szyfrowania przechowywanych w magazynie kluczy, z identyfikatora Entra firmy Microsoft. Odzyskaj tożsamość i poczekaj na okresowe ponowne uruchomienie klucza przez usługę, a następnie automatycznie przełącz stan klastra na Gotowe.
Model uprawnień magazynu kluczy jest skonfigurowany do używania kontroli dostępu opartej na rolach. Usuwasz przypisanie roli RBAC użytkownika Key Vault Crypto Service Encryption User z tożsamości zarządzanych, które są skonfigurowane do pobierania kluczy. Ponownie przyznaj rolę RBAC tożsamości zarządzanej i poczekaj, aż usługa będzie uruchamiać okresową ponowną zmianę klucza, a następnie automatycznie przełącz stan klastra na Gotowe. Alternatywnie możesz przyznać rolę w magazynie kluczy innej tożsamości zarządzanej i zaktualizować klaster, tak aby korzystała z tej innej tożsamości zarządzanej w celu uzyskania dostępu do klucza.
Model uprawnień magazynu kluczy jest skonfigurowany do używania zasad dostępu. Odwołujesz polityki dostępu listy, pobierania, zawijania lub odpakowania kluczy do tożsamości zarządzanych, które są skonfigurowane do pobierania dowolnego z kluczy. Udziel roli RBAC tożsamości zarządzanej i poczekaj na okresowe ponowne uruchomienie klucza przez usługę, a następnie automatycznie przełącz stan klastra na Gotowe. Alternatywnie można przyznać wymagane zasady dostępu w magazynie kluczy do innej tożsamości zarządzanej i zaktualizować klaster, aby korzystał z tej innej tożsamości zarządzanej w celu uzyskania dostępu do klucza.
Skonfigurowano zbyt restrykcyjne reguły zapory magazynu kluczy, aby klaster usługi Azure DocumentDB nie mógł komunikować się z magazynem kluczy w celu pobrania kluczy. Podczas konfigurowania zapory magazynu kluczy upewnij się, że wyłączysz dostęp publiczny i wybrano opcję zezwalania na zaufane usługi firmy Microsoft lub dozwolony dostęp publiczny ze wszystkich sieci. Dzięki dostępowi publicznemu ze wszystkich sieci klaster usługi Azure DocumentDB może uzyskać dostęp do magazynu kluczy. Po wyłączeniu dostępu publicznego i opcji zezwalania zaufanym usługom firmy Microsoft na dostęp do wartości klucza klaster może pominąć zaporę.

Uwaga / Notatka

Gdy klucz jest wyłączony, usunięty, wygasł lub nieosiągalny, klaster, który ma dane zaszyfrowane za pomocą tego klucza, staje się niedostępny zgodnie z wcześniejszym opisem. Stan klastra nie zmienia się na Gotowe ponownie, dopóki nie będzie mógł ponownie zmienić klucza szyfrowania.

Ogólnie rzecz biorąc, klaster staje się niedostępny w ciągu 60 minut po wyłączeniu klucza, usunięciu, wygaśnięciu lub nieosiągalnym. Po udostępnieniu klucza klaster może potrwać do 60 minut, aby ponownie stać się Gotowy .

Odzyskiwanie tożsamości zarządzanej po jej usunięciu

Jeśli tożsamość zarządzana przypisana przez użytkownika używana do uzyskiwania dostępu do klucza szyfrowania przechowywanego w magazynie kluczy zostanie usunięta w usłudze Microsoft Entra ID, wykonaj następujące kroki, aby odzyskać:

  1. Odzyskaj tożsamość lub utwórz nową tożsamość zarządzanego identyfikatora entra.
  2. Jeśli utworzono nową tożsamość, nawet jeśli ma taką samą nazwę jak usunięta, zaktualizuj usługę Azure Database dla elastycznych właściwości klastra, aby wiedziała, że musi używać tej nowej tożsamości w celu uzyskania dostępu do klucza szyfrowania.
  3. Upewnij się, że ta tożsamość ma odpowiednie uprawnienia do operacji na kluczu w usłudze Azure Key Vault (AKV).
  4. Poczekaj około godziny, aż klaster ponownie zwaliduje klucz.

Ważne

Tworzenie nowej tożsamości identyfikatora Entra o tej samej nazwie co usunięta tożsamość nie jest odzyskiwane po usunięciu tożsamości zarządzanej.

Rozwiązywanie problemów z nieudaną aprowizowaniem klastra z włączoną obsługą klucza zarządzanego przez klienta

Jeśli którekolwiek z wymagań dotyczących klucza zarządzanego przez klienta nie zostanie spełnione, próba aprowizacji klastra z włączonym kluczem cmK zakończy się niepowodzeniem. Następujący błąd podczas aprowizacji klastra wskazuje, że magazyn kluczy, klucz szyfrowania lub uprawnienia tożsamości zarządzanej nie zostały prawidłowo skonfigurowane: "Nie można uzyskać dostępu do klucza. Może brakować podanej tożsamości użytkownika, która nie ma uprawnień GET, lub magazyn kluczy nie włączył dostępu do publicznego Internetu".

Aby rozwiązać ten problem:

  1. Sprawdź wszystkie wymagania dotyczące klucza zarządzanego przez klienta.
  2. Aprowizuj klaster przy użyciu tożsamości zarządzanej i zaznaczonego magazynu kluczy.
  3. Usuń jednostkę klastra, która zakończyła się niepowodzeniem. Klaster, który uległ awarii, ma clusterStatus właściwość ustawioną na Niepowodzenie. W witrynie Azure Portal stan klastra można znaleźć w bloku Przegląd we właściwościach klastra.

Treści powiązane

  • Last updated on