26 AWS Security Best Practices to Adopt in Production – Part 1
Share article
Table of Contents
One of the most important pillars of a well-architected framework is security. Thus, it is important to follow these AWS security best practices to prevent unnecessary security situations.
So, you’ve got a problem to solve and turned to AWS to build and host your solution. You create your account and now you’re all set up to brew some coffee and sit down at your workstation to architect, code, build, and deploy. Except, you aren’t!
There are many things you must set up if you want your solution to be operative, secure, reliable, performant, and cost effective. And, first things first, the best time to do that is now – right from the beginning, before you start to design and engineering.
Initial AWS setup
Never, ever, use your root account for everyday use. Instead, head to Identity and Access Management (IAM) and create an administrator user. Protect and lock your root credentials in a secure place (is your password strong enough?) and, if your root user has keys generated, now is the best time to delete them.
You will absolutely want to activate Multi Factor Authentication (MFA) too for your root account. You must end up with a root user with MFA and no access keys. And you won’t use this user unless strictly necessary.
Now, about your newly created admin account, activating MFA for it is a must. It’s actually a requirement for every user in your account if you want to have a security first mindset (and you actually want to), but especially so for power users. You will only use this account for administrative purposes.
For daily use, you need to go to the IAM panel and create users, groups, and roles which can access only the resources to which you explicitly grant permissions.
Now you have:
- Root account (with no keys) securely locked into a safe.
- Admin account for administrative use.
- Several users, groups, and roles for day to day use.
All of them should have MFA activated and strong passwords.
You are almost ready to begin your actual work, but first, a word of caution about the AWS shared responsibility model.
Security and compliance is a shared responsibility between AWS and the customer. AWS operates, manages, and controls the components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software, as well as the configuration of the AWS provided security group firewall.
Therefore, the management and application of diligent AWS security is the responsibility of the customer.
AWS Cloud security best practices checklist
In this section we will walk through the most common AWS services and provide 26 security best practices to adopt.
AWS Security best practices with open source – Cloud Custodian is a Cloud Security Posture Management (CSPM) tool. CSPM tools evaluate your cloud configuration and identify common configuration mistakes. They also monitor cloud logs to detect threats and configuration changes.
Now let’s walk through service by service.
| AWS security best practices by service | |||
| High Risk 🟥🟥🟥 | Medium Risk 🟨🟨 | Low Risk 🟩 | |
| AWS IAM | (1) IAM policies should not allow full “*” administrative privileges
(4) IAM root user access key should not exist (6) Hardware MFA should be enabled for the root user |
(3) IAM users’ access keys should be rotated every 90 days or less
(5) MFA should be enabled for all IAM users that have a console password (7) Password policies for IAM users should have strong configurations (8) Unused IAM user credentials should be removed |
(2) IAM users should not have IAM policies attached |
| Amazon S3 | (10) S3 buckets should have server-side encryption enabled | (9) S3 Block Public Access setting should be enabled
(11) S3 Block Public Access setting should be enabled at the bucket level |
|
| AWS CloudTrail | (12) CloudTrail should be enabled and configured with at least one multi-Region trail | (13) CloudTrail should have encryption at rest enabled
(14) Ensure CloudTrail log file validation is enabled |
|
| AWS Config | (15) AWS Config should be enabled | ||
| Amazon EC2 | (16) Attached EBS volumes should be encrypted at rest
(19) EBS default encryption should be enabled |
(17) VPC flow logging should be enabled in all VPCs
(18) The VPC default security group should not allow inbound and outbound traffic |
|
| AWS DMS | (20) AWS Database Migration Service replication instances should not be public | ||
| Amazon EBS | (21) Amazon EBS snapshots should not be public, determined by the ability to be restorable by anyone | ||
| Amazon OpenSearch Service | (22) Elasticsearch domains should have encryption at rest enabled | ||
| Amazon SageMaker | (23) SageMaker notebook instances should not have direct internet access | ||
| AWS Lambda | (24) Lambda functions should use supported runtimes | ||
| AWS KMS | (25) AWS KMS keys should not be unintentionally deleted | ||
| Amazon GuardDuty | (26) GuardDuty should be enabled |
AWS Identity and Access Management (IAM)
AWS Identity and Access Management (IAM) helps enforce least privilege access control to AWS resources. You can use IAM to restrict who is authenticated (signed in) and authorized (has permissions) to use resources.
1.- Do not allow full “*” administrative privileges on IAM policies 🟥🟥🟥
IAM policies define a set of privileges that are granted to users, groups, or roles. Following standard security advice, you should grant least privilege, which means to allow only the permissions that are required to perform a task.
When you provide full administrative privileges instead of the minimum set of permissions that the user needs, you expose the resources to potentially unwanted actions.
For each AWS account, list the customer managed policies available:
aws iam list-policies –scope Local –query ‘Policies[*].Arn’
The previous command will return a list of policies along with their Amazon Resource Names (ARNs). Using these ARNs, now retrieve the policy document in JSON format:
aws iam get-policy-version
–policy-arn POLICY_ARN
–version-id v1
–query ‘PolicyVersion.Document’
The output should be the requested IAM policy document:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “1234567890”,
“Effect”: “Allow”,
“Action”: “*”,
“Resource”: “*”
}
]
}
Look into this document for the following elements:
“Effect”: “Allow”, “Action”: “*”, “Resource”: “*”
If these elements are present, then the customer-managed policy allows full administrative privileges. This is a risk and must be avoided, so you will need to tune these policies down to pinpoint exactly what actions you want to allow for each specific resource.
Repeat the previous procedure for the other IAM customer managed policies.
If you want to detect the use of full administrative privileges with open source, here is a Cloud Custodian rule:
– name: full-administrative-privileges
description: IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege -that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges.
resource: iam-policy
filters:
– type: used
– type: has-allow-all
2.- Do not attach IAM policies to users 🟩
By default, IAM users, groups, and roles have no access to AWS resources.
IAM policies grant privileges to users, groups, or roles. We recommend that you apply IAM policies directly to groups and roles but not to users. Assigning privileges at the group or role level reduces the complexity of access management as the number of users grows. Reducing access management complexity might in turn reduce the opportunity for a principal to inadvertently receive or retain excessive privileges.
3.- Rotate IAM users’ access keys every 90 days or less 🟨🟨
AWS recommends that you rotate the access keys every 90 days. Rotating access keys reduces the chance that an access key that is associated with a compromised or terminated account is used. It also ensures that data cannot be accessed with an old key that might have been lost, cracked, or stolen. Always update your applications after you rotate access keys.
First, list all IAM users available in your AWS account with:
aws iam list-users –query ‘Users[*].UserName’
For all the users returned by this command, determine each active access key lifetime by doing:
aws iam list-access-keys –user-name USER_NAME
This should expose the metadata for each access key existing for the specified IAM user. The output will look like this:
{
“AccessKeyMetadata”: [
{
“UserName”: “some-user”,
“Status”: “Inactive”,
“CreateDate”: “2022-05-18T13:43:23Z”,
“AccessKeyId”: “AAAABBBBCCCCDDDDEEEE”
},
{
“UserName”: “some-user”,
“Status”: “Active”,
“CreateDate”: “2022-03-21T09:12:32Z”,
“AccessKeyId”: “AAAABBBBCCCCDDDDEEEE”
}
]
}
Check the CreateDate parameter value for each active key to determine its creation time. If an active access key has been created before the last 90 days, the key is outdated and must be rotated to secure the access to your AWS resources.
Repeat for each IAM user existing in your AWS account.
4.- Ensure that IAM root user access keys do not exist 🟥🟥🟥
As we stated during your initial setup, we highly recommend that you remove all access keys that are associated with the root user. This limits the vectors that can be used to compromise your account. It also encourages the creation and use of role-based accounts that are least privileged.
The following Cloud Custodian rule will check if root access keys have been used on your account:
– name: root-access-keys
description: The root user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root user account be removed.
resource: account
filters:
– type: iam-summary
key: AccountAccessKeysPresent
value: 0
op: gt
5.- Enable MFA for all IAM users that have a console password 🟨🟨
Multi-factor authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they are prompted for their username and password. In addition, they are prompted for an authentication code from their AWS MFA device.
We recommend that you enable MFA for all accounts that have a console password. MFA is designed to provide increased security for console access. The authenticating principal must possess a device that emits a time-sensitive key and must have knowledge of a credential.
6.- Enable hardware MFA for the root user 🟥🟥🟥
Virtual MFA might not provide the same level of security as hardware MFA devices. A hardware MFA has a minimal attack surface, and cannot be stolen unless the malicious user gains physical access to the hardware device. We recommend that you use only a virtual MFA device while you wait for hardware purchase approval or for your hardware to arrive, especially for root users.
To learn more, see Enabling a virtual multi-factor authentication (MFA) device (console) in the IAM User Guide.
Here is a Cloud Custodian rule to detect lack of root hardware MFA:
– name: root-hardware-mfa
description: The root user account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device. It is recommended that the root user account be protected with a hardware MFA.
resource: account
filters:
– or:
– type: iam-summary
key: AccountMFAEnabled
value: 1
op: ne
– and:
– type: iam-summary
key: AccountMFAEnabled
value: 1
op: eq
– type: has-virtual-mfa
value: true
7.- Ensure those password policies for IAM users have strong configurations 🟨🟨
We recommend that you enforce the creation of strong user passwords. You can set a password policy on your AWS account to specify complexity requirements and mandatory rotation periods for passwords.
When you create or change a password policy, most of the password policy settings are enforced the next time users change their passwords. Some of the settings are enforced immediately.
What constitutes a strong password is a subjective matter, but the following settings will put you on the right path:
RequireUppercaseCharacters: true
RequireLowercaseCharacters: true
RequireSymbols: true
RequireNumbers: true
MinimumPasswordLength: 8
8.- Remove unused IAM user credentials 🟨🟨
IAM users can access AWS resources using different types of credentials, such as passwords or access keys. We recommend you remove or deactivate all credentials that were unused for 90 days or more to reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used.
You can use the IAM console to get some of the information that you need to monitor accounts for dated credentials. For example, when you view users in your account, there is a column for Access key age, Password age, and Last activity. If the value in any of these columns is greater than 90 days, make the credentials for those users inactive.
You can also use credential reports to monitor user accounts and identify those with no activity for 90 or more days. You can download credential reports in .csv format from the IAM console.
For more information, check out AWS security best practices for IAM in more detail.
Conclusion
Going all cloud opens a new world of possibilities, but it also opens a wide door to attacking vectors. Each new AWS service you leverage has its own set of potential dangers you need to be aware of and well prepared for.
Luckily, cloud native security tools like Renova Cloud, an AWS Consulting Partner with a focus on Security, can guide you through these best practices, and help you meet your compliance requirements.
Subscribe now to learn more about security best practices in AWS part 1 and part 2.
