Access control policy
Version0.1 draft
OwnerInfrastructure Owner
ReviewYearly
Applies toEvery in-scope system, and every workforce system that can reach one (source host, cloud console, DNS, registrar, email, password manager, compliance platform)
Principles#
Unique identity, least privilege, MFA, approval before access, removal on departure, and a regular review that actually changes something.
Workforce access#
- Unique named accounts for every person on every system. Shared accounts are forbidden. Service accounts are allowed only for machines, have a named owner, and cannot sign in interactively ACC-02.
- MFA is enforced (not merely available) on the workforce identity provider, GitHub, Cloudflare, the registrar, the cloud console, email, the password manager, and the production access path. Phishing-resistant methods (passkeys, hardware keys) are preferred for administrators. SMS is not accepted for administrators ACC-03.
- Request and approval. Access is requested in a ticket naming the system, the role, and the reason. The system owner approves. The approval is recorded before the grant ACC-04.
- Least privilege. Default roles are read-only or developer. Administrator, root, sudo, database superuser and cloud owner roles are held by named individuals listed in the privileged access list ACC-07.
- Removal within 1 business day of departure or role change, under 12 ACC-05.
- Quarterly review. The Security Owner exports the account list of every in-scope system, each system owner confirms each account or removes it, and the signed review records the before list, the after list, and every change ACC-06. A review that never removes anything over a year is itself examined.
Production access#
- Production is administered only through [the chosen path: cloud session manager, or a bastion with SSH certificates or keys, behind MFA]. Password SSH is off. Root login is off. Database ports are never exposed to the internet ACC-08.
- Access to customer content in production (reading a mailbox, opening a file, querying a customer's rows) is allowed only for support, security or legal reasons, is logged, and where practical is done with the customer's knowledge.
- Every privileged action is logged centrally and attributable to a person OPS-01.
- Break-glass credentials exist for when the identity provider is down. They are sealed in the password manager, their use pages the Security Owner, and they are rotated after every use.
- Coding agents never hold production credentials of their own. See 17.
Customer authentication#
Gate and every in-scope product follow the security defaults in the compliance prompt: argon2id or bcrypt, breached-password check, minimum length 8, no forced rotation, MFA available to every user and enforced for workspace administrators, rate-limited sign-in, OTP and reset, httpOnly Secure SameSite cookies, session revocation, server-side authorisation on every object, tenant scoping at the query layer ACC-09, ACC-10.