You use AWS. It’s secure out of the box, but introducing security issues through misconfiguration is easy…
I found a checklist and I also added the best practices from AWS, this helps me in my daily work to guide me through potential security issues. This can and will help you to tighten up the security of your AWS infrastructure.
The purpose of this article is to remind you of the most urgent security measures that should be taken on your AWS infrastructure. It is by no means exhaustive, and it should be adapted to your specific business use cases.
Here are some guidelines and takeaways…
Enforce security settings for Identity and Access Management (IAM) accounts
The AWS IAM accounts are the most important part of your AWS setup, as they are where configuring the whole platform starts. Take these steps to secure them:
- Use multi-factor authentication to protect your users against password theft.
- Enable a strong password policy for good sources of information
Rotate your AWS keys
In a typical production environment, AWS keys get spread across various services, which have various privilege needs. Many employees will have access to multiple keys, DevOps will have access to most keys, DBAs will have access to the database keys, backend team to the log keys…
It is often necessary to renew these keys (e.g. when someone leaves a team). This procedure should be straightforward and risk-free, so that you can do it frequently, and more importantly, in urgent situations.
Do not commit AWS access keys or credentials
AWS access keys are meant to be used by your infrastructure and/or your code. Do not commit them into your source code. It would else make them available to a lot of 3rd parties, such as contractors or continuous integration tools. It will also make them very difficult to change. A good way to approach this is to use environment variables. It would also allow you to easily run your code in a non-production environment. These ideas are described in The Twelve-actor App.
Keep your security groups minimal
By default, any AWS element has an empty security policy, meaning that nothing is allowed to access it. You should only give access to the IPs and ports that are really needed for the service, and block all the rest.
Use a private VPC
AWS makes it very easy to configure the networks. To make the most of it, your VPC should be private, and all the instances in your VPC should have an internal IP address.
It means your machines will have private IP addresses, preventing by default connections to the internet and from being accessible from the Internet.
If external internet access is required on your machines, they should use an AWS NAT gateway as their only way to access the Internet.
If you need to grant public access to these machines from the outside, use an Elastic Load Balancer, or an Application Load Balancer. They are the AWS dedicated elements that allow you to easily operate and scale public accesses.
For internal access (e.g. a microservice), it is better to create an internal Load
Balancer (that will be restricted to your VPC) in order to decouple the network configuration of this specific machine from the configuration of its clients.
Use Trusted advisor
AWS Trusted Advisor is a great way to retrieve many details about the security of your AWS setup. It also allows you to monitor billing or performance.
The free version of Trusted advisor will only tell you about the Security Groups with unrestricted ports, though the paying version has much more information available. The paid version will tell you about logging, your SSL certificates, exposed IAM keys and key rotation. The price is high, up to 10% of your infrastructure price. Only 4 checks are available by default, then you need to purchase Business support (100$ / month) to access all of them.
AWS CloudTrail is a logger that will record all the calls performed to AWS APIs with credentials that you own. All this information can be stored to S3 for further analysis (allowing low-cost retention). It is not a prevention against security incidents, though it is a way to be able to analyze what happened on your infrastructure in case of an incident, and examine which services were accessed.
Update your Amazon Machine Images (AMI)
Just like any other piece of software, the OS needs to be upgraded to prevent security issues. Some of them should be corrected as soon as possible — even though some previous steps, such as reducing network exposure, can mitigate some of the issues created by an out-ofdate OS. In AWS, the OS is managed with the AMIs. You should ensure your AMIs are kept up to date. When an AMI starts, it will by default download and apply the latest security patches. AWS keeps a very up to date list of the security issues corrected in the AWS instances. AMIs can be displayed in the AWS Web console Pay attention when choosing the region were your EC2 instances are placed.
Choose your rights carefully
Just like your network, the other AWS services start with a zero-rights policy (nothing is allowed by default). So allowing certain entities to use this service is part of the service configuration. This configuration need to be tight, and must not contain any unnecessary privileges. Some tools that are part of AWS IAM can help perform simulations of the rights you are building. The “Access Advisor” in IAM will help you fine tune the rights associated to the roles you create.
Billing is not directly security related, though it can be an excellent indicator that something went wrong, or that your credentials have been used by a third party. It is not rare to see companies with dozens of new machines started to relay traffic or even mine cryptocurrencies (such as Bitcoin). Billing information can be accessed from the AWS dashboard. Billing alarms can also be created in order to monitor this.
These AWS-authored articles will help you review what you have done in your organization and how you should improve your infrastructure:
Don’t forget, your infrastructure is only one piece of your company’s security!
Also check out Sqreen a security platform to learn more about to protect and monitor your apps deployed on AWS.
Pingback: AWS Security Checklist & Best Practices | Cloud Astronaut – Cloud & Virtualization Complete Guide
Pingback: AWS Security Checklist & Best Practices – Learning mind