Over the next several weeks, we will be discussing best practices for securing your Amazon Web Services (AWS) environment. Before we dive into securing your instances, applications and data, we have to start from the top.
As part of the AWS shared responsibility security model, consumers of AWS play a significant role in securing their use of the service. Back in November 2012 at the AWS re:invent conference, Max Ramsay mapped AWS to the CSIS 20 Critical Security Controls as a framework for further understanding this responsibility shared between AWS and the client (you). Critical Control #12 is the controlled use of administrative privileges and the responsibility for protection is squarely on you as the user of AWS. Over the next weeks, we’ll be focusing in on the critical controls that are your responsibility.
Prior to virtualization or cloud the administrative privileges were typically your accounts to the operating system. However, now you have a much more powerful set of credentials to manage — the access to the AWS console and APIs.
Put Away Your AWS “root” Account and Use Identity and Access Management (IAM) to Enable Access
When you signed up for AWS you were given a username and password. This account has full access to all of your AWS resources and billing information. Donāt share this with anyone! A certain manager I know shared the account with his team and they quickly discovered they could order from Amazon.com on the managerās credit card!
Keep that account safe and head over to the IAM tab on the console to start defining Groups and Users.
Generally you will need two types of users:
- People with a username and password to access the AWS console
- Programs using an Access Key Id and Secret Access Key to access the APIs
In both cases you want to assign the minimal privileges required for users via a Group. AWS helps by providing a number of policy templates. For instance you may want to give operations people “Power User Access” while giving development people “EC2 Full Access”.
For the users you create, you will be given a special URL called the IAM user sign-in link. Provide this URL to the users you create along with their username and password.Ā They wonāt be able to use the main sign-in link.
The principle of least privilege is also important for users you create to grant programs access to the AWS APIs. If you are developing an application that ships data from your datacenter to S3 you may want to only enable S3 āPutā operations in a custom policy using the policy generator tool. That way if that key is compromised your damage is very limited.
Creating specific users will help you control permissions for the people and programs accessing AWS, and allow you to individually revoke access when needed. For example if you give an access key to the 3rd party program or service, it is much easier to revoke it when it is a properly named user account.
For more on using IAM, see AWS IAM Best Practices.
Proper control of access to AWS is the first step. Later we will discuss other aspects of controlled use of administrative privileges including adding Multi-Factor authentication, AWS Roles, and controlling administrative access to the Operating System.
Any tips for managing access in AWS ā share them in the comments! And if you’re interested in securing your EC2 or VPC instances check out our new Deep Security as a Service for cloud servers, currently in free Beta.
