Amazon Web Services IAM (identity access management) is the core authentication and authorization mechanism for AWS resources. With IAM you can control user access levels for the resources in an AWS account. The sign-in mechanism provides authentication, and the IAM permissions attached to the identities manage authorization for the AWS console.
Several IAM best practices can help you mitigate common AWS security risks. For example, limiting the use of root accounts for routine work is an IAM best practice. When you create a new AWS account, the default identity, known as the root user, has full access to all the resources. The root user can create other IAM identities (users and roles) with restricted access to AWS resources.
You should only use root credentials to perform actions that can not be performed using other IAM identities. IAM users and roles created in an account can have permissions assigned to them based on their use cases. The permissions are assigned in JSON format, known as policies.
You can use the AWS Console’s visual editor to create and modify the IAM policies. These permissions define the access level of the identities and are evaluated by AWS when an identity requests a resource. Access to resources is either allowed or denied based on the permissions assigned to the IAM identity. It is an IAM best practice to follow the principle of least privilege for these access policies.
This article will explore these and other Amazon Web Services IAM best practices in detail.
Summary of IAM best practices
The following table briefly describes the Amazon Web Services IAM best practices we will explain each in greater detail later in the article.
IAM best practice | Descriptions |
---|---|
Use MFA as a second layer of authentication | Passwords can be leaked and misused. Adding an additional layer of authentication protects the account from unauthorized access. |
Follow the principle of least privilege | Insider threats can misuse their permissions or the user credentials can be leaked and misused by attackers. The principle of least privilege limits the damage that can occur in these cases. |
Rotate access keys periodically | Access keys provide similar access permissions to the console access. The access keys, if leaked while embedded (e.g., in source code), can be abused by attackers. Rotating access keys can limit the scope of keys in terms of duration. |
Disable not-in-use IAM users and Access keys | Having active not-in-use access keys can serve as an attack vector. Ideally, the access keys that are not in use should be disabled. Similarly, not-in-use IAM users can be misused and should be disabled. |
Use condition keys to restrict access further | Condition keys are attached with IAM policy statements to limit the scope of permission statements further. |
Use CloudTrail to help you create an initial IAM policy | CloudTrail lets you create a policy following the least privilege by analyzing the permissions of an IAM user over a time period and sharing them with you to decide the appropriate permissions. |
Use IAM access analyzer to identify public and cross-account access | IAM access analyzer analyzes resources to identify public or cross-account access. They can be utilized to identify any unauthorized access patterns. |
Use short-lived credentials instead of assigning permanent permissions | Use IAM role, SSO, etc., to set short-lived credentials for a task instead of directly assigning user permissions. |
IAM best practices
IAM serves as a security boundary for accessing AWS resources. IAM identities include IAM users and roles that can be used to access resources or perform tasks in an AWS account. IAM identities can be assigned permissions using inline policies or managed policies, assigned directly or by virtually dividing the identities into groups and permissions being assigned to groups.
IAM User accessing AWS resources
IAM supports role-based access control fundamentally. Access to AWS resources is managed using IAM. IAM provides access based on the identities and the permissions assigned to them. You can also manage access and permissions by defining groups based on the job responsibilities and assigning permissions to the groups instead of directly assigning them to IAM roles or users.
IAM – Security best practices
You should follow the IAM security best practices below to help prevent security breaches.
Limit root account use
You should only use root accounts for tasks that cannot be performed using IAM user credentials. You can find the list of these tasks in the AWS documentation here.
Like root account console access, root account access keys are highly privileged. Root account access keys should not be created for routine tasks. Always set up MFA (multi-factor authentication) for the root account to add an additional layer of authentication.
Also, set up alerts on the usage of the root account, considering it to be a red flag. The IAM dashboard displays a security alert if the root account MFA is not enabled, like in the screenshot below.
MFA alert on IAM dashboard
Configure multi-factor authentication for IAM users
MFA adds a layer of security to ensure only authorized individuals can authenticate. It is an effective mechanism to prevent credential misuse in case of credential leakage. You can use a virtual MFA device, hardware MFA device, or security key for MFA setup. The most commonly used is a virtual MFA device. Once you select the virtual MFA device on the setup, it asks you to scan the QR code in your virtual authenticator app and add codes for verification. You can find the detailed steps for enabling MFA devices in the AWS documentation.
Setup virtual MFA device
In addition to Amazon Web Services’ built-in MFA offerings, you may want to consider more advanced third-party integrations.
Use access key rotation
Access keys are often embedded in source codes by the developers and released to the public accidentally with the source code. AWS is making efforts to prevent the use of leaked keys, but it’s still a work in progress. It is, therefore, recommended to use IAM roles instead of access keys to prevent the accidental release of keys. If there is a need to use access keys, the following are the suggestions to avoid or mitigate security risks:
- Rotate access keys periodically
- Create separate IAM users with restricted IAM permissions to reduce the scope of keys in case of leakage
- Create separate keys for multiple tasks instead of one key with high privileges.
- Create separate IAM users for console and CLI access to reduce the risk of compromise
- Disable the keys that are not in use.
Define a password policy for console users
Having no password policy, or a weak password policy, can be a security risk. Weak passwords can be easily guessed using brute force. Therefore, you should enforce a strong password policy with a minimum of 12 characters.
Complex passwords can be auto-generated and stored in password managers for easier access, secure storage, and management. Also, password reuse should be disallowed to prevent setting the previous password and reduce the risk of credential compromise. To configure a password policy in the IAM console, go to account settings, and the option to configure password policies is displayed at the top of the page.
The default AWS password policy.
Edit the default password policy to set up a strong password policy for your account, following the guidelines mentioned above. You can learn more about this in the AWS Setting an account password policy for IAM users docs.
You should also disable the not-in-use IAM users to prevent the misuse of IAM credentials of those users.
Permissions policies
The following IAM best practices are essential for assigning permissions to IAM entities.
Follow the principle of least privilege
Edit the default password policy to set up a strong password policy for your account, following the guidelines mentioned above. You can learn more about this in the AWS Setting an account password policy for IAM users docs.
You should also disable unused IAM accounts to prevent misuse of those credentials.
Use AWS-managed policies and Customer managed policies instead of inline policies
Start by using AWS-managed policies for various tasks and move towards restricted permissions by limiting the scope of permissions (e.g., by specifying the resources for allowed actions). Then, define your own as custom policies as needed. Using inline policies with entities is discouraged because they are hard to audit and track. You can read more on policies in the AWS docs here.
Use condition keys to restrict permissions
When you use condition keys in your policy JSON, they are compared with the request context, and the requests are only allowed if the request context matches the condition keys specified in the policy JSON. There are global keys and service-specific keys that can be used with the policies.
Condition key used to restrict access (Source)
Use CloudTrail-based policies
Historically, you would grant access beyond what is required and review the cloud trail logs to examine the activity and gradually restrict the permissions of IAM users. Nowadays, IAM access analyzer does this for you by generating a policy template based on the cloud trail logs that can be modified to restrict access.
Use Access Analyzer to periodically review permissions
Accidental public or cross-account access to critical resources can result in the disclosure of confidential information. You can use Access Analyzer to periodically review the findings to identify the supported resources with public or cross-account access.
AWS IAM Recommendations and tips
The recommendations and tips below can help you hit the ground running with Amazon Web Services IAM best practices.
Centralize IAM management
Managing multiple accounts IAM users, roles, and permissions can be complex. A mechanism to centrally manage IAM permissions is essential for security. You can centralize the management of IAM for your multiple AWS accounts by using AWS Organizations.
AWS Organizations can help you centrally manage the accounts and consolidate their billing. You can divide the accounts into virtual units called Organizational Units (OUs) and use service control policies (SCPs) to manage the permissions in your Amazon Web Services accounts centrally. SCPs define the maximum set of permissions allowed to an Organizational Unit. You can read more about the topic in the AWS Organizations docs.
Use AWS IAM Identity Center for central management of human users
To further extend the capabilities of IAM, you can use IAM Identity Center. IAM Identity Center helps you manage access for your human identities directly or by externally authenticating with other identity providers. Human users can use their directory credentials to sign into the AWS access portal. After authenticating, users get to choose the AWS account they want to have federated access of. The user gets access to an AWS account based on the IAM role assigned and their associated permissions. You can also link IAM Identity Center with your AWS Organizations to help you manage the human identities for your Organization centrally. You can learn more in the AWS docs here.
IAM Identity Center (Single Sign-On) supports authenticating with external identity providers by exchanging temporary credentials with external Idp and managing access permissions by assigning IAM roles. You can read more on using external identity providers with IAM Identity Center in these AWS docs.
Conclusion
Amazon Web Services IAM manages the authentication and authorization of IAM entities and provides them access to AWS resources based on their roles. To ensure restricted access to AWS resources, follow the principle of least privilege when assigning IAM permissions. Centralize IAM across accounts by using AWS Organizations and discourage the use of root accounts.
Periodically audit the IAM resources to ensure they comply with the security best practices. You can also use Paladin Cloud’s Open Source Tool to to monitor your IAM configurations to ensure compliance to industry best practices such as enabling MFA for root users and rotating customer managed keys.