2 Commits

Include renames

Author	SHA1	Message	Date
sysopsandClaude Sonnet 5	4de9310213	AUD-06: audit-log-verdrahtung-in-sicherheitsrelevante-core-handler ... Schliesst die in QA-05 gefundene Luecke: der zentrale Audit-Log (AUD-01/02) existierte und war getestet, wurde aber von keinem Produktions-Handler befuellt. Additive WithAudit(...)-Methode je Store (Konvention aus lockout.Store.WithPolicy uebernommen, audit==nil bleibt gueltig, kein Verhaltensbruch fuer bestehende Aufrufer): - internal/policy.Store.Grant/Revoke -> policy.grant/policy.revoke - internal/tenant.Registry (Suspend/Reactivate/ScheduleDeletion/ CancelDeletion via transition) -> tenant.transition - internal/lockout.Store.RecordFailure/Unlock -> auth.login_failed/ auth.account_locked/auth.account_unlocked - internal/kek.Store.RotateTenantKEK/RotateMasterKey -> kek.tenant_rotated/ kek.master_rotated Neues Testpaket internal/audit/wiring_test.go: fuer jeden der vier Bereiche eine reale Aktion ausgefuehrt und per direkter audit_events-Abfrage nachgewiesen (derselbe Nachweisstil wie der QA-05-Stichprobenabgleich, der die Luecke fand). Alle bestehenden Tests der vier Pakete bleiben gruen. 51/51 Pakete gruen auf 192.168.1.131. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ	2026-08-29 17:24:26 +02:00
sysopsandClaude Sonnet 5	ac070c160a	IAM-07: account-lockout-login-rate-limiting ... internal/lockout: Store.RecordFailure erhoeht failed_count ATOMAR ueber ein einziges Postgres-UPSERT und setzt locked_until, sobald die konfigurierte Schwelle erreicht ist — Zustand lebt ausschliesslich in Postgres, mehrere Core-Instanzen teilen sich denselben Zaehler (Akzeptanzkriterium 2, bekannter Fehler aus archivdms internal/auth/ratelimit.go vermieden: kein In-Process-Zaehler). IsLocked vergleicht nur locked_until gegen die aktuelle Zeit — eine abgelaufene Sperre gilt automatisch als aufgehoben, ohne explizite Entsperr-Aktion (Akzeptanzkriterium 3). Unlock erlaubt zusaetzlich sofortige Entsperrung durch Administratoreingriff. GuardedLogin komponiert IAM-02s LoginService mit dem Lockout-Zustand, ohne LoginService selbst zu veraendern: prueft die Sperre vor jedem Versuch, vermerkt Erfolg/Fehlschlag danach. Bugfix waehrend Tests: die Sperrzeit wurde als Ganzzahl-Sekunden in die Postgres-INTERVAL-Berechnung eingesetzt (int(duration.Seconds())), wodurch Sperrzeiten unter 1 Sekunde (z.B. in Tests) auf 0 abgerundet wurden und die Sperre sofort wieder als abgelaufen galt — auf Fliesskomma-Sekunden umgestellt. Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. Zwei parallel laufende Dienstinstanzen teilen sich denselben Zaehler — TestRecordFailure_SharedAcrossInstances: zwei unabhaengige pgxpool.Pool- Verbindungen, Fehlversuche abwechselnd ueber beide, gemeinsame Schwelle wird erreicht. PASS. 2. Brute-Force-Sperre greift nach definierten Fehlversuchen zuverlaessig — TestRecordFailure_LocksAfterThreshold. PASS. 3. Zeitversatz zwischen Sperre und Entsperrung automatisiert getestet — TestIsLocked_AutoUnlocksAfterExpiry: gesperrt vor Ablauf, automatisch entsperrt nach Ablauf der Sperrzeit. PASS. Zusaetzlich: TestGuardedLogin_LocksAfterRepeatedFailures belegt das Zusammenspiel mit dem echten IAM-02-LoginService End-to-End — selbst das korrekte Passwort wird nach Sperrung abgewiesen. PASS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 22:15:25 +02:00