We’ve talked about AWS security before – what tools AWS has created for us and some common mistakes people make – but you never can really cover the whole thing. So I’ve put together a checklist of some key best practices that’s guaranteed to mess with your next night’s sleep.
Thinking of launching an EC2 instance as a testbed? Not sure whether it’ll still be up a month from now? Don’t stop reading…now’s the time to think about AWS security!
Avoid using the default AWS security group
Everyone loves a default setting because it can help you avoid thinking for yourself…and who has time for that? Sure, you can always keep adding new policies to a single AWS security group so it will work with all your nodes, but try not to.
Instead, create separate security groups for each network traffic profile you plan to use and use them only when the fit is perfect. Besides the risk of introducing vulnerabilities, overusing default configurations can lead to bad architecture design and practices. Also, if you force yourself to create new security groups for each project, you’ll actually end up thinking a whole lot more about your larger design, which will probably improve it.
Open only those ports that are absolutely necessary
If the only access you will need is SSH, then make sure that’s all you leave open. Afraid you may need POP3 or MySQL access some time over the next six months? Wait until you actually need it.
Restrict access to sessions originating on your IP
When you set up a security group in AWS and open a certain port, you can also choose the Source. This controls which traffic will be allowed to reach your instance. Rather than leaving it wide open (0.0.0.0/0), specify a single IP address or an IP address range in CIDR notation (for example, 203.0.113.0/24).
Even better: if you select “My IP” for “source”, AWS should automatically populate your public IP.
Use meaningful names
You may not think it is possible, but twelve months from now, you may be looking after a huge AWS infrastructure with 50 or more security groups. Which of these AWS security group names do you think would work best?
- security_group1
- my-sg
- ssh_access_port22_only_WordPress_server
- jimmies_best_security_group_ever
Hopefully, you guessed (2) ssh_access_port22_only because it tells us exactly what it does and what it’s meant for. You get the idea.
If you look at the screenshot below, I’m in the middle of configuring the launch of an EC2 instance. In Step 6: Configure Security Group, I chose:
- A meaningful security group name.
- A description that explains it even better.
- SSH access only
- Only my IP
Remove (or don’t even generate) a Root Account Access Key
One of the best ways to protect your account is to not have an access key for your root account. Unless there’s some reason that you absolutely must have a root access key (which is very rare), it is best not to generate one. Instead, the recommended best practice is to create one or more AWS Identity and Access Management (IAM) users, give them the necessary permissions, and use IAM users for everyday interaction with AWS.
If you already have an access key for your account, AWS recommends that you find all the applications currently relying on it key, replace the root access key with an IAM user access key, and then disable and remove the root access key.
AWS security: summary
Security is important – and nowhere more so than in the cloud. From my experience, you need to get the basics in place first and the rest of your security should build out naturally. So, to review, I would suggest focusing on these points for your AWS security plan:
- Avoid using the default security group.
- Only open ports that need to be open.
- Use names that are meaningful for your Security Group
- Choose to access from your IP only unless wider access is needed (eg:HTTP)
- Remove (or don’t generate) a Root Account Access Key
If you want to get a jump start on cloud security, check out Cloud Academy’s Security training library.
