One of the main pillars of a well-built framework is security. So, for greater security and to prevent unwanted security problems, let's detail some service-specific security guidelines.

‍

Since there is so much to this topic, we’ll split it into four parts for easier readability, and convenience. Today we’ll cover the basic configuration and security practices for AWS IAM. 

To navigate to the information that you need here’s a quick summation of topics: 

• Part 1: basics, and AWS IAM. 
• Part 2: Amazon S3, AWS CloudTrail, and AWS Config
• Part 3: Amazon EC2, AWS DMS, Amazon EBS, Amazon OpenSearch Service
• Part 4: Amazon SageMaker, AWS Lambda, AWS KMS, Amazon GuardDuty

‍

So, you've encountered a problem and turned to AWS to build and host your solution. After setting up your account, you thought you'd be able to design, code, build, and deploy. However, there are crucial steps to take for the solution to be operational, secure, reliable, performant, and cost-effective. The optimal time to address these is now, right from the beginning, before diving into the design and engineering process.

Setting Up AWS for the First Time

Never utilize your root account for day-to-day activities. Instead, navigate to Identity and Access Management (IAM) to create an administrator user. In IAM, craft an administrator user for routine tasks. Safeguard and store your root credentials securely, ensuring your password is as strong as possible. If your root user has generated keys, consider deleting them at this point.

‍

To start off right, make sure to activate Enable Multi-Factor Authentication (MFA) for your root account. You should also ensure your root user has MFA enabled and no access keys. Reserve the use of this user strictly for necessary situations. In addition to these, it's also essential to enable MFA for your newly created admin account. In fact, it's a mandatory step for every user in your account, promoting a security-first approach. This is particularly important for power users.

‍

The admin account should only be utilized for administrative purposes. To ensure secure daily operations on AWS, navigate to the IAM panel and create users, groups, and roles with explicit permissions for resource access.

Here's your current setup:

• Your root account, with no keys, is securely stored in a safe.
• A designated admin account is reserved exclusively for administrative tasks.
• Several users, groups, and roles tailored for everyday activities.

‍

Each should have MFA activated and strong passwords you could never remember yourself.With this setup, you are on the verge of adhering to AWS security best practices. However, before proceeding, it's essential to acknowledge a crucial aspect: the AWS shared responsibility model.

AWS Shared Responsibility Model

Security and compliance involve both AWS and the customer in a shared responsibility model. AWS takes charge of, oversees, and manages components from the host operating system and virtualization layer to the physical security of the operating facilities. On the other hand, the customer takes on the responsibility and management tasks related to the guest operating system, including updates and security patches. Additionally, the customer handles other associated application software and configures the security group firewall provided by AWS.

‍

Hence, it is the customer's responsibility to oversee and implement thorough AWS security measures.

AWS Security Best Practices Checklist

This section outlines essential AWS services and presents a comprehensive checklist of 26 security best practices to embrace. To enhance clarity, we'll divide the checklist into four parts, as previously mentioned. When it comes to AWS security, incorporating open-source solutions is valuable. Cloud Custodian, a Cloud Security Posture Management (CSPM) tool, proves beneficial in assessing your cloud configuration and identifying common mistakes.

‍

CSPM tools also play a crucial role in monitoring cloud logs to detect potential threats and configuration changes. Now, let’s go proceed and examine each AWS service in detail.

AWS Identity & Access Management (IAM)

In implementing least privilege access control over AWS resources, there is a vital role for AWS Identity and Access Management (IAM). With IAM, you have the capability to limit access to authenticated (signed-in) individuals and control authorization (permissions) for resource usage.

1. Avoid Granting Full Administrative Privileges in IAM Policies

IAM policies outline the permissions assigned to users, groups, or roles. Due to security reasons, it is advised to adhere to the principle of least privilege. This means granting only the necessary permissions for a particular task.

Providing full administrative privileges, denoted by "*", rather than the minimum required permissions, exposes resources to potentially undesired actions.

‍

Make sure to list the customer-managed policies available for each account:

<pre class="codeWrap"><code>aws iam list-policies --scope Local --query 'Policies[*].Arn'</code></pre>

Executing the above command will display a list of policies along with their Amazon Resource Names (ARNs). To retrieve the policy document in JSON format, utilize these ARNs:

<pre class="codeWrap"><code>aws iam get-policy-version
--policy-arn POLICY_ARN
--version-id v1
--query 'PolicyVersion.Document'
</code></pre>

The output will present the requested IAM policy document:

<pre class="codeWrap"><code>{
   "Version": "2012-10-17",
   "Statement": [        
{
           "Sid": "1234567890",
           "Effect": "Allow",
           "Action": "",
           "Resource": ""
       }
   ]
}
</code></pre>

‍

Examine this document for the following elements:

<pre class="codeWrap"><code>"Effect": "Allow", "Action": "", "Resource": "" </code></pre>

‍

If these elements are present, it indicates that the customer-managed policy allows full administrative privileges, posing a risk. It's crucial to refine these policies to specify precisely which actions are permissible for each specific resource. Repeat the preceding process for other customer-managed IAM policies.

‍

To identify the use of full administrative privileges using open source, consider employing a Cloud Custodian rule:

<pre class="codeWrap"><code> - 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
</code></pre>

2. Avoid Attaching IAM Policies Directly to Users

By default, IAM users, groups, and roles start with no access to AWS resources.

IAM policies are responsible for assigning privileges to users, groups, or roles. It is advisable to associate IAM policies directly with groups and roles instead of users. Applying privileges at the group or role level helps streamline access management, especially as the number of users increases. This reduction in access management complexity can decrease the likelihood of a principal unintentionally acquiring or retaining excessive privileges.

3. Regularly Update IAM User Access Keys

AWS suggests changing IAM user access keys every 90 days or sooner. This practice minimizes the risk associated with compromised or terminated accounts using outdated access keys. Additionally, it ensures that data cannot be accessed using an old key that may be lost, compromised, or stolen. Always remember to update your applications following the access key rotation.image

‍

Begin by listing all IAM users in your AWS account with:

<pre class="codeWrap"><code>aws iam list-users --query 'Users[*].UserName'</code></pre>

For each user returned in the previous step, assess the lifetime of their active access keys by using:

<pre class="codeWrap"><code>aws iam list-access-keys --user-name USER_NAME</code></pre>

‍

The output provides metadata for each access key, resembling the following:

<pre class="codeWrap"><code>{
   "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"
       }
   ]
}</code></pre>

Examine the CreateDate parameter for each active key to determine its creation time. If an active access key was created more than 90 days ago, it is outdated. To secure access to your AWS resources, rotate such keys. Repeat these steps for every IAM user in your AWS account.

4. Eliminate IAM Root User Access Keys

As emphasized in the initial setup, it is strongly advised to eliminate all access keys linked to the root user. This action reduces potential vulnerabilities that could compromise your account and promotes the establishment and utilization of role-based accounts with minimal privileges.

‍

The following Cloud Custodian rule verifies the usage of root access keys in your account:

<pre class="codeWrap"><code>- 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
</code></pre>

5. Activate Multi-factor authentication (MFA) for IAM Users with Console Passwords

MFA improved security by insisting on an additional verification step beyond a username and password. When a user logs in to an AWS website, they need to provide their username, password, and an authentication code from their AWS MFA device.

‍

In line with this, enabling MFA for all accounts with console passwords is a recommended practice. MFA strengthens security for console access, requiring the authenticating user to possess a device generating a time-sensitive key and knowledge of a credential. For an added layer of security, consider monitoring logins with MFA to identify suspicious activities.

6. Hardware MFA for the Root User

Hardware MFA devices offer a higher level of security compared to virtual MFA. They have a limited attack surface and cannot be compromised unless an unauthorized user gains physical access to the hardware device. While awaiting approval for hardware purchases or the arrival of physical devices, it is advisable to use a virtual MFA for root users.

For detailed instructions, refer to the IAM User Guide section on Enabling a Virtual Multi-Factor Authentication (MFA) Device.

‍

The following Cloud Custodian rule identifies instances where hardware MFA is not enabled for the root user:

<pre class="codeWrap"><code>- 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
</code></pre>

7. Establish Robust Password Policies for IAM Users

To enhance security, it is advisable to ensure that IAM user password are as strong as possible. Setting a password policy in your AWS account allows you to define complexity requirements and mandatory rotation periods for passwords. When you create or modify a password policy, most of the settings take effect the next time users update their passwords. Some settings are implemented immediately.

‍

Determining what qualifies as a strong password is subjective, but the following settings provide a solid foundation:

<pre class="codeWrap"><code>RequireUppercaseCharacters: true
RequireLowercaseCharacters: true
RequireSymbols: true
RequireNumbers: true
MinimumPasswordLength: 8
</code></pre>

8. Eliminate Unused IAM User Credentials

IAM users have various credentials like passwords or access keys to access AWS resources. It is recommended to remove or deactivate credentials that have been unused for 90 days or more. This practice reduces the risk of compromised or abandoned account credentials being exploited. The IAM console provides information to monitor accounts for outdated credentials. For instance, the "Access key age," "Password age," and "Last activity" columns display relevant data.

‍

If any of these values exceed 90 days, deactivate the credentials for those users. Credential reports are also useful for monitoring user accounts and identifying those with no activity for 90 or more days. You can download these reports in .csv format from the IAM console. For a more in-depth understanding, keep reading and move on to best practices for IAM.Amazon S3.