Sentinel Log Analytics Workspace: Architektur, Datenfluss und Betrieb

Definition

Ein Sentinel Log Analytics Workspace ist ein Log Analytics Workspace, der als Datenspeicher und Analysebasis für Microsoft Sentinel dient. Er ist kein allgemeines Logging-Archiv für alle IT-Themen und keine vollständige Sicherheitsstrategie, sondern die Plattform für Ingestion, KQL-Analysen, Regeln und Incident-Erzeugung in Sentinel.

Einleitung

Wenn Sentinel „zu laut“ ist, Incidents fehlen oder Kosten aus dem Ruder laufen, liegt die Ursache oft nicht in Sentinel selbst, sondern im Workspace-Design. Mit einem sauberen Setup steuerst du Datenquellen, Zugriffe und Automatisierung so, dass dein Team weniger sucht und schneller entscheidet.

Sentinel Log Analytics Workspace: die Architektur-Relation

Microsoft Sentinel wird auf einem Log Analytics Workspace aktiviert. Der Workspace ist die Datenebene (Logs, Tabellen, Retention), Sentinel ist die SIEM/SOAR-Ebene darüber (Analytics Rules, Incidents, Automations, Workbooks).

Der praktische Nutzen: Du zentralisierst Security-Informationen, korrelierst Ereignisse über Datenquellen hinweg und bekommst ein einheitliches Incident-Management. Das spart Zeit im Betrieb, weil Analyse und Nachverfolgung nicht in einzelnen Portalen und Tools auseinanderlaufen.

Datenquellen und Ingestion-Pfade: so kommen Logs hinein

Logs landen über Data Connectors und Ingestion-Pfade im Workspace. Für viele Microsoft-Quellen ist das „Connector aktivieren“, bei Custom Logs geht es um strukturierte Ingestion und stabile Feldnamen, damit Regeln und Workbooks langfristig wartbar bleiben.

• Microsoft-Quellen: z. B. Entra ID, Microsoft 365, Azure Activity Logs, Defender-Produkte.
• Azure/Hybrid: z. B. Windows-Events oder Syslog über Agent/DCR, je nach Architektur.
• Custom/Third-Party: z. B. via Log Analytics Data Collector API oder definierte Custom Tables.

Wichtig für die Praxis: Jede zusätzliche Quelle erhöht nicht nur Sichtbarkeit, sondern auch Datenvolumen, Regelpflege und Abstimmungsaufwand. Deshalb zuerst klären, welche Use Cases du wirklich abdecken willst.

Mehrere Workspaces und Tenants: was du wirklich managen musst

Ein Workspace ist eine harte Grenze für Datenhaltung, Retention, Berechtigungen und viele Konfigurationen. Mehrere Workspaces sind sinnvoll, wenn Organisationsstruktur, Zugriffsmodelle oder Kostenstellen es erfordern, erhöhen aber die Betriebs-Komplexität.

Typische Gründe für mehrere Workspaces: getrennte Gesellschaften, unterschiedliche Regionen, unterschiedliche Retention-Vorgaben oder ein striktes „Need-to-know“-Modell. Multi-Tenant wird relevant, wenn du über mehrere Entra-Tenants hinweg betreibst; dann brauchst du ein klares Modell für Zuständigkeiten und Zugriff, statt nur „mehr Daten anschalten“.

Eine pragmatische Regel: Starte so zentral wie möglich, trenne nur, wenn du einen klaren Governance-Grund hast. Sonst entstehen doppelte Analytics Rules, uneinheitliche Incident Settings und schwer vergleichbares Reporting.

Erste Schritte: Workspace erstellen und Sentinel verbinden

Der Start ist bewusst simpel, wenn du ihn in Reihenfolge abarbeitest. Erst Infrastruktur-Grundlagen, dann Daten, dann Erkennung, dann Betrieb.

• Log Analytics Workspace in passender Subscription/Resource Group/Region erstellen und Grundlagen festlegen (z. B. Retention, Zugriffe).
• Microsoft Sentinel auf diesem Workspace aktivieren und wichtige Data Connectors priorisiert anbinden.
• Erste Analytics Rules und Workbooks aktivieren, aber mit klarer Zielsetzung statt „alles an“.

Run Frequency, Incident Settings und Alert-Management

Regeln ohne Betriebslogik erzeugen entweder Lärm oder blinde Flecken. Run Frequency (wie oft Regeln laufen), Incident Settings (wann und wie Alerts in Incidents zusammengeführt werden) und das Alert-Management entscheiden, ob dein Team handlungsfähig bleibt.

Bewährt ist ein stufenweises Vorgehen: Erst wenige, hochwertige Detection-Use-Cases produktiv nehmen, dann tunen. Dazu gehören Owner, Prioritäten, Triage-Kriterien und eine Routine für False-Positive-Reduktion. Messbar wird es, wenn du Kennzahlen wie Zeit bis zur Triage, Anteil automatisch geschlossener Incidents und Anzahl wiederkehrender Alarmmuster verfolgst.

Automatisierung: Playbooks, Automation Rules und Integrationen

Sentinel spart dann Betriebskosten, wenn wiederkehrende Arbeit nicht manuell passiert. Automation Rules können Incidents automatisch taggen, priorisieren, zuweisen oder Playbooks anstoßen. Playbooks (auf Basis von Logic Apps) übernehmen standardisierte Schritte wie Benachrichtigung, Ticket-Erstellung oder erste Eindämmungsaktionen in angebundenen Microsoft-Systemen.

Mini-Beispiel aus der Praxis: Ein Risky Sign-in in Entra ID erzeugt einen Alert, der per Automation Rule als „Identity“ klassifiziert, einem Owner zugewiesen und mit Kontextdaten angereichert wird. Das Playbook erstellt parallel ein Ticket und sammelt relevante Logs für die Triage. Ergebnis: weniger Kontext-Suche, schnellere Entscheidung, weniger Eskalationen.

Kosten, Pricing-Modelle und Lizenzoptionen: was wirklich treibt

Kosten entstehen vor allem durch Dateningestion, Aufbewahrung (Retention) und den Umfang aktiv genutzter Funktionen. Das Pricing-Modell hängt von deinem Nutzungsprofil ab; entscheidend ist, dass du von Anfang an steuerst, welche Daten wirklich nötig sind und wie lange sie gespeichert werden.

Pragmatische Stellhebel: unnötige Datenquellen vermeiden, Custom Logs sauber normalisieren (damit Regeln nicht „teurer“ durch ineffiziente Queries werden), Retention nach Use Case definieren, und Workspaces so schneiden, dass Kostenstellen und Verantwortlichkeiten nachvollziehbar bleiben.

Sicherheitsaspekte: RBAC, Zugriffskontrollen und Governance

Ein Sentinel Log Analytics Workspace ist ein sensibles System: Wer Zugriff hat, kann Sicherheitsdaten sehen oder Erkennung verändern. Azure role-based access control (Azure RBAC) ist deshalb Pflicht, nicht Kür.

• Rollen strikt trennen: Lesen/Analysieren vs. Konfigurieren/Deployen.
• Zugriffe regelmäßig reviewen, besonders bei mehreren Workspaces und Tenants.
• Änderungen an Regeln und Connectors über definierte Freigaben steuern.

Als Governance-Checkliste: Datenquellen-Katalog, Owner je Connector, Naming-Konventionen für Rules/Incidents, Change-Prozess, Runbooks für Top-10-Incident-Typen und ein Reporting, das auch für Geschäftsführung verständlich ist.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn Sentinel nicht nur eingerichtet, sondern stabil betrieben werden soll: mehrere Workspaces oder Tenants, viele Datenquellen, hoher Druck durch NIS2-Nachweispflichten oder ein IT-Team ohne dedizierte Security-Rolle.

Dann geht es um Betrieb: kontinuierliches Tuning, Alert-Handling, Incident-Prozesse, Zugriffskontrolle und saubere Dokumentation. Ein kostenloses Erstgespräch (30 Minuten, remote, kein Pitch, kein Angebot ohne dein OK) klärt schnell, ob dein Setup eher „Monitoring“ braucht oder bereits aktive Incident Response.