Over Bank Holiday Weekend I decided to spend some time further locking down my AWS accounts, over the years AWS has made it a lot easier to manage multiple accounts thanks to AWS Organizations.
What is AWS Organizations?
AWS Organizations helps you centrally govern your environment as you grow and scale your workloads on AWS. Whether you are a growing startup or a large enterprise, Organizations helps you to centrally manage billing; control access, compliance, and security; and share resources across your AWS accounts.
Being able to create new AWS accounts and centrally manage the billing is great, it makes your life much simpler as it is all in one place. The only problem I’ve found with AWS Organizations is that when you do create a new account, in order to set up a password and add MFA you have to do a password reset for that new account.
Here is an example of what you might see in the billing dashboard once you have a few accounts set up.
You get a nice overview of how much you are spending per account and you can even break it down into specific resources. This is the most basic feature of AWS Organizations, there are a few other things you can set up such as:
- AWS Artifact
- AWS CloudTrail
- AWS Config
- AWS Directory Service
- AWS Firewall Manager
- AWS Resources Access Manager
- AWS Single Sign-On
- AWS License Manager
- AWS Service Catalog
As most of these are for enterprises I don’t tend to use them, the ones I recommend looking into are AWS CloudTrail, AWS Config and AWS Firewall Manager.
AWS account structure
The way I have decided to structure my AWS accounts can be seen in the diagram below.
This account only holds IAM users, once placed in groups the only permissions these users have is to manage their own credentials, MFA and to switch roles into different accounts.
This is the billing account and the owner of the organization; there should be very little to none activity in this account so you might want to alert on any CloudTrail activity.
DEV / PREPROD / PROD
These are the environment accounts, any code or infrastructure deployed in these accounts should be consistent.
In this account, you might to deploy resources which need to be used by all the environments. It is common to run tools and shared services from this account.
This is a locked down, write only account used for audit purposes. You should send logs, CloudTrail, etc into this account. Don’t forget GDPR and only hold what you need!
Improving security by adding MFA
An easy way you can improve your security with this AWS account structure is by enforcing MFA, you can do that by checking for MultiFactorAuthPresent in the cross-account roles. The reason why this works so well is that even if someone manages to leak their AWS credentials accidentally, the attackers:
- will not be able to run anything in the IAM account, as the permissions essentially only allow to assume-role and manage your own user.
- won’t have access to your MFA device, locking them out from assuming role into any of your other accounts.
This is what the trust relationship policy should look like,
1234567890 being your IAM account:
Locking down STS
One extra thing I like to do is limit STS endpoints as I don’t want resources generating temporary credentials in other regions, all I need is us-east-1 and eu-west-1.