Zarządzanie dostępem do danych Microsoft Sentinel według zasobu

Dostęp do obszaru roboczego jest zarządzany przy użyciu Azure RBAC. Zazwyczaj użytkownicy, którzy mają dostęp do obszaru roboczego usługi Log Analytics włączonego dla Microsoft Sentinel również mają dostęp do wszystkich danych obszaru roboczego, w tym zawartości zabezpieczeń. Administratorzy mogą używać ról Azure do konfigurowania dostępu do określonych funkcji w Microsoft Sentinel, w zależności od wymagań dotyczących dostępu w zespole.

Jednak niektórzy użytkownicy mogą mieć dostęp tylko do określonych danych w obszarze roboczym, ale nie powinni mieć dostępu do całego środowiska Microsoft Sentinel. Na przykład możesz udostępnić zespołowi operacji niezwiązanych z zabezpieczeniami (innym niż SOC) dostęp do danych zdarzeń systemu Windows dla serwerów, których są właścicielami.

Dla użytkowników, którzy potrzebują dostępu tylko do określonych danych w przestrzeni roboczej, zalecamy skonfigurowanie kontroli dostępu opartej na rolach (RBAC) na podstawie zasobów dostępnych dla tych użytkowników, zamiast zapewniać im dostęp do przestrzeni roboczej lub konkretnych funkcji Microsoft Sentinel. Ta metoda jest również znana jako konfigurowanie RBAC kontekstu zasobu.

Gdy użytkownicy mają dostęp do Microsoft Sentinel danych za pośrednictwem zasobów, do których mogą uzyskać dostęp zamiast do obszaru roboczego, mogą wyświetlać dzienniki i skoroszyty przy użyciu następujących metod:

Za pośrednictwem samego zasobu, takiego jak Azure Virtual Machine. Ta metoda służy do wyświetlania dzienników i skoroszytów tylko dla określonego zasobu.
Za pośrednictwem monitora Azure. Użyj tej metody, jeśli chcesz utworzyć zapytania obejmujące wiele zasobów i/lub grup zasobów. Podczas przechodzenia do dzienników i skoroszytów w usłudze Azure Monitor zdefiniuj zakres do co najmniej jednej konkretnej grupy zasobów lub zasobów.

Włącz mechanizm RBAC w kontekście zasobu w usłudze Azure Monitor. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do danych dziennika i obszarów roboczych w usłudze Azure Monitor.

Uwaga

Jeśli dane nie są zasobem Azure, takim jak dziennik Syslog, CEF lub dane Microsoft Entra ID lub dane zbierane przez niestandardowy moduł zbierający, musisz ręcznie skonfigurować identyfikator zasobu używany do identyfikowania danych i włączania dostępu. Aby uzyskać więcej informacji, zobacz Jawne konfigurowanie kontroli dostępu opartej na rolach kontekstu zasobu dla zasobów innych niż Azure.

Ponadto funkcje i zapisane wyszukiwania nie są obsługiwane w kontekstach zorientowanych na zasoby. W związku z tym funkcje programu Microsoft Sentinel, takie jak parsowanie i normalizacja, nie są obsługiwane w przypadku mechanizmu RBAC w kontekście zasobu w usłudze Microsoft Sentinel.

Scenariusze dla mechanizmu RBAC w kontekście zasobów

Poniższa tabela przedstawia scenariusze, w których mechanizm RBAC w kontekście zasobów jest najbardziej pomocny. Zwróć uwagę na różnice w wymaganiach dostępu między zespołami SOC a zespołami spoza SOC.

Typ wymagania	Zespół SOC	Zespół spoza SOC
Uprawnienia	Cały obszar roboczy	Tylko określone zasoby
Dostęp do danych	Wszystkie dane w obszarze roboczym	Tylko dane dotyczące zasobów, do których zespół ma uprawnienia dostępu
Doświadczenie	Pełne środowisko Microsoft Sentinel, prawdopodobnie ograniczone przez uprawnienia funkcjonalne przypisane do użytkownika	Tylko zapytania dzienników i skoroszyty

Jeśli Twój zespół ma wymagania dotyczące dostępu podobne do wymagań zespołu non-SOC opisanego w powyższej tabeli, mechanizm RBAC w kontekście zasobów może być dobrym rozwiązaniem dla Twojej organizacji.

Na przykład 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 mechanizm RBAC w kontekście zasobów służy do przydzielania wymaganych uprawnień.

W przykładowym diagramie architektury RBAC kontekst zasob-kontekst:

Obszar roboczy usługi Log Analytics włączony dla Microsoft Sentinel jest umieszczany w oddzielnej subskrypcji w celu lepszego odizolowania uprawnień od subskrypcji używanej przez zespoły aplikacji do hostowania obciążeń.
Zespoły aplikacji otrzymują dostęp do odpowiednich grup zasobów, w których mogą zarządzać swoimi zasobami.

Umieszczenie przestrzeni roboczej w osobnej subskrypcji i użycie RBAC z kontekstem zasobów pozwala zespołom aplikacyjnym przeglądać logi generowane przez dowolne zasoby, do których mają dostęp, nawet gdy logi są przechowywane w przestrzeni roboczej, do której nie mają bezpośredniego dostępu. Zespoły aplikacji mogą uzyskiwać dostęp do swoich dzienników za pośrednictwem obszaru Dzienniki Azure Portal, aby wyświetlić dzienniki dla określonego zasobu lub za pośrednictwem Azure Monitor, aby wyświetlić wszystkie dzienniki, do których mogą uzyskiwać dostęp w tym samym czasie.

Jawna konfiguracja mechanizmu RBAC w kontekście zasobu dla zasobów spoza platformy Azure

Zasoby platformy Azure mają wbudowaną obsługę mechanizmu RBAC w kontekście zasobu, ale mogą wymagać dodatkowego dostosowania w przypadku pracy z zasobami spoza platformy Azure. Na przykład dane w twojej przestrzeni roboczej Log Analytics włączonej dla Microsoft Sentinel, które nie są zasobami Azure, obejmują dane z Syslog, CEF lub Microsoft Entra ID, albo dane zbierane przez niestandardowego kolektora.

Aby skonfigurować RBAC kontekstu zasobów-dla danych niebędących Azure, wykonaj następującą procedurę.

Aby jawnie skonfigurować RBAC dla kontekstu zasobu:

Upewnij się, że włączono funkcję RBAC kontekstu zasobów w usłudze Azure Monitor.
Utwórz grupę zasobów dla każdego zespołu użytkowników, którzy muszą uzyskać dostęp do zasobów bez całego środowiska Microsoft Sentinel.

Przypisz uprawnienia czytnika dzienników dla każdego z członków zespołu.
Przypisz zasoby do utworzonych grup zespołów zasobów i otaguj zdarzenia przy użyciu odpowiednich identyfikatorów zasobów.

Gdy zasoby Azure wysyłają dane do Microsoft Sentinel, rekordy dziennika są automatycznie oznaczane identyfikatorem zasobu źródła danych.

Wskazówka

Zalecamy grupowanie zasobów, dla których udzielasz dostępu, w ramach określonej grupy zasobów utworzonej w tym celu.

Jeśli nie możesz, upewnij się, że twój zespół ma uprawnienia czytelnika dzienników bezpośrednio do zasobów, do których chcesz uzyskać dostęp.

Aby uzyskać więcej informacji na temat identyfikatorów zasobów, zobacz:

Identyfikatory zasobów z przekazywaniem dzienników

Gdy zdarzenia są zbierane przy użyciu formatu Common Event Format (CEF) lub dziennika Syslog, przekazywanie dzienników jest używane do zbierania zdarzeń z wielu systemów źródłowych.

Na przykład gdy maszyna wirtualna do przekazywania komunikatów CEF lub Syslog nasłuchuje źródeł wysyłających zdarzenia Syslog i przekazuje je do Microsoft Sentinel, identyfikator zasobu tej maszyny wirtualnej do przekazywania dzienników jest przypisywany do wszystkich przekazywanych przez nią zdarzeń.

Jeśli masz wiele zespołów, upewnij się, że masz osobne maszyny wirtualne przekazujące dzienniki przetwarzające zdarzenia dla każdego oddzielnego zespołu.

Na przykład rozdzielenie maszyn wirtualnych zapewnia, że zdarzenia Syslog przypisane do zespołu A są zbierane za pomocą maszyny wirtualnej kolektora A.

Wskazówka

W przypadku korzystania z lokalnej maszyny wirtualnej lub innej maszyny wirtualnej w chmurze, takiej jak AWS, jako usługi przesyłania dalej dzienników, upewnij się, że ma ona identyfikator zasobu, implementując usługę Azure Arc.
Aby skalować środowisko maszyny wirtualnej przekazującej dzienniki, rozważ utworzenie zestawu skalowania maszyn wirtualnych w celu zbierania dzienników CEF i Syslog.

Identyfikatory zasobów zbierane przez Logstash

Jeśli zbierasz dane przy użyciu wtyczki danych wyjściowych Microsoft Sentinel Logstash, użyj pola azure_resource_id, aby skonfigurować niestandardowy moduł zbierający w celu uwzględnienia identyfikatora zasobu w danych wyjściowych.

Jeśli używasz RBAC z kontekstem zasobu i chcesz, aby zdarzenia zbierane przez API były dostępne dla konkretnych użytkowników, użyj identyfikatora zasobu grupy zasobów, którą skonfigurowałeś w Explicitnie konfiguruj RBAC kontekstu zasobu dla zasobów niezwiązanych z Azure.

Na przykład poniższy plik konfiguracyjny Logstash pokazuje, jak pobierać zdarzenia za pomocą wejścia Beats i wysyłać je do przestrzeni roboczej Log Analytics za pomocą wtyczki wyjściowej Microsoft Sentinel, z polem azure_resource_id ustawionym na oznaczanie zdarzeń z konkretną grupą zasobów dla RBAC kontekstu zasobów:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Wskazówka

Możesz dodać wiele output sekcji, aby odróżnić tagi stosowane do różnych zdarzeń.

Identyfikatory zasobów w kolekcji interfejsu API usługi Log Analytics

Podczas zbierania danych przy użyciu interfejsu API modułu zbierającego dane usługi Log Analytics można przypisać zdarzeniom identyfikator zasobu przy użyciu nagłówka żądania HTTP x-ms-AzureResourceId.

Alternatywy dla RBAC w kontekście zasobów

W zależności od wymaganych uprawnień w Twojej organizacji, korzystanie RBAC z kontekstu zasobów może nie spełniać wszystkich wymagań dotyczących dostępu do danych w Twojej organizacji. Na przykład, rozważmy, czy organizacja korzystająca z architektury oddzielnych subskrypcyjnych przestrzeni roboczych opisanej w Scenariuszach dla RBAC kontekstu zasobów musi również przyznawać dostęp do logów Office 365 zespołowi audytu wewnętrznego. W takim przypadku mogą użyć kontroli RBAC na poziomie tabeli, aby przyznać zespołowi audytowemu dostęp do całej tabeli OfficeActivity bez przyznawania uprawnień do żadnej innej tabeli.

Na poniższej liście opisano scenariusze, w których inne rozwiązania dotyczące dostępu do danych mogą lepiej dopasować twoje wymagania:

Scenariusz	Rozwiązanie
Jednostka zależna ma zespół SOC, który wymaga pełnego środowiska Microsoft Sentinel.	W takim przypadku użyj architektury z wieloma obszarami roboczymi, aby oddzielić uprawnienia do danych. Więcej informacji można znaleźć w następujących artykułach: Rozszerz Microsoft Sentinel na obszary robocze i dzierżawy > Pracuj z incydentami w wielu obszarach roboczych jednocześnie
Chcesz zapewnić dostęp do określonego typu zdarzenia.	Na przykład zapewnij administratorowi systemu Windows dostęp do zdarzeń Zabezpieczenia Windows we wszystkich systemach. W takich przypadkach użyj kontroli RBAC na poziomie tabeli , aby zdefiniować uprawnienia dla każdej tabeli.
Ogranicz dostęp na bardziej szczegółowym poziomie: albo nie na podstawie zasobu, albo jedynie do podzbioru pól w zdarzeniu	Na przykład możesz chcieć ograniczyć dostęp do dzienników Office 365 w oparciu o jednostkę zależną użytkownika. W takim przypadku zapewnij dostęp do danych przy użyciu wbudowanej integracji z pulpitami nawigacyjnymi i raportami usługi Power BI.
Ograniczanie dostępu według grupy zarządzania	Umieść Microsoft Sentinel w osobnej grupie zarządzania dedykowanej zabezpieczeniom, tak aby członkowie grupy dziedziczyli tylko minimalne uprawnienia. W zespole ds. zabezpieczeń przypisz uprawnienia do różnych grup zgodnie z każdą funkcją grupy. Ponieważ wszystkie zespoły mają dostęp do całego obszaru roboczego, będą mieć dostęp do pełnego środowiska Microsoft Sentinel, ograniczonego tylko przez przypisane role Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Uprawnienia w Microsoft Sentinel.

Więcej informacji można znaleźć w następujących artykułach:

Opinia

Czy ta strona była pomocna?

Last updated on 2026-08-14