Identity and access

Most cloud breaches start with a leaked key or an account with too much power. These rules decide who and what can change the infrastructure. Keys inside the app and database users are covered in Give each key the least power and the app database role.

Required

• Sign people in through single sign-on

  Required

  Give people cloud access only through the company identity provider, with two-factor login. Create no separate cloud user with a password for a person.

• Keep no long-lived access keys

  Required

  Use short-lived credentials for every person, pipeline and service. Delete every static access key, and alert when a new one appears.

• Give every role the least it needs

  Required

  Write every role's permissions in code, limited to named actions on named resources. Never grant every action on every resource, except to the break-glass role.

• Lock the root account away

  Required

  Protect every cloud root or owner account with a hardware key or passkey, give it no access keys, and alert on every sign-in.

• Keep tested break-glass accounts

  Required

  Keep two emergency admin accounts that work when single sign-on is down. Store their factors offline, alert on every use, and test them twice a year.

• Grant admin access for hours only

  Required

  Give admin rights in production only on request, with a reason and an approver, for 8 hours at most.

Recommended

• Separate the roles for plan and apply

  Recommended

  Give pull requests a read-only role that can only plan. Give the write role only to the main branch in a protected environment. Give the app its own runtime role.