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

Wird nach Verifikation auf root@192.168.1.131 ergänzt.