IAM and privileged-access controls
Identity boundaries
| Identity type | Authentication and scope | Privilege rule |
|---|---|---|
| Application user | Managed password authentication with a signed session | Tenant, hierarchy, mapped scope, role, record ownership, and database policy determine access |
| Leadership and administration | Same managed identity boundary with elevated application roles | Elevated menus do not replace backend authorization; sensitive actions require server or database enforcement |
| Serverless workload | Provider-managed runtime with server-side secrets | Uses elevated credentials only for a defined operation after caller and input validation |
| Cloudflare administrator | Cloudflare account identity | Limited to personnel who manage domains, deployments, edge controls, and rollback |
| Supabase administrator | Supabase organization or project identity | Limited to personnel who manage data services, identities, backups, logs, and platform configuration |
| Monitoring administrator | Monitoring-platform identity | Limited to personnel who triage releases, telemetry, and incidents |
Control requirements
- grant least privilege and separate routine application use from provider administration;
- use named human accounts; do not share administrator credentials;
- require MFA for provider administration and review recovery methods;
- keep privileged service credentials only in protected server or deployment configuration;
- rotate secrets after exposure, personnel change, supplier incident, or defined expiry;
- review privileged access at least quarterly and after role changes;
- log privileged changes and investigate unexplained access;
- revoke access promptly when no longer required.
Identity lifecycle
| Event | Required control action | Verification evidence |
|---|---|---|
| Joiner | Create a named identity after approved role, tenant, and business-scope authorization | Request, approver, assigned role, MFA state where applicable, and first-use confirmation |
| Mover | Recalculate access when team, tenant, level, reporting line, or duties change | Old-versus-new access review and explicit removal of privileges that no longer apply |
| Leaver | Disable application access, revoke managed identity access, transfer owned work, and remove provider membership | Deactivation time, reassignment result, provider removal, and unsuccessful post-removal access test |
| Privilege elevation | Use a dated request with purpose, target scope, approver, and expiry | Before-and-after role evidence and completion or revocation time |
| Emergency access | Use a separately protected break-glass path only for declared operational need | Incident reference, authorizer, actions performed, credential rotation, and post-use review |
| Service credential rotation | Create replacement, deploy to the approved workload, verify, revoke predecessor, and monitor | Rotation date, affected integrations, successful validation, and predecessor revocation |
Privileged-operation invariants
- Provider administration uses named identities; shared personal accounts are not an acceptable operating model.
- Application-level leadership or menu visibility does not grant provider administration.
- A trusted workload validates the initiating actor and business target before using elevated credentials on the actor's behalf.
- Administrative recovery paths retain incident recording, authorization, and post-use review.
- Access reviews remove orphaned, inactive, duplicate, expired, or excessive privilege.
Periodic access-review evidence
| Review field | Required content |
|---|---|
| Identity | Named person or workload, provider/application boundary, employment or service status, and last activity where available |
| Entitlement | Tenant, application level, provider role, resource scope, inherited groups, service credential, and emergency access |
| Business justification | Current duties, approved request, segregation-of-duties consideration, and accountable manager |
| Authentication strength | MFA state, recovery path, credential age, device or SSO condition where applicable |
| Decision | Retain, reduce, suspend, remove, rotate, or investigate with due date and approver |
| Verification | Access removal test, credential revocation, transferred work, closed session, and review completion time |
Provider access is reviewed separately from application roles because a high application level does not imply platform administration, and platform administration does not create a legitimate business need to read customer records. Workload credentials are reviewed by purpose and dependent service, not assigned to a human role as if they were interactive users.
Current evidence and gaps
Application role and tenant enforcement is documented separately and current database controls were reviewed read-only. The account-level administrator roster, MFA enforcement, access-review records, emergency-access procedure, secret-rotation dates, and Cloudflare/Supabase audit logs were not available. Those items remain required operational evidence.