AWS top 10 misconfigurations and how to fix them: A cheat sheet

Amazon Web Services (AWS) remains the dominant cloud provider, with 40.8% of the market share. Many enterprises and organizations today have some, if not most, of their infrastructure on Amazon Web Services. AWS helps organizations accelerate their digital transformations and innovate faster, but there are common misconfigurations when moving to AWS. 

Common misconfigs can lead to security breaches or security gaps in infrastructure, leaving you scrambling to identify what bad actors did in your AWS account. So, to prevent these possible security gaps in your infrastructure and potential security breaches, here are the top 10 AWS misconfigs we will cover:

1. Using root user as the main AWS account user.

2. Saving long-living secrets in application code bases.

3. Use of * permission in IAM policies.

4. Using unauthorized AWS services in your AWS account.

5. Lack of encryption of data stored in AWS storage services.

6. Not enabling monitoring tools for your AWS accounts.

7. Security groups open to everyone on the internet.

8. Having all services in 1 AWS account.

9. AWS RDS insecure defaults  

10. Dangling DNS with a public deleted AWS s3 bucket.

Download our AWS security misconfigurations cheat sheet to learn more about how to avoid the following misconfigurations. 

1. Don’t use Root User as the main AWS account user

Root User is the AWS-provided user with administrative privileges. hHowever, if Root User is compromised, it can lead to a total loss of access to all AWS accounts where the root user has access to that organization. Instead of Root User, use Federation (AWS Identity Center) for human users or AWS IAM Users. 

The Root User has access to every AWS resource and service in an account. If the credentials for the root account become compromised, bad actors will have access to sensitive applications and data and possibly a chance to misuse the data and resources in the compromised account. 

It is critical to keep the root user safe and out of reach of bad actors. Along with using Federation or AWS IAM Users, there are other things you can do to keep your root user account secure:

• Create an IAM user for yourself and give yourself administrative permissions.

• Never share the Root User credentials.

• If possible, use a password manager and create a strong password. 

• Make sure to enable multi-factor authentication.

• Have alerting for when the root user is logged in to be notified if someone is using the Root User account.

2. Don’t save long-living secrets in application codebases

Using AWS programmatically means providing your AWS access keys for identity verification in programmatic calls. These access keys consist of both an access key ID and a secret access key. Therefore, anyone with your access keys has the same access to your AWS resources that you do. Accordingly, protecting your access keys is critical because if these access keys were compromised, malicious actors could use them to access all services available via the keys programmatically. 

In fact, we recommend rotating your AWS access keys every 90 days, and deleting the access keys that have not been used for more than 90 days.  If possible, do not store access keys in application code, implementation softwares, or storage in the cloud.

3.  Use * permissions in IAM policies

We are only as secure as what is actually deployed and running in our cloud environments.

Therefore, to ensure you’re not granting permission or access to everything, assign your permission policies to IAM Users, IAM Roles, Groups, and AWS workload profiles (Instance Profiles). 

You can use IAM Access Analyzer to stay ahead or even fix this. IAM Access Analyzer allows you to:

• Develop least-privilege policies based on access activity.

• Monitor and review supported resource types continuously. Continuous monitoring helps you identify resources that allow for public or cross-account access. It also allows you to identify resources that are too permissive regarding any assigned permissions.

Once you deploy your IAM policies to your production environment, rest assured that you have granted only the required permissions to your workload.

4. Don’t use unauthorized AWS services in your AWS account

Compliance, legal or technical, varies from industry to industry. Most organizations build a list of known industry-compliant AWS services and the geographical regions they operate in. This allows organizations to continue to operate and maintain industry compliance requirements legally and quickly in the markets they need to operate in.

However, working outside these regions or using AWS services that breach their legal or compliance mandates will most likely result in massive fines for organizations. 

We recommend using AWS SCP in AWS Organizations to define the safety guardrails for managing access of all IAM users and roles across your AWS accounts.

5. Encrypt data stored in AWS storage services

Part of the defense in depth baked into the security of AWS is the idea that you should encrypt all data at rest and in transit. You can do this with your organization-managed encryption keys (AWS KMS with CMK).

As cloud adoption continues to increase for building infrastructure and applications, there is going to be a lot of data that will inevitably be stored, transmitted, or processed in AWS. Availing that data as plain text or in an unencrypted format invites malicious actors to read, copy, or modify the data. To prevent this and other security breaches, encrypt your data at rest or in transit.

6. Start enabling monitoring tools for your AWS accounts

Monitoring is crucial to maintaining your AWS solutions' availability, reliability, and performance. If a malicious attacker comes after your infrastructure, it is important to know the steps they took in your AWS Accounts. 

AWS offers several monitoring tools that report when something is wrong and take action automatically when appropriate. To keep yourself informed, enable the following tools to monitor your account:

• AWS CloudTrail in All AWS Regions 

• AWS CloudWatch for all resources & applications in AWS 

• Depending on your organization's risk profile, you may also want to consider enabling AWS VPC Flow logs and AWS S3 Access Log.

7. Use Security Groups to control traffic from the internet 

Creating resources in your AWS Accounts that can be accessed via the internet leaves you vulnerable to attacks. Malicious actors constantly scan IP addresses on the internet for potential vulnerabilities or unauthenticated servers to use for their personal benefit.

You can use the Security Groups rules to restrict resource access to only known IP addresses or known applications/networks. We also recommend AWS Security Hub and AWS GuardDuty to monitor your AWS accounts and workloads for malicious activity and automatic remediation.

8. Don’t have all services in one AWS account

When you host all of your applications in one AWS account, it makes it easy for bad actors to gain access to your account and enumerate all the services and other applications hosted in your AWS account. 

Instead, separate and manage multiple accounts to keep your resources safe. 

AWS Organization is a service from AWS that can separate and manage multiple AWS Accounts. Using AWS’s Well-Architected Framework to separate applications and workloads reduces the blast radius of a potential bad actor gaining access to your AWS Account. 

9. Prevent misconfigurations in AWS RDS 

Managed databases like AWS RDS (Amazon’s Relational Database Service) can be misconfigured and become accessible to anyone because they don’t require authentication or a default database-admin password.

Many applications use a backend database to store personal and sensitive customer information and data. To prevent misconfigs that leave data vulnerable, limit access to Security Groups of AWS RDS instances to only known IP addresses. Additionally, you can also change the default credentials on database instances used by AWS RDS.

10. Prevent a dangling DNS 

Ensure that none of the DNS (Domain Name System) entries in Route53 are unknown or no longer linked to a public AWS S3 bucket. 

Websites managed and hosted on a public cloud provider (like AWS) are prone to dangling DNS. If the files and servers hosting the website can be replaced by an attacker’s server, it will result in a subdomain takeover. 

To prevent this, maintain an inventory of all active DNS records and regularly audit processes to ensure that if any DNS entries are no longer required, their resources have been deleted too. 

Additionally, continuously monitor if an AWS S3 bucket is accidentally exposed to the internet, or an S3 bucket with the static website hosting config enabled is deleted. Then, relevant remediation can be performed. Automated alerting should be a part of this continuous monitoring.

Securing your cloud infrastructure

While migrating to a cloud provider offers substantial benefits — such as cost savings, scalability, competitive advantage, enhanced security, and opportunities for collaboration — setup must be performed correctly to avoid the misconfigurations we’ve covered today. Reducing potential for security breaches in your application is an ongoing responsibility for development and security teams alike, but Snyk is here to help. Check out our AWS misconfiguration cheat sheet for more information and remediation tips today — and if you haven’t already, create a free Snyk account or book a demo to see how Snyk can help you find and fix vulnerabilities in your cloud infrastructure. 

Download cheat sheet