Cloud SIEM vs. On-Premises: Was sich beim Betriebsmodell wirklich ändert

Die Frage wird fast immer als Infrastrukturfrage gestellt: Cloud SIEM oder On-Premises? Also: Steht die Box im eigenen Rechenzentrum oder bei einem Anbieter? In der Praxis ist der Serverstandort der am wenigsten interessante Teil der Entscheidung. Was sich beim Wechsel tatsächlich ändert, sind drei andere Dinge: wie die Kapazität skaliert, wie die Lizenz abrechnet und wer den Betrieb verantwortet.

Und eine Sache ändert sich gar nicht: dazu am Ende mehr, weil sie in Auswahlprozessen regelmäßig untergeht.

Was ein SIEM tatsächlich leistet

Ein Security Information and Event Management-System sammelt Logdaten aus dem gesamten Unternehmen: Endpoints, Identity-Systeme, Netzwerk, Cloud-Plattformen, Applikationen: normalisiert sie in ein gemeinsames Format und korreliert sie über Regeln zu Ereignissen, die einen Menschen interessieren sollten.

Der Wert entsteht nicht beim Sammeln. Er entsteht in der Korrelation: Ein fehlgeschlagener Login ist ein Rauschen. Fünfzig fehlgeschlagene Logins, gefolgt von einem erfolgreichen aus einem anderen Land, gefolgt von einem neu angelegten Postfach-Weiterleitungsregel, das ist ein Vorfall. Kein einzelnes System sieht diese Kette. Das SIEM sieht sie.

Der eigentliche Unterschied liegt im Betriebsmodell

Ein On-Premises-SIEM ist ein Softwareprodukt, das Sie einkaufen, dimensionieren, installieren, patchen und über Jahre pflegen. Sie planen Storage im Voraus, Sie planen Rechenleistung im Voraus, und Sie tragen das Risiko, wenn die Planung nicht aufgeht.

Ein Cloud-SIEM ist ein Dienst. Kapazität ist elastisch, Updates kommen ohne Wartungsfenster, und die Detection-Inhalte des Anbieters landen laufend in Ihrer Umgebung, ohne dass jemand sie manuell nachbaut.

Das klingt nach einer klaren Sache, ist es aber nur, wenn man die Konsequenzen kennt.

Wo ein Cloud-SIEM klar gewinnt

Log-Volumen lässt sich nicht seriös vorhersagen. Ein neuer Cloud-Tenant, eine Migration, eine zusätzliche Applikation mit gesprächigem Debug-Logging und das Tagesvolumen verdoppelt sich. On-Premises heißt das: Storage nachkaufen, Beschaffungsprozess, Wochen. In der Cloud heißt es: nichts tun.

Cloud-Quellen sprechen nativ Cloud. Telemetrie aus Microsoft 365, Entra ID, AWS CloudTrail oder Kubernetes-Audit-Logs kommt über gepflegte Connectors herein, statt über selbstgebaute Parser, die bei jeder API-Änderung des Anbieters brechen. Wer schon einmal einen Parser nach einem Schema-Update nachts repariert hat, kennt den Unterschied.

Time-to-Value ist kürzer. Kein Hardware-Beschaffungszyklus, keine Kapazitätsplanung vor dem ersten Log. Die ersten sinnvollen Detections laufen typischerweise Wochen früher.

Kapazitätsengpässe treffen Sie im schlechtesten Moment. Ein Incident produziert ein Vielfaches der normalen Logmenge: genau dann, wenn Sie jedes Detail brauchen. Ein On-Prem-Cluster am Kapazitätslimit fängt in dieser Situation an, Daten zu verwerfen. Das ist der teuerste denkbare Zeitpunkt für Datenverlust.

Wo On-Premises weiterhin die richtige Antwort ist

Wir verkaufen hier keine Cloud-Doktrin. Es gibt Fälle, in denen On-Premises schlicht die bessere Wahl ist:

• Harte Datenresidenz- oder Geheimschutzauflagen, die eine Verarbeitung außerhalb einer definierten Umgebung ausschließen, nicht das Gefühl einer Auflage, sondern eine dokumentierte.
• OT- und Produktionsnetze, die bewusst air-gapped betrieben werden. Was keine Verbindung nach außen haben darf, kann auch nicht nach außen loggen.
• Eine abgeschriebene Investition mit eingespieltem Team. Ein gut getuntes On-Prem-SIEM mit Analysten, die es beherrschen, ist einem frisch eingeführten Cloud-SIEM ohne Tuning deutlich überlegen. Migration ist kein Selbstzweck.
• Extreme Volumina mit Bandbreitengrenze. Wenn der Standort die Rohdaten gar nicht erst hochbekommt, hilft die eleganteste Cloud-Plattform nichts.

Ein realistischer Mittelweg ist häufig hybrid: Detection-relevante Telemetrie geht in die Cloud, besonders sensible oder besonders voluminöse Quellen bleiben lokal und liefern nur Ergebnisse nach oben.

Die Kostenfalle: Sie zahlen für Ingest, nicht für Sicherheit

Das ist der Punkt, an dem die meisten Cloud-SIEM-Projekte finanziell aus dem Ruder laufen und er hat mit Cloud vs. On-Prem nur indirekt zu tun.

Cloud-SIEM-Lizenzen rechnen fast durchgehend nach aufgenommenem Datenvolumen ab, meist in Gigabyte pro Tag. Der intuitive Reflex lautet: Wir sammeln erst mal alles ein, filtern später. Das Ergebnis ist eine Rechnung, die mit dem Logvolumen wächst: während die Erkennungsqualität es nicht tut.

Denn die meisten Logzeilen tragen keinen Detection-Wert. Verbose Applikations-Logs, Health-Checks, Load-Balancer-Zeilen im Sekundentakt: Das ist Forensik-Material, kein Erkennungsmaterial.

Was tatsächlich hilft:

• Log-Routing vor dem Ingest. Entscheiden, welche Quelle in die teure Detection-Schicht geht und welche direkt in günstigen Archivspeicher.
• Tiering. Heiße Daten für Korrelation und Alerting, kalte Daten für Untersuchung und Nachweispflichten. Beides ist notwendig, beides muss nicht dasselbe kosten.
• Quellen nach Detection-Wert priorisieren, nicht nach Verfügbarkeit. Identity- und Endpoint-Telemetrie trägt fast immer mehr zur Erkennung bei als Applikations-Debug-Logs.

Wer diese Entscheidungen vor dem Rollout trifft, statt nach der ersten überraschenden Rechnung, spart im laufenden Betrieb regelmäßig einen substanziellen Teil der Lizenzkosten, ohne Erkennungsabdeckung zu verlieren.

Was das Betriebsmodell nicht löst

Und hier ist die Sache, die sich beim Wechsel eben nicht ändert.

Ein SIEM (in der Cloud oder im Keller) ist eine Maschine, die Alarme erzeugt. Ein SIEM ohne Analysten ist ein sehr teurer Alarm, den niemand beantwortet. Die Plattformentscheidung ändert nichts an den drei Aufgaben, die den Unterschied zwischen einem funktionierenden und einem dekorativen SIEM ausmachen:

1. Detection Engineering. Mitgelieferte Standardregeln sind ein Startpunkt, kein Ergebnis. Wirksame Erkennung wird auf die eigene Umgebung geschrieben und gegen ein Framework wie MITRE ATT&CK auf Abdeckungslücken geprüft.
2. Kontinuierliches Tuning. Ein untuned SIEM produziert so viele False Positives, dass das Team aufhört hinzuschauen. Alert Fatigue ist kein Komfortproblem, sondern ein Erkennungsausfall mit Ansage.
3. Reaktion rund um die Uhr. Angriffe laufen nachts, am Wochenende und an Feiertagen. Ein Alert um 03:14 Uhr, den niemand liest, ist funktional identisch mit keinem Alert.

Genau diese Trennlinie bildet unser Leistungsschnitt bei Managed SIEM / SOC ab: Plattformbetrieb und Detection Engineering auf der einen Seite, menschliche Triage und Response rund um die Uhr auf der anderen. Wo Ihr Team endet, fangen wir an.

Fünf Fragen, die Sie vor der Auswahl beantworten sollten

1. Wie hoch ist unser Logvolumen heute und wie hoch nach der nächsten geplanten Migration?
2. Welche Quellen tragen wirklich zur Erkennung bei, und welche nur zur Rechnung?
3. Wie lange müssen wir Daten vorhalten: aus Untersuchungssicht und aus Nachweissicht?
4. Wer schreibt und pflegt die Detection-Regeln nach dem Go-live?
5. Wer bearbeitet den Alert um 03:14 Uhr?

Frage 4 und 5 entscheiden über den Erfolg des Projekts. Frage 1 bis 3 entscheiden nur über den Preis.

Was NIS2 und DORA daran ändern

Für regulierte Unternehmen kommt ein harter Zeitfaktor dazu. NIS2 verlangt nach Art. 23 eine Frühwarnung binnen 24 Stunden, eine Vorfallsmeldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats. Diese Fristen laufen ab Kenntnis und Kenntnis setzt Erkennung voraus.

Ein Meldeprozess ist nur so schnell wie die Detection darunter. Wer erst nach Wochen bemerkt, dass etwas passiert ist, hat die 24-Stunden-Frist nicht knapp verpasst, sondern nie erreicht. Dazu kommt: Meldungen müssen belastbar sein, und belastbar heißt Evidenz aus Logdaten, die zum Vorfallszeitpunkt noch vorhanden waren.

Welche Anforderungen aus NIS2 und DORA durch welche Leistung abgedeckt sind (und welche bewusst nicht) haben wir im Detail unter NIS2 & DORA aufgeschlüsselt.

Fazit

Cloud oder On-Premises ist eine Betriebsentscheidung, keine Sicherheitsentscheidung. Cloud gewinnt bei Elastizität, Cloud-nativen Quellen und Time-to-Value; On-Premises behält seine Berechtigung bei harten Residenzauflagen, air-gapped Umgebungen und funktionierenden Bestandsinstallationen.

Was in beiden Modellen über die tatsächliche Sicherheitswirkung entscheidet, ist unverändert: saubere Quellenauswahl, gepflegte Detection-Regeln und Menschen, die auf Alarme reagieren. Die Plattform ist die Voraussetzung. Sie ist nicht das Ergebnis.