nexarch/docs/QA-03-PRUEFPROTOKOLL.md

# QA-03 – Prüfprotokoll: Prüfgate Rechte & Policy

Stand: 2026-08-29. Branch `feature/qa-03-pruefgate-rechte-policy` (RBAC-05 + RBAC-04 gemergt).

## 1. Akzeptanzkriterien RBAC-01 bis RBAC-05 — Testabdeckung

| Ticket | Titel | Abdeckende Tests |
|---|---|---|
| RBAC-01 | Rollenmodell & Grundrechte | `internal/rbac/role_test.go`: `TestEffectivePermissions_Inheritance`, `TestHasPermission` |
| RBAC-01 | Rollenzuweisung | `internal/rbac/store_test.go`: `TestStore_AssignAndGet`, `TestStore_RejectsSuperadminOutsideAllowedMatrix`, `TestStore_RejectsUnknownRole`, `TestStore_HistoryTracksWhoAndWhen` |
| RBAC-02 | Policy-Enforcement-Schicht (zentral) | `internal/policy` — kein eigenes `*_test.go` in diesem Merge gefunden für `enforcer.go`/`store.go` direkt (siehe Abweichungen unten); Verhalten indirekt über `TestBypass_PolicyEnforcerItselfRespectsRevocation` (dieser Branch) nachgewiesen |
| RBAC-03 | Gruppen & Abteilungen | `internal/rbac/group_test.go`: `TestGroup_CreateAndAddMember`, `TestGroup_RoleAffectsAllCurrentMembers`, `TestGroup_RemoveMemberRevokesRightsImmediately`, `TestGroup_DeleteGroupRevokesRightsWithoutDeletingUser`, `TestGroup_TenantIsolation` |
| RBAC-04 | Modul-scoped Berechtigungen | `internal/policy/module_scope_test.go`: `TestAuthorizeForTenant_DeniesWhenModuleNotActivated`, `TestAuthorizeForTenant_BecomesActiveWithoutRestart`, `TestAuthorizeForTenant_CombinationsOfRoleAndModuleScope` |
| RBAC-05 | Rechte-Administrationsoberfläche | `internal/rbac/handler_test.go`: `TestListRoles`, `TestAssignRole_RejectsSelfEscalation`, `TestAssignRole_AdminCanPromoteOtherUser`, `TestAssignRole_AdminCanDemoteOtherUser` (neu, dieser Branch), `TestRoleHistory_TracksAssignments`, `TestGroupWorkflow`, `TestRequireManageUsers_RejectsPlainUser` |

**Ergebnis Abschnitt 1:** alle 5 Tickets haben automatisierte Tests, die ihre dokumentierten Akzeptanzkriterien abdecken. RBAC-02 selbst hat keine eigene Testdatei im gemergten Stand — abgedeckt nur indirekt über den in diesem Branch neu geschriebenen `TestBypass_PolicyEnforcerItselfRespectsRevocation`. Als Abweichung festgehalten (Abschnitt 4).

## 2. Umgehungsversuch der zentralen Policy-Schicht (Akzeptanzkriterium 2 / Prüfung 1)

Getestet in `internal/rbac/bypass_test.go`:

- **`TestBypass_NoDirectWriteAPIOutsideStore`**: bestanden. `role_assignments` hat keine Schreib-API außerhalb von `Store.Assign` — Umgehungsversuch scheitert strukturell (Typsystem, kein exportierter DB-Pool).
- **`TestBypass_PolicyEnforcerItselfRespectsRevocation`**: bestanden. RBAC-02s eigentliche Policy-Tabelle (`policy_rules`) reagiert sofort auf `Revoke` — kein Cache, keine verzögerte Wirkung.
- **`TestBypass_HandlerIgnoresCentralPolicyRevocation`**: **deckt einen echten Fund auf**, siehe Abschnitt 4.

## 3. Rollenwechsel-Szenario (Akzeptanzkriterium 2 / Prüfung 2)

- Hochstufung (user → tenant_admin): `TestAssignRole_AdminCanPromoteOtherUser` — bestanden.
- Rückstufung (tenant_admin → user): `TestAssignRole_AdminCanDemoteOtherUser` (neu, dieser Branch) — bestanden, inklusive Prüfung, dass `role_assignment_history` beide Richtungen (erst `tenant_admin`, dann `user`) korrekt in chronologischer Reihenfolge festhält.
- Selbst-Eskalation bleibt weiterhin gesperrt (`TestAssignRole_RejectsSelfEscalation`, aus RBAC-05).

**Ergebnis Abschnitt 3:** bestanden, beide Richtungen automatisiert nachgewiesen.

## 4. Abweichungen (Akzeptanzkriterium 3: nicht stillschweigend ignoriert)

### 4.1 RBAC-05-Handler prüfen nicht gegen die zentrale Policy-Schicht (RBAC-02) — Schweregrad: Mittel

**Fund:** `internal/rbac/handler.go` (`requireManageUsers`) entscheidet Zugriff über `HasPermission(role, PermManageUsers)` — die **statische**, hartcodierte Rollenhierarchie aus `role.go`. Es ruft nirgends `internal/policy.Enforcer.Authorize`/`Guard` auf, die eigentliche zentrale, DB-gestützte Durchsetzungsschicht aus RBAC-02 (`policy_rules`-Tabelle, per `Store.Grant`/`Revoke` administrierbar, versioniert in `policy_rule_changes`).

**Konsequenz:** ein Administrator, der über die RBAC-02-Policy-Schicht das Recht `tenant.manage_users` von `tenant_admin` entzieht (`policy.Store.Revoke`), sperrt die RBAC-05-Endpunkte **nicht** aus — sie fragen `policy_rules` nie ab. Zwei parallele Enforcement-Pfade statt einer zentralen Schicht, verletzt die Ticket-Produkt-DNA "Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden" (RBAC-05-Ticket) UND RBAC-02s eigenen Anspruch ("keine Tenant- oder Rechteprüfung verstreut in einzelnen Handlern").

**Nachweis:** `TestBypass_HandlerIgnoresCentralPolicyRevocation` in `internal/rbac/bypass_test.go`.

**Nicht in dieser Kachel behoben** (QA-03-Arbeitsweise: kein Umbau angrenzender Bereiche, RBAC-05 ist nicht Vorbedingung von QA-03) — Empfehlung: eigenes Folgeticket, das `requireManageUsers` auf `internal/policy.Guard`/`Enforcer.Authorize` umstellt.

### 4.2 RBAC-02 hat keine eigene Testdatei im gemergten Stand — Schweregrad: Niedrig

`internal/policy/enforcer.go` und `store.go` (RBAC-02 selbst) haben keine `enforcer_test.go`/`store_test.go` im Merge-Ergebnis dieses Branches — nur `module_scope_test.go` (RBAC-04) prüft sie indirekt über `AuthorizeForTenant`. Die in diesem Branch neu geschriebenen Bypass-Tests schließen die Lücke teilweise, ersetzen aber keine dedizierten RBAC-02-Unit-Tests. Empfehlung: bei Gelegenheit nachziehen, kein blockierender Fund.

## 5. RBAC-04-Zusammenspiel mit Lizenz-/Flag-Zustand (Akzeptanzkriterium 3)

`internal/flag` (aus RBAC-04-Merge) ist vorhanden. `internal/policy.Enforcer.AuthorizeForTenant` verknüpft eine Policy-Regel optional mit einem `flag.Service`-Eintrag (`ModuleScope.FlagKey`): eine sonst erlaubte Regel greift nicht, wenn das zugehörige Modul für den Tenant nicht aktiviert ist. `TestAuthorizeForTenant_DeniesWhenModuleNotActivated` und `TestAuthorizeForTenant_BecomesActiveWithoutRestart` beweisen das bereits (aus RBAC-04, unverändert übernommen).

**Ergebnis Abschnitt 5:** bestanden, Zusammenspiel vorhanden und getestet.

## 6. Gesamtergebnis

Bestanden mit einem dokumentierten Mittel-Schweregrad-Fund (4.1) und einem Niedrig-Schweregrad-Hinweis (4.2). Build-/Test-Ergebnis auf dem Testhost: siehe Abschnitt 7.

## 7. Build/Test-Ergebnis auf 131

Durchgeführt 2026-08-29 auf root@192.168.1.131 (`/root/nexarch-code-qa03`, isolierter Sync, kein Konflikt mit parallelem QA-02-Testlauf):

- `go mod tidy`, `go build ./...`, `go vet ./...` — alle sauber, keine Fehler.
- `go test ./... -v -p 1` gegen frisch zurückgesetzte Testumgebung — **alle 30 Tests grün**, über alle betroffenen Pakete (`internal/auth`, `internal/policy`, `internal/rbac`, `internal/tenant`, `internal/user`), inklusive `TestBypass_HandlerIgnoresCentralPolicyRevocation` (bestätigt den Fund aus Abschnitt 4.1 als reproduzierbar, nicht nur behauptet) und `TestAssignRole_AdminCanDemoteOtherUser` (neuer Rückstufungs-Test aus Abschnitt 3).
- Keine Regressionen in RBAC-01/02/03/04/05 durch den Merge.

**QA-03 Gesamtergebnis: bestanden**, mit einem dokumentierten Mittel-Schweregrad-Fund (4.1, Empfehlung: Folgeticket) und einem Niedrig-Schweregrad-Hinweis (4.2).