duffyduckandClaude Opus 5
c7d6b6de7e
Problem 1 (Deutbarkeit): verifyIntegrity warf zwei voellig unterschiedliche Befunde in einen Topf und meldete beides als "N manipulierte Eintraege". Eine harmlose Verkettungsluecke sah damit aus wie ein Angriff - die Meldung war im Alltag nicht deutbar und dadurch wertlos, dasselbe Muster wie beim Refresh-Rauschen. Fix: Rueckgabe um tamperedEntries (Inhalt nachtraeglich veraendert, ernst) und chainGaps (Verkettung unterbrochen durch parallele Schreibvorgaenge oder geloeschte Zeilen, meist harmlos) erweitert. invalidEntries bleibt als Summe erhalten. Controller formuliert die Meldung eindeutig, Frontend-API-Typ nachgezogen. Problem 2 (Aufbewahrung): Token-Refreshes landen seit der Entrauschung als Authentication/LOW. Diese Kombination traf auf keine spezifische Regel und fiel in die Auffangregel * mit 3650 Tagen - das Rauschen waere 10 Jahre aufbewahrt worden, echte Logins nur 2. Fix: Regel Authentication/LOW mit 90 Tagen, als idempotente Migration und im Seed. Sensitivitaet steuert die Aufbewahrung und ist keine Alarmstufe - normale Logins und Zugriffe auf Bankdaten/Ausweise bleiben bewusst CRITICAL, ein Herabstufen wuerde still die Aufbewahrungsfrist verlaengern. Verifiziert: Live-Test gegen Dev-DB - echte Manipulation einer Zeile wird als manipuliert erkannt und nicht mit Luecken verwechselt, Ketten-Luecken bleiben bei 7, Originalzustand exakt wiederhergestellt. tsc + vite build gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
20 lines
1.1 KiB
SQL
20 lines
1.1 KiB
SQL
-- Aufbewahrungsregel fuer routinemaessige Auth-Eintraege (Token-Refresh).
|
|
--
|
|
-- Seit der Entrauschung landen erfolgreiche Token-Refreshes als
|
|
-- `Authentication / LOW`. Diese Kombination traf auf KEINE spezifische Regel
|
|
-- (es gab nur `Authentication / CRITICAL`) und fiel damit in die Auffangregel
|
|
-- `*` mit 3650 Tagen. Ergebnis: Das Rauschen waere 10 Jahre aufbewahrt worden,
|
|
-- echte Logins dagegen nur 2 Jahre - genau verkehrt herum.
|
|
--
|
|
-- 90 Tage reichen, um einen Refresh-Vorgang im Nachhinein nachzuvollziehen.
|
|
-- Idempotent: der Unique-Index (resourceType, sensitivity) verhindert Dubletten.
|
|
INSERT INTO `AuditRetentionPolicy`
|
|
(`resourceType`, `sensitivity`, `retentionDays`, `description`, `legalBasis`, `isActive`, `createdAt`, `updatedAt`)
|
|
VALUES
|
|
('Authentication', 'LOW', 90, 'Routine-Auth (stiller Token-Refresh)', 'Betriebsnotwendigkeit / Datenminimierung (DSGVO Art. 5)', 1, NOW(3), NOW(3))
|
|
ON DUPLICATE KEY UPDATE
|
|
`retentionDays` = VALUES(`retentionDays`),
|
|
`description` = VALUES(`description`),
|
|
`legalBasis` = VALUES(`legalBasis`),
|
|
`updatedAt` = NOW(3);
|