Manipulationssichere Audit-Logs ohne Serverpark

Audit-Trails stehen und fallen mit einer Frage: Kann jemand nachträglich etwas ändern, ohne dass es auffällt? Wir haben für unser internes Werkzeug tseit ein Log-Format gebaut, das diese Frage mit Bordmitteln beantwortet — eine SHA-256-Hash-Chain über Append-Only-JSONL, schlank genug für eine einzelne Workstation, streng genug für ein Compliance-Audit.

Das Problem

Wer Tätigkeiten, Zeiten oder Systemereignisse protokolliert — für die eigene Nachweisbarkeit, für DSGVO-taugliche Zeiterfassung oder für ein Compliance-Audit — hat mit gewöhnlichen Logfiles ein strukturelles Problem: Eine Textdatei beweist nichts. Jeder mit Schreibzugriff kann Einträge ändern, löschen oder umsortieren — und das Ergebnis sieht anschließend genauso glaubwürdig aus wie das Original. Kommerzielle Lösungen beantworten das meist mit Infrastruktur: zentrale Server, WORM-Storage, signierte Datenbank-Appliances. Für ein Projektportfolio auf einer einzelnen Workstation ist das die falsche Gewichtsklasse.

Das Design

Jedes Projekt bekommt eine eigene Kette von Ereignis-Einträgen, gespeichert als Append-Only-JSONL: eine Datei pro Erfassungszeitraum, ein JSON-Objekt pro Zeile, genau sieben Pflichtfelder. Zwei davon tragen die Kette: prev_hash und chain_hash.

chain_hash_n  = SHA256( canonical_payload_n || prev_hash_n )
prev_hash_n+1 = chain_hash_n
prev_hash_0   = "0" × 64

Der Hash läuft über eine kanonische Serialisierung des Eintrags: Schlüssel lexikographisch sortiert, kompakteste Schreibweise (ohne Whitespace), UTF-8 unverändert (Umlaute und Sonderzeichen gehen so in den Hash ein, wie sie auf der Platte stehen). Das klingt nach Detail, ist aber der Kern: Erst die eindeutige kanonische Form macht den Hash reproduzierbar — und erst der reproduzierbare Hash macht die Verifikation möglich.

Die Verifikation ist entsprechend schlicht: alle Einträge lesen, jeden Hash nachrechnen, jede Verkettung prüfen. Läuft in Sekundenbruchteilen über Monate von Einträgen.

Was garantiert ist — und wo die Grenze liegt

Der Verifier erkennt zuverlässig:

• Feld-Manipulation — jede byte-genaue Änderung eines Eintrags bricht dessen Hash,
• Hash-Fälschung — ein nachgerechneter chain_hash entlarvt den geforgten,
• Löschung eines Eintrags mitten in der Kette — der Nachfolger verweist ins Leere,
• Umsortierung — jede Vertauschung bricht die Verkettung.

Und jetzt der Teil, der seriöse Dokumentation von Produktbroschüren unterscheidet: Für das Erkennen abgeschnittener jüngster Einträge am Kettenende braucht es einen externen Anker — eine verkürzte Kette ist in sich konsistent. Ein signierter Git-Commit, der auf den jeweils letzten chain_hash zeigt, schließt diese Lücke; wir haben ihn bewusst in eine spätere Ausbaustufe verschoben und die Grenze in der Format-Spezifikation festgehalten. Genau diese Transparenz ist ein Asset: Wer präzise weiß, was der Mechanismus abdeckt, kann die knappe Ressource menschlicher Prüf-Aufmerksamkeit gezielt auf die verbleibende Lücke richten — Prüfarbeit wird planbar und messbar produktiver.

Drei Entscheidungen, die sich bewährt haben

Erstens: Das Format-Modul ist reine Standardbibliothek. Was Beweischarakter haben soll, verdient ein Fundament mit der Halbwertszeit der Sprache selbst statt der eines Dependency-Baums — jede Python-Installation der nächsten Jahre kann diese Dateien lesen und verifizieren.

Zweitens: Vertrauliche Bereiche sind auf Architektur-Ebene getrennt. Projekte mit Vertraulichkeitsanforderungen schreiben in vollständig isolierte Vaults mit eigener Kette. Die Trennung ist als harte Invariante im Code durchgesetzt — eine Fehlkonfiguration stoppt den Lauf mit einem klaren Fehler, und die Daten bleiben dort, wo sie hingehören. Isolation als Architektur-Eigenschaft statt als UI-Hinweis.

Drittens: Werkzeugwahl nach Bedrohungsmodell. Verteilte Konsensmechanismen lösen das Problem, dass sich gegenseitig misstrauende Parteien auf einen gemeinsamen Zustand einigen müssen. Unser Szenario ist deutlich einfacher — eine Partei, eine Workstation. Eine lokale Hash-Chain plus perspektivisch ein signierter Anker leistet hier dasselbe wie eine Blockchain, bei einem Bruchteil der Komplexität.

Warum das mehr ist als ein Zeiterfassungs-Feature

Schreibschutz ist gut — append-only ist besser. Vertrauen ist gut — verifiable Hash-Chain ist besser. Marketinggarantien sind Geschmackssache, dokumentierte Grenzen sind gelebtes Risikomanagement. Diese Denkweise trägt unsere Compliance-Arbeit generell: Auditierbarkeit ist eine Architektur-Eigenschaft, die man von Zeile eins an einbaut — und die sich in jeder späteren Prüfung auszahlt. Das Format ist mit über 200 Tests abgesichert, darunter je ein dedizierter Test pro forensischer Garantie — inklusive der Fälle, in denen die Verifikation fehlschlagen muss.