Access

Deprecated

This page is deprecated. Policies have moved to Vanta; this copy is kept for reference and is pending removal.

2026.1

Access to Changineers systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, and any other entity, is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization’s information systems.

Policy Statements

Access Control Policy

Changineers policy requires that

(a) Access to all computing resources, including servers, end-user computing devices, network equipment, services and applications, must be protected by strong authentication, authorization, and auditing.

(b) Interactive user access must be associated to an account or login unique to each user.

(c) All credentials, including user passwords, service accounts, and access keys, must meet the length, complexity, age, and rotation requirements defined in Changineers security standards.

(d) Use strong password and multi-factor authentication (MFA) whenever possible to authenticate to all computing resources (including both devices and applications).

(e) MFA is required to access any critical system or resource, including but not limited to resources in Changineers production environments.

(f) Unused accounts, passwords, access keys must be removed within an established timeframe.

(g) A unique access key or service account must be used for different application or user access.

(h) Authenticated sessions must time out after a defined period of inactivity.

Access Authorization and Termination

Changineers policy requires that

(a) Access authorization shall be implemented using role-based access control (RBAC) or similar mechanism.

(b) Standard access based on a user’s job role may be pre-provisioned during employee onboarding. All subsequent access requests to computing resources must be approved by the requestor’s manager, prior to granting and provisioning of access.

(c) Access to critical resources, such as production environments, must be approved by the security team in addition to the requestor’s manager.

(d) Access must be reviewed on a regular basis and revoked if no longer needed.

(e) Upon termination of employment, all system access must be revoked and user accounts terminated within the defined, predetermined timeframe.

(f) All system access must be reviewed at least annually and whenever a user’s job role changes.

Shared Secrets Management

Changineers policy requires that

(a) Use of shared credentials/secrets must be minimized and approved on an exception basis.

(b) If required by business operations, secrets/credentials must be shared securely and stored in encrypted vaults that meet the Changineers data encryption standards.

(c) Usage of a shared secret to access a critical system or resource must be supported by a complimenting solution to uniquely identify the user.

Privileged Access Management

Changineers policy requires that

(a) Users must not log in directly to systems as a privileged user.

• A privileged user is someone who has administrative access to critical systems, such as a Active Directory Domain Administrator, root user to a Linux/Unix system, and Administrator or Root User to an AWS account.

(b) Privilege access must only be gained through a proxy, or equivalent, that supports strong authentication (such as MFA) using a unique individual account with full auditing of user activities.

(c) Direct administrative access to production systems must be kept to an absolute minimum.

Controls and Procedures

Password Management

1. User IDs and passwords control access to Changineers systems and must not be disclosed to anyone. Users must not share credentials or access systems using another user’s account.

2. Google Workspace is the primary identity provider and enforces Changineers’s password requirements on workforce accounts.

3. Passwords for business applications that do not federate through Google Workspace are stored in the Changineers 1Password organisation and shared through 1Password vaults where necessary. Personal password managers are not used for business credentials.

   • 1Password access is protected by the account holder’s Secret Key and Master Password.
   • MFA is required on every 1Password account.

4. Default system, application, and vendor-provided passwords are changed before deployment to production.

5. Any automatically generated password must be changed on first use.

6. Passwords stored by Changineers systems are hashed with a salted cryptographic hash function (SHA-256 or stronger). Passwords held in non-hashed form are encrypted at rest per Data Protection. Passwords in transit are encrypted per the same policy.

7. All credentials associated with a departing employee are revoked following the Employee Termination Procedures.

8. If a user believes their credentials have been compromised, they must immediately notify the Security team.

Single Sign On

• Changineers uses Google Workspace as its primary Identity Provider (IdP). Google Workspace is the authoritative source for employee identity and authentication.

• New business applications must support single sign-on (SSO). Exceptions require Security Officer approval and are tracked in the vendor register.

• SSO uses SAML 2.0 or OpenID Connect between Google Workspace and the target application. For AWS, SCIM also synchronises users and groups from Google Workspace into AWS IAM Identity Center.

• Changineers will not configure SSO to target applications unless they score a “B” rating or higher on the Qualys SSL Labs benchmark.

• The Security Officer is responsible for administration of the IdP and SSO integrations, including user and access provisioning. Administrative privilege to a specific application may be delegated to an application owner.

Multi-factor Authentication

Multi-factor authentication (MFA) is enabled wherever a system supports it.

• Workforce access to Changineers business systems is federated through Google Workspace, and MFA is enforced at the Google Workspace level.
• AWS access inherits the Google Workspace MFA challenge through AWS IAM Identity Center.
• AWS root users are protected by a hardware MFA device.
• End-user access to the platform via Cognito supports MFA (SMS or TOTP via an authenticator app). Tenants may require MFA for their users.

Approved MFA methods are:

• Hardware security keys (required for AWS root users).
• Time-based one-time passwords (TOTP) via an authenticator app.
• Push notifications from a supported authenticator app.
• SMS one-time passcodes, where other methods are not supported by the service.

Access to AWS Accounts and Resources

Access to Changineers AWS accounts is permitted through federated temporary credentials only. No long-lived IAM users, passwords, or access keys are provisioned for end-user access, either to the AWS Console or the AWS CLI.

Two controls enforce this:

1. A DenyIAMAccessKeys Service Control Policy (SCP) at the AWS Organizations level blocks iam:CreateAccessKey and iam:UpdateAccessKey in member accounts. Any exception requires Security Officer approval and is documented in Terraform.
2. AWS IAM Identity Center, federated with Google Workspace, is the sole means of human access to AWS.

AWS Console Access

• Human access is granted via AWS IAM Identity Center, federated from Google Workspace using SAML for authentication and SCIM for user/group provisioning.
• Users authenticate via Google Workspace (username, password, and MFA enforced by the Google Workspace policy). Identity Center then presents the portal for selecting a target account and permission set.
• On selection, Identity Center issues temporary credentials via AWS STS and opens a console session in the target account. Sessions are limited to 12 hours, after which re-authentication is required.

The permission sets available are:

Permission set	Purpose
AdministratorAccess	Full admin access; assigned sparingly to the Engineering and Security leads.
ReadOnlyAccess	AWS-managed read-only policy; does not grant read access to data (e.g. S3 object contents).
CloudWatchReadOnlyAccess	CloudWatch metrics, logs, and dashboards only. Used for routine troubleshooting.

Assignments of users → accounts → permission sets are managed in Terraform.

AWS CLI/SDK Access

• Developers obtain temporary credentials from AWS IAM Identity Center for local CLI and SDK use via Granted. Credentials expire with the SSO session and must be refreshed by re-authenticating.

CI/CD Access

• GitHub Actions assumes short-lived roles in AWS via OIDC federation. No static AWS credentials are stored as GitHub secrets.
• Each CI/CD role has a least-privilege policy scoped to the specific repository it serves.
• Role trust policies constrain sts:AssumeRoleWithWebIdentity to the expected GitHub organization and repository via the token.actions.githubusercontent.com:sub claim.

Root Account Access

AWS root user credentials for each account are held for break-glass use only. Root credentials:

• Have a hardware MFA device registered.
• Are stored in the Security Officer’s password manager and are not shared.
• May only be used for tasks that cannot be performed via Identity Center, such as closing an account or changing the root email.

Any root credential use is visible in CloudTrail (delivered to the centralised audit log bucket in the Security account) and generates a GuardDuty finding.

Troubleshooting / Support Access

Engineers troubleshoot using CloudWatch Logs, Metrics, and X-Ray under CloudWatchReadOnlyAccess. If broader read is needed to inspect resource configuration, they use ReadOnlyAccess instead. Both are bounded by the 12-hour SSO session.

Any action requiring AdministratorAccess in Production must be preceded by an approved change management ticket. See the Production Change Management process.

Remote Access

Changineers operates fully remote under a zero-trust posture: every service that accesses Changineers resources authenticates the user and the device, and network location is not treated as a trust signal.

Tailscale is used where engineers need device-to-device access (for example, reaching a laptop’s local development server from another device on the same user’s tailnet).

Service Accounts

• Application-to-application communication using service accounts is limited to cases where it is necessary.

• Within AWS, service access is granted through IAM Roles with scoped policies wherever possible. Role and policy changes are managed in Terraform and follow the same pull request and CI process as any other infrastructure change.

• Generic shared accounts for human use are not provisioned on Changineers systems.

Employee Workstation / Endpoints Access and Usage

All workstations at Changineers are company owned, using one the following approved hardware vendors and operating systems:

• Apple, Dell, or Lenovo
• macOS, Linux (Ubuntu or Debian), or Windows 10

1. Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through organization’s system.
3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
4. Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
5. Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
6. Workstation hard drives will be encrypted using FileVault (macOS), BitLocker (Windows) or equivalent.
7. All workstations must have host firewalls enabled to prevent unauthorized access unless explicitly granted.
8. All workstations must have endpoint security software installed and actively running, if supported by the operating system.

Revision History

Date	Summary	Approved by
2020-01	Initial revision.	James Gregory
2026-04-24	Refreshed AWS access procedures and adopted MFA, remote access, service account, and password management procedures.	James Gregory