sysopsandClaude Sonnet 5
4de9310213
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
3.7 KiB
AUD-06 – Audit-Log-Verdrahtung in sicherheitsrelevante Core-Handler
Welle 8. Voraussetzung: AUD-01, AUD-02, RBAC-02, TEN-04, IAM-07, API-10 (alle
Status "Fertig"). Branch:
feature/aud-06-audit-log-verdrahtung-in-sicherheitsrelevante-core-handler,
aufbauend auf dem gemergten Stand von QA-05.
Entstanden aus einem Befund des QA-05-Abnahmegates
(docs/QA-05-ABNAHME-COMPLIANCE-PRUEFUNG.md Abschnitt 2): der zentrale
Audit-Log (AUD-01/AUD-02) existierte und war getestet, wurde aber von
keinem Produktions-Handler tatsächlich befüllt.
Umsetzung
Additive WithAudit(...)-Methode je betroffenem Store (Konvention aus
internal/lockout.Store.WithPolicy übernommen) — bestehende Konstruktoren
(NewStore/NewRegistry) bleiben unverändert, audit == nil bleibt gültig
und verhält sich exakt wie vorher (kein Verhaltensbruch für bestehende
Aufrufer/Tests):
| Bereich | Datei | Verdrahtete Methode(n) | Audit-Action |
|---|---|---|---|
| Policy (RBAC-02) | internal/policy/store.go |
Grant, Revoke |
policy.grant / policy.revoke |
| Tenant-Lifecycle (TEN-04) | internal/tenant/registry.go, lifecycle.go |
transition (genutzt von Suspend/Reactivate/ScheduleDeletion/CancelDeletion) |
tenant.transition |
| Lockout (IAM-07) | internal/lockout/lockout.go |
RecordFailure, Unlock |
auth.login_failed / auth.account_locked / auth.account_unlocked |
| KEK-Rotation (API-10) | internal/kek/store.go |
RotateTenantKEK, RotateMasterKey |
kek.tenant_rotated / kek.master_rotated |
login_attempts (Lockout) liegt in der Tenant-Datenbank, audit_events in
der Registry-Datenbank — lockout.Store.WithAudit nimmt daher zusätzlich
zum *audit.Log den Tenant-Slug entgegen, damit das Event den korrekten
Tenant-Bezug trägt (audit.Event.TenantSlug).
Prüfung 1: reale Aktion je Bereich, Nachweis per direkter Abfrage von audit_events
Neues Testpaket internal/audit/wiring_test.go, vier Tests, jeweils: reale
Aktion über den öffentlichen Store-API ausführen, anschließend
SELECT count(*) FROM audit_events WHERE action = ... AND target = ...
direkt abfragen — derselbe Nachweisstil wie der QA-05-Stichprobenabgleich.
| Test | Ergebnis |
|---|---|
TestWiring_PolicyGrantRevokeAreAudited |
bestanden — je 1 Eintrag für policy.grant/policy.revoke |
TestWiring_TenantLifecycleTransitionIsAudited |
bestanden — Eintrag für tenant.transition → suspended |
TestWiring_LockoutFailuresAndUnlockAreAudited |
bestanden — je 1 Eintrag für auth.login_failed, auth.account_locked, auth.account_unlocked |
TestWiring_KEKRotationIsAudited |
bestanden — je 1 Eintrag für kek.tenant_rotated, kek.master_rotated |
Prüfung 2: bestehende Tests aller vier Pakete bleiben grün
internal/policy, internal/tenant, internal/lockout, internal/kek —
alle bestehenden Tests unverändert grün (rein additive Verdrahtung, siehe
Tabelle oben zu audit == nil).
Prüfung 3: QA-05-Stichprobenabgleich wiederholt
Derselbe Stichprobenabgleich wie in QA-05 (policy.Store.Grant/Revoke
über internal/pentest) erneut ausgeführt — jetzt mit Treffer statt 0
Zeilen (siehe TestWiring_PolicyGrantRevokeAreAudited, welche exakt diesen
Fall abdeckt).
Build/Test-Ergebnis
go build ./... / go vet ./... -> clean
go test ./... -p 1 -count=1 -> 51/51 Pakete ok, 0 Fehlschläge
Gesamtergebnis
Bestanden. Alle drei Akzeptanzkriterien und alle drei Pflichtprüfungen
erfüllt. Die in QA-05 als Auflage vor QA-06 vermerkte Audit-Log-Lücke ist
für die vier dort konkret benannten Bereiche geschlossen. Weiterhin nicht
Bestandteil (siehe QA-05 „Nicht Bestandteil"): Vereinheitlichung der
*-devserver-Binaries zu einer zentralen Server-Topologie, sowie
Verdrahtung außerhalb Core.