Bitemporaler Event-Store: wie eine unveränderliche Historie funktioniert
Ein bitemporaler Event-Store speichert jede Beobachtung als unveränderliches, zeitgestempeltes Ereignis (append-only) und unterscheidet zwei Zeitachsen: wann etwas in der Wirklichkeit geschah und wann es im System erfasst wurde. Eine zusätzliche Hash-Kette macht nachträgliche Manipulationen erkennbar — allerdings ausschliesslich ab dem Zeitpunkt, an dem die Kette begonnen hat, nicht rückwirkend für die Zeit davor.
- Speicherprinzip
- Append-only (nie löschen, nie überschreiben)
- Zeitachsen
- 2 (Ereigniszeit + Erfassungszeit)
- Integritätsmechanismus
- Hash-Kette
- Externe Verankerung
- OpenTimestamps (täglich) + RFC-3161-Zeitstempel (wöchentlich)
Was „append-only" und „bitemporal" bedeuten
Append-only heisst: ein einmal geschriebenes Ereignis wird nie gelöscht oder verändert — eine Korrektur wird als neues, eigenständiges Ereignis angehängt, das auf das ursprüngliche verweist. Bitemporal heisst: jedes Ereignis trägt zwei Zeitstempel — wann es in der Wirklichkeit geschah (Ereigniszeit) und wann es tatsächlich im System aufgezeichnet wurde (Erfassungszeit). Diese Trennung macht sichtbar, wenn eine Beobachtung mit Verspätung nachgetragen wurde (z.B. Offline-Erfassung im Feld, die erst später synchronisiert wird), ohne die tatsächliche Beobachtungszeit zu verfälschen.
Was die Hash-Kette beweist — und was nicht
Jedes neue Ereignis enthält den Hash-Wert seines Vorgängers. Eine nachträgliche Änderung eines früheren Ereignisses würde diese Kette sichtbar brechen. Entscheidend ist aber: dieser Mechanismus beweist Unversehrtheit nur ab dem Zeitpunkt, an dem die Kette tatsächlich zu laufen begann. Für Ereignisse, die vor dem Kettenbeginn liegen, gibt es keine nachträgliche kryptografische Garantie — eine rückwirkend berechnete Kette beweist nichts über die Vergangenheit vor ihrem eigenen Start.
Externe Verankerung
Um die Kette selbst gegen eine spätere Manipulation abzusichern, wird sie zusätzlich extern verankert: täglich über das kostenlose OpenTimestamps-Protokoll und wöchentlich über einen RFC-3161-konformen Zeitstempeldienst. Das verschiebt das Vertrauen von einer internen Behauptung zu einem extern nachprüfbaren Zeitpunkt.
Für Ihren Betrieb
In der Praxis heisst das: eine im Feld ohne Netzverbindung erfasste Beobachtung, die erst Stunden später synchronisiert wird, bleibt mit ihrer tatsächlichen Beobachtungszeit erhalten — sie wird nicht fälschlich auf den späteren Synchronisationszeitpunkt datiert.
Für die Auftraggeberin
Eine append-only-Historie ist ein starkes, aber kein absolutes Argument für Nachvollziehbarkeit — sie ersetzt keine eigene Prüfung der konkreten Beweiskraft im Einzelfall.
Was das nicht bedeutet
- Der Begriff „gerichtsfest" ist bewusst nicht Teil unserer Kommunikation (Art. 13a UWG) — ein Gericht würdigt Beweise stets frei (Art. 157 ZPO), eine technische Absicherung kann diese Würdigung unterstützen, sie aber nicht ersetzen.
- Die Hash-Kette beweist Integrität nur AB dem Kettenbeginn, nie rückwirkend für davor liegende Daten — das ist eine bewusste, ehrliche Grenze der Technologie, keine Marketingaussage.
- Ein bitemporaler Event-Store schützt vor unbemerkter nachträglicher Änderung, nicht vor einer von Anfang an falschen Erstbeobachtung.
Häufige Fragen
- Beweist eine Hash-Kette, dass Daten von Anfang an korrekt waren?
- Nein. Sie beweist nur, dass Daten seit Beginn der Kette nicht unbemerkt verändert wurden — eine von Anfang an falsche Beobachtung bleibt davon unberührt.
- Was ist der Unterschied zwischen Ereigniszeit und Erfassungszeit?
- Die Ereigniszeit ist, wann etwas in der Wirklichkeit tatsächlich geschah; die Erfassungszeit ist, wann es im System aufgezeichnet wurde. Bei Offline-Erfassung können beide deutlich auseinanderliegen.