Wann Logdaten vom Helfer zum Risiko werden

Logdaten sind im IT-Betrieb wie eine Erinnerung an das, was wirklich passiert ist. Sie zeigen Fehler, Zugriffe, Warnungen und technische Abläufe. Doch je länger niemand entscheidet, welche Daten gebraucht werden und welche verschwinden sollen, desto schneller wird aus Hilfe ein neues Risiko.

Logdaten sind automatisch erzeugte Aufzeichnungen von Anwendungen, Servern, Netzwerkkomponenten, Sicherheitswerkzeugen oder Cloud-Diensten. Sie zeigen zum Beispiel, wann ein Dienst gestartet wurde, welche Fehlermeldung auftrat oder welcher Zugriff geprüft werden muss. Für ITSM-Generalisten sind sie wichtig, weil Störungen, Sicherheitsfragen und Nachweise ohne solche Spuren oft nur geraten werden. Gleichzeitig enthalten Logs manchmal personenbezogene Daten, interne Abläufe oder Hinweise auf Schwachstellen.

Der Nutzen entsteht nur durch Auswahl

Ein häufiger Irrtum lautet: Mehr Logs bedeuten automatisch mehr Überblick. In der Praxis stimmt das nur begrenzt. Wenn jedes System unbegrenzt schreibt, wächst zuerst die Datenmenge. Der tatsächliche Nutzen wächst nur, wenn klar ist, welche Ereignisse für Störungen, Sicherheit, Kapazität, Audits oder Kundenkommunikation wirklich gebraucht werden.

NIST beschreibt Logmanagement als eigene Betriebsaufgabe, nicht als beiläufige Technikfunktion. Dazu gehören Sammeln, Schützen, Auswerten, Aufbewahren und Löschen. Genau diese Kette macht den Unterschied. Ein Log, das niemand auswertet, hilft im Ernstfall kaum. Ein Log, das zu früh verschwindet, fehlt bei der Ursachenanalyse. Ein Log, das zu lange und ungeschützt bleibt, kann selbst zum Angriffs- oder Datenschutzproblem werden.

Zu kurze Aufbewahrung schadet der Fehlersuche

Störungen zeigen sich selten im perfekten Moment. Ein Nutzer meldet ein Problem erst am nächsten Tag, ein Fachbereich erkennt eine Datenabweichung nach dem Monatslauf, ein Sicherheitsereignis fällt erst durch einen späteren Hinweis auf. Wenn die relevanten Logs dann schon gelöscht sind, verliert der Betrieb die Möglichkeit, sauber zu erklären, was passiert ist.

Deshalb brauchen Teams keine pauschale Maximalaufbewahrung, sondern sinnvolle Fristen je Logtyp. Ein Debug-Log aus einer Testumgebung hat eine andere Aufgabe als ein Sicherheitsereignis im Produktivbetrieb. Ein kurzer technischer Trace kann nach wenigen Tagen wertlos sein. Ein Zugriffsnachweis für einen kritischen Dienst kann länger relevant bleiben. Entscheidend ist, dass diese Unterschiede vor der Störung festgelegt sind.

Zu lange Aufbewahrung schafft neue Angriffsfläche

Das andere Extrem ist das stille Horten. Alte Logs wirken harmlos, weil sie im Alltag selten sichtbar sind. Sie können aber sensible Details enthalten. Dazu gehören Benutzernamen, IP-Adressen, interne Pfade, Fehlermeldungen, Session-Hinweise oder technische Konfigurationen. Wenn solche Daten jahrelang unklar gespeichert bleiben, wächst die Angriffsfläche.

Auch Datenschutz spielt hinein. Die Datenschutz-Grundverordnung nennt im Grundsatz der Speicherbegrenzung, dass personenbezogene Daten nicht länger aufbewahrt werden sollen, als es für den Zweck notwendig ist. Für ITSM heißt das praktisch: Der Zweck eines Logtyps muss bekannt sein. Nur dann lässt sich erklären, warum er gespeichert wird, wie lange er gebraucht wird und wer darauf zugreifen darf.

Der Service Desk braucht klare Antworten

Logaufbewahrung klingt nach Backend-Thema, landet aber schnell im Service Desk. Nutzer fragen, warum ein Vorgang nicht mehr nachvollzogen werden kann. Fachbereiche wollen wissen, ob eine Störung nachweisbar ist. Security fragt, ob ein verdächtiger Zugriff geprüft wurde. Datenschutz fragt, welche Daten in welchem System liegen.

Ohne abgestimmte Antwort wirkt der Betrieb unsicher. Die eine Stelle verspricht Nachweise, die andere verweist auf gelöschte Logs, die dritte findet Daten in einem alten Export. Besser ist eine einfache Loglandkarte. Sie zeigt pro Service, welche wichtigen Logquellen existieren, welche Fristen gelten, wer Zugriff hat und welcher Eskalationsweg bei einer Untersuchung greift.

Gute Logs sind lesbar, geschützt und begrenzt

OWASP empfiehlt in seiner Logging Cheat Sheet, Protokollierung bewusst zu planen. Sie soll Ereignisse erfassen, die für Sicherheit und Betrieb relevant sind, aber keine unnötigen Geheimnisse oder sensiblen Inhalte speichern. Diese Regel ist für den Servicebetrieb besonders wertvoll. Ein Log soll erklären, was passiert ist. Es soll nicht nebenbei Passwörter, Tokens oder private Inhalte einsammeln.

Der Schutz der Logs ist genauso wichtig wie ihre Existenz. Schreibrechte, Leserechte, Transport, zentrale Ablage und Manipulationsschutz gehören zusammen. Wenn ein Angreifer Logs löschen oder ändern kann, verlieren sie im Sicherheitsfall an Wert. Wenn zu viele Menschen vollständigen Zugriff haben, steigt das Risiko für Missbrauch oder versehentliche Offenlegung.

Ausmisten ist ein Betriebsprozess

Eine gute Ausmist-Routine beginnt mit einer Bestandsaufnahme. Welche Systeme schreiben welche Logs? Welche davon werden wirklich genutzt? Welche enthalten sensible Daten? Welche Fristen sind fachlich, rechtlich oder vertraglich begründet? Welche Exporte, Backups oder Archivkopien umgehen die eigentliche Löschregel?

Danach braucht jede wichtige Logquelle eine Entscheidung. Der Betrieb legt fest, wofür die Daten gebraucht werden, wie lange sie aufbewahrt werden, wann sie gelöscht oder verdichtet werden und wer eine Ausnahme genehmigt. Eine Ausnahme ohne Ablaufdatum ist kein sauberer Betrieb. Sie ist nur eine verschobene Entscheidung.

Prüffragen für den nächsten Log-Review

• Welche Logquellen sind für die wichtigsten Services wirklich entscheidend?
• Welche Logs werden nie ausgewertet und erzeugen nur Speicher, Kosten oder Risiko?
• Welche Einträge enthalten personenbezogene oder sicherheitskritische Informationen?
• Welche Aufbewahrungsfrist ist für Fehlersuche, Sicherheit und Nachweis nötig?
• Wer darf vollständige Logs lesen, exportieren oder löschen?
• Welche alten Exporte, Archive oder Backups umgehen die aktuelle Löschlogik?

Logdaten sind kein digitales Gedächtnis ohne Ende. Sie sind ein Arbeitsmittel. Ihr Wert entsteht aus Zweck, Qualität, Schutz und begrenzter Aufbewahrung. Wer Logdaten regelmäßig überprüft und ausmistet, nimmt dem Betrieb keine Transparenz. Er sorgt dafür, dass im Ernstfall die richtigen Spuren da sind und die falschen nicht unnötig lange herumliegen.

Quellen und Einordnung NIST Special Publication 800-92 Guide to Computer Security Log Management, OWASP Logging Cheat Sheet und Art. 5 Datenschutz-Grundverordnung zur Speicherbegrenzung. Stand der Quellenprüfung 27.06.2026.