Companies are complicated, and it requires significantly more setup to manage the AWS accounts of hundreds of people. In this article, we discuss the best practices for managing secure access to your organization’s resources without hindering your developers with bureaucracy.
Use IAM Users for Employee Accounts
If you’ve used AWS before, you’re probably familiar with IAM users. They’re essentially service accounts used to authenticate things running on remote servers and to allow them to access the AWS resources they need (putting things in an S3 bucket, running lambda functions, etc.) without giving full access to your main account. This way, if your servers are compromised (by a hacker or rogue employee), the intruder only has access to the permissions you gave.
IAM users are great, and are also useful for giving out employee access to services they need. When you create an IAM user, you have the option to enable management console access (as opposed to CLI/API access), which enables you to give the account to an employee and have them access the the management console with restricted permissions. You can even enable Multi-Factor Authentication (MFA) for IAM users with console access, making them very secure.
The main issue, though, is that employees using IAM accounts won’t be able to create their own IAM users without help from the root account. If you have a project manager who needs to give secure S3 PUT access to an application, they have to ask the root account holder to create a whole new IAM user specifically for that permission. Considering that the root account holder usually is the owner, CTO, or someone high up, it’s a massive waste of time, especially if you’re not even touching production.
Otherwise, IAM Users are the way to go for giving out managed access to certain services. You can create IAM groups, which are useful for laying out the permissions each role in your organization has. Whatever you do, just remember the principle of “Least Permissions”—each account should have only the permissions it needs to do its job effectively, nothing more. Also, make sure not to give IAM access to IAM users, or they can escalate privileges.
Separating Development and Production Environments
The solution to the problem of varying security is AWS Organizations. This service enables you to administrate multiple different accounts under one root account, complete with consolidated billing (root user pays for each child account).
The default limit is four accounts, which makes Organizations infeasible for use as individual employee accounts. It wouldn’t make much sense to do this anyway, as each account is seperate from the others, and won’t be able to see services or servers launched in other accounts. You can request a limit increase if you need more environments, but AWS wants you to use IAM users for employees.
What AWS Organizations is intended for is separating development and production environments. Different rules apply to each environment; for example, you may want to restrict employees from creating new IAM users without going through all the proper channels and consulting the higher-ups, but in development having to go through all these checks would just slow developers down. You may choose to give your project managers access to the development account to enable quicker testing.
As far as the hierarchy is concerned, the master account acts as the root of the tree, and handles the creation of new accounts. Accounts can be sorted into Organization Units, which act as groups and apply permissions to each account under it. These can be nested as you see fit (if you even have enough accounts to do so).
AWS’s recommendation here is probably how your organization should look. You have the main production account, which is highly secure and only really fully accessible by upper management. The “Test” or “Staging” environment functions as a mirror of production, and is accessible by your quality engineers and anyone else who is doing testing before pushing changes to production. You may choose to split these into two separate environments: test is for automated testing with dummy data (functionally an extension of development, but cleaner), and staging is a complete mirror of production including customer data and access to real public APIs.
Then you have development, which is accessible by your project managers and the developers under them. This environment has much more lax permissions, as the overall security of it doesn’t matter as much as production. Any databases created in development (or testing, for that matter) shouldn’t include customer data.
Most of your developers probably operate from personal IAM accounts in the development environment, giving them much fuller access than they would otherwise get in production. You probably want to give your developers permissions to use most of the services that you use in production (just keep an eye on things to ensure usage is under control).
Organization Units (OUs) also enable you to restrict the permissions of each account, using Service Control Policies (SCP). SCPs are a lot like IAM policies, but a level higher—they apply to the whole account under them. If the development account created an IAM user that had access to S3, but S3 wasn’t enabled in the SCP, that IAM user wouldn’t be able to use S3 on that account. Services are denied by default, so you have to manually whitelist them to be able to use them.
One AWS account per OU should be fine for most applications, but you do have the option of creating more. If you wanted to have a separate development environment for different teams, you could create two or more development accounts under one OU. Even with only one account, you can still manage permissions with SCP rules.
Regularly Review the Security of Your Organization
If you’re setting up an organization in AWS, you are quickly going to run into the issue of needing to run regular security checks to make sure everything is secure. AWS provides a security checklist that you should read through and ensure you’re compliant with everything. Even something as simple as checking each user is in the right place is good practice.
If someone leaves the company, you need make sure any associated IAM accounts are deactivated or transfered. If someone changes roles, you also need make sure that their account’s policies reflect that role, and that they don’t have leftover permissions from old jobs.
You also need make sure that SCP permissions are set correctly for each OU, and don’t change much over time. You don’t want the development environment to be able to rent 20 c5d.24xlarge instances and drive your bill through the roof.
