Wählen Sie eine Azure-Zielplattform zum Hosten der exportierten Verlaufsdaten aus

  • Artikel

Eine der wichtigen Entscheidungen, die Sie während des Migrationsprozesses treffen, ist, wo Ihre Verlaufsdaten gespeichert werden sollen. Um diese Entscheidung zu treffen, müssen Sie die verschiedenen Zielplattformen verstehen und vergleichen können.

In diesem Artikel werden Zielplattformen in Bezug auf Leistung, Kosten, Benutzerfreundlichkeit und Verwaltungsaufwand verglichen.

Hinweis

Die Überlegungen in dieser Tabelle gelten nur für die Protokollverlaufsmigration und nicht für andere Szenarien, wie z. B. die langfristige Aufbewahrung.

Basisprotokolle/Archiv Azure Data Explorer (ADX) Azure Blob Storage ADX + Azure Blob Storage
Fähigkeiten: • Nutzen Sie die meisten der vorhandenen Azure Monitor-Protokolle zu geringeren Kosten.
• Basic Logs werden acht Tage lang aufbewahrt und anschließend automatisch in das Archiv übertragen (gemäß dem ursprünglichen Aufbewahrungszeitraum).
• Verwenden Sie Suchaufträge, um in Petabytes von Daten zu suchen und bestimmte Ereignisse zu finden.
• Zur detaillierten Untersuchung über einen bestimmten Zeitraum hinweg stellen Sie Daten aus dem Archiv wieder her. Die Daten stehen dann im Hot Cache für weitere Analysen zur Verfügung.		 • Sowohl ADX als auch Microsoft Sentinel verwenden die Kusto-Abfragesprache (KQL), sodass Sie Daten auf beiden Plattformen abfragen, aggregieren oder korrelieren können. Beispielsweise können Sie eine KQL-Abfrage von Microsoft Sentinel ausführen, um in ADX gespeicherte Daten mit in Log Analytics gespeicherten Daten zu verknüpfen.
• Mit ADX haben Sie nachhaltige Kontrolle über die Clustergröße und -konfiguration. Sie können beispielsweise einen größeren Cluster erstellen, um einen höheren Erfassungsdurchsatz zu erzielen oder einen kleineren Cluster erstellen, um Ihre Kosten zu kontrollieren.		 • Blob Storage ist für die Speicherung großer Mengen unstrukturierter Daten optimiert.
• Bietet wettbewerbsfähige Kosten.
• Geeignet für ein Szenario, in dem Ihre Organisation die Barrierefreiheit oder Leistung nicht priorisiert, wie z. B. wenn die Organisation die Compliance- oder Überwachungsanforderungen erfüllt.		 • Daten werden in einem BLOB-Speicher gespeichert, der wenig kostet.
• Sie verwenden ADX zum Abfragen der Daten in KQL, sodass Sie einfach auf die Daten zugreifen können. Erfahren Sie, wie Sie Azure Monitor-Daten mit ADX abfragen
Benutzerfreundlichkeit: Hoch

Die Archivierungs- und Suchoptionen sind einfach zu verwenden und über das Microsoft Sentinel-Portal zugänglich. Die Daten sind jedoch nicht sofort für Abfragen verfügbar. Sie müssen eine Suche ausführen, um die Daten abzurufen; dies kann einige Zeit dauern, je nachdem, wie viele Daten überprüft und zurückgegeben werden.		 Gut

Im Kontext von Microsoft Sentinel ziemlich einfach zu verwenden. Sie können beispielsweise eine Azure-Arbeitsmappe verwenden, um Daten in Microsoft Sentinel und ADX zu visualisieren. Sie können auch ADX-Daten aus dem Microsoft Sentinel-Portal mithilfe des ADX-Proxys abfragen.		 Schlecht

Bei der Migration von Verlaufsdaten müssen Sie möglicherweise mit Millionen von Dateien umgehen, sodass das Untersuchen der Daten zu einer Herausforderung wird.		 Mittelmäßig

Während die Verwendung des externaldata Operators mit großen Anzahl von Blobs, auf die verwiesen werden soll, sehr schwierig ist, besteht dieses Problem bei Verwendung externer ADX-Tabellen nicht. Die Definition der externen Tabelle versteht die Ordnerstruktur des BLOB-Speichers und ermöglicht es Ihnen, die Daten, die in vielen verschiedenen Blobs und Ordnern enthalten sind, transparent abzufragen.
Verwaltungsaufwand: Vollständige Verwaltung

Die Such- und Archivierungsoptionen werden vollständig verwaltet, und es fällt kein zusätzlicher Verwaltungsaufwand an.		 Hoch

ADX ist nicht in Microsoft Sentinel integriert, sodass Überwachung und Wartung erforderlich sind.		 Niedrig

Während diese Plattform wenig Wartung erfordert, führt die Auswahl dieser Plattform zu weiteren Überwachungs- und Konfigurationsaufgaben, wie z. B. zum Einrichten der Lebenszyklusverwaltung.		 Mittel

Mit dieser Option verwalten und überwachen Sie ADX und Azure Blob Storage, die beide externe Komponenten von Microsoft Sentinel sind. Auch wenn ADX zeitweise heruntergefahren werden kann, sollten Sie den zusätzlichen Verwaltungsaufwand mit dieser Option berücksichtigen.
Leistung: Mittel

Sie interagieren in der Regel mit Basisprotokollen innerhalb des Archivs mithilfe von Suchaufträgen, die geeignet sind, wenn Sie weiterhin auf die Daten zugreifen möchten, aber keinen unmittelbaren Zugriff auf die Daten benötigen.		 Hoch bis niedrig

• Die Abfrageleistung eines ADX-Clusters hängt von der Anzahl der Knoten im Cluster, der virtuellen Clustercomputer-SKU, der Datenpartitionierung und weiteren Komponenten ab.
• Während Sie dem Cluster Knoten hinzufügen, verbessert sich die Leistung, aber die Kosten steigen.
• Wenn Sie ADX verwenden, empfehlen wir Ihnen, Ihre Clustergröße so zu konfigurieren, dass Leistung und Kosten ausgeglichen sind. Diese Konfiguration hängt von den Anforderungen Ihrer Organisation ab, wie z. B. davon, wie schnell Ihre Migration abgeschlossen sein muss, wie oft auf die Daten zugegriffen wird, und wie lang die erwartete Antwortzeit ist.		 Niedrig

Bietet zwei Leistungsstufen: Premium oder Standard. Auch wenn sich beide Ebenen für die Langzeitspeicherung eignen, ist die Standardoption kostengünstiger. Erfahren Sie mehr über Leistungs- und Skalierbarkeitsgrenzwerte.		 Niedrig

Da sich die Daten im BLOB-Speicher befinden, ist die Leistung durch diese Plattform begrenzt.
Kosten: Hoch

Die Kosten setzen sich aus zwei Komponenten zusammen:
• Erfassungskosten. Für jedes GB Daten, das in den Basisprotokollen erfasst wird, fallen Microsoft Sentinel- und Azure Monitor Logs-Erfassungskosten in Höhe von ca. 1 USD/GB an. Sehen Sie sich die Preisdetails an.
• Archivierungskosten. Die Kosten für die Daten in der Archivebene belaufen sich auf ca. 0,02 SD/GB pro Monat. Sehen Sie sich die Preisdetails an.
Zusätzlich zu diesen beiden Kostenkomponenten fallen, wenn Sie häufig Zugriff auf die Daten nehmen müssen, zusätzliche Kosten an, wenn Sie per Suchauftrag auf die Daten zugreifen.		 Hoch bis niedrig

• Da ADX ein Cluster aus virtuellen Computern ist, werden Ihnen die Kosten basierend auf der Berechnung, Speicherung und Netzwerknutzung zuzüglich eines ADX-Aufschlags in Rechnung gestellt (siehe die Preisdetails. Daher sind die Kosten umso höher, je mehr Knoten Sie Ihrem Cluster hinzufügen und je mehr Daten Sie speichern.
• ADX bietet darüber hinaus automatische Skalierungsfunktionen zum Anpassen der Arbeitslast nach Bedarf. Bei ADX können Sie auch von Preisen für reservierte Instanzen profitieren. Sie können ihre eigenen Kostenberechnungen im Azure-Preisrechner ausführen.		 Niedrig

Bei optimaler Einrichtung fallen bei Azure Blob Storage die geringsten Kosten an. Für höhere Effizienz und Kosteneinsparungen können Sie mit der Azure Storage Lebenszyklusverwaltung ältere Blobs automatisch in günstigeren Speicherstufen platzieren.		 Niedrig

ADX fungiert in diesem Fall nur als Proxy, sodass der Cluster klein sein kann. Darüber hinaus kann der Cluster heruntergefahren werden, wenn Sie keinen Zugriff auf die Daten benötigen, und nur gestartet werden, wenn Sie auf die Daten zugreifen müssen.
So greifen Sie auf die Daten zu: Suchaufträge Direkte KQL Abfragen externaldata Geänderte KQL Abfragen
Szenario: Gelegentlicher Zugriff

Maßgeblich in Szenarien, in denen Sie keine umfangreichen Analysen ausführen oder Analyseregeln auslösen müssen, und wenn Sie nur gelegentlich auf die Daten zugreifen müssen.		 Häufiger Zugriff

Maßgeblich in Szenarien, in denen Sie häufig auf die Daten zugreifen und außerdem steuern müssen, wie groß der Cluster ist und wie er konfiguriert wird.		 Compliance/Überwachung

• Optimal zum Speichern von großer Mengen unstrukturierter Daten.
• Maßgeblich in Szenarien, in denen Sie keinen schnellen Zugriff auf die Daten und keine hohe Leistung benötigen, wie z. B. zu Compliance- oder Überwachungszwecken.		 Gelegentlicher Zugriff

Maßgeblich in Szenarien, in denen Sie von den niedrigen Kosten von Azure Blob Storage profitieren möchten und relativ schnell Zugriff auf die Daten nehmen können müssen.
Komplexität: Sehr niedrig Medium Niedrig High
Bereitschaft: Allgemein verfügbar Allgemein verfügbar Allgemein verfügbar Allgemein verfügbar

Allgemeine Hinweise

Nachdem Sie nun mehr über die verfügbaren Zielplattformen wissen, überprüfen Sie diese wichtigen Faktoren, um sich endgültig zu entscheiden.

Verwendung der erfassten Protokolle

Definieren Sie als Orientierungshilfe für die Auswahl der Plattform für die Datenerfassung, wie Ihre Organisation die erfassten Protokolle verwendet.

Berücksichtigen Sie diese drei allgemeinen Szenarien:

  • Ihre Organisation muss die Protokolle nur zu Compliance- oder Überwachungszwecken behalten. In diesem Fall wird Ihre Organisation selten auf die Daten zugreifen. Auch wenn Ihre Organisation auf die Daten zugreift, haben hohe Leistung oder Benutzerfreundlichkeit keine Priorität.
  • Ihre Organisation muss die Protokolle aufbewahren, damit Ihre Teams problemlos und relativ schnell auf die Protokolle zugreifen können.
  • Ihre Organisation muss die Protokolle aufbewahren, damit Ihre Teams gelegentlich auf die Protokolle zugreifen können. Leistung und Benutzerfreundlichkeit sind sekundär.

Sehen Sie sich den Plattformvergleich an, um zu verstehen, welche Plattform für jedes dieser Szenarien geeignet ist.

Migrationsgeschwindigkeit

In einigen Szenarien müssen Sie ggf. eine knappe Frist einhalten, wie z. B. wenn Ihre Organisation aufgrund eines Lizenzablaufs dringend die bisherige SIEM-Lösung wechseln muss.

Überprüfen Sie die Komponenten und Faktoren, die die Geschwindigkeit Ihrer Migration bestimmen.

Datenquellen-

Die Datenquelle ist in der Regel ein lokales Dateisystem oder ein Cloudspeicher, z. B. S3. Die Speicherleistung eines Servers hängt von mehreren Faktoren ab, wie z. B. von der Datenträgertechnologie (SSD vs HDD), der Art der IO-Anforderungen und der Größe der einzelnen Anforderungen.

Die Leistung der virtuellen Azure-Computer reicht beispielsweise von 30 MB pro Sekunde bei kleineren VM-SKUs bis zu 20 GB pro Sekunde bei einigen der speicheroptimierten SKUs mit NVM Express (NVMe)-Datenträgern. Erfahren Sie, wie Sie Ihre Azure-VM für hohe Speicherleistung konzipieren. Die meisten Konzepte können Sie auch auf lokale Server anwenden.

Computeleistung

In einigen Fällen ist die Rechenleistung, auch wenn ihre Festplatte Daten schnell kopieren kann, der Engpass im Kopiervorgang. In diesen Fällen können Sie eine der folgenden Skalierungsoptionen auswählen:

  • Nebeneinander skalieren. Sie erhöhen die Leistung eines einzelnen Servers, indem Sie weitere CPUs hinzufügen oder die CPU-Geschwindigkeit erhöhen.
  • Untereinander skalieren. Sie fügen weitere Server hinzu, sodass mehr Kopiervorgänge parallel ausgeführt werden können.

Zielplattform

Jede der in diesem Abschnitt beschriebenen Zielplattformen weist ein anderes Leistungsprofil auf.

  • Azure Monitor-Basisprotokolle. Standardmäßig können Basisprotokolle mit einer Geschwindigkeit von ca. 1 GB pro Minute an Azure Monitor übertragen werden. Mit dieser Geschwindigkeit können Sie ca. 1,5 TB pro Tag oder 43 TB pro Monat erfassen.
  • Azure Data Explorer. Die Erfassungsleistung variiert je nach Größe des von Ihnen bereitgestellten Clusters und den von Ihnen angewendeten Batcheinstellungen. Erfahren Sie mehr über bewährte Erfassungsmethoden , einschließlich Leistung und Überwachung.
  • Azure Blob Storage: Die Leistung eines Azure Blob Storage-Kontos kann je nach Anzahl und Größe der Dateien, Auftragsgröße, Parallelität etc. stark variieren. Erfahren Sie, wie Sie die Leistung von AzCopy und Azure Storage optimieren.

Datenmenge

Die Menge der Daten ist der Hauptfaktor, der sich auf die Dauer des Migrationsprozesses auswirkt. Sie sollten sich daher gut überlegen, wie Sie Ihre Umgebung je nach Datensatz einrichten.

Um die Mindestdauer der Migration zu ermitteln und wo sich der Engpässe befinden könnten, berücksichtigen Sie die Datenmenge und die Erfassungsgeschwindigkeit der Zielplattform. Beispielsweise wählen Sie eine Zielplattform aus, die 1 GB pro Sekunde erfassen kann, und Sie müssen 100 TB migrieren. In diesem Fall müssen Sie mindestens 100.000 GB migrieren, multipliziert mit der Geschwindigkeit von 1 GB pro Sekunde. Teilen Sie das Ergebnis durch 3600. Dies ergibt 27 Stunden. Diese Berechnung ist richtig, wenn die restlichen Komponenten in der Pipeline, z. B. der lokale Datenträger, das Netzwerk und die virtuellen Computer, mit einer Geschwindigkeit von 1 GB pro Sekunde ausgeführt werden können.

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie Ihre Migrationsregeln von QRadar zu Microsoft Sentinel zuordnen.

Wählen Sie ein Datenerfassungstool aus