Imagine, your company has just started to move to the cloud and has decided to put an important application in AWS. It’s your job to ensure that the data in your AWS account is secure and has limited access. You’ve begun an IT Security Audit of AWS. You ask a few questions of the DEVOPS manager and he tells you that they are using account 123456789 for their important application. As a good security professional you email and tell him you will need to get a list of all the users for that account. Priority one is to conduct an audit and ensure only appropriate people have access to your AWS environment. The DevOps manager emails you back this screen shot.
You review the list of users. Five total IAM users, no generic IDs. The team has (surprisingly) done a pretty good job of keeping access limited and appropriate. You file your Security Audit report with management and pat yourself on the back. Unfortunately, you’ve only scratched the surface on who really has access to your AWS account. Here are the top 4 hidden ways to access an AWS Account and its data that you’ll want to check.
#1 AWS Roles
The primary mechanism to access an AWS Account without a direct IAM user account is via an IAM Role. An IAM Role can be used in many different scenarios. A role with some sort of trust relationship is needed in order to gain access. It is the first place you should look after reviewing the IAM users. You’ll want to conduct a detailed assessment of every role and tie those roles, especially ones that grant access from other accounts or the Internet. This is what it might look like. Note that the Trusted entities lists an account number. That account has access to YOUR account.
#2 Single Sign On
It can be a pain to manage both AWS IAM users and all the other user stores – Active Directory, Azure, etc. So to make things easier your AWS environment might be configured for “Single Sign on” or “Federated Access”. When this is configured, users are managed external to AWS. This means that your IAM user report might only show 5 users but with Single Sign on there could be hundreds of other people who have access into your account. To top it off, their password settings are enforced externally, so you’ll want to check that as well.
#3 Root Account
Every AWS account is setup with a “root account”. This ID is the email address provided by whoever first setup the account. This user always has full administrator access to the entire environment. If you’ll notice, there is no root user in the above screen shot! That’s because the AWS root user never shows up in the list of AWS IAM users. Another hidden way to gain access into the AWS environment.
#4 AWS Organizational Account Access
It is common for organizations to utilize many AWS accounts for various reasons. In order to manage all of them more easily they can be linked using “AWS Organizations”. This is a hierarchical structure with a “master” AWS account as the leader and various sub accounts. Users can be configured within the master account to access the sub account. The root user in the master account always has the ability to gain access to the sub account. This will be an important relationship to understand and review as part of any AWS Security review.
Wrap Up
As you can see, our initial IT security assessment of our AWS environment was woefully incomplete and inaccurate. It takes a lot more effort to get the full picture for AWS. Luckily there are tools and processes that can help quickly gather this information for you. You can try AWS’s documentation or AWS Expert, by BlackBox Auditor was built for just this task. With just a couple of clicks you can get a report that will highlight all of these potential relationships, along with many more key security tests and data for your AWS environment. Email us and we’ll be glad to give you more information on how you can review your AWS environment simply and easily without having to be an AWS Expert. Sales@BlackBoxAuditor.com