Auditierbarkeit & Nachvollziehbarkeit
Auditierbarkeit ist kein Feature, das man am Ende hinzufügt. Es ist eine Architektur-Entscheidung, die von Anfang an getroffen werden muss.
Was Auditierbarkeit erfordert
Abschnitt betitelt „Was Auditierbarkeit erfordert“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.
Frontend-Spezifisches
Abschnitt betitelt „Frontend-Spezifisches“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
Event-basierte Architektur als Lösung
Abschnitt betitelt „Event-basierte Architektur als Lösung“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 }Technologische Souveränität
Abschnitt betitelt „Technologische Souveränität“Auditierbare Systeme müssen vollständig im eigenen Einflussbereich liegen. Audit-Logs in US-Cloud-Diensten erfüllen regulatorische Anforderungen oft nicht.