Audit Trail: wer tat was, wann, und warum Sie der Antwort vertrauen koennen
Wie append-only Event Logs, RLS-protected Mutation Records und Activity Log zusammen Beweise bilden, die der Auditor akzeptiert.
Ein Audit Trail, der bearbeitet werden kann, ist kein Audit Trail. Er ist ein Arbeitsdokument. Die Audit-Infrastruktur der Plattform ist so gebaut, dass der Trail nicht stillschweigend umgeschrieben werden kann — und dass das Operations-Team das beweisen kann.
Append-only Event-Tabellen
Mehrere Tabellen sind als append-only konzipiert: escrow_events, audit_events, settlement_events und einige weitere. Database Triggers lehnen UPDATE und DELETE auf diesen Tabellen ab. Neue Zeilen können eingefügt werden (ein Korrektur-Event mit Referenz auf das Original), aber die Originale bleiben bestehen. Jedes Event trägt Timestamp, Actor (user_id) und relevanten Kontext.
Activity Log
Die Seite /admin/activity ist die plattformweite Eventansicht. Sie zeigt User-Aktionen über Module hinweg: Company Edits, Contract Terminations, Role Changes, Settings Updates. Filterbar nach User, Action Type und Zeitraum. Genutzt für die Frage “wer hat das am Dienstag um 16 Uhr geändert?”, die in Incident Reviews zuverlässig auftaucht.
RLS-Schutz
Row-Level Security auf den Event-Tabellen sorgt dafür, dass selbst ein SQL-level read keine Tenant-Grenzen überschreitet — ein Tenant sieht nur seine eigenen Audit-Zeilen. Platform Admins (verifiziert über getAdminScope() mit Plattformebene) können für Cross-Tenant-Fragen tenantübergreifend sehen, aber dieser Zugriff wird selbst geloggt.
Historie pro Entität
Die meisten Entitäten zeigen ihre eigene Historie auf der Detailseite: eine Company zeigt Änderungen an Kernfeldern, ein Asset zeigt Statusübergänge und Grade-Änderungen, ein Contract zeigt Amendments. Die History View ist der Entitätsausschnitt des Audit Trails, für Menschen lesbar formatiert statt für Maschinen.
Was der Auditor prüft
Der Audit Trail beweist: Integrität (die Records wurden nicht editiert), Autorenschaft (der genannte User hat die Aktion tatsächlich ausgeführt, mit verifiziertem Login), Chronologie (Timestamps sind serverseitig, nicht vom Client geliefert) und Vollständigkeit (das Event zur Aktion existiert am richtigen Ort). Wenn alle vier halten, geht der Audit weiter zum nächsten Thema.