Prüfung & AuditAudit-Kette (immudb)

Audit-Kette (immudb)

immudb ist eine Append-only-Datenbank mit kryptographischer Merkle-Verkettung. Jeder relevante Schreibvorgang in Craken hängt einen Eintrag an die Kette an — niemand kann nachträglich Einträge verändern, ohne dass der Hash-Anker bricht.

Was kommt in die Kette?

Nicht in der Kette: rein lesende Aktionen (Liste anzeigen, Beleg öffnen) — das wäre zu viel Lärm und ist über Loki-Logs ohnehin verfügbar.

Entry-Struktur

Jeder Eintrag hat dieselbe Form:

{
  "event_id":   "uuid-...",
  "occurred_at": "2026-06-19T10:42:00Z",
  "actor":      "user:chris@scaleix.de",
  "action":     "Beleg.StateChange",
  "document_id": "uuid-...",
  "decision_inputs_hash":  "sha256-...",
  "resulting_state_hash":  "sha256-...",
  "payload_ref": "s3://audit-payloads/...",
  "metadata":    { /* freie Felder pro Action */ }
}

Bei großen Payloads (z. B. einem JSON-Snapshot) wird nur der Hash gespeichert; der vollständige Snapshot liegt in MinIO unter payload_ref. So bleibt die Kette schlank, aber jede Aussage ist mit einem konkreten Dokument-Stand verknüpft.

Verifikation eines einzelnen Eintrags

Die VerifiableGet-Operation gibt nicht nur den Wert zurück, sondern auch den Merkle-Proof — der Auditor kann mathematisch nachweisen, dass der Eintrag Bestandteil der Kette zum Zeitpunkt X war.

Anker-Snapshots

Beim GoBD-Export wird der aktuelle Stand der Kette als “Anker-Snapshot” mit eingepackt:

{
  "database": "defaultdb",
  "tx_id":    1247831,
  "tx_hash":  "sha256-...",
  "captured_at": "2026-06-19T11:00:00Z"
}

Mit dieser Information kann ein Steuerprüfer auch Jahre später beweisen, ob ein bestimmter Eintrag schon zum Export-Zeitpunkt in der Kette war (oder nachträglich entstanden ist).

Was ist nicht in immudb?

  • Original-Belege — die liegen in MinIO; immudb speichert nur ihre Hashes (und damit den Beweis der Unveränderlichkeit).
  • Lieferanten-Stamm-Snapshots — die DB ist mutabel; immudb-Einträge verweisen via resulting_state_hash auf den Stand nach der Änderung.

Provider-Wahl

immudb läuft als Container-Service Teil des Kraken-Stacks; es gibt keine externe Abhängigkeit. Wartung ist auf periodisches Backup (über den selben restic-Pfad wie Postgres) und gelegentliches compact (manuelle Operation, im Backlog).