Klucz zarządzany przez klienta usługi Azure Monitor

  • Artykuł

Dane w usłudze Azure Monitor są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft. Możesz użyć własnego klucza szyfrowania, aby chronić dane i zapisane zapytania w obszarach roboczych. Klucze zarządzane przez klienta w usłudze Azure Monitor zapewniają większą elastyczność zarządzania mechanizmami kontroli dostępu do dzienników. Po skonfigurowaniu nowe dane pozyskane z połączonych obszarów roboczych są szyfrowane przy użyciu klucza przechowywanego w usłudze Azure Key Vault lub zarządzanego przez usługę Azure Key Vault "HSM".

Przed konfiguracją przejrzyj ograniczenia i ograniczenia .

Omówienie klucza zarządzanego przez klienta

Szyfrowanie w spoczynku jest typowym wymaganiem dotyczącym prywatności i zabezpieczeń w organizacjach. Możesz zezwolić platformie Azure na całkowite zarządzanie szyfrowaniem magazynowanych, a jednocześnie masz różne opcje ścisłego zarządzania szyfrowaniem i kluczami szyfrowania.

Azure Monitor gwarantuje, że wszystkie dane i zapisane zapytania są szyfrowane podczas przechowywania przy użyciu kluczy zarządzanych przez firmę Microsoft. Dane można szyfrować przy użyciu własnego klucza w usłudze Azure Key Vault, w celu kontrolowania cyklu życia klucza i możliwości odwoływanie dostępu do danych. Korzystanie z szyfrowania w usłudze Azure Monitor jest identyczne ze sposobem działania szyfrowania usługi Azure Storage.

Klucz zarządzany przez klienta jest dostarczany w dedykowanych klastrach , zapewniając wyższy poziom ochrony i kontrolę. Dane są szyfrowane dwa razy w magazynie, raz na poziomie usługi przy użyciu kluczy zarządzanych przez firmę Microsoft lub kluczy zarządzanych przez klienta, a raz na poziomie infrastruktury przy użyciu dwóch różnych algorytmów szyfrowania i dwóch różnych kluczy. podwójne szyfrowanie chroni przed scenariuszem, w którym jeden z algorytmów szyfrowania lub kluczy może zostać naruszony. Dedykowany klaster umożliwia również ochronę danych za pomocą skrytki.

Dane pozyskane w ciągu ostatnich 14 dni lub ostatnio używane w zapytaniach są przechowywane w gorącej pamięci podręcznej (opartej na dyskach SSD) w celu zwiększenia wydajności zapytań. Dane SSD są szyfrowane przy użyciu kluczy firmy Microsoft niezależnie od konfiguracji klucza zarządzanego przez klienta, ale kontrola dostępu do dysków SSD jest zgodna z odwoływaniem kluczy

Model cenowy dedykowanych klastrów usługi Log Analytics wymaga warstwy zobowiązania, począwszy od 100 GB dziennie.

Jak działa klucz zarządzany przez klienta w usłudze Azure Monitor

Usługa Azure Monitor używa tożsamości zarządzanej do udzielania dostępu do usługi Azure Key Vault. Tożsamość klastra usługi Log Analytics jest obsługiwana na poziomie klastra. Aby zezwolić na używanie klucza zarządzanego przez klienta w wielu obszarach roboczych, zasób klastra usługi Log Analytics działa jako pośrednie połączenie tożsamości między usługą Key Vault i obszarami roboczymi usługi Log Analytics. Magazyn klastra używa tożsamości zarządzanej skojarzonej z klastrem do uwierzytelniania w usłudze Azure Key Vault za pośrednictwem identyfikatora Entra firmy Microsoft.

Klastry obsługują dwa typy tożsamości zarządzanych: przypisane przez system i przypisane przez użytkownika, podczas gdy w klastrze można zdefiniować jedną tożsamość w zależności od scenariusza.

  • Tożsamość zarządzana przypisana przez system jest prostsza i jest generowana automatycznie podczas tworzenia klastra, gdy tożsamość type jest ustawiona na "SystemAssigned". Ta tożsamość może służyć później do udzielania dostępu do magazynu do usługi Key Vault na potrzeby operacji zawijania i odpakowania.
  • Tożsamość zarządzana przypisana przez użytkownika umożliwia skonfigurowanie klucza zarządzanego przez klienta podczas tworzenia klastra podczas udzielania mu uprawnień w usłudze Key Vault przed utworzeniem klastra.

Konfigurację klucza zarządzanego przez klienta można zastosować do nowego klastra lub istniejącego klastra połączonego z obszarami roboczymi i pozyskiwania danych. Nowe dane pozyskane z połączonych obszarów roboczych są szyfrowane przy użyciu klucza, a starsze dane pozyskane przed konfiguracją pozostają zaszyfrowane przy użyciu klucza firmy Microsoft. Twoje zapytania nie mają wpływu na konfigurację klucza zarządzanego przez klienta i bezproblemowo wykonywane na starych i nowych danych. Obszary robocze można odłączyć od klastra w dowolnym momencie. Nowe dane pozyskane po odłączeniu są szyfrowane przy użyciu klucza firmy Microsoft, a zapytania są wykonywane na starych i nowych danych bezproblemowo.

Ważne

Funkcja klucza zarządzanego przez klienta jest regionalna. Usługa Azure Key Vault, klaster i połączone obszary robocze muszą znajdować się w tym samym regionie, ale mogą znajdować się w różnych subskrypcjach.

Screenshot of customer-managed key overview.

  1. Magazyn kluczy
  2. Zasób klastra usługi Log Analytics mający tożsamość zarządzaną z uprawnieniami do usługi Key Vault — tożsamość jest propagowana do magazynu dedykowanego klastra nakładki
  3. Dedykowany klaster
  4. Obszary robocze połączone z dedykowanym klastrem

Operacja kluczy szyfrowania

Istnieją trzy typy kluczy związanych z szyfrowaniem danych usługi Storage:

  • "KEK" — klucz szyfrowania klucza (klucz zarządzany przez klienta)
  • "AEK" — klucz szyfrowania konta
  • "DEK" — klucz szyfrowania danych

Obowiązują następujące zasady:

  • Magazyn klastra ma unikatowy klucz szyfrowania dla każdego konta magazynu, czyli "AEK".
  • Klucz "AEK" służy do uzyskiwania "szyfrowania kluczy, które są używane do szyfrowania każdego bloku danych zapisanych na dysku.
  • Po skonfigurowaniu klucza w usłudze Key Vault i zaktualizowaniu szczegółów klucza w klastrze magazyn klastra wykonuje żądania "zawijania" i "odpakowywania" "AEK" na potrzeby szyfrowania i odszyfrowywania.
  • Twój klucz KEK nigdy nie opuszcza usługi Key Vault, a w przypadku zarządzanego "modułu HSM" nigdy nie opuszcza sprzętu.
  • Usługa Azure Storage używa tożsamości zarządzanej skojarzonej z zasobem klastra do uwierzytelniania. Uzyskuje dostęp do usługi Azure Key Vault za pośrednictwem identyfikatora Entra firmy Microsoft.

Kroki aprowizacji klucza zarządzanego przez klienta

  1. Tworzenie usługi Azure Key Vault i przechowywanie klucza
  2. Tworzenie klastra
  3. Udzielanie uprawnień do usługi Key Vault
  4. Aktualizowanie klastra przy użyciu szczegółów identyfikatora klucza
  5. Łączenie obszarów roboczych

Konfiguracja klucza zarządzanego przez klienta nie jest obecnie obsługiwana w witrynie Azure Portal i aprowizację można wykonywać za pośrednictwem programu PowerShell, interfejsu wiersza polecenia lub żądań REST .

Przechowywanie klucza szyfrowania ("KEK")

Portfolio produktów azure Key Management zawiera listę magazynów i zarządzanych modułów HSM, których można użyć.

Utwórz lub użyj istniejącej usługi Azure Key Vault w regionie, w którym jest zaplanowany klaster. W magazynie kluczy wygeneruj lub zaimportuj klucz do użycia na potrzeby szyfrowania dzienników. Usługa Azure Key Vault musi być skonfigurowana jako możliwe do odzyskania, aby chronić klucz i dostęp do danych w usłudze Azure Monitor. Tę konfigurację można sprawdzić we właściwościach usługi Key Vault. Należy włączyć zarówno ochronę przed usuwaniem nietrwałym, jak i przeczyszczanie.

Screenshot of soft delete and purge protection settings.

Te ustawienia można zaktualizować w usłudze Key Vault za pomocą interfejsu wiersza polecenia i programu PowerShell:

Tworzenie klastra

Klastry używają tożsamości zarządzanej do szyfrowania danych w usłudze Key Vault. Skonfiguruj właściwość tożsamości type do SystemAssigned podczas tworzenia klastra, aby zezwolić na dostęp do usługi Key Vault dla operacji "zawijanie" i "odpakowywanie".

Ustawienia tożsamości w klastrze dla tożsamości zarządzanej przypisanej przez system

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Postępuj zgodnie z procedurą opisaną w artykule Dedicated Clusters (Klastry dedykowane).

Udzielanie uprawnień usługi Key Vault

Istnieją dwa modele uprawnień w usłudze Key Vault, które umożliwiają udzielanie dostępu do klastra i magazynu nakładki — kontrola dostępu oparta na rolach platformy Azure (RBAC) platformy Azure i zasady dostępu do magazynu (starsza wersja).

  1. Przypisywanie kontroli RBAC platformy Azure (zalecane)

    Aby dodać przypisania ról, musisz mieć uprawnienia Microsoft.Authorization/roleAssignments/write i Microsoft.Authorization/roleAssignments/delete, takie jak dostęp użytkowników Administracja istrator lub właściciel.

    Otwórz usługę Key Vault w witrynie Azure Portal, kliknij pozycję Konfiguracja dostępu w Ustawienia i wybierz opcję Kontrola dostępu oparta na rolach platformy Azure. Następnie wprowadź pozycję Kontrola dostępu (IAM) i dodaj przypisanie roli Użytkownika szyfrowania usługi kryptograficznej usługi Key Vault.

    Screenshot of Grant Key Vault RBAC permissions.

  2. Przypisywanie zasad dostępu do magazynu (starsza wersja)

    Otwórz usługę Key Vault w witrynie Azure Portal i kliknij pozycję Zasady dostępu, wybierz pozycję Zasady dostępu magazynu, a następnie kliknij pozycję + Dodaj zasady dostępu, aby utworzyć zasady z następującymi ustawieniami:

    • Uprawnienia klucza — wybierz pozycję Pobierz, Zawijaj klucz i Odpakuj klucz.
    • Wybierz jednostkę — w zależności od typu tożsamości używanego w klastrze (tożsamość zarządzana przypisana przez system lub użytkownika)
      • Tożsamość zarządzana przypisana przez system — wprowadź nazwę klastra lub identyfikator podmiotu zabezpieczeń klastra
      • Tożsamość zarządzana przypisana przez użytkownika — wprowadź nazwę tożsamości

    Screenshot of Grant Key Vault access policy permissions.

    Aby sprawdzić, czy usługa Key Vault jest skonfigurowana jako możliwe do odzyskania w celu ochrony klucza i dostępu do danych usługi Azure Monitor, wymagane jest uprawnienie Pobierz .

Aktualizowanie klastra przy użyciu szczegółów identyfikatora klucza

Wszystkie operacje w klastrze wymagają Microsoft.OperationalInsights/clusters/write uprawnienia akcji. To uprawnienie można udzielić za pośrednictwem właściciela lub współautora zawierającego */write akcję lub rolę Współautor usługi Log Analytics, która zawiera Microsoft.OperationalInsights/* akcję.

Ten krok aktualizuje dedykowany magazyn klastra przy użyciu klucza i wersji do użycia w celu opakowania i odpakowania klucza AEK.

Ważne

  • Rotacja kluczy może być automatyczna lub wymagaj jawnej aktualizacji klucza, zobacz Rotacja kluczy, aby określić, które podejście jest odpowiednie dla Ciebie przed zaktualizowaniem szczegółów identyfikatora klucza w klastrze.
  • Aktualizacja klastra nie powinna zawierać zarówno szczegółów tożsamości, jak i identyfikatora klucza w tej samej operacji. Jeśli musisz zaktualizować obie te elementy, aktualizacja powinna znajdować się w dwóch kolejnych operacjach.

Screenshot of Grant Key Vault permissions.

Zaktualizuj właściwość KeyVaultProperties w klastrze przy użyciu szczegółów identyfikatora klucza.

Operacja jest asynchroniczna i może trochę potrwać.

Nie dotyczy

Ważne

Ten krok należy wykonać tylko po aprowizacji klastra. Jeśli połączysz obszary robocze i pozyskasz dane przed aprowizowaniem, pozyskane dane zostaną porzucone i nie będą możliwe do odzyskania.

Aby wykonać tę operację, musisz mieć uprawnienia do zapisu w obszarze roboczym i klastrze. Zawiera on elementy Microsoft.OperationalInsights/workspaces/write i Microsoft.OperationalInsights/clusters/write.

Postępuj zgodnie z procedurą opisaną w artykule Dedicated Clusters (Klastry dedykowane).

Odwołanie klucza

Ważne

  • Zalecanym sposobem odwołania dostępu do danych jest wyłączenie klucza lub usunięcie zasad dostępu w usłudze Key Vault.
  • Ustawienie klastra identitytype na odwołanie dostępu do danych również nie jest zalecane, ponieważ nie można go przywrócić None bez kontaktu z pomocą techniczną.

Magazyn klastra zawsze uwzględnia zmiany uprawnień klucza w ciągu godziny lub wcześniej, a magazyn stanie się niedostępny. Nowe dane pozyskane z połączonych obszarów roboczych są porzucane i nie można ich odzyskać. Dane są niedostępne w tych obszarach roboczych i zapytania kończą się niepowodzeniem. Wcześniej pozyskane dane pozostają w magazynie, o ile klaster i obszary robocze nie zostaną usunięte. Niedostępne dane podlegają zasadom przechowywania danych i czyszczone po osiągnięciu okresu przechowywania. Dane pozyskane w ciągu ostatnich 14 dni, a dane ostatnio używane w zapytaniach są również przechowywane w gorącej pamięci podręcznej (opartej na dyskach SSD) w celu zwiększenia wydajności zapytań. Dane na dysku SSD są usuwane w operacji odwoływania kluczy i stają się niedostępne. Magazyn klastra próbuje okresowo zawijać i odpakowywać magazyn kluczy, a po włączeniu klucza odpakowywanie zakończy się pomyślnie, dane SSD zostaną ponownie załadowane z magazynu, a pozyskiwanie i wykonywanie zapytań danych zostanie wznowione w ciągu 30 minut.

Wymiana kluczy

Rotacja kluczy ma dwa tryby:

  • Autorotacja — zaktualizuj klaster przy użyciu "keyVaultProperties" właściwości , ale pomiń "keyVersion" ją lub ustaw na ""wartość . Usługa Storage automatycznie używa najnowszej wersji klucza.
  • Jawna aktualizacja wersji klucza — zaktualizuj klaster przy użyciu wersji klucza we "keyVersion" właściwości. Rotacja kluczy wymaga jawnej "keyVaultProperties" aktualizacji w klastrze. Zobacz Aktualizowanie klastra przy użyciu szczegółów identyfikatora klucza. Jeśli w usłudze Key Vault zostanie wygenerowana nowa wersja klucza, ale nie zaktualizujesz jej w klastrze, magazyn klastra będzie nadal używać poprzedniego klucza. Jeśli wyłączysz lub usuniesz stary klucz przed zaktualizowaniem nowego klucza w klastrze, przejdziesz do stanu odwołania klucza.

Wszystkie dane pozostają dostępne po operacji rotacji kluczy. Dane są zawsze szyfrowane przy użyciu klucza szyfrowania konta ("AEK"), który jest szyfrowany przy użyciu nowej wersji klucza szyfrowania kluczy ("KEK") w usłudze Key Vault.

Klucz zarządzany przez klienta dla zapisanych zapytań i alertów przeszukiwania dzienników

Język zapytań używany w usłudze Log Analytics jest ekspresyjny i może zawierać poufne informacje w komentarzach lub składni zapytania. Niektóre organizacje wymagają, aby takie informacje były chronione w ramach zasad klucza zarządzanego przez klienta i należy zapisać zapytania zaszyfrowane przy użyciu klucza. Usługa Azure Monitor umożliwia przechowywanie zapisanych zapytań i alertów przeszukiwania dzienników zaszyfrowanych przy użyciu klucza na własnym koncie magazynu podczas nawiązywania połączenia z obszarem roboczym.

Klucz zarządzany przez klienta dla skoroszytów

W przypadku zagadnień dotyczących klucza zarządzanego przez klienta w przypadku zapisanych zapytań i alertów przeszukiwania dzienników usługa Azure Monitor umożliwia przechowywanie zapytań skoroszytu zaszyfrowanych przy użyciu klucza na własnym koncie magazynu, po wybraniu opcji Zapisz zawartość na koncie usługi Azure Storage w operacji Zapisywania skoroszytu.

Screenshot of Workbook save.

Uwaga

Zapytania pozostają szyfrowane przy użyciu klucza firmy Microsoft ("MMK") w następujących scenariuszach niezależnie od konfiguracji klucza zarządzanego przez klienta: pulpity nawigacyjne platformy Azure, aplikacja logiki platformy Azure, notesy platformy Azure i elementy Runbook usługi Automation.

Podczas łączenia konta magazynu dla zapisanych zapytań usługa przechowuje zapisane zapytania i zapytania alertów przeszukiwania dzienników na koncie magazynu. Mając kontrolę nad zasadami szyfrowania konta magazynu w spoczynku, można chronić zapisane zapytania i alerty wyszukiwania dzienników za pomocą klucza zarządzanego przez klienta. Użytkownik będzie jednak odpowiedzialny za koszty związane z tym kontem magazynu.

Zagadnienia przed ustawieniem klucza zarządzanego przez klienta dla zapytań

  • Musisz mieć uprawnienia do zapisu w obszarze roboczym i na koncie magazynu.
  • Pamiętaj, aby utworzyć konto magazynu w tym samym regionie, w którym znajduje się obszar roboczy usługi Log Analytics, z szyfrowaniem kluczy zarządzanych przez klienta. Jest to ważne, ponieważ zapisane zapytania są przechowywane w magazynie tabel i mogą być szyfrowane tylko podczas tworzenia konta magazynu.
  • Zapytania zapisane w pakiecie zapytań nie są szyfrowane przy użyciu klucza zarządzanego przez klienta. Wybierz pozycję Zapisz jako starsze zapytanie podczas zapisywania zapytań , aby chronić je przy użyciu klucza zarządzanego przez klienta.
  • Zapisywanie zapytań w magazynie jest uznawane za artefakty usługi, a ich format może ulec zmianie.
  • Łączenie konta magazynu dla zapytań usuwa istniejące zapytania z obszaru roboczego. Kopiuj zapisuje potrzebne zapytania przed tą konfiguracją. Zapisane zapytania można wyświetlić przy użyciu programu PowerShell.
  • Zapytania "historia" i "przypnij do pulpitu nawigacyjnego" nie są obsługiwane podczas łączenia konta magazynu dla zapytań.
  • Jedno konto magazynu można połączyć z obszarem roboczym zarówno dla zapisanych zapytań, jak i zapytań alertów przeszukiwania dzienników.
  • Alerty przeszukiwania dzienników są zapisywane w magazynie obiektów blob, a szyfrowanie kluczy zarządzanych przez klienta można skonfigurować podczas tworzenia konta magazynu lub nowszego.
  • Wyzwolone alerty wyszukiwania dzienników nie będą zawierać wyników wyszukiwania ani kwerendy alertu. Możesz użyć wymiarów alertów , aby uzyskać kontekst w wyzwolonych alertach.

Konfigurowanie usługi BYOS dla zapisanych zapytań

Połącz konto magazynu dla zapytań, aby zachować zapisane zapytania na koncie magazynu.

Nie dotyczy

Po zakończeniu konfiguracji wszystkie nowe zapisane zapytanie wyszukiwania zostaną zapisane w magazynie.

Konfigurowanie usługi BYOS pod kątem zapytań alertów dotyczących przeszukiwania dzienników

Połącz konto magazynu dla alertów , aby zachować zapytania alertów przeszukiwania dzienników na koncie magazynu.

Nie dotyczy

Po zakończeniu konfiguracji wszystkie nowe zapytania alertu zostaną zapisane w magazynie.

Skrytka klienta

Lockbox zapewnia kontrolę, aby zatwierdzić lub odrzucić żądanie inżyniera firmy Microsoft w celu uzyskania dostępu do danych podczas żądania pomocy technicznej.

Skrytka jest udostępniana w dedykowanym klastrze w usłudze Azure Monitor, gdzie twoje uprawnienia dostępu do danych są przyznawane na poziomie subskrypcji.

Dowiedz się więcej o skrytce klienta dla platformy Microsoft Azure

Operacje klucza zarządzanego przez klienta

Klucz zarządzany przez klienta jest udostępniany w dedykowanym klastrze, a te operacje są określane w dedykowanym artykule dotyczącym klastra

  • Pobieranie wszystkich klastrów w grupie zasobów
  • Pobieranie wszystkich klastrów w subskrypcji
  • Aktualizowanie rezerwacji pojemności w klastrze
  • Aktualizowanie parametru billingType w klastrze
  • Odłączanie obszaru roboczego z klastra
  • Usuwanie klastra

Limity i ograniczenia

  • W każdym regionie i subskrypcji można utworzyć maksymalnie pięć aktywnych klastrów.

  • Maksymalna liczba siedmiu klastrów zarezerwowanych (aktywnych lub ostatnio usuniętych) może istnieć w każdym regionie i subskrypcji.

  • Do klastra można połączyć maksymalnie 1000 obszarów roboczych usługi Log Analytics.

  • Maksymalnie dwie operacje łączenia obszaru roboczego w określonym obszarze roboczym są dozwolone w okresie 30 dni.

  • Przenoszenie klastra do innej grupy zasobów lub subskrypcji nie jest obecnie obsługiwane.

  • Aktualizacja klastra nie powinna zawierać zarówno szczegółów tożsamości, jak i identyfikatora klucza w tej samej operacji. W przypadku konieczności zaktualizowania obu aktualizacji aktualizacja powinna znajdować się w dwóch kolejnych operacjach.

  • Skrytka nie jest obecnie dostępna w Chinach.

  • Podwójne szyfrowanie jest konfigurowane automatycznie dla klastrów utworzonych od października 2020 r. w obsługiwanych regionach. Możesz sprawdzić, czy klaster jest skonfigurowany do podwójnego szyfrowania, wysyłając żądanie GET w klastrze i obserwując, że isDoubleEncryptionEnabled wartość jest true dla klastrów z włączonym podwójnym szyfrowaniem.

    • Jeśli utworzysz klaster i wystąpi błąd "nazwa regionu nie obsługuje podwójnego szyfrowania dla klastrów", nadal możesz utworzyć klaster bez podwójnego szyfrowania, dodając "properties": {"isDoubleEncryptionEnabled": false} treść żądania REST.
    • Nie można zmienić ustawień podwójnego szyfrowania po utworzeniu klastra.

Usunięcie połączonego obszaru roboczego jest dozwolone podczas łączenia z klastrem. Jeśli zdecydujesz się odzyskać obszar roboczy w okresie usuwania nietrwałego, powróci do poprzedniego stanu i pozostanie połączony z klastrem.

  • Szyfrowanie kluczy zarządzanych przez klienta ma zastosowanie do nowo pozyskanych danych po czasie konfiguracji. Dane pozyskane przed konfiguracją pozostają zaszyfrowane przy użyciu klucza firmy Microsoft. Możesz bezproblemowo wykonywać zapytania dotyczące danych pozyskanych przed konfiguracją klucza zarządzanego przez klienta i po nim.

  • Usługa Azure Key Vault musi być skonfigurowana jako możliwe do odzyskania. Te właściwości nie są domyślnie włączone i powinny być skonfigurowane przy użyciu interfejsu wiersza polecenia lub programu PowerShell:

  • Usługa Azure Key Vault, klaster i obszary robocze muszą znajdować się w tym samym regionie i w tej samej dzierżawie firmy Microsoft Entra, ale mogą znajdować się w różnych subskrypcjach.

  • Ustawienie klastra identitytype na odwołanie dostępu do danych również nie jest zalecane, ponieważ nie można go przywrócić None bez kontaktu z pomocą techniczną. Zalecanym sposobem odwołania dostępu do danych jest odwołanie klucza.

  • Nie można używać klucza zarządzanego przez klienta z tożsamością zarządzaną przypisaną przez użytkownika, jeśli usługa Key Vault znajduje się w usłudze Private-Link (vNet). W tym scenariuszu można użyć tożsamości zarządzanej przypisanej przez system.

  • Zapytania asynchroniczne zadań wyszukiwania nie są obecnie obsługiwane w scenariuszu klucza zarządzanego przez klienta.

Rozwiązywanie problemów

  • Zachowanie na dostępność usługi Key Vault:

    • Normalna operacja — magazyn buforuje wartość "AEK" przez krótki czas i cofa się do usługi Key Vault, aby okresowo odpakowywać.

    • Błędy połączenia z usługą Key Vault — magazyn obsługuje błędy przejściowe (przekroczenia limitu czasu, błędy połączeń, problemy z usługą DNS), umożliwiając kluczom pozostawanie w pamięci podręcznej podczas problemu z dostępnością, co pozwala na rozwiązywanie problemów z błędami i dostępnością. Możliwości zapytań i pozyskiwania są kontynuowane bez przerwy.

  • Szybkość dostępu do usługi Key Vault — częstotliwość, z jaką usługa Azure Cluster Storage uzyskuje dostęp do usługi Key Vault w celu zawijania i odpakowania, wynosi od 6 do 60 sekund.

  • Jeśli zaktualizujesz klaster w stanie aprowizacji lub zaktualizujesz stan, aktualizacja zakończy się niepowodzeniem.

  • Jeśli wystąpi konflikt — błąd podczas tworzenia klastra, klaster o tej samej nazwie mógł zostać usunięty w ciągu ostatnich 14 dni i zachowany jako zarezerwowany. Usunięta nazwa klastra stanie się dostępna 14 dni po usunięciu.

  • Łącze obszaru roboczego do klastra kończy się niepowodzeniem, jeśli jest połączony z innym klastrem.

  • Jeśli utworzysz klaster i określisz właściwość KeyVaultProperties natychmiast, operacja może zakończyć się niepowodzeniem, dopóki tożsamość nie zostanie przypisana w klastrze i udzielona w usłudze Key Vault.

  • Jeśli zaktualizujesz istniejący klaster przy użyciu właściwości KeyVaultProperties i zasad dostępu klucza "Pobierz" w usłudze Key Vault, operacja zakończy się niepowodzeniem.

  • Jeśli nie można wdrożyć klastra, sprawdź, czy usługa Azure Key Vault, klaster i połączone obszary robocze znajdują się w tym samym regionie. Element może znajdować się w różnych subskrypcjach.

  • Jeśli obrócisz klucz w usłudze Key Vault i nie zaktualizujesz nowych szczegółów identyfikatora klucza w klastrze, klaster będzie nadal używać poprzedniego klucza, a dane staną się niedostępne. Zaktualizuj szczegóły nowego identyfikatora klucza w klastrze, aby wznowić pozyskiwanie danych i wykonywanie zapytań. Możesz zaktualizować wersję klucza za pomocą polecenia "''", aby magazyn zawsze używał automatycznie wersji klucza późnego.

  • Niektóre operacje są długotrwałe i mogą chwilę potrwać, obejmują tworzenie klastra, aktualizowanie klucza klastra i usuwanie klastra. Stan operacji można sprawdzić, wysyłając żądanie GET do klastra lub obszaru roboczego i obserwując odpowiedź. Na przykład odłączony obszar roboczy nie będzie miał identyfikatora clusterResourceId w obszarze funkcji.

  • Komunikaty o błędach

    Aktualizacja klastra

    • 400 — klaster jest w stanie usuwania. Operacja asynchroniczny jest w toku. Klaster musi ukończyć swoją operację przed wykonaniem jakiejkolwiek operacji aktualizacji.
    • 400 — właściwość KeyVaultProperties nie jest pusta, ale ma nieprawidłowy format. Zobacz aktualizację identyfikatora klucza.
    • 400 — Nie można zweryfikować klucza w usłudze Key Vault. Może to być spowodowane brakiem uprawnień lub brakiem klucza. Sprawdź, czy ustawiono klucz i zasady dostępu w usłudze Key Vault.
    • 400 — klucz nie jest możliwy do odzyskania. Usługa Key Vault musi być ustawiona na usuwanie nietrwałe i ochronę przed przeczyszczeniem. Zobacz dokumentację usługi Key Vault
    • 400 — nie można teraz wykonać operacji. Poczekaj na zakończenie operacji asynchronicznych i spróbuj ponownie.
    • 400 — klaster jest w stanie usuwania. Poczekaj na zakończenie operacji asynchronicznych i spróbuj ponownie.

    Pobieranie klastra

    • 404 — nie znaleziono klastra, który mógł zostać usunięty. Jeśli spróbujesz utworzyć klaster o tej nazwie i uzyskać konflikt, klaster jest w trakcie usuwania.

Następne kroki