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 zu entscheiden, wo Ihre historischen Daten gespeichert werden sollen, müssen Sie die verschiedenen Zielplattformen verstehen und vergleichen.
In diesem Artikel werden Zielplattformen in Bezug auf Leistung, Kosten, Benutzerfreundlichkeit und Verwaltungsaufwand verglichen.
Hinweis
Die Aspekte in diesem Artikel gelten nur für die Migration historischer Protokolle. Sie gelten nicht für andere Szenarien, z. B. die langfristige Aufbewahrung von Betriebsdaten.
Empfohlener Pfad: Microsoft Sentinel Data Lake
Für die meisten neuen Migrationen empfehlen wir, Ihre historischen Daten in Microsoft Sentinel Data Lake, der systemeigenen Datenebene der Microsoft Sentinel-Plattform, zu speichern. Der Datensee gibt Ihnen:
- Kosteneffiziente langfristige Aufbewahrung: Bewahren Sie bis zu 12 Jahre Sicherheitsdaten in einem einzigen, offenen Format (Parquet) Store auf, ohne zwischen Deckung und Kosten wählen zu müssen.
- Eine einzelne Kopie deiner Daten: Die Daten in der Analyse-Stufe werden auf die See-Stufe gespiegelt, sodass du keine doppelten Kopien für Jagd und Untersuchung bezahlst.
- Integration von native Sentinel und Defender: Suchen, untersuchen und analysieren Sie historische Daten direkt aus dem Microsoft Defender-Portal – kein separater Cluster oder Proxy zum Verwalten.
- Mehrere Analyse-Engines: Verwenden Sie KQL für Ad-hoc-Abfragen und Jupyter-Notebooks mit Python- und Machine-Learning-Bibliotheken für tiefere Analysen, Forensik und Anomalieerkennung.
- Ein vollständig verwalteter Dienst: Sie bereiten keine Infrastrukturen ein, skalieren oder patchen.
Wählen Sie Microsoft Sentinel Data Lake aus, wenn Sie den einfachsten Pfad zu einem einheitlichen, abfragbaren Verlauf Ihrer Sicherheitsdaten innerhalb Microsoft Sentinel möchten.
Weitere Informationen finden Sie unter Was ist Microsoft Sentinel Data Lake? und Onboard to Microsoft Sentinel Data Lake.
Alternative Zielplattformen
Microsoft Sentinel Data Lake ist das empfohlene Ziel für die meisten Kunden, andere Plattformen gelten jedoch für bestimmte Szenarien. Verwenden Sie den Vergleich in diesem Abschnitt, wenn Sie über eine vorhandene Investition in Azure Data Explorer (ADX) oder Azure Blob Storage verfügen oder wenn ein bestimmtes Szenario noch nicht vom Datensee abgedeckt ist.
| Microsoft Sentinel Data Lake | Azure Data Explorer (ADX) | Azure Blob Storage | |
|---|---|---|---|
| Funktionen: | - Speziell entwickelter Sicherheitsdatenspeicher, integriert mit Microsoft Sentinel und dem Defender-Portal. - Einzelne Kopie der Daten in den Analytics- und Lake-Tiers. - Bis zu 12 Jahre Betreuung im offenen Parquet-Format. - Abfrage mit KQL- und Jupyter-Notebooks (Python + Machine Learning Libraries). - Daten auf Abruf zurück in die Analytics-Stufe bringen, wenn vollständige SIEM-Fähigkeiten benötigt werden. |
- ADX und Microsoft Sentinel verwenden beide die Kusto Query Language (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 Größe und Konfiguration des Clusters. Sie können beispielsweise einen größeren Cluster erstellen, um einen höheren Aufnahmedurchsatz zu erzielen, oder einen kleineren Cluster, um Ihre Kosten zu steuern. |
- Blob-Speicher ist für die Speicherung riesiger Mengen unstrukturierter Daten optimiert. - Bietet wettbewerbsfähige Kosten. - Geeignet, wenn Ihre Organisation Zugänglichkeit oder Leistung nicht priorisiert, etwa wenn Sie Compliance- oder Auditanforderungen erfüllen müssen. |
| Nutzbarkeit: |
Wunderbar Fragen Sie historische Daten direkt im Microsoft Defender-Portal ab und untersuchen Sie sie – mit derselben KQL-Oberfläche, die Sie bereits für Sentinel verwenden. Notizbücher bieten eine vertraute Schnittstelle für die erweiterte Analyse. |
Gut Recht einfach im Kontext von Microsoft Sentinel zu verwenden. Sie können beispielsweise eine Azure-Arbeitsmappe verwenden, um die Datenverteilung über Microsoft Sentinel und ADX hinweg zu visualisieren. Sie können ADX-Daten auch über das Microsoft Sentinel-Portal mithilfe des ADX-Proxys abfragen. |
Schlecht 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. |
| Verwaltungsaufwand: |
Vollständig verwaltet Microsoft verwaltet die Data Lake-Infrastruktur, skalierung und Patching. Sie führen keinen Cluster aus oder verwalten Speicherkonten. |
Hoch ADX ist außerhalb von Microsoft Sentinel und erfordert Überwachung und Wartung. |
Niedrig Die Plattform selbst erfordert wenig Wartung, aber Sie müssen weiterhin Überwachungs- und Konfigurationsaufgaben einrichten, z. B. die Lebenszyklusverwaltung. |
| Leistung: |
Hoch Der Data Lake trennt den Speicher von der Berechnung und unterstützt mehrere Analysemodule, sodass Sie Abfrageworkloads unabhängig von der Erfassung skalieren können. Stufen Sie Daten auf die Analysestufe hoch, wenn Sie interaktive SIEM-Performance benötigen. |
Hoch bis niedrig - Die ADX-Abfrageleistung hängt von der Anzahl der Knoten im Cluster, der SKU der Cluster-virtuellen Maschine, Datenpartitionierung und mehr ab. - Wenn du Knoten zum Cluster hinzufügst, verbessert sich die Leistung mit zusätzlichen Kosten. - Wenn Sie ADX verwenden, empfehlen wir, Ihren Cluster so zu dimensionieren, dass Leistung und Kosten entsprechend den Bedürfnissen Ihrer Organisation ausbalanciert werden, einschließlich der Geschwindigkeit Ihrer Migration, wie oft die Daten abgerufen werden und die erwartete Antwortzeit. |
Niedrig Bietet zwei Leistungsstufen: Premium oder Standard. Beide sind eine Option für die langfristige Speicherung, aber Standard ist kostengünstiger. Erfahren Sie mehr über Leistungs- und Skalierbarkeitsgrenzwerte. |
| Kosten: |
Niedrig bis mittel Zahlen Sie für Speicher auf der Lake-Ebene sowie für On-Demand-Compute für KQL-Aufträge und Notebooks. Das Einzelkopiemodell vermeidet doppelte Speichergebühren in Sentinel und am See. Ausführliche Informationen finden Sie unter Abrechnung für den Microsoft Sentinel Data Lake. |
Hoch bis niedrig - ADX ist ein Cluster von virtuellen Maschinen, sodass Sie basierend auf Rechen-, Speicher- und Netzwerknutzung sowie einem ADX-Aufschlag berechnet werden (siehe Preisdetails). Je mehr Knoten Sie hinzufügen und je mehr Daten Sie speichern, desto höher sind die Kosten. - ADX bietet außerdem Autoskalierung, um sich an die Nachfrage anzupassen und profitiert von der Preisgestaltung von reservierten Instanzen. Sie können ihre eigenen Kostenberechnungen im Azure Preisrechner ausführen. |
Niedrig Bei optimaler Einrichtung hat Azure Blob Storage die geringsten Kosten. Verwenden Sie für eine höhere Effizienz und Kosteneinsparungen Azure Storage Lebenszyklusverwaltung, um ältere Blobs automatisch in günstigere Speicherebenen zu verschieben. |
| Zugreifen auf Daten: | KQL-Abfragen und Jupyter Notebooks aus dem Microsoft Defender-Portal; stufen Sie Daten bei Bedarf wieder auf die Analyseebene hoch. | Direkte KQL-Abfragen | KQL externaldata-Operator |
| Szenario: |
Empfohlene Standardeinstellung Wird für die meisten neuen Migrationen verwendet, wenn Sie eine langfristige Aufbewahrung, integrierte Untersuchung und erweiterte Analysen innerhalb Microsoft Sentinel möchten, ohne Infrastruktur zu verwalten. |
Häufiger Zugriff Relevant, wenn Sie häufig auf die Daten zugreifen müssen und steuern müssen, wie der Cluster angepasst und konfiguriert wird. |
Compliance/Überwachung - Optimal zur Speicherung riesiger Mengen unstrukturierter Daten. - Relevant, wenn Sie keinen schnellen Zugriff auf die Daten oder hohe Leistung benötigen, beispielsweise für Compliance- oder Auditzwecke. |
| Komplexität: | Niedrig | Mittel | Niedrig |
Allgemeine Überlegungen
Nachdem Sie den Plattformvergleich überprüft haben, verwenden Sie die folgenden Faktoren, 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?
Überlegen Sie, wie Ihre Organisation aufgenommene Protokolle verwenden wird
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 Ihre Organisation selten auf die Daten zu. Auch wenn Ihre Organisation auf die Daten zugreift, sind hohe Leistung und Benutzerfreundlichkeit keine Priorität.
- Ihre Organisation muss die Protokolle aufbewahren, damit Ihre Teams auf sie problemlos und relativ schnell zugreifen können.
- Ihre Organisation muss die Protokolle aufbewahren, damit Ihre Teams gelegentlich darauf zugreifen können. Leistung und Benutzerfreundlichkeit sind sekundär.
In den meisten Compliance-, Häufigzugriffs- und gelegentlichen Zugriffsszenarien ist der Microsoft Sentinel Data Lake das empfohlene Ziel. Überprüfen Sie die Vergleichstabelle der alternativen Zielplattformen , wenn eine der alternativen Plattformen eine bestehende Investition oder eine spezialisierte Anforderung erfüllt.
Bewerten Sie Faktoren, die die Migrationsgeschwindigkeit beeinflussen
In einigen Szenarien müssen Sie einen engen Stichtag einhalten. Ihre Organisation muss z. B. aufgrund eines Lizenzablaufereignisses dringend von einem früheren SIEM wechseln.
Überprüfen Sie die Komponenten und Faktoren, die die Migrationsgeschwindigkeit bestimmen: Datenquelle, Computeleistung und Zielplattform.
Wie die Datenquelle die Migrationsgeschwindigkeit beeinflusst
Die Datenquelle ist in der Regel ein lokales Dateisystem oder Cloudspeicher, z. B. Amazon S3. Die Speicherleistung eines Servers hängt von mehreren Faktoren ab, einschließlich Datenträgertechnologie (SSD und HDD), der Art der E/A-Anforderungen und der Größe jeder Anforderung.
Beispielsweise reicht die Leistung virtueller Computer in Azure von 30 MB pro Sekunde bei kleineren VM-SKUs bis zu 20 GB pro Sekunde bei einigen 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 dieser Azure-VM-Speicherperformance-Designkonzepte auch auf On-Premises-Server anwenden.
Wie die Rechenkapazität die Migrationsgeschwindigkeit beeinflusst
In einigen Fällen ist die Rechenleistung, auch wenn ihre Festplatte Daten schnell kopieren kann, der Engpass im Kopiervorgang. Wenn die Rechenleistung der Engpass ist, können Sie eine der folgenden Skalierungsoptionen auswählen:
- Vertikale Skalierung: Erhöhen Sie die Leistung eines einzelnen Servers, indem Sie mehr CPUs hinzufügen oder die CPU-Geschwindigkeit erhöhen.
- Horizontal skalieren" Fügen Sie mehr Server hinzu, was die Parallelität des Kopierprozesses erhöht.
Wie die Zielplattform die Migrationsgeschwindigkeit beeinflusst
Microsoft Sentinel Data Lake, Azure Data Explorer und Azure Blob Storage haben jeweils ein anderes Leistungsprofil.
- Microsoft Sentinel Data Lake: Der Data Lake ist für die Hochdurchsatzerfassung großer Mengen an Sicherheitsdaten konzipiert. Da Speicher und Compute voneinander getrennt sind, wird die Erfassung unabhängig von Abfrageworkloads skaliert. Informationen zu Dienstgrenzwerten finden Sie unter Microsoft Sentinel Data Lake Service Limits.
- Azure Data Explorer: Die Aufnahmeleistung variiert je nach Größe des bereitgestellten Clusters und den Batching-Einstellungen, die du anwendest. 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 stark variieren, abhängig von Anzahl und Größe der Dateien, Jobgröße, Nebenläufigkeit und weiteren Faktoren. Erfahren Sie, wie Sie die Leistung von AzCopy mit Azure Storage optimieren.
Bewerten Sie, wie das Datenvolumen die Migrationsplanung beeinflusst
Die Datenmenge ist der Hauptfaktor, der sich auf die Dauer des Migrationsprozesses auswirkt. Sie sollten daher überlegen, wie Sie Ihre Umgebung basierend auf 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. Wenn Sie beispielsweise eine Zielplattform auswählen, die 1 GB pro Sekunde aufnehmen kann und Sie 100 TB migrieren müssen, dauert ihre Migration mindestens 100.000 GB dividiert durch 1 GB pro Sekunde. Dividieren Sie das Ergebnis durch 3.600, und die Migration dauert mindestens 27 Stunden. Die Schätzung der Mindestdauer von 27 Stunden ist nur dann korrekt, wenn die übrigen Komponenten in der Pipeline – wie die lokale Festplatte, das Netzwerk und die virtuellen Maschinen – mit einer Geschwindigkeit von 1 GB pro Sekunde arbeiten können.