Verwalten des Zugriffs auf Microsoft Sentinel Daten nach Ressource

Der Zugriff auf einen Arbeitsbereich wird mithilfe von Azure RBAC verwaltet. In der Regel haben Benutzer, die Zugriff auf einen Log Analytics-Arbeitsbereich haben, der für Microsoft Sentinel auch Zugriff auf alle Arbeitsbereichsdaten, einschließlich Sicherheitsinhalten. Administratoren können Azure Rollen verwenden, um den Zugriff auf bestimmte Features in Microsoft Sentinel zu konfigurieren, abhängig von den Zugriffsanforderungen in ihrem Team.

Möglicherweise haben Sie jedoch einige Benutzer, die nur auf bestimmte Daten in Ihrem Arbeitsbereich zugreifen müssen, aber keinen Zugriff auf die gesamte Microsoft Sentinel-Umgebung haben sollten. Sie können z. B. einem nicht sicherheitsrelevanten Betriebsteam (non-SOC) Zugriff auf die Windows-Ereignisdaten für die Server bereitstellen, die es besitzt.

In solchen Fällen wird empfohlen, die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) basierend auf den Ressourcen zu konfigurieren, die Ihren Benutzern erlaubt sind, anstatt ihnen Zugriff auf den Arbeitsbereich oder bestimmte Microsoft Sentinel Features zu gewähren. Diese Methode wird auch als Einrichten von RBAC im Ressourcenkontext bezeichnet.

Wenn Benutzer Zugriff auf Microsoft Sentinel Daten über die Ressourcen haben, auf die sie anstelle des Arbeitsbereichs zugreifen können, können sie Protokolle und Arbeitsmappen mit den folgenden Methoden anzeigen:

Über die Ressource selbst, z. B. einen Azure virtuellen Computer. Verwenden Sie diese Methode, um Protokolle und Arbeitsmappen nur für eine bestimmte Ressource anzuzeigen.
Über Azure Monitor. Verwenden Sie diese Methode, wenn Sie Abfragen erstellen möchten, die mehrere Ressourcen und/oder Ressourcengruppen umfassen. Wenn Sie zu Protokollen und Arbeitsmappen in Azure Monitor navigieren, definieren Sie Ihren Bereich für eine oder mehrere bestimmte Ressourcengruppen oder Ressourcen.

Aktivieren Sie RBAC im Ressourcenkontext in Azure Monitor. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf Protokolldaten und Arbeitsbereiche in Azure Monitor.

Hinweis

Wenn es sich bei Ihren Daten nicht um eine Azure-Ressource handelt, z. B. Syslog-, CEF- oder Microsoft Entra ID-Daten, oder daten, die von einem benutzerdefinierten Collector gesammelt werden, müssen Sie die Ressourcen-ID manuell konfigurieren, die zum Identifizieren der Daten und zum Aktivieren des Zugriffs verwendet wird. Weitere Informationen finden Sie unter Explizites Konfigurieren von Ressourcenkontext-RBAC für Ressourcen, die nicht Azure.

Darüber hinaus werden Funktionen und gespeicherte Suchvorgänge in ressourcenorientierten Kontexten nicht unterstützt. Daher werden Microsoft Sentinel Features wie Analyse und Normalisierung für RBAC im Ressourcenkontext in Microsoft Sentinel nicht unterstützt.

Szenarien für RBAC im Ressourcenkontext

In der folgenden Tabelle sind die Szenarien aufgeführt, in denen RBAC im Ressourcenkontext am hilfreichsten ist. Beachten Sie die Unterschiede bei den Zugriffsanforderungen zwischen SOC-Teams und Nicht-SOC-Teams.

Anforderungstyp	SOC-Team	Nicht-SOC-Team
Berechtigungen	Der gesamte Arbeitsbereich	Nur bestimmte Ressourcen
Datenzugriff	Alle Daten im Arbeitsbereich	Nur Daten für Ressourcen, auf die das Team zugreifen darf
Umgebung	Die vollständige Microsoft Sentinel Erfahrung, die möglicherweise durch die dem Benutzer zugewiesenen funktionalen Berechtigungen eingeschränkt ist	Nur Protokollabfragen und Arbeitsmappen

Wenn Ihr Team ähnliche Zugriffsanforderungen wie das in der obigen Tabelle beschriebene Nicht-SOC-Team hat, kann RBAC im Ressourcenkontext eine gute Lösung für Ihre organization sein.

Die folgende Abbildung zeigt beispielsweise eine vereinfachte Version einer Arbeitsbereichsarchitektur, in der Sicherheits- und Betriebsteams Zugriff auf verschiedene Datensätze benötigen und RBAC im Ressourcenkontext verwendet wird, um die erforderlichen Berechtigungen bereitzustellen.

In dieser Abbildung gilt Folgendes:

Der für Microsoft Sentinel aktivierte Log Analytics-Arbeitsbereich befindet sich in einem separaten Abonnement, um Berechtigungen besser von dem Abonnement zu isolieren, das die Anwendungsteams zum Hosten ihrer Workloads verwenden.
Die Anwendungsteams erhalten Zugriff auf ihre jeweiligen Ressourcengruppen, wo sie ihre Ressourcen verwalten können.

Diese separate RBAC für Abonnements und Ressourcenkontext ermöglicht es diesen Teams, Protokolle anzuzeigen, die von allen Ressourcen generiert wurden, auf die sie Zugriff haben, auch wenn die Protokolle in einem Arbeitsbereich gespeichert sind, auf den sie keinen direkten Zugriff haben. Die Anwendungsteams können auf ihre Protokolle über den Bereich Protokolle des Azure-Portal zugreifen, um Protokolle für eine bestimmte Ressource anzuzeigen, oder über Azure Monitor, um alle Protokolle anzuzeigen, auf die sie gleichzeitig zugreifen können.

Explizites Konfigurieren von Ressourcenkontext-RBAC für Nicht-Azure Ressourcen

Azure Ressourcen verfügen über integrierte Unterstützung für RBAC im Ressourcenkontext, erfordern jedoch möglicherweise eine zusätzliche Feinabstimmung, wenn Sie mit Ressourcen ohne Azure arbeiten. Daten in Ihrem Log Analytics-Arbeitsbereich, die für Microsoft Sentinel aktiviert sind, die nicht Azure Ressourcen sind, umfassen beispielsweise Syslog-, CEF- oder AAD-Daten oder daten, die von einem benutzerdefinierten Collector gesammelt werden.

Führen Sie die folgenden Schritte aus, wenn Sie die RBAC im Ressourcenkontext konfigurieren möchten, ihre Daten jedoch keine Azure Ressource sind.

So konfigurieren Sie die RBAC im Ressourcenkontext explizit:

Stellen Sie sicher, dass Sie die RBAC im Ressourcenkontext in Azure Monitor aktiviert haben.
Erstellen Sie eine Ressourcengruppe für jedes Benutzerteam, das ohne die gesamte Microsoft Sentinel Umgebung auf Ihre Ressourcen zugreifen muss.

Weisen Sie jedem Teammitglied Protokollleserberechtigungen zu .
Weisen Sie den von Ihnen erstellten Ressourcenteamgruppen Ressourcen zu, und kennzeichnen Sie Ereignisse mit den relevanten Ressourcen-IDs.

Wenn Azure Ressourcen Daten an Microsoft Sentinel senden, werden die Protokolldatensätze automatisch mit der Ressourcen-ID der Datenquelle gekennzeichnet.

Tipp

Es wird empfohlen, die Ressourcen, denen Sie Zugriff gewähren, unter einer bestimmten Ressourcengruppe zu gruppieren, die zu diesem Zweck erstellt wurde.

Wenn dies nicht möglich ist, stellen Sie sicher, dass Ihr Team über Protokollleseberechtigungen direkt für die Ressourcen verfügt, auf die es zugreifen soll.

Weitere Informationen zu Ressourcen-IDs finden Sie unter:

Ressourcen-IDs mit Protokollweiterleitung

Wenn Ereignisse mit dem Common Event Format (CEF) oder Syslog gesammelt werden, wird die Protokollweiterleitung verwendet, um Ereignisse aus mehreren Quellsystemen zu sammeln.

Wenn beispielsweise eine CEF- oder Syslog-Weiterleitungs-VM auf die Quellen lauscht, die Syslog-Ereignisse senden, und diese an Microsoft Sentinel weiterleitet, wird die VM-Ressourcen-ID für die Protokollweiterleitung allen weitergeleiteten Ereignissen zugewiesen.

Wenn Sie über mehrere Teams verfügen, stellen Sie sicher, dass Sie über separate VMs für die Protokollweiterleitung verfügen, die die Ereignisse für jedes einzelne Team verarbeiten.

Durch das Trennen Ihrer VMs wird beispielsweise sichergestellt, dass Syslog-Ereignisse, die zu Team A gehören, mithilfe der Collector-VM A erfasst werden.

Tipp

Wenn Sie eine lokale VM oder eine andere Cloud-VM wie AWS als Protokollweiterleitung verwenden, stellen Sie sicher, dass sie über eine Ressourcen-ID verfügt, indem Sie Azure Arc implementieren.
Um Ihre VM-Umgebung für die Protokollweiterleitung zu skalieren, sollten Sie eine VM-Skalierungsgruppe erstellen, um Ihre CEF- und Syslog-Protokolle zu erfassen.

Ressourcen-IDs mit Logstash-Sammlung

Wenn Sie Ihre Daten mit dem Microsoft Sentinel Logstash-Ausgabe-Plug-In sammeln, verwenden Sie das Feld azure_resource_id, um Ihren benutzerdefinierten Collector so zu konfigurieren, dass die Ressourcen-ID in Ihre Ausgabe eingeschlossen wird.

Wenn Sie RBAC im Ressourcenkontext verwenden und die von der API gesammelten Ereignisse für bestimmte Benutzer verfügbar sein sollen, verwenden Sie die Ressourcen-ID der Ressourcengruppe, die Sie für Ihre Benutzer erstellt haben.

Der folgende Code zeigt beispielsweise eine Logstash-Beispielkonfigurationsdatei:

 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>   
     }
 }

Tipp

Sie können mehrere output Abschnitte hinzufügen, um die Tags zu unterscheiden, die auf verschiedene Ereignisse angewendet werden.

Ressourcen-IDs mit der Log Analytics-API-Sammlung

Beim Sammeln mithilfe der Log Analytics-Datensammler-API können Sie Ereignisse mit einer Ressourcen-ID mithilfe des HTTP-Anforderungsheaders x-ms-AzureResourceId zuweisen.

Alternativen zur RBAC im Ressourcenkontext

Abhängig von den berechtigungen, die in Ihrem organization erforderlich sind, bietet die Verwendung von RBAC im Ressourcenkontext möglicherweise keine vollständige Lösung. Stellen Sie sich beispielsweise vor, ob die organization, deren Architektur im vorherigen Abschnitt beschrieben ist, einem internen Überwachungsteam auch Zugriff auf Office 365 Protokolle gewähren muss. In diesem Fall können sie RBAC auf Tabellenebene verwenden, um dem Überwachungsteam Zugriff auf die gesamte OfficeActivity-Tabelle zu gewähren, ohne Berechtigungen für eine andere Tabelle zu gewähren.

In der folgenden Liste werden Szenarien beschrieben, in denen andere Lösungen für den Datenzugriff möglicherweise besser ihren Anforderungen entsprechen:

Szenario	Lösung
Eine Tochtergesellschaft verfügt über ein SOC-Team, das eine vollständige Microsoft Sentinel Erfahrung erfordert.	Verwenden Sie in diesem Fall eine Architektur mit mehreren Arbeitsbereichen, um Ihre Datenberechtigungen zu trennen. Weitere Informationen finden Sie unter: Erweitern von Microsoft Sentinel über Arbeitsbereiche und Mandanten hinweg > Gleichzeitiges Arbeiten mit Incidents in vielen Arbeitsbereichen
Sie möchten Zugriff auf einen bestimmten Ereignistyp bereitstellen.	Geben Sie beispielsweise einem Windows-Administrator Zugriff auf Windows-Sicherheit Ereignisse in allen Systemen. Verwenden Sie in solchen Fällen RBAC auf Tabellenebene , um Berechtigungen für jede Tabelle zu definieren.
Beschränken Sie den Zugriff auf eine präzisere Ebene, entweder nicht basierend auf der Ressource, oder nur auf eine Teilmenge der Felder in einem Ereignis.	Beispielsweise können Sie den Zugriff auf Office 365 Protokolle basierend auf der Tochtergesellschaft eines Benutzers einschränken. In diesem Fall ermöglichen Sie den Zugriff auf Daten mithilfe der integrierten Integration mit Power BI-Dashboards und -Berichten.
Beschränken des Zugriffs nach Verwaltungsgruppe	Platzieren Sie Microsoft Sentinel unter einer separaten Verwaltungsgruppe, die der Sicherheit gewidmet ist, und stellen Sie sicher, dass nur minimale Berechtigungen an Gruppenmitglieder geerbt werden. Weisen Sie innerhalb Ihres Sicherheitsteams je nach Gruppenfunktion verschiedenen Gruppen Berechtigungen zu. Da alle Teams Zugriff auf den gesamten Arbeitsbereich haben, haben sie Zugriff auf die vollständige Microsoft Sentinel Erfahrung, die nur durch die Microsoft Sentinel Rollen eingeschränkt ist, denen sie zugewiesen sind. Weitere Informationen finden Sie unter Berechtigungen in Microsoft Sentinel.

Weitere Informationen finden Sie unter:

Feedback

War diese Seite hilfreich?

Last updated on 2026-04-23