In the past few years, the number of enterprises relying on cloud solutions, especially Amazon Web Services has risen and the trend continues. With this, AWS security threats are getting more advanced and complex day by day. It is more essential than ever to have control and recognize accurately what is going on in your AWS cloud environment and ensure that you follow AWS security best practices.
It is high time to make your AWS environment protected, compliant and competent. This is needed in today’s quickly varying threat landscape. For this, you need to ensure that your business doesn’t find itself trapped in the next wave of cloud security breaches.
As you may know AWS and you share responsibility for security of your cloud infrastructure. While AWS takes responsibility of the facilities, physical security of hardware and virtualization infrastructure, you are responsible for anything provisioned and run on top of that.
Now, assuming that you know what your responsibilities are and that AWS would take care of the parts of the infrastructure it has promised, let’s discuss what are the different threat landscapes you need to take care about. You get to define the controls within your AWS infrastructure. AWS provides tools and enables you to strengthen your infrastructure security.
In this AWS security best practices series, we will talk about the four major AWS security threat landscapes:
You can define who has how much access to which of your cloud infrastructure resources.
Rules of computer networks in traditional data centers apply to cloud as well. You need to define how computers (or instances in AWS lingo) are connected and talk to each other over networks.
With many of the AWS services you must define rules and ways to secure your data in transit as well as at rest.
You must be aware of what exactly is going on in your cloud environment. In order to have a proper AWS audit trail, you must enable various monitoring and logging tools provided by AWS.
As part 1 of this AWS security series, we will discuss how access to your cloud resources is controlled in AWS, the security threats around it and the all important lists of do’s and don’ts for each of the modes of AWS access control.
Access to your AWS infrastructure resources needs to be restricted and supervised. This ensures reliability of user authentication. In AWS, there are two ways to access resources for your AWS infrastructure. One to the EC2 machines via EC2 KeyPairs and one to the AWS console/APIs and other things. Let’s see and analyze these.
When an EC2 instance is launched using standard AMIs, you can connect to that instance using remote access protocols like SSH and RDP. In order for you to authenticate yourself to the EC2 instance, AWS provides asymmetric key pairs called as Amazon EC2 key pairs. EC2 Key Pairs are used for encrypting and decrypting login information: Public Key and Private Key. Public–key cryptography utilizes a public key to encrypt any piece of data, such as a password, and then the receiver can use the private key to decrypt the data.
To log in to your instance, it is essential to generate a key pair, identify the name of that key pair when instance has to be launched, and provide the information about the private key when you connect to the instance.
Identity and Access Management (IAM)
This is one of the most critical AWS service as it provides a centralized way to manage users, roles, groups and their corresponding access levels to various AWS resources in your account. You may consider Identity and Access Management (IAM) system as an outline for business procedures that helps in the management of electronic identities. It can be used to set off, capture, trace, and administer user identities and their connected access authorization in an automated style.
Inadequately inhibited IAM processes can result in regulatory non-compliance because if your enterprise is audited, your management will not be able to confirm that business data is not at risk for being misused.
It can be tricky to get financial support for IAM projects as they do not straight away add to either productivity or revenue. However, lack of efficient identity and access management pretends momentous risks not only to compliance but also an enterprise’s security on the whole. These misconduct issues raise the risk of bigger damages from both exterior and internal threats.
These resources maintain the requisite flow of business data available while at the same time overseeing their functions has always required managerial attention. There are many security threats which need to be taken care of while using these access control mechanism. These threats include:
You may have that disgruntled employee trying to harm your cloud infrastructure. If your data is not secured in transit or at rest, it can also lead to unauthorized access.
If the user accounts or services get hijacked, your cloud infrastructure gets vulnerable. Man in the middle attacks can happen if you do not follow proper security measures.
Human errors can lead to cloud outages bringing severe damages. They may also add in the security loopholes in your AWS cloud environment.
Lack of Understanding
AWS cloud infrastructure with its array of services needs specific proficiency. If there is a lack of understanding or knowledge of various AWS resources and their functions, you may be compromising you infrastructure’s security.
These security threats are alarming. But if you follow AWS security best practices, then you can easily deal with the majority of security challenges.
Following AWS security best practices, organizations can keep their data safe and secure. Here are some do’s and don’ts which must be followed to ensure that security is applied in layers. This gives various levels of shield from early attacks.
EC2 Key-Pair Do’s
Below are some of the AWS security best practices you must follow while working with Amazon EC2 key pairs.
Rotate SSH keys regularly
As a AWS security best practice, it is necessary to regularly rotate EC2 key pairs within your account.
Create Key Pairs Using Passphrase
If anyone gains access to your console, he would be able to log in to remote systems using your keys. To avoid this, it is better to use a passphrase on your key.
Enable Google Authenticator based MFA for SSH
Google offers the needed software to incorporate Google Authenticator’s time-based one-time password (TOTP) system with your SSH server. This will secure your SSH server with easy-to-use two-factor authentication.
Change SSH from port 22 to a non standard port
The major advantage of changing the port is to evade being noticed by casual scans.
EC2 Key-Pair Don’ts
Below are some of the things you must never do while working with Amazon EC2 key pairs.
Do not keep private keys in temp or home directories
You must not keep your private keys in directories which are publicly accessible. Better practice is to keep them in directories with limited access to users who may have the permission to use those keys.
Do not keep unused EC2 key pairs
It is a good practice to remove all the EC2 key pairs which aren’t attached to any instance.
Identity and Access Management Do’s
Below are some of the AWS security best practices you must follow while working with AWS IAM.
Create individual IAM users using unique credentials
Use unique credentials and keep individual credential rotation. Providing every user a unique identity will help you in keeping track of who is doing what. It would also help you in providing the right access required for an individual.
Grant least privilege
Give fewer chances to people for making mistakes. It is always better to relax than to tighten up. It is better to provide more granular control to API and resources and avoid assigning *:* policy.
Use groups to assign permissions to IAM users
It is always easy to assign the same permissions to multiple users. It helps in re-assigning users based on change in responsibilities. It can also help in mapping permissions to a specific business function.
Configure a strong password policy for your users
It is highly recommended to enforce a password policy for all your IAM users. You may define the minimum allowed password strength as well as password expiration for your AWS account.
Restrict privileged access further with conditions
With ability to add conditions to IAM policies, you can further control the access to a very granular level. It minimizes chances of accidentally performing privileged actions. You can define tag based or specific resource based access.
Enable MFA for all users not just privileged users, why take chance
This provides additional layer of AWS security and makes your infrastructure less vulnerable to unauthorized access.
Use roles for applications that run on Amazon EC2 instances
Using EC2 roles is the best way to provide access to your AWS infrastructure’s access via APIs. This will also ensure automatic key rotation.
Rotate credentials regularly
If there is an EC2 Access Key and Security Key attached to any IAM user, it is recommended to periodically rotate it. You may also enforce password expiration as your password policy. It increases safety and helps in keeping your infrastructure free from attacks.
Identity and Access Management Don’ts
Below are some of the things you must never do while working with AWS IAM.
Do not use your root account access keys
Create an IAM user for yourself and forget the root account. Use root account to login only when you absolutely need to do so.
Do not share access using Access Key & Secret Key
Stop using any third-party tools that asks for Access Keys & Secret Keys as it is not safe. Instead only use tools who take access using cross-account IAM roles.
Do not have single role for all the users
Create roles as per your business need and map IAM roles to your team/organization roles.
Do not have too many users with administrative access
Having too many admins increases the surface area of security threat. Hence, it is recommended to have only a limited number of users having full administrative rights.
Do not use old access keys. Rotate it.
Enough times said already. You must make it a habit to rotate access credentials.
Following these simple AWS security best practices, you can ensure that your cloud infrastructure is protected from unwanted and unauthorized access.
You must perform a regular AWS security audit to ensure that all the AWS security best practices are being followed in your cloud infrastructure. But performing such an extensive audit manually on regular periods, even once a day is really difficult. Botmetric’s thorough AWS security audit helps you discover AWS security best practices violations within minutes. It also allows you to automate security audit of your infrastructure and deliver results to your inbox.
If you aren’t using Botmetric yet, sign up for a 14-day trial and automate your security audit.
Hope this post helps you in strengthening your AWS cloud infrastructure’s security. We would love to hear your feedbacks and questions. Tweet to Us.
Next in our AWS security best practices series, we will discuss about another major security threat landscape: Network Security.
Latest posts by Amar (see all)
- Why Your Cloud Strategy Is Failing? – The Cloud Adoption Mistakes - October 5, 2017
- Continuous Security: A Necessity on Cloud - February 2, 2017
- Bridging the Cloud Security Gaps: With Freedom Comes Greater Responsibility - December 17, 2016