5 Advanced IAM Best Practices

IAM Best Practices Overview

Amazon Web Services (AWS) Identity and Access Management (IAM) features include groups, users, IAM policies, IAM roles, and identity federation to help run your cloud architecture in a secure manner. In this article, we’ll delve into five IAM advanced best practices that can significantly boost cloud security.

1. Enable multi-factor authentication (MFA) for privileged users

Strong passwords are a must for securing enterprise data and networks, but that is not enough. Most breaches occur due to compromised authentication. Security experts highly recommend multi-factor authentication. It mandates any two of the three factors mentioned below before access is granted to any system:

1. Something you know: such as a password
2. Something you possess: such as a hardware token or one-time password (OTP) on mobile device
3. Something you are: such as a retina scan or fingerprint

Adhering to best practices, AWS has mandated multi-factor authentication for all privileged IAM users. These are users who have access to APIs or other sensitive resources. AWS provides a couple of options to its users to enable the second level of authentication:

• Security token-based authentication: A six-digit numerical value is generated based on a password-generation algorithm. This value has to be keyed in by the user on the second web page presented to while logging in. A security token can either be a hardware or virtual device, which is assigned to the IAM user or AWS root account user. A virtual device can be a software program running on a mobile device. But security that comes with a hardware device is incomparable to software installed on a mobile device. Each of these devices are unique, and numerical values generated by them cannot be shared among users.
• SMS authentication: The overall process remains the same as explained in ‘security token-based authentication’ but instead of a hardware or virtual device, a one time password (OTP) with six digit numeric value is sent to the user’s mobile device. Note that the SMS based method of authentication cannot be used with AWS account root user.

2. Use Policy Conditions for Extra Security

Policies are a set of JSON statements which provide certain permissions to users. To add more security, AWS has added an optional component called ‘Conditions’ to policies. Condition block always returns a boolean output : ‘true’ or ‘false’, which decides whether a policy grants or denies the request.

For example, one can write a condition that all requests coming from a particular subnet should not be allowed access to any resource. Or subnet X.X.X.X should be allowed access only for next week. Let’s see the basic condition block. Here, condition operator – “DateLessThan” specifies that access to a particular resource is up to 2017-10-15 and key – “aws:CurrentTime” is compared to the value which determines the permissions.

“Condition”: {
“DateLessThan” : {
“aws:CurrentTime” : “2017-10-15T12:00:00Z”
}
}

A condition block can further contain multiple conditions (Condition 1 and Condition 2 in diagram below) which will be assessed by a logical AND. Also, multiple keys within one condition uses a logical AND and if a key contains multiple values, a logical OR operator is used for evaluation.

Figure 1: Condition Block

AWS provides a long list of conditional operators needed for various comparisons. These operators can be grouped as:

• String
• Numeric
• Date and time
• Boolean
• Binary
• IP address
• Amazon Resource Name (ARN) (not for all services)
• …IfExists
• Null check

Though all of these operators have their own significance, we will explain the ‘Null’ conditional operator with an example. Null operator is used to check if a particular key is present. ‘True’ implies that key is not present while ‘false’ points that key is present. In the below example, key is “aws:TokenIssueTime” and as per the logic, access to EC2 resource is denied in case the user is using temporary credentials.

{
“Version”: “2015-12-20”,
“Statement”:{
“Action”:”EC2:*”,
“Effect”:”Deny”,
“Resource”:”*”,
“Condition”:{“Null”:{“aws:TokenIssueTime”:”false”}}
}
}

3. Remove Unnecessary Credentials

It is always a good security practice to regularly audit user credentials and remove them in case they are not in use. AWS provides an out-of-the-box ‘credential report’ which helps you track the lifecycle of passwords and access keys. The report includes user details, date created, when the password was last used, and when the password was last changed. Also, if you have set the password rotation policy, this report mentions the date and time at which the user is supposed to change the password.

For access keys, reports highlight whether a user has an access key and if it is active or not; date and time when the key was rotated or created, when the access key was used for the last time, AWS region where the key was used for the last time, and the AWS service (Amazon S3, EC2) where the key was used.

These details are quite useful for internal and external audits. With AWS, you can grant a role to an auditor so he/she can directly download the credential report on a requirement basis.

Credential reports can be generated every four hours. If you try to generate a new report within four hours, the last-generated report will be shared with the user. AWS IAM internally checks when the last report was generated and takes a decision whether to generate a new one or not.

There are multiple ways to generate a credential report (as mentioned below) but the simplest one is to log into the AWS management console → open the IAM console → click “credential report” in the navigation panel → click “download report” (a comma-separated values file is available for your reference).

1. AWS management console
2. AWS CLI
3. Tools for AWS powershell
4. IAM API

4. Use AWS-Defined Policies to Assign Permissions Whenever Possible

If you’re new to AWS world and struggling to create and maintain your own policies for different job functions, consider starting with out-of-the-box AWS-defined policies whenever possible. These policies are well-aligned to common information technology functions ranging from the finance guy responsible for billing to the data scientist executing hadoop queries, or the network administrator who sets up, configures and maintains databases in the AWS cloud. For example, ‘Network Administrator’ policy grants access to setup and maintain network for Amazon EC2, Amazon Route 53, Amazon Virtual Private Cloud (VPC), and AWS Direct Connect.

A major benefit of using these policies is the auto-update functionality AWS provides. As these policies are updated whenever a new AWS service or API is introduced. This saves lot of time and makes life easier. For example, AWS manages a policy called ‘ReadOnlyAccess’ which provides read access to all AWS services and resources. Let’s say a new service is launched by AWS. AWS will make sure that ‘ReadOnlyAccess’ policy is updated with this newly launched service. Also, this change will be applied to all the entities (group, user, or role) wherever ReadOnlyAccess policy is already attached.

AWS defined policies cannot be modified by end users; those rights rest solely with Amazon. One can make a copy of AWS policy and make required customizations but that copy will not be an AWS policy and hence will not be updated by AWS with new services or APIs.

The diagram below demonstrates how an AWS managed policy can be applied to multiple accounts – AWS Account1 and AWS Account2 respectively – and to different roles in the same account: Role EC2-app and Role ThirdPartyAccess in AWS Account1. Here, AWS policies under consideration are AdministratorAccess, PowerUserAccess and AWSCloudTrailReadOnlyAccess.

Figure 2: AWS Managed Policy

5. Use Groups to Assign Permissions to IAM Users

It is always easier to create groups and assign permissions to them than to define permissions for individual users. Using Figure 2 above, policy ‘AdministratorAccess’ is assigned to group ‘Admins’ and the same access percolates to User ‘Alice’ and ‘Susan’ on its own. This way, one can create multiple groups related to various job functions (Administrator, Security Auditor etc.) and assign relevant permissions to each group before tagging users to those groups.

This methodology for managing permissions is not only easier. It is more secure and manageable, too. For example, whenever there are inter-departmental moves, one simply needs to place the individual in another group rather than redefining the whole set of permissions.

The Importance of Following IAM Best Practices

AWS is a vast and complex system, but it provides a free service in the form of Identity and Access Management, the first step towards securing your cloud resources. By following IAM best practices such as multi-factor authentication and removing unused credentials with timely audits, the chances of a security breach can be greatly reduced.

If you want to save the time and energy needed to define your own policies, AWS-defined policies are the best place to start. These policies are well-aligned to common IT job functions. These IAM best practices can help to easily manage AWS users, groups, roles and permissions and improve the security of your AWS resources.

Ready to Implement IAM Best Practices?

Schedule a demo to learn how CloudCheckr can help you implement IAM best practices and meet other benchmarks for security, compliance, and more.