Top-10 AWS Security Tips

Despite the numerous advantages of cloud computing, enterprises can’t reap the benefits of cloud computing without first securing its infrastructure, software applications, and underlying data.

Amazon Web Services (AWS) offers a scalable cloud computing platform with high availability as well as a variety of tools to help users operate a wide range of applications. AWS is in charge of securing the cloud’s core infrastructure, while you are in charge of whatever you place in or connect to the cloud. Having said that, AWS offers a number of tools to help secure your account. Following are some key findings to consider when safeguarding your AWS account and its resources.

Authentication

Authentication is an essential objective of computer security. It guarantees that an action performed is not forged and it does actually come from whom it states. Anyone who gets access to your authentication methods, such as if someone gets ahold of your AWS credentials, can easily log into your AWS account and compromise it.

Suggestions:

• Enable MFA

Multi-Factor Authentication (MFA) is a method that is often used in security configurations where the user needs to provide additional verifications to gain access to a resource. MFA is used to add extra security to the system. You can enable MFA for IAM users or the AWS account root user. You can select the type of MFA device you want to use from the list of supported MFA devices in AWS. AWS offers to configure MFA on specific API calls as well. It is advised to always set up MFA on your Root user, IAM users, and crucial API operations such as ec2:TerminateInstances, s3:DeleteObject, dynamodb:ListTable, etc.
Find more information about MFA

{
“Version”: “2012–10–17”,
“Statement”:[
{
“Sid”: “AllowActionsForEC2”,
“Effect”: “Allow”,
“Action”: [“ec2:RunInstances”,
“ec2:DescribeInstances”,
“ec2:StopInstances “],
“Resource”: “*”
},
{
“Sid”: “AllowActionsForEC2WhenMFAIsPresent”,
“Effect”:”Allow”,
“Action”:”ec2:TerminateInstances”,
“Resource”:”*”,
“Condition”:{
“Bool”:{“aws:MultiFactorAuthPresent”:”true”}
}
}
]
}

The above policy demonstrates how to use this condition key to require MFA authentication for users attempting to call the EC2 TerminateInstances action.

Password management

Passwords are the first line of defense against unauthorized access to your valuable resources. Either it is a phone, a web application, a bank account, or an online cloud management service, passwords help your valuable assets stay private and secure. The main types of security credentials of AWS are passwords and access keys. They can be applied to the AWS root user account or individual AWS IAM users. Therefore, safeguarding these credentials are a must to protect your AWS resources.

Suggestions:

• Strong passwords

According to the 2020 Verizon Data Breach Investigations Report, 81% of the total number of breaches leveraged stolen or weak passwords. You need to set a strong password to your AWS root account as well for each IAM user. A password is deemed secure if it has a random combination of numbers, symbols, uppercase letters, and lowercase letters and is at least 12 characters long. Avoid using personal information when constructing your password. Find more information about AWS password policy

• Password rotation

People tend to use the same password in both their personal and professional lives. The issue with this practice is that if someone gains access to one of your passwords, they may gain access to all of your resources. Password rotation ensures users from reusing the same passwords again and again. It mitigates the risk of compromising invaluable assets, which puts the business at significant risk. AWS provides rotation strategies for managing secrets. Find more information about AWS rotating secrets

Safeguard AWS Credentials

As mentioned in the previous section, the two main types of AWS security credentials are passwords and access keys. Now that you know how to protect passwords, it is time to find out how to protect AWS secret access keys. Access keys act as long-term credentials for IAM users. They are also used to digitally sign API calls made to AWS services. You need to protect access keys as securely as you would any other confidential personal data. Your access keys provide anyone with them the same level of access to your AWS resources as you do.

Suggestions:

• Safeguard root user access keys

A root user is a user that is generated when an AWS account is created. The account owner’s credentials grant full access to all account resources. And this includes billing information of the account as well. AWS has not yet provided an escape route to reduce the permissions associated with the root user. For that reason, you should always disable root API access keys and secret keys. At all times, use the account email address and password to sign in to the AWS Management Console. Create a separate IAM user that has admin privileges instead of using the root user.

• IAM user access keys

You can create any amount of IAM users in your AWS account. It allows you to create individual users for anyone that needs access to your AWS account. As a best practice, users should rotate their access keys regularly. You can also check the last used access keys from the IAM console. It will help to keep track of who is using what and when.

• Limit programmatic access

Programmatic access means accessing AWS resources with a pair of access keys. Users with this access have access to the APIs, AWS CLI, and Tools. To adhere to security best practices, you need to limit providing programmatic access to every IAM user. If the access keys are exposed to the outside world, anyone can access your AWS resources using those keys. Find more information about programmatic access

IAM policy management

An IAM policy is a great feature that allows you to define fine-grained rules to control access to AWS resources. There are several facts to consider when creating efficient and secure IAM policies.

Suggestions:

• Grant least privilege

The principle of least privilege in security states that users cannot access system resources beyond what is required to execute a task. You need to follow this concept when you are dealing with IAM policies. ALWAYS follow this rule → “Grant only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks”. You can start off easy with a minimum set of permissions and work your way up by providing any additional permissions necessary.

Bad example:

{
“Version”: “2012–10–17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “s3:*”,
“Resource”: [
“arn:aws:s3:::dev_artifact_bucket”,
“arn:aws:s3:::dev_artifact_bucket/*”
]
}
}

Good example:

{
“Version”: “2012–10–17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “s3:ListBucket”,
“Resource”: [
“arn:aws:s3:::dev_artifact_bucket”,
“arn:aws:s3:::dev_artifact_bucket/*”
]
}
}

• Customer-managed policies

There are two main policy types in AWS. Managed policies and Inline policies. Managed policies are further classified into two, AWS-managed and customer-managed. Customer-managed policies are standalone policies that you can administer in your AWS account. You can easily create a customer-managed policy by copying an existing AWS-managed policy and customizing it with your permissions and entities. It is well-advised not to use inline policies as much because they are embedded into IAM entities (user, user group, or role) and harder to inspect or view them from a centralized location, unlike managed policies that are viewable through the AWS console, CLI, and API operations.

(Image source: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)

• Validate the policies

If you create a custom policy, it is best to validate it first before applying and using it. Policy validation can be done when you create and edit JSON policies. AWS IAM is configured to identify any syntax errors. There is another excellent feature of IAM which is the IAM Access Analyzer. It provides over 100 policy checks and can also recommend secure and functional policies with policy writing. Find more information about validating IAM policies

Manage IAM Users, Groups, and Roles

Ensuring that the users have the appropriate and least level of permissions to perform any task in your AWS account is a necessity. There are several factors that you need to consider if you are managing multiple AWS accounts, IAM users, IAM groups, or multiple IAM roles.

Suggestions:

• Validate IAM roles

IAM role is an IAM identity that you can create in your account that has specific permissions. These are an excellent way to delegate permission within your AWS account. You can provide different types of access to AWS resources using IAM roles, without having to share AWS security credentials with every user. A role is meant to be assumable by anyone who requires it, rather than being identified with a specific individual user.

A great way to use IAM roles in your account is with temporary security credentials. As the name depicts, these credentials are valid only for a short amount of time ranging from minutes to hours. Temporary credentials are generated by AWS STS (Security Token Service). A general use-case of temporary credentials are binding them with EC2 instances. If you have applications running on EC2 and those apps need to access AWS resources, you can easily provide temporary credentials to the instances when you launch them. It mitigates the risk of storing long-term credentials inside your EC2 instance. Find more information about AWS temporary credentials

• Audit IAM users and their policies frequently

As mentioned earlier in the IAM policy management section, all IAM users need to have the most restrictive policies attached to them as possible. You can set up individual MFA devices for each IAM user who has access to the console. Audit your IAM users and their rights regularly, and remove any unnecessary IAM users or keys.

Data Security

The practice of protecting data from unauthorized access and data corruption/loss throughout its lifecycle is known as data security. Accidental data exposure, phishing, and social engineering attacks, data loss in the cloud, cloud misconfigurations, compromised credentials are some of the examples of threats to data security. The means of protecting data at rest and in transit should always be implemented when using the cloud. There are several ways that you can do this and you’ll want to use as many as possible, which shall ensure that all potential threats are mitigated.

Suggestions:

• Protecting data at rest

Data at rest refers to data that is stored in data storage facilities such as in S3 buckets, EBS volumes, and RDS instances. There are a number of security features that AWS has offered for the protection of data at rest.

• S3 — You can use bucket-level or object-level permissions in your S3 bucket. Versioning is also another great feature that can be used to restore compromised or deleted objects if there were any. AWS also provides server-side and client-side encryption for data stored inside S3 buckets.
• EBS — EBS volumes can be encrypted according to the OS it is bound with or simply by using EBS Encryption. If you are using Windows, you can use Windows Encrypted File System and Windows BitLocker features. If you are using Linux, dm-crypt, and TrueCrypt are the go-to encryption solutions. You may also want to start using replication and backups of EBS volumes as well.
• RDS — RDS is an AWS-managed service. But it is the user’s responsibility to enable security features such as using strong db authentication mechanisms (strong hash schemes, client authentication, etc.), enable encryption for DB resources and instances, access control using security groups, etc.
• Protecting data in transit

This is otherwise known as the security of data in motion. It’s information traveling from one point to another across the internet and or networks you don’t own/control. As all cloud applications are communicating over the Internet, it is important to protect data in transit. When it comes to AWS cloud services, they provide support for both IPSec and SSL/TLS for the protection of data in transit. Always use HTTPS with server certificate authentication for your web applications in AWS. If you need remote access to your Linux servers, use the SSH version 2 protocol or make use of the AWS-managed VPN service.

Secure O/S and Applications

If you do not secure the underlying operating system and the application itself that you are hosting, you will always be at risk no matter what features you have enabled for your AWS infrastructure. Following are some suggestions that you might want to consider when securing the OS and applications.

Suggestions:

• Rotate credentials

Rotating access credentials such as passwords, certificates, or keys is a universally accepted best practice for security. Credentials that will be used to access databases, applications need to be rotated on a monthly or weekly basis.

• Secure storage of .pem files

A .pem file is used to SSH into a server. Anyone who has access to those keypair files has access to your servers. Therefore, you must password protect and securely store these in a safe place on your computer.

• Custom AMIs

You can design your own AMIs (Golden AMIs) to match your organization’s specific needs and make them available for internal (private) or external (public) use. You are responsible for the overall security of the machine images you publish. It is best advised to create these AMIs with updated security patches to minimize the risk of exploiting known vulnerabilities of an O/S.

• AWS Secrets Manager

AWS Secrets Manager is a terrific service that helps you easily rotate, manage, and retrieve secrets such as database credentials, API keys, and other types of secrets throughout their lifecycle. You can use AWS Secrets Manager to manage any API keys, OAuth tokens, DB credentials, etc. that will be used by users or applications.

Secure Infrastructure

Network security is another component that you need to consider in AWS cloud security. Even though AWS is responsible for its security of the cloud, security in the cloud must be configured properly by the users.

Suggestions:

• VPC security

Security groups, network ACLs, and routing tables, and external gateways are some of the security features available in Amazon VPC. You can restrict access to your subnets using security groups for your VPC. Use public, private, and database subnet features when necessary. You must configure Amazon VPC subnet route tables with the minimal required network routes. Using AWS VPN or AWS Direct Connect to establish private connections from your remote networks to your VPCs is also recommended.

• Security groups

Security groups are the equivalent of a firewall that provides stateful Layer 3/Layer 4 filterings for EC2 interfaces. You need to limit the ingress or otherwise known as inbound port ranges as much as possible. You may be vulnerable to just about any vulnerabilities or unexpected access to services if you leave wide port ranges accessible. Always monitor the creation or deletion of security groups. You can use IAM roles to limit modifications of security groups to authorized roles only.

Security monitoring, Alerting, and Incident Response

It is a best practice to actively monitor your account and its resources to discover any unexpected activity or access to your account because AWS doesn’t actively monitor your usage to investigate issues for privacy and security reasons.

Suggestions:

• AWS Cloudwatch

Cloudwatch provides visibility into resource utilization, operational performance, and several metric types such as CPU utilization, network traffic, disk read and writes, etc. It also can be configured to monitor other managed AWS services and trigger alerts as necessary.

(Image source: https://aws.amazon.com/cloudwatch/ )

• AWS Cloudtrail

Cloudtrail logging service can be used to track what credentials are used to initiate particular API calls, as well as when they are used. AWS recommends writing these Cloudtrail logs to an S3 bucket for later analysis. Find more information about AWS Cloudtrail logs

(Image source: https://aws.amazon.com/cloudtrail/ )

• AWS Config

AWS Config is a continuous monitoring and assessment service that records changes to the configuration of your AWS resources. The current and historic configurations of a resource can be viewed from the AWS config in which can be used for troubleshooting, security attack analysis, etc. You can also write a custom AWS Config Rule to systemize your own corporate security policies. AWS Config alerts you in real-time when a resource is misconfigured, or when a resource violates a particular security policy.

(Image source: https://aws.amazon.com/config/ )

• PatchDuty

PatchDuty is an AWS architecture and security solution that provides agentless monitoring and smart cloud infrastructure diagrams for AWS accounts. PatchDuty’s security scanner feature can be used to manage your cloud environments by ensuring compliance with more than 500 custom rules added on top of AWS’ existing security policies. You can tag policies as well as use this tool to view as a garbage collection of unused resources from a single tool. Learn more about PatchDuty

Conclusion

While Amazon Web Services (AWS) provides a solid security layer surrounding its infrastructure and services, businesses are still responsible for the confidentiality, integrity, and availability of their data in the cloud. This article highlights various aspects and best practices that you can use to secure your organization, its users, and applications with AWS. Security must always be the starting point, not an afterthought.

References

• https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/
• https://aws.amazon.com/blogs/security/getting-started-follow-security-best-practices-as-you-configure-your-aws-resources/
• https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/
• https://www.patchduty.com