How Do We Secure AWS Organizations?

AWS Organizations allows you to manage multiple accounts under one management account, but how do we ensure they are secure?

Creating A New “child” Account.

Log in to the console of the account you are expecting to be the “master” and search for “AWS Organizations.”

Provide a valid email and create a new AWS account (you may need to confirm the email in use with your main account before AWS will create the child account).

How Do We Access The New Account?

Now that we’ve created the child account, you’ll want to access it. As part of the Organizations account creation process, you will of noticed AWS informed you it would add the “OrganizationAccountAccessRole” role. Let’s check what permissions it has and the trust policy assigned.

Role Policy: (Admin access)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Trust Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::matthew_account:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

What does this actually translate to? Anyone within the “matthew” account, which is the master account in our example, within enough permissions to execute sts:AssumeRole (unbounded) can now access our child account as an admin user. That’s not ideal, to correct this, one of the first actions you should take is limiting the trust policy, so there is a condition on the origin role.

The code block below ensures that only one user can assume this role. In this case, user “LiJuan” from the account “111122223333”.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam::111122223333:user/LiJuan"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

Now we are in a position where only one user can gain admin rights in our child account. This is one example of limiting access to the newly created role. However, integrating this role and the account in general with an external SSO provider (or AWS-managed one) would be another good way of securing this role.

Logging

Now that you’ve created and accessed your account, we probably want to start thinking about activity logging. To do this, we will use CloudTrail. CloudTrail logs all API activity that is made within the account. For example, if a user created a new SSH key pair, CloudTrail would record this.

We have 2 options on how to proceed, create an organization trail so we can correlate all our logs in one place, or set up a trail just in the child account. The correlate option is much better from a security standpoint as it reduces the overhead of managing CloudTrail independently in what could be hundreds of accounts. However, if you have this many AWS accounts, you’d want to create a “security” account to manage all this, but that’s a story for another time!

Now that CloudTrail is enabled for all accounts, this will include our “child” account, and we can verify this by opening the Cloudtrail console in the child account:

If you are an enterprise, then sending CloudTrail logs to a log analytics service like Splunk would also be a good step to take.

Account Security?

Now that logging is enabled, we want to think about the general security of the new account. This is where GuardDuty comes in.

GuardDuty is a threat detection service which monitors various aspects of our AWS account and in some cases even automatically takes action to block malicious actions with the account.

Enabaling GuardDuty is slightly different to CloudTrail as a few more manual steps are required. Head to the GuardDuty console in the master account.

Once GuardDuty has been enabled head to the settings and you will notice a box called “Delegeated Administrator” which is expecting an accountID. Enter your master accountID here and press “delegate“

Once this has been added, search for the “Accounts” screen, this should be in the left pane under settings. All account(s) within the current organization should automatically appear.

From here you have 2 options on how to enable GuardDuty in the child accounts

• Enable “Auto-Enable” (recommended). This option causes any accounts currently in or added to the organization in the future to automatically be enrolled into GuardDuty. (Red Box)
• Manually add the account to GaurdDuty. This can be done by selecting the account and clicking the “Actions” section on the top right. Then press “Add member” (Blue Box)

Once enabled re-login to the child account to make sure everything has worked correctly.

Sumary

After all that what did we actually do?

• IAM access to our account
  • We’ve limited who can access our child account
• Logging
  • We’ve enabled CloudTrail in the Master account and ensured it’s logging all actions from the child account(s)
• Security
  • GuardDuty has been setup in the Master account and we’ve invited our child account.

Our organization is now in a good place to start configuring resources within. However, don’t be fooled into thinking this is enough to be secure. There is still much more things to watch out for when adding resources to the account.

Speaking of which…

Further Reading

Check out some of my other blog posts about securing your AWS account here

The seccloud.wiki also has a page on GuardDuty here and CloudTrail which can be found here

AWS Documentation:

Organizations here

CloudTrail here

GuardDuty here