60 lines
4.7 KiB
Markdown
60 lines
4.7 KiB
Markdown
# Research: Enterprise Access Boundary & Support Access Governance v1
|
||
|
||
**Date**: 2026-05-05
|
||
**Branch**: `276-support-access-governance`
|
||
|
||
## Decision 1: Keep support access workspace-scoped and tied to repo-real support seams
|
||
|
||
- **Decision**: V1 support access is workspace-scoped and only governs two current repo-real scopes: `audit_view` and `workspace_recovery`.
|
||
- **Rationale**: The repository already has workspace detail, workspace settings, audit history, break-glass, and owner-repair seams. Those seams are enough to deliver customer-safe support governance without inventing a broad delegated admin bridge.
|
||
- **Alternatives considered**:
|
||
- Full impersonation or delegated admin browsing: rejected because the repo has no current bounded bridge for that and the slice would become an IAM project.
|
||
- Keep break-glass as the only support mechanism: rejected because it is global, session-based, and not customer-visible enough for ordinary support access.
|
||
|
||
## Decision 2: Use one workspace-owned grant history, not session-only state
|
||
|
||
- **Decision**: Persist support-access lifecycle in a new workspace-owned `support_access_grants` table.
|
||
- **Rationale**: Support access now needs approval lineage, expiry, reason capture, and customer-visible history that outlives one PHP session.
|
||
- **Alternatives considered**:
|
||
- Session-only state layered onto `BreakGlassSession`: rejected because approval and workspace-visible history would drift or disappear.
|
||
- Audit-log-only reconstruction with no first-class entity: rejected because lifecycle and dedupe rules would become hard to reason about and hard to gate correctly.
|
||
|
||
## Decision 3: Make `workspace_recovery` require both support access and break-glass
|
||
|
||
- **Decision**: The existing `RepairWorkspaceOwners` action requires both an active `workspace_recovery` grant for the target workspace and active break-glass.
|
||
- **Rationale**: This keeps ordinary support access and emergency recovery visibly separate while preventing the owner-repair utility from relying on platform capability plus break-glass alone.
|
||
- **Alternatives considered**:
|
||
- Support access alone enables recovery: rejected because it would collapse ordinary support and emergency recovery.
|
||
- Break-glass alone enables recovery: rejected because it preserves today’s governance gap.
|
||
|
||
## Decision 4: Reuse existing system and admin surfaces instead of adding a new support console
|
||
|
||
- **Decision**: Reuse `ViewWorkspace`, `WorkspaceSettings`, `AuditLog`, and `AccessLogs`.
|
||
- **Rationale**: These surfaces already own workspace detail, owner approval, customer-visible history, and system security history. A new support console would duplicate navigation and create a second control plane.
|
||
- **Alternatives considered**:
|
||
- New support-access resource or page family: rejected because it would duplicate existing detail and history semantics.
|
||
- Approval through email or out-of-band workflow only: rejected because it would leave the product without one inspectable approval truth.
|
||
|
||
## Decision 5: Keep approval optional only where the risk profile changes
|
||
|
||
- **Decision**: `audit_view` may auto-activate for authorized platform operators. `workspace_recovery` requires workspace-owner approval when owners exist, and uses an explicit waiver path only when the workspace is ownerless and break-glass is already active.
|
||
- **Rationale**: This keeps the slice narrow while still giving the high-risk recovery path the stronger human approval boundary it needs.
|
||
- **Alternatives considered**:
|
||
- Require approval for every scope: rejected because it would add friction to low-risk history inspection and overcomplicate the first slice.
|
||
- Never require approval: rejected because recovery support would remain too close to today’s emergency bypass.
|
||
|
||
## Decision 6: Export customer-visible history from the existing admin audit page
|
||
|
||
- **Decision**: Support-access export belongs on the current admin audit-log surface with a support-access filter preset.
|
||
- **Rationale**: The admin audit log is already the customer-visible history surface and already understands workspace-scoped event inspection.
|
||
- **Alternatives considered**:
|
||
- Export from the system access-log page only: rejected because that stays platform-side and does not satisfy customer-visible history.
|
||
- Add a dedicated support-history export page: rejected because it would duplicate the existing audit-history family.
|
||
|
||
## Final Research Outcome
|
||
|
||
- Current-release truth justifies one workspace-owned support-access grant history.
|
||
- The slice stays on two repo-real support scopes and explicitly defers impersonation.
|
||
- Recovery becomes the one place where support access and break-glass must both be present.
|
||
- Existing detail, settings, and history surfaces are sufficient for the first governed package.
|