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!
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.
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.
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.
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?
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:
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.
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:
If you want to get a jump start on cloud security, check out Cloud Academy’s Security training library.
It's Flash Sale time! Get 50% off your first year with Cloud Academy: all access to AWS, Azure, and Cloud…
In this blog post, we're going to answer some questions you might have about the new AWS Certified Data Engineer…
This is my 3rd and final post of this series ‘Navigating the Vocabulary of Gen AI’. If you would like…