Najlepsze rozwiązania dotyczące architektury obszaru roboczego usługi Microsoft Sentinel

Podczas planowania wdrożenia obszaru roboczego usługi Microsoft Sentinel należy również zaprojektować architekturę obszaru roboczego usługi Log Analytics. Decyzje dotyczące architektury obszaru roboczego są zwykle oparte na wymaganiach biznesowych i technicznych. Ten artykuł zawiera przegląd kluczowych czynników decyzyjnych, które pomogą Ci określić właściwą architekturę obszaru roboczego dla organizacji, w tym:

  • Niezależnie od tego, czy będziesz używać jednej dzierżawy, czy wielu dzierżaw
  • Wszelkie wymagania dotyczące zgodności dotyczące zbierania i przechowywania danych
  • Jak kontrolować dostęp do danych usługi Microsoft Sentinel
  • Implikacje dotyczące kosztów w różnych scenariuszach

Aby uzyskać więcej informacji, zobacz Projektowanie architektury obszaru roboczego usługi Microsoft Sentinel i Przykładowe projekty obszarów roboczych dla typowych scenariuszy oraz Działania przed wdrożeniem i wymagania wstępne dotyczące wdrażania usługi Microsoft Sentinel.

Zobacz nasze wideo: Tworzenie architektury secOps na potrzeby sukcesu: najlepsze rozwiązania dotyczące wdrażania usługi Microsoft Sentinel.

Ten artykuł jest częścią przewodnika wdrażania usługi Microsoft Sentinel.

Zagadnienia dotyczące dzierżawy

Chociaż mniejsza liczba obszarów roboczych jest prostsza do zarządzania, może istnieć konkretne potrzeby wielu dzierżaw i obszarów roboczych. Na przykład wiele organizacji ma środowisko chmury, które zawiera wiele dzierżaw firmy Microsoft Entra, wynikających z fuzji i przejęć lub z powodu wymagań dotyczących separacji tożsamości.

Podczas określania liczby dzierżaw i obszarów roboczych do użycia należy wziąć pod uwagę, że większość funkcji usługi Microsoft Sentinel działa przy użyciu jednego obszaru roboczego lub wystąpienia usługi Microsoft Sentinel, a usługa Microsoft Sentinel pozyska wszystkie dzienniki znajdujące się w obszarze roboczym.

Koszty są jednym z głównych zagadnień podczas określania architektury usługi Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Koszty i rozliczenia usługi Microsoft Sentinel.

Praca z wieloma dzierżawami

Jeśli masz wiele dzierżaw, takich jak jeśli jesteś dostawcą usług zabezpieczeń zarządzanych (MSSP), zalecamy utworzenie co najmniej jednego obszaru roboczego dla każdej dzierżawy firmy Microsoft Entra w celu obsługi wbudowanych łączników danych usługi service to service to service data connector , które działają tylko w ramach własnej dzierżawy firmy Microsoft Entra.

Nie można połączyć wszystkich łączników na podstawie ustawień diagnostycznych z obszarem roboczym, który nie znajduje się w tej samej dzierżawie, w której znajduje się zasób. Dotyczy to łączników, takich jak Azure Firewall, Azure Storage, Azure Activity lub Microsoft Entra ID.

Usługa Azure Lighthouse ułatwia zarządzanie wieloma wystąpieniami usługi Microsoft Sentinel w różnych dzierżawach.

Uwaga

Łączniki danych partnerów są często oparte na kolekcjach interfejsów API lub agentów i dlatego nie są dołączone do określonej dzierżawy firmy Microsoft Entra.

Zagadnienia dotyczące zgodności

Po zebraniu, przechowywaniu i przetwarzaniu danych zgodność może stać się ważnym wymaganiem projektowym ze znaczącym wpływem na architekturę usługi Microsoft Sentinel. Możliwość weryfikacji i udowodnienia, kto ma dostęp do danych we wszystkich warunkach, jest krytycznym wymogiem suwerenności danych w wielu krajach i regionach oraz ocenianiem ryzyka i uzyskiwaniem szczegółowych informacji w przepływach pracy usługi Microsoft Sentinel jest priorytetem dla wielu klientów.

W usłudze Microsoft Sentinel dane są głównie przechowywane i przetwarzane w tej samej lokalizacji geograficznej lub regionie, z pewnymi wyjątkami, takimi jak w przypadku korzystania z reguł wykrywania korzystających z uczenia maszynowego firmy Microsoft. W takich przypadkach dane mogą być kopiowane poza obszarem geograficznym obszaru roboczego na potrzeby przetwarzania.

Aby uzyskać więcej informacji, zobacz:

Aby rozpocząć weryfikowanie zgodności, oceń źródła danych oraz sposób i miejsce ich wysyłania.

Uwaga

Agent usługi Log Analytics obsługuje protokół TLS 1.2 w celu zapewnienia bezpieczeństwa danych przesyłanych między agentem a usługą Log Analytics, a także standardem FIPS 140.

Jeśli wysyłasz dane do lokalizacji geograficznej lub regionu innego niż obszar roboczy usługi Microsoft Sentinel, 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.

Zagadnienia dotyczące regionów

Użyj oddzielnych wystąpień usługi Microsoft Sentinel dla każdego regionu. Chociaż usługa Microsoft Sentinel może być używana w wielu regionach, mogą istnieć wymagania dotyczące oddzielania danych według zespołu, regionu lub witryny albo przepisów i mechanizmów kontroli, które sprawiają, że modele wieloregionowe są niemożliwe lub bardziej złożone niż jest to konieczne. Używanie oddzielnych wystąpień i obszarów roboczych dla każdego regionu pomaga uniknąć kosztów przepustowości/ruchu wychodzącego w przypadku przenoszenia danych między regionami.

Podczas pracy z wieloma regionami należy wziąć pod uwagę następujące kwestie:

  • Koszty ruchu wychodzącego są zwykle stosowane, gdy do zbierania dzienników jest wymagany agent usługi Log Analytics lub Azure Monitor, na przykład na maszynach wirtualnych.

  • Opłaty za ruch wychodzący z Internetu również mogą nie mieć wpływu na Ciebie, chyba że dane zostaną wyeksportowane poza obszarem roboczym usługi Log Analytics. Na przykład w przypadku eksportowania danych usługi Log Analytics do serwera lokalnego mogą być naliczane opłaty za ruch wychodzący z Internetu.

  • Koszty przepustowości różnią się w zależności od regionu źródłowego i docelowego oraz metody zbierania. Aby uzyskać więcej informacji, zobacz:

  • Użyj szablonów dla reguł analizy, zapytań niestandardowych, skoroszytów i innych zasobów, aby zwiększyć wydajność wdrożeń. Wdróż szablony zamiast ręcznie wdrażać każdy zasób w każdym regionie.

  • Połączenie ory oparte na ustawieniach diagnostycznych nie generują kosztów przepustowości. Aby uzyskać więcej informacji, zobacz Opłaty za transfery danych przy użyciu usługi Log Analytics.

Jeśli na przykład zdecydujesz się zbierać dzienniki z maszyn wirtualnych w regionie Wschodnie stany USA i wysyłać je do obszaru roboczego usługi Microsoft Sentinel w regionie Zachodnie stany USA, zostaną naliczone opłaty za transfer danych. Ponieważ agent usługi Log Analytics kompresuje dane przesyłane, rozmiar naliczany za przepustowość może być mniejszy niż rozmiar dzienników w usłudze Microsoft Sentinel.

Jeśli zbierasz dzienniki Syslog i CEF z wielu źródeł na całym świecie, możesz skonfigurować moduł zbierający dziennik systemowy w tym samym regionie co obszar roboczy usługi Microsoft Sentinel, aby uniknąć kosztów przepustowości, pod warunkiem, że zgodność nie jest problemem.

Zrozumienie, czy koszty przepustowości uzasadniają oddzielne obszary robocze usługi Microsoft Sentinel, zależą od ilości danych potrzebnych do transferu między regionami. Użyj kalkulatora cen platformy Azure, aby oszacować koszty.

Aby uzyskać więcej informacji, zobacz Data residency in Azure (Rezydencja danych na platformie Azure).

Zagadnienia dotyczące dostępu

Mogą wystąpić sytuacje, w których różne zespoły będą potrzebować dostępu do tych samych danych. Na przykład zespół SOC musi mieć dostęp do wszystkich danych usługi Microsoft Sentinel, natomiast zespoły ds. operacji i aplikacji będą potrzebować dostępu tylko do określonych części. Niezależne zespoły ds. zabezpieczeń mogą również potrzebować dostępu do funkcji usługi Microsoft Sentinel, ale z różnych zestawów danych.

Połącz kontrolę dostępu opartej na rolach na poziomie zasobów i kontrolę dostępu na poziomie tabeli, aby zapewnić zespołom szeroką gamę opcji dostępu, które powinny obsługiwać większość przypadków użycia.

Aby uzyskać więcej informacji, zobacz Uprawnienia w usłudze Microsoft Sentinel.

Kontrola dostępu oparta na rolach w kontekście zasobów

Na poniższej ilustracji przedstawiono uproszczoną wersję architektury obszaru roboczego, w której zespoły ds. zabezpieczeń i operacji potrzebują dostępu do różnych zestawów danych, a kontrola dostępu oparta na zasobach jest używana do zapewnienia wymaganych uprawnień.

Diagram of a sample architecture for resource-context RBAC.

Na tej ilustracji obszar roboczy usługi Microsoft Sentinel jest umieszczany w oddzielnej subskrypcji, aby lepiej odizolować uprawnienia.

Uwaga

Inną opcją byłoby umieszczenie usługi Microsoft Sentinel w oddzielnej grupie zarządzania dedykowanej do zabezpieczeń, co zapewniłoby dziedziczenie tylko minimalnych przypisań uprawnień. W zespole ds. zabezpieczeń kilka grup ma przypisane uprawnienia zgodnie z ich funkcjami. Ponieważ te zespoły mają dostęp do całego obszaru roboczego, będą mieli dostęp do pełnego środowiska usługi Microsoft Sentinel, ograniczone tylko przez przypisane role usługi Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Uprawnienia w usłudze Microsoft Sentinel.

Oprócz subskrypcji zabezpieczeń oddzielna subskrypcja jest używana dla zespołów aplikacji do hostowania obciążeń. Zespoły aplikacji mają dostęp do odpowiednich grup zasobów, w których mogą zarządzać swoimi zasobami. Ta oddzielna subskrypcja i kontrola dostępu na podstawie ról w kontekście zasobów umożliwia tym zespołom wyświetlanie dzienników generowanych przez wszystkie zasoby, do których mają dostęp, nawet jeśli dzienniki są przechowywane w obszarze roboczym, w którym nie mają bezpośredniego dostępu. Zespoły aplikacji mogą uzyskiwać dostęp do dzienników za pośrednictwem obszaru Dzienniki witryny Azure Portal, aby wyświetlić dzienniki dla określonego zasobu lub za pośrednictwem usługi Azure Monitor, aby pokazać wszystkie dzienniki, do których mogą uzyskiwać dostęp w tym samym czasie.

Zasoby platformy Azure mają wbudowaną obsługę kontroli dostępu opartej na rolach w kontekście zasobów, ale mogą wymagać dodatkowego dostrajania podczas pracy z zasobami spoza platformy Azure. Aby uzyskać więcej informacji, zobacz Jawne konfigurowanie kontroli dostępu opartej na rolach w kontekście zasobów.

Kontrola RBAC na poziomie tabeli

Kontrola dostępu oparta na rolach na poziomie tabeli umożliwia definiowanie określonych typów danych (tabel) jako dostępnych tylko dla określonego zestawu użytkowników.

Rozważmy na przykład, czy organizacja, której architektura została opisana na powyższej ilustracji, musi również udzielić dostępu do dzienników usługi Office 365 wewnętrznemu zespołowi inspekcji. W takim przypadku mogą używać kontroli dostępu opartej na rolach na poziomie tabeli w celu udzielenia zespołowi inspekcji dostępu do całej tabeli OfficeActivity bez udzielania uprawnień do jakiejkolwiek innej tabeli.

Zagadnienia dotyczące dostępu z wieloma obszarami roboczymi

Jeśli masz różne jednostki, jednostki zależne lub lokalizacje geograficzne w organizacji, każdy z własnymi zespołami ds. zabezpieczeń, które potrzebują dostępu do usługi Microsoft Sentinel, użyj oddzielnych obszarów roboczych dla każdej jednostki lub jednostki zależnej. Zaimplementuj oddzielne obszary robocze w ramach jednej dzierżawy firmy Microsoft Entra lub w wielu dzierżawach przy użyciu usługi Azure Lighthouse.

Centralny zespół SOC może również użyć dodatkowego, opcjonalnego obszaru roboczego usługi Microsoft Sentinel do zarządzania scentralizowanymi artefaktami, takimi jak reguły analizy lub skoroszyty.

Aby uzyskać więcej informacji, zobacz Upraszczanie pracy z wieloma obszarami roboczymi.

Najlepsze rozwiązania techniczne dotyczące tworzenia obszaru roboczego

Skorzystaj z poniższych wskazówek dotyczących najlepszych rozwiązań podczas tworzenia obszaru roboczego usługi Log Analytics, którego będziesz używać dla usługi Microsoft Sentinel:

  • Podczas nazewnictwa obszaru roboczego uwzględnij usługę Microsoft Sentinel lub inny wskaźnik w nazwie, aby można było go łatwo zidentyfikować wśród innych obszarów roboczych.

  • Użyj tego samego obszaru roboczego zarówno dla usługi Microsoft Sentinel, jak i Microsoft Defender dla Chmury, aby wszystkie dzienniki zebrane przez Microsoft Defender dla Chmury mogły być również pozyskiwane i używane przez usługę Microsoft Sentinel. Domyślny obszar roboczy utworzony przez Microsoft Defender dla Chmury nie będzie wyświetlany jako dostępny obszar roboczy dla usługi Microsoft Sentinel.

  • Użyj dedykowanego klastra obszarów roboczych, jeśli przewidywane pozyskiwanie danych wynosi około lub więcej niż 1 TB dziennie. Dedykowany klaster umożliwia zabezpieczanie zasobów dla danych usługi Microsoft Sentinel, co zapewnia lepszą wydajność zapytań dla dużych zestawów danych. Dedykowane klastry zapewniają również opcję większego szyfrowania i kontroli kluczy organizacji.

Nie stosuj blokady zasobów do obszaru roboczego usługi Log Analytics, którego użyjesz w usłudze Microsoft Sentinel. Blokada zasobu w obszarze roboczym może spowodować niepowodzenie wielu operacji usługi Microsoft Sentinel.

Upraszczanie pracy z wieloma obszarami roboczymi

Jeśli musisz pracować z wieloma obszarami roboczymi, uprość zarządzanie zdarzeniami i badanie , kondensując i wyświetlając listę wszystkich zdarzeń z każdego wystąpienia usługi Microsoft Sentinel w jednej lokalizacji.

Aby odwołać się do danych przechowywanych w innych obszarach roboczych usługi Microsoft Sentinel, takich jak w skoroszytach między obszarami roboczymi, użyj zapytań między obszarami roboczymi.

Najlepszym czasem korzystania z zapytań między obszarami roboczymi jest to, że cenne informacje są przechowywane w innym obszarze roboczym, subskrypcji lub dzierżawie i mogą zapewnić wartość bieżącej akcji. Na przykład poniższy kod przedstawia przykładowe zapytanie obejmujące wiele obszarów roboczych:

union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification

Aby uzyskać więcej informacji, zobacz Rozszerzanie usługi Microsoft Sentinel między obszarami roboczymi i dzierżawami.

Następne kroki

W tym artykule przedstawiono kluczowe czynniki decyzyjne ułatwiające określenie odpowiedniej architektury obszaru roboczego dla organizacji.