Der Sentinel Data Lake senkt die Kosten für große Logmengen deutlich

Wer in Security-Projekten mit Microsoft Sentinel arbeitet, merkt schnell, wie teuer klassische Log-Analytics-Workspaces bei großen Logmengen werden, etwa bei Firewall- oder Proxy-Logs. Seit die neue Sentinel-Data-Lake-Funktion den GA-Status erreicht hat, lassen sich günstiger Langzeitspeicher und hohe Flexibilität endlich kombinieren, ohne dass wir auf Abfragemöglichkeiten verzichten müssen. Der Data Lake nimmt kalte, selten genutzte Daten auf, die sich trotzdem jederzeit per KQL abfragen lassen. Den vollen Analytics-Funktionsumfang bekommt man dort allerdings nicht auf Knopfdruck. Viele meiner Kunden müssen regelmäßig Compliance- und Forensik-Anforderungen erfüllen, und für sie ist das eine spürbare Erleichterung.

Der Data Lake ergänzt das Analytics Tier um eine günstige Speicherebene

Das Prinzip ist schnell erklärt. Neben dem gewohnten Analytics Tier stellt der Sentinel Data Lake eine eigene, kostengünstige Speicherebene bereit. Logs im Analytics Tier bleiben für den laufenden Security-Betrieb und für Detektionen schnell durchsuchbar. In den Data Lake wandert alles, was man selten braucht, aber lange aufheben muss, zum Beispiel Firewall-, Proxy- oder RADIUS-Logs, aber auch Sign-in-Noise aus Entra ID. Gerade bei Logs mit Aufbewahrungsfristen von Monaten oder Jahren rechnet sich das. Die Kosten sinken erheblich, und gezielte KQL-Analysen bleiben trotzdem möglich.

In der Praxis sehe ich häufig Analytics-Tier-Workspaces, die mit riesigen Mengen an Netzwerk- oder Authentifizierungsdaten gefüllt sind, obwohl diese Daten der Security im Alltag nichts bringen. Mit dem Data Lake lässt sich das sauber trennen, und Budget und Compliance passen wieder zusammen. Architektur und Abfragepfade beschreibt Microsoft sehr anschaulich in der eigenen Dokumentation.

Für den Umstieg muss der Arbeitsbereich mit dem Defender-Portal verbunden sein

Bevor ihr loslegt, müssen ein paar Voraussetzungen erfüllt sein. Der Sentinel-Arbeitsbereich muss mit dem Microsoft-Defender-Portal verbunden sein (bei den meisten Tenants ist das seit 2025 Standard, prüft es im Sentinel-Setup aber trotzdem nach). Eingerichtet wird das Ganze im Defender-Portal unter „Microsoft Sentinel → Data lake exploration → KQL queries“. Nur über diesen Weg greift ihr per KQL direkt auf den Lake zu. Wer noch mit älteren, nicht verbundenen Workspaces arbeitet, muss unter Umständen einmalig migrieren oder einen neuen Workspace als Ziel anlegen.

Welche Tabellen in die kalte Ablage wandern, entscheidet ihr granular. Typische Kandidaten sind:

• Firewall- und Proxy-Logs
• VPN- und RADIUS-Anmeldungen
• Authentifizierungs-Noise (z. B. Success-Events aus Entra ID)
• IoT- und OT-Telemetriedaten mit geringer Security-Relevanz
• Große Diagnose- und Telemetrie-Streams, die vor allem für Audits gebraucht werden

Das Verschieben in den Lake ist dabei mehr als ein reiner Retention-Vorgang, denn ihr bestimmt, ab wann und wie lange die Daten einer Tabelle im Data Lake statt im Analytics Tier liegen. Das erledigt ihr in den Retention-Einstellungen der jeweiligen Tabelle im Sentinel-Setup.

Lake-Daten lassen sich per KQL abfragen und gezielt zurückholen

Herzstück der neuen Funktion ist der direkte KQL-Zugriff auf die Lake-Daten, wenn auch mit einigen Einschränkungen. Die Abfrageumgebung findet ihr im Defender-Portal unter „Microsoft Sentinel → Data lake exploration → KQL queries“. Dort lassen sich klassische KQL-Statements ausführen, allerdings nur für Tabellen, die im Data Lake liegen.

Viele Kunden interessiert vor allem, dass sich regelmäßige, geplante KQL-Jobs definieren lassen. Sie durchsuchen den Lake nach bestimmten Mustern, etwa nach auffälligen Proxy-Zugriffen, und promoten nur die relevanten Treffer zurück ins Analytics Tier. Auf diese Weise findet man auch nachträglich Indikatoren früherer Angriffe, ohne die kompletten Rohdaten dauerhaft im teuren Analytics Tier vorzuhalten.

Das folgende KQL-Beispiel ist typisch für den Alltag. Ihr führt es im Defender-Portal unter „Microsoft Sentinel → Data lake exploration → KQL queries“ aus und braucht dafür Berechtigungen für den Sentinel-Arbeitsbereich sowie Zugriff auf die Data-Lake-Tabelle.

// Suche nach fehlgeschlagenen VPN-Logins im Data Lake der letzten 180 Tage
VPNConnectionLogs
| where Result == "Failure"
| summarize Anzahl = count() by User, bin(Timestamp, 1d)
| sort by Anzahl desc

Mein Tipp: Legt eure KQL-Jobs so an, dass sie möglichst wenige Daten zurück ins Analytics Tier promoten. Je selektiver ihr filtert, desto günstiger bleibt es auf Dauer.

Das folgende Diagramm zeigt den Abfragefluss im Überblick:

flowchart TD
    User["Defender-Portal"] --> Query["KQL-Abfrage (Data Lake)"]
    Query --> Lake["Data Lake (günstig)"]
    Lake --> Job["Geplanter KQL-Job"]
    Job --> Analytics["Analytics Tier (teuer)"]

Abbildung: KQL-Abfragefluss im Sentinel Data Lake – nur ausgewählte Daten gelangen ins Analytics Tier.

Der günstige Speicher bringt einige Einschränkungen mit sich

Das Preismodell des Sentinel Data Lake rechnet sich vor allem bei großen Mengen selten genutzter Logs. Für die kalten Daten zahlt ihr günstigen Speicher und behaltet über den KQL-Zugriff trotzdem die analytische Flexibilität. Nicht jede Abfrage läuft allerdings so schnell wie im Analytics Tier, und einige fortgeschrittene Funktionen wie Near-Real-Time-Alerts oder komplexe Analytics Rules gibt es nur für Daten im Analytics Tier. Auch die unmittelbare Integration in alle Log-Analytics-Funktionen fehlt im Data Lake, weshalb viele Security-Playbooks und Automatisierungen an die Trennung angepasst werden müssen. Hinzu kommt, dass das Zurückverschieben ins Analytics Tier Geld kostet. Schneidet eure selektiven KQL-Jobs deshalb so fein wie möglich zu.

In meinen Projekten herrscht noch viel Unsicherheit darüber, welche Datenkategorien tatsächlich in den Lake gehören. Als Faustregel gilt: Was selten gebraucht wird und weder für Detection Rules noch für Echtzeit-Dashboards relevant ist, kann in den Lake. Wer das von Anfang an sauber trennt, spart deutlich und bekommt obendrein eine spürbar bessere Governance in Sentinel. Hilfreich sind dabei die offizielle Übersicht zu KQL im Data Lake und eigene Auswertungen im Defender-Portal.

Die Trennung von Betrieb und Aufbewahrung zahlt sich schnell aus

Wer mit großen Logmengen arbeiten muss, profitiert vom Sentinel Data Lake erheblich. Operativ wichtige Daten lassen sich endlich von der Compliance-Aufbewahrung trennen, statt alles in die teure Analytics-Ebene zu kippen. Mir ist wichtig, die Abläufe rund um geplante KQL-Jobs und das gezielte Promoten von Daten früh festzulegen. Wer das Prinzip verstanden und die Datenflüsse sauber und granular geplant hat, holt den größten Effizienz- und Kostenvorteil heraus. Das gilt besonders für Tenants, in denen Compliance und Security-Budget zusammenpassen sollen. Weitere Praxistipps zum Logmanagement im Microsoft-Umfeld findet ihr in meinen Beiträgen zu Defender XDR und zu Audit und Aufbewahrung.