Projektowanie wdrożenia dzienników usługi Azure Monitor

Usługa Azure Monitor przechowuje dane dziennika w obszarze roboczym usługi Log Analytics, który jest zasobem platformy Azure i kontenerem, w którym dane są zbierane, agregowane i służą jako granica administracyjna. Chociaż możesz wdrożyć co najmniej jeden obszar roboczy w ramach subskrypcji platformy Azure, istnieje kilka zagadnień, które należy zrozumieć, aby upewnić się, że początkowe wdrożenie jest zgodnie z naszymi wytycznymi w celu zapewnienia ekonomicznego, możliwego do zarządzania i skalowalnego wdrożenia spełniającego potrzeby organizacji.

Dane w obszarze roboczym są zorganizowane w tabele, z których każdy przechowuje różne rodzaje danych i ma własny unikatowy zestaw właściwości na podstawie zasobu generującego dane. Większość źródeł danych będzie zapisywać własne tabele w obszarze roboczym usługi Log Analytics.

Example workspace data model

Obszar roboczy usługi Log Analytics zapewnia:

  • Lokalizacja geograficzna magazynu danych.
  • Izolacja danych przez przyznanie różnym użytkownikom praw dostępu po jednej z naszych zalecanych strategii projektowania.
  • Zakres konfiguracji ustawień, takich jak warstwa cenowa, przechowywanie i ograniczenie danych.

Obszary robocze są hostowane w klastrach fizycznych. Domyślnie system tworzy te klastry i zarządza nimi. Oczekuje się, że klienci, którzy pozyskają więcej niż 4 TB/dzień, będą tworzyć własne dedykowane klastry dla swoich obszarów roboczych — umożliwia im lepszą kontrolę i większą szybkość pozyskiwania.

Ten artykuł zawiera szczegółowe omówienie zagadnień dotyczących projektowania i migracji, omówienie kontroli dostępu i zrozumienie implementacji projektu, które zalecamy dla twojej organizacji IT.

Ważne zagadnienia dotyczące strategii kontroli dostępu

Określenie liczby potrzebnych obszarów roboczych ma wpływ na co najmniej jedno z następujących wymagań:

  • Jesteś firmą globalną i potrzebujesz danych dzienników przechowywanych w określonych regionach ze względu na niezależność danych lub zgodność.
  • Korzystasz z platformy Azure i chcesz uniknąć naliczania opłat za transfer danych wychodzących przez umieszczenie obszaru roboczego w tym samym regionie co zarządzane przez niego zasoby platformy Azure.
  • Zarządzasz wieloma działami lub grupami biznesowymi i chcesz, aby każdy z nich widział własne dane, ale nie dane od innych. Ponadto nie ma wymagania biznesowego dla skonsolidowanego widoku między działami lub grupami biznesowymi.

Organizacje IT są obecnie modelowane zgodnie ze scentralizowanym, zdecentralizowanym lub między hybrydowym obu struktur. W związku z tym następujące modele wdrażania obszaru roboczego były często używane do mapowania na jedną z tych struktur organizacyjnych:

  • Scentralizowane: wszystkie dzienniki są przechowywane w centralnym obszarze roboczym i administrowane przez jeden zespół, a usługa Azure Monitor zapewnia zróżnicowany dostęp dla poszczególnych zespołów. W tym scenariuszu można łatwo zarządzać, przeszukiwać zasoby i dzienniki skorelowane krzyżowo. Obszar roboczy może znacznie rosnąć w zależności od ilości danych zebranych z wielu zasobów w ramach subskrypcji, a dodatkowe koszty administracyjne umożliwiają utrzymanie kontroli dostępu do różnych użytkowników. Ten model jest znany jako "piasta i szprycha".
  • Zdecentralizowane: każdy zespół ma własny obszar roboczy utworzony w grupie zasobów, którą posiadają i którymi zarządza, a dane dzienników są segregowane na zasób. W tym scenariuszu obszar roboczy może być bezpieczny, a kontrola dostępu jest spójna z dostępem do zasobów, ale trudno jest skorelować dzienniki krzyżowe. Użytkownicy, którzy potrzebują szerokiego widoku wielu zasobów, nie mogą analizować danych w zrozumiały sposób.
  • Hybrydowe: Wymagania dotyczące zgodności inspekcji zabezpieczeń dodatkowo komplikują ten scenariusz, ponieważ wiele organizacji implementuje oba modele wdrażania równolegle. Często powoduje to złożoną, kosztowną i trudną do utrzymania konfigurację z lukami w zakresie dzienników.

W przypadku używania agentów usługi Log Analytics do zbierania danych należy zrozumieć następujące kwestie, aby zaplanować wdrożenie agenta:

Jeśli używasz programu System Center Operations Manager 2012 R2 lub nowszego:

  • Każda grupa zarządzania programu Operations Manager może być połączona tylko z jednym obszarem roboczym.
  • Komputery z systemem Linux raportowania do grupy zarządzania muszą być skonfigurowane do raportowania bezpośrednio do obszaru roboczego usługi Log Analytics. Jeśli komputery z systemem Linux są już raportowane bezpośrednio do obszaru roboczego i chcesz monitorować je za pomocą programu Operations Manager, wykonaj następujące kroki, aby zgłosić raport do grupy zarządzania programu Operations Manager.
  • Agenta usługi Log Analytics Windows można zainstalować na komputerze Windows i udostępnić raport zarówno do programu Operations Manager zintegrowanego z obszarem roboczym, jak i innego obszaru roboczego.

Omówienie kontroli dostępu

Dzięki kontroli dostępu opartej na rolach platformy Azure (RBAC) na platformie Azure można udzielać użytkownikom i grupom tylko ilości dostępu potrzebnego do pracy z danymi monitorowania w obszarze roboczym. Dzięki temu można dopasować model operacyjny organizacji IT przy użyciu jednego obszaru roboczego do przechowywania zebranych danych włączonych na wszystkich zasobach. Na przykład udzielasz dostępu zespołowi odpowiedzialnemu za usługi infrastruktury hostowane na maszynach wirtualnych platformy Azure i w rezultacie będą miały dostęp tylko do dzienników generowanych przez maszyny wirtualne. Następuje to zgodnie z naszym nowym modelem dziennika kontekstu zasobów. Podstawą tego modelu jest każdy rekord dziennika emitowany przez zasób platformy Azure, jest automatycznie skojarzony z tym zasobem. Dzienniki są przekazywane do centralnego obszaru roboczego, który uwzględnia zakres i kontrolę RBAC platformy Azure na podstawie zasobów.

Dane, do których użytkownik ma dostęp, są określane przez kombinację czynników wymienionych w poniższej tabeli. Każdy z nich jest opisany w poniższych sekcjach.

Czynnik Opis
Tryb dostępu Metoda używana przez użytkownika do uzyskiwania dostępu do obszaru roboczego. Definiuje zakres dostępnych danych i zastosowany tryb kontroli dostępu.
Tryb kontroli dostępu Ustawienie w obszarze roboczym, który określa, czy uprawnienia są stosowane na poziomie obszaru roboczego lub zasobu.
Uprawnienia Uprawnienia stosowane do poszczególnych lub grup użytkowników dla obszaru roboczego lub zasobu. Określa dane, do których użytkownik będzie miał dostęp.
Kontrola dostępu oparta na rolach platformy Azure na poziomie tabeli Opcjonalne szczegółowe uprawnienia, które mają zastosowanie do wszystkich użytkowników niezależnie od trybu dostępu lub trybu kontroli dostępu. Określa typy danych, do których użytkownik może uzyskiwać dostęp.

Tryb dostępu

Tryb dostępu odnosi się do sposobu, w jaki użytkownik uzyskuje dostęp do obszaru roboczego usługi Log Analytics i definiuje zakres danych, do których mogą uzyskiwać dostęp.

Użytkownicy mają dwie opcje uzyskiwania dostępu do danych:

  • Kontekst obszaru roboczego: możesz wyświetlić wszystkie dzienniki w obszarze roboczym, do którego masz uprawnienia. Zapytania w tym trybie są ograniczone do wszystkich danych we wszystkich tabelach w obszarze roboczym. Jest to tryb dostępu używany podczas uzyskiwania dostępu do dzienników z obszarem roboczym jako zakresu, na przykład po wybraniu pozycji Dzienniki z menu usługi Azure Monitor w Azure Portal.

    Log Analytics context from workspace

  • Kontekst zasobów: w przypadku uzyskiwania dostępu do obszaru roboczego dla określonego zasobu, grupy zasobów lub subskrypcji, na przykład po wybraniu pozycji Dzienniki z menu zasobów w Azure Portal, możesz wyświetlić dzienniki tylko dla zasobów we wszystkich tabelach, do których masz dostęp. Zapytania w tym trybie są ograniczone tylko do danych skojarzonych z tym zasobem. Ten tryb umożliwia również szczegółową kontrolę dostępu opartą na rolach platformy Azure.

    Log Analytics context from resource

    Uwaga

    Dzienniki są dostępne dla zapytań kontekstowych zasobów tylko wtedy, gdy zostały prawidłowo skojarzone z odpowiednim zasobem. Obecnie następujące zasoby mają ograniczenia:

    Możesz sprawdzić, czy dzienniki są prawidłowo skojarzone z ich zasobem, uruchamiając zapytanie i sprawdzając interesujące Cię rekordy. Jeśli prawidłowy identyfikator zasobu znajduje się we właściwości _ResourceId , dane są dostępne dla zapytań skoncentrowanych na zasobach.

Usługa Azure Monitor automatycznie określa odpowiedni tryb w zależności od kontekstu, z którego wykonujesz wyszukiwanie dzienników. Zakres jest zawsze prezentowany w lewej górnej sekcji usługi Log Analytics.

Porównywanie trybów dostępu

Poniższa tabela zawiera podsumowanie trybów dostępu:

Problem Kontekst obszaru roboczego Kontekst zasobu
KtoTo jest przeznaczony dla każdego modelu? Administracja centralna. Administratorzy, którzy muszą skonfigurować zbieranie danych i użytkowników, którzy potrzebują dostępu do szerokiej gamy zasobów. Obecnie wymagane jest również dla użytkowników, którzy muszą uzyskiwać dostęp do dzienników zasobów spoza platformy Azure. Zespoły aplikacji. Administratorzy monitorowanych zasobów platformy Azure.
Co użytkownik wymaga wyświetlania dzienników? Uprawnienia do obszaru roboczego. Zobacz Uprawnienia obszaru roboczego w temacie Zarządzanie dostępem przy użyciu uprawnień obszaru roboczego. Odczyt dostępu do zasobu. Zobacz Uprawnienia zasobów w temacie Zarządzanie dostępem przy użyciu uprawnień platformy Azure. Uprawnienia można dziedziczyć (na przykład z zawierającej grupę zasobów) lub bezpośrednio przypisać do zasobu. Uprawnienia do dzienników zasobu zostaną automatycznie przypisane.
Jaki jest zakres uprawnień? Obszaru roboczego. Użytkownicy z dostępem do obszaru roboczego mogą wykonywać zapytania dotyczące wszystkich dzienników w obszarze roboczym z tabel, do których mają uprawnienia. Zobacz Kontrola dostępu do tabel Zasób platformy Azure. Użytkownik może wykonywać zapytania dotyczące dzienników dla określonych zasobów, grup zasobów lub subskrypcji, do których mają dostęp z dowolnego obszaru roboczego, ale nie może wykonywać zapytań dotyczących dzienników dla innych zasobów.
Jak użytkownik może uzyskiwać dostęp do dzienników?
  • Uruchom dzienniki z menu usługi Azure Monitor .
  • Uruchom dzienniki z obszarów roboczych usługi Log Analytics.
  • Uruchamianie dzienników z menu zasobu platformy Azure
  • Uruchom dzienniki z menu usługi Azure Monitor .
  • Uruchom dzienniki z obszarów roboczych usługi Log Analytics.

Tryb kontroli dostępu

Tryb kontroli dostępu to ustawienie w każdym obszarze roboczym, które definiuje sposób określania uprawnień dla obszaru roboczego.

  • Wymagaj uprawnień obszaru roboczego: ten tryb sterowania nie zezwala na szczegółową kontrolę dostępu na podstawie ról platformy Azure. Aby użytkownik mógł uzyskać dostęp do obszaru roboczego, musi mieć przyznane uprawnienia do obszaru roboczego lub określonych tabel.

    Jeśli użytkownik uzyskuje dostęp do obszaru roboczego po trybie kontekstu obszaru roboczego, ma dostęp do wszystkich danych w dowolnej tabeli, do której udzielono im dostępu. Jeśli użytkownik uzyskuje dostęp do obszaru roboczego zgodnie z trybem kontekstu zasobu, ma dostęp tylko do danych dla tego zasobu w dowolnej tabeli, do której udzielono im dostępu.

    Jest to ustawienie domyślne dla wszystkich obszarów roboczych utworzonych przed marcem 2019 r.

  • Użyj uprawnień zasobu lub obszaru roboczego: ten tryb sterowania umożliwia szczegółową kontrolę dostępu na podstawie ról platformy Azure. Użytkownicy mogą mieć dostęp tylko do danych skojarzonych z zasobami, które mogą wyświetlać, przypisując uprawnienie platformy Azure read .

    Gdy użytkownik uzyskuje dostęp do obszaru roboczego w trybie kontekstu obszaru roboczego, mają zastosowanie uprawnienia obszaru roboczego. Gdy użytkownik uzyskuje dostęp do obszaru roboczego w trybie kontekstu zasobu, weryfikowane są tylko uprawnienia zasobów, a uprawnienia obszaru roboczego są ignorowane. Włącz kontrolę dostępu opartą na rolach platformy Azure dla użytkownika, usuwając je z uprawnień obszaru roboczego i zezwalając na rozpoznawanie uprawnień do zasobów.

    Jest to ustawienie domyślne dla wszystkich obszarów roboczych utworzonych po marcu 2019 r.

    Uwaga

    Jeśli użytkownik ma tylko uprawnienia do zasobu w obszarze roboczym, może uzyskać dostęp tylko do obszaru roboczego przy użyciu trybu kontekstu zasobu przy założeniu, że tryb dostępu do obszaru roboczego ma wartość Użyj uprawnień do zasobu lub obszaru roboczego.

Aby dowiedzieć się, jak zmienić tryb kontroli dostępu w portalu za pomocą programu PowerShell lub przy użyciu szablonu Resource Manager, zobacz Konfigurowanie trybu kontroli dostępu.

Limit szybkości skalowania i pozyskiwania

Azure Monitor to usługa danych o wysokiej skali, która obsługuje tysiące klientów wysyłających petabajty danych każdego miesiąca w rosnącym tempie. Obszary robocze nie są ograniczone w ich przestrzeni dyskowej i mogą rosnąć do petabajtów danych. Nie ma potrzeby dzielenia obszarów roboczych z powodu skalowania.

Aby chronić i odizolować klientów usługi Azure Monitor i jej infrastruktury zaplecza, istnieje domyślny limit szybkości pozyskiwania, który jest przeznaczony do ochrony przed wzrostami i powodziami. Wartość domyślna limitu szybkości wynosi około 6 GB/minutę i została zaprojektowana tak, aby umożliwić normalne pozyskiwanie. Aby uzyskać więcej informacji na temat pomiaru limitu ilości pozyskiwania, zobacz Limity usługi Azure Monitor.

Klienci, którzy pozyskiwają mniej niż 4 TB/dzień, zwykle nie spełniają tych limitów. Klienci, którzy pozyskiwają wyższe ilości lub mają skoki w ramach normalnych operacji, rozważą przejście do dedykowanych klastrów , w których można podnieść limit szybkości pozyskiwania.

Po aktywowaniu limitu szybkości pozyskiwania lub przejściu do 80% progu zdarzenie zostanie dodane do tabeli Operacje w obszarze roboczym. Zaleca się monitorowanie go i tworzenie alertu. Zobacz więcej szczegółów dotyczących szybkości pozyskiwania danych.

Zalecenia

Resource-context design example

Ten scenariusz obejmuje pojedynczy projekt obszaru roboczego w subskrypcji organizacji IT, która nie jest ograniczona przez niezależność danych lub zgodność z przepisami, lub musi być mapowana na regiony, w których są wdrażane zasoby. Umożliwia ona zespołom ds. zabezpieczeń i administratorów IT organizacji możliwość korzystania z ulepszonej integracji z zarządzaniem dostępem do platformy Azure i bezpieczniejszą kontrolą dostępu.

Wszystkie zasoby, rozwiązania do monitorowania i Szczegółowe informacje, takie jak application Szczegółowe informacje i vm insights, obsługa infrastruktury i aplikacji obsługiwanych przez różne zespoły są skonfigurowane do przekazywania zebranych danych dziennika do scentralizowanego udostępnionego obszaru roboczego organizacji IT. Użytkownicy w każdym zespole mają dostęp do dzienników dla zasobów, do których otrzymali dostęp.

Po wdrożeniu architektury obszaru roboczego możesz wymusić to w zasobach platformy Azure przy użyciu Azure Policy. Zapewnia ona sposób definiowania zasad i zapewniania zgodności z zasobami platformy Azure, aby wysyłać wszystkie dzienniki zasobów do określonego obszaru roboczego. Na przykład w przypadku maszyn wirtualnych platformy Azure lub zestawów skalowania maszyn wirtualnych można użyć istniejących zasad, które oceniają zgodność obszaru roboczego i raportują wyniki, lub dostosować je do korygowania, jeśli nie są zgodne.

Strategia migracji konsolidacji obszarów roboczych

W przypadku klientów, którzy już wdrożyli wiele obszarów roboczych i są zainteresowani konsolidacją modelu dostępu do kontekstu zasobów, zalecamy zastosowanie przyrostowego podejścia do migracji do zalecanego modelu dostępu i nie próbujesz osiągnąć tego szybko lub agresywnie. Zgodnie z etapowym podejściem do planowania, migrowania, weryfikowania i wycofywania zgodnie z rozsądną osią czasu pomoże uniknąć nieplanowanych zdarzeń lub nieoczekiwanego wpływu na operacje w chmurze. Jeśli nie masz zasad przechowywania danych ze względu na zgodność lub przyczyny biznesowe, musisz ocenić odpowiedni czas przechowywania danych w obszarze roboczym, z którego przeprowadzasz migrację podczas procesu. Podczas ponownego konfigurowania zasobów w celu raportowania do udostępnionego obszaru roboczego możesz nadal analizować dane w oryginalnym obszarze roboczym w razie potrzeby. Po zakończeniu migracji, jeśli zarządzasz przechowywaniem danych w oryginalnym obszarze roboczym przed końcem okresu przechowywania, nie usuwaj ich.

Podczas planowania migracji do tego modelu rozważ następujące kwestie:

  • Dowiedz się, jakie przepisy branżowe i zasady wewnętrzne dotyczące przechowywania danych muszą być zgodne.
  • Upewnij się, że zespoły aplikacji mogą pracować w ramach istniejącej funkcjonalności kontekstu zasobów.
  • Zidentyfikuj dostęp przyznany zasobom dla zespołów aplikacji i przetestuj je w środowisku deweloperskim przed wdrożeniem w środowisku produkcyjnym.
  • Skonfiguruj obszar roboczy, aby włączyć uprawnienia Użyj zasobu lub obszaru roboczego.
  • Usuń uprawnienia zespołów aplikacji do odczytu i wykonywania zapytań dotyczących obszaru roboczego.
  • Włącz i skonfiguruj wszystkie rozwiązania do monitorowania, Szczegółowe informacje, takie jak szczegółowe informacje o kontenerze i/lub Azure Monitor dla maszyn wirtualnych, konta usługi Automation i rozwiązania do zarządzania, takie jak Rozwiązanie Update Management, uruchamianie/zatrzymywanie maszyn wirtualnych itp., które zostały wdrożone w oryginalnym obszarze roboczym.

Następne kroki

Aby zaimplementować uprawnienia i mechanizmy kontroli zabezpieczeń zalecane w tym przewodniku, zapoznaj się z artykułem Zarządzanie dostępem do dzienników.