Sentinel Data Lake: Was es ist, wann es sich lohnt und wie du startest
Der Microsoft Sentinel Data Lake erweitert Microsoft Sentinel um günstige, skalierbare Langzeitspeicherung für Security-Logs – ohne die schnelle Erkennung im Analytics Tier auszubremsen.
- Skalierung: große Log-Volumen lassen sich langfristig speichern und für Forensik/Threat Hunting nutzen.
- Kosten: Trennung aus Analytics Tier (schnell) und Lake Tier (günstig) reduziert teure „Alles-im-Workspace“-Retention.
- Governance: Zugriff wird über RBAC (Entra-basiert/Unified RBAC) kontrolliert, damit nicht jeder alles sehen kann.
Der praktische Nutzen: weniger Geld für selten genutzte historische Logs und gleichzeitig bessere Nachvollziehbarkeit bei Incidents und Audit-Anfragen.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
Microsoft Sentinel Data Lake ist ein cloud-nativer Security Data Lake für Microsoft Sentinel, der Sicherheitsdaten langfristig speichert und für Analytics, Threat Hunting und Forensik nutzbar macht.
Er ist kein Ersatz für ein SIEM und kein allgemeines Unternehmens-Data-Lake-Projekt, sondern eine Sentinel-nahe Speicher- und Analyseerweiterung für Security-Logs.
Einleitung
Wenn du heute mehr Logs sammelst als früher, passiert meist das Gleiche: Entweder die Retention im Log Analytics Workspace bleibt kurz, oder die Kosten steigen. Genau hier setzt der Sentinel Data Lake an. Du hältst aktuelle Daten weiter schnell im Analytics Tier für Detection und Reaktion, und verschiebst historische Daten ins günstigere Lake Tier. Ergebnis: bessere Rückverfolgbarkeit bei Incidents und weniger Budgetdruck durch Langzeitspeicherung.
Wann Sentinel Data Lake sinnvoll ist
Sentinel Data Lake lohnt sich besonders, wenn Retention und Datenvolumen zu deinem Engpass werden und du trotzdem „zurückschauen“ können musst.
- Compliance/Nachweis: Audit Logs und Sicherheitsereignisse müssen länger aufbewahrt und auswertbar bleiben (z. B. für NIS2, ISO 27001, DORA).
- Forensik: bei einem Incident brauchst du Kontext aus Wochen/Monaten, nicht nur aus der Standard-Retention.
- Kostensteuerung: du willst die teure Speicherung und Abfrage im Analytics Tier auf das reduzieren, was operativ wirklich gebraucht wird.
Daten-Tiers, Retention und Lifecycle: die Kernlogik
Die wichtigste Entscheidung ist nicht „mehr Logs“, sondern „welche Logs wie lange wo“.
Im Analytics Tier liegen Daten für schnelle Abfragen, Analytics Rules und operative Detection. Im Lake Tier liegen Daten für Long-term retention und spätere Analysen, oft mit selteneren Queries. Ein Lifecycle-Modell definiert: Welche Tabellen bleiben wie lange im Analytics Tier, wann werden sie in den Lake verschoben und wie lange bleiben sie dort.
Praktischer Mehrwert: Du hältst Detection-Performance stabil, verlierst aber nicht die historischen Spuren für Threat Hunting und Incident-Aufklärung.
Prerequisites und Anforderungen (damit das Setup nicht scheitert)
Sentinel Data Lake ist kein reines „Klick-und-fertig“-Feature, wenn Rollen, Regionen oder Workspaces nicht passen.
- Azure-Grundlage: passende Subscription/Resource Group und eine unterstützte Region für die Bereitstellung.
- Rechte/RBAC: Security- und Azure-Rollen für Setup, Billing und späteren Zugriff (Least Privilege, getrennt nach Admin vs. Analyst).
- Datenquellen: funktionierende Data Connectors und saubere Tabellenstrategie im Microsoft Sentinel Workspace (sonst füllst du den Lake mit unbrauchbarem Rauschen).
Setup/Onboarding: Schritt für Schritt
Ein pragmatischer Start reduziert Risiko und macht Kosten schnell messbar.
1) Scope festlegen
Definiere zuerst 3 Dinge: welche Log-Quellen rein sollen (z. B. Microsoft Defender XDR, Entra ID Sign-ins, Azure Activity), welche Tabellen operativ im Analytics Tier bleiben, und welche Retention du wirklich brauchst.
2) Data Lake im Defender-Portal aktivieren
Aktiviere den Sentinel Data Lake im Defender portal und verknüpfe ihn mit den relevanten Sentinel-Workspaces. Achte darauf, dass Billing korrekt auf die gewünschte Subscription zeigt, damit die Kosten später nicht „irgendwo“ landen.
3) Tiering und Retention konfigurieren
Setze eine klare Standardregel (Default) und überschreibe sie nur für Tabellen, die für Detection wirklich häufig abgefragt werden. Damit bleibt das Analytics Tier klein und performant.
4) Zugriff und Sichtbarkeit steuern
Lege RBAC so fest, dass Security Analysts suchen und jagen können, aber nicht automatisch alle sensiblen Log-Daten sehen. Trenne Rollen für Table management, Query-Ausführung und Export.
Dateninjektion, Data Connectors und Data Flow
Der Data Lake ersetzt nicht die Datenerfassung, sondern nimmt die Daten aus dem Sentinel-Ökosystem auf. Data connectors bestimmen Quelle, Format und Ingestion-Pfad (z. B. über Azure Monitor Agent (AMA), Event Hubs oder native Microsoft-Connectors). Ein sauberer Data Flow heißt: nur relevante Logs, konsistente Felder, und klare Zuordnung zu Tabellen, damit Kusto Query Language (KQL) später zuverlässig funktioniert.
Transformationen und Enrichment: wann es „Gold“ wird
Kosten sparen ist gut, aber der größere ROI entsteht, wenn Daten schneller auswertbar sind. Transformationen und Enrichment (z. B. Normalisierung, Anreicherung mit Threat Intelligence oder Kontext aus Defender XDR) erhöhen die „Query-Qualität“: weniger Nacharbeit, schnellere Triage, bessere Jagd-Hypothesen.
Mini-Beispiel: Nach einem verdächtigen Login willst du prüfen, ob dieselbe Identität vor 90 Tagen schon auffällig war. Mit kurzer Analytics-Retention ist das oft unmöglich oder teuer; mit Lake-Retention kannst du den Verlauf in Sekunden per KQL prüfen und Incidents sauber erklären.
RBAC, Security-Governance und Integrationen
Der Data Lake ist nur so gut wie seine Zugriffskontrolle. Nutze Entra-basierte Rollen (Unified RBAC/Entra RBAC) und dokumentiere, wer was darf: Lesen, Abfragen, Export, Verwaltung. Ergänzend lohnt sich ein Review-Prozess für neue Tabellen/Connector-Änderungen, damit Kosten und Datenqualität nicht schleichend entgleisen.
Integrationen entstehen typischerweise über Sentinel, Defender portal, Notebooks (z. B. Jupyter notebooks) und Workflows für Threat hunting. Wichtig ist, dass Governance und Use Cases zusammenpassen: Analysten brauchen Tempo, Compliance braucht Nachvollziehbarkeit.
Preis-/Billing-Logik: wie du sauber kalkulierst
Für die Kalkulation trennst du drei Treiber: Ingestion, Storage und Queries. Das Analytics Tier ist typischerweise teurer, weil es auf schnelle Abfrage und Detection ausgelegt ist. Das Lake Tier verschiebt den Kostenschwerpunkt in günstigeren Log storage, während Abfragen aus dem Lake in der Regel seltener, aber gezielt erfolgen.
Pragmatisches Vorgehen: Starte mit wenigen, volumenstarken Tabellen als Kandidaten fürs Lake Tier, beobachte Query-Verhalten und justiere. So wird der Effekt messbar, ohne sofort alles umzubauen.
Wann externe Unterstützung sinnvoll wird
Externe Hilfe lohnt sich, wenn du den Nutzen schnell realisieren willst, ohne Monate in Trial-and-Error zu verlieren: falsche Retention, zu breite Connector-Scope, unklare RBAC und fehlende Kosten-Transparenz sind die typischen Budget-Killer.
Call-to-Action
Wenn du Sentinel Data Lake einführen willst, aber Retention, Tiering, Connectors und RBAC sauber aufsetzen musst, klärt ein kurzes Erstgespräch die sinnvolle Zielarchitektur und den schnellsten Start. Wir betreiben Managed Microsoft 365 Security mit Fokus auf dem Microsoft Security-Stack und übernehmen den laufenden Sentinel-Betrieb inklusive Tuning, Monitoring und Dokumentation.
Fazit
Sentinel Data Lake ist vor allem eine Steuerungsentscheidung: Was muss schnell im Analytics Tier sein und was gehört als Langzeitwissen in den Lake. Wer Retention, Tiering, Datenfluss und RBAC sauber definiert, senkt laufende Log-Kosten und gewinnt gleichzeitig bessere Forensik- und Nachweisfähigkeit. Der beste Start ist klein, messbar und konsequent auf die wichtigsten Tabellen und Use Cases ausgerichtet.
Häufige Fragen
Ist Sentinel Data Lake ein Ersatz für Microsoft Sentinel (SIEM)?
Nein. Microsoft Sentinel bleibt das SIEM für Detection, Analytics Rules und Incident-Prozesse. Sentinel Data Lake ergänzt es um günstigere, skalierbare Langzeitspeicherung und Analyse historischer Logs.
Wie schnell sieht man einen ROI?
Typisch dann, wenn du teure Analytics-Tier-Retention reduzierst und nur das operativ Nötige dort hältst. Zusätzlich wird ROI sichtbar, wenn Incident-Aufklärung und Audit-Anfragen weniger Zeit kosten, weil historische Daten verfügbar bleiben.
Welche Voraussetzungen sind die häufigsten Stolpersteine?
Fehlende Rechte (RBAC), unklare Tabellen-/Retention-Strategie und zu breit konfigurierte Data Connectors. Das führt entweder zu Zugriffsproblemen oder zu unnötigem Datenvolumen und damit Kosten.
Wie messe ich, ob das Setup „wirkt“?
Über drei Kennzahlen: Anteil der Daten, die im Analytics Tier verbleiben, die Storage-Entwicklung im Lake Tier und die Anzahl/Art der Queries auf historische Daten (z. B. für Threat Hunting und Forensik). Dazu kommt die Zeit bis zur Klärung von Incidents mit historischem Kontext.
