security(saas-control-plane): enforce platform/tenant separation, SoD, step-up, privacy, and support-access controls #879

Parent epic: #868
Depends on: #869, #871, #873, #876, #877

Context

A SaaS control plane introduces privileged platform actors who can influence many tenants. Existing tenant RBAC/ABAC/RLS remains essential, but platform operations need explicit scope, segregation of duties, break-glass/support access, step-up, privacy, and negative-test coverage rather than implicit elevated access.

Objective

Define and implement the cross-cutting security model for all control-plane modules without granting hidden database bypass or weakening tenant isolation.

Scope

• Define and seed explicit platform/control-plane permissions and roles, including separate responsibilities for:
  • catalog management;
  • tenant provisioning/lifecycle;
  • entitlement overrides;
  • billing/invoice operations;
  • payment/refund/reconciliation;
  • support/read-only investigation;
  • security/audit review.
• Add SoD rules for maker/checker and conflicting responsibilities, including at least:
  • catalog publish versus commercial approval where required;
  • invoice/credit/refund creation versus approval;
  • entitlement override versus audit review;
  • support access request versus approval;
  • requester versus lifecycle restore/exception approval.
• Add high-risk action classification and step-up requirements using available authentication assurance mechanisms.
• Implement explicit support-access grants with tenant scope, reason, expiry, approval, revocation, and audit.
• Ensure platform API/SSR/worker paths use authorization chokepoints and do not rely on UI hiding.
• Review DB role/grant matrices so no runtime path uses superuser/BYPASSRLS or unnecessary global-table writes.
• Add PII/data-classification matrix, masking, export controls, retention, legal hold, DSR/tenant data access considerations, and audit-event minimization.
• Add anomaly/alert signals for repeated cross-tenant denies, refund abuse, entitlement override spikes, support-access misuse, webhook failures, and secret/config errors.
• Add security-readiness checks for provider secrets, encryption keys, role grants, RLS, step-up policy, and unsafe configuration combinations.

Out of scope

• Replacing tenant RBAC/ABAC/RLS with a platform super-admin shortcut.
• Granting permanent support impersonation.
• Implementing a new identity provider or MFA system outside existing auth roadmap.
• Claiming regulatory or ISO certification.

Security requirements

• Default deny on every platform action.
• Tenant support access is scope-bound, time-bound, reason-bound, and independently auditable.
• Platform actors cannot directly access tenant-owned records unless a documented capability and authorization path requires it.
• Secrets and raw provider tokens are never stored in audit logs or user-visible diagnostics.
• Refund, credit, entitlement override, lifecycle restore, and provider configuration changes require idempotency, mandatory reason, high-severity audit, and step-up/SoD as classified.
• Break-glass use is exceptional, short-lived, alerted, and followed by review.
• All negative decisions use safe errors without tenant/resource enumeration.

Acceptance criteria

• Platform and tenant permission sets are mechanically distinct and default-deny.
• SoD conflicts prevent a single actor from completing configured high-risk maker/checker flows without an approved exception.
• Support access expires automatically and cannot be reused for another tenant.
• No control-plane runtime database role is superuser, owner, or BYPASSRLS.
• Cross-tenant denial tests cover API, SSR, worker, search, export, webhook, and reconciliation paths.
• High-risk actions require current assurance/step-up according to registry policy.
• Audit and alerts record operator, tenant scope, reason, result, and correlation without raw secrets/PII.
• Security readiness blocks go-live for missing secrets/keys, unsafe role grants, RLS gaps, or contradictory policy.
• Privacy/retention/export controls are documented and testable.

Testing

• Unit tests for role/permission/SoD/step-up/support-access policy.
• PostgreSQL integration tests for RLS, DB grants, expiry/revocation, and cross-tenant denial.
• Security/adversarial tests for IDOR/BOLA, privilege escalation, stale support grant, refund abuse, export leakage, raw webhook/secret exposure, and safe error behavior.
• Concurrency tests for support-access approval/revocation and high-risk actions.
• Browser E2E for platform role separation and step-up denial/success.
• Mutation tests: remove tenant predicate, expiry, step-up, or SoD rule and ensure tests fail.

Documentation

• Threat model, platform/tenant role matrix, SoD registry, support/break-glass SOP, privacy impact/data classification/retention matrix, incident-response guidance, ISO/OWASP control mapping, security-readiness docs, and changeset.

Dependencies

Must be applied to #878 admin surfaces and verified in #881 pilot.