Red Mesa Studios

Access Control Policy

Red Mesa Studios LLC
Owner and responsible party: David Barkman, support@redmesastudios.com
Last reviewed: September 3, 2026 · Review cadence: annually, and on any material change

1. Scope

In scope:

• The production server, the applications running on it, and their databases.
• The macOS workstation used to administer them, which holds the SSH key to production and the password manager.
• Third-party services holding company or consumer data.

2. Principle

Access is granted on the principle of least privilege. Nothing is granted by default. Each account and each credential is limited to what its task requires, and no further.

3. Authorization

• Access to production systems and to consumer data is authorized by the owner alone. No other person may grant, extend or approve it.
• There are no employees or contractors with system access. Any future grant is a decision the owner makes and records.
• Third parties are given access only where a service cannot be delivered without it, and only to the data that service requires.

4. Granting access

• Human access to the server is granted by adding a public key. Passwords are not used for interactive login, and shared or generic accounts are not created.
• Application access is granted by creating a named account. There is no self-registration.
• Access is granted for a stated purpose. A credential created for one purpose is not reused for another.

5. Authentication requirements

• Server access requires an SSH key. Password authentication and root login are disabled.
• SSH private keys are protected by a passphrase.
• Application accounts require a password and a second factor.
• Non-human authentication uses cryptographic credentials, being SSH keys, TLS certificates and API tokens, rather than shared passwords.
• Credentials are held in a password manager. Application secrets are held in environment files readable only by the service account, never in source control.

6. Privileged access

• Applications do not run as root. Each service runs as an unprivileged system user and is confined to its own directory and database.
• Administrative escalation is via sudo, logged, with a time-limited authentication window.
• Database access is not exposed to the network. The database listens on localhost only.

7. Review

• Access is reviewed weekly. The automated system audit checks accounts, authentication settings and privilege configuration, and the weekly server review covers access alongside it.
• Authentication logs are reviewed daily and reported. Repeated failed logins are blocked automatically.
• A review that finds access no longer required removes it in the same session.

8. Revocation

• Access is revoked as soon as it is no longer required, by removing the key or the account on the server and revoking the credential at any third-party provider.
• A credential believed to be exposed is revoked before any other step is taken, ahead of investigating how it was exposed.
• Revoking a bank connection at the data provider invalidates the stored token immediately, and is the first action taken if that token is suspected of being compromised.

9. Known gaps