TenantAtlas/docs/audits/2026-03-09-enterprise-rbac-scope-audit.md

# Enterprise RBAC, Scope Enforcement & Navigation Governance Audit

**Datum:** 9. März 2026
**Anwendung:** TenantPilot / TenantAtlas
**Stack:** Laravel 12, Filament v5, Livewire v4, PostgreSQL, Tailwind v4
**Auditor:** Enterprise SaaS Security & Architecture Audit
**Scope:** RBAC, Multi-Tenancy, Scope Enforcement, Navigation Governance, Filament Authorization

---

## 1. Executive Security / Structure Assessment

### Gesamturteil: **Teilweise robust — mit gezieltem Hardening-Bedarf**

Die Anwendung verfügt über ein **architektonisch durchdachtes, capability-first RBAC-Modell** mit klarer Trennung von Platform/Workspace/Tenant-Scopes. Die Kernarchitektur (CapabilityResolver, UiEnforcement, Membership-Manager, Policies) ist solide und enterprise-geeignet.

Allerdings gibt es **strukturelle Lücken** in folgenden Bereichen:
- System-Panel-Widgets aggregieren cross-workspace/cross-tenant Daten ohne Kompartimentierung
- Einige Monitoring-Pages fehlen explizite `canAccess()` Checks und verlassen sich ausschließlich auf Middleware
- AuditLog-Modell hat keine `workspace_id` Spalte und damit kein strukturelles Workspace-Scoping
- Einige Modelle (OperationRun, BaselineProfile, AlertRule) haben keine Immutabilitäts-Traits am Model-Level
- URL-basierte Enumeration von sequenziellen IDs ist möglich (Finding, OperationRun)

### Die 5 kritischsten RBAC-/Scope-Probleme

| # | Problem | Severity |
|---|---------|----------|
| 1 | **System Panel leakt Cross-Workspace/Cross-Tenant Operational Data** — ControlTower-Widgets zeigen Workspace-Namen, Tenant-Namen und Fehlerstatistiken aller Mandanten an jeden PlatformUser | CRITICAL |
| 2 | **Directory-Pages exponieren alle Tenants/Workspaces** — System/Directory-Seiten erlauben Aufzählung aller registrierten Tenants/Workspaces mit Health-Status und Permission-Gaps | HIGH |
| 3 | **AuditLog hat kein strukturelles Workspace-Scoping** — Nur `tenant_id`, kein `workspace_id`; Scoping ist rein auf Query-Level und kann bei neuen Zugangspfaden umgangen werden | HIGH |
| 4 | **Monitoring-Pages (Operations, AuditLog) fehlen `canAccess()` Checks** — Verlassen sich nur auf Middleware + Query-Scoping, nicht auf explizite Page-Level Authorization | MEDIUM |
| 5 | **Sequenzielle IDs in URLs erlauben Enumeration** — Finding-IDs, OperationRun-IDs sind sequential integers in Deep Links und Notifications | MEDIUM |

### Die 5 wichtigsten Korrekturen

| # | Maßnahme | Priorität |
|---|----------|-----------|
| 1 | System-Panel Kompartimentierung: Capability-Granularisierung für cross-workspace Sicht | P0 |
| 2 | `canAccess()` auf allen Monitoring-Pages implementieren | P1 |
| 3 | AuditLog-Modell um `workspace_id` ergänzen mit Migration + Scoping-Trait | P1 |
| 4 | OperationRun + BaselineProfile + AuditLog mit DerivesWorkspaceId-Trait absichern | P2 |
| 5 | UUID-basierte Route-Keys für sensitive Ressourcen (Finding, OperationRun) evaluieren | P2 |

---

## 2. Access Model Map

### Subjekte

| Subjekt | Guard | Scope | Modell |
|---------|-------|-------|--------|
| **Platform User** | `platform` | System-weit | `PlatformUser` |
| **Workspace Owner** | `web` | Workspace | `User` + `WorkspaceMembership(role=owner)` |
| **Workspace Manager** | `web` | Workspace | `User` + `WorkspaceMembership(role=manager)` |
| **Workspace Operator** | `web` | Workspace | `User` + `WorkspaceMembership(role=operator)` |
| **Workspace Readonly** | `web` | Workspace | `User` + `WorkspaceMembership(role=readonly)` |
| **Tenant Owner** | `web` | Tenant | `User` + `TenantMembership(role=owner)` |
| **Tenant Manager** | `web` | Tenant | `User` + `TenantMembership(role=manager)` |
| **Tenant Operator** | `web` | Tenant | `User` + `TenantMembership(role=operator)` |
| **Tenant Readonly** | `web` | Tenant | `User` + `TenantMembership(role=readonly)` |

### Scopes

| Scope | Kontext | Enforcement |
|-------|---------|-------------|
| **Platform** | System-Administration (break-glass, directory, ops) | `platform` Guard + PlatformCapabilities |
| **Workspace** | Organisation/Account-Isolation | WorkspaceMembership + WorkspaceCapabilityResolver + WorkspaceContext (Session) |
| **Tenant** | Mandant innerhalb eines Workspace | TenantMembership + CapabilityResolver + Filament::getTenant() |

### Kernobjekte pro Scope

| Scope | Objekte |
|-------|---------|
| **Platform** | PlatformUser, Access Logs, Break-Glass-Sessions |
| **Workspace** | Workspace, WorkspaceMembership, WorkspaceSetting, AlertRule, AlertDestination, BaselineProfile, OperationRun (multi-tenant) |
| **Tenant** | Tenant, TenantMembership, Policy, PolicyVersion, BackupSet, BackupItem, BackupSchedule, RestoreRun, Finding, ReviewPack, InventoryItem, EntraGroup, ProviderConnection, TenantPermission, TenantRoleMapping |
| **Ambivalent** | AuditLog (nur tenant_id, kein workspace_id), OperationRun (hat workspace_id, aber kein Immutabilitäts-Trait), AlertDelivery (workspace_id + optional tenant_id) |

### Capability-Muster

**Klar und konsistent:**
- Capability-first Design über `Capabilities::*` und `PlatformCapabilities::*`
- Static Registry (`Capabilities::all()`, `Capabilities::isKnown()`)
- Rolle→Capability Mapping über `RoleCapabilityMap` und `WorkspaceRoleCapabilityMap`
- Gates werden dynamisch aus Capabilities registriert (AuthServiceProvider)
- UiEnforcement erzwingt dreilagige Autorisierung (Visibility → Disabled → Server Guard)

**Inkonsistent:**
- Einige Policies nutzen `Gate::allows()`, andere nutzen `CapabilityResolver::can()` direkt
- System-Panel nutzt separate `PlatformCapabilities` ohne Kompartimentierung innerhalb des System-Scopes
- AuditLog hat keinen eigenen Capability-Check — Sichtbarkeit wird durch Page-Navigation gesteuert

---

## 3. Findings Table

| ID | Severity | Kategorie | Datei / Klasse | Scope | UI-Symptom | Technische Ursache | Risiko | Empfohlene Korrektur |
|----|----------|-----------|----------------|-------|------------|---------------------|--------|---------------------|
| F-01 | **CRITICAL** | Cross-Scope Data Leak | `App\Filament\System\Widgets\ControlTowerTopOffenders` | System→All | Widget zeigt Top-10-Fehler mit Workspace+Tenant-Namen | Query ohne jegliche Scope-Filterung: `OperationRun::query()->selectRaw('workspace_id, tenant_id...')` | Jeder PlatformUser sieht Betriebsdaten aller Mandanten | Capability-basierte Kompartimentierung oder Anonymisierung im System-Panel |
| F-02 | **CRITICAL** | Cross-Scope Data Leak | `App\Filament\System\Widgets\ControlTowerKpis` | System→All | KPI-Dashboard zeigt Gesamtstatistiken über alle Workspaces | Globale `OperationRun::query()` ohne WHERE-Klausel | Informations-Leaking über Betriebsumfang und Fehlerquoten | Scope-Filter oder Capability-Granularisierung |
| F-03 | **CRITICAL** | Cross-Scope Data Leak | `App\Filament\System\Widgets\ControlTowerRecentFailures` | System→All | Zeigt letzte fehlgeschlagene Runs mit Workspace-Namen | Ungefilterter Query | Sensitive Betriebs-Metadaten sichtbar | Scope-aware oder anonymisiert |
| F-04 | **HIGH** | Tenant Enumeration | `App\Filament\System\Pages\Directory\Tenants` | System | Directory listet alle Tenants mit Health, Status, Permission Gaps | `Tenant::query()->with('workspace')` ohne Scope | Reconnaissance: Angreifer sieht alle Mandanten, deren Konfigurationsprobleme und Provider-Status | Capability-basierter Zugang oder Scope-Einschränkung |
| F-05 | **HIGH** | Workspace Enumeration | `App\Filament\System\Pages\Directory\Workspaces` | System | Directory listet alle Workspaces mit Tenant-Count und Fehlerquoten | `Workspace::query()` ohne Scope | Reconnaissance: vollständige Sicht auf Struktur und Probleme aller Organisationen | Wie F-04 |
| F-06 | **HIGH** | Missing Structural Scope | `App\Models\AuditLog` | Tenant/Workspace | AuditLog-Einträge haben kein `workspace_id` | Model hat nur `tenant_id`, kein Workspace-Feld | Bei neuen Zugangspfaden oder Queries ohne Tenant-Kontext könnten Audit-Daten cross-workspace leaken | Migration: `workspace_id` Spalte + NOT NULL + DerivesWorkspaceIdFromTenant Trait |
| F-07 | **MEDIUM** | Missing `canAccess()` | `App\Filament\Pages\Monitoring\Operations` | Admin | Seite ist über `/admin/operations` direkt erreichbar | Kein expliziter `canAccess()` Check, nur Middleware+Query-Scoping | Falls Middleware fehlschlägt oder umgangen wird, keine zweite Schutzschicht | `canAccess()` mit WorkspaceCapabilityResolver implementieren |
| F-08 | **MEDIUM** | Missing `canAccess()` | `App\Filament\Pages\Monitoring\AuditLog` | Admin | Seite über `/admin/audit-log` erreichbar, `shouldRegisterNavigation=false` | Kein `canAccess()`, nur `shouldRegisterNavigation=false` und OperateHubShell | Hidden page ohne Page-Level Auth ist per URL erreichbar | `canAccess()` implementieren |
| F-09 | **MEDIUM** | URL Enumeration | Notification Deep Links + Route `{run}` | Tenant | OperationRun-IDs in Notification-URLs sind sequential integers | `OperationRunLinks::tenantlessView($run)` nutzt Integer-ID | ID-Enumeration erlaubt Erkennung valider Run-IDs (Auth verhindert Lesezugriff) | UUID-basierte Route-Keys oder Rate-Limiting |
| F-10 | **MEDIUM** | URL Enumeration | Finding-URLs in Tenant Panel | Tenant | Finding-IDs in Links: `/findings/140`, `/findings/139` | Sequential integer keys in URLs | Ähnlich wie F-09 | UUID-basierte Anzeige |
| F-11 | **MEDIUM** | No Model Immutability | `App\Models\OperationRun` | Workspace/Tenant | N/A | Kein `DerivesWorkspaceIdFromTenant` Trait; workspace_id wird per boot() auto-filled, aber nicht immutabel erzwungen | Theoretische Reassignment-Möglichkeit (kein aktueller Exploit-Pfad) | DerivesWorkspaceIdFromTenant Trait hinzufügen |
| F-12 | **MEDIUM** | No Model Immutability | `App\Models\BaselineProfile` | Workspace | N/A | Kein Scoping-Trait; workspace_id muss bei Creation gesetzt werden | Developer-Fehler bei zukünftigen Code-Änderungen möglich | Trait oder DB-Constraint |
| F-13 | **LOW** | Break-Glass Scope | `App\Filament\System\Pages\RepairWorkspaceOwners` | System | PlatformUser kann Owner für beliebigen Workspace zuweisen | Nur `USE_BREAK_GLASS` Capability geprüft, keine Workspace-Zugehörigkeitsvalidierung | Intentional (Emergency-Feature), aber unkompartimentiert | Dokumentation und Audit-Alerting sicherstellen; optional: Require 4-eyes |
| F-14 | **LOW** | Access Log Exposure | `App\Filament\System\Pages\Security\AccessLogs` | System | Zeigt alle Platform-Logins und Break-Glass-Aktivitäten | Nur `CONSOLE_VIEW` Capability erforderlich | Offenlegen, wer System-Zugang hat und wann | Separate Capability `SECURITY_AUDIT_VIEW` |
| F-15 | **LOW** | Livewire Auth Gap | `App\Livewire\SettingsCatalogSettingsTable` | Tenant | Liest Policy-Einstellungen ohne eigene Auth | Kein eigener Authorization-Check; angenommen: nur auf autorisierten Seiten gemounted | Falls auf anderer Seite gemounted, Daten-Leak möglich | Defensive Auth prüfen oder Assert bei mount() |

---

## 4. Mismatch Matrix

| Dimension | Status | Details |
|-----------|--------|---------|
| **Navigation Visibility ↔ Policy Enforcement** | ✅ Konsistent für Tenant-Panel | Navigation items nutzen `canViewAny()` + Policy-Checks; UiEnforcement erzwingt Dreischicht-Modell |
| **Navigation Visibility ↔ Policy Enforcement** | ⚠️ Inkonsistent für Monitoring-Pages | Operations und AuditLog sind `shouldRegisterNavigation=false` aber per URL erreichbar ohne `canAccess()` |
| **Navigation Visibility ↔ Policy Enforcement** | ⚠️ Inkonsistent für System-Panel | System-Pages haben nur `DIRECTORY_VIEW`/`OPERATIONS_VIEW` Capability, aber zeigen Daten aller Mandanten |
| **Query/Data Scope ↔ Navigation Scope** | ✅ Konsistent für Tenant-scoped Resources | `getEloquentQuery()` filtert konsequent nach `Tenant::current()` |
| **Query/Data Scope ↔ Navigation Scope** | ✅ Konsistent für Workspace-scoped Resources | `getEloquentQuery()` filtert nach `WorkspaceContext::currentWorkspaceId()` mit `whereRaw('1 = 0')` als Fallback |
| **Query/Data Scope ↔ Navigation Scope** | ⚠️ System-Widgets: Kein Scope, Navigation erlaubt | ControlTower-Widgets haben weder Query-Scope noch Navigation-Gate |
| **Route Accessibility ↔ Authorization** | ✅ Tenant Panel Seiten | Middleware-Stack (`ensure-workspace-selected`, `ensure-filament-tenant-selected`, `DenyNonMemberTenantAccess`) |
| **Route Accessibility ↔ Authorization** | ✅ Tenantless Run Viewer | `mount()` → `$this->authorize('view', $run)` → OperationRunPolicy prüft Workspace+Tenant+Capability |
| **Route Accessibility ↔ Authorization** | ⚠️ AuditLog Page | `shouldRegisterNavigation=false`, aber kein `canAccess()` — per URL erreichbar |
| **Action Auth ↔ Bulk Action Auth** | ✅ Konsistent | UiEnforcement erzwingt all-or-nothing Semantik für Bulk Actions mit gleicher Capability wie Single Actions |
| **Widget Data ↔ User Scope** | ✅ Dashboard-Widgets | `DashboardKpis`, `NeedsAttention`, `RecentOperations` nutzen `Filament::getTenant()` korrekt |
| **Widget Data ↔ User Scope** | ✅ AlertsKpiHeader | Filtert nach workspace_id + user.tenantMemberships + optional activeTenant |
| **Widget Data ↔ User Scope** | ⚠️ ControlTower-Widgets | Keine Scope-Filterung — zeigen Platform-weite Aggregate |
| **Global Search ↔ Scope** | ✅ ScopesGlobalSearchToTenant Trait | Prüft `canAccessTenant()` und filtert per `whereBelongsTo()` |
| **Global Search ↔ Scope** | ⚠️ Trait-Nutzung verifizieren | Unklar ob alle globalsuchbaren Resources diesen Trait nutzen |
| **Relation Managers ↔ Parent Scope** | ✅ Konsistent | TenantMembershipsRelationManager, BackupItemsRelationManager etc. erben Parent-Scope des owning Resource |
| **Deep Links ↔ Auth** | ✅ Notification-URLs | OperationRunPolicy prüft Workspace+Tenant bei mount() |
| **Deep Links ↔ Auth** | ⚠️ IDs in URLs | Sequential integers ermöglichen Enumeration |

---

## 5. Target Enterprise RBAC Model

### Rollen-/Capability-Modell (Zielzustand)

```
Platform Layer
├── Platform Admin: Full system access
├── Platform Ops:   Operations monitoring (scoped)
├── Platform Audit: Security audit view only
└── Platform Support: Break-glass + Directory (audited, 4-eyes for critical)

Workspace Layer
├── Owner:    Full workspace control + all tenant capabilities
├── Manager:  Workspace admin (no archive/delete) + most tenant capabilities
├── Operator: Execute operations + view
└── Readonly: View-only

Tenant Layer
├── Owner:    Full tenant control
├── Manager:  Admin (no delete/membership manage)
├── Operator: Execute sync/backup/run + view
└── Readonly: View-only
```

### Regeln für Navigation Visibility

1. **Navigation zeigt NUR Items, für die der Nutzer authorization hat** — sowohl `shouldRegisterNavigation()` als auch `canAccess()` müssen konsistent sein
2. **Hidden Pages müssen `canAccess()` implementieren** — `shouldRegisterNavigation=false` bedeutet nicht "keine Autorisierung nötig"
3. **System-Panel Navigation muss capability-granular sein** — nicht eine einzige `CONSOLE_VIEW` Capability für alles
4. **Navigation darf niemals die einzige Schutzschicht sein**

### Regeln für Query Scope

1. **Jede `getEloquentQuery()` muss scope-aware sein** — mit `whereRaw('1 = 0')` als Fallback bei fehlendem Kontext
2. **Tenant-scoped Modelle nutzen `DerivesWorkspaceIdFromTenant` oder `$tenantOwnershipRelationshipName`**
3. **Workspace-scoped Modelle filtern nach `WorkspaceContext::currentWorkspaceId()`**
4. **System-Queries (ControlTower) müssen entweder scope-kompartimentiert oder anonymisiert sein**
5. **AuditLog muss `workspace_id` als strukturelles Scope-Feld haben**

### Regeln für Direct URL Access

1. **Jede Page muss `canAccess()` implementieren** — keine Ausnahme für "hidden" Pages
2. **Route Model Binding muss Scope-Ownership erzwingen** — OperationRunPolicy-Muster als Standard
3. **UUID-basierte Route-Keys für sensitive Ressourcen** — Findings, OperationRuns
4. **Rate-Limiting auf Detail-Endpoints** — gegen Enumeration

### Regeln für Actions / Bulk Actions

1. **UiEnforcement ist der Standard für alle Actions** — kein Bypass
2. **Destructive Actions: `->requiresConfirmation()` + `->action(...)` + Capability-Check**
3. **Bulk Actions: all-or-nothing Semantik (bereits implementiert)**
4. **Keine Action darf schwächer autorisiert sein als die entsprechende Single-Record-Action**

### Regeln für Widgets, Search, Exports und Deep Links

1. **Widgets dürfen nur scope-konforme Daten anzeigen** — kein Count über unerlaubte Scopes
2. **Global Search muss `ScopesGlobalSearchToTenant` nutzen** — für alle tenant-scoped Resources
3. **Deep Links in Notifications müssen Policy-geschützt sein** — bereits implementiert, UUID-Keys evaluieren
4. **Export-Funktionen müssen dieselbe Scope-Filterung wie die UI anwenden**

---

## 6. Hardening Recommendations

### Quick Wins (P0-P1, sofort umsetzbar)

| # | Maßnahme | Nutzen | Risiko | Aufwand | Priorität |
|---|----------|--------|--------|---------|-----------|
| QW-1 | `canAccess()` auf `Operations.php` implementieren — WorkspaceCapabilityResolver + Membership Check | Schließt Page-Level Auth Lücke | Minimal: bestehende Pattern kopieren | 1h | P1 |
| QW-2 | `canAccess()` auf `AuditLog.php` implementieren | Wie QW-1 | Minimal | 1h | P1 |
| QW-3 | System-Panel Capability-Granularisierung: `OPERATIONS_VIEW` in `OPS_VIEW_RUNS`, `OPS_VIEW_FAILURES`, `OPS_VIEW_STUCK` aufteilen | Feinere Zugriffskontrolle | Migration + PlatformUser Capability-Update | 4h | P1 |
| QW-4 | ControlTower-Widgets: Option für anonymisierte/aggregierte Ansicht | Verhindert Tenant-Namen-Leak | Widget-Refactor | 4h | P1 |
| QW-5 | `SettingsCatalogSettingsTable` Livewire: Defensive Auth in `mount()` | Verhindert Context-Leak bei Wiederverwendung | Minimal | 30min | P2 |

### Mittlere Hardening-Maßnahmen (P2, geplant)

| # | Maßnahme | Nutzen | Risiko | Aufwand | Priorität |
|---|----------|--------|--------|---------|-----------|
| MH-1 | AuditLog Migration: `workspace_id` Spalte + NOT NULL + Index | Strukturelles Workspace-Scoping | Backfill-Migration nötig | 8h | P2 |
| MH-2 | `DerivesWorkspaceIdFromTenant` auf OperationRun-Model | Immutabilitäts-Garantie | Sehr gering | 2h | P2 |
| MH-3 | `DerivesWorkspaceIdFromTenant` auf BaselineProfile-Model | Wie MH-2 | Gering | 2h | P2 |
| MH-4 | UUID-basierte Route-Keys für Finding, OperationRun | Verhindert ID-Enumeration | Model+Migration+Route-Refactor | 12h | P2 |
| MH-5 | Rate-Limiting auf `/admin/operations/{run}` und ähnliche Detail-Endpoints | Anti-Enumeration | Middleware-Config | 2h | P2 |
| MH-6 | System-Panel Directory: Capability `DIRECTORY_MANAGE` vs `DIRECTORY_VIEW` differenzieren | Least-Privilege im System-Panel | Capability-Registry Update | 4h | P2 |
| MH-7 | Break-Glass: 4-eyes-Prinzip oder temporal scoping verschärfen | Privileged-Access-Governance | UX-Design nötig | 8h | P2 |

### Strukturelle Refactors (P3, Spec-gesteuert)

| # | Maßnahme | Nutzen | Risiko | Aufwand | Priorität | Spec? |
|---|----------|--------|--------|---------|-----------|-------|
| SR-1 | Global Scope auf OperationRun für automatisches Workspace-Scoping | Präventiv gegen zukünftige Query-Fehler | Model-Behavior-Änderung; Tests nötig | 16h | P3 | Ja |
| SR-2 | System-Panel Kompartimentierung: Scope-basierte Platform Views | Enterprise isolation für managed-service Betrieb | Architektur-Refactor | 40h | P3 | Ja |
| SR-3 | Einheitliche `canAccess()` Base-Mixin für alle Pages | DRY + Konsistenz | Base-Class Refactor | 16h | P3 | Ja |
| SR-4 | Monitoring-Pages: Unified OperateHub Authorization Layer | Konsolidierte Auth statt Page-for-Page | Architektur | 24h | P3 | Ja |

---

## 7. Project Rules

### Verbindliche Enterprise RBAC Rules

1. **Navigation ist nie die Sicherheitsgrenze.** Jede Filament-Page muss eine `canAccess()` Methode implementieren, die unabhängig von Navigation Visibility autorisiert. `shouldRegisterNavigation=false` ersetzt keinen Authorization-Check.

2. **Jede sichtbare Aktion braucht deckungsgleiche Server-Autorisierung.** UiEnforcement (Tenant) oder WorkspaceUiEnforcement (Workspace) ist der Standard-Wrapper für alle Actions. Kein Action-Handler darf ohne Server-Side Guard ausgeführt werden.

3. **Hidden Pages dürfen nicht unautorisiert per URL erreichbar sein.** Jede Page mit `shouldRegisterNavigation=false` oder `isDiscovered=false` MUSS explizit `canAccess()` implementieren.

4. **Workspace- und Tenant-Scope müssen in Query, Route Binding und Policy konsistent erzwungen werden.** Scope-Enforcement findet auf mindestens zwei Ebenen statt: Query-Level (`getEloquentQuery()`) UND Policy/Gate-Level.

5. **Widgets, Counts und Search dürfen keine scope-fremden Metadaten leaken.** Jedes Dashboard-Widget muss denselben Scope-Filter anwenden wie die zugehörige Tabelle/Resource. System-Widgets müssen scope-kompartimentiert oder anonymisiert sein.

6. **Bulk Actions dürfen nie schwächer autorisiert sein als Single Actions.** UiEnforcement erzwingt all-or-nothing Semantik: Wenn ein Record in der Selektion die Capability verletzt, wird die gesamte Bulk-Action blockiert.

7. **Deep Links und Notifications müssen kanonisch und permission-sicher sein.** Jede URL, die per Notification, E-Mail oder API-Response geteilt wird, muss bei Zugriff denselben Auth-Check durchlaufen wie der UI-Pfad.

8. **Route Model Binding muss Scope-Ownership erzwingen.** Policies müssen bei `view()` immer Workspace-Membership UND Tenant-Membership (falls tenant-scoped) prüfen. Non-Members erhalten 404 (deny-as-not-found), nicht 403.

9. **Capability-first vor rollen-/UI-getriebener Logik.** Autorisierung leitet sich aus Capabilities ab, nicht aus Rollen-Strings oder UI-Zustand. `RoleCapabilityMap` ist die Single Source of Truth.

10. **Kein Zugriff über "zufällig funktionierende" indirekte Pfade.** Jeder neue Pfad (Relation Manager, Tab, Widget, Global Search, Export) muss explizit scope-geprüft werden. Filament Auto-Discovery allein ist keine Autorisierung.

11. **Modelle mit Tenant- oder Workspace-Zugehörigkeit MÜSSEN Immutabilitäts-Traits nutzen.** `DerivesWorkspaceIdFromTenant` oder vergleichbare Traits stellen sicher, dass Scope-Zuweisungen nach Creation nicht verändert werden können.

12. **System-Panel Capabilities müssen granular sein.** Eine einzige `CONSOLE_VIEW` Capability für cross-workspace Sichtbarkeit reicht für Enterprise-Betrieb nicht aus. Differenzierung in Operations, Directory, Security, Break-Glass.

13. **Destructive Actions erfordern immer `->requiresConfirmation()`.** Keine Ausnahme, auch nicht bei "schnellen" Aktionen wie Archive oder Toggle.

14. **AuditLog muss workspace-scoped sein.** Jeder Audit-Eintrag muss `workspace_id` tragen, um cross-workspace Reporting und Compliance zu ermöglichen.

---

## 8. Spec Proposal Backlog

### Spec A: System Panel Kompartimentierung

| Feld | Wert |
|------|------|
| **Titel** | System Panel Capability Granularization & Data Compartmentalization |
| **Problem** | Alle PlatformUser mit `CONSOLE_VIEW` sehen Betriebsdaten aller Workspaces/Tenants. ControlTower-Widgets, Directory-Pages und Access-Logs bieten keine Scope-Isolation. |
| **Ziel** | PlatformCapabilities aufteilen in `OPS_VIEW_RUNS`, `OPS_VIEW_FAILURES`, `DIRECTORY_VIEW_TENANTS`, `DIRECTORY_VIEW_WORKSPACES`, `SECURITY_AUDIT_VIEW`. ControlTower-Widgets anonymisieren oder scope-kompartimentieren. |
| **Scope** | System Panel Widgets, Directory Pages, Access Logs, PlatformCapabilities Registry |
| **Non-goals** | Nicht: Umbau der web-Guard-Architektur; nicht: Multi-Panel Redesign |
| **Priorität** | P1 — Enterprise-Compliance-Risiko |
| **Abhängigkeiten** | Keine |

### Spec B: Page-Level Authorization Enforcement

| Feld | Wert |
|------|------|
| **Titel** | Enforce canAccess() on all Filament Pages |
| **Problem** | Mehrere Pages (Operations, AuditLog, potentiell weitere) haben keinen expliziten `canAccess()` Check und verlassen sich nur auf Middleware |
| **Ziel** | Alle Pages im Admin/Tenant/System Panel implementieren `canAccess()` mit CapabilityResolver/WorkspaceCapabilityResolver |
| **Scope** | Alle Filament Pages; PHPStan oder Pest-Regel zur Enforcement-Prüfung |
| **Non-goals** | Nicht: Middleware-Umbau; nicht: UiEnforcement-Refactor |
| **Priorität** | P1 — Defense-in-Depth |
| **Abhängigkeiten** | Keine |

### Spec C: AuditLog Workspace Scoping

| Feld | Wert |
|------|------|
| **Titel** | Add workspace_id to AuditLog for Structural Scope Isolation |
| **Problem** | AuditLog hat nur `tenant_id`, kein `workspace_id`. Query-Level-Scoping ist fragil und kann bei neuen Zugangspfaden umgangen werden. |
| **Ziel** | Migration: `workspace_id` Spalte (nullable → later NOT NULL); Backfill-Job; DerivesWorkspaceIdFromTenant-Trait; Index |
| **Scope** | AuditLog Model, Migration, Backfill, Audit-Service Updates |
| **Non-goals** | Nicht: AuditLog Schema-Redesign; nicht: Retention-Policy |
| **Priorität** | P2 |
| **Abhängigkeiten** | Keine |

### Spec D: Model Immutability Enforcement

| Feld | Wert |
|------|------|
| **Titel** | Apply DerivesWorkspaceId Trait to OperationRun, BaselineProfile, AlertRule |
| **Problem** | OperationRun, BaselineProfile, AlertRule haben keine Model-Level Immutabilitäts-Garantie für workspace_id. Scope-Zuweisungen könnten theoretisch nach Creation verändert werden. |
| **Ziel** | DerivesWorkspaceIdFromTenant oder DerivesWorkspaceIdFromTenantWhenPresent Trait auf alle scope-relevanten Modelle anwenden; WorkspaceIsolationViolation als Guard |
| **Scope** | OperationRun, BaselineProfile, AlertRule, AlertDestination Models |
| **Non-goals** | Nicht: Global Scope Enforcement (separate Spec) |
| **Priorität** | P2 |
| **Abhängigkeiten** | Keine |

### Spec E: UUID Route Keys für Sensitive Resources

| Feld | Wert |
|------|------|
| **Titel** | UUID-based Route Keys for Findings, OperationRuns, and Sensitive Records |
| **Problem** | Sequential integer IDs in URLs ermöglichen Enumeration. Notification-Deep-Links und Tabellen-Links enthalten vorhersagbare IDs. |
| **Ziel** | getRouteKeyName() auf `external_id` (UUID) umstellen für Finding, OperationRun; Migration für UUID-Spalte; URL-Refactor |
| **Scope** | Finding, OperationRun, ReviewPack Models; Routes; Notification Links |
| **Non-goals** | Nicht: Alle Models umstellen; nicht: bestehende DB-PKs ändern |
| **Priorität** | P2 |
| **Abhängigkeiten** | Keine |

### Spec F: OperateHub Unified Authorization Layer

| Feld | Wert |
|------|------|
| **Titel** | Unified Authorization Layer for Monitoring/OperateHub Pages |
| **Problem** | Monitoring-Pages (Operations, Alerts, AuditLog) haben unterschiedliche Auth-Patterns. Operations nutzt kein `canAccess()`, Alerts nutzt WorkspaceCapabilityResolver, AuditLog nutzt keines. |
| **Ziel** | Shared Trait oder Base-Page-Klasse für OperateHub-Pages mit einheitlicher `canAccess()` + Capability-Mapping |
| **Scope** | OperateHub Pages, Monitoring Cluster, Shared Trait |
| **Non-goals** | Nicht: Redesign der OperateHubShell Navigation-Logik |
| **Priorität** | P2 |
| **Abhängigkeiten** | Spec B (Page-Level Auth Enforcement) |

### Spec G: Global Search Scope Verification & Trait Coverage

| Feld | Wert |
|------|------|
| **Titel** | Verify and Enforce ScopesGlobalSearchToTenant Usage on All Searchable Resources |
| **Problem** | `ScopesGlobalSearchToTenant` Trait existiert und ist gut implementiert, aber es ist unklar, ob alle global-suchbaren Resources ihn nutzen. |
| **Ziel** | Audit: Welche Resources sind global-suchbar? Nutzen alle den Trait? Pest-Test für Enforcement. |
| **Scope** | Alle Filament Resources mit $recordTitleAttribute oder globallySearchable |
| **Non-goals** | Nicht: Redesign der Global-Search-Architektur |
| **Priorität** | P2 |
| **Abhängigkeiten** | Keine |

---

## Appendix: Positive Architecture Highlights

### Was gut funktioniert

1. **Capability-first Design** mit `Capabilities::all()` als Single Source of Truth und dynamischer Gate-Registrierung
2. **UiEnforcement** als dreilagiger RBAC-Wrapper (Visibility → Disabled → Server Guard) — Enterprise-Grade
3. **Deny-as-not-found Semantik** — Non-Members bekommen 404, nicht 403 (verhindert Existence-Leaking)
4. **DerivesWorkspaceIdFromTenant Trait** — Model-Level Immutabilität mit `WorkspaceIsolationViolation` Exception
5. **Last-Owner Guard** — Verhindert Removal/Demotion des letzten Workspace/Tenant Owners
6. **Workspace 7-Step Selection Algorithm** — Robust mit Stale-Session-Handling und Audit-Events
7. **Tenant Middleware Stack** — 4 Middleware-Layer (correct guard → workspace selected → tenant selected → deny non-member)
8. **Break-Glass Auditing** — Vollständig auditiert mit TTL, explicit start/exit, IP-Logging
9. **OperateHubShell** — Konsistente Cross-Tenant-Sicht mit Membership-Validation und Entitlement-Prüfung
10. **WriteGateInterface** — Hardening-Layer gegen unsichere RBAC-Zustände bei Intune-Writes

### Zusammenfassung

Die Architektur zeigt ein **reifes, mehrschichtiges Autorisierungsmodell**, das für die meisten Enterprise-Szenarien robust ist. Die identifizierten Lücken betreffen primär:

1. **System-Panel**: Unzureichende Kompartimentierung (alle PlatformUser sehen alles)
2. **Monitoring-Pages**: Fehlende explizite Page-Level Auth (Defense-in-Depth Lücke)
3. **AuditLog**: Fehlendes strukturelles Workspace-Scoping
4. **ID-Enumeration**: Sequenzielle IDs in URLs (kein Datenleak, aber Reconnaissance-Vektor)

Keines dieser Findings ermöglicht aktuell einen direkten Daten-Leak oder Privilege-Escalation über die bestehenden Middleware- und Policy-Checks hinaus. Die Maßnahmen dienen der **Enterprise-Härtung und Defense-in-Depth**, nicht der Schließung aktiver Sicherheitslücken.