Projektowanie architektury obszaru roboczego usługi Log Analytics

Artykuł
11/05/2024

Pojedynczy obszar roboczy usługi Log Analytics może być wystarczający dla wielu środowisk korzystających z usług Azure Monitor i Microsoft Sentinel. Jednak wiele organizacji tworzy wiele obszarów roboczych, aby zoptymalizować koszty i lepiej spełnić różne wymagania biznesowe. W tym artykule przedstawiono zestaw kryteriów określania, czy używać jednego obszaru roboczego, czy wielu obszarów roboczych. Omówiono również konfigurację i umieszczanie tych obszarów roboczych w celu spełnienia wymagań podczas optymalizowania kosztów.

Uwaga

W tym artykule omówiono usługi Azure Monitor i Microsoft Sentinel, ponieważ wielu klientów musi wziąć pod uwagę zarówno projekt. Większość kryteriów decyzyjnych ma zastosowanie do obu usług. Jeśli używasz tylko jednej z tych usług, możesz zignorować drugą w ocenie.

Oto film wideo na temat podstaw dzienników usługi Azure Monitor oraz najlepszych rozwiązań i zagadnień projektowych dotyczących projektowania wdrożenia dzienników usługi Azure Monitor:

Strategia projektowania

Projekt powinien zawsze rozpoczynać się od jednego obszaru roboczego, aby zmniejszyć złożoność zarządzania wieloma obszarami roboczymi i wykonywania zapytań dotyczących danych z nich. Brak ograniczeń wydajności dotyczących ilości danych w obszarze roboczym. Wiele usług i źródeł danych może wysyłać dane do tego samego obszaru roboczego. Podczas identyfikowania kryteriów tworzenia większej liczby obszarów roboczych projekt powinien używać najmniejszej liczby obszarów roboczych, aby spełnić wymagania.

Projektowanie konfiguracji obszaru roboczego obejmuje ocenę wielu kryteriów. Ale niektóre z kryteriów mogą być w konflikcie. Na przykład możesz zmniejszyć opłaty za ruch wychodzący, tworząc oddzielny obszar roboczy w każdym regionie świadczenia usługi Azure. Konsolidacja w jednym obszarze roboczym może pozwolić zmniejszyć opłaty jeszcze bardziej dzięki warstwie zobowiązania. Ocenianie każdego z kryteriów niezależnie. Zastanów się nad wymaganiami i priorytetami, aby określić, który projekt jest najbardziej efektywny dla danego środowiska.

Kryteria projektowania

W poniższej tabeli przedstawiono kryteria, które należy wziąć pod uwagę podczas projektowania architektury obszaru roboczego. Sekcje, które są zgodne z opisem kryteriów.

Kryterium	opis
Dane operacyjne i dane zabezpieczeń	Możesz połączyć dane operacyjne z usługi Azure Monitor w tym samym obszarze roboczym co dane zabezpieczeń z usługi Microsoft Sentinel lub oddzielić je od własnego obszaru roboczego. Połączenie ich zapewnia lepszą widoczność wszystkich danych, podczas gdy standardy zabezpieczeń mogą wymagać oddzielenia ich, aby zespół ds. zabezpieczeń miał dedykowany obszar roboczy. Może również mieć wpływ na koszty dla każdej strategii.
Dzierżawy platformy Azure	Jeśli masz wiele dzierżaw platformy Azure, zazwyczaj utworzysz obszar roboczy w każdym z nich. Kilka źródeł danych może wysyłać dane monitorowania tylko do obszaru roboczego w tej samej dzierżawie platformy Azure.
Regiony platformy Azure	Każdy obszar roboczy znajduje się w określonym regionie świadczenia usługi Azure. Mogą istnieć wymagania prawne lub wymagania dotyczące zgodności do przechowywania danych w określonych lokalizacjach.
Własność danych	Możesz utworzyć oddzielne obszary robocze w celu zdefiniowania własności danych. Można na przykład tworzyć obszary robocze według spółek zależnych lub powiązanych firm.
Dzielenie rozliczeń	Umieszczając obszary robocze w oddzielnych subskrypcjach, mogą być rozliczane dla różnych stron.
Przechowywanie danych	Dla każdego obszaru roboczego i każdej tabeli w obszarze roboczym można ustawić różne ustawienia przechowywania. Potrzebujesz oddzielnego obszaru roboczego, jeśli potrzebujesz różnych ustawień przechowywania dla różnych zasobów, które wysyłają dane do tych samych tabel.
Warstwy zobowiązania	Warstwy zobowiązania umożliwiają zmniejszenie kosztów pozyskiwania, zobowiązując się do minimalnej ilości danych dziennych w jednym obszarze roboczym.
Starsze ograniczenia agenta	Starsi agenci maszyn wirtualnych mają ograniczenia dotyczące liczby obszarów roboczych, z którymi mogą się łączyć.
Kontrola dostępu do danych	Skonfiguruj dostęp do obszaru roboczego oraz do różnych tabel i danych z różnych zasobów.
Sprężystość	Aby upewnić się, że dane w obszarze roboczym są dostępne w przypadku awarii regionu, można pozyskiwać dane do wielu obszarów roboczych w różnych regionach.

Dane operacyjne i dane zabezpieczeń

Decyzja o połączeniu danych operacyjnych z usługi Azure Monitor w tym samym obszarze roboczym co dane zabezpieczeń z usługi Microsoft Sentinel lub oddzielenie ich od własnego obszaru roboczego zależy od wymagań dotyczących zabezpieczeń i potencjalnych konsekwencji kosztów dla danego środowiska.

Dedykowane obszary robocze Tworzenie dedykowanych obszarów roboczych dla usług Azure Monitor i Microsoft Sentinel umożliwi oddzielenie własności danych między zespołami operacyjnymi i zespołami ds. zabezpieczeń. Takie podejście może również pomóc w optymalizacji kosztów, ponieważ gdy usługa Microsoft Sentinel jest włączona w obszarze roboczym, wszystkie dane w tym obszarze roboczym podlegają cenom usługi Microsoft Sentinel, nawet jeśli są to dane operacyjne zebrane przez usługę Azure Monitor.

Obszar roboczy z usługą Microsoft Sentinel pobiera trzy miesiące bezpłatnego przechowywania danych zamiast 31 dni. Ten scenariusz zwykle powoduje wyższe koszty danych operacyjnych w obszarze roboczym bez usługi Microsoft Sentinel. Zobacz Szczegóły cennika dzienników usługi Azure Monitor.

Połączony obszar roboczy Łączenie danych z usług Azure Monitor i Microsoft Sentinel w tym samym obszarze roboczym zapewnia lepszą widoczność wszystkich danych, co pozwala na łatwe łączenie zarówno zapytań, jak i skoroszytów. Jeśli dostęp do danych zabezpieczeń powinien być ograniczony do określonego zespołu, możesz użyć kontroli RBAC na poziomie tabeli, aby zablokować określonych użytkowników z tabel z danymi zabezpieczeń lub ograniczyć użytkownikom dostęp do obszaru roboczego przy użyciu kontekstu zasobów.

Ta konfiguracja może spowodować oszczędności kosztów, jeśli pomoże ci osiągnąć warstwę zobowiązania, która zapewnia rabat na opłaty za pozyskiwanie. Rozważmy na przykład organizację, która ma dane operacyjne i dane zabezpieczeń, które pozyskuje około 50 GB dziennie. Połączenie danych w tym samym obszarze roboczym umożliwiłoby warstwę zobowiązania na poziomie 100 GB dziennie. Ten scenariusz zapewni 15% rabatu na usługę Azure Monitor i 50% rabatu dla usługi Microsoft Sentinel.

Jeśli utworzysz oddzielne obszary robocze dla innych kryteriów, zwykle utworzysz więcej par obszarów roboczych. Jeśli na przykład masz dwie dzierżawy platformy Azure, możesz utworzyć cztery obszary robocze z obszarem roboczym operacyjnym i zabezpieczeń w każdej dzierżawie.

Jeśli korzystasz zarówno z usług Azure Monitor, jak i Microsoft Sentinel: rozważ oddzielenie każdego z nich w dedykowanym obszarze roboczym, jeśli jest to wymagane przez zespół ds. zabezpieczeń lub jeśli spowoduje to oszczędność kosztów. Rozważ połączenie tych dwóch elementów w celu lepszego wglądu w połączone dane monitorowania lub jeśli pomoże Ci osiągnąć warstwę zobowiązania.
Jeśli używasz zarówno usługi Microsoft Sentinel, jak i Microsoft Defender dla Chmury: rozważ użycie tego samego obszaru roboczego dla obu rozwiązań, aby zachować dane zabezpieczeń w jednym miejscu.

Dzierżawy platformy Azure

Większość zasobów może wysyłać dane monitorowania tylko do obszaru roboczego w tej samej dzierżawie platformy Azure. Maszyny wirtualne korzystające z agenta usługi Azure Monitor lub agentów usługi Log Analytics mogą wysyłać dane do obszarów roboczych w oddzielnych dzierżawach platformy Azure. Ten scenariusz można rozważyć jako dostawcę usług.

Jeśli masz jedną dzierżawę platformy Azure: utwórz jeden obszar roboczy dla tej dzierżawy.
Jeśli masz wiele dzierżaw platformy Azure: utwórz obszar roboczy dla każdej dzierżawy. Aby uzyskać inne opcje, w tym strategie dla dostawców usług, zobacz Wiele strategii dzierżawy.

Regiony platformy Azure

Każdy obszar roboczy usługi Log Analytics znajduje się w określonym regionie świadczenia usługi Azure. W celu przechowywania danych w określonym regionie mogą istnieć przepisy lub zgodność. Na przykład międzynarodowa firma może zlokalizować obszar roboczy w każdym głównym regionie geograficznym, takim jak Stany Zjednoczone i Europa.

Jeśli masz wymagania dotyczące przechowywania danych w określonej lokalizacji geograficznej: utwórz oddzielny obszar roboczy dla każdego regionu z takimi wymaganiami.
Jeśli nie masz wymagań dotyczących przechowywania danych w określonej lokalizacji geograficznej: użyj jednego obszaru roboczego dla wszystkich regionów.
Jeśli wysyłasz dane do lokalizacji geograficznej lub regionu spoza regionu obszaru roboczego, niezależnie od tego, czy zasób wysyłający znajduje się na platformie Azure: rozważ użycie obszaru roboczego w tej samej lokalizacji geograficznej lub regionie co dane.

Rozważ również potencjalne opłaty za przepustowość, które mogą mieć zastosowanie podczas wysyłania danych do obszaru roboczego z zasobu w innym regionie. Te opłaty są zwykle niewielkie w stosunku do kosztów pozyskiwania danych dla większości klientów. Te opłaty zwykle wynikają z wysyłania danych do obszaru roboczego z maszyny wirtualnej. Monitorowanie danych z innych zasobów platformy Azure przy użyciu ustawień diagnostycznych nie powoduje naliczania opłat za ruch wychodzący.

Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszt i określić, które regiony są potrzebne. Rozważ obszary robocze w wielu regionach, jeśli opłaty za przepustowość są znaczące.

Jeśli opłaty za przepustowość są wystarczająco znaczące, aby uzasadnić dodatkową złożoność: utwórz oddzielny obszar roboczy dla każdego regionu z maszynami wirtualnymi.
Jeśli opłaty za przepustowość nie są wystarczająco znaczące, aby uzasadnić dodatkową złożoność: użyj jednego obszaru roboczego dla wszystkich regionów.

Własność danych

Być może musisz segregować dane lub definiować granice na podstawie własności. Na przykład mogą istnieć różne spółki zależne lub powiązane firmy, które wymagają oddzielenia ich danych monitorowania.

Jeśli potrzebujesz segregacji danych: użyj oddzielnego obszaru roboczego dla każdego właściciela danych.
Jeśli nie potrzebujesz segregacji danych: użyj jednego obszaru roboczego dla wszystkich właścicieli danych.

Podział rozliczeń

Może być konieczne podzielenie rozliczeń między różnymi stronami lub wykonanie opłat z powrotem do klienta lub wewnętrznej jednostki biznesowej. Aby wyświetlić opłaty według obszaru roboczego, możesz użyć usługi Azure Cost Management + Billing . Możesz również użyć zapytania dziennika, aby wyświetlić rozliczany wolumin danych według zasobu platformy Azure, grupy zasobów lub subskrypcji. Takie podejście może być wystarczające dla wymagań dotyczących rozliczeń.

Jeśli nie musisz dzielić rozliczeń ani wykonywać obciążeń zwrotnych: użyj jednego obszaru roboczego dla wszystkich właścicieli kosztów.
Jeśli musisz podzielić rozliczenia lub wykonać obciążenie zwrotne: rozważ, czy usługa Azure Cost Management + Billing , czy zapytanie dziennika zapewnia raportowanie kosztów, które jest wystarczająco szczegółowe dla Twoich wymagań. Jeśli nie, użyj oddzielnego obszaru roboczego dla każdego właściciela kosztów.

Przechowywanie danych

Możesz skonfigurować domyślne ustawienia przechowywania danych dla obszaru roboczego lub skonfigurować różne ustawienia dla każdej tabeli. Może być wymagane różne ustawienia dla różnych zestawów danych w określonej tabeli. Jeśli tak, musisz oddzielić te dane do różnych obszarów roboczych, z których każde ma unikatowe ustawienia przechowywania.

Jeśli możesz użyć tych samych ustawień przechowywania dla wszystkich danych w każdej tabeli: użyj jednego obszaru roboczego dla wszystkich zasobów.
Jeśli potrzebujesz różnych ustawień przechowywania dla różnych zasobów w tej samej tabeli: użyj oddzielnego obszaru roboczego dla różnych zasobów.

Warstwy zobowiązania

Warstwy zobowiązania zapewniają rabat na koszty pozyskiwania obszarów roboczych, gdy zobowiązujesz się do określonej ilości danych dziennych. Możesz skonsolidować dane w jednym obszarze roboczym, aby osiągnąć poziom określonej warstwy. Ta sama ilość danych rozmieszczonych w wielu obszarach roboczych nie będzie kwalifikować się do tej samej warstwy, chyba że masz dedykowany klaster.

Jeśli możesz zatwierdzić codzienne pozyskiwanie co najmniej 100 GB dziennie, należy zaimplementować dedykowany klaster , który zapewnia dodatkowe funkcje i wydajność. Dedykowane klastry umożliwiają również łączenie danych z wielu obszarów roboczych w klastrze w celu osiągnięcia poziomu warstwy zobowiązania.

Jeśli pozyskasz co najmniej 100 GB dziennie we wszystkich zasobach: utwórz dedykowany klaster i ustaw odpowiednią warstwę zobowiązania.
Jeśli pozyskasz co najmniej 100 GB dziennie dla zasobów: rozważ połączenie ich w jednym obszarze roboczym, aby skorzystać z warstwy zobowiązania.

Starsze ograniczenia agenta

Należy unikać wysyłania zduplikowanych danych do wielu obszarów roboczych z powodu dodatkowych opłat, ale mogą istnieć maszyny wirtualne połączone z wieloma obszarami roboczymi. Najbardziej typowym scenariuszem jest agent połączony z oddzielnymi obszarami roboczymi dla usług Azure Monitor i Microsoft Sentinel.

Agent usługi Azure Monitor i agent usługi Log Analytics dla systemu Windows mogą łączyć się z wieloma obszarami roboczymi. Agent usługi Log Analytics dla systemu Linux może łączyć się tylko z jednym obszarem roboczym.

Jeśli używasz agenta usługi Log Analytics dla systemu Linux: przeprowadź migrację do agenta usługi Azure Monitor lub upewnij się, że maszyny z systemem Linux wymagają dostępu tylko do jednego obszaru roboczego.

Kontrola dostępu do danych

Po udzieleniu użytkownikowi dostępu do obszaru roboczego użytkownik ma dostęp do wszystkich danych w tym obszarze roboczym. Ten dostęp jest odpowiedni dla członka centralnego zespołu administracyjnego lub zespołu ds. zabezpieczeń, który musi uzyskiwać dostęp do danych dla wszystkich zasobów. Dostęp do obszaru roboczego jest również określany przez kontrolę dostępu opartą na rolach (RBAC) i kontrolę dostępu na poziomie tabeli.

Kontrola dostępu na podstawie ról w kontekście zasobów: domyślnie, jeśli użytkownik ma dostęp do odczytu do zasobu platformy Azure, dziedziczy uprawnienia do dowolnego z danych monitorowania tego zasobu wysyłanych do obszaru roboczego. Ten poziom dostępu umożliwia użytkownikom dostęp do informacji o zarządzanych zasobach bez udzielenia jawnego dostępu do obszaru roboczego. Jeśli chcesz zablokować ten dostęp, możesz zmienić tryb kontroli dostępu, aby wymagać jawnych uprawnień obszaru roboczego.

Jeśli chcesz, aby użytkownicy mogli uzyskiwać dostęp do danych dla swoich zasobów: Zachowaj domyślny tryb kontroli dostępu uprawnień Użyj zasobu lub obszaru roboczego.
Jeśli chcesz jawnie przypisać uprawnienia dla wszystkich użytkowników: zmień tryb kontroli dostępu na Wymagaj uprawnień obszaru roboczego.

Kontrola dostępu oparta na rolach na poziomie tabeli: w przypadku kontroli dostępu opartej na rolach na poziomie tabeli można udzielić lub odmówić dostępu do określonych tabel w obszarze roboczym. W ten sposób można zaimplementować szczegółowe uprawnienia wymagane w określonych sytuacjach w danym środowisku.

Na przykład możesz udzielić dostępu tylko określonym tabelom zbieranym przez usługę Microsoft Sentinel do wewnętrznego zespołu ds. inspekcji. Możesz też odmówić dostępu do tabel związanych z zabezpieczeniami właścicielom zasobów, którzy potrzebują danych operacyjnych związanych z ich zasobami.

Jeśli nie potrzebujesz szczegółowej kontroli dostępu według tabeli: Udziel zespołowi ds. operacji i zabezpieczeń dostępu do swoich zasobów i zezwól właścicielom zasobów na używanie kontroli dostępu opartej na rolach zasobów dla swoich zasobów.
Jeśli potrzebujesz szczegółowej kontroli dostępu według tabeli: Udzielanie lub odmawianie dostępu do określonych tabel przy użyciu kontroli dostępu opartej na rolach na poziomie tabeli.

Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do danych usługi Microsoft Sentinel według zasobu.

Odporność

Aby upewnić się, że krytyczne dane w obszarze roboczym są dostępne w przypadku awarii regionu, możesz pozyskać niektóre lub wszystkie dane do wielu obszarów roboczych w różnych regionach.

Ta opcja wymaga oddzielnego zarządzania integracją z innymi usługami i produktami dla każdego obszaru roboczego. Mimo że dane będą dostępne w alternatywnym obszarze roboczym w przypadku awarii, zasoby, które opierają się na danych, takich jak alerty i skoroszyty, nie będą wiedzieć, aby przełączyć się do alternatywnego obszaru roboczego. Rozważ przechowywanie szablonów usługi ARM dla krytycznych zasobów z konfiguracją alternatywnego obszaru roboczego w usłudze Azure DevOps lub jako wyłączone zasady, które można szybko włączyć w scenariuszu trybu failover.

Praca z wieloma obszarami roboczymi

Wiele projektów zawiera wiele obszarów roboczych. Na przykład zespół ds. operacji zabezpieczeń centralnych może używać własnych obszarów roboczych usługi Microsoft Sentinel do zarządzania scentralizowanymi artefaktami, takimi jak reguły analizy lub skoroszyty.

Zarówno usługi Azure Monitor, jak i Microsoft Sentinel zawierają funkcje ułatwiające analizowanie tych danych w obszarach roboczych. Aby uzyskać więcej informacji, zobacz:

Podczas nazewnictwa każdego obszaru roboczego zalecamy uwzględnienie znaczącego wskaźnika w nazwie, dzięki czemu można łatwo określić cel każdego obszaru roboczego.

Wiele strategii dzierżawy

Środowiska z wieloma dzierżawami platformy Azure, w tym dostawcami usług firmy Microsoft (MSP), niezależnymi dostawcami oprogramowania (ISV) i dużymi przedsiębiorstwami, często wymagają strategii, w której centralny zespół administracyjny ma dostęp do administrowania obszarami roboczymi znajdującymi się w innych dzierżawach. Każda z dzierżaw może reprezentować oddzielnych klientów lub różne jednostki biznesowe.

Uwaga

W przypadku partnerów i dostawców usług, którzy są częścią programu Dostawca rozwiązań w chmurze (CSP), usługa Log Analytics w usłudze Azure Monitor jest jedną z usług platformy Azure dostępnych w subskrypcjach programu Azure CSP.

W poniższych sekcjach opisano dwie podstawowe strategie dotyczące tej funkcji.

Architektura rozproszona

W architekturze rozproszonej obszar roboczy usługi Log Analytics jest tworzony w każdej dzierżawie platformy Azure. Ta opcja jest jedyną opcją, której można użyć, jeśli monitorujesz usługi platformy Azure inne niż maszyny wirtualne.

Istnieją dwie opcje umożliwiające administratorom dostawcy usług dostęp do obszarów roboczych w dzierżawach klientów:

Użyj usługi Azure Lighthouse , aby uzyskać dostęp do każdej dzierżawy klienta. Administratorzy dostawcy usług są dołączani do grupy użytkowników firmy Microsoft Entra w dzierżawie dostawcy usług. Ta grupa ma dostęp podczas procesu dołączania dla każdego klienta. Administratorzy mogą następnie uzyskiwać dostęp do obszarów roboczych każdego klienta z poziomu własnej dzierżawy dostawcy usług zamiast logować się indywidualnie do dzierżawy poszczególnych klientów. Aby uzyskać więcej informacji, zobacz Monitorowanie zasobów klientów na dużą skalę.
Dodaj poszczególnych użytkowników od dostawcy usług jako użytkowników-gości firmy Microsoft (B2B). Administratorzy dzierżawy klienta zarządzają indywidualnym dostępem dla każdego administratora dostawcy usług. Aby uzyskać dostęp do tych obszarów roboczych, administratorzy dostawcy usług muszą zalogować się do katalogu dla każdej dzierżawy w witrynie Azure Portal.

Zalety tej strategii:

Dzienniki można zbierać ze wszystkich typów zasobów.
Klient może potwierdzić określone poziomy uprawnień za pomocą delegowanego zarządzania zasobami platformy Azure. Klient może też zarządzać dostępem do dzienników przy użyciu własnej kontroli dostępu opartej na rolach platformy Azure.
Każdy klient może mieć różne ustawienia dla swojego obszaru roboczego, takie jak przechowywanie i limit danych.
Izolacja między klientami w celu zapewnienia zgodności z przepisami.
Opłata za każdy obszar roboczy jest uwzględniana na rachunku za subskrypcję klienta.

Wady tej strategii:

Centralnie wizualizowanie i analizowanie danych w dzierżawach klientów za pomocą narzędzi, takich jak skoroszyty usługi Azure Monitor, może spowodować wolniejsze środowisko. Dzieje się tak szczególnie w przypadku analizowania danych w ponad 50 obszarach roboczych.
Jeśli klienci nie są dołączani do zarządzania zasobami delegowanymi na platformie Azure, administratorzy dostawcy usług muszą być aprowizowani w katalogu klienta. To wymaganie utrudnia dostawcy usług zarządzanie wieloma dzierżawami klientów jednocześnie.

Scentralizowany

W ramach subskrypcji dostawcy usług jest tworzony pojedynczy obszar roboczy. Ta opcja może zbierać dane tylko z maszyn wirtualnych klienta. Agenci zainstalowani na maszynach wirtualnych są skonfigurowani do wysyłania dzienników do tego centralnego obszaru roboczego.