Skip to main content

Trust Center · Policies

Access Control Policy

Last updated: 2026-09-03 · Owner: Founder / CTO · Design Excellent Group SL

Who can reach production systems and customer data, how access is granted, verified and removed.

Purpose

Limit access to Eduspera systems and customer data to the people and services that need it, for as long as they need it.

Scope

Production application (Coolify-hosted Next.js), Supabase project (Postgres, Auth, Storage), Bunny Stream, Cloudflare, Emailit, Stripe, GitHub organisation and the secrets vault.

Principles

  • Least privilege. Every account has the minimum role needed. Learners and creators only see their own tenant through Postgres Row Level Security on every table; cross-tenant reads happen only through service-role paths that are logged.
  • Unique identities. No shared accounts. Service credentials are issued per integration and stored in the platform secrets vault (AES-256-GCM, single master key held in the hosting environment), never in the repository.
  • Multi-factor authentication. GitHub, Supabase, Cloudflare, Stripe and the hosting console require MFA. The Eduspera admin and creator zone enforces e-mail 2FA with a 30-day device trust; platform-admin actions that erase or export data additionally re-check that trust.
  • Server-side mutations only. The browser holds a read-only key. All writes go through server route handlers with schema validation.

Access lifecycle

  1. Grant — access is requested in writing, approved by the founder, and granted with the narrowest role available (e.g. school_admin scoped to one academy).
  2. Review — platform-admin and infrastructure access is reviewed quarterly; the list of accounts with production access is kept with this policy.
  3. Revoke — access is removed on the day a person leaves or a contract ends: SSO/identity disabled, personal tokens rotated, shared secrets rotated in the vault.

Monitoring

Sensitive actions (sign-in, role changes, enrollments, grading, payments, exports, erasure, SSO changes) are written to an immutable audit log that tenant admins can read and export. Failed sign-ins are rate-limited at the edge and the application.

Exceptions

Exceptions require written approval by the founder, a stated expiry and a compensating control, and are recorded in the audit log.