Udostępnij za pośrednictwem

Klucze zarządzane przez klienta w usłudze Azure Monitor

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 w obszarach roboczych. Klucze zarządzane przez klienta w usłudze Azure Monitor zapewniają kontrolę nad cyklem życia klucza szyfrowania i dostępem do dzienników. Po skonfigurowaniu nowe dane pozyskane z połączonych obszarów roboczych są szyfrowane przy użyciu klucza w usłudze Azure Key Vault lub zarządzanego modułu HSM usługi Azure Key Vault (sprzętowego modułu zabezpieczeń).

Omówienie klucza zarządzanego przez klienta

Szyfrowanie danych magazynowanych jest typowym wymaganiem dotyczącym prywatności i zabezpieczeń w organizacjach. Możesz pozwolić platformie Azure na kompletne zarządzanie szyfrowaniem danych spoczynkowych lub skorzystać z różnych opcji, aby ściśle zarządzać 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 kontrolować cykl życia klucza z możliwością odwoływania dostępu do danych, zaszyfruj dane przy użyciu własnego klucza w usłudze Azure Key Vault lub w Azure Key Vault Managed HSM. Funkcja kluczy zarządzanych przez klienta jest dostępna w dedykowanych klastrach i zapewnia wyższy poziom ochrony i kontroli.

Dane pozyskane do dedykowanych klastrów są szyfrowane dwa razy — 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 naruszono bezpieczeństwo jednego z algorytmów szyfrowania lub kluczy. 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 zarządzanych przez firmę 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 opierającego się na zobowiązaniu, wynoszącym 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 klucza w usłudze Azure Key Vault. Tożsamość klastrów w usłudze Log Analytics jest obsługiwana na poziomie klastra. Aby umożliwić użycie kluczy zarządzanych przez klienta w wielu obszarach roboczych, zasób klastra Log Analytics działa jako pośrednie połączenie tożsamości między Key Vault a obszarami roboczymi 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 identitytype jest ustawione na SystemAssigned. Ta tożsamość jest później używana do przyznania dostępu do magazynu w Twoim 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 identitytype jest ustawiona na UserAssigned, i udzielanie jej uprawnień w usłudze Key Vault przed utworzeniem klastra.

Skonfiguruj klucze zarządzane przez klienta w nowym klastrze lub w istniejącym dedykowanym klastrze z połączonymi obszarami roboczymi do pozyskiwania danych. Odłączanie obszarów roboczych z klastra można wykonywać w dowolnym momencie. Nowe dane pozyskane z połączonych obszarów roboczych są szyfrowane przy użyciu klucza, a starsze dane pozostają zaszyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft. Konfiguracja nie przerywa pozyskiwania ani zapytań, w których zapytania są wykonywane w starych i nowych danych bezproblemowo. Po odłączeniu obszarów roboczych z klastra nowe pozyskane dane są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft.

Ważne

Możliwość kluczy zarządzanych przez klienta jest regionalna. Usługa Azure Key Vault, dedykowany 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 przegląd 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 bazowego dedykowanego magazynu klastra
  3. Dedykowany klaster
  4. Obszary robocze połączone z dedykowanym klastrem

Typy kluczy szyfrowania

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

  • KEK — klucz szyfrowania kluczy (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, nazywanego kluczem AEK.
  • Klucz AEK jest używany do wyprowadzania DEK, czyli kluczy, które służą do szyfrowania każdego bloku danych zapisywanego na dysku.
  • Podczas konfigurowania klucza KEK zarządzanego przez klienta w klastrze przechowywanie klastra wykonuje wrap żądania dotyczące usługi Key Vault w celu szyfrowania i unwrap odszyfrowywania AEK.
  • Twój KEK nigdy nie opuszcza Key Vault. Jeśli klucz jest przechowywany w zarządzanym module HSM usługi Azure Key Vault, nigdy nie opuszcza tego sprzętu.
  • Usługa Azure Storage używa tożsamości zarządzanej skojarzonej z klastrem do uwierzytelniania. Uzyskuje dostęp do usługi Azure Key Vault za pośrednictwem identyfikatora Entra firmy Microsoft.

Kroki konfiguracji klucza zarządzanego przez klienta

  1. Tworzenie usługi Azure Key Vault i przechowywanie klucza
  2. Tworzenie dedykowanego klastra
  3. Udzielanie uprawnień do usługi Key Vault
  4. Aktualizowanie dedykowanego klastra z wykorzystaniem szczegółów kluczowych identyfikatorów
  5. Łączenie obszarów roboczych

Konfiguracja klucza zarządzanego przez klienta nie obsługuje konfigurowania szczegółów tożsamości i identyfikatora klucza. Wykonaj tę operację za pomocą programu PowerShell, interfejsu wiersza polecenia lub żądań REST .

Wymagane uprawnienia

Aby wykonać akcje związane z klastrem, potrzebne są następujące uprawnienia:

Akcja Wymagane uprawnienia lub rola
Tworzenie dedykowanego klastra Microsoft.Resources/deployments/*i Microsoft.OperationalInsights/clusters/write uprawnienia, jak przewidziano w wbudowanej roli Log Analytics Contributor, na przykład
Zmienianie właściwości klastra Microsoft.OperationalInsights/clusters/write uprawnienia, jakie przewiduje wbudowana rola Log Analytics Contributor, na przykład
Łączenie obszarów roboczych z klastrem Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write i Microsoft.OperationalInsights/workspaces/linkedservices/write uprawnienia dostarczone przez wbudowaną rolę Współautor usługi Log Analytics, na przykład
Sprawdź stan łącza obszaru roboczego Microsoft.OperationalInsights/workspaces/readuprawnienia do obszaru roboczego, zgodnie z wbudowaną rolą Czytelnik usługi Log Analytics, na przykład
Pobierz klastry lub sprawdź stan udostępniania klastra Microsoft.OperationalInsights/clusters/readuprawnienia, jak przewidziano we wbudowanej roli Log Analytics Reader, na przykład
Aktualizowanie poziomu zobowiązania lub typu fakturowania w klastrze Microsoft.OperationalInsights/clusters/write uprawnienia, jakie przewiduje wbudowana rola Log Analytics Contributor, na przykład
Udzielanie wymaganych uprawnień Rola właściciela lub współautora, która ma */write uprawnienia, lub wbudowaną rolę Współautor usługi Log Analytics, która ma Microsoft.OperationalInsights/* uprawnienia
Odłączanie obszaru roboczego z klastra Microsoft.OperationalInsights/workspaces/linkedServices/delete uprawnienia, jakie przewiduje wbudowana rola Log Analytics Contributor, na przykład
Usuwanie dedykowanego klastra Microsoft.OperationalInsights/clusters/delete uprawnienia, jakie przewiduje wbudowana rola Log Analytics Contributor, na przykład

Przechowywanie klucza szyfrowania ("KEK")

Portfolio produktów Azure Key Management przedstawia magazyny i zarządzane moduły 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 odzyskiwalna, aby chronić klucz i dostęp do danych w usłudze Azure Monitor. Tę konfigurację można sprawdzić we właściwościach w usłudze Key Vault. Powinny być włączone zarówno miękkie usuwanie, jak i ochrona przed nieodwracalnym usunięciem.

Ważne

Zaleca się skonfigurowanie powiadomienia za pośrednictwem usługi Azure Event Grid w celu efektywnego reagowania na zdarzenia usługi Azure Key Vault, takie jak klucz zbliżający się do wygaśnięcia. Po wygaśnięciu klucza pozyskiwanie i zapytania nie mają wpływu, ale nie można zaktualizować klucza w klastrze. Wykonaj następujące kroki, aby rozwiązać ten problem

  1. Zidentyfikuj klucz używany na stronie przeglądu klastra w portalu Azure w Widoku JSON
  2. Rozszerzanie daty wygaśnięcia klucza w usłudze Azure Key Vault
  3. Zaktualizuj klaster przy użyciu aktywnego klucza, najlepiej z wartością wersji "", aby zawsze używać najnowszej wersji automatycznie

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

Na przykład dodaj te właściwości w treści żądania 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 przetwarzaniu danych lub zapytaniach, przy uwzględnieniu następujących uwag:

  • Nie można jednocześnie zaktualizować klucza i tożsamości dla klastra. Wykonaj aktualizację w dwóch następujących operacjach.
  • Podczas aktualizacji SystemAssigned do UserAssigned, najpierw udziel UserAssign tożsamości w usłudze Key Vault, a następnie zaktualizuj w klastrze.
  • Podczas aktualizacji UserAssigned do SystemAssigned, najpierw udziel SystemAssigned tożsamości w usłudze Key Vault, a następnie zaktualizuj w klastrze.

Postępuj zgodnie z procedurą opisaną w artykule dotyczącym dedykowanego klastra.

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 podstawowego — kontrola dostępu oparta na rolach (Azure RBAC) oraz zasady dostępu do Key Vault (wersja klasyczna).

  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 Key Vault w portalu Azure i wybierz Ustawienia>konfigurację dostępu>opartą na rolach platformy Azure i kliknij Zastosuj.
    2. Wybierz pozycję Przejdź do kontroli dostępu (zarządzanie tożsamościami i dostępem) i dodaj przypisanie roli Użytkownika kryptograficznej usługi szyfrowania Key Vault.
    3. Wybierz Tożsamość zarządzana na karcie Członkowie, a następnie wybierz subskrypcję oraz tożsamość jako członka.

    Zrzut ekranu uprawnień RBAC dla Key Vault.

  2. Przypisz zasady dostępu do skarbca (starsza wersja)

    Otwórz swój Key Vault w portalu Azure i wybierz pozycję Zasady dostępu>Zasady dostępu do magazynu>+ Dodaj zasady dostępu, aby utworzyć zasady z następującymi ustawieniami:

    • Uprawnienia klucza — wybierz pozycję Pobierz>Zawiń klucz i Rozwiń klucz.
    • Wybierz główną tożsamość w zależności od typu tożsamości używanego w klastrze (zarządzana tożsamość przypisana przez system lub użytkownika).
      • Tożsamość zarządzana przypisana przez system — wprowadź nazwę klastra lub identyfikator podmiotu głównego klastra
      • Tożsamość zarządzana przypisana przez użytkownika — wprowadź nazwę tej tożsamości

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

    Aby zweryfikować, czy Key Vault jest skonfigurowany jako odzyskiwalny w celu ochrony klucza i dostępu do danych usługi Azure Monitor, wymagane jest uprawnienie Get.

Aktualizacja klastra z użyciem szczegółowych informacji o identyfikatorze klucza

Wszystkie operacje w klastrze wymagają Microsoft.OperationalInsights/clusters/write uprawnienia akcji. Uprawnienie to można udzielić za pośrednictwem właściciela lub współautora, który zawiera akcję */write, lub poprzez rolę współautora Log Analytics, która zawiera akcję Microsoft.OperationalInsights/*.

Ten krok aktualizuje dedykowaną pamięć klastra, dodając klucz i wersję do użycia dla AEKwrap i unwrap.

Ważne

  • Rotacja kluczy może być automatyczna lub na podstawie jawnej wersji klucza. Zobacz sekcję Rotacja kluczy, aby określić odpowiednie podejście 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 kwestie, aktualizacja powinna być wykonana w dwóch kolejnych operacjach.

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

Zaktualizuj KeyVaultProperties w klastrze za pomocą szczegółów identyfikatora klucza.

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

Nie dotyczy

Ważne

Ten krok należy wykonać tylko po udostępnieniu klastra. Jeśli połączysz obszary robocze i zaimportujesz dane przed przydzieleniem zasobów, zaimportowane dane zostaną porzucone i nie można ich odzyskać.

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

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 None również powoduje odwołanie dostępu do danych, ale takie działanie nie jest zalecane, ponieważ nie można go cofnąć bez kontaktu z pomocą techniczną.

Magazyn klastra zawsze respektuje zmiany uprawnień klucza w ciągu godziny lub wcześniej, po czym magazyn staje się niedostępny. Nowe dane pozyskane z połączonych obszarów roboczych są usuwane i nie do odzyskania. Dane są niedostępne w tych obszarach roboczych i zapytania kończą się niepowodzeniem. Wcześniej pozyskane dane pozostają w magazynie, jeśli Twój klaster i Twoje obszary robocze nie zostaną usunięte. Zasady przechowywania danych określają niedostępne dane i czyszczą je 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 okresowo próbuje uzyskać dostęp do usługi Key Vault w celu wykonania operacji wrap i unwrap. Po włączeniu klucza i gdy unwrap powiedzie się, dane SSD są ponownie ładowane z magazynu. Pozyskiwanie danych i funkcjonalność zapytań są wznawiane w ciągu 30 minut.

Rotacja kluczy

Rotacja kluczy ma dwa tryby:

  • Autorotacja — aktualizuj "keyVaultProperties" właściwości w klastrze i pomiń "keyVersion" właściwość lub ustaw ją na "". 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. Przełączanie kluczy wymaga jawnej aktualizacji właściwości "keyVersion" w klastrze. Aby uzyskać więcej informacji, zobacz Aktualizowanie klastra ze szczegółami 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 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 składni zapytań lub komentarzach. Organizacje objęte rygorystycznymi wymaganiami prawnymi i zgodności muszą zachować takie informacje zaszyfrowane za pomocą klucza zarządzanego przez klienta. Usługa Azure Monitor umożliwia przechowywanie zapisanych zapytań, funkcji i alertów przeszukiwania dzienników zaszyfrowanych przy użyciu klucza na własnym koncie magazynu, gdy są połączone 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, Azure Logic Apps, notatniki Azure i runbooki automatyzacji.

Podczas łączenia konta magazynu dla zapisanych zapytań usługa przechowuje zapisane zapytania i zapytania alertów przeszukiwania dzienników na koncie magazynu. Kontrolując politykę szyfrowania danych w spoczynku na koncie magazynu, 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 magazynowym.

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

  • Musisz mieć „uprawnienia do zapisu” w obszarze roboczym i na koncie magazynowym.
  • Konto magazynowe musi być typu StorageV2 i znajdować się w tym samym regionie co obszar roboczy usługi Log Analytics.
  • Podczas łączenia konta magazynu dla zapisanych zapytań istniejące zapisane zapytania i funkcje są usuwane z obszaru roboczego w celu zachowania poufności informacji. Jeśli musisz mieć te zapytania i funkcje pod ręką, skopiuj istniejące zapisane zapytania i funkcje przed konfiguracją. Zapisane zapytania można wyświetlić przy użyciu programu PowerShell lub podczas eksportowania szablonu w obszarze Automatyzacja w obszarze roboczym.
  • Zapytania zapisane w pakiecie zapytań nie są przechowywane na połączonym koncie magazynu i nie mogą być szyfrowane przy użyciu klucza zarządzanego przez klienta. Zaleca się zapisanie jako zapytanie Legacy w celu ochrony zapytań przy użyciu klucza zarządzanego przez użytkownika.
  • Zapisane zapytania i funkcje na połączonym koncie usługi magazynowej uważane są za artefakty usługi, a ich format może ulec zmianie.
  • Zapytania "historia" i "przypięcie do pulpitu nawigacyjnego" nie są obsługiwane podczas łączenia konta magazynowego dla zapisanych kwerend.
  • Możesz połączyć jedno lub osobne konto magazynowe do zapisanych zapytań i zapytań dotyczących alertów wyszukiwania dzienników.
  • Aby utrzymać szyfrowanie zapytań i funkcji przy użyciu Twojego klucza, skonfiguruj połączone konto Storage Account za pomocą klucza zarządzanego przez klienta. Tę operację można wykonać podczas tworzenia konta magazynowego lub później.

Konfigurowanie połączonego konta magazynu dla zapisanych zapytań

Połącz konto magazynu, aby zapisywać zapytania i funkcje, oraz przechowywać zapisane zapytania i funkcje na koncie magazynu.

Uwaga

Operacja przenosi zapisane zapytania i funkcje z obszaru roboczego do tabeli w Twoim Koncie magazynu. Możesz odłączyć konto magazynu dla zapisanych zapytań, aby przenieść zapisane zapytania i funkcje z powrotem do obszaru roboczego. Odśwież przeglądarkę, jeśli nie zapisano zapytań lub funkcji nie są wyświetlane w witrynie Azure Portal po wykonaniu operacji.

Nie dotyczy

Po zakończeniu konfiguracji każde nowe zapisane wyszukiwanie zostanie zapisane w pamięci.

Skonfiguruj połączone konto magazynowe do zapytań o alerty przeszukiwania dziennika

Zagadnienia przed ustawieniem klucza zarządzanego przez klienta dla zapisanych zapytań alertów dziennika

  • Zapytania alertów są zapisywane jako obiekty blob na koncie magazynowym.
  • Wyzwolone alerty wyszukiwania dzienników nie zawierają wyników wyszukiwania ani zapytania alertu. Użyj wymiarów alertów , aby uzyskać kontekst dla wyzwolonych alertów.
  • Aby zapewnić szyfrowanie zapytań i funkcji przy użyciu twojego klucza, skonfiguruj połączone konto magazynowe przy użyciu klucza zarządzanego przez klienta. Tę operację można wykonać podczas tworzenia konta magazynowego lub później.

Połącz konto magazynu z alertami , aby zachować zapytania alertów przeszukiwania dzienników w swoim 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.

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

Dowiedz się więcej o Customer Lockbox w Microsoft Azure

Operacje kluczy zarządzanych 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

  • Pobierz wszystkie klastry w grupie zasobów
  • Pobierz wszystkie klastry w subskrypcji
  • Zaktualizuj rezerwację 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, aktualizacje powinny być wykonane w dwóch kolejnych operacjach.

  • Usługa Skrytka nie jest obecnie dostępna w Chinach.

  • Skrytka nie ma zastosowania do tabel z planem tabeli pomocniczej.

  • 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 GET żądanie do klastra i sprawdzając, czy wartość isDoubleEncryptionEnabled wynosi 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 miękkiego usunięcia, powróci on 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 z możliwością 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 None również powoduje odwołanie dostępu do danych, ale takie działanie nie jest zalecane, ponieważ nie można go cofnąć bez kontaktu z pomocą techniczną. Zalecanym sposobem odwołania dostępu do danych jest odwołanie klucza.

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

Rozwiązywanie problemów

  • Zachowanie w odniesieniu do dostępności usługi Key Vault

    • Zasoby w ramach normalnej pracy przechowują tymczasowo AEK i okresowo powracają do Key Vault unwrap.

    • Błędy połączenia z usługą Key Vault — system magazynowania obsługuje błędy przejściowe (tymczasowe przekroczenia limitu czasu, błędy połączeń, problemy z usługą DNS), umożliwiając pozostawanie kluczy w pamięci podręcznej podczas problemów z dostępnością, co pomaga przezwyciężać przestoje i problemy z dostępnością. Możliwości zapytań i pozyskiwania działają bez przerwy.

  • Częstotliwość dostępu do usługi Key Vault — częstotliwość, z jaką magazyn klastra uzyskuje dostęp do usługi Key Vault oraz wrap i unwrap operacje, wynosi od 6 do 60 sekund.

  • Jeśli zaktualizujesz klaster, gdy znajduje się on w stanie aprowizacji lub aktualizacji, aktualizacja zakończy się niepowodzeniem.

  • Jeśli wystąpi błąd powodujący konflikt podczas tworzenia klastra, klaster o tej samej nazwie mógł zostać usunięty w ciągu ostatnich 14 dni i jego nazwa zarezerwowana. Usunięte nazwy klastrów stają się dostępne 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 określisz KeyVaultProperties natychmiast, operacja może zakończyć się niepowodzeniem, dopóki tożsamość nie zostanie przypisana klastrowi i dostęp do Key Vault nie zostanie przyznany.

  • Jeśli zaktualizujesz istniejący klaster za pomocą KeyVaultProperties i Get, a w usłudze Key Vault brakuje zasad dostępu do kluczy, 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. Te mogą być 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 funkcjonalność zapytań. Zaktualizuj wersję klucza za pomocą '' notacji, aby zapewnić, że magazyn zawsze używa najnowszej wersji klucza automatycznie.

  • 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 GET żądanie do klastra lub obszaru roboczego i obserwując odpowiedź. Na przykład odłączony obszar roboczy nie ma clusterResourceId pod features.

  • Komunikaty o błędach

    Aktualizacja klastra

    • 400 — Klaster jest w stanie usuwania. Operacja asynchroniczna jest w trakcie realizacji. Klaster musi ukończyć swoją operację przed wykonaniem jakiejkolwiek operacji aktualizacji.
    • 400 - KeyVaultProperties nie jest pusty, 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 miękkie i ochronę przed usunięciem. 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.

    Pobierz klaster

    • 404 — Nie znaleziono klastra, klaster 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