Check Designer — Support Access Policy (Draft)
Status: Draft administrative/security policy — subject to attorney review before commercial launch. Implementation alignment: See `SUPPORT_ACCESS_IMPLEMENTATION_REVIEW.md` (Phase 2P-D audit).
1. Purpose
This policy describes how vendor support personnel may access a customer tenant in Check Designer. It reflects implemented controls in the application: there is no silent or standing support access, no tenant user impersonation, and no platform-operator bypass of tenant OWNER approval.
2. Core principles
| Principle | Implementation |
|---|---|
| No silent access | A SUPPORT user cannot browse a tenant without an ACTIVE session, valid signed `check_designer_support_mode` cookie, and matching database session row |
| OWNER approval required | Only tenant OWNER (not ADMIN) may create, approve, deny, or revoke sessions via `requireOwnerManagement` APIs |
| Explicit activation | After approval, the assigned SUPPORT user must call Activate (`POST /api/support-access/activate`), which sets status ACTIVE and the support-mode cookie |
| Time-boxed | Each session has `expiresAt`; maximum duration 24 hours from request/approval; expired and terminal statuses block use |
| Scoped stores | Optional `allowedStoreIds` limits which store locations apply; validated against tenant ACTIVE stores |
| Scoped permissions | Optional `allowedPermissions` is intersected with the SUPPORT role ceiling; empty list means full SUPPORT ceiling (still no reveal/print/backup) |
| Audit trail | Lifecycle writes tenant audit events (see §5) |
| Visible mode | UI shows Support mode active banner with expiry; SUPPORT can end session from banner |
| No impersonation | Permission `support.impersonate` exists in code but is not granted to any role and is unused |
3. Session lifecycle (current behavior)
| Step | Actor | Status / result |
|---|---|---|
| 1. Request | Tenant OWNER | Creates session PENDING (`POST /api/support-access`) with support user, reason, ticket ref, expiry ≤ 24h, optional store/permission scope |
| 2. Approve or deny | Tenant OWNER | APPROVED or DENIED (`approve` / `deny`) — ADMIN cannot approve |
| 3. Revoke | Tenant OWNER | REVOKED from PENDING, APPROVED, or ACTIVE |
| 4. Activate | Assigned SUPPORT user only | ACTIVE + support-mode cookie (`activate`); must match `supportUserId` on session |
| 5. Work in tenant | SUPPORT | Tenant APIs use support scope binding; without ACTIVE mode, APIs return inactive-scope error |
| 6. End | SUPPORT or OWNER | ENDED; cookie cleared (`end`) |
| 7. Expire | System | EXPIRED when past `expiresAt` (also marks stale APPROVED/ACTIVE) |
Platform operators may view support session metadata on the platform portal (`GET /api/platform/support-sessions`). They cannot approve, activate, or operate inside a tenant as SUPPORT without being the designated support user on an approved session.
4. Suspended tenants (2M platform policy)
When a tenant is SUSPENDED (platform operator action):
- New support access requests fail (tenant must be ACTIVE to create a session).
- ACTIVE support sessions for that tenant are ended; PENDING and APPROVED sessions are revoked.
- Tenant users (including SUPPORT with a stale cookie) receive 403 on tenant APIs: *"This account is suspended. Please contact support."*
- Platform portal APIs remain available to platform operators for suspend/reactivate and monitoring.
5. Audit events
Support lifecycle actions write `AuditLog` entries with safe metadata (session id, tenant id, support user id, status, store count — not bank data or MICR). Actions include:
| Audit action | When |
|---|---|
| `SUPPORT_ACCESS_REQUESTED` | OWNER creates PENDING session |
| `SUPPORT_ACCESS_APPROVED` | OWNER approves |
| `SUPPORT_ACCESS_DENIED` | OWNER denies |
| `SUPPORT_ACCESS_REVOKED` | OWNER revokes |
| `SUPPORT_ACCESS_STARTED` | SUPPORT activates (ACTIVE) |
| `SUPPORT_ACCESS_ENDED` | SUPPORT or OWNER ends ACTIVE session |
| `SUPPORT_ACCESS_EXPIRED` | System marks expired |
| `SUPPORT_PERMISSION_DENIED` | SUPPORT denied a route permission (logged with session id when applicable) |
6. What support can and cannot do
6.1 SUPPORT role ceiling (implemented)
The SUPPORT role includes read-oriented permissions only, for example: dashboard, accounts (read), stores, templates (read), designer (read), print queue (read), history (read), audit (read), reports (read), settings (read), and `support.access`.
Not included in the SUPPORT ceiling (cannot be granted via allow-list either):
| Capability | Notes |
|---|---|
| `account.reveal` | Full decrypted account numbers and signatures — excluded from SUPPORT ceiling; validation rejects granting it on a session |
| Print / prepare / queue print | Print mutations not in SUPPORT permissions |
| Backup download | Database and project JSON backup routes block active support mode |
| `support.impersonate` | Not assigned to any role |
| User/tenant OWNER management | Approve/deny/revoke reserved for OWNER APIs |
Optional session `allowedPermissions` only narrows the ceiling further; it cannot elevate beyond SUPPORT permissions.
6.2 Masked bank data
Support users see masked account numbers in normal account APIs (same as other roles without `account.reveal`). Support mode does not grant reveal.
6.3 Platform operators
Users with `isPlatformOperator` access the platform portal for tenant metadata (status, billing fields, system health, support session list). Responses exclude forbidden keys (account numbers, MICR, signatures, print HTML, tokens, etc.). Platform sessions cannot call tenant-scoped APIs. This is monitoring, not impersonation of tenant users.
6.4 Sensitive data in logs
Support and operators must not log decrypted account numbers, signatures, MICR lines, or `BANK_DATA_ENCRYPTION_KEY`. Audit metadata uses redaction patterns in application code.
7. Customer responsibilities
- Approve support sessions only for legitimate tickets
- Revoke access when work completes
- Use minimum necessary scope (stores and permissions) when creating requests
- Understand ADMIN users cannot approve vendor access — OWNER approval is required
8. Operator responsibilities
- Assign SUPPORT role only to trusted staff
- Train staff on approve → activate → end workflow
- Review audit logs for anomalous support activity
- Document ticket linkage (`ticketRef`) where possible
- On tenant suspend, expect support sessions to be ended/revoked automatically
9. Incident or abuse
If unauthorized access is suspected, the OWNER should revoke active sessions and contact the operator at *[security@example.com — placeholder]*. See `INCIDENT_RESPONSE_POLICY.md`.
10. No certification
This policy describes administrative and technical controls in the product. It does not certify SOC 2, HIPAA, PCI DSS, or bank regulatory compliance.
*Draft only — Phase 2P-D aligned policy text with implementation. No support-access code changes.*