fix(audit): GET_LOCK-Ergebnis prüfen, connector/ip in Hash-Kette

Zwei vom Nacht-Agenten gefundene Lücken, gegen den echten Code
verifiziert und behoben:

1. Das Ergebnis von GET_LOCK() wurde nie geprüft. Bei Timeout (10s)
   oder Fehler lief audit() trotzdem ungesperrt weiter – zwei
   gleichzeitige Aufrufe hätten dieselbe "letzte Zeile" lesen und
   beide anhängen können, was die Kettengarantie bricht. Wirft jetzt
   einen Fehler, wenn die Sperre nicht erlangt wurde.

2. connector und ip wurden zwar in audit_events gespeichert, aber nie
   mitgehasht – beide Felder ließen sich im Nachhinein unbemerkt
   ändern, ohne die Kette zu brechen. Neue Einträge (hash_version = 2,
   Migration 030) hashen sie jetzt mit. Bestehende Einträge (Version 1)
   bleiben mit ihrer ursprünglichen Formel gültig; verifyAuditChain()
   berücksichtigt die Version pro Zeile.

Gegen die echte Datenbank verifiziert: Kette bleibt über alle 183
bestehenden (v1) Einträge sauber, ein neu eingefügter (v2) Eintrag mit
connector/ip ebenfalls – 184/184 ohne Bruch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Kundencenter 2026-09-29 09:56:46 +02:00
parent 4976fc529e
commit acf8751f9f
2 changed files with 19 additions and 9 deletions

View file

@ -0,0 +1,6 @@
-- Behebt zwei vom Nacht-Agent gefundene und verifizierte Lücken in der Audit-Hash-Kette:
-- 1) Das Ergebnis von GET_LOCK() wurde nie geprüft (bei Timeout/Fehler lief die Kette ungesperrt weiter).
-- 2) connector/ip wurden zwar gespeichert, aber nie mitgehasht (im Nachhinein unbemerkt änderbar).
-- Neue Einträge (hash_version = 2) hashen connector/ip mit; bestehende Einträge (Version 1) bleiben mit
-- ihrer ursprünglichen Formel gültig, damit die Kette rückwärtskompatibel bleibt.
ALTER TABLE audit_events ADD COLUMN hash_version TINYINT UNSIGNED NOT NULL DEFAULT 1;