pic

AWS Security Best Practice #7: Use IAM Roles with STS AssumeRole

We are more than half way through the top ten, so let’s finish up the IAM discussion before jumping into some of the top AWS configuration areas! This post will wrap up our discussion of individual people controls leveraging the IAM service by leveraging roles to simplify and create a more secure environment.

Earlier in the series, we covered how and why you should use roles for EC2 instances.  The premise for this was to make it easier for your resources to communicate securely and reduce the management burden by leveraging the AWS Security Token Service.

How often is it that you are able to both become more secure and simplify management?  While they sound like opposite pairs, they are actually what we strive for.

Any time you can make it easier for users to be more secure, you are more likely to get adoption.  Whereas, if you make security too complicated, it can actually result in less security, in practice.

As an example, if you forced all users to use a randomly-generated 24-character password that was impossible to memorize, how many would revert to writing their password down or storing it someplace that may not meet security guidelines?

Sure, the password itself may seem to increase security, but in practice, it actually creates bad habits and reduces security.

Today, we are going to extend the roles for EC2 and talk about using roles for your IAM users. Again, this is to make it more secure and easier to maintain that security.  In this example, I’ll use the Evident.io Demo AWS accounts.

When Evident was just starting out as a company, there was a single AWS account used to demonstrate the Evident Security Platform (ESP) and its ability to create custom validations, security checks and integrations. A single AWS account with a couple engineers, that should be pretty easy to secure right?

We disabled root API access and ensured there were no secret keys. Then for the two admins, we enabled MFA tokens. For some of the sales folks, we even keys that needed to be rotated.

Now, ESP was designed to be an enterprise platform and support customers with ten’s, hundreds and even thousands of AWS accounts (there’s a blog about the segregation of duties on ESP.)

To extend our demo, we added a handful of AWS accounts and, by this time, the number of people that had access to the demo account was growing. We could go through each and every AWS account and create new users, generate a password, and restrict that user’s permissions much like we had done in the beginning, but that seemed like a lot of repetitive, manual steps.

A better option was to leverage the users we already created and secured, and just enable them to have access to the additional accounts. It sounds pretty easy, and in practice, it is.

AWS provides a quick walkthrough to help you get started in delegating access to AWS accounts from IAM users in another account. Now, in many cases, you may even have a master AWS account that has no resources running in it that is just used for administrative control and billing access.

In our case, we extended the one AWS account to allow the engineers and sales folks the same access to the other accounts with a few mouse clicks in the console.

If you have more than one AWS Account, it is worth the time to go through the steps outlined by AWS to get a good feel for what you can accomplish by leveraging roles with your IAM users.

A quick recap of our past AWS Best Practice posts:

  1. Disable Root API Access Key and Secret Key
  2. Enable MFA Tokens Everywhere
  3. Reduce Number of IAM Users with Admin Rights
  4. Use Roles for EC2
  5. Least Privilege: Limit what IAM Entities Can Do with Strong Policies
  6. Rotate all the Keys Regularly
  7. Use IAM Roles with STS AssumeRole Where Possible
  8. Use AutoScaling to Dampen DDoS Effects
  9. Do Not Allow 0.0.0.0/0 Unless You Mean It
  10. Watch World-Readable and Listable S3 Bucket Policies