Revisionssicheres Logging: Protokolle, die im Nachweis halten

Revisionssicheres Logging wird spätestens dann zur Prüffrage, wenn im Nachweis nach § 39 BSIG belegt werden muss, dass sich Protokolle nicht unkontrolliert ändern oder löschen lassen. Schreibt das eigene Fachverfahren sein Audit Logging in eine gewöhnliche Datenbanktabelle, auf die auch die Administration Zugriff hat, fehlt genau dieser Beleg. Das Protokoll existiert dann, es beweist nur nichts.
Eine Frau im gelbgrünen Blazer zeigt auf ihren Laptop, ein Mann hält sein Tablet daneben, beide Bildschirme zeigen dieselbe Zeichenfolge, im Hintergrund eine Leitwarte. Sinnbild für Audit Logging, dessen Prüfwert gegen ein getrenntes System abgeglichen wird.
© KI-generiert (TenMedia)

Warum der Nachweis revisionssicheres Logging verlangt

Von den Unternehmen, die nach einem Angriff etwas über die Täter herausfanden, nannten 2025 genau 75 Prozent die Analyse von Log-Dateien als Grundlage, ein Jahr zuvor waren es 66 Prozent. Logging heißt, dass ein System seine Vorgänge automatisch mitschreibt.

Revisionssicheres Logging bedeutet, dass Protokolleinträge nach ihrer Entstehung weder unbemerkt verändert noch unkontrolliert gelöscht werden können und dass sich diese Unveränderbarkeit belegen lässt. Dazu gehören ein Integritätsschutz schon in der Anwendung, eine Ablage außerhalb der Reichweite der Administration, eine synchrone Systemzeit und eine festgelegte Aufbewahrungsfrist. Ziel ist Beweiskraft gegenüber Prüfstelle und Aufsicht und bei der Aufklärung eines Vorfalls.

Von § 31 BSIG zum Baustein OPS.1.1.5

Im IT-Sicherheitsmanagement hat die Protokollierung eine eigene Sicherheitsrichtlinie (OPS.1.1.5.A1). § 31 Absatz 2 BSIG verpflichtet Betreiber kritischer Anlagen, Systeme zur Angriffserkennung einzusetzen. Die Orientierungshilfe Angriffserkennung des BSI, noch zur Vorgängerregelung in § 8a BSIG verfasst, verlangt dafür in Kapitel 3.1.2, dass für die Protokollierung alle Basisanforderungen des Bausteins OPS.1.1.5 erfüllt sind (BSI, Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, 2024). Darin regelt das BSI Protokollierung im Detail, und Anforderung A5 endet mit dem Satz, an dem alles hängt: „Es MUSS technisch unterbunden werden, dass Protokollierungsdaten unkontrolliert gelöscht oder verändert werden.“ (BSI, IT-Grundschutz-Kompendium, Baustein OPS.1.1.5 Protokollierung, 2023). Revisionssicheres Logging gehört damit zur Mindestanforderung und nicht zur Kür.

Welche Ereignisse eine Fachanwendung liefert und wie sie ins Erkennungssystem gelangen, ist Teil der SIEM-Anbindung für Fachanwendungen. Hier geht es um die Beweiskraft des Gelieferten.

Was „unkontrolliert“ im Betrieb bedeutet

Gelöscht werden darf durchaus, denn dieselbe Anforderung verlangt einen festgelegten Löschprozess. Unkontrolliert ist ein Eingriff erst, wenn er ohne Verfahren und ohne Spur möglich ist. Bei selbst entwickelten Fachanwendungen sind das typische Ausgangslagen für das Audit Logging:

Jede dieser Lagen ist eine Entscheidung aus der Entwicklung, kein Fehler im Betrieb. Revisionssicheres Logging behebt sie deshalb dort, wo der Eintrag entsteht, etwa mit Hash-Verkettung und Signatur.

Revisionssichere Protokollierung ist keine GoBD-Archivierung

Der Begriff Revisionssicherheit stammt aus der Archivierung nach Handels- und Steuerrecht, wo Buchungsbelege über Jahre unverändert bleiben müssen. Eine revisionssichere Protokollierung nach BSIG soll dagegen Angriffe aufklärbar machen. Deren Daten unterliegen dem Datenschutz mit eher kurzen Fristen. Beide Pflichten treffen sich in der IT-Compliance, folgen aber verschiedenen Regeln. Ein Archivsystem für Belege ersetzt deshalb kein revisionssicheres Logging.

Reicht ein SIEM als revisionssichere Ablage für Logdaten?

Ein SIEM, also die zentrale Plattform, die Sicherheitsmeldungen vieler Systeme sammelt und vergleicht, ist für die Auswertung gebaut. Ob es Protokolle unveränderbar ablegt, hängt von seiner Konfiguration ab und nicht von seiner Aufgabe. Revisionssichere Protokollierung entscheidet sich deshalb daran, wo der Eintrag entsteht, wer auf die Ablage zugreift und ob sich die Unveränderbarkeit später prüfen lässt.

Auswertung und Ablage sind zwei Aufgaben

Die Auswertung sucht Muster und schlägt Alarm, die Ablage belegt, dass ein Eintrag seit seiner Entstehung derselbe geblieben ist. Das BSI sieht für Betreiber kritischer Anlagen vor, dass Protokolle auf zentralen Protokollierungsservern liegen, „wo sie vor unautorisierten Zugriffen und Veränderungen geschützt sind“ (BSI, Konkretisierung der Anforderungen an die gemäß § 8a Absatz 1 und Absatz 1a BSIG umzusetzenden Maßnahmen, 2024). Ein revisionssicheres Log-Management behandelt die Protokollierungsinfrastruktur deshalb selbst als Schutzobjekt.

Offen bleibt oft der Weg dorthin. Schreibt die Anwendung erst in eine lokale Datei und übergibt sie später, lässt sich der Eintrag zwischendurch ändern, ohne dass das SIEM es merkt. Die Datenschutzkonferenz empfiehlt deshalb, Protokolle in Echtzeit auf zugriffsbeschränkte Protokollserver zu übertragen. Das verkleinert die Lücke, geschlossen ist sie erst, wenn die Anwendung jeden Eintrag beim Schreiben sichert.

Wie lässt sich verhindern, dass Admins Spuren löschen?

Die Administration hat weitreichende Rechte und darf gerade deshalb nicht über die Aufzeichnung ihrer eigenen Arbeit verfügen. OPS.1.1.5.A10 sieht als Standardanforderung (SOLLTE) vor, dass die ausführenden Administrierenden die Protokollierungsdaten weder verändern noch löschen können. Protokolldaten vor Administratoren schützen heißt nicht, ihnen zu misstrauen, sondern sie vor dem Verdacht zu bewahren. Um das Logging revisionssicher zu machen, trennt die Fachanwendung die Rechte so:

Diese Trennung entsteht im Berechtigungsmanagement der Anwendung, nicht erst im Betrieb. Wer die Ablage verwaltet, administriert nicht zugleich die Systeme, deren Protokolle dort liegen.

Audit Logging in der Fachanwendung umsetzen

Audit Logging meint die Aufzeichnung sicherheitsrelevanter Vorgänge mit Blick auf eine spätere Prüfung. Ein revisionssicheres Logging entsteht aus zwei Mechanismen, die sich ergänzen: einem Integritätsschutz, den die Anwendung jedem Eintrag mitgibt, und einer Ablage, die Änderungen technisch ausschließt. Dazu kommt eine leicht übersehene Voraussetzung: die gemeinsame Zeit aller Systeme.

Hash-Verkettung und Signatur am Entstehungsort

Bei der Hash-Verkettung trägt jeder Eintrag einen Prüfwert, der aus seinem Inhalt und dem Prüfwert des Vorgängers berechnet wird. Ändert jemand einen alten Eintrag, passen alle folgenden Prüfwerte nicht mehr. Ein so gesicherter Audit Trail verhindert Manipulation nicht, er macht sie sichtbar, solange niemand die ganze Kette neu berechnet. Mit vollem Zugriff ginge genau das. Deshalb geht der jeweils letzte Prüfwert regelmäßig an ein getrenntes System. Im Audit Logging trägt ein Eintrag dafür typischerweise:

👉 Zeitstempel aus einer synchronisierten Quelle
👉 Ereignistyp und handelnde Kennung
👉 fortlaufende Nummer ohne Lücken
👉 Prüfwert des vorherigen Eintrags
👉 Prüfwert oder Signatur des Eintrags selbst

Eine digitale Signatur belegt zusätzlich, welches System den Eintrag erzeugt hat. OPS.1.1.5 sieht sie bei erhöhtem Schutzbedarf vor (A12). Die Signaturschlüssel brauchen eine eigene Public-Key-Infrastruktur, sonst ist sie nur so vertrauenswürdig wie ein ungeschützter Schlüssel.

WORM-Speicher oder verkettete Einträge?

WORM steht für Write Once Read Many. In einem WORM-Speicher lassen sich Daten bis zum Ablauf einer Sperrfrist weder ändern noch löschen. Die Datenschutzkonferenz nennt WORM-Speicher und digitale Signaturen als Mittel gegen nachträgliche Änderung von Audit-Protokollen. Der WORM-Speicher schützt ab der Ankunft des Eintrags, die Verkettung schon ab seiner Entstehung. Welcher Schutz für revisionssicheres Logging zuerst kommt, hängt davon ab, wo die Schwachstelle liegt. Steht eine Ablage mit Aufbewahrungssperre schon bereit, kostet sie wenig. Liegt die Schwachstelle auf dem Weg aus der Anwendung, hilft nur die Verkettung, und bei hohem Schutzbedarf gilt beides.

Zeitsynchronisation als Beweisvoraussetzung

Eine Reihenfolge belegt ein Protokoll nur, wenn alle Systeme dieselbe Zeit haben. OPS.1.1.5.A4 verlangt deshalb, dass die Systemzeit aller protokollierenden Systeme immer synchron ist. Fehlt die Zeitsynchronisation, kann das laut BSI dazu führen, „dass die Protokollierung nicht zur Beweissicherung herangezogen werden kann“. Die Revisionsfestigkeit der Protokolldaten hängt also auch an der Uhr. Für das Audit Logging heißt das: zentrale Zeitquelle, einheitliches Format, Zeitzone im Zeitstempel.

Revisionssicheres Logging: Frist und Nachweis

Den Abstand zur Vorgabe zeigt der BSI-Lagebericht: Bei Systemen zur Angriffserkennung erfüllen erst 48 Prozent der KRITIS-Betreiber die Mindestanforderungen, beim ISMS sind es rund 80 Prozent. Mindestanforderung heißt Reifegrad 3, in der Orientierungshilfe Umsetzungsgrad 3, und der setzt alle MUSS-Anforderungen voraus, den Schutz der Protokolle eingeschlossen. Offen bleiben zwei Fragen: wie lange Protokolle bleiben und was vorgelegt wird.

Revisionssichere Protokollierung und die Speicherfrist

Eine einheitliche gesetzliche Speicherfrist für Protokolldaten gibt es nicht. Die Orientierungshilfe Angriffserkennung verlangt, gesetzliche Lösch- und Speicherfristen einzuhalten, und weil Protokolle meist Personenbezug haben, entscheidet der Zweck über die Speicherdauer. Logfiles mit Kennungen und Zugriffszeiten sind personenbezogene Daten. Deshalb muss jede Protokollierung DSGVO-konform bleiben. Für Betreiber kritischer Anlagen nennt das BSI einen Erfahrungswert: Eine Frist von einem Jahr sollte nicht überschritten werden. Die revisionssichere Protokollierung legt die Frist deshalb je Ereignisklasse fest und begründet sie, und eine WORM-Sperrfrist darf nicht länger laufen als diese Frist. Auch revisionssicheres Logging muss also löschen, sobald der Zweck entfällt. Bei einem laufenden Vorfall entfällt er nicht.

Was in die Nachweisdokumentation gehört

Die Orientierungshilfe verlangt eine dokumentierte Planung und einen Prozess, der sie bei Änderungen anpasst. Bitkom-Präsident Dr. Ralf Wintergerst sagte im Studienbericht Wirtschaftsschutz 2025: „IT-Sicherheit ist kein Zustand, IT-Sicherheit ist ein Prozess und ihn müssen wir aktiv betreiben.“ Das Protokollierungskonzept lebt also mit jedem Release weiter. Die ersten vier Punkte sind Pflicht, die übrigen machen den Integritätsschutz prüfbar:

TenMedia ist nach ISO/IEC 27001:2022 durch den TÜV SÜD zertifiziert, Geltungsbereich Entwicklung von Individualsoftware sowie Hosting und Maintenance von Cloud-Anwendungen. TenMedia übernimmt die Protokollierung auf der Anwendungsseite bis zur Dokumentation für die Prüfstelle, betreibt aber kein SIEM und erteilt keine Testate. Beim SaaS für ambulante Betreuungsdienste, seit Juli 2023 im Betrieb, gehören ein Rechte- und Rollenkonzept und die datenschutzkonforme Pflege von Patientendaten zum laufenden Auftrag, also dieselbe Rechtetrennung, auf der revisionssicheres Logging aufbaut.

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.

FAQs

Woran erkennt eine prüfende Stelle, dass Protokolle unverändert sind? keyboard_arrow_down keyboard_arrow_up
An einem Verfahren, das sich vorführen lässt, nicht an einer Zusicherung. Belegbar wird die Unveränderbarkeit, wenn sich die Prüfwerte der Einträge mit einem Werkzeug nachrechnen lassen und mit dem zuletzt extern hinterlegten Wert übereinstimmen. Dazu kommen eine Rechteübersicht, aus der hervorgeht, dass niemand aus der Administration die Ablage ändern kann, und ein dokumentierter Test, bei dem ein gezielt veränderter Eintrag erkannt wurde. Lückenlose laufende Nummern zeigen, dass kein Eintrag fehlt, Zeitstempel aus einer gemeinsamen Zeitquelle belegen die Reihenfolge. Am stärksten wirkt eine Prüfung, welche die prüfende Stelle selbst wiederholen kann.
Dürfen Protokolle über die Administration zur Leistungskontrolle dienen? keyboard_arrow_down keyboard_arrow_up
Nach Auffassung der Datenschutzkonferenz nicht. Sie bindet Protokolle über administrative Tätigkeiten an ihren Zweck, also an die Prüfung, ob nur übertragene Aufgaben erledigt wurden. Wie schnell jemand gearbeitet hat, darf daraus nicht ausgewertet werden. Wo ein Betriebs- oder Personalrat besteht, greift dessen Mitbestimmung.
Woran lässt sich ein geeigneter Dienstleister für revisionssichere Protokollierung erkennen? keyboard_arrow_down keyboard_arrow_up
Ein geeigneter Dienstleister belegt drei Dinge: ein zertifiziertes ISMS mit passendem Geltungsbereich, ein schriftliches Protokollierungskonzept je Anwendung und Erfahrung mit Rechtetrennung in Fachverfahren. TenMedia übernimmt die Protokollierung auf der Anwendungsseite und dokumentiert für die Prüfstelle, wie revisionssicheres Logging umgesetzt ist.