Audit-Log

Das Audit-Log zeigt jede Zugriffsentscheidung des Systems – erlaubt und verweigert –, mit Zeitpunkt, Aktion, Ressource und Grund. Die Einträge sind verkettet; eine entfernte oder geänderte Zeile bricht die Kette sichtbar.

So geht's

Einträge ansehen

1. Öffnen Sie System → Audit-Log.
2. Lesen Sie in der Liste, wer woran was versucht hat. Neueste stehen zuerst.
3. Klicken Sie auf , um frische Einträge zu sehen.

Festlegen, was mitgeschrieben wird

1. Wählen Sie unter Was mitgeschrieben wird eine Stufe: Maximum, Standard, Minimal oder Aus.

Das Log leeren

1. Klicken Sie Log leeren.
2. Tragen Sie zur Bestätigung LEEREN ein.
3. Klicken Sie Endgültig leeren.

Gut zu wissen

• Die Stufe ändert nie, wer etwas darf. Sie regelt nur, was festgehalten wird.
• Das Umstellen selbst und jeder Zugriff über die Fernwartung werden auf jeder Stufe aufgezeichnet.
• Inhalte stehen hier nicht – nur, dass jemand ein Dokument gelesen hat.
• default_deny als Grund heißt: Keine Richtlinie hat es erlaubt.
• Zum Leeren braucht es ein eigenes Recht über die Rolle Audit-Log verwalten.

Achtung

Leeren ist kein Aufräumen, sondern ein Bruch der Kette. Für den gelöschten Zeitraum lässt sich danach weder eine Datenpanne beschreiben noch beantworten, wer worauf zugegriffen hat. Wer regelmäßig löschen will, braucht eine Aufbewahrungsfrist.

Hintergrund

Kurz (bisher)

Jede Zugriffsentscheidung, die das System getroffen hat – erlaubt und verweigert –, mit Zeitpunkt, Aktion, Ressource und Grund.

Warum es das gibt

Ein Protokoll, das nur Erfolge kennt, beantwortet die wichtigste Frage nicht: Warum durfte jemand nicht? Und ein Protokoll, das man nachträglich ändern kann, beantwortet gar keine. Die Einträge sind deshalb verkettet: Jeder trägt die Prüfsumme seines Vorgängers; eine entfernte oder geänderte Zeile bricht die Kette sichtbar.

Was in der Liste steht

Spalte	Bedeutung
Zeitpunkt	Wann entschieden wurde.
Aktion	Was versucht wurde, als Code – z. B. dokumentenmanagement.document.lesen.
Ressource	Woran, als Typ.
Kanal	standard oder partner_fernwartung – ein Zugriff aus der Fernwartung ist etwas anderes als der aus dem Haus.
Ergebnis	erlaubt oder verweigert.
Grund	Welche Policy entschied, oder default_deny – niemand hat es erlaubt.

Häufige Gründe

• default_deny – keine Policy passte. Das System erlaubt nichts, was nicht ausdrücklich erlaubt ist.
• lizenz_abgelaufen, bereich_nicht_lizenziert, modul_nicht_lizenziert – nicht die Rechte fehlen, sondern die Lizenz. Lesen und Export bleiben dabei erlaubt: Der Kunde kommt an seine Daten, gesperrt ist, was etwas verändert.

Was hier nicht steht

Inhalte. Das Protokoll sagt, dass jemand ein Dokument gelesen hat, nicht was darin stand.

Wie viel mitgeschrieben wird

Über der Liste steht, was aufgezeichnet wird. Vier Stufen, und sie unterscheiden nach Beweiswert, nicht nach Menge:

• Maximum – jede Entscheidung, auch jeder Lesezugriff. Für Häuser mit Gesundheits- oder Personaldaten: Dort ist „wer hat das gesehen” die entscheidende Frage.
• Standard – jede Abweisung und alles, was etwas verändert. Das ist die Vorgabe und deckt ab, was die DSGVO an Nachweis verlangt: die Rechenschaftspflicht und die Meldung einer Datenpanne binnen 72 Stunden.
• Minimal – nur Abweisungen. Das Sicherheitssignal bleibt, die Masse fällt weg.
• Aus – nichts. Für Entwicklungsumgebungen.

Die Stufe ändert nie, wer etwas darf. Sie regelt nur, was festgehalten wird. „Aus” macht keinen Zugriff möglich, der vorher verwehrt war.

Zwei Dinge sind auf keiner Stufe abschaltbar: das Umstellen selbst – aufgezeichnet, bevor es wirkt – und jeder Zugriff über die Fernwartung. Das Erste, weil sonst der erste Handgriff wäre, das Licht auszumachen; das Zweite, weil es eine Zusage an Sie ist und keine Einstellung.

Ist ein Protokoll Pflicht?

Kein Artikel der DSGVO verlangt es ausdrücklich. Aber drei Pflichten lassen sich ohne eines nicht erfüllen: Art. 5 Abs. 2 (die Einhaltung nachweisen, nicht nur einhalten), Art. 33 (eine Datenpanne binnen 72 Stunden melden, samt Kategorien und ungefährer Zahl der Betroffenen) und Art. 15 (Auskunft, wem Daten offengelegt wurden). Bei Gesundheitsdaten gibt es ausdrückliche Protokollpflichten.

Kurz: Abschalten ist erlaubt, aber es ist eine Entscheidung, die Sie begründen können müssen.

Das Log leeren

Möglich, aber es ist kein Aufräumen, sondern ein Bruch der Kette. Danach lässt sich für den gelöschten Zeitraum weder eine Datenpanne beschreiben noch beantworten, wer worauf zugegriffen hat.

Deshalb drei Hürden, und jede hat einen Grund:

• Ein eigenes Recht (privacy-audit.audit.loeschen), das nicht mit dem Lesen mitkommt. Auch Administratoren haben es nicht von sich aus – es hängt an der Rolle Audit-Log verwalten.
• Das Wort LEEREN muss abgetippt werden. Ein „Sind Sie sicher?” wird nach dem dritten Mal nicht mehr gelesen; etwas, das man tippen muss, lässt sich nicht versehentlich wegklicken. (Ein Wort und nicht die Anzahl: Die Zahl ändert sich, während man sie abliest – schon das Ansehen dieser Seite wird mitgeschrieben.)
• Der Bericht über die Löschung ist der erste Eintrag der neuen Kette – mit Anzahl, Zeitraum, Person und Zeitpunkt. Eine Löschung, die sich selbst verschweigt, wäre genau das, wogegen die Kette gebaut ist.

Gelöscht wird alles bis zu dem Zeitpunkt, an dem Sie den Dialog geöffnet haben – was seither dazugekommen ist, bleibt stehen. Nach dem Leeren steht deshalb nicht null da, sondern eine Handvoll: der Bericht über die Löschung und die Zugriffe, die währenddessen entstanden sind.

Wer regelmäßig löschen will, braucht in Wahrheit eine Aufbewahrungsfrist – die ist der normale Weg, das Leeren der Ausnahmefall.

Stand: 01.11.2026

Hängt zusammen mit

• Rollen
• KI-Auswertung

Stand der Texte: Netbits.Flow 0.2.0.0-beta.3 · Schlüssel privacy-audit