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: Entwerfen erfolgreicher SecOps: Bewährte Methoden zum Bereitstellen von 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 z. B. über eine Cloudumgebung, die mehrere Azure Active Directory-Mandanten (Azure AD) enthält. Solche Umgebungen entstehen vor allem durch Fusionen und Übernahmen oder aufgrund von Anforderungen an die Identitätstrennung.

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 Managed Security Service Provider (MSSP) sind, empfiehlt es sich, mindestens einen Arbeitsbereich für jeden Azure AD-Mandanten zu erstellen, um integrierte Dienst-zu-Dienst-Connectors zu unterstützen, die nur innerhalb ihres eigenen Azure AD-Mandanten funktionieren.

Connectors, die auf Diagnoseeinstellungen basieren, können nicht mit einem Arbeitsbereich verbunden werden, der sich nicht in dem Mandanten befindet, in dem sich auch die Ressource befindet. Dies gilt für Connectors wie Azure Firewall, Azure Storage, Azure Activity oder Azure Active Directory.

Nutzen Sie Azure Lighthouse, um mehrere Microsoft Sentinel-Instanzen in verschiedenen Mandanten zu verwalten.

Hinweis

Partnerdatenconnectors basieren in der Regel auf API- oder Agent-Sammlungen und sind daher keinem bestimmten Azure AD-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önnen Daten zur Verarbeitung in ein Gebiet außerhalb Ihres Arbeitsbereichs kopiert werden.

Weitere Informationen finden Sie unter:

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 möglicherweise gesonderte Anforderungen für das Trennen von Daten nach Team, Region oder Standort 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 ausgehende Internetdaten werden in Rechnung gestellt. Dies betrifft Sie nur, wenn Sie Daten außerhalb Ihres Log Analytics-Arbeitsbereichs exportieren. 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. Dies gilt unter der Voraussetzung, dass dadurch keine Konformitätsprobleme entstehen.

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 treten bei Ihnen Situationen auf, 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.

Diagramm einer Beispielarchitektur für Ressourcenkontext-RBAC

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 integrierte Unterstützung für Ressourcenkontext-RBAC, benötigen jedoch möglicherweise eine zusätzliche Optimierung 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 Azure AD-Mandanten oder mandantenübergreifend mithilfe von Azure Lighthouse.

Es ist ebenfalls möglich, dass Ihr zentrales SOC-Team einen zusätzlichen, optionalen Microsoft Sentinel-Arbeitsbereich nutzt, 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