Based on the last two posts, you have disabled your AWS root user; removed any root keys, assigned an MFA to that user, and then either destroyed or intentionally lost them. Root has no access to your AWS environment, only IAM users, you have created. Correct?
In a nutshell, that’s the first two blog posts in this series of top ten security best practices. So, in this week’s release, we simply have one question. When you leave your home for vacation and lock the door on the way out. How many people have access while you’re out on vacation? Who has a key to your house?
Really, how many people have access while you’re out on vacation? This is the same question that drives the subject here, and thus this should be a very short post.
When you leave your home, you more than likely have a very good idea of how many keys there are to get back into the house AND who has them, right? Those keys were handed out with a lot of consideration.
For example, your housekeeper may have full access, but you ran an extensive background check and even they do not have access to the safe hidden in your closet.
Then there is close family or friends; you may have given a spare key, just in case you lock yourself out, or to feed the fish. But in reality, the number of keys is strictly controlled, and for specific reasons. The same logic should be applied when considering whom or what should have Admin privileges to your investment in AWS Infrastructure.
Lets consider the federal postal service in the US. They want to deliver your mail while you’re away. Do they have a key to your home? Odds are that they have access to your post office box, but only your post office box.
You have not trusted your local carrier to put the mail on your kitchen counter, but rather have given them access to a very specific place. If your mailbox keys are compromised while you’re enjoying time away, you have a good understanding of the risk. However, if they had the keys to your home, and they were lost or compromised, your vacation might be cut short.
This same methodology should be used when giving out access on AWS. Each key you give out should be reviewed from the perspective of least privilege:
- How much access does this user or application need in order to perform the task? What is the risk if the key is lost or compromised?
- Is there intellectual property or financial data somewhere in that equation?
- Could the result impact my revenue or reputation?
The more granular you are with access, the more you help protect your business if and when something is compromised. Here are some examples:
If your EC2 application needs to post data to S3, should that same application have the ability to launch more EC2 instances like itself?
No, and AWS IAM has provided you the ability to assign a “Role” to your EC2 instance that will grant that access, but only that access, while removing the ability of any application on that instance the ability to do things you have not specifically authorized.
There is more detail about setting that up here, “Using EC2 Instance Roles.” The nice thing is, you no longer have to integrate keys into your instances or application; you can simply put your instance in a group that has the permissions it needs. More will be covered specific to this in an upcoming post titled, “Use Roles for EC2.”
In the same type situation, do you want every IAM user to be able to delete data in your S3 buckets?
While the most common response in no, in many cases, IAM users are given full access to your AWS environment which includes both creating and deleting resources in all of the services. With the low cost of storage in the cloud, it is a recommended best practice to limit those users and applications that can permanently delete information.
In this case, you can assign a policy to all of your IAM users very easily limiting their ability to remove information. Again, here AWS has provided a good walk-though on setting this up, “Using IAM Policies to Control Bucket Access.” We will also dive deeper into this with the upcoming post, “Watch world-readable/listable S3 bucket policies.”
AWS has provided you the ability in many situations to implement the least privilege methodology in many ways that may not be possible, or challenging to implement, in a traditional on-premise infrastructure.
While limiting access is a good best practice, there is always the need to do things that require increased privileges. You may want to allow a user to delete S3 objects, or you may want to give someone Admin privileges while you are away.
In the vacation scenario, you may want to give someone access to your home while you are gone, but then revoke that access once you are back. This is a temporary key, and AWS provides you the ability to grant a temporary key to your users and or applications so they can do what they need to, and then destroy that key so it can no longer be used.
The Evident.io Security Platform (ESP) actually leverages this via the Security Token Service to make read only API calls on your behalf. The credentials expire and are all controlled via AWS, so you do not need to give out static keys. More examples of this service in action can be found in the AWS documentation on “Granting Temporary Access.”
So, limiting access has sparked your interest and would like some help to see where your environment might be at risk? All of the most common scenarios discussed here and in AWS Security Best Practices are checked via the Evident.io Security Platform.
The nice thing is that we offer a free 14-day trial, so you can evaluate your security risks, like too many IAM Admin users, but also over 130 other checks.
You are also welcome and encouraged to come chat with us tonight, February 26th, at the AWS Pop-Up Loft in San Francisco and again March 10 to dive deeper into the series of security presentations and workshops!
A quick recap of our past AWS Best Practice posts:
- Disable Root API Access Key and Secret Key
- Enable MFA Tokens Everywhere
- Reduce Number of IAM Users with Admin Rights
- Use Roles for EC2
- Least Privilege: Limit what IAM Entities Can Do with Strong Policies
- Rotate all the Keys Regularly
- Use IAM Roles with STS AssumeRole Where Possible
- Use AutoScaling to Dampen DDoS Effects
- Do Not Allow 0.0.0.0/0 Unless You Mean It
- Watch World-Readable and Listable S3 Bucket Policies