Now that we’ve covered the basics, I want to talk about AWS account structure and how to utilise it to improve security posture. By default, everyone signs up and runs everything from their first account. When people hit the limits (of the account, or of their understanding of AWS), that’s when they’ll investigate how to do something more with their account structure.
Instead of that, I want to encourage people to set up their environment to be more secure, simply by taking advantage of thing such as consolidated billing. If you read all the AWS material on consolidated billing, they’ll tell you:
Consolidated Billing is strictly an accounting and billing feature. It is not a method for controlling accounts, or provisioning resources for accounts. It doesn’t change how the accounts function or how they are accessed. Consolidated Billing, therefore, cannot be used for sharing computing resources between accounts.
This isn’t strictly true. You can use Consolidated Billing to control accounts, but you’re doing it at a much higher level than IAM. Instead of working inside the account, you’re going to sign up to several AWS accounts, link them for consolidated billing and utilise this account structure for security.
Its actually pretty simple. We’re using a feature that was designed to simplify billing in order to create an account structure to separate out services. Leveraging this also creates the ability to granularly purchase AWS support to the elements of the environment that need it.
In this series of articles, the topics being covered are:
- Root Account Management
- IAM Policies and Users
- Establishing an account hierarchy (this page)
- Setting up CloudTrail and Billing Alerts
- SumoLogic (optional)
Establishing an account hierarchy
The goal here is to use the concepts around consolidated billing to create an account structure that provides more security than a single account. Rather than typing out what I mean, the following diagram should illustrate exactly what I’m talking about:
In the diagram, each rectangle represents an AWS account. Each line represents the interactions between accounts.
After several discussions with AWS Solutions Architects and other AWS experts, the overall consensus is to use an AWS account as a physical boundary to secure groups of systems and services. In a traditional infrastructure deployment, you’d segregate away your production load from your development load because you don’t want the latter impacting the former. In this account structure, you’re achieving much the same thing.
Firstly, let’s go over the accounts in this environment:
- Master – This is your master account, all accounts tie into this via Consolidated Billing. The sole purpose of this account is to manage the billing for all of your AWS resources
- Backups – Your backup account is purely to house all your backups. If you store all your data backups in another account with entirely different security permissions, it becomes more complex for a malicious attacker to gain access and irrevocably harm your business or data.
- Logging – Similarly, you need to store all your logging data (be it for the AWS account, or for your application) in another account. In doing so, you improve protection of that data. With security and application log data, you can build a picture of what is happening within your environment
- Production – This is where your production workload and services will operate from
- Development – You develop in an entirely different account. For some organisations, they run development and testing within the same space. I don’t agree with this, but that’s another topic for another time
- Testing – In the diagram, this is represented with broken lines, this is because it may be optional for some. Its purpose is to house the resources used for testing and nothing else
- Staging – Like testing, this account is optional. Not all organisations have a deployment process that has multiple phases. For some, development functions as both testing and staging. Others have testing that functions as both testing and staging. The point of the testing and staging accounts is to show that you can scale out your accounts to meet your requirements
The key interactions with the Logging and Backup accounts are:
- Store any and all log data (AWS account based data like CloudTrail, IIS/Apache logs etc.) in your Logging account
- Store any and all backup data (Active Directory System State information, MySQL data backups etc.) in your Backup account
With this account structure, you can then grant access to the relevant people to have access to the relevant data sets. These accounts become your “Services” accounts, solely there to safeguard one specific aspect of your environment.
In saying that, there are a few thoughts around these “Services” type accounts:
- By default, no one should ever be granted Delete access to anything. I’d almost go so far as to say that you should consider a Deny policy on any deletion by anyone
- There’s a threat in the form of Denial of Service type attacks – specifically, a DoS intended to make the cost of operating untenable. As with everything, ensure you place billing alerts on your accounts so you can track your progress
- Don’t feel restricted to just these accounts. If you use AWS’s Code Commit, there’s scope for you to create an account for your code repository
- For accounts that do store data, ensure you’re writing to S3 and using policies to archive to Glacier
- Ensure that any data you write is encrypted – not using the AWS encryption tools, but other systems that you’ve got direct control over
One of the other benefits of this account structure, is that you can now buy the support you need for the type of account. One problem with running all your services out of a single account, is that if you buy the Business support it applies to everything. Doesn’t matter if development needs Business support or not, they’re getting it. This account structure means that each account can be provided the support it needs. Production can get Business (or Enterprise) support, development can get Development support and similar. The master account can be setup with no support, since you really shouldn’t need it. In doing this, you can reduce your support costs to AWS, since the resources that need it are the ones that get it.
One caveat does exist. If you qualify for AWS Activate, you might find that when you apply your credits to your master account it also means your master account is the one that gets Business support. There is no formally recognised fix for this, however I have been told that if you can demonstrate administrative access into the relevant accounts you can get support for them. This is where you might consider AWS Account Delegation so that you can demonstrate that access. If this is the path you take, ensure that you explicitly deny delete access for this IAM account to any and all services. This account should only be there to demonstrate administrative access, it is not intended for anything else
By splitting up what account does what, you can now control your environment with granularity. As a side bonus, you can now also assign costs to those aspects of your environment that you may not have readily been able to do so in the past. If you institute the 3 concepts of the articles I’ve written, you should be able to create the foundation for a resilient AWS based environment. The combination of multiple accounts with IAM policies and users in each account should mean that your foray into AWS should be inherently more secure than that of a single account running everything.
My aim in the next two articles are to elaborate more on logging data and how you can monitor your accounts more effectively for suspicious activity. This would leverage functionality like CloudTrail, AWS Billing Alerts and advanced log analysis technologies like SumoLogic. In saying that, I do want to remind you that security is a constantly evolving thing. You will always need to keep watching and reviewing, innovating in how you operate.