Verwalten des Zugriffs auf Microsoft Sentinel-Daten nach Ressource

Artikel
10/16/2024

In der Regel haben Benutzer, die Zugriff auf einen für Microsoft Sentinel aktivierten Log Analytics-Arbeitsbereich haben, auch Zugriff auf alle Daten im Arbeitsbereich, einschließlich Sicherheitsinhalten. Administratoren können Azure-Rollen verwenden, um den Zugriff auf bestimmte Features in Microsoft Sentinel zu konfigurieren. Dies hängt jeweils von den Zugriffsanforderungen des Teams ab.

Möglicherweise verfügen Sie jedoch über Benutzer, die nur auf bestimmte Daten in Ihrem Arbeitsbereich zugreifen müssen, aber keinen Zugriff auf die gesamte Microsoft Sentinel-Umgebung haben sollten. Beispiel: Sie möchten einem nicht für Sicherheitsvorgänge zuständigen Team Zugriff auf die Windows-Ereignisdaten für die eigenen Server gewähren.

Für diesen Fall empfehlen wir Ihnen, Ihre rollenbasierte Zugriffssteuerung (RBAC) basierend auf den Ressourcen zu konfigurieren, die für Ihre Benutzer zulässig sind – anstelle des Zugriffs auf den Arbeitsbereich oder bestimmte Microsoft Sentinel-Features. Diese Methode wird auch als die Einrichtung der rollenbasierten Zugriffssteuerung (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 mithilfe der folgenden Methoden anzeigen:

Über die Ressource selbst, z. B. einen virtuellen Azure-Computer. Verwenden Sie diese Methode, um die Protokolle und Arbeitsmappen nur für eine bestimmte Ressource anzuzeigen.
Über Azure Monitor. Verwenden Sie diese Methode, wenn Sie Abfragen erstellen möchten, mit denen mehrere Ressourcen bzw. Ressourcengruppen abgedeckt werden. Legen Sie Ihren Bereich beim Navigieren zu Protokollen und Arbeitsmappen in Azure Monitor auf eine oder mehrere bestimmte Ressourcengruppen oder Ressourcen fest.

Aktivieren Sie in Azure Monitor die rollenbasierte Zugriffssteuerung (RBAC) für den Ressourcenkontext. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf Protokolldaten und Arbeitsbereiche in Azure Monitor.

Hinweis

Falls es sich bei Ihren Daten nicht um eine Azure-Ressource, z. B. Syslog-, CEF- oder Microsoft Entra ID-Daten, oder von einem benutzerdefinierten Sammler erfasste Daten handelt, müssen Sie manuell die Ressourcen-ID konfigurieren, die zum Ermitteln der Daten und Aktivieren des Zugriffs verwendet wird. Weitere Informationen finden Sie unter Explizites Konfigurieren der rollenbasierten Zugriffssteuerung (RBAC) im Ressourcenkontext für Non-Azure-Ressourcen.

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 Ressourcen- und Kontextbasierte RBAC in Microsoft Sentinel nicht unterstützt.

Szenarien für die rollenbasierte Zugriffssteuerung (RBAC) im Ressourcenkontext

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

Anforderungstyp	SOC-Team	Anderes Team
Berechtigungen	Gesamter Arbeitsbereich	Nur bestimmte Ressourcen
Datenzugriff	Alle Daten des Arbeitsbereichs	Nur Daten für Ressourcen, für die das Team eine Zugriffsberechtigung besitzt
Erfahrung	Die vollständige Microsoft Sentinel-Benutzeroberfläche, die möglicherweise durch die dem Benutzer zugewiesenen funktionalen Berechtigungen eingeschränkt ist	Nur Protokollabfragen und Arbeitsmappen

Falls für Ihr Team ähnliche Zugriffsanforderungen wie für andere Teams (keine SOC-Teams) gemäß der obigen Tabelle bestehen, ist RBAC im Ressourcenkontext unter Umständen gut für Ihre Organisation geeignet.

Die folgende Abbildung zeigt zum Beispiel die vereinfachte Version einer Arbeitsbereichsarchitektur, bei der Sicherheits- und Betriebsteams Zugriff auf verschiedene Datasets benötigen. Hier wird die Ressourcenkontext-RBAC verwendet, um die erforderlichen Berechtigungen zu erteilen.

In dieser Abbildung:

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

Durch dieses separate Abonnement und die Ressourcenkontext-RBAC können diese Teams Protokolle sehen, die von den Ressourcen generiert wurden, auf die sie Zugriff haben. Dies funktioniert auch, wenn die Protokolle in einem Arbeitsbereich gespeichert sind, in dem sie keinen direkten Zugriff haben. Die Anwendungsteams können entweder über den Bereich Protokolle im Azure-Portal auf ihre Protokolle zugreifen, um Protokolle für eine bestimmte Ressource anzusehen. Oder sie können sich über Azure Monitor alle Protokolle anzeigen lassen, auf die sie gleichzeitig zugreifen können.

Explizites Konfigurieren der rollenbasierten Zugriffssteuerung (RBAC) im Ressourcenkontext für Non-Azure-Ressourcen

Azure-Ressourcen verfügen über eine integrierten Support für rollenbasierte Zugriffssteuerung auf Ressourcenkontext, benötigen jedoch möglicherweise eine zusätzliche Feinabstimmung für die Arbeit mit Nicht-Azure-Ressourcen. Zu den Daten in Ihrem für Microsoft Sentinel aktivierten Log Analytics-Arbeitsbereich, bei denen es sich nicht um Azure-Ressourcen handelt, zählen beispielsweise Syslog-, CEF- oder AAD-Daten oder von einem benutzerdefinierten Collector gesammelte Daten.

Führen Sie die folgenden Schritte aus, wenn Sie die rollenbasierte Zugriffssteuerung (RBAC) im Ressourcenkontext konfigurieren möchten, es sich bei Ihren Daten aber nicht um eine Azure-Ressource handelt.

Gehen Sie wie folgt vor, um die rollenbasierte Zugriffssteuerung im Ressourcenkontext explizit zu konfigurieren:

Vergewissern Sie sich, dass Sie die rollenbasierte Zugriffssteuerung (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 Berechtigungen für das Lesen von Protokollen zu.
Weisen Sie den von Ihnen erstellten Ressourcenteamgruppen Ressourcen zu, und versehen Sie die Ereignisse mit den relevanten Ressourcen-IDs.

Wenn Azure-Ressourcen Daten an Microsoft Sentinel senden, werden die Protokolleinträge automatisch mit der Ressourcen-ID der Datenquelle versehen.

Tipp

Wir empfehlen Ihnen, die Ressourcen, für die Sie Zugriff gewähren, in einer speziell für diesen Zweck erstellten Ressourcengruppe zu gruppieren.

Falls dies nicht möglich ist, sollten Sie sicherstellen, dass Ihr Team über Protokollleseberechtigungen direkt für die Ressourcen verfügt, auf die Zugriff bestehen soll.

Weitere Informationen zu Ressourcen-IDs finden Sie unter:

Ressourcen-IDs mit Protokollweiterleitung

Wenn Ereignisse per Common Event Format (CEF) oder Syslog erfasst werden, wird die Protokollweiterleitung genutzt, um Ereignisse für mehrere Quellsysteme zu erfassen.

Wenn beispielsweise eine CEF- oder Syslog-Weiterleitungs-VM die Quellen abhört, die Syslog-Ereignisse senden, und diese an Microsoft Sentinel weiterleitet, wird die Ressourcen-ID der Log-Weiterleitungs-VM allen Ereignissen zugewiesen, die sie weiterleitet.

Falls mehrere Teams vorhanden sind, sollten Sie sicherstellen, dass Sie über separate VMs für die Protokollweiterleitung verfügen, von denen die Ereignisse für die einzelnen Teams verarbeitet werden.

Durch die Trennung Ihrer VMs wird beispielsweise dafür gesorgt, dass Syslog-Ereignisse, die zu Team „A“ gehören, auch mit der Sammler-VM „A“ erfasst werden.

Tipp

Stellen Sie bei Verwendung einer lokalen VM oder anderen Cloud-VM, z. B. AWS, als Mittel für die Protokollweiterleitung sicher, dass diese über eine Ressourcen-ID verfügt, indem Sie Azure Arc implementieren.
Erwägen Sie, zur Skalierung Ihrer VM-Umgebung für die Protokollweiterleitung eine VM-Skalierungsgruppe zu erstellen, über die Ihre CEF- und Sylog-Protokolle erfasst werden.

Ressourcen-IDs mit Logstash-Sammlung

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

Wenn Sie die rollenbasierte Zugriffssteuerung (RBAC) im Ressourcenkontext nutzen und die per API erfassten 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 enthält ein Beispiel für eine Logstash-Konfigurationsdatei:

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

Tipp

Hierbei kann es ratsam sein, mehrere output-Abschnitte hinzuzufügen, um die auf die einzelnen Ereignisse angewendeten Tags unterscheiden zu können.

Ressourcen-IDs mit der Log Analytics-API-Sammlung

Bei Verwendung der Log Analytics-Datensammler-API können Sie für die Zuweisung zu Ereignissen eine Ressourcen-ID nutzen, indem Sie den HTTP-Anforderungsheader x-ms-AzureResourceId verwenden.

Alternativen zur Ressourcenkontext-RBAC

Je nach den Berechtigungen, die für Ihre Organisation benötigt werden, ist die Nutzung von RBAC im Ressourcenkontext ggf. keine vollwertige Lösung. Gehen wir z. B. davon aus, dass die Organisation, deren Architektur im vorherigen Abschnitt beschrieben ist, einem internen Überwachungsteam Zugriff auf Office 365-Protokolle gewähren muss. In diesem Fall kann RBAC auf Tabellenebene verwendet werden, um dem Überwachungsteam Zugriff auf die gesamte OfficeActivity-Tabelle zu gewähren, ohne dabei auch Berechtigungen für eine andere Tabelle zu erteilen.

Die folgende Liste enthält Beschreibungen von Szenarien, in denen andere Datenzugriffslösungen unter Umständen besser für Ihre Anforderungen geeignet sind:

Szenario	Lösung
Eine Niederlassung verfügt über ein SOC-Team, das eine vollständige Microsoft Sentinel-Erfahrung erfordert.	Verwenden Sie in diesem Fall eine Architektur mit mehreren Arbeitsbereichen, damit Sie Ihre Datenberechtigungen trennen können. Weitere Informationen finden Sie unter Erweitern von Microsoft Sentinel über Arbeitsbereiche und Mandanten hinweg >Arbeiten mit Vorfällen in vielen Arbeitsbereichen gleichzeitig
Sie möchten Zugriff auf eine bestimmte Art von Ereignis gewähren.	Gewähren Sie für einen Windows-Administrator den Zugriff auf Windows-Sicherheitsereignisse auf allen Systemen. Verwenden Sie in solchen Fällen RBAC auf Tabellenebene, um die Berechtigungen für die einzelnen Tabellen festzulegen.
Der Zugriff auf eine Ebene mit höherer Granularität soll eingeschränkt werden (entweder nicht basierend auf der Ressource oder nur auf einen Teil der Felder eines Ereignisses).	Es kann beispielsweise sein, dass Sie den Zugriff auf Office 365-Protokolle auf ein Tochterunternehmen eines Benutzers beschränken möchten. Gewähren Sie in diesem Fall Zugriff auf die Daten, indem Sie die integrierte Integration mit Power BI-Dashboards und -Berichten verwenden.
Einschränken des Zugriffs nach Verwaltungsgruppe	Platzieren Sie Microsoft Sentinel in einer separaten Verwaltungsgruppe, die speziell auf Sicherheit ausgelegt ist, sodass nur minimale Berechtigungen an die Gruppenmitglieder vererbt werden. Weisen Sie innerhalb Ihres Sicherheitsteams den verschiedenen Gruppen Berechtigungen entsprechend ihrer jeweiligen Funktion zu. Da alle Teams Zugriff auf den gesamten Arbeitsbereich haben, haben sie ebenfalls Zugriff auf die gesamte Microsoft Sentinel-Benutzeroberfläche. Dies wird nur durch die Microsoft Sentinel-Rollen eingeschränkt, denen sie zugewiesen sind. Weitere Informationen hierzu finden Sie unter Berechtigungen in Microsoft Sentinel.

Nächste Schritte

Weitere Informationen finden Sie unter Berechtigungen in Microsoft Sentinel.

Freigeben über