NIS2 und DORA: Das Audit-Protokoll, das sie erwarten

Zwei europäische Gesetze bestimmen inzwischen für viele Organisationen, was „Wir führen ein Audit-Protokoll“ bedeuten muss. NIS2 erfasst wesentliche und wichtige Einrichtungen in achtzehn Sektoren, von Energie und Gesundheit bis zu digitalen Anbietern und den Unternehmen, die sie beliefern. DORA erfasst den Finanzsektor und die IKT-Dienstleister, von denen er abhängt. Beide gelten: DORA seit Januar 2025, das deutsche NIS2-Umsetzungsgesetz seit Dezember 2025 und das niederländische seit August 2026.

Keiner der beiden Texte enthält ein Protokollschema. Wer eine Feldliste sucht, geht leer aus, und Anbieter füllen die Lücke mit der Behauptung, ihr Produkt sei „NIS2-konform“. Das ist keine Eigenschaft, die ein Produkt haben kann. Was die beiden Gesetze enthalten, ist nützlicher: eine Beschreibung dessen, was ein Protokoll leisten können muss, besonders in den Stunden, nachdem etwas schiefgegangen ist. Dieser Artikel stellt das dar und zeigt dann, wie das Audit-Protokoll von Sapherbox jeden Punkt beantwortet, auch dort, wo es das noch nicht tut.

Was NIS2 verlangt

Die Richtlinie selbst listet in Artikel 21 die Maßnahmen auf, die jede erfasste Einrichtung treffen muss. Die Bewältigung von Sicherheitsvorfällen ist eine davon, ebenso Konzepte für Zugriffskontrolle, Kryptografie und die Sicherheit der Lieferkette. Protokollierung wird nicht als eigene Maßnahme genannt. Sie taucht dort auf, wo sie hingehört: als das, worauf die Bewältigung von Vorfällen aufbaut.

Die Einzelheiten stehen in der Durchführungsverordnung, die die Kommission im Oktober 2024 für digitale Anbieter erlassen hat und die die nationalen Behörden auch für alle anderen als Referenz heranziehen. Unter der Bewältigung von Vorfällen verlangt sie, Aktivitäten auf den Systemen zu überwachen und zu protokollieren, um Ereignisse zu erkennen, die Vorfälle sein könnten. Und sie sagt, was das Protokoll, soweit angemessen, abdecken soll: Anlegen, Ändern und Löschen von Nutzern, Authentifizierungsereignisse, jeden privilegierten Zugriff sowie Zugriffe auf und Änderungen an kritischen Konfigurationen und Backups. Protokolle sind für einen vorab festgelegten Zeitraum aufzubewahren und gegen unbefugten Zugriff und Veränderung zu schützen. Uhren sind zu synchronisieren, damit sich Protokolle verschiedener Systeme korrelieren lassen. Und das Protokollierungssystem selbst ist zu überwachen, damit sein Ausfall bemerkt wird.

Dann ist da die Uhr. Artikel 23 gibt einer erfassten Einrichtung 24 Stunden ab Kenntnis eines erheblichen Vorfalls für eine Frühwarnung, 72 Stunden für eine Meldung mit einer ersten Bewertung von Schwere und Auswirkungen und einen Monat für einen Abschlussbericht mit Ursache und ergriffenen Maßnahmen. Was ein Protokoll auch sonst ist, es muss diese drei Dokumente möglich machen.

Was DORA verlangt

DORA ist eine Verordnung, gilt also unmittelbar, und ist bei Protokollen deutlicher. Artikel 10 verlangt Mechanismen, um anomale Aktivitäten umgehend zu erkennen. Artikel 17 verlangt, dass alle IKT-bezogenen Vorfälle erfasst werden, nicht nur die schwerwiegenden. Der technische Standard, der den Rahmen für das Risikomanagement ausfüllt, hat einen Artikel, der schlicht „Protokollierung“ heißt. Er verlangt von Finanzunternehmen, festzulegen, welche Ereignisse protokolliert werden und wie lange, Protokollierungssysteme und die Protokolle selbst gegen Manipulation, Löschung und unbefugten Zugriff zu schützen, Ausfälle des Protokollierungssystems zu erkennen und Uhren gegen eine dokumentierte Referenz zu synchronisieren. Die Aufbewahrung ist keine feste Zahl. Sie ist aus dem Zweck des Protokolls und der eigenen Risikobewertung abzuleiten und schriftlich festzuhalten.

Die Uhr von DORA läuft schneller als die von NIS2. Eine Erstmeldung eines schwerwiegenden Vorfalls ist innerhalb von vier Stunden nach seiner Einstufung als schwerwiegend fällig, spätestens 24 Stunden nach Kenntnis. Ein Zwischenbericht folgt innerhalb von 72 Stunden nach der Erstmeldung, ein Abschlussbericht einen Monat nach dem letzten Zwischenbericht. Vier Stunden reichen nicht, um mit dem Zusammentragen von Nachweisen anzufangen. Sie reichen nur, um sie nachzuschlagen.

Eine Sache ist DORA-spezifisch. Die IKT-Dienstleister eines Finanzunternehmens fallen über den Vertrag in den Geltungsbereich der Verordnung. Artikel 30 verlangt, dass die Vereinbarung dem Unternehmen Mitwirkung bei der Bewältigung von Vorfällen und Zugang zu den nötigen Informationen zusichert. Für ein Produkt wie unseres heißt das: Das Audit-Protokoll Ihres Tenants ist Ihr Nachweis, für Sie verfügbar, ohne ein Ticket bei uns.

Vier Dinge, die beide Gesetze wollen

Zusammen gelesen laufen die beiden Regelwerke auf vier Forderungen hinaus. Sie sind eine bessere Checkliste als jede Feldliste.

1. Die richtigen Ereignisse. Wer sich angemeldet hat und wer daran gescheitert ist, wer angelegt, geändert oder entfernt wurde, wer Zugriff worauf bekommen hat und von wem, wer ihn entzogen hat, wer heruntergeladen hat, wer eine Sicherheitseinstellung geändert hat. Menschen und Maschinenkonten gleichermaßen.
2. Integrität. Ein Protokoll, das sich spurlos bearbeiten oder kürzen lässt, ist kein Nachweis. Beide Regelwerke nennen Manipulation und Löschung als die Bedrohungen, gegen die zu schützen ist.
3. Eine entschiedene Aufbewahrung. Nicht „für immer“ und nicht „was die Datenbank eben hält“. Ein Zeitraum, aus einem Grund gewählt, mit einer Löschung unter Kontrolle.
4. Antworten unter Zeitdruck. Wenn die Uhr läuft, müssen Sie „Was ist mit dieser Datei passiert, wer hatte Zugriff auf diesen Ordner, was hat dieses Konto getan“ in Minuten beantworten, aus dem Produkt heraus, ohne Hilfe der Entwicklung.

Wie Sapherbox jeden Punkt beantwortet

Ereignisse. Das Audit-Protokoll erfasst 159 verschiedene Aktionen, gegliedert in achtzehn Kategorien, so dass ein Administrator es ohne Legende lesen kann. Authentifizierung und Konten: Anmeldung, Abmeldung, fehlgeschlagene Versuche, Sperrungen, Leerlauf-Timeouts, Widerruf von Sitzungen, Passwortänderungen und -zurücksetzungen, SSO-Verknüpfung und -Anmeldung, Registrierung von MFA und Passkeys. Nutzerverwaltung: Konten angelegt, deaktiviert und gelöscht, Rollen geändert, Kontingente und Zugriffskontrollen gesetzt. Dateien und Ordner: Uploads, Downloads, Umbenennungen, Verschiebungen, Löschungen, Wiederherstellungen und endgültige Löschungen. Teilen: jede Freigabe und jeder Entzug, Änderungen von Gruppenmitgliedschaften, Download-Links erstellt, aufgerufen und widerrufen, Upload-Links erstellt und widerrufen, Einladungen versandt und abgeschlossen. Einstellungen: jede Änderung einer Sicherheitseinstellung, unter Nennung der geänderten Einstellung. Service-Accounts und API-Schlüssel angelegt und gelöscht. Änderungen an der Escrow-Konfiguration und von Administratoren durchgeführte Kontowiederherstellungen. Die tägliche Aufbewahrungsbereinigung selbst. Aktionen über einen API-Schlüssel werden dem Service-Account zugerechnet, der ihn hält, so dass ein maschineller Akteur ebenso sichtbar ist wie ein Mensch.

Jeder Eintrag trägt Akteur, Aktion, Ressource, den von der Datenbank aufgezeichneten Zeitpunkt und die Details der Aktion. Die Aufzeichnung der Client-IP-Adresse ist ein Schalter, den der Administrator einschaltet, denn für viele Tenants ist die Adresse ein personenbezogenes Datum, das sie lieber nicht aufbewahren. Datei- und Ordnernamen sind im Protokoll maskiert, wie in Was unsere Server sehen können und was nicht beschrieben. Der Server hatte die Inhalte nie, also kann das Protokoll sie auch nicht enthalten. Das ist der Sinn des Produkts, keine Lücke im Protokoll.

Integrität. Jeder Eintrag ist mit dem vorherigen über eine HMAC-SHA-256-Kette verbunden, deren Schlüssel die Datenbank nie sieht. Die Rolle, mit der die Anwendung arbeitet, kann Einträge einfügen und lesen, aber weder ändern noch löschen. Ein Administrator prüft die gesamte aufbewahrte Kette mit einem Knopfdruck oder per API, und ein Bruch wird als Sicherheitsvorfall gemeldet, unter Nennung des ersten Eintrags, der nicht mehr stimmt. Den Entwurf haben wir in Ein Audit-Protokoll, das sich nicht unbemerkt ändern lässt beschrieben. Für eine DORA- oder NIS2-Akte ist dieser Artikel die Antwort auf „Wie sind Protokolle gegen Manipulation und Löschung geschützt“.

Aufbewahrung. Die Aufbewahrung ist eine Tenant-Einstellung, standardmäßig 365 Tage. Ältere Einträge werden täglich bereinigt, und die Bereinigung ist selbst ein auditiertes, verkettetes Ereignis, das den neuen Anker der Kette und die Zahl der entfernten Einträge festhält. Der gewählte Zeitraum und seine Begründung gehören in Ihre Richtlinie. Das Produkt setzt ihn durch und zeigt, dass es das getan hat.

Antworten unter Zeitdruck. Die Audit-Seite filtert nach Aktion und Freitext. Jede Datei und jeder Ordner hat eine eigene Audit-Ansicht, so dass „Was ist mit diesem Dokument passiert“ einen Klick vom Dokument entfernt ist. Der Zugriffsbericht listet für alles, was Ihnen gehört, wer Zugriff hat und auf welcher Stufe. Das ist der schnellste Weg, einen Vorfall mit einem kompromittierten Konto einzugrenzen. Massenaktivität wird gemeldet, während sie passiert: Lädt ein Konto innerhalb kurzer Zeit mehr als eine Schwellenzahl von Dateien herunter oder hoch, erhalten die Administratoren sofort eine Alarm-E-Mail, statt das Muster eine Woche später im Protokoll zu finden. Die Schwellen sind Einstellungen. Der CSV-Export schreibt das aufbewahrte Protokoll oder einen gefilterten Teil davon in eine Datei für die Vorfallsakte.

Wo die Lücken sind

Sapherbox schickt keine Einträge an Ihr SIEM. Beide Gesetze erwarten, dass Sie Protokolle systemübergreifend korrelieren, und die Durchführungsverordnung erwartet, dass das Protokollierungssystem unabhängig überwacht wird. Der Export ist eine Datei, die Sie herunterladen, kein Datenstrom. Ein geplanter Export sowie ein nativer Syslog- oder Webhook-Versand stehen auf der Roadmap. Bis dahin ist ein skriptgesteuerter Abruf über die API der Weg, eine externe Kopie aktuell zu halten, und wir helfen beim Aufbau dieser Anbindung an Ihr SIEM.

Für die Compliance-Akte

Falls Ihr Prüfer die Fassung in einem Absatz möchte: Das Audit-Protokoll des Tenants erfasst Authentifizierungs-, Konto-, Zugriffs-, Freigabe-, Übertragungs- und Konfigurationsereignisse für menschliche und maschinelle Akteure. Die Einträge sind per HMAC verkettet, mit einem Schlüssel außerhalb der Datenbank, und können von der Anwendungsrolle nicht verändert werden. Die Kette ist auf Abruf prüfbar. Die Aufbewahrung ist ein konfigurierter Zeitraum, dessen Durchsetzung selbst protokolliert wird. Ansichten je Ressource, Filter, Alarme bei Massenaktivität und ein Export unterstützen die Vorfallsmeldung innerhalb der Fristen von NIS2 und DORA. Und das Protokoll gehört dem Tenant und ist ohne Mitwirkung des Anbieters zugänglich. Die lange Fassung ist dieser Artikel und die beiden verlinkten.

Fragen?

Wenn Sie Ihre NIS2- oder DORA-Kontrollen abbilden und unsere Antworten im Format Ihres Fragebogens brauchen, schreiben Sie uns an hello@sapherbox.com.