Supply-Chain-Scan (Go) / govulncheck (push) Canceled after 0s
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
75 lines
3.7 KiB
Markdown
75 lines
3.7 KiB
Markdown
# 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.
|