Zarządzanie dostępem do danych usługi Microsoft Sentinel według zasobu
Dostęp do obszaru roboczego jest zarządzany przy użyciu kontroli dostępu opartej na rolach platformy Azure. Zazwyczaj użytkownicy, którzy mają dostęp do obszaru roboczego usługi Log Analytics włączonego dla 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ń dotyczących dostępu w ich zespole.
Być może jednak niektórzy użytkownicy muszą uzyskiwać dostęp tylko do określonych danych w obszarze roboczym, 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 dla użytkowników, zamiast zapewniania im dostępu do obszaru roboczego lub określonych funkcji usługi Microsoft Sentinel. Ta metoda jest również nazywana konfigurowaniem kontroli dostępu opartej na rolach w kontekście zasobów.
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, 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łączanie kontroli dostępu opartej na rolach w kontekście 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 identyfikatora entra firmy Microsoft lub dane zebrane przez niestandardowy moduł zbierający, należy 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 dla zasobów spoza platformy Azure.
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 dotyczące kontroli dostępu opartej na rolach w kontekście zasobów
W poniższej tabeli przedstawiono scenariusze, w których najbardziej przydatna jest kontrola RBAC kontekstu zasobów. Zwróć uwagę na różnice w wymaganiach dotyczących dostępu między zespołami SOC i zespołami spoza 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 |
| Doświadczenie | Pełne środowisko usługi Microsoft Sentinel, prawdopodobnie ograniczone przez uprawnienia funkcjonalne przypisane do użytkownika | Tylko zapytania dzienników i skoroszyty |
Jeśli twój zespół ma podobne wymagania dostępu do zespołu innego niż SOC opisanego w powyższej tabeli, kontrola dostępu oparta na zasobach 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 kontrola dostępu oparta na rolach w kontekście zasobów służy do zapewniania wymaganych uprawnień.
Elementy na tym obrazie:
- Obszar roboczy usługi Log Analytics włączony dla usługi Microsoft Sentinel jest umieszczany w oddzielnej subskrypcji, aby lepiej odizolować uprawnienia od subskrypcji używanej przez zespoły 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.
Jawne konfigurowanie kontroli dostępu opartej na rolach zasobów dla zasobów spoza platformy Azure
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. Na przykład dane w obszarze roboczym usługi Log Analytics włączone dla usługi Microsoft Sentinel, które nie są zasobami platformy Azure, obejmują dziennik Syslog, CEF lub dane usługi AAD albo dane zbierane przez niestandardowy moduł zbierający.
Wykonaj poniższe kroki, jeśli chcesz skonfigurować kontrolę dostępu opartą na rolach kontekstu zasobów, ale dane nie są zasobem platformy Azure.
Aby jawnie skonfigurować kontrolę dostępu opartą na rolach w kontekście zasobów:
Upewnij się, że włączono kontrolę 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ą uzyskiwać dostęp do zasobów bez całego środowiska usługi Microsoft Sentinel.
Przypisz uprawnienia czytelnika dziennika dla każdego członka zespołu.
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.
Napiwek
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 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 systemowego, przekazywanie dzienników służy do zbierania zdarzeń z wielu systemów źródłowych.
Na przykład gdy maszyna wirtualna przekazująca plik 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 modułu zbierającego A.
Napiwek
- W przypadku korzystania z lokalnej maszyny wirtualnej lub innej maszyny wirtualnej w chmurze, takiej jak AWS, jako usługi przesyłania dalej dziennika, 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 zebrania dzienników cef i dziennika systemowego.
Identyfikatory zasobów z kolekcją logstash
Jeśli zbierasz dane przy użyciu wtyczki danych wyjściowych 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 dostępu opartej na rolach 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>
}
}
Napiwek
Możesz dodać wiele output sekcji, aby odróżnić tagi stosowane 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 dostępu opartej na rolach 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.
Alternatywy dla kontroli dostępu opartej na rolach w kontekście zasobów
W zależności od uprawnień wymaganych w organizacji użycie kontroli dostępu opartej na rolach w kontekście zasobów może nie zapewnić pełnego rozwiązania. Rozważmy na przykład, czy organizacja, której architektura została opisana w poprzedniej sekcji, 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.
Poniższa lista zawiera opis scenariuszy, w których inne rozwiązania dotyczące dostępu do danych mogą lepiej spełniać twoje wymagania:
| Scenariusz | Rozwiązanie |
|---|---|
| Przedstawicielstwo 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: |
| 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. |
| Ogranicz dostęp do bardziej szczegółowego poziomu, nie na podstawie zasobu lub tylko do podzbioru pól w zdarzeniu | Na przykład możesz ograniczyć dostęp do dzienników usługi 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. |
| Ograniczanie dostępu według grupy zarządzania | Umieść usługę Microsoft Sentinel w oddzielnej grupie zarządzania dedykowanej do zabezpieczeń, zapewniając, że tylko minimalne uprawnienia są dziedziczone do członków grupy. 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ą 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. |
Powiązana zawartość
Aby uzyskać więcej informacji, zobacz: