Audit-Kette
Jede sicherheitsrelevante Aktion, kryptografisch verkettet. Manipulationssicher per Konstruktion.
HMAC-SHA256-Zeilenverkettung, Append-only-Datenbanktrigger und eine monoton steigende Sequenz pro Mandant. Drei unabhängige Manipulationssignale im Schema verankert, nicht aufgesetzt.
WARUM DAS KEIN FEATURE IST
Unser Audit-Log ist auf Zeilenebene kryptografisch verkettet
Ein Angreifer mit vollem Schreibzugriff auf die Datenbank kann keine Zeile fälschen oder löschen, ohne Spuren zu hinterlassen. Dieselbe Hash-Ketten-Primitive, die in Blockchain-Ledgern zum Einsatz kommt, auf Zeilenebene angewendet, mit einem HMAC-Schlüssel anstelle eines Konsensprotokolls.
7 Jahre. 2.555 Tage. Jede sicherheitsrelevante Aktion jedes Nutzers, erfasst und überprüfbar.
SO FUNKTIONIERT ES
Drei Felder machen aus jeder Zeile einen Beweis
Jede Zeile in audit_logs trägt drei Schutzfelder. Die Tabelle ist unauffällig; die Disziplin liegt darin, was beim Insert berechnet und signiert wird.
sequence
Pro Mandant monoton steigende Ganzzahl. Eine Lücke in der Sequenz bedeutet, dass eine Zeile gelöscht wurde, und der Verifier markiert die erste fehlende Nummer.
prev_hash
Verweist zurück auf den row_hash der vorhergehenden Zeile. Eine gebrochene Kette bedeutet, dass eine Zeile umsortiert oder unzulässig eingefügt wurde.
row_hash
HMAC-SHA256 über die kanonische Serialisierung von {tenant_id, sequence, prev_hash, actor_id, action, resource_type, resource_id, payload, created_at}, signiert mit AUDIT_HMAC_KEY, den die Anwendung hält, nicht die Datenbank.
DREI MANIPULATIONS-SIGNALE
Was wir erkennen und wie
| Angriff | Was wir erkennen | Wie |
|---|---|---|
| Zeilenmutation | Der gespeicherte row_hash entspricht nicht mehr dem neu berechneten HMAC. | Der Verifier läuft durch die Kette und berechnet jede Zeile aus ihrer kanonischen Payload neu. |
| Zeilenlöschung | Eine Sequenzlücke tritt auf, und der prev_hash der überlebenden Zeile passt nicht mehr zu ihrem tatsächlichen Vorgänger. | Sequenzprüfung plus Kettenprüfung; jede für sich reicht zur Erkennung. |
| Zeile einfügen oder umsortieren | Die eingefügte Zeile kann keinen echten prev_hash referenzieren, sodass die Kette an der eingefügten Zeile oder der danach bricht. | Der Kettenlauf erkennt die Diskontinuität am ersten ungültigen Hash. |
VERTEIDIGUNG IN DER TIEFE
Drei Schichten, mit Absicht getrennt
Append-only-Durchsetzung
Ein PostgreSQL-Trigger blockt jedes DELETE gegen audit_logs. Löschen ist nur in einer Transaktion möglich, die SET LOCAL app.audit_retention_cleanup = on gesetzt hat, ein Flag, das ausschließlich der Retention-Sweep hält. SET LOCAL ist transaktionsweit, das Flag wird bei Commit oder Rollback automatisch zurückgesetzt und kann nicht in spätere Statements lecken.
Schlüsseltrennung
Das HMAC-Geheimnis liegt in der Anwendungskonfiguration, nicht in der Datenbank. Ein Nur-Lese-Kompromiss der Datenbank kann keine gültigen Zeilen fälschen. Ein schreibender Kompromiss wird beim nächsten Verifier-Lauf erkannt, der mit dem HMAC-Geheimnis jede Zeile neu berechnet und Fehler als eigene Audit-Ereignisse sichtbar macht.
Unabhängigkeit des Verifiers
Der Verifier läuft die Kette jedes Mandanten Ende zu Ende durch und nutzt dafür das in der Anwendung gehaltene HMAC-Geheimnis. Seine Ergebnisse sind selbst Audit-Ketteneinträge, sodass ein deaktivierter oder übersprungener Lauf in dem Moment sichtbar wird, in dem es passiert.
WAS PROTOKOLLIERT WIRD
Jedes Ereignis, das den operativen Datensatz berührt
- 01 Alle Authentifizierungen: Login, Logout, MFA-Einrichtung, Passwortwechsel, Passwortzurücksetzung
- 02 Alle Autorisierungen: Rollenänderungen, Berechtigungserteilungen, API-Schlüssel-Erstellung und -Widerruf
- 03 Alle sensiblen Admin-Aktionen: Mandant-Einstellungen, Retention-Änderungen, RLS-Kontext-Overrides
- 04 Alle Arbeitsauftrags-Abzeichnungen, mit dem SHA-256 der Signatur-Payload
- 05 Alle Abonnement- und Billing-Ereignisse: Webhook-Empfang, Planwechsel, Customer-Portal-Session
- 06 Alle Änderungen der Ingest-Quellen-Konfiguration
- 07 Alle Änderungen der SSO-Konfiguration
- 08 Alle Exports: CSV, PDF, geplante Berichtsversände
- 09 Alle Bulk-Löschungen und Right-of-Erasure-Verfahren
AUFBEWAHRUNG
2.555 Tage. Unabhängig von der operativen Aufbewahrung.
RetentionConfig.AUDIT_LOG_DAYS hält die Kette sieben Jahre. Tenant.data_retention_days ist darauf ausgelegt, operative Daten separat zu steuern, sodass Maschinentelemetrie in einem konfigurierbaren Fenster gelöscht werden kann, während die Audit-Kette das SOC-2-CC2.2-Beweisfenster und finanznahe Aufbewahrungsnormen weiterhin abdeckt.
COMPLIANCE-ABBILDUNG
Worauf die Kette antwortet
SOC 2 CC6.1 & CC7.2
Manipulationssichere Protokollierung und die Beweiskette für Change Management. Die Kette ist das, was Ihr SOC-2-Auditor während der Beobachtungsperiode durchgeht, um CC6.1 (logischer Zugriff) und CC7.2 (Systemüberwachung) zu erfüllen.
ISO 27001 A.12.4
Ereignisprotokollierung und Integrität der Bediener-Logs. Jede Administratoraktion und Ausnahme landet auf der Kette mit Zeitstempel, Attribution und der kanonischen Payload, auf die reagiert wurde.
FDA 21 CFR Part 11 §11.10(e)
Sichere, computer-generierte, zeitgestempelte Audit-Trails für elektronische Datensätze. Jedes signierte Ereignis ist attributierbar, gleichzeitig, original, genau und zeitgestempelt, was Kunden bei der 21-CFR-Part-11-Validierung unterstützt.
DSGVO Artikel 30
Verzeichnis von Verarbeitungstätigkeiten. Ihr DSB kann auf Abruf einen mandantenbezogenen Audit-Auszug ziehen. Personenbezogene Daten in audit_logs beschränken sich auf Nutzer-IDs und IP-Adressen; reichere Payloads tragen nur den Mindestkontext, der zur Rekonstruktion des Ereignisses nötig ist.
EU-NIS2-Richtlinie
Beweise für die Vorfalluntersuchung. CSIRTs der Mitgliedstaaten und Ihr eigenes Forensik-Team können exakt rekonstruieren, wer wann was getan hat, mit einer Kette, deren Integrität nicht vom DB-Administrator-Vertrauen abhängt.
DER VERIFIER
Auditprotokollierte Audit-Verifikation
Die Kettenverifikation rechnet jede Zeile aus der kanonischen Payload mit dem HMAC-Schlüssel des Mandanten neu nach und liefert PASS mit der Zeilenanzahl oder FAIL bei der ersten gebrochenen Sequenznummer. Die Ergebnisse des Verifiers sind selbst Audit-Ketteneinträge.
Kadenz
Aktuell on demand über den Admin-Verifier-Endpunkt. Geplante tägliche Verifikation kommt mit der Plattform-GA-Release.
Ergebnis
PASS mit Zeilenanzahl, oder FAIL mit der ersten Sequenznummer, an der die Kette brach. Die Zeile selbst bleibt als Beweis erhalten.
Quelle
Der Verifier-Quellcode steht Ihrem Auditor zum Durchgehen zur Verfügung. Wir sitzen mit im Raum, wenn er es tut.
WARUM DAS BESSER IST ALS „WIR HABEN AUDIT-LOGS"
Standard-Audit-Logs überstehen einen entschlossenen Operator nicht
Einfache Audit-Tabelle
Append-freundlich, aber veränderbar. Jeder mit Schreibzugriff kann eine Zeile ändern, eine Zeile entfernen oder eine einfügen. Kein mathematisches Signal, dass es passiert ist.
WORM-Speicher
Hilft gegen Löschen, weniger gegen Einfügen oder Umsortieren. Speicher-Integrität fängt eine Zeile nicht ab, die nie hätte da sein dürfen.
Hash-verkettetes Log (das hier)
Mathematisch manipulationssicher. Erkennt Mutation, Löschung und Einfügen auf Zeilenebene, mit dem Parent-Hash als Integritätsanker.
HÄUFIG GEFRAGT
Was passiert, wenn ein Hash nicht passt?
Der Verifier liefert FAIL mit der ersten Sequenznummer, an der die Kette brach. Die Zeile wird nicht gelöscht, wir behalten den Beweis. Der Fehlschlag wird als eigener Ketteneintrag erfasst und über den Incident-Pfad der Plattform sichtbar.
Kann der Datenbankadministrator die Kette manipulieren?
Nicht ohne (a) den Append-only-Trigger zu brechen, (b) das HMAC-Geheimnis zu erlangen, das außerhalb der Datenbank liegt, und (c) jede nachfolgende Zeile für den betroffenen Mandanten neu zu schreiben. Alle drei Schritte würden selbst forensische Spuren hinterlassen.
Können Sie eine Zeile für das DSGVO-Recht auf Löschung entfernen?
Personenbezogene Daten in audit_logs sind bereits auf user_id und IP minimiert. Das Recht auf Löschung auf dem Nutzerdatensatz entfernt die Audit-Historie nicht, da diese Verarbeitung auf Art. 6(1)(c) rechtliche Verpflichtung und (f) berechtigtem Interesse beruht. Wir können die user_id-Referenz pseudonymisieren, wenn Ihr DSB es verlangt.
Verlangsamt die Kette die Schreibvorgänge?
Jedes Insert berechnet einen HMAC und liest eine vorherige Zeile, beides indiziert. Vernachlässigbarer Aufwand bei typischen Workloads, und der Verifier läuft außer Reihe.
