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

Zazwyczaj użytkownicy, którzy mają dostęp do obszaru roboczego usługi Microsoft Sentinel, również mają dostęp do wszystkich danych obszaru roboczego, w tym zawartości zabezpieczeń. Administratorzy mogą używać ról platformy Azure do konfigurowania dostępu do określonych funkcji w usłudze Microsoft Sentinel, w zależności od wymagań dostępu w ich zespole.

Jednak niektórzy użytkownicy muszą uzyskiwać dostęp tylko do określonych danych w obszarze roboczym usługi Microsoft Sentinel, ale nie powinni mieć dostępu do całego środowiska usługi Microsoft Sentinel. Na przykład możesz podać zespół ds. operacji niezwiązanych z zabezpieczeniami (non-SOC) z dostępem do danych zdarzeń systemu Windows dla serwerów, których są właścicielami.

W takich przypadkach zalecamy skonfigurowanie kontroli dostępu opartej na rolach (RBAC) na podstawie zasobów, które są dozwolone użytkownikom, zamiast zapewniania im dostępu do obszaru roboczego usługi Microsoft Sentinel lub określonych funkcji usługi Microsoft Sentinel. Ta metoda jest również nazywana konfigurowaniem kontroli dostępu opartej na zasobach.

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

  • Za pośrednictwem samego zasobu, takiego jak maszyna wirtualna platformy Azure. Ta metoda służy do wyświetlania dzienników i skoroszytów tylko dla określonego zasobu.

  • Za pośrednictwem usługi Azure Monitor. 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 określonej grupy zasobów lub zasobów.

Włącz kontrolę RBAC kontekstu zasobów w usłudze Azure Monitor. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do danych dzienników i obszarów roboczych w usłudze Azure Monitor.

Uwaga

Jeśli dane nie są zasobem platformy Azure, takim jak dziennik syslog, CEF lub dane usługi AAD lub dane zebrane 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 RBAC kontekstu zasobów.

Ponadto funkcje i zapisane wyszukiwania nie są obsługiwane w kontekstach skoncentrowanych na zasobach. W związku z tym funkcje usługi Microsoft Sentinel, takie jak analizowanie i normalizacja , nie są obsługiwane w przypadku kontroli dostępu opartej na rolach w kontekście zasobów w usłudze Microsoft Sentinel.

Scenariusze kontroli dostępu opartej na rolach w kontekście zasobów

W poniższej tabeli przedstawiono scenariusze, w których kontrola RBAC kontekstu zasobów jest najbardziej przydatna. Zwróć uwagę na różnice w wymaganiach dotyczących dostępu między zespołami SOC i zespołami innych niż SOC.

Typ wymagania Zespół SOC Zespół inny niż SOC
Uprawnienia Cały obszar roboczy Tylko określone zasoby
Dostęp do danych Wszystkie dane w obszarze roboczym Tylko dane dla zasobów, do których zespół ma uprawnienia dostępu
Środowisko użytkownika Pełne środowisko usługi Microsoft Sentinel, prawdopodobnie ograniczone przez uprawnienia funkcjonalne przypisane do użytkownika Tylko zapytania dziennika i skoroszyty

Jeśli twój zespół ma podobne wymagania dostępu do zespołu innego niż SOC opisanego w powyższej tabeli, kontrola RBAC kontekstu zasobów może być dobrym rozwiązaniem dla organizacji.

Alternatywne metody implementowania kontroli dostępu opartej na rolach kontekstu zasobów

W zależności od uprawnień wymaganych w organizacji użycie kontroli dostępu opartej na zasobach może nie zapewnić pełnego rozwiązania.

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

Scenariusz Rozwiązanie
Spółka zależna ma zespół SOC, który wymaga pełnego środowiska usługi Microsoft Sentinel. W takim przypadku użyj architektury z wieloma obszarami roboczymi, aby oddzielić uprawnienia do danych.

Aby uzyskać więcej informacji, zobacz:
- Rozszerzanie usługi Microsoft Sentinel między obszarami roboczymi i dzierżawami
- Praca z incydentami w wielu obszarach roboczych jednocześnie
Chcesz zapewnić dostęp do określonego typu zdarzenia. Na przykład podaj administratorowi systemu Windows dostęp do Zabezpieczenia Windows zdarzeń we wszystkich systemach.

W takich przypadkach użyj kontroli dostępu opartej na rolach na poziomie tabeli , aby zdefiniować uprawnienia dla każdej tabeli.
Ograniczanie dostępu do bardziej szczegółowego poziomu, a nie na podstawie zasobu lub tylko do podzestawu pól w zdarzeniu Na przykład możesz ograniczyć dostęp do dzienników Office 365 na podstawie jednostki zależnej użytkownika.

W takim przypadku zapewnij dostęp do danych przy użyciu wbudowanej integracji z pulpitami nawigacyjnymi i raportami usługi Power BI.

Jawne konfigurowanie kontroli dostępu opartej na rolach zasobu

Wykonaj poniższe kroki, jeśli chcesz skonfigurować kontrolę RBAC kontekstu zasobów, ale dane nie są zasobem platformy Azure.

Na przykład dane w obszarze roboczym usługi Microsoft Sentinel, które nie są zasobami platformy Azure, obejmują dane Syslog, CEF lub AAD albo dane zebrane przez niestandardowy moduł zbierający.

Aby jawnie skonfigurować kontrolę RBAC kontekstu zasobów:

  1. Upewnij się, że włączono kontrolę RBAC kontekstu zasobów w usłudze Azure Monitor.

  2. 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 usługi Microsoft Sentinel.

    Przypisz uprawnienia czytelnika dzienników dla każdego z członków zespołu.

  3. Przypisz zasoby do utworzonych grup zespołów zasobów i oznacz zdarzenia tagami przy użyciu odpowiednich identyfikatorów zasobów.

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

    Porada

    Zalecamy grupowanie zasobów, dla których udzielasz dostępu w ramach określonej grupy zasobów utworzonej do tego 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

W przypadku zbierania zdarzeń przy użyciu formatu Common Event Format (CEF) lub dziennika systemowego przekazywanie dzienników jest używane do zbierania zdarzeń z wielu systemów źródłowych.

Na przykład gdy maszyna wirtualna przekazująca cef lub Syslog nasłuchuje źródeł wysyłających zdarzenia dziennika systemowego i przekazuje je do usługi Microsoft Sentinel, identyfikator zasobu maszyny wirtualnej przekazującej dziennik jest przypisywany do wszystkich zdarzeń, które przesyłają dalej.

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

Na przykład oddzielenie maszyn wirtualnych gwarantuje, że zdarzenia dziennika systemowego należące do zespołu A są zbierane przy użyciu maszyny wirtualnej A modułu zbierającego.

Porada

  • 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 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 Sylog.

Identyfikatory zasobów z kolekcją Logstash

Jeśli zbierasz dane przy użyciu wtyczki wyjściowej usługi Logstash usługi Microsoft Sentinel, 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 kontroli RBAC kontekstu zasobów i chcesz, aby zdarzenia zebrane przez interfejs API miały być dostępne dla określonych użytkowników, użyj identyfikatora zasobu grupy zasobów utworzonej dla użytkowników.

Na przykład poniższy kod przedstawia przykładowy plik konfiguracji usługi Logstash:

 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Porada

Możesz dodać wiele output sekcji w celu odróżnienia tagów zastosowanych do różnych zdarzeń.

Identyfikatory zasobów z kolekcją interfejsu API usługi Log Analytics

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

Jeśli używasz kontroli RBAC kontekstu zasobów i chcesz, aby zdarzenia zebrane przez interfejs API miały być dostępne dla określonych użytkowników, użyj identyfikatora zasobu grupy zasobów utworzonej dla użytkowników.

Następne kroki

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