Splunk → Microsoft Sentinel

Der Business Case, Splunk zugunsten von Microsoft Sentinel zu verlassen, schreibt sich meist von selbst: Die Splunk-Lizenz ist eine grosse, sichtbare Jahreszahl, Sentinel steckt ohnehin in einem E5-Vertrag, den jemand anderes verhandelt hat, und das Security-Team hätte lieber eine Microsoft-Konsole als zwei Anbieter. Der Plan, der daraus folgt, ist fast immer derselbe: Forwarder umbiegen, Suchen übersetzen, Indexer abbauen.

Dieser Plan verschiebt Komplexität. Er reduziert sie nicht, und er senkt häufig auch die Kosten nicht — denn beide Produkte rechnen nach dem Volumen ab, das Sie ihnen schicken. Ein Lift-and-Shift von 900 GB/Tag nach Sentinel sind 900 GB/Tag Sentinel-Ingest. Der Anbieter hat gewechselt; die Ökonomie nicht.

Dieser Beitrag behandelt, was sich zwischen den beiden Plattformen wirklich unterscheidet, was ein Forwarder-Lift-and-Shift tatsächlich kostet und wo eine Telemetrie-Pipeline die Antwort verändert.

Die drei Dinge, die wirklich anders sind

Jenseits der Konsole treiben drei Unterschiede die eigentliche Arbeit:

• Die Abfragesprache. SPL und KQL sind keine Dialekte voneinander. Jede gespeicherte Suche, jede Korrelationsregel, jedes Dashboard-Panel ist eine Neufassung — unterstützt von Übersetzungswerkzeugen, aber geprüft von einem Menschen, der versteht, was die Detection eigentlich fangen sollte. Kalkulieren Sie das als grössten Posten: Es ist Engineering-Zeit, keine Infrastruktur.
• Das Ingestion-Modell. Splunk nimmt fast alles an und ermittelt das Schema zur Suchzeit. Sentinel sitzt auf Log Analytics, das Tabellen, ein deklariertes Schema und eine Data Collection Rule mit der Transformation erwartet. Aus Schema-on-Read wird Schema-on-Write — mehr Vorarbeit und weniger Toleranz für unordentliche Quellen.
• Die Tiers. Sentinel trennt die Aufnahme in analysefähige Tabellen und günstigere Stufen mit eingeschränkter Abfragefähigkeit und anderem Aufbewahrungsverhalten. Diese Stufung ist der wichtigste Kostenhebel der Plattform — und sie funktioniert nur, wenn etwas pro Datensatz entscheidet, in welche Stufe ein Log gehört.

Genau an diesem letzten Punkt scheitern die meisten Migrationen still. Die Stufung ist real und sie spart Geld, aber nichts in Splunks Forwarder-Topologie weiss, wie man diese Entscheidung trifft — also landet standardmässig alles in der teuren Stufe.

Was ein Forwarder-Lift-and-Shift tatsächlich kostet

Splunks Erfassungsschicht sind Universal und Heavy Forwarder, die an Indexer liefern. Das naive Sentinel-Äquivalent ist der Azure Monitor Agent auf jedem Host mit Data Collection Rules, oder ein Syslog-/CEF-Forwarder für Netzwerkgeräte. Das funktioniert. Es erbt auch jede Eigenschaft des alten Aufbaus, dem Sie vermutlich entkommen wollten:

• Das Volumen bleibt unverändert, die Pro-GB-Rechnung wandert also einfach zu einem neuen Anbieter. War Splunk wegen dessen teuer, was Sie hineingeschickt haben, wird Sentinel aus demselben Grund teuer.
• Der Agent ist wieder herstellerspezifisch. Sie haben einen Splunk-Forwarder gegen einen Microsoft-Agenten getauscht. Die nächste Migration — und es wird eine geben — ist dasselbe Projekt von vorn, weil die Erfassungsschicht weiterhin dem gehört, dem das Backend gehört.
• Die unordentlichen Quellen bleiben unordentlich. Mehrzeilige Stack Traces, inkonsistente Zeitstempel und Freitext-Logs, die Splunk zur Suchzeit tolerierte, müssen nun beim Eintritt geparst werden — sonst werden sie zu nicht abfragbaren Textspalten.
• Pro Datensatz wird nichts günstiger. Debug-Logs, Health-Check-Geplauder und ausschweifende Access-Logs werden weiterhin vollständig geschickt, indexiert und abgerechnet.

Wo die Pipeline-Schicht die Antwort verändert

Die Alternative ist, eine Erfassungsschicht, die Ihnen gehört, zwischen die Quellen und Sentinel zu setzen. Konkret: ein OpenTelemetry Collector auf jedem Host (oder eine Gateway-Ebene für Netzwerkquellen) und eine Pipeline, die vier Dinge tut, bevor irgendetwas abgerechnet wird:

• Filtern. Verwerfen, was nie jemand abfragen wird. Health-Checks, erfolgreiche Liveness-Probes, Debug-Geplauder eines Dienstes im Normalbetrieb. Das ist der mit Abstand grösste Hebel und alles andere als subtil — siehe Observability-Kosten senken.
• Parsen. Mehrzeilige Ereignisse zu einzelnen Datensätzen falten und die wenigen Felder extrahieren, die ein Log abfragbar machen, sodass Sentinel Struktur statt eines Textklumpens erhält — unordentliche Logs onboarden.
• Nach Wert routen. Sicherheitsrelevante Datensätze in die Analytics-Stufe; volumenstarke Betriebslogs in ein günstiges Archiv oder gleich in ein anderes Backend. Das ist die Entscheidung, die das Stufenmodell braucht und nicht für Sie treffen kann — Route Telemetry by Attribute (englisch).
• Maskieren. Credentials, Tokens und Personendaten entfernen, bevor der Datensatz Ihr Netzwerk verlässt, statt einer nachgelagerten Maskierungsregel zu vertrauen — PII in Logs maskieren.

Das Ergebnis: Die Migration wird zu einer echten Reduktion statt zu einem Adresswechsel, und die Erfassungsschicht ist nicht mehr an das Backend gebunden — was die nächste Backend-Entscheidung günstig macht.

Die Connector-Lücke ehrlich benennen

Ein Punkt, den Sie einplanen sollten: OpenTelemetry hat keinen erstklassigen, offiziell unterstützten Sentinel-Exporter, wie es ihn für OTLP-Backends gibt. Datensätze in eine Log-Analytics-Tabelle zu bekommen bedeutet in der Regel die Logs Ingestion API gegen eine Data Collection Rule — oder den Microsoft-Agenten als letzten Hop zu behalten, während der Collector die Reduktion davor erledigt.

Das ist ein realer Integrationsaufwand und er gehört in den Plan. Am Argument ändert er nichts — die Reduktion passiert so oder so vor diesem Hop, und dort liegt das Geld —, aber ein Entwurf, der einen sauberen OTLP-Pfad nach Sentinel annimmt, läuft in Woche drei gegen eine Wand. Prüfen Sie die aktuelle Exporter- und API-Lage bei der Aufwandsschätzung in Microsofts Dokumentation, nicht in einem Blogbeitrag.

Eine Migrationsreihenfolge, die funktioniert

1. Zuerst messen. Volumen pro Quelle, pro Tag. Fast jeder Bestand stellt fest, dass eine Handvoll Quellen den Grossteil der Bytes erzeugt — und dass einige davon praktisch nie abgefragt werden: echten Durchsatz sehen.
2. Collectors in den Pfad setzen, solange Splunk noch läuft. Einmal erfassen, an beide exportieren — Dual-Shipping ohne Duplikate. Betreiben Sie nicht zwei Erfassungs-Agents auf demselben Host für dieselbe Datei; so entstehen doppelt gezählte Hosts und duplizierte Log-Zeilen.
3. Volumen senken, bevor Sie umschalten. Filtern, samplen und routen, während das alte Backend noch läuft, sodass Sie beide vergleichen und belegen können, dass nichts verschwunden ist, worauf Sie sich verlassen.
4. Detections gegen den reduzierten Stream übersetzen, nicht gegen den alten. Eine SPL-Regel neu zu fassen, die von einem Feld abhängt, das Sie gleich verwerfen, ist vergeudete Arbeit.
5. Dann abbauen, Quelle für Quelle, während die Erfassungsschicht bestehen bleibt.

Die Reihenfolge zählt: Reduzieren Sie, solange Sie beide Seiten sehen. Ein Cutover mit anschliessender Reduktion sind zwei riskante Projekte; eine Reduktion mit anschliessendem Cutover ist eines.

Der ehrliche Kompromiss

Sie fügen eine Komponente hinzu. Die Collector-Flotte ist Infrastruktur, die betrieben, konfiguriert und aktuell gehalten werden will — und falsch konfiguriert kann sie Daten verwerfen, die Sie gebraucht hätten. Genau deshalb wollen die Filterregeln vor dem flottenweiten Ausrollen an echten erfassten Datensätzen in der Vorschau geprüft werden, nicht danach.

Dafür bekommen Sie das, was eine reine Backend-Migration nie liefert: Die Volumenentscheidung, die Redaction-Entscheidung und die Routing-Entscheidung wandern in eine Schicht, die Ihnen gehört — und bleiben dort, wenn das Backend erneut wechselt.