Zum Inhalt springen

Auditierbarkeit & Nachvollziehbarkeit

Auditierbarkeit ist kein Feature, das man am Ende hinzufügt. Es ist eine Architektur-Entscheidung, die von Anfang an getroffen werden muss.

Unveränderlichkeit von Logs: Audit-Logs dürfen nicht editierbar, nicht löschbar sein. Event-Sourcing oder immutable Append-Only-Stores sind die architektonischen Antworten.

Zeitstempel mit Kontext: Wer hat wann was getan — mit vollständigem Kontext (Session-ID, IP, Nutzer-Rolle, betroffene Entität).

Reproducibility: Kann man den Systemzustand zu einem beliebigen Zeitpunkt in der Vergangenheit rekonstruieren? Ohne das ist Auditierbarkeit nur Protokollführung.

Das Frontend ist oft der Ort, wo Audit-Trail-Lücken entstehen:

  • Formulare, die serverseitig keine vollständigen Audit-Events erzeugen
  • Optimistic Updates, die offline nichts loggen
  • Multi-Step-Workflows, die nur den Endzustand persistieren

Wenn jede Business-Aktion als Event gespeichert wird (nicht nur der resultierende Zustand), ist Auditierbarkeit inhärent. Der Event-Log ist das Audit-Log.

UserLoggedIn { userId, timestamp, ip, sessionId }
TaskStatusChanged { taskId, from, to, changedBy, timestamp }
DocumentApproved { documentId, approvedBy, timestamp, signature }

Auditierbare Systeme müssen vollständig im eigenen Einflussbereich liegen. Audit-Logs in US-Cloud-Diensten erfüllen regulatorische Anforderungen oft nicht.