AWS Identity and Access Management Best Practices

In this post we explore AWS IAM best practices. Before we get to that, let me first explain what AWS IAM is. IAM, or Identity and Access Management, is a global AWS service that controls both user and programmatic access to AWS resources. Correct use of AWS IAM is essential to ensure the security and integrity of data and workloads hosted in the AWS cloud.

Within AWS IAM you can create and manage users and groups, and use policies and permissions to control their access to AWS resources. IAM is a core service offered by AWS at no charge and it’s global—meaning users and groups are available in all AWS regions.

16 AWS IAM Best Practices

By following AWS recommended IAM best practices, you will be setting a solid security baseline for your AWS accounts. It is important to only grant the level of access required to an individual user or service, by ensuring that users are appropriately grouped together and the right access policies are assigned to those groups. Here we list our top AWS IAM best practices to help you keep your AWS accounts secure.

1. Securely Store AWS Account Root User Keys

When an IAM user is created in AWS, you have the option of creating an access key consisting of an Access Key ID and Secret Access Key to enable programmatic access to AWS. The Access Key for the Root user of your AWS account should never be used, as it grants full access to all AWS resources (including billing data). It’s also not possible to reduce the permissions associated with the Root user.

Best practice dictates that you should not actually create an Access Key for your Root user. However, if you have created one, there are a few things you can do to protect it:

• Delete it! You don’t need it. If you really want to keep it, be sure to rotate it regularly in ‘My Security Credentials’
• Use a strong password to protect your Root Account (see point #7 in this post)
• Enable MFA on your Root Account (see point #8 in this post)
• Never share Root Account credentials with anyone else

2. Create Individual IAM Users

Root Account credentials should never be used to access AWS. You should first create an individual user account for yourself with administrative permissions, then log in with your individual user credentials and create additional users for anyone else in your company that requires access to your AWS accounts.

Creating individual IAM user accounts enables you to grant different permissions to different users. It also makes it easier to revoke permissions should you need to. When granting permissions to IAM users, best practice dictates that you should use groups.

3. Assign Permissions to IAM Users With Groups

Rather than managing individual permissions across large numbers of users, it is easier to assign permissions to groups that relate to job roles e.g. admins, developers, finance, etc. Once you have created your groups, you can assign permissions to those groups and then add users to the groups. Changing permissions for a particular job role is much easier this way—you can simply update the permissions for the group and they will be applied to all users in that group.

4. Adopt the Principle of ‘Least Privilege’

The principle of ‘least privilege’ dictates that you should only grant the permissions required for users or roles to perform a specific task. You need to figure out what a specific user or group needs to do, then either select an AWS-managed policy or design your own policy that enables them to do only that task. For example, a finance user may only need to be able to access the billing dashboard—you probably don’t want them to have full console access.

It’s best to start with what you deem to be the bare minimum, and then slowly add permissions if the users are unable to perform the required tasks. This way you avoid creating policies that are too lenient, which creates unnecessary risk.

5. Use AWS Managed Policies to Grant Permissions

Manually creating access policies for your users can be time-consuming. It can also be difficult to know what level of access your users will require until they are actually using AWS services.

AWS provides a set of Managed Policies that are regularly maintained by AWS and are available to all AWS customers. AWS Managed Policies provide permissions for common use cases. One example is the ‘Administrator Access’ policy, which can be used to create your first admin user. There are hundreds of Managed Policies for you to choose from to grant access to a whole range of AWS services. And you can of course modify the Managed Policies to suit your own specific requirements.

6. Use Customer Managed Policies Rather Than Inline Policies

AWS recommends the use of Managed Policies when creating custom policies. One reason for this is that it’s easy to view all Managed Policies in one place in the AWS console.  

A Managed Policy is an individual entity that can be attached to other users, groups, or roles. Managed Policies are therefore reusable.

By contrast, an Inline Policy only exists for a single user, group or role. Inline policies are useful if you want a strict one-to-one relationship between a specific policy and a specific identity. Inline policies can be converted into Managed Policies if required to make them easier to manage.

7. Regularly Review IAM Permissions

It is important to regularly review your IAM policies to ensure that they continue to adhere to the principle of least privilege.  

AWS categorizes service actions into one of these five access levels, based on what the service action does:

• List
• Read
• Write
• Permissions management
• Tagging

Access levels can be found in the policy summary on the ‘Policies’ page for managed policies, or on the ‘Users’ page for policies attached to a user.

8. Enable and Configure a Strong User Password Policy

If you allow your users to change their own passwords, then you should enforce a complex password policy and regular password rotation. Password policies can be created on the ‘Account Settings’ page of the IAM console. The password policy dictates password length, what characters should be included as well as the required frequency of password rotation.

9. Enable and Enforce Multi-Factor Authentication

Multi-factor authentication requires users to enter both their password as well as a response to an authentication challenge in order to log in. This could be a simple virtual MFA device, such as a smartphone app (Google or Microsoft Authenticator), or it could be a hardware device, such as an RSA key or U2F security key.

Administrators can enable MFA for IAM users, but enforcing MFA login must be achieved using a custom policy.

10. Use IAM Roles for EC2 Hosted Apps

In order for applications running on EC2 instances to access other AWS services, the EC2 instance needs credentials. For example, the application hosted on the EC2 instance may need access to a database hosted on an RDS instance, or objects stored in S3. The recommended and most secure way to give credentials to an EC2 instance is by creating an IAM Role.

An IAM role is an entity with its own set of permissions, but it is different to an IAM user or group. With IAM roles, credentials are regularly and automatically rotated by AWS.

IAM Roles can be specified in the launch parameters of an EC2 instance.

Further Reading: AWS EC2 – Everything You Need to Know About EC2 Instances

11. Delegate Permissions Using IAM Roles

If you need users in one AWS account to access resources in another AWS account, this should be done using IAM roles. You should not share security credentials between AWS accounts. An IAM role can specify the permissions to be granted to the users in the other account, along with which users are able to assume the role.

A quick note on IAM role vs user, as it’s been known to cause some confusion. An IAM role is an ‘identity’ within your AWS account. While similar to an IAM user, it is not associated with a specific person.

12. Do Not Share Access Keys

Access keys should not be shared between users in an AWS account, nor embedded in un-encrypted application code. If you have an application that needs AWS access, this should be granted using an IAM role. If individual users require programmatic access to AWS, they should have their own individual access keys.

13. Regularly Rotate Credentials

Passwords and access keys should be changed regularly by all AWS users. By doing so you limit the length of time compromised credentials can be used to access your AWS account. You can enforce the rotation of credentials using a password policy.

14. Delete Unused or Unnecessary IAM Credentials

Passwords and access keys that are no longer required should be removed e.g. when a user leaves your organization. Similarly, if a user has programmatic access keys but only ever uses the console, the access keys should be deleted.

You can easily tell when credentials were last used by downloading the ‘Credentials Report’.

15. For Extra Security, Use Policy Conditions

It is possible to define optional ‘conditions’ under which a policy grants access to your AWS resources. For example, you may wish to define a set of IP addresses that you will accept requests from, or perhaps you wish to only accept requests at certain times of the day. You may wish to restrict access to users who have authenticated using MFA.

This is achieved by building expressions with ‘condition operators’ (less than, equal, etc.) to match condition keys in the policy against values in the request context.

16. Use Logging to Monitor Account Activity

AWS offers a number of logging features designed to keep track of actions taken by users in your account and the resources that they used. Log files show the details of what actions were taken by whom, on what date and time, actions that failed due to lack of permissions, and so on.

Logging features are available in:

• CloudTrail: logs all API calls made by an AWS account, whether by a user or programmatically
• CloudWatch: monitors your AWS resources and applications and can generate alarms based on conditions you define
• CloudFront: the AWS Content Delivery Network (CDN) logs user requests received
• Config: provides a detailed history of the configuration of your AWS account at a particular point in time  
• S3: access requests to S3 buckets are logged

Staying On Top of IAM Best Practices

There’s a lot to think about in this post, right? It may even sound pretty daunting to some. But fear not, there are a number of tools to help you keep on top of your IAM configurations and ensure that you are adhering to the best practices laid out above.

AWS has a number of tools (listed under point #16) that can be used to both record IAM configurations and also alert you to changes in your IAM configuration.

CloudTrail and CloudWatch can be configured to send an alert via SNS (Simple Notification Service) when your IAM configuration changes.

AWS Config Rules can be configured to check the policies in use by your users.

Third party tools such as CloudCheckr and CloudHealth regularly monitor your AWS configuration and alert you to changes or policy breaches.

Alternatively, you could opt to enlist the services of an AWS Managed Services provider like Logicata. Our team of qualified experts will work with you to ensure you stay on top of AWS Identity and Access Management (IAM) best practices at all times. If you’re not convinced that you need a public cloud managed serviced provider, get in touch and we’ll talk through any questions or concerns you may have.