🎓 Shortcut to SOC 2: Use AWS Identity Center for Auth

Technical content rating: 🎓 basic coding literacy assumed

When you're setting up your AWS account — especially for your first time — access controls can be quite an intimidating consideration. By now, you probably know not to log in with your root credentials … right? Right? But the furthest you've gone beyond that may just be creating IAM users for your team. There's a better way!

At the early stage of your company, you should be spending your innovation tokens on building the valuable features your customers want. But if you're building a SaaS business, then SOC 2 compliance is probably in your future. SOC 2 certification will require you to design around these security principles:

• Principle of Least Authority: your team should only have the authorizations they need to perform their job function, and no more. You need to limit the impact of accidents and malice.

• Role-based Access Control (RBAC): you should not have long-lived credentials floating around your team, or authorizations assigned to specific identities. These create additional attack vectors and ways to shoot yourself in the foot, if for example you forget to de-provision authorizations when a member of your team leaves.

• Single sign-on (SSO): ideally, you should have a single identity provider (IdP) that implements your password and multi-factor authentication (MFA) policies in one place. Then the other services your team needs to use can rely on your IdP for authentication, and derive an access token via OAuth or SAML.

• Just-in-time (JIT) access for production: we won't delve into JIT access in this post, but be aware that you'll eventually need to lock your production systems and data down like Fort Knox. Access to production only happens on a need-to-have-it basis.

There are services built on top of AWS that will help you achieve these goals. Okta is commonly used at larger companies. My personal favorite is Opal. However, these services are quite expensive and take some time to learn and deploy.

Enter AWS Identity Center. Here's how it works:

1. You configure an "identity source" (IdP) for Identity Center that's an external provider: your Google Workspace instance, authenticated by SAML

2. You add an AWS app to your Google Workspace, again with SAML authentication

3. You configure "permission sets" (roles) in Identity Center. The predefined AdministratorAccess, PowerUserAccess, and ReadOnlyAccess roles are good ones to start with.

4. You create groups for your team. We have an Engineering group and an Admin group. Aim to minimize the number of members of the Admin group.

5. For each of your AWS accounts (you probably only have one), you provision access for your Identity Center groups and assign which roles they're allowed to assume. We allow our Engineering group to assume the PowerUserAccess and ReadOnlyAccess roles, and we allow the Admin group to assume AdministratorAccess.

6. Finally, add your users to Identity Center and put them in the appropriate group(s), with the username being the email address that your IdP can authenticate. (You can automate user provisioning, but it's not worth the time at your early stage and small scale.)

This should all take around 30 minutes.

Now that you've configured Identity Center, here's how your team will use it:

1. Your team signs into AWS via your access portal URL, which looks something like https://x-xxxxxxxxxx.awsapps.com/start. For the AWS CLI, you configure your ~/.aws/config profile to authenticate using your Identity Center portal.

2. The AWS sign-in automatically redirects your team to Google auth and returns to AWS

3. Your team is given the choice of roles to assume: ReadOnlyAccess, PowerUserAccess, or AdministratorAccess if they have permission. Your team member chooses the role with least privilege needed to achieve their goal.

4. The authenticated session times out automatically after a configurable duration, so you never need to worry about dangling credentials or lost passwords etc. — Google manages the authentication for you.

And that's it! Using AWS Identity Center won't get you all the way to SOC 2. You'll still need to implement additional policies to lock down your production data and systems. But Identity Center will help you maintain good SOC 2 hygiene without any extra investment of time, and it may be one fewer thing you'll need to rebuild in order to get SOC 2.

p.s. what if you're already created IAM users for your team?

No worries. Just set up Identity Center and then de-provision your IAM users. De-provisioning IAM users can be an interesting exploration of skeletons in your IAM closet, where you find certain people or processes depend on special permission grants that they shouldn't have.