Bewährte Methoden für die Microsoft Sentinel-Arbeitsbereichsarchitektur
Wenn Sie die Bereitstellung Ihres Microsoft Sentinel-Arbeitsbereichs planen, müssen Sie auch Ihre Log Analytics-Arbeitsbereichsarchitektur entwerfen. Entscheidungen über die Arbeitsbereichsarchitektur werden in der Regel von den geschäftlichen und technischen Anforderungen gesteuert. In diesem Artikel werden wichtige Faktoren für die Entscheidung behandelt, anhand derer Sie die richtige Arbeitsbereichsarchitektur für Ihre Organisationen ermitteln können. Dies umfasst u. a.:
- ob Sie einen einzelnen oder mehrere Mandanten verwenden wollen
- sämtliche Konformitätsanforderungen für die Datensammlung und -speicherung
- Steuern des Zugriffs auf Microsoft Sentinel-Daten
- die Kostenauswirkungen verschiedener Szenarien
Weitere Informationen finden Sie unter Entwerfen Ihrer Microsoft Sentinel-Arbeitsbereichsarchitektur, Beispielentwürfe von Arbeitsbereichen für gängige Szenarien und Aktivitäten vor der Bereitstellung und Voraussetzungen für die Bereitstellung von Microsoft Sentinel.
Weitere Informationen finden Sie in unserem Video: Gestalten von SecOps für den Erfolg: Bewährte Methoden zum Bereitstellen von Microsoft Sentinel.
Dieser Artikel ist Teil des Bereitstellungshandbuchs für Microsoft Sentinel.
Überlegungen zu Mandanten
Wenige Arbeitsbereiche sind einfach zu verwalten, aber möglicherweise gibt es in Ihrer Organisation bestimmte Anforderungen für mehrere Mandanten und mehrere Arbeitsbereiche. Viele Organisationen verfügen beispielsweise über eine Cloudumgebung, die mehrere Microsoft Entra-Mandanten enthält, die das Ergebnis von Fusionen und Übernahmen sind oder aufgrund von Anforderungen an die Identitätstrennung entstanden.
Berücksichtigen Sie bei der Ermittlung der benötigten Mandanten und Arbeitsbereiche, dass die meisten Microsoft Sentinel-Features mit einem einzelnen Arbeitsbereich oder einer einzelnen Microsoft Sentinel-Instanz betrieben werden, und dass Microsoft Sentinel alle Protokolle erfasst, die sich im Arbeitsbereich befinden.
Die Kosten sind einer der wichtigsten Aspekte bei der Festlegung der Microsoft Sentinel-Architektur. Weitere Informationen finden Sie unter Microsoft Sentinel – Kosten und Abrechnung.
Verwenden mehrerer Mandanten
Wenn Sie über mehrere Mandanten verfügen, z. B. wenn Sie ein Dienstanbieter für verwaltete Sicherheit (Managed Security Service Provider, MSSP) sind, empfehlen wir, mindestens einen Arbeitsbereich für jeden Microsoft Entra-Mandanten zu erstellen, um integrierte Dienst-zu-Dienst-Datenconnectors zu unterstützen, die nur innerhalb ihres eigenen Microsoft Entra-Mandanten funktionieren.
Alle Connectors, die auf Diagnoseeinstellungen basieren, können nicht mit einem Arbeitsbereich verbunden werden, der sich nicht im gleichen Mandanten wir die Ressource befindet. Dies gilt für Connectors wie Azure Firewall, Azure Storage, Azure Activity oder Microsoft Entra ID.
Nutzen Sie Azure Lighthouse, um mehrere Microsoft Sentinel-Instanzen in verschiedenen Mandanten zu verwalten.
Hinweis
Datenconnectors für Partner basieren oft auf API- oder Agent-Sammlungen und sind daher keinem bestimmten Microsoft Entra-Mandanten angefügt.
Überlegungen zur Vorschrifteneinhaltung
Nach dem Sammeln, Speichern und Verarbeiten Ihrer Daten wird die Konformität zu einer wichtigen Grundlage für Entwurfsentscheidungen, was erhebliche Auswirkungen auf Ihre Microsoft Sentinel-Architektur hat. Die Fähigkeit, zu überprüfen und nachzuweisen, wer unter welchen Bedingungen Zugriff auf welche Daten hat, ist in vielen Ländern und Regionen eine wichtige Anforderung an die Datenhoheit. Darüber hinaus ist die Bewertung von Risiken und das Gewinnen von Erkenntnissen über Microsoft Sentinel-Workflows für viele Kunden von besonderer Priorität.
In Microsoft Sentinel werden Daten größtenteils in demselben Gebiet oder in derselben Region gespeichert und verarbeitet. Es gibt jedoch auch ein paar Ausnahmen, z. B. wenn Erkennungsregeln im Zusammenhang mit dem Machine Learning von Microsoft genutzt werden. In solchen Fällen könnten Daten zur Verarbeitung in ein Gebiet außerhalb Ihres Arbeitsbereichs kopiert werden.
Weitere Informationen finden Sie unter:
- Geografische Verfügbarkeit und Data Residency
- Datenresidenz in Azure
- Speichern und Verarbeiten von EU-Daten in der EU – Blog zu EU-Richtlinien
Um Ihre Konformität zu überprüfen, müssen Sie sowohl Ihre Datenquellen als auch wie und wohin diese die Daten senden bewerten.
Hinweis
Der Log Analytics-Agent unterstützt TLS 1.2, um die Datensicherheit während der Übertragung zwischen dem Agent und dem Log Analytics-Dienst sicherzustellen, sowie den FIPS 140-Standard.
Wenn Sie Daten an ein Gebiet oder eine Region senden, die sich von Ihrem Microsoft Sentinel-Arbeitsbereich unterscheidet (unabhängig davon ob sich die sendende Ressource in Azure befindet oder nicht), sollten Sie die Nutzung eines Arbeitsbereichs in demselben Gebiet oder derselben Region in Betracht ziehen.
Überlegungen zu Regionen
Verwenden Sie unterschiedliche Microsoft Sentinel-Instanzen für jede Region. Obwohl Microsoft Sentinel in mehreren Regionen verwendet werden kann, gibt es für Sie möglicherweise gesonderte Anforderungen für das Trennen von Daten nach Team, Region oder Site sowie Vorschriften und Kontrollen, durch die Modelle mit mehreren Regionen unmöglich oder unnötig komplex werden. Die Nutzung separater Instanzen und Arbeitsbereiche für jede Region trägt dazu bei, Bandbreitenkosten und Kosten für ausgehende Daten im Zusammenhang mit dem regionsübergreifenden Verschieben von Daten zu vermeiden.
Beachten Sie Folgendes, wenn Sie mit mehreren Regionen arbeiten:
Kosten für ausgehende Daten fallen in der Regel an, wenn der Log Analytics- oder Azure Monitor-Agent Protokolle sammeln muss, z. B. auf virtuellen Computern.
Auch ausgehender Internetdatenverkehr wird in Rechnung gestellt, was Sie möglicherweise nicht betrifft, es sei denn, Sie exportieren Daten außerhalb Ihres Log Analytics-Arbeitsbereichs. Es können z. B. Gebühren für ausgehenden Internetdatenverkehr anfallen, wenn Sie Ihre Log Analytics-Daten auf einen lokalen Server exportieren.
Die Bandbreitenkosten variieren je nach Quell- und Zielregion sowie nach Sammlungsmethode. Weitere Informationen finden Sie unter:
Verwenden Sie Vorlagen für Ihre Analyseregeln, benutzerdefinierten Abfragen, Arbeitsmappen und anderen Ressourcen, um Ihre Bereitstellungen effizienter zu gestalten. Stellen Sie die Vorlagen bereit, anstatt jede Ressource in jeder Region manuell bereitzustellen.
Connectors, die auf Diagnoseeinstellungen basieren, verursachen keine Bandbreitenkosten. Weitere Informationen finden Sie unter Gebühren für Datenübertragung.
Wenn Sie beispielsweise Protokolle von VMs in der Region „USA, Osten“ sammeln und an einen Microsoft Sentinel-Arbeitsbereich in der Region „USA, Westen“ senden möchten, werden Ihnen die Kosten für diese Datenübertragung in Rechnung gestellt. Da der Log Analytics-Agent die Daten während der Übertragung komprimiert, kann die als Bandbreite abgerechnete Größe kleiner sein, als die tatsächliche Größe der Protokolle in Microsoft Sentinel.
Wenn Sie Syslog- und CEF-Protokolle aus mehreren Quellen auf der ganzen Welt sammeln, sollten Sie einen Syslog-Collector in derselben Region wie Ihren Microsoft Sentinel-Arbeitsbereich einrichten, um Bandbreitenkosten zu vermeiden, vorausgesetzt, die Einhaltung von Vorschriften ist kein Problem.
Die Überlegungen, ob Bandbreitenkosten separate Microsoft Sentinel-Arbeitsbereiche rechtfertigen, hängt von der Datenmenge ab, die Sie zwischen verschiedenen Regionen übertragen müssen. Verwenden Sie den Azure-Preisrechner, um Ihre Kosten zu ermitteln.
Weitere Informationen finden Sie unter Datenresidenz in Azure.
Überlegungen zum Zugriff
Möglicherweise haben Sie Situationen geplant, in denen verschiedene Teams Zugriff auf dieselben Daten benötigen. Ihr SOC-Team muss beispielsweise Zugriff auf alle Microsoft Sentinel-Daten haben, während die Betriebs- und Anwendungsteams nur Zugriff auf bestimmte Teile der Daten benötigen. Unabhängige Sicherheitsteams müssen möglicherweise ebenfalls auf Microsoft Sentinel-Features zugreifen können, aber mit jeweils unterschiedlichen Datensätzen.
Kombinieren Sie Ressourcenkontext-RBAC und RBAC auf Tabellenebene, um für Ihr Team eine große Bandbreite an Zugriffsoptionen bereitzustellen, mit denen die meisten Anwendungsfälle abgedeckt werden können.
Weitere Informationen hierzu finden Sie unter Berechtigungen in Microsoft Sentinel.
Ressourcenkontext-RBAC
Die folgende Abbildung zeigt 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 ist zu sehen, dass der Microsoft Sentinel-Arbeitsbereich in einem separaten Abonnement platziert wird, um Berechtigungen besser zu isolieren.
Hinweis
Eine weitere Möglichkeit besteht darin, Microsoft Sentinel in einer separaten Verwaltungsgruppe zu platzieren, die speziell auf Sicherheit ausgelegt ist. Auf diese Weise wird sichergestellt, dass nur minimale Berechtigungszuweisungen vererbt werden. Innerhalb des Sicherheitsteams werden mehreren Gruppen gemäß ihren Funktionen die entsprechenden Berechtigungen zugewiesen. Da diese 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.
Zusätzlich zum Sicherheitsabonnement wird ein separates Abonnement genutzt, in dem Anwendungsteams ihre Workloads hosten können. 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.
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. Weitere Informationen finden Sie unter Explizites Konfigurieren der rollenbasierten Zugriffssteuerung im Ressourcenkontext.
Table-level RBAC (RBAC auf Tabellenebene)
Mit der RBAC auf Tabellenebene können Sie bestimmte Datentypen (Tabellen) definieren, auf die nur eine bestimmte Benutzergruppe zugreifen kann.
Gehen wir z. B. davon aus, dass die Organisation, deren Architektur in der obigen Abbildung 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.
Überlegungen zum Zugriff bei mehreren Arbeitsbereichen
Wenn Sie in Ihrer Organisation über verschiedene Entitäten, Niederlassungen oder Gebiete verfügen, und diese jeweils eigene Sicherheitsteams haben, die Zugriff auf Microsoft Sentinel benötigen, sollten Sie separate Arbeitsbereiche für jede Entität oder Niederlassung verwenden. Implementieren Sie die separaten Arbeitsbereiche entweder in einem einzelnen Microsoft Entra-Mandanten oder mandantenübergreifend mithilfe von Azure Lighthouse.
Möglicherweise verwendet Ihr zentrales SOC-Team einen zusätzlichen, optionalen Microsoft Sentinel-Arbeitsbereich, um zentralisierte Artefakte wie Analyseregeln oder Arbeitsmappen zu verwalten.
Weitere Informationen finden Sie unter Vereinfachung der Arbeit mit mehreren Arbeitsbereichen.
Bewährte technische Methoden für das Erstellen Ihres Arbeitsbereichs
Beachten Sie beim Erstellen des Log Analytics-Arbeitsbereichs für Microsoft Sentinel die folgenden bewährten Methoden:
Integrieren Sie bei der Benennung Ihres ArbeitsbereichsMicrosoft Sentinel oder einen anderen Indikator in den Namen, sodass dieser leicht von Ihren anderen Arbeitsbereichen unterschieden werden kann.
Verwenden Sie den gleichen Arbeitsbereich sowohl für Microsoft Sentinel als auch für Microsoft Defender für Cloud, sodass alle von Microsoft Defender für Cloud gesammelten Protokolle auch von Microsoft Sentinel erfasst und verwendet werden können. Der von Microsoft Defender für Cloud erstellte Standardarbeitsbereich wird nicht als verfügbarer Arbeitsbereich für Microsoft Sentinel angezeigt.
Verwenden Sie einen dedizierten Arbeitsbereichscluster, wenn Ihre voraussichtliche Datenerfassung etwa bei 1 TB pro Tag oder höher liegt. Mit einem dedizierten Cluster können Sie Ressourcen für Ihre Microsoft Sentinel-Daten schützen, wodurch eine bessere Abfrageleistung für große Datensätze ermöglicht wird. Dedizierte Cluster bieten darüber hinaus die Möglichkeit, mehr Verschlüsselung und eine bessere Kontrolle über die Schlüssel Ihrer Organisation zu erhalten.
Wenden Sie keine Ressourcensperre auf einen Log Analytics-Arbeitsbereich an, den Sie für Microsoft Sentinel verwenden möchten. Eine Ressourcensperre in einem Arbeitsbereich kann zu Fehlern bei vielen Microsoft Sentinel-Vorgängen führen.
Vereinfachung der Arbeit mit mehreren Arbeitsbereichen
Wenn Sie mit mehreren Arbeitsbereichen arbeiten müssen, sollten Sie das Management und die Untersuchung von Incidents vereinfachen, indem Sie alle Incidents aus jeder Microsoft Sentinel-Instanz an einem einzigen Speicherort zusammenfassen und auflisten.
Nutzen Sie arbeitsbereichsübergreifende Abfragen, um auf Daten zu verweisen, die sich in anderen Microsoft Sentinel-Arbeitsbereichen befinden, z. B. in arbeitsbereichsübergreifenden Arbeitsmappen.
Die Verwendung von arbeitsbereichsübergreifender Abfragen ist vor allem dann sinnvoll, wenn wertvolle Informationen, die von Nutzen für Ihre aktuelle Aktion wären, in einem anderen Arbeitsbereich, Abonnement oder Mandanten gespeichert sind. Der folgende Code enthält ein Beispiel für eine arbeitsbereichsübergreifende Abfrage:
union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
Weitere Informationen finden Sie unter Erweitern von Microsoft Sentinel auf Arbeitsbereiche und Mandanten.
Nächste Schritte
In diesem Artikel wurden wichtige Faktoren für die Entscheidung behandelt, anhand derer Sie die richtige Arbeitsbereichsarchitektur für Ihre Organisationen ermitteln können.