When you think about user account security, there are likely several thoughts that come to mind. Password complexity, password age, password history are all standard procedures. One of my favorite movies, Hackers, pointed out how dangerous simple passwords could be when it came to network security.
The reality is that in the public cloud, things like security could often times be overlooked. Using Administrator with the same password on every machine in my lab or even my datacenter isn’t that big of a deal when it is behind my firewall. Using that same password in the public cloud and more importantly in all of my servers will just cause me to eventually have a very bad day. Honestly, who wants to have to live in fear of $6,000 AWS bills over night.
One of the first things that I do when I setup a new AWS account is to create an Identity and Access Management (IAM) user. Think of these as role based sub-users of my account. If there will be multiple users to the account, then each of those will receive their own IAM user. Each of the users can have individual permission policies or controlled as a group based on membership. Feels just like my local domain right?
I have always been very impressed at the shear granularity of an IAM user policy. Honestly, the first time that I looked at the custom policies my mind melted a little. There are just so many possible scenarios. In fact, I created a custom policy for our lab users. The policy that I suggest that they use grants our system the ability to create the infrastructure but denies access to any deletion API calls. This is to protect our users and to protect us. There is no possibility of accidental deletion because the account doesn’t have the right.
Passwords aren’t the only entry point into your account. AWS has the concept of Access and Secret keys. These are used to authenticate users via API calls. We use these in our lab to remotely connect to the end-user’s account. The important part is that these keys can be expired without affecting the IAM user’s password. The keys still must adhere to the same User Policy assigned to the user account.
Here is my checklist:
Over the time that I have been working on Amazon, I occasionally hear stories about compromised accounts. Each article that I have read seem to always come back to the same point about user accounts. Rarely, is the issue due to some multi-national elite hacker group brute-forcing their way through the gates. Instead, it is a simple mistake where Access Keys end up posted to Github or passwords become compromised by former employees. In my next post in this series, we will talk about a completely different way to secure your environment. We will investigate how to get away from storing Access Keys on a server by using EC2 Instance Roles.
Other articles in this series