Entwerfen der Microsoft Sentinel-Arbeitsbereichsarchitektur
Dieser Artikel enthält eine Entscheidungsstruktur, mit deren Hilfe Sie wichtige Entscheidungen zum Entwurf Ihrer Microsoft Sentinel-Arbeitsbereichsarchitektur treffen können. Weitere Informationen finden Sie unter Beispielentwürfe von Microsoft Sentinel-Arbeitsbereichen und Bewährte Methoden für die Microsoft Sentinel-Arbeitsbereichsarchitektur. Dieser Artikel ist Teil des Bereitstellungshandbuchs für Microsoft Sentinel.
Voraussetzungen
Bevor Sie die Entscheidungsstruktur durcharbeiten, stellen Sie sicher, dass Sie über die folgenden Informationen verfügen:
| Voraussetzung | BESCHREIBUNG |
|---|---|
| Rechtliche Anforderungen im Zusammenhang mit der Data Residency in Azure | Microsoft Sentinel kann in Arbeitsbereichen in den meisten, jedoch nicht in allen, Regionen ausgeführt werden, die in der geografischen Verfügbarkeit für Log Analytics unterstützt werden. Das Durchführen des Onboardings des Microsoft Sentinel-Diensts für neu unterstützte Log Analytics-Regionen kann einige Zeit dauern. Von Microsoft Sentinel generierte Daten, z. B. Vorfälle, Lesezeichen und Analyseregeln, enthalten möglicherweise einige Kundendaten, die aus den Log Analytics-Arbeitsbereichen des Kunden stammen. Weitere Informationen finden Sie unter Geografische Verfügbarkeit und Data Residency. |
| Datenquellen | Erfahren Sie, welche Datenquellen Sie verbinden müssen, einschließlich integrierter Connectors für Microsoft-Lösungen und Lösungen von anderen Anbietern als Microsoft. Sie können auch Common Event Format (CEF), Syslog oder eine REST-API verwenden, um Ihre Datenquellen mit Microsoft Sentinel zu verbinden. Wenn Sie über virtuelle Azure-Computer an mehreren Azure-Standorten verfügen, von denen Sie die Protokolle erfassen müssen, und die Einsparung von Kosten für ausgehende Daten für Sie von Bedeutung ist, müssen Sie die Kosten für ausgehende Daten mithilfe des Bandbreitenpreisrechners für jeden Azure-Standort berechnen. |
| Benutzerrollen und Datenzugriffsebenen/-berechtigungen | Microsoft Sentinel verwendet die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC). Dabei werden integrierte Rollen bereitgestellt, die Benutzern, Gruppen und Diensten in Azure zugewiesen werden können. Alle in Microsoft Sentinel integrierten Rollen gewähren Lesezugriff auf die Daten in Ihrem Microsoft Sentinel-Arbeitsbereich. Daher müssen Sie herausfinden, ob der Datenzugriff pro Datenquelle oder Zeilenebene gesteuert werden muss, da sich dies auf die Entscheidung beim Entwurf des Arbeitsbereichs auswirken wird. Weitere Informationen finden Sie unter Custom roles and advanced Azure RBAC (Benutzerdefinierte Rollen und erweiterte rollenbasierte Zugriffssteuerung in Azure (RBAC)). |
| Tägliche Erfassungsrate | Die tägliche Erfassungsrate (in der Regel in GB/Tag) ist einer der wichtigsten Faktoren bei den Überlegungen zur Kostenverwaltung und -planung sowie beim Entwurf von Arbeitsbereichen für Microsoft Sentinel. In den meisten Cloud- und Hybridumgebungen erzeugen Netzwerkgeräte wie Firewalls oder Proxys sowie Windows- und Linux-Server die am häufigsten erfassten Daten. Damit Sie die genauesten Ergebnisse erhalten, empfiehlt Microsoft ein umfassendes Inventar von Datenquellen. Alternativ dazu enthält der Microsoft Sentinel-Kostenrechner Tabellen, die bei der Schätzung des Speicherbedarfs von Datenquellen hilfreich sind. Wichtig: Diese Schätzungen sind ein Ausgangspunkt, die Einstellungen für die Ausführlichkeit des Protokolls und die Workload führen zu Abweichungen. Es wird empfohlen, Ihr System regelmäßig zu überwachen, um Änderungen nachzuverfolgen. Eine regelmäßige Überwachung wird basierend auf Ihrem Szenario empfohlen. Weitere Informationen finden Sie unter Azure Monitor-Protokolle: Preise. |
Entscheidungsstruktur
Die folgende Abbildung zeigt ein Flussdiagramm einer vollständigen Entscheidungsstruktur, mit dem Sie besser verstehen können, wie Sie Ihren Arbeitsbereich am besten entwerfen.
Die folgenden Abschnitte enthalten eine Volltextversion dieser Entscheidungsstruktur, einschließlich der folgenden Hinweise, auf die in der Abbildung verwiesen wird:
Hinweis #1 | Hinweis #2 | Hinweis #3 | Hinweis #4 | Hinweis #5 | Hinweis #6 | Hinweis #7 | Hinweis #8 | Hinweis #9 | Hinweis #10
Schritt 1: Neuer oder vorhandener Arbeitsbereich?
Verfügen Sie über einen vorhandenen Arbeitsbereich, den Sie für Microsoft Sentinel verwenden können?
Falls nicht und Sie ohnehin einen neuen Arbeitsbereich erstellen, fahren Sie direkt mit Schritt 2 fort.
Wenn Sie über einen vorhandenen Arbeitsbereich verfügen, den Sie möglicherweise verwenden, überlegen Sie, wie viele Daten Sie erfassen werden.
Schritt 2: Werden Daten in verschiedenen Azure-Geografien aufbewahrt?
Wenn Sie aufgrund von rechtlichen Anforderungen Daten in verschiedenen Azure-Geografien aufbewahren müssen, verwenden Sie für jede Azure-Region, für die Complianceanforderungen bestehen, einen separaten Microsoft Sentinel-Arbeitsbereich. Weitere Informationen finden Sie unter Überlegungen zu Bereichen.
Wenn Sie Daten nicht in verschiedenen Azure-Geografien aufbewahren müssen, fahren Sie mit Schritt 3 fort.
Schritt 3: Verfügen Sie über mehrere Azure-Mandanten?
Wenn Sie nur über einen einzelnen Mandanten verfügen, fahren Sie direkt mit Schritt 4 fort.
Wenn Sie über mehrere Azure-Mandanten verfügen, überlegen Sie, ob Sie Protokolle sammeln, die für eine Mandantengrenze spezifisch sind, z. B. Office 365 oder Microsoft Defender XDR.
Wenn Sie über keine mandantenspezifischen Protokolle verfügen, fahren Sie direkt mit Schritt 4 fort.
Wenn Sie tatsächlich mandantenspezifische Protokolle sammeln, verwenden Sie für jeden Microsoft Entra-Mandanten einen separaten Microsoft Sentinel-Arbeitsbereich. Für weitere Überlegungen fahren Sie mit Schritt 4 fort.
Entscheidungsstrukturhinweis #1: Protokolle, die sich auf Mandantengrenzen beschränken, wie bei Office 365 und Microsoft Defender for Cloud, können nur im Arbeitsbereich innerhalb desselben Mandanten gespeichert werden.
Obwohl es möglich ist, benutzerdefinierte Collectors zu verwenden, um mandantenspezifische Protokolle aus einem Arbeitsbereich in einem anderen Mandanten zu sammeln, wird dies aufgrund der folgenden Nachteile nicht empfohlen:
- Von benutzerdefinierten Connectors gesammelte Daten werden in benutzerdefinierten Tabellen erfasst. Daher können Sie nicht alle integrierten Regeln und Arbeitsmappen verwenden.
- Benutzerdefinierte Tabellen werden von einigen der integrierten Features wie UEBA und Regeln für maschinelles Lernen nicht berücksichtigt.
- Erforderliche zusätzliche Kosten und zusätzlicher Aufwand für die benutzerdefinierten Connectors, z. B. die Verwendung von Azure Functions und Logic Apps.
Wenn diese Nachteile für Ihre Organisation nicht von Bedeutung sind, fahren Sie mit Schritt 4 fort, anstatt separate Microsoft Sentinel-Arbeitsbereiche zu verwenden.
Schritt 4: Werden Abrechnung oder Chargeback geteilt?
Wenn Sie Ihre Abrechnung oder Ihr Chargeback teilen müssen, sollten Sie überlegen, ob die Nutzungsberichterstellung oder die manuelle Verrechnung für Sie geeignet ist.
Wenn Sie Ihre Abrechnung oder Ihr Chargeback nicht teilen müssen, fahren Sie mit Schritt 5 fort.
Wenn Sie Ihre Abrechnung oder Ihr Chargeback tatsächlich teilen müssen, sollten Sie über manuelle Verrechnung nachdenken. Um genaue Kosten pro Entität zu erhalten, können Sie eine geänderte Version der Microsoft Sentinel-Kostenarbeitsmappe verwenden, die die Kosten nach Entität aufschlüsselt.
Wenn die Nutzungsberichterstellung oder die manuelle Verrechnung für Sie geeignet ist, fahren Sie mit Schritt 5 fort.
Wenn weder die Nutzungsberichterstellung noch die manuelle Verrechnung für Sie geeignet ist, verwenden Sie für jeden Kostenträger einen separaten Microsoft Sentinel-Arbeitsbereich.
Entscheidungsstrukturhinweis #2: Weitere Informationen finden Sie unter Microsoft Sentinel – Kosten und Abrechnung.
Schritt 5: Werden Nicht-SOC-Daten erfasst?
Wenn Sie keine Nicht-SOC-Daten erfassen, wie beispielsweise operative Daten, können Sie direkt mit Schritt 6 fortfahren.
Wenn Sie tatsächlich Nicht-SOC-Daten erfassen, sollten Sie überlegen, ob es Überlappungen gibt, bei denen dieselbe Datenquelle sowohl für SOC-Daten als auch für Nicht-SOC-Daten erforderlich ist.
Wenn es tatsächlich Überlappungen zwischen SOC-Daten und Nicht-SOC-Daten gibt, behandeln Sie die sich überlappenden Daten nur als SOC-Daten. Überlegen Sie anschließend, ob die Erfassung sowohl für SOC-Daten als auch für Nicht-SOC-Daten einzeln weniger als 100 GB/Tag beträgt, kombiniert jedoch mehr als 100 GB/Tag:
- Ja: Fahren Sie zur weiteren Auswertung mit Schritt 6 fort.
- Nein: Wir empfehlen aus Gründen der Kosteneffizienz, nicht denselben Arbeitsbereich zu verwenden. Fahren Sie zur weiteren Auswertung mit Schritt 6 fort.
Weitere Informationen zu beiden Fällen finden Sie unter Hinweis 10.
Wenn es keine sich überlappenden Daten gibt, sollten Sie überlegen, ob die Erfassung sowohl für SOC-Daten als auch für Nicht-SOC-Daten einzeln weniger als 100 GB/Tag beträgt, kombiniert jedoch mehr als 100 GB/Tag:
Kombinieren Ihrer SOC-Daten und Nicht-SOC-Daten
Entscheidungsstrukturhinweis #3: Obwohl wir Kunden im Allgemeinen empfehlen, einen separaten Arbeitsbereich für ihre Nicht-SOC-Daten beizubehalten, damit Nicht-SOC-Daten keinen Microsoft Sentinel-Kosten unterliegen, kann es Situationen geben, in denen die Kombination von SOC- und Nicht-SOC-Daten weniger teurer ist als ihre Trennung.
Stellen Sie sich beispielsweise eine Organisation vor, die über Sicherheitsprotokolle mit einer Erfassung von 50 GB/Tag, Vorgangsprotokolle mit einer Erfassung von 50 GB/Tag und über einen Arbeitsbereich in der Region "USA, Osten" verfügt.
In der folgenden Tabelle werden Arbeitsbereichsoptionen mit und ohne separate Arbeitsbereiche verglichen.
Hinweis
Die in der folgenden Tabelle aufgeführten Kosten und Bedingungen sind nicht echt und dienen nur zur Veranschaulichung. Aktuelle Kosteninformationen erhalten Sie über den Microsoft Sentinel-Preisrechner.
| Arbeitsbereichsarchitektur | BESCHREIBUNG |
|---|---|
| Das SOC-Team verfügt über einen eigenen Arbeitsbereich, in dem Microsoft Sentinel aktiviert ist. Das Betriebsteam verfügt über einen eigenen Arbeitsbereich, in dem kein Microsoft Sentinel aktiviert ist. |
SOC-Team: Die Microsoft Sentinel-Kosten für 50 GB/Tag betragen 6.500 US-Dollar pro Monat. Die ersten drei Monate der Aufbewahrung sind kostenlos. Betriebsteam: – Die Kosten für Log Analytics mit 50 GB/Tag betragen etwa 3.500 US-Dollar pro Monat. - Die ersten 31 Tage der Aufbewahrung sind kostenlos. Die Gesamtkosten für beides betragen 10.000 USD pro Monat. |
| Sowohl das SOC-Team als auch das Betriebsteam nutzen denselben Arbeitsbereich, in dem Microsoft Sentinel aktiviert ist. | Bei einer Kombination beider Protokolle beträgt die Erfassung 100 GB/Tag und erfüllt damit die Voraussetzungen für die Berechtigung zur Mindestabnahme (50 % für Sentinel und 15 % für LA). Die Microsoft Sentinel-Kosten für 100 GB/Tag betragen 9.000 USD pro Monat. |
In diesem Beispiel erzielen Sie eine Kosteneinsparung von 1.000 USD pro Monat, indem Sie beide Arbeitsbereiche kombinieren, und das Betriebsteam hat darüber hinaus den Vorteil einer kostenlosen Aufbewahrung von 3 Monaten anstelle von nur 31 Tagen.
Dieses Beispiel ist nur relevant, wenn die SOC-Daten und Nicht-SOC-Daten jeweils eine Erfassungsgröße von >=50 GB/Tag und <100 GB/Tag aufweisen.
Entscheidungsstrukturhinweis #10: Wir empfehlen, einen separaten Arbeitsbereich für Nicht-SOC-Daten zu verwenden, damit Nicht-SOC-Daten keinen Microsoft Sentinel-Kosten unterliegen.
Diese Empfehlung für separate Arbeitsbereiche für Nicht-SOC-Daten basiert jedoch auf einer rein kostenorientierten Perspektive, und es gibt andere wichtige Entwurfsfaktoren, die bei der Entscheidung, ob ein einzelner Arbeitsbereich oder mehrere Arbeitsbereiche verwendet werden sollen, zu untersuchen sind. Um doppelte Erfassungskosten zu vermeiden, sollten Sie erwägen, überlappende Daten nur in einem einzelnen Arbeitsbereich mit Azure RBAC auf Tabellenebene zu erfassen.
Schritt 6: Mehrere Regionen?
Wenn Sie Protokolle von virtuellen Azure-Computern nur in einer einzelnen Region erfassen, fahren Sie direkt mit Schritt 7 fort.
Wenn Sie Protokolle von virtuellen Azure-Computern in mehreren Regionen erfassen, machen Sie sich dann viele Gedanken über die Kosten für ausgehende Daten?
Entscheidungsstrukturhinweis #4: Der Begriff „Ausgehende Daten“ bezieht sich auf die Bandbreitenkosten für die Übertragung von Daten aus Azure-Rechenzentren. Weitere Informationen finden Sie unter Überlegungen zu Bereichen.
Wenn die Reduzierung des Aufwands, der zum Verwalten separater Arbeitsbereiche erforderlich ist, Priorität hat, fahren Sie mit Schritt 7 fort.
Wenn die Kosten für ausgehende Daten eine so große Rolle spielen, dass sich die Verwaltung separater Arbeitsbereiche lohnt, verwenden Sie einen separaten Microsoft Sentinel-Arbeitsbereich für jede Region, in der Sie die Kosten für ausgehende Daten reduzieren müssen.
Entscheidungsstrukturhinweis #5: Wir empfehlen, so wenige Arbeitsbereiche wie möglich zu verwenden. Verwenden Sie den Azure-Preisrechner, um die Kosten zu schätzen und zu entscheiden, welche Regionen Sie tatsächlich benötigen, und kombinieren Sie Arbeitsbereiche für Regionen mit niedrigen Kosten für ausgehende Daten. Bandbreitenkosten machen im Vergleich zu separaten Kosten für die Microsoft Sentinel- und Log Analytics-Erfassung möglicherweise nur einen kleinen Teil Ihrer Azure-Rechnung aus.
Beispielsweise könnten Ihre Kosten wie folgt geschätzt werden:
- 1\.000 virtuelle Computer, die jeweils 1 GB/Tag generieren;
- Senden von Daten aus einer US-Region an eine EU-Region;
- Verwendung einer 2:1-Komprimierungsrate im Agent
Die Berechnung für diese geschätzten Kosten wäre:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costDiese Beispielkosten wären im Vergleich zu den monatlichen Kosten eines separaten Microsoft Sentinel- und Log Analytics-Arbeitsbereichs deutlich günstiger.
Hinweis
Die aufgeführten Kosten sind nicht echt und dienen nur zur Veranschaulichung. Aktuelle Kosteninformationen erhalten Sie über den Microsoft Sentinel-Preisrechner.
Schritt 7: Werden Daten getrennt oder Grenzen nach Besitz definiert?
Wenn Sie keine Daten trennen oder Besitzgrenzen definieren müssen, fahren Sie direkt mit Schritt 8 fort.
Wenn Sie tatsächlich Daten trennen oder Grenzen nach Besitz definieren müssen, muss dann jeder Datenbesitzer das Microsoft Sentinel-Portal verwenden?
Wenn jeder Datenbesitzer Zugriff auf das Microsoft Sentinel-Portal haben muss, verwenden Sie einen separaten Microsoft Sentinel-Arbeitsbereich für jeden Besitzer.
Entscheidungsstrukturhinweis #6: Für den Zugriff auf das Microsoft Sentinel-Portal ist es erforderlich, dass jeder Benutzer mindestens über die Rolle Microsoft Sentinel-Leser mit den Leser-Berechtigungen für alle Tabellen im Arbeitsbereich verfügt. Wenn ein Benutzer keinen Zugriff auf alle Tabellen im Arbeitsbereich hat, muss er Log Analytics verwenden, um in Suchabfragen auf die Protokolle zuzugreifen.
Wenn der Zugriff auf die Protokolle über Log Analytics für alle Besitzer ohne Zugriff auf das Microsoft Sentinel-Portal ausreicht, fahren Sie mit Schritt 8 fort.
Weitere Informationen hierzu finden Sie unter Berechtigungen in Microsoft Sentinel.
Schritt 8: Wird der Datenzugriff nach Datenquelle/Tabelle gesteuert?
Wenn Sie den Datenzugriff nicht nach Quelle oder Tabelle steuern müssen, verwenden Sie einen einzelnen Microsoft Sentinel-Arbeitsbereich.
Wenn Sie den Datenzugriff tatsächlich nach Quelle oder Tabelle steuern müssen, sollten Sie erwägen, in den folgenden Situationen die rollenbasierte Zugriffssteuerung (RBAC) im Ressourcenkontext zu verwenden:
Wenn Sie den Zugriff auf Zeilenebene steuern müssen, z. B. bei der Angabe mehrerer Besitzer für einzelne Datenquellen oder Tabellen
Wenn Sie über mehrere benutzerdefinierte Datenquellen/Tabellen verfügen, für die jeweils separate Berechtigungen erforderlich sind
Wenn Sie in anderen Fällen den Zugriff nicht auf Zeilenebene steuern müssen, stellen Sie mehrere benutzerdefinierte Datenquellen/Tabellen mit separaten Berechtigungen bereit, und verwenden Sie einen einzelnen Microsoft Sentinel-Arbeitsbereich mit RBAC auf Tabellenebene für die Datenzugriffssteuerung.
Überlegungen zu RBAC im Ressourcenkontext oder RBAC auf Tabellenebene
Wenn Sie die Verwendung der rollenbasierten Zugriffssteuerung (RBAC) im Ressourcenkontext oder auf Tabellenebene planen, sollten Sie die folgenden Informationen berücksichtigen:
Entscheidungsstrukturhinweis #7: Für die Konfiguration der rollenbasierten Zugriffssteuerung im Ressourcenkontext für Nicht-Azure-Ressourcen möchten Sie möglicherweise den Daten eine Ressourcen-ID zuordnen, wenn Sie diese an Microsoft Sentinel senden, so dass die Berechtigung mit der rollenbasierten Zugriffssteuerung im Ressourcenkontext auf einen Bereich festgelegt werden kann. Weitere Informationen finden Sie unter Explizites Konfigurieren der rollenbasierten Zugriffssteuerung im Ressourcenkontext und Access modes by deployment (Zugriffsmodi nach Bereitstellung).
Entscheidungsstrukturhinweis #8: Mit Ressourcenberechtigungen oder Ressourcenkontext wird ermöglicht, dass Benutzer Protokolle nur für Ressourcen anzeigen können, auf die sie Zugriff haben. Der Zugriffsmodus für den Arbeitsbereich muss auf Benutzerressource oder Arbeitsbereichsberechtigungen festgelegt werden. Nur Tabellen, die für die Ressourcen relevant sind, für die der Benutzer über Berechtigungen verfügt, sind in den Suchergebnissen auf der Seite Protokolle in Microsoft Sentinel enthalten.
Entscheidungsstrukturhinweis #9: RBAC auf Tabellenebene ermöglicht zusätzlich zu den anderen Berechtigungen eine präzisere Steuerung von Daten in einem Log Analytics-Arbeitsbereich. Mit diesem Steuerelement können Sie bestimmte Datentypen definieren, auf die nur eine bestimmte Gruppe von Benutzern Zugriff besitzt. Weitere Informationen finden Sie unter RBAC auf Tabellenebene in Microsoft Sentinel.
Nächste Schritte
In diesem Artikel haben Sie mehr über die Entscheidungsstruktur erfahren, mit deren Hilfe Sie wichtige Entscheidungen zum Entwurf Ihrer Microsoft Sentinel-Arbeitsbereichsarchitektur treffen können.