Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 Verlaufsprotokollmigration und nicht für andere Szenarien, z. B. die langfristige Aufbewahrung.
| Basisprotokolle/Archiv | Azure Data Explorer (ADX) | Azure Blob Storage | ADX + Azure Blob Storage | |
|---|---|---|---|---|
| Funktionen: | • Wenden Sie die meisten vorhandenen Azure Monitor-Protokolle zu geringeren Kosten an. • Basisprotokolle werden acht Tage lang aufbewahrt und dann automatisch in das Archiv übertragen (gemäß dem ursprünglichen Aufbewahrungszeitraum). • Verwenden Sie Suchaufträge , um Daten in Petabytes zu durchsuchen und bestimmte Ereignisse zu finden. • Für eingehende Untersuchungen zu einem bestimmten Zeitbereich können Daten aus dem Archiv wiederhergestellt werden. Die Daten stehen dann im 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. Sie können beispielsweise eine KQL-Abfrage aus Microsoft Sentinel ausführen, um in ADX gespeicherte Daten mit in Log Analytics gespeicherten Daten zu verbinden. • Mit ADX haben Sie erhebliche 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 Ihr organization nicht die Barrierefreiheit oder Leistung priorisiert, z. B. wenn die organization den Compliance- oder Überwachungsanforderungen entsprechen muss. |
• Daten werden in einem Blobspeicher gespeichert, der kostengünstig ist. • Sie verwenden ADX, um die Daten in KQL abzufragen, sodass Sie problemlos auf die Daten zugreifen können. Erfahren Sie, wie Sie Azure Monitor-Daten mit ADX abfragen. |
| Nutzbarkeit: |
Wunderbar Die Archiv- 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 durchführen, um die Daten abzurufen. Dies kann je nach Der Menge der gescannten und zurückgegebenen Daten einige Zeit dauern. |
Gut Recht einfach im Kontext von Microsoft Sentinel zu verwenden. Beispielsweise können Sie eine Azure Arbeitsmappe verwenden, um Daten zu visualisieren, die auf Microsoft Sentinel und ADX verteilt sind. Sie können ADX-Daten auch über das Microsoft Sentinel-Portal mithilfe des ADX-Proxys abfragen. |
Arm Bei Migrationen von Historischen Daten müssen Sie möglicherweise mit Millionen von Dateien fertig werden, und das Untersuchen der Daten wird zu einer Herausforderung. |
Gerecht Während die Verwendung des externaldata Operators bei einer großen Anzahl von Blobs, auf die verwiesen werden muss, sehr schwierig ist, beseitigt die Verwendung externer ADX-Tabellen dieses Problem. Die Definition der externen Tabelle kennt die Struktur des Blobspeicherordners und ermöglicht es Ihnen, die Daten in vielen verschiedenen Blobs und Ordnern transparent abzufragen. |
| Verwaltungsaufwand: |
Vollständig verwaltet Die Such- und Archivoptionen sind vollständig verwaltet und verursachen keinen Verwaltungsaufwand. |
High ADX ist für Microsoft Sentinel extern, was eine Überwachung und Wartung erfordert. |
Niedrig Diese Plattform erfordert zwar wenig Wartung, aber durch die Auswahl dieser Plattform werden Überwachungs- und Konfigurationsaufgaben hinzugefügt, z. B. das Einrichten der Lebenszyklusverwaltung. |
Medium Mit dieser Option verwalten und überwachen Sie ADX und Azure Blob Storage, die beide externe Komponenten für Microsoft Sentinel sind. Obwohl ADX manchmal heruntergefahren werden kann, berücksichtigen Sie den zusätzlichen Verwaltungsaufwand bei dieser Option. |
| Leistung: |
Medium In der Regel interagieren Sie mit grundlegenden Protokollen innerhalb des Archivs mithilfe von Suchaufträgen, die geeignet sind, wenn Sie den Zugriff auf die Daten beibehalten möchten, aber keinen sofortigen Zugriff auf die Daten benötigen. |
Hoch bis niedrig • Die Abfrageleistung eines ADX-Clusters hängt von der Anzahl der Knoten im Cluster, der SKU des virtuellen Clusters, der Datenpartitionierung und mehr ab. • Wenn Sie dem Cluster Knoten hinzufügen, verbessert sich die Leistung mit zusätzlichen Kosten. • Wenn Sie ADX verwenden, empfiehlt es sich, die Clustergröße so zu konfigurieren, dass Leistung und Kosten ausgeglichen werden. Diese Konfiguration hängt von den Anforderungen Ihrer organization ab, z. B. wie schnell Die Migration abgeschlossen werden muss, wie oft auf die Daten zugegriffen wird und wie lange die antwortet. |
Niedrig Bietet zwei Leistungsstufen: Premium oder Standard. Obwohl beide Ebenen eine Option für die langfristige Speicherung sind, ist Standard kosteneffizienter. Erfahren Sie mehr über Leistungs- und Skalierbarkeitsgrenzwerte. |
Niedrig Da sich die Daten im Blob Storage befinden, wird die Leistung durch diese Plattform eingeschränkt. |
| Kosten: |
High Die Kosten bestehen aus zwei Komponenten: • Erfassungskosten. Jedes GB von Daten, die in Standardprotokollen erfasst werden, unterliegt Microsoft Sentinel und Azure Erfassungskosten für Überwachungsprotokolle, die sich auf ungefähr 1 USD/GB be summieren. Weitere Informationen finden Sie in den Preisdetails. • Archivierungskosten. Die Kosten für Daten auf der Archivebene summieren sich auf ungefähr 0,02 USD/GB pro Monat. Weitere Informationen finden Sie in den Preisdetails. Wenn Sie zusätzlich zu diesen beiden Kostenkomponenten häufigen Zugriff auf die Daten benötigen, fallen zusätzliche Kosten an, wenn Sie über Suchaufträge auf Daten zugreifen. |
Hoch bis niedrig • Da ADX ein Cluster von virtuellen Computern ist, werden Ihnen die Kosten basierend auf der Compute-, Speicher- und Netzwerknutzung sowie einem ADX-Markup berechnet (siehe Preisdetails). Je mehr Knoten Sie Ihrem Cluster hinzufügen und je mehr Daten Sie speichern, desto höher sind die Kosten. • ADX bietet auch Funktionen für die automatische Skalierung, um sich bedarfsgesteuert an die Workload anzupassen. ADX kann auch von den Preisen für reservierte Instanzen profitieren. Sie können ihre eigenen Kostenberechnungen im Azure Preisrechner ausführen. |
Niedrig Bei optimaler Einrichtung hat Azure Blob Storage die geringsten Kosten. Um mehr Effizienz und Kosten zu sparen, kann Azure Storage Lifecycle Management verwendet werden, um ältere Blobs automatisch in kostengünstigeren Speicherebenen zu 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 sie nur dann starten, wenn der Datenzugriff erforderlich ist. |
| Zugreifen auf Daten: | Aufträge suchen | Direkte KQL-Abfragen | KQL externaldata-Operator | Geänderte KQL-Abfragen |
| Szenario: |
Gelegentlicher Zugriff Relevant in Szenarien, in denen Sie keine umfangreichen Analysen ausführen oder Analyseregeln auslösen müssen und nur gelegentlich auf die Daten zugreifen müssen. |
Häufiger Zugriff Relevant in Szenarien, in denen Sie häufig auf die Daten zugreifen und steuern müssen, wie der Cluster dimensioniert und konfiguriert wird. |
Compliance/Überwachung • Optimal für die Speicherung großer Mengen unstrukturierter Daten. • Relevant in Szenarien, in denen Sie keinen schnellen Zugriff auf die Daten oder hohe Leistung benötigen, z. B. für Compliance- oder Überwachungszwecke. |
Gelegentlicher Zugriff Relevant in Szenarien, in denen Sie von den niedrigen Kosten für Azure Blob Storage profitieren und relativ schnellen Zugriff auf die Daten erhalten möchten. |
| Komplexität: | Sehr niedrig | Medium | Niedrig | Hoch |
| Bereitschaft: | Allgemein verfügbar | Allgemein verfügbar | Allgemein verfügbar | Allgemein verfügbar |
Allgemeine Überlegungen
Nachdem Sie nun mehr über die verfügbaren Zielplattformen erfahren haben, überprüfen Sie diese Hauptfaktoren, um Ihre Entscheidung abzuschließen.
- Wie verwendet Ihr organization die erfassten Protokolle?
- Wie schnell muss die Migration ausgeführt werden?
- Wie hoch ist die zu erfassende Datenmenge?
- Was sind die geschätzten Migrationskosten während und nach der Migration? Sehen Sie sich den Plattformvergleich an, um die Kosten zu vergleichen.
Verwendung von erfassten Protokollen
Definieren Sie, wie Ihre organization die erfassten Protokolle verwenden, um Ihre Auswahl der Erfassungsplattform zu steuern.
Betrachten Sie diese drei allgemeinen Szenarien:
- Ihre organization muss die Protokolle nur zu Compliance- oder Überwachungszwecken speichern. In diesem Fall greift Ihr organization selten auf die Daten zu. Auch wenn Ihr organization auf die Daten zugreift, sind hohe Leistung oder Benutzerfreundlichkeit keine Priorität.
- Ihre organization muss die Protokolle aufbewahren, damit Ihre Teams problemlos und relativ schnell auf die Protokolle zugreifen können.
- Ihre organization 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 möglicherweise eine enge Frist einhalten, z. B. müssen Ihre organization aufgrund eines Lizenzablaufereignisses dringend vom vorherigen SIEM wechseln.
Überprüfen Sie die Komponenten und Faktoren, die die Geschwindigkeit Ihrer Migration bestimmen.
Datenquelle
Die Datenquelle ist in der Regel ein lokales Dateisystem oder Cloudspeicher, z. B. S3. Die Speicherleistung eines Servers hängt von mehreren Faktoren ab, z. B. der Datenträgertechnologie (SSD im Vergleich zu HDD), der Art der E/A-Anforderungen und der Größe jeder Anforderung.
Die Leistung Azure virtuellen Computers reicht beispielsweise von 30 MB pro Sekunde auf kleineren VM-SKUs bis zu 20 GB pro Sekunde für einige der speicheroptimierten SKUs, die NVM Express-Datenträger (NVMe) verwenden. Erfahren Sie, wie Sie Ihre Azure VM für eine hohe Speicherleistung entwerfen. Sie können die meisten Konzepte auch auf lokale Server anwenden.
Computeleistung
In einigen Fällen ist die Computeleistung der Engpass im Kopiervorgang, selbst wenn Ihr Datenträger in der Lage ist, Ihre Daten schnell zu kopieren. In diesen Fällen können Sie eine der folgenden Skalierungsoptionen auswählen:
- Vertikal skalieren. Sie erhöhen die Leistung eines einzelnen Servers, indem Sie weitere CPUs hinzufügen oder die CPU-Geschwindigkeit erhöhen.
- Horizontales Skalieren. Sie fügen weitere Server hinzu, wodurch die Parallelität des Kopiervorgangs erhöht wird.
Zielplattform
Jede der in diesem Abschnitt erläuterten Zielplattformen verfügt über ein anderes Leistungsprofil.
- Azure Monitor Basic-Protokolle. Standardmäßig können Standardprotokolle mit einer Rate von ca. 1 GB pro Minute an Azure Monitor gepusht werden. Mit dieser Rate können Sie ungefähr 1,5 TB pro Tag oder 43 TB pro Monat erfassen.
- Azure Data Explorer. Die Erfassungsleistung hängt von der Größe des bereitgestellten Clusters und den von Ihnen angewendeten Batchverarbeitungseinstellungen ab. Erfahren Sie mehr über bewährte Methoden für die Erfassung, 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 usw. stark variieren. Erfahren Sie, wie Sie die Leistung von AzCopy mit Azure Storage optimieren.
Datenmenge
Die Datenmenge ist der Hauptfaktor, der sich auf die Dauer des Migrationsprozesses auswirkt. Sie sollten daher überlegen, wie Sie Ihre Umgebung abhängig von Ihrem Dataset einrichten.
Um die Mindestdauer der Migration zu bestimmen und zu ermitteln, wo der Engpass liegen könnte, berücksichtigen Sie die Menge der Daten und die Erfassungsgeschwindigkeit der Zielplattform. Sie wählen beispielsweise eine Zielplattform aus, die 1 GB pro Sekunde erfassen kann, und Sie müssen 100 TB migrieren. In diesem Fall dauert die Migration mindestens 100.000 GB, multipliziert mit der Geschwindigkeit von 1 GB pro Sekunde. Dividieren Sie das Ergebnis durch 3600, was zu 27 Stunden berechnet wird. 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.