Audited support access

Support Access & Audit

When to Use

Use when designing or auditing customer support troubleshooting access ("Login As" / support impersonation), internal platform admin tools, or tenant-facing security audit logs.

Zero Hidden Backdoors Rule

Never implement support or developer access by sprinkling if (user.isSuperAdmin) return true; across workspace authorization checks! Unscoped superadmin bypasses:

• Accidentally expose all tenants' data in normal list/search UI views.
• Attribute mutations to the customer or hide who actually performed the action.
• Violate SOC 2, ISO 27001, GDPR, and enterprise tenant trust requirements.

1. Controlled Support Impersonation & Break-Glass Access

Explicit Elevation & Tenant Consent

• Dedicated Elevation Flow: Support access must require an explicit elevation action specifying:
  • Target workspace_id (and optionally target user_id being assisted).
  • Support ticket / reason reference (reason: "Ticket #4821 — debugging webhook failure").
  • Access mode: Read-Only by default (mode: 'read_only'), requiring explicit higher-tier approval for write access.
  • Strict TTL: Hard auto-expiration (e.g., 15–60 minutes) with an immediate "End Support Session" revocation button.
• Tenant Consent Grant: Where supported by the product's security model, verify that a workspace owner/admin has enabled temporary support access (support_access_expires_at > NOW()) and allow the workspace owner to revoke an active support session at any time.
• Persistent Visual Banner: Whenever a session is in support/impersonation mode, expose impersonatorId and mode to the UI so a prominent, non-dismissible banner displays the active target workspace and read-only/logged status.

2. Dual-Actor Attribution (actor + onBehalfOf)

Never overwrite actor_id with the impersonated customer's user_id. Every context object and audit record during support access must record both principals:

{
  "timestamp": "2026-10-20T04:15:00Z",
  "workspaceId": "ws_0192a...",
  "action": "webhook.endpoint.updated",
  "actor": {
    "id": "staff_018f...",
    "type": "support_impersonation",
    "reason": "Ticket #4821"
  },
  "impersonatedUser": {
    "id": "usr_0190..."
  },
  "resource": { "type": "webhook", "id": "wh_881" },
  "ipAddress": "198.51.100.42"
}

3. Immutable, Tenant-Scoped Audit Logs

• Mandatory Audit Events:
  • Workspace lifecycle (workspace.created, suspended, deleted, owner_transferred).
  • Membership & access (member.invited, invite.accepted, invite.revoked, member.role_changed, member.removed).
  • Security & credentials (api_key.created, api_key.revoked, sso.updated, integration.connected, support.session.started, support.session.ended).
• Append-Only Integrity: Audit log tables must forbid UPDATE and DELETE from application roles (except complete tenant erasure under documented compliance rules) and never log raw secrets, tokens, or passwords in metadata diffs.