internal/policy/module_scope.go: policy_module_scopes verknuepft optional
eine (role, permission)-Regel mit einem LIC-02-Feature-Flag. Enforcer.
AuthorizeForTenant ist DIESELBE zentrale Entscheidungsfunktion wie Authorize
(Akzeptanzkriterium 3, kein zweiter Enforcement-Mechanismus) — prueft
zusaetzlich zur Grundregel, ob das verknuepfte Modul fuer den Tenant aktiv
ist. Existiert kein ModuleScope-Eintrag, bleibt eine Regel wie bisher ohne
Lizenzbindung gueltig (Kombinationsfall). GuardModuleScoped erweitert
policy.Guard um dieselbe Pruefung.
internal/flag (LIC-02) wurde 1:1 aus dem lic-02-Branch uebernommen (git show
aus derselben Repo-Historie, keine Aenderung) — RBAC-04 haengt sowohl an
RBAC-01/02 als auch an LIC-02, aber diese leben auf getrennten, noch nicht
gemergten Feature-Branches ohne gemeinsame Historie.
Fail-Safe-Verhalten aus LIC-02 greift automatisch: ein nicht konfiguriertes
oder nicht erreichbares Feature-Flag gilt als deaktiviert, nie als aktiviert
(sicherer Default fuer Modul-Aktivierungspruefungen).
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Zugriff auf deaktiviertes Modul trotz passender Rolle abgewiesen —
TestAuthorizeForTenant_DeniesWhenModuleNotActivated: GuardModuleScoped
ruft die Query-Funktion nachweislich nicht auf. PASS.
2. Reaktivierung macht Berechtigung im laufenden Betrieb wirksam, kein
Neustart — TestAuthorizeForTenant_BecomesActiveWithoutRestart: derselbe
Enforcer/Service-Prozess, Flag per Store.Set aktiviert, TTL abgewartet,
danach erlaubt. PASS.
3. Zusammenspiel Modul-Scope + Rollenscope in Kombinationsfaellen —
TestAuthorizeForTenant_CombinationsOfRoleAndModuleScope: keine Regel ->
verboten; Regel ohne Modul-Scope -> immer erlaubt; Regel mit Modul-Scope
und Flag aus -> verboten; Flag an -> erlaubt. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/policy: deklarativer, DB-gehaltener Regelsatz (policy_rules) statt
hartcodierter Go-Entscheidungslogik — Store.IsAllowed schaut ausschliesslich
in die Datenbank, kein Go-Fallback. Ein Regelwechsel (Grant/Revoke) wirkt
sich sofort aus, ohne Codeaenderung/Deploy (Akzeptanzkriterium 3). Jede
Aenderung wird atomar mit einem versionierten Historieneintrag in
policy_rule_changes festgehalten (grant/revoke, Akteur, Version).
Enforcer.Authorize ist Default-Deny: existiert keine Regel fuer role+
permission, ist der Zugriff verboten (Akzeptanzkriterium 2), fuer sich
genommen ohne Anwendungslogik testbar.
Guard/GuardTenantScoped sind die zentrale Enforcement-Funktion
(Akzeptanzkriterium 1): die uebergebene Query-Funktion wird NUR bei
erfolgreicher Autorisierung aufgerufen — es gibt keinen Weg, Daten ohne
vorherige Authorize-Entscheidung zu erhalten. GuardTenantScoped erzwingt
zusaetzlich per Funktionssignatur, dass tenantSlug TEIL der Query-Funktion
ist (Akzeptanzkriterium 3) — ein nachgelagerter Post-Filter (der
archivmail-Fehler aus "Bekannte Fehler vermeiden": Tenant-Filter nach statt
in der Query) ist mit dieser Signatur strukturell nicht moeglich, da die
Repository-Implementierung tenantSlug selbst fuer ihre eigene WHERE-Klausel
entgegennimmt.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Kein Datenzugriffs-Pfad umgeht die zentrale Enforcement-Schicht —
TestGuard_NeverCallsQueryWithoutAuthorization: query-Funktion wird
nachweislich NICHT aufgerufen ohne vorherige Regel, erst nach Grant. PASS.
2. Anfrage ohne passende Policy wird zuverlaessig abgewiesen (Default-Deny) —
TestAuthorize_DefaultDeny: keine Regel konfiguriert -> ErrDenied, nicht
automatisch erlaubt. PASS.
3. Policy-Regelsatz versioniert, Regelwechsel ohne Codeaenderung
nachvollziehbar — TestGrantRevoke_ChangesBehaviorWithoutCodeChange:
Verhalten aendert sich durch reinen Datenbank-Grant/Revoke, Historie
zeigt beide Versionen korrekt. PASS.
Zusaetzlich: TestGuardTenantScoped_IsolatesDataBetweenTenants belegt das
Tenant-Scoping-Muster aus Akzeptanzkriterium 3 konkret anhand zweier
Tenants. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
