scripte/nexarch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

QA-03: pruefgate-rechte-policy (rbac-04 gemergt, umgehungsversuch+rollenwechsel-tests, pruefprotokoll)

Browse Source
This commit is contained in:
sysops
2026-08-29 00:15:57 +02:00
parent ba23d4d90d
commit 073e61664f
3 changed files with 236 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/QA-03-PRUEFPROTOKOLL.md
+62
View File
@@ -0,0 +1,62 @@
# 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
_Wird nach Verifikation auf root@192.168.1.131 ergänzt._