Udostępnij za pośrednictwem

Klucze zarządzane przez klienta w usłudze 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 lub użyć różnych opcji do ś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. Korzystanie z szyfrowania w usłudze Azure Monitor jest identyczne ze sposobem działania szyfrowania usługi Azure Storage.

Aby zarządzać cyklem życia klucza i mieć możliwość odwołania dostępu do danych, możesz zaszyfrować dane przy użyciu własnego klucza przy użyciu usługi Azure Key Vault.

Klucze zarządzane przez klienta są dostępne w dedykowanych klastrach i zapewniają wyższy poziom ochrony i kontroli. Dane są szyfrowane dwa razy w magazynie — na poziomie usługi przy użyciu kluczy zarządzanych przez firmę Microsoft lub kluczy zarządzanych przez klienta oraz 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. Dedykowane klastry umożliwiają 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 tego, czy są konfigurowane klucze zarządzane przez klienta, ale kontrola nad dostępem do dysków SSD jest zgodna z odwołaniem kluczy.

Ważne

Klastry dedykowane używają modelu cenowego warstwy zobowiązania co najmniej 100 GB dziennie.

Jak działają klucze zarządzane 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 klucze zarządzane przez klienta w wielu obszarach roboczych, zasób klastra usługi Log Analytics służy 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 pomocą 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 generowana automatycznie z klastrem, gdy identity type jest ustawiona na SystemAssignedwartość . Ta tożsamość jest później używana do udzielania dostępu magazynu do usługi Key Vault na potrzeby szyfrowania i odszyfrowywania danych.
  • Tożsamość zarządzana przypisana przez użytkownika umożliwia skonfigurowanie kluczy zarządzanych przez klienta podczas tworzenia klastra, gdy identity type jest ustawiona na UserAssigned, i udzielanie jej uprawnień w usłudze Key Vault przed utworzeniem klastra.

Klucze zarządzane przez klienta można skonfigurować w nowym klastrze lub w istniejącym klastrze połączonym z obszarami roboczymi i już pozyskiwać dane. Nowe dane pozyskane z połączonych obszarów roboczych są szyfrowane przy użyciu klucza, a starsze dane pozyskane przed zaszyfrowaniem konfiguracji za pomocą kluczy firmy Microsoft. Konfiguracja klucza zarządzanego przez klienta nie ma wpływu na zapytania, które będą nadal bezproblemowo uruchamiane na starych i nowych danych. Obszary robocze można odłączyć od klastra w dowolnym momencie. Nowe dane pozyskiwane po odłączeniu są szyfrowane przy użyciu kluczy firmy Microsoft, a zapytania są wykonywane na starych i nowych danych bezproblemowo.

Ważne

Możliwość kluczy zarządzanych 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.

Zrzut ekranu przedstawiający omówienie klucza zarządzanego przez klienta.

  1. Key Vault
  2. Zasób klastra usługi Log Analytics, który ma 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 jeśli używasz 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.

Zrzut ekranu przedstawiający ustawienia ochrony przed usuwaniem nietrwałym i przeczyszczaniem.

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 identity type właściwość do SystemAssigned lub UserAssigned podczas tworzenia klastra, aby zezwolić na dostęp do usługi Key Vault na potrzeby operacji szyfrowania i odszyfrowywania danych.

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

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

Uwaga

Typ tożsamości można zmienić po utworzeniu klastra bez przerw w pozyskiwaniu lub zapytaniach, biorąc pod uwagę następujące zagadnienia

  • Aktualizowanie SystemAssigned do UserAssigned— udzielanie tożsamości UserAssign w usłudze Key Vault, a następnie aktualizowanie identity type w klastrze
  • Aktualizowanie UserAssigned do SystemAssigned— ponieważ tożsamość zarządzana przypisana przez system została utworzona po zaktualizowaniu klastra identity type za pomocą SystemAssignedpolecenia , należy wykonać następujące kroki
    1. Aktualizowanie klastra i usuwanie klucza — ustaw keyVaultUrikeyName, i keyVersion z wartością ""
    2. Aktualizowanie klastra identity type do SystemAssigned
    3. Aktualizowanie usługi Key Vault i udzielanie uprawnień tożsamości
    4. Aktualizowanie klucza w klastrze

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ć rolę z uprawnieniami Microsoft.Authorization/roleAssignments/write i Microsoft.Authorization/roleAssignments/delete , takimi jak administrator dostępu użytkowników lub właściciel.

    1. Otwórz usługę Key Vault w witrynie Azure Portal i wybierz pozycję UstawieniaZasadyj>konfigurację> dostępu opartą na rolach platformy Azure i Zastosuj
    2. Kliknij przycisk Przejdź do kontroli dostępu (IAM) i dodaj przypisanie roli Użytkownika szyfrowania usługi Kryptograficznej usługi Key Vault.
    3. Wybierz pozycję Tożsamość zarządzana na karcie Członkowie i wybierz subskrypcję tożsamości i tożsamości jako członka

    Zrzut ekranu przedstawiający przyznawanie uprawnień kontroli dostępu opartej na rolach usługi Key Vault.

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

    Otwórz usługę Key Vault w witrynie Azure Portal i wybierz pozycję Zasady dostępu do>magazynu zasad> dostępu+ 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

    Zrzut ekranu przedstawiający przyznawanie uprawnień zasad dostępu usługi Key Vault.

    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 jawna wersja 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.

Zrzut ekranu przedstawiający przyznawanie uprawnień usługi Key Vault.

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 identity type 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 nieodwracalne. 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 — aktualizowanie "keyVaultProperties" właściwości w klastrze i pomijanie "keyVersion" właściwości lub ustawianie jej na wartość "". Usługa Storage automatycznie używa najnowszej wersji klucza.
  • Jawna aktualizacja wersji klucza — zaktualizuj "keyVaultProperties" właściwości i zaktualizuj wersję klucza we "keyVersion" właściwości. Rotacja kluczy wymaga jawnej "keyVersion" aktualizacji właściwości w klastrze. Aby uzyskać więcej informacji, 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 klucza 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 podczas i po operacji rotacji klucza. 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.

Zrzut ekranu przedstawiający zapisywanie skoroszytu.

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.

  • Skrytka nie ma zastosowania do tabel z planem pomocniczym.

  • 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 kluczy 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 identity type 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.

  • Plan tabeli pomocniczej nie obsługuje kluczy zarządzanych przez klienta. Dane w tabelach z planem pomocniczym są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft, nawet jeśli dane są chronione w pozostałej części obszaru roboczego usługi Log Analytics przy użyciu własnego klucza szyfrowania.

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 usługi Key Vault — częstotliwość, z jaką magazyn klastra 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.

  • Łączenie obszaru roboczego z klastrem kończy się niepowodzeniem, jeśli obszar roboczy jest połączony z innym klastrem.

  • Jeśli utworzysz klaster i natychmiast określisz właściwość KeyVaultProperties, operacja może zakończyć się niepowodzeniem, dopóki tożsamość nie zostanie przypisana do klastra i udzielona 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 procesie usuwania.

Następne kroki