AWS Account Security 101

As a VMware & AWS geek, I was excited to learn that both companies have collaborated to give some very exciting news that soon we’ll be able to run our VMware workloads in AWS data centres and get direct access to the AWS VPC and as such all the AWS portfolio! This is super exciting, put aside all my worries and concerns (and there’s a few) and this does open up a lot of exciting potential to merge these 2 worlds. With all this excitement I’m fairly certain lots of people that haven’t already done so will be sticking their personal credit cards into the AWS console and spinning up t2.micro’s and lambda functions and SQS queues to see what this is all about. So for all you VMware people out there that haven’t used AWS before (and maybe a refresher for those that have), here’s a few top tips beforeyou start getting familiar with AWS and tinkering.

My bill is $$$$’s, what happened?!?

Everyone has a story of a friend, or a friend-of-a-friend, or read an internet blog about someone that had their AWS account hacked, or they accidentally left instances running when they could have sworn they shut them down! Firstly, AWS support are a very friendly bunch, they understand that mistakes happen and they can see usage metrics and help identify when an account was hacked (take note, they won’t do this proactively for you!). If you suddenly rack up a massive bill or get hacked, give AWS a ring immediately, they are a great bunch and will do their best to help you out. But let’s try help prevent that!

Root account

When you first sign up for AWS you create a root account. First and foremost DO NOT USE YOUR AMAZON.COM (or regional alternative) SHOPPING ACCOUNT! This is bad practice, and if someone gets your Amazon shopping account there’s other security in place to prevent them racking up a massive bill. If someone gets your Amazon shopping account you don’t want them racking up $$$$’s in AWS bills do you? I made this mistake, and I desperately need to move my AWS workloads across, but time makes fools of us all.

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials

MFA (Multi-Factor Authentication)

It’s not good practice to use your root account for day-to-day operations, same as it isn’t with Linux. Best practice is to give it a ridiculously complex password and vault it. You could also put MFA on this as well, but keep in mind that if you don’t regularly authenticate then the MFA keys can get out of sync (mine seems to go out if I don’t use it for around 3-4 weeks). Take your preference of Google Authenticator, a Gemalto hardware key, or my personal favourite a Yubico USB key (or a suitable alternative, there’s all sorts). They all do much the same, and if you aren’t using 2FA with other accounts then it’s a good thing to have and start using!

https://www.yubico.com/

IAM (Idenitity & Access Management)

This is great for large enterprises as you hand out specific privileges to people in your organisation and people can only do exactly what you say they should be able to do. This is also really useful if you lock down your root account and don’t use it all the time. Create a general purpose account with the access to the resources you want (or all the resources if you like) but don’t give it access to IAM, billing and things like that. Then you can use this IAM account to your hearts content. Make sure you enable MFA on this IAM account also! This will greatly reduce your exposure.

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users

Roles

Learn what roles are within AWS and use them. You should not need to bake in credentials or access keys within your code or application! Build your EC2 instance with this pre-baked roles and access. If you don't know what roles are or don't know how to use them, create a role with no access and associate it to you EC2 instances anyway. You can't add a role to an existing EC2 instance, so rather have it and never use it, than not have it and be stuck.

Access Keys

Don't enable access keys under your root or IAM user account. These are keys used for API calls and other automation functions. Create a specific account to do this and don't give that account a password, and then limit (greatly) what this account can do under the IAM controls. If your access keys get hijacked the impact potential is minimal.

CloudWatch Alarms

Go into CloudWatch and setup usage limits. This is a great practice if you’re an individual or a large multi-national. Set an alarm to what you want to spend, then set another 10% below this and another 10% above this, then another 100% above this. If you don’t know what you want to spend then guess for the first month, and then set a threshold for the amount you spent last month. For large multi-nationals, set an alert to the level that you normally spend. This means that any abnormal usage will get alerted on almost immediately when it happens. I get a warning when I hit $50, $75 and $100 as I only run a few services all the time. If I get an alert on the first week of the month I know somethings gone wrong or I’ve left something switched on that I shouldn’t have (that’s happened!).

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

Pre-Paid Credit Cards

This is probably frowned upon by AWS, but I think it’s a great idea for personal users. Get yourself a pre-paid credit card and top it up each month when you need to (even setup a scheduled payment which is your Usage Limit alarm level and forget about it). Some of the pre-paid credit cards even give you some perks, but shop around as you might be able to get one that’s totally free (I use Pockit). Again this can be good practice for online stuff anyway, I also use this same card for things like the London Underground as I’m paranoid getting bumped by someone with a card cloner.

Usage Limits

When I hear stories about people waking up to bills of $10k’s overnight, I’m automatically sceptical, the full story isn’t there. By default AWS will restrict your account to only 20 instances, so even if you spin up the heaviest of GPU instances (which hackers traditionally do for Bitcoin / crypto-coin mining) then this overnight bill seems extreme! If you’re a home tester, stick within the instance limitations. You can even talk to AWS and ask them to lower this, but if you really need more then of course you can also ask them to raise it. Regardless of your sizing (personal or multi-national) I’d highly recommend always having a sensible limit. Worst case you need to log a support call in order to spin up a few extra, but there’s a trail to this and it gives you protection!

https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html

Github / Bitbucket with caution

Love these tools, but make sure any access keys you have aren't baked into your code that gets synced to a public repo! You'd be surprised! There are web crawlers always looking for keys, anecdotally it can take as little as 5 minutes for your keys to be grabbed, so be careful what you sync!

AWS Masterclasses

Finally, totally unrelated to account security, go check out the AWS Masterclass videos. Ian Massingham and the Evangelists / Architects have done an awesome job in going deep into AWS technology. I had these on in my car (audio only) and watched everything I could prior to doing my exams, and I would suggest this got me 70-80% of the knowledge I needed to pass both the Solutions Architect exams (the Professional level is a tough one!). Go watch these videos, they’re awesome and I’m confident you’ll learn something you didn’t know, either about the AWS portfolio or a neat trick on how to use things in the AWS portfolio.

https://aws.amazon.com/webinars/emea-masterclass/

AWS User Groups

A little self serving, but I do think the AWS User Group community is great. I run one in the West Midlands in the UK and the feedback I get is that the discussions in the group are great. Speaking with the other group leaders across Europe and the feedback is similar. Great community where everyone is keen to help and share knowledge and war stories.

https://aws.amazon.com/usergroups/

Have fun!

AWS is awsome (Dad pun intended), the potential is bigger than I'll ever get my head around and it'll up your entire game. Even if you end up using Google, Azure, Soft Layer or something else, learning AWS gives you a good understanding of what can be done. Have fun playing!