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.
• 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 Google Workspace, which enforces 2-step verification, and only with a techly.au account. There is no Support password.
• Session. A Support session lasts at most 8 hours and cannot be extended: after that, Support signs in through Google again.
• What Support can do. Inside a workspace, Support has full access, so that it can fix what a customer cannot. A workspace cannot yet turn Support access off.
• 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 AWS IAM Identity Center, with permission sets for each job: an administrator set, a read-only set that cannot read customer data, a security audit set, and a one-hour organisation administrator set. Nobody uses an account's root user in normal work.
• Emergency access. A one-hour BreakGlass set exists for emergencies. 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 set, 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 and Support sign-in run on Techly's Google Workspace, which enforces 2-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.

Techly has one engineer, who holds administrator access to the production cloud accounts. Until the team grows, that is mitigated by the alerts on emergency access and on changes to the organisation's policies and its activity logging, and by the activity records kept in a separate archive account.

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 Google Workspace (which ends their Support access) and AWS.
• Every quarter, the Technical Director reviews who has access to each system (IAM Identity Center, GitHub, Google Workspace, Cloudflare, the monitoring and alerting tools, and the authorisation service's administration), 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 team grows.