It might be unrealistic to expect your AWS security to be bullet-proof, but there is still a great deal you can do to make things a whole lot better.

AWS Security and more AWS security. We all know it’s important, but if you’re like me, there always seems to be a nagging doubt in the back of your mind that somewhere, there’s a nasty hole in your infrastructure, and that some hacker is prodding and probing away trying to find it. It sometimes seems that keeping everything 100% secure is a losing battle.

However, I do believe there are a few things that can be easily plugged that can make a big difference.

1. AWS security: delete Root Account Keys

This is something about which AWS is constantly trying to remind us – even I’ve written about it before. It’s probably the easiest and most important security move you can make.

1a) What you need to check

Login to your AWS console root account and click on Identity and Access Management. If you see the a nice green tick next to the “Delete your root access keys” box…

AWS Security - IAM

…Then everything is OK and you don’t need to do anything.

However, if you see this:
AWS Security IAM

Do the following:

1b) What you need to do

  1. Click on ‘Manage Security Credentials’.
  2. Click on ‘Access Keys (Access Key ID and Secret Access Key)’.
  3. Delete any Access keys that are still Active like the one below.

AWS Security - credentials

AWS Security - credentials

2. Name everything

I originally left this until the end of the article. However I realised that it makes a lot more sense having it right here, before we remove our unused Security Groups in the next step. This is because having everything correctly named will be easier to actually see which Security Groups should, in fact, be removed.

2a) What you need to check

Go through all your resources and check to see that everything – EC2 Instances, Security Groups, Network Interfaces, Volumes, Snapshots – has a name. Why? Because it will make keeping track of your resources so much easier and make it more likely that you will quickly spot anything being misused.

2b) What you need to do

Give everything a name. More importantly the name should be related to what the resource’s specific function is. Make sure you do this for all your resources in all regions.

Note: If you want to be even more thorough, then TAG everything. So instead of being restricted to just a name, you can add your own key-value pairs.  

3. Remove unused Security Groups

Now, with everything nicely named or tagged, it’s time to get rid of any unused security groups. Cleaning out your security groups eliminates the risk that a forgotten security group policy will be used to accidentally open an attack surface.

3a) What you need to check

Open your EC2 Console and click on ‘Security Groups.’ You should see a list of all your Security Groups

3b) What you need to do

Go through them carefully and delete any that you are certain aren’t being used or don’t belong to a default security group. If you try to delete a group that is being used, you should see a warning pop-up telling you. In any case, review the policies of all groups to make sure there are no unnecessary holes.

4. Restrict SSH access to your IP only

If you are the only one who connects to your instances via SSH, you should restrict access to sessions originating from your IP only.

4a) What you need to check

  1. Open your EC2 Console and click on ‘Security Groups.’
  2. Click on a Security Group and then select ‘Inbound’ in the bottom window.
  3. If you see any SSH connections with a source of 0.0.0.0/0 like this:

AWS Security - Policy

…Do the following:

4b) What you need to do

Click on ‘edit’ and then select the Source for SSH as MY IP, then save it as follows:

AWS Security - policy SSH

Repeat for all Security Groups in all regions.

5.  Create individual IAM users (especially for yourself)

Avoid using your AWS root account credentials (ie: your original AWS login) to access AWS.

5a) What you need to check

  1. Open the Identity and Access Management console.
  2. Click on Users.
  3. If you have a user for yourself with administrative privileges, then use that to login to AWS from now on (unless you have a really, really good reason not to).
  4. If you don’t have a user for yourself with administrative privileges, then follow these steps:

5b) What you need to do

  1. Create an IAM user for yourself with administrative privileges, and use that IAM user for all your work.
  2. Follow this guide: Create individual IAM users.

Conclusion

AWS Security can be a little overwhelming at times, but if you make sure you get the easy stuff right from the beginning, then you should find yourself ahead of the game.