Techly Access Control Policy

Purpose

This policy sets out how access to Pyron and to the systems behind it is granted, limited, reviewed and removed, for customers and for Techly Operations Pty Ltd (Techly) staff.

Scope

• Access to a customer's workspace: by its own people, its guests, its automations and API keys, and by Pyron Support.
• Access by Techly staff to Techly's systems: its AWS accounts, its Kubernetes cluster and database, Cloudflare, GitHub, Google Workspace, and its monitoring and alerting tools.

The principles

• No by default. Nothing is reachable until a role or a share grants it. Pyron's permission engine answers no unless something says yes.
• Least privilege. People and services get what their work needs and nothing more.
• Every access is recorded. In a workspace, on its audit trail. In Techly's cloud accounts, by AWS CloudTrail.
• Removed promptly. When someone leaves or no longer needs access, it goes.

Access to a customer's workspace

The customer controls who can reach its workspace and what they can do.

• Roles and shares. What a person can see and do comes from their roles and from what has been shared with them, and access to a place flows down to everything beneath it. The customer's admins assign them.
• Two-step sign-in. People can add an authenticator app, a passkey or a code sent by email. Admins can make two-step sign-in required, for everyone or for chosen roles, from a date they set. It is optional until they do.
• Single sign-on. A workspace can sign its people in through Microsoft Entra ID, Okta, Google Workspace or another SAML or OpenID Connect provider, and can make it the only way in. A person is created the first time they sign in. There is no SCIM, so an admin deactivates a leaver in Pyron.
• Failed sign-ins. Repeated failed sign-ins are slowed down, both from the address they come from and for the person they name, and each further failure waits longer. The password and the two-step code both count. A wait ends by itself, guesses made elsewhere never hold up an address the person has recently signed in from, and a password reset ends it. Each pause is on the workspace's audit trail, and the person is emailed.
• Sessions. Admins choose how long people stay signed in (1, 7 or 30 days) and whether an idle session signs out (after 30 minutes, 2 hours or 8 hours).
• Guests. People outside the business sign in with a six-digit code emailed to them, which works only in the browser that asked for it, and see only what has been shared with them.
• Automations and API keys. An automation runs as an account an admin chose, and does only what its approved version declares. An API key belongs to a service account, is shown once, and is stored only as a hash.

A customer is responsible for deciding who gets which role, for requiring two-step sign-in or single sign-on if it wants them, and for deactivating people who leave.

Pyron Support

Pyron Support is Techly staff helping a customer.

• Sign-in. Support signs in only through Techly's own single sign-on, which enforces two-step verification. There is no Support password.
• Session. A Support session is time-limited and cannot be extended: after it ends, Support signs in again.
• What Support can do. Inside a workspace, Support has full access, so that it can fix what a customer cannot.
• The customer decides. Support access is on unless a workspace's administrators turn it off, which they can do at any time in Setup. Turning it off refuses every Support sign-in to that workspace and ends any Support session there, viewing as a person included, at its next request. Support cannot turn it back on: only the workspace's administrators can. Automations Support set up keep running, as the accounts they run as.
• When Support may use it. Only to give the support the customer asked for, to investigate a fault or an incident, or to operate the service.
• Recorded. What Support views and changes is recorded on the workspace's audit trail as "Support", and Techly's internal record names the person.

View as

A workspace admin, or Support, can view Pyron as a particular person, to see exactly what they see. A view-as session needs a reason, cannot change anything, ends within 60 minutes, and is recorded on the audit trail, naming who viewed and as whom.

Techly staff access

• AWS. Staff sign in to AWS through single sign-on with two-step verification, in sessions that expire, with a separate role for each job, including read-only roles that cannot read customer data. Nobody uses an account's root user in normal work.
• Emergency access. A separate, time-limited emergency role exists. Every use of it, and every sign-in as a root user, pages the on-call engineer and is treated as an incident until it is explained.
• The database. The production database accepts only short-lived sign-in tokens issued through AWS. No one holds a stored database password.
• The cluster. Changes to the Kubernetes cluster are applied with a dedicated cluster administrator role, not with emergency access.
• GitHub. Techly's GitHub organisation requires two-factor authentication. Changes reach production only through pull requests (Techly Change Management Policy).
• Google Workspace. Staff email runs on Techly's Google Workspace, which enforces two-step verification.
• Everything else. Staff use their own named account on every tool, with two-step sign-in wherever the tool offers it. Accounts are never shared.

Joining, moving and leaving

• Joining. A director approves each person's access, and the Technical Director grants only what their work needs.
• Leaving. On the day someone leaves, the Technical Director removes their access to every system above, starting with their Techly account (which ends their Support access) and AWS.
• Every quarter, the Technical Director reviews who has access to each system above, removes what is no longer needed, checks that two-step sign-in is on for every account, and records the review.

Who is responsible

• The Technical Director owns this policy, grants and removes staff access, and runs the quarterly review.
• The directors approve every grant of staff access.
• Each customer manages access to its own workspace.

Review

The Technical Director reviews this policy every year, and when the way staff reach production changes.