Udostępnij za pośrednictwem

Konfigurowanie kluczy zarządzanych przez klienta dla istniejącego konta usługi Azure Cosmos DB za pomocą usługi Azure Key Vault

  • Artykuł

DOTYCZY: NoSQL MongoDB Gremlin Stół

Włączenie drugiej warstwy szyfrowania danych magazynowanych przy użyciu kluczy zarządzanych przez klienta podczas tworzenia nowego konta usługi Azure Cosmos DB zostało od jakiegoś czasu ogólnie dostępne. W ramach naturalnego następnego kroku mamy teraz możliwość włączenia klucza zarządzanego przez klienta na istniejących kontach usługi Azure Cosmos DB.

Ta funkcja eliminuje konieczność migracji danych do nowego konta w celu włączenia klucza zarządzanego przez klienta. Pomaga to zwiększyć poziom bezpieczeństwa i zgodności klientów.

Włączenie klucza zarządzanego przez klienta rozpoczyna proces asynchroniczny w celu zaszyfrowania wszystkich istniejących danych na koncie, podczas gdy nowe dane przychodzące są szyfrowane przed utrwaleniem. Nie trzeba czekać na pomyślną operację asynchroniczną. Proces włączania zużywa nieużywane/zapasowe jednostki RU, dzięki czemu nie ma wpływu na obciążenia odczytu/zapisu. Możesz zapoznać się z tym linkiem do planowania pojemności po zaszyfrowaniu konta.

Rozpocznij od włączenia klucza zarządzanego przez klienta na istniejących kontach

Ważne

Dokładnie zapoznaj się z sekcją wymagań wstępnych. Są to ważne zagadnienia.

Wymagania wstępne

Wszystkie kroki wymagań wstępnych wymaganych podczas konfigurowania kluczy zarządzanych przez klienta dla nowych kont mają zastosowanie do włączenia klucza zarządzanego przez klienta na istniejącym koncie. Zapoznaj się z krokami tutaj

Uwaga

Należy pamiętać, że włączenie szyfrowania na koncie usługi Azure Cosmos DB spowoduje dodanie małego obciążenia do identyfikatora dokumentu, ograniczając maksymalny rozmiar identyfikatora dokumentu do 990 bajtów zamiast 1024 bajtów. Jeśli twoje konto ma jakiekolwiek dokumenty z identyfikatorami większymi niż 990 bajtów, proces szyfrowania zakończy się niepowodzeniem, dopóki te dokumenty nie zostaną usunięte.

Aby sprawdzić, czy twoje konto jest zgodne, możesz użyć udostępnionej aplikacji konsolowej hostowanej tutaj do skanowania konta. Upewnij się, że używasz punktu końcowego z właściwości konta "sqlEndpoint", niezależnie od wybranego interfejsu API.

Jeśli chcesz wyłączyć walidację po stronie serwera podczas migracji, skontaktuj się z pomocą techniczną.

Kroki włączania klucza zarządzanego przez klienta na istniejącym koncie

Aby włączyć klucz cmK na istniejącym koncie, zaktualizuj konto przy użyciu szablonu usługi ARM, ustawiając identyfikator klucza usługi Key Vault we właściwości keyVaultKeyUri — tak jak podczas włączania klucza zarządzania kluczami na nowym koncie. Ten krok można wykonać, wykonując wywołanie PATCH z następującym ładunkiem:

    {
        "properties": {
        "keyVaultKeyUri": "<key-vault-key-uri>"
        }
    }

Dane wyjściowe tego polecenia interfejsu wiersza polecenia umożliwiającego włączenie klucza zarządzanego przez klienta czeka na ukończenie szyfrowania danych.

    az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"

Kroki włączania klucza zarządzanego przez klienta na istniejącym koncie usługi Azure Cosmos DB przy użyciu ciągłego tworzenia kopii zapasowej lub konta magazynu analitycznego

Aby włączyć klucz zarządzania kluczami na istniejącym koncie, na którym włączono ciągłą kopię zapasową i przywracanie do punktu w czasie, należy wykonać kilka dodatkowych kroków. Wykonaj krok 1 do kroku 5, a następnie postępuj zgodnie z instrukcjami, aby włączyć klucz cmK na istniejącym koncie.

  1. Konfigurowanie tożsamości zarządzanej na koncie usługi Cosmos Konfigurowanie tożsamości zarządzanych przy użyciu identyfikatora Entra firmy Microsoft dla konta usługi Azure Cosmos DB

  2. Zaktualizuj konto usługi Cosmos, aby ustawić tożsamość domyślną tak, aby wskazywała tożsamość zarządzaną dodaną w poprzednim kroku

    W przypadku tożsamości zarządzanej przez system:

    az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"

    W przypadku tożsamości zarządzanej przez użytkownika:

    az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"

  3. Skonfiguruj usługę Keyvault zgodnie z podanymi w dokumentacji tutaj

  4. Dodaj zasady dostępu w usłudze keyvault dla domyślnej tożsamości ustawionej w poprzednim kroku

  5. Zaktualizuj konto usługi Cosmos, aby ustawić identyfikator URI usługi Keyvault. Ta aktualizacja wyzwala wyzwalacze włączania klucza zarządzanego przez klienta na koncie 

    az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI 

Znane ograniczenia

  • Nie obsługujemy włączania klucza zarządzanego przez klienta na istniejących kontach usługi Azure Cosmos DB dla systemu Apache Cassandra.
  • Włączanie klucza zarządzanego przez klienta jest dostępne tylko na poziomie konta usługi Cosmos DB, a nie w kolekcjach.
  • Nie obsługujemy włączania klucza cmK na istniejących kontach, które są włączone dla zmaterializowanych widoków i wszystkich wersji oraz usuwa tryb zestawienia zmian.
  • Przed włączeniem klucza cmK upewnij się, że konto nie może mieć dokumentów z dużymi identyfikatorami większymi niż 990 bajtów. Jeśli nie, otrzymasz błąd z powodu maksymalnego obsługiwanego limitu 1024 bajtów po szyfrowaniu.
  • Podczas szyfrowania istniejących danych akcje płaszczyzny sterowania, takie jak "dodaj region" są blokowane. Te akcje są odblokowane i mogą być używane bezpośrednio po zakończeniu szyfrowania.

Monitorowanie postępu wynikowego szyfrowania

Włączenie klucza zarządzanego przez klienta na istniejącym koncie jest operacją asynchroniczną, która uruchamia zadanie w tle, które szyfruje wszystkie istniejące dane. W związku z tym żądanie interfejsu API REST umożliwiające włączenie klucza zarządzanego przez klienta zapewnia w odpowiedzi adres URL "Azure-AsyncOperation". Sondowanie tego adresu URL przy użyciu żądań GET zwraca stan ogólnej operacji, co ostatecznie powiedzie się. Ten mechanizm jest w pełni opisany w tym artykule.

Konto usługi Cosmos DB może nadal być używane, a dane mogą być nadal zapisywane bez oczekiwania na pomyślną operację asynchroniczną. Polecenie interfejsu wiersza polecenia umożliwiające włączenie klucza zarządzanego przez klienta czeka na ukończenie szyfrowania danych.

Aby umożliwić korzystanie z istniejącego konta usługi Cosmos DB w kluczu cmK, należy przeprowadzić skanowanie, aby upewnić się, że konto nie ma "dużych identyfikatorów". "Duży identyfikator" to identyfikator dokumentu, który przekracza 990 znaków. To skanowanie jest obowiązkowe w przypadku migracji klucza zarządzanego przez klienta i jest wykonywane automatycznie przez firmę Microsoft. Podczas tego procesu może zostać wyświetlony błąd.

BŁĄD: (InternalServerError) Nieoczekiwany błąd podczas skanowania dokumentów pod kątem migracji klucza zarządzanego przez klienta. Ponów próbę wykonania operacji.

Dzieje się tak, gdy proces skanowania używa więcej jednostek RU niż te aprowidowane w kolekcji, zgłaszając błąd 429. Rozwiązaniem tego problemu będzie tymczasowe podbicie jednostek RU znacznie. Alternatywnie możesz skorzystać z udostępnionej aplikacji konsolowej hostowanej tutaj , aby skanować swoje kolekcje.

Uwaga

Jeśli chcesz wyłączyć walidację po stronie serwera podczas migracji, skontaktuj się z pomocą techniczną. Jest to zalecane tylko wtedy, gdy masz pewność, że nie ma dużych identyfikatorów. Jeśli podczas szyfrowania napotkany jest duży identyfikator, proces zostanie zatrzymany do momentu rozwiązania problemu dotyczącego dokumentu o dużym identyfikatorze.

Jeśli masz dodatkowe pytania, skontaktuj się z pomoc techniczna firmy Microsoft.

Często zadawane pytania

Jakie są czynniki, od których zależy czas szyfrowania?

Włączenie klucza zarządzanego przez klienta jest operacją asynchroniczną i zależy od dostępności wystarczających nieużywanych jednostek RU. Zalecamy włączenie klucza zarządzanego przez klienta w godzinach poza godzinami szczytu, a jeśli ma to zastosowanie, możesz zwiększyć liczbę jednostek RU przed przekazaniem, aby przyspieszyć szyfrowanie. Jest to również bezpośrednia funkcja rozmiaru danych.

Czy musimy samodzielnie przygotować się do przestoju?

Włączenie klucza zarządzanego przez klienta rozpoczyna proces asynchroniczny w celu zaszyfrowania wszystkich danych. Nie trzeba czekać na pomyślną operację asynchroniczną. Konto usługi Azure Cosmos DB jest dostępne dla operacji odczytu i zapisu i nie ma potrzeby przestoju.

Czy można podnieść ru po wyzwoleniu klucza zarządzanego przez klienta?

Zaleca się, aby podnieść jednostki RU przed wyzwoleniem klucza zarządzanego przez klienta. Po wyzwoleniu klucza zarządzanego przez klienta niektóre operacje płaszczyzny sterowania są blokowane do momentu ukończenia szyfrowania. Ten blok może uniemożliwić użytkownikowi zwiększenie liczby jednostek ŻĄDANIA po wyzwoleniu klucza zarządzanego przez klienta.

Aby umożliwić istniejącemu kontu usługi Cosmos DB używanie do klucza cmK, skanowanie dużego identyfikatora jest wykonywane automatycznie przez firmę Microsoft w celu rozwiązania jednego ze znanych ograniczeń wymienionych wcześniej. Ten proces zużywa również dodatkowe jednostki RU i warto znacznie podnieść jednostki RU, aby uniknąć błędu 429.

Czy istnieje sposób odwrócenia szyfrowania lub wyłączenia szyfrowania po wyzwoleniu klucza zarządzanego przez klienta?

Po wyzwoleniu procesu szyfrowania danych przy użyciu klucza zarządzanego przez klienta nie można go przywrócić.

Czy włączenie szyfrowania przy użyciu klucza zarządzanego przez klienta na istniejącym koncie ma wpływ na rozmiar danych i odczyt/zapis?

Jak można się spodziewać, włączenie klucza zarządzanego przez klienta ma niewielki wzrost rozmiaru danych i jednostek RU w celu uwzględnienia dodatkowego przetwarzania szyfrowania/odszyfrowywania.

Czy należy utworzyć kopię zapasową danych przed włączeniem klucza zarządzanego przez klienta?

Włączenie klucza zarządzanego przez klienta nie stanowi żadnego zagrożenia utraty danych.

Czy stare kopie zapasowe są tworzone jako część okresowych kopii zapasowych?

L.p. Stare okresowe kopie zapasowe nie są szyfrowane. Nowo wygenerowane kopie zapasowe po włączeniu klucza zarządzanego przez klienta są szyfrowane.

Jakie jest zachowanie istniejących kont, które są włączone dla ciągłej kopii zapasowej?

Po włączeniu klucza cmK szyfrowanie jest również włączone dla ciągłych kopii zapasowych. Po włączeniu klucza cmK wszystkie przywrócone konta będą włączone.

Jakie jest zachowanie, jeśli klucz cmK jest włączony na koncie z włączoną usługą PITR i przywracamy konto do czasu wyłączenia klucza zarządzanego przez klienta?

W takim przypadku klucz cmK jest jawnie włączony na przywróconym koncie docelowym z następujących powodów:

  • Po włączeniu klucza zarządzanego przez klienta na koncie nie ma możliwości wyłączenia klucza zarządzanego przez klienta.
  • To zachowanie jest zgodne z bieżącym projektem przywracania konta z obsługą klucza zarządzanego przez klienta z okresową kopią zapasową

Co się stanie, gdy użytkownik odwoła klucz podczas migracji klucza zarządzanego przez klienta?

Stan klucza jest sprawdzany po wyzwoleniu szyfrowania klucza zarządzanego przez klienta. Jeśli klucz w usłudze Azure Key Vault jest w dobrej kondycji, szyfrowanie jest uruchamiane i proces kończy się bez dalszej kontroli. Nawet jeśli klucz zostanie odwołany lub magazyn kluczy platformy Azure zostanie usunięty lub niedostępny, proces szyfrowania zakończy się pomyślnie.

Czy można włączyć szyfrowanie CMK na istniejącym koncie produkcyjnym?

Tak. Dokładnie zapoznaj się z sekcją wymagań wstępnych. Zalecamy przetestowanie wszystkich scenariuszy najpierw na kontach nieprodukcyjnych, a gdy wszystko będzie wygodne, możesz rozważyć konta produkcyjne.

Następne kroki