Testisolation Core/Mail, Sicherheitsbehebung Phase 2a+2b, Anmeldung mit
Bearer-Token in den Oberflaechen. Alle Module bauen und testen sauber
auf 204, Token-Modus-Smoke (60 Pruefungen) mit der Haertung aus 2a/2b
bestanden, Rueckbau identisch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Readiness-Warnung (internal/health.Registry.RegisterWarning) plus
internal/mtls.GateCheck erkennen verteilten Betrieb (>1 Instanz/Host) ohne
aktives mTLS und machen das als "mtls-gate"-Warnung im Readiness-Antwort-
koerper sichtbar, ohne den Dienst als "nicht bereit" zu melden. Neue
Betriebs-Checkliste (docs/BETRIEBS-CHECKLISTE-STUFENWECHSEL.md) haelt die
mTLS-Aktivierung als Pflichtschritt beim Wechsel Stufe 1 -> Stufe 2 fest,
SKALIERUNGSKONZEPT.md verweist darauf.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Ergaenzt das aus RBAC-01 fehlende Pflichtgate: ValidateNoTenantToSuperadminEscalation
prueft Rollenhierarchie/Rechtezuordnung gegen die Invariante, dass keine
Nicht-Superadmin-Rolle (weder direkt noch geerbt) Superadmin-exklusive Rechte
erreichen kann. Vier neue Tests in internal/rbac/policy_invariant_test.go
decken die aktuelle Policy sowie zwei unabhaengig konstruierte, absichtlich
fehlerhafte Testfixtures ab (nie die produktiv genutzten parent/direct-Werte).
CI-Pflichtgate .gitea/workflows/rbac-policy-gate.yml laeuft bei jeder Aenderung
unter internal/rbac/** sowie bei jedem Pull Request. QA-03/QA-05 um den
entsprechenden Nachtrag ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Nach ALTER ROLE nexarch_test WITH CREATEROLE auf dem Testhost 131 läuft
TestRegistryRole_CannotAccessTenantDatabase durch; temporäre Testrolle
wird via t.Cleanup automatisch entfernt, manuell verifiziert. Alle 3
TEN-09-Prüfungen sind damit erfüllt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Prüfung 2 (Audit-Events für Superadmin-Lesezugriff und
Registry-Verbindungsinfo-Lesezugriff) ist grün nach sauberem
reset-test-env.sh-Lauf. Prüfung 1 bleibt offen: der Test benötigt
CREATEROLE für die Testrolle nexarch_test, um die simulierte
Registry-Rolle anzulegen; das erfordert einen separaten,
autorisierten Privilegien-Grant auf dem Testhost.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Haertet die Control-Plane-Registry als eigene Schutzzone:
- Dedizierte Postgres-Rolle nexarch_registry (ohne CREATEDB) fuer
NEXARCH_REGISTRY_DSN, getrennt von der Provisioning-Rolle nexarch_core
(deploy/install.sh). Neu angelegte Tenant-Datenbanken entziehen PUBLIC
explizit das CONNECT-Recht (internal/tenant/provisioner.go), damit die
Registry-Rolle unter keinen Umstaenden Zugriff auf eine Tenant-Datenbank
erhaelt (Akzeptanzkriterium 1).
- Auditierte Zugriffsmethoden (*AsActor) fuer Superadmin-Konten
(internal/user.SuperadminStore) und Verbindungsinformationen
(internal/tenant.Registry) — jeder lesende/schreibende Zugriff erzeugt
einen Audit-Event mit Akteur und Zeitstempel, verdrahtet in
internal/tenantadmin (TEN-05-Konsole) und cmd/core (Akzeptanzkriterium 2).
- Betriebsanleitung docs/TEN-09-REGISTRY-BETRIEB.md dokumentiert
Rollentrennung und den auf den Core-Dienst beschraenkten Netzwerkzugriff
(pg_hba.conf, listen_addresses, Firewall-Default-Policy), abgesichert
durch internal/opsdocs/registry_hardening_test.go (Akzeptanzkriterium 3).
Automatisierte Tests je Akzeptanzkriterium: internal/tenant/isolation_test.go
(negativer Zugriffstest), internal/audit/wiring_test.go
(TestWiring_SuperadminReadIsAudited, TestWiring_RegistryConnectionInfoReadIsAudited),
internal/opsdocs/registry_hardening_test.go.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
- cmd/kek-api: startet internal/kek.Handler.TenantKEKHandler (API-10),
tenantResolverAdapter bildet tenant.Registry.GetBySlug auf
kek.TenantResolver ab (nur Signatur-Anpassung)
- reines Wiring, kein Diff an internal/kek|moduleregistry|tenant
(verifiziert)
- real deployed auf 131, end-zu-ende bewiesen: echtes Modul
registriert+provisioniert, echter Tenant-KEK erzeugt, curl gegen
laufenden Dienst liefert exakt denselben KEK zurueck (byte-fuer-byte
verglichen), falsches Credential -> 403
- reale Grant-Luecke gefunden und behoben (nexarch_core auf
tenant_keks), verifiziert
Pruefungen siehe docs/API-12-PRUEFPROTOKOLL.md
- cmd/notifyprefs-api: startet internal/notifyprefs.Handler (CFG-04),
hinter auth.RequireAuth mit demselben JWT-Secret wie IAM-16
- reines Wiring, kein Diff an internal/notifyprefs/ (verifiziert)
- real deployed auf 131, cross-service-Session real bewiesen: Login
gegen account-api, dasselbe Cookie gegen notifyprefs-api verwendet ->
echtes Setzen und Lesen einer Praeferenz, ohne Cookie -> 401
- nutzt dieselbe nexarch_registry-DB wie CFG-05, Grants bereits
vorhanden
Pruefungen siehe docs/CFG-06-PRUEFPROTOKOLL.md
- cmd/rbac-admin-api: startet internal/rbac.Handler (RBAC-05), hinter
auth.RequireAuth mit demselben JWT-Secret wie IAM-16 (account-api)
- reines Wiring, kein Diff an internal/rbac/ (verifiziert)
- real deployed auf 131, cross-service-Session real bewiesen: Login
gegen account-api (Port 8099), dasselbe Session-Cookie gegen
rbac-admin-api (Port 8100) verwendet -> echte Rollenliste, ohne
Cookie -> 401
- Migrationen (role_assignments/groups) real auf tenant_acme
angewendet, reale Grant-Luecke behoben und verifiziert
- Bootstrap-Erkenntnis dokumentiert: ListRoles selbst verlangt bereits
eine Rolle mit PermManageUsers, Testnutzer daher mit direkter
DB-Bootstrap-Rolle angelegt (wie Ersteinrichtung)
Pruefungen siehe docs/RBAC-07-PRUEFPROTOKOLL.md
- internal/notifyapi.Mount (POST /notify/enqueue), reiner Wrapper um
notifyprefs.EnqueueIfAllowed (CFG-04)
- Reuse von internal/policyapi.RequireServiceToken (RBAC-06), kein
neues Provisorium, eigener Service-Token pro Endpunkt
- Tests: 401 ohne Token, Aequivalenz HTTP vs. direkter Aufruf
(aktiviert/deaktiviert), realer Fremd-Modul-Client mit echter
notification_jobs-Zeile
- real deployed auf 131 (notify-api, Port 8094), Grant-Nachverfolgung
fuer nexarch_core auf notification_preferences/notification_jobs,
end-zu-ende per curl nachgewiesen (401, job_id+skipped:false)
Pruefungen siehe docs/CFG-05-PRUEFPROTOKOLL.md
nexarch_core-Rechte auf policy_rules/policy_rule_changes real ueber
information_schema.role_table_grants verifiziert (dauerhaft, nicht von
postgres-Eigentuemerschaft abhaengig). Push zu Gitea zum Commit-
Zeitpunkt durch externen Netzwerkausfall (TCP 443/80 auf
gitea.perlbach24.de nicht erreichbar) blockiert, kein Code-Fehler -
Board-Status bleibt bis zum tatsaechlichen Push auf Backlog.
internal/policyapi: POST /authorize wrapt policy.Enforcer.Authorize
(RBAC-02) fuer physisch getrennte Module (DMS, Mail, Archive) - reiner
Wrapper, keine zweite Autorisierungslogik, 100 Stichproben beweisen
Uebereinstimmung mit dem direkten Enforcer-Aufruf. Service-Auth ueber
schlanken, timing-safe verglichenen Token statt moduleregistrys
schwererem Credential-System (unnoetige internal/flag-Abhaengigkeit,
nie mit internal/policy gemergt). Ersetzt spaeter das dokumentierte
RET-06-API-Provisorium (Archive, eigenes Folgeticket). Reale
Rechtevergabe-Luecke auf policy_rules gefunden und behoben (Tabelle
von frueherem Testlauf unter anderem Owner). Real auf 131 deployed,
beide Pfade (Allow/Deny) per curl end-to-end verifiziert.
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
Voller Merge der 15 verbleibenden Vorbedingungen (QA-07/QA-08/TEN-08/AUD-02/
API-04/OPS-03/API-06/AUD-05/API-07/LIC-05/OPS-04/OPS-05/OPS-06/IAM-15 plus
QA-03) auf den bereits gemergten Staenden von QA-02/QA-04/QA-09. Konsolidiert
alle sechs vorgelagerten Pruefgates (QA-02/03/04/07/08/09) - widerspruchsfrei,
Akzeptanzkriterium 1 erfuellt.
Echter, substanzieller Befund beim Audit-Log-Stichprobenabgleich (Pruefung
1): internal/policy.Store.Grant/Revoke, Tenant-Lifecycle-Uebergaenge,
Lockout und KEK-Rotation rufen internal/audit.Log.Record nirgends auf - der
zentrale, unveraenderliche Audit-Log (AUD-01/02) existiert und ist getestet,
wird aber von keinem Produktions-Handler tatsaechlich befuellt. Bewusst
NICHT in dieser Kachel behoben (waere Umbau vieler bestehender Pakete,
kein punktueller Fix) - dokumentiert mit Begruendung und Auflage vor QA-06.
Pruefung 2 (Vier-Augen-Gegenlesen) mangels zweiter Person nicht durchgefuehrt,
ebenfalls als Auflage vermerkt. Siehe docs/QA-05-ABNAHME-COMPLIANCE-PRUEFUNG.md.
Zwei reale Testinfrastruktur-Fehler gefunden und behoben (kein Produktions-
code): fehlender PG-Fehlercode 42723 (duplicate_function, AUD-02s
CREATE FUNCTION bei zweiter Migrationsanwendung) in der Toleranzliste der
E2E-/Pentest-Testhelfer; internal/loadtest wiederholte die aus QA-04
bekannte defer-vor-t.Cleanup-Reihenfolge-Fehlerklasse (200 liegen
gebliebene synthetische Tenant-Zeilen verfaelschten internal/migrate).
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
Voller Merge von TEN-05/IAM-08/RBAC-05/LIC-04/AUD-04/CFG-04/OPS-02 (SHL-01
bereits Bestandteil) nach feature/qa-09-barrierefreiheits-audit. WCAG-2.1-AA-
Audit ueber alle 7 Core-Frontends (15 Seiten): automatisierte Pruefung
(pa11y/HTML_CodeSniffer WCAG2AA) und automatisiertes Tastatur-Traversal
(Puppeteer) auf 192.168.1.131 durchgefuehrt, Ergebnis nach Fixes 0/15
Verstoesse, 100% Tastaturerreichbarkeit ohne Fallen.
Vier reale WCAG-Verstoesse gefunden und behoben: ungueltiger
autocomplete="username" auf type="email"-Feldern (account, 2 Seiten) sowie
fehlende zugaengliche Namen auf Filter-/Eingabefeldern in audit-log,
lic-admin und tenant-admin (aria-label ergaenzt).
Zusaetzlich ein realer Testinfrastruktur-Fehler in internal/adminapi
gefunden: lichandler_test.go's Cleanup rief `DELETE FROM tenant_licenses
WHERE tenant_id = $1` OHNE das $1-Argument auf (Fehler durch `_, _ =`
verschluckt) - die Tenant-Zeile blieb dadurch ueber eine FK-Constraint
dauerhaft haengen und verfaelschte internal/migrate im vollen Testlauf,
analog zu den in QA-04 gefundenen defer/t.Cleanup-Bugs. Nur Testcode
betroffen.
Ein Restbefund terminiert: echter Bildschirmleser-Durchlauf (NVDA/
VoiceOver) steht mangels grafischer Testumgebung noch aus, Frist vor QA-05
(siehe docs/QA-09-BARRIEREFREIHEITS-AUDIT.md Abschnitt 5).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
Voller Merge von RBAC-02/IAM-06/IAM-07/API-03/API-10/API-08/API-09/IAM-10/
IAM-11/IAM-13 plus echte Angriffstests (internal/pentest) gegen SSO/OIDC
(alg=none, Fremdschluessel, Claims-Manipulation, Nonce-Replay), Rate-
Limiting/Lockout im simulierten Mehrinstanz-Betrieb, zentrale Policy-
Durchsetzung (Rechteausweitung, struktureller Guard-Bypass) und Master-
Key-/Tenant-KEK-Rotation. 29/29 Pakete gruen auf 192.168.1.131.
Vier real gefundene Testinfrastruktur-Fehler behoben: reset-test-env.sh
liess tenant_keks (und weitere neuere Registry-Tabellen) beim Reset stehen
(FK-CASCADE loescht nur die Constraint, keine Zeilen); zwei E2E-Tests und
kek_test.go schlossen ihren adminPool per defer VOR ihrer t.Cleanup-
Bereinigung (t.Cleanup laeuft immer nach allen defers); migrate_test.go
hatte ein Testschema ohne die TEN-04-Lifecycle-Spalten. Alle vier Fixes
betreffen ausschliesslich Testcode, kein Produktionscode geaendert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
Volle Merge-Verifikation aller 21 Vorbedingungs-Tickets: neue
internal/e2e-Tests (Tenant-Onboarding-Login-Flow, Cross-Tenant-Isolation)
gegen echte Postgres-Instanz, docs/QA-02-PRUEFPROTOKOLL.md mit
Ticket-zu-Test-Zuordnung. Dabei echten Merge-Konflikt zwischen IAM-12 und
IAM-13 gefunden und behoben (jwk/jwkSet-Typkollision in internal/oidc).
124/124 Tests gruen auf 131.
patrickandClaude Sonnet 5