AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

There three types of entities in IAM, Users, Groups and Roles, and you grant granular access to the AWS resources using IAM Permissions using policies

Users and permissions

By default, a brand new IAM user has no permissions to do anything. The user is not authorized to perform any AWS operations or to access any AWS resources. An advantage of having individual IAM users is that you can assign permissions individually to each user. You might assign administrative permissions to a few users, who then can administer your AWS resources and can even create and manage other IAM users. In most cases, however, you want to limit a user's permissions to just the tasks (AWS actions or operations) and resources that are needed for the job.

Users as service accounts

An IAM user is a resource in IAM that has associated credentials and permissions. An IAM user can represent a person or an application that uses its credentials to make AWS requests. This is typically referred to as a service account. If you choose to use the long-term credentials of an IAM user in your application, do not embed access keys directly into your application code. The AWS SDKs and the AWS Command Line Interface allow you to put access keys in known locations so that you do not have to keep them in code.

Accessing IAM

You can work with AWS Identity and Access Management in any of the following ways.

  • AWS Management Console
  • AWS Command Line Tools
  • AWS SDKs
  • IAM HTTPS API

IAM Permissions

Permissions let you specify access to AWS resources. Permissions are granted to IAM entities (users, groups, and roles) and by default these entities start with no permissions. In other words, IAM entities can do nothing in AWS until you grant them your desired permissions. To give entities permissions, you can attach a policy that specifies the type of access, the actions that can be performed, and the resources on which the actions can be performed. In addition, you can specify any conditions that must be set for access to be allowed or denied.


To assign permissions to a user, group, role, or resource, you create a policy that lets you specify:

  • Actions – Which AWS service actions you allow. For example, you might allow a user to call the Amazon S3 ListBucket action. Any actions that you don't explicitly allow are denied.
  • Resources – Which AWS resources you allow the action on. For example, what Amazon S3 buckets will you allow the user to perform the ListBucket action on? Users cannot access any resources that you do not explicitly grant permissions to.
  • Effect – Whether to allow or deny access. Because access is denied by default, you typically write policies where the effect is to allow.
  • Conditions – Which conditions must be present for the policy to take effect. For example, you might allow access only to the specific S3 buckets if the user is connecting from a specific IP range or has used multi-factor authentication at login.

There are more elements, for more information you can see the reference here

By default, all requests are implicitly denied. (Alternatively, by default, the AWS account root user has full access.)

This is an example of a policy for a user that only need to access to start and stop an instance Id

{
	"Statement":
	{
		"Effect": "Allow",
		"Action": [
			"ec2:Describe",
			"ec2:StartInstances",
			"ec2:StopInstances"
		],
		"Resource": "(instance ARN)"
		//"Resource": "arn:aws:region:account-id:instance/instance-id"
	}
}

AWS IAM Cross-Account

You can grant your IAM users permission to switch to roles within your AWS account or to roles defined in other AWS accounts that you own.

When you create a role for this purpose, you specify the accounts by ID whose users need access in the Principal element of the role's trust policy. You can then grant specific users in those other accounts permissions to switch to the role.

This is an example of a policy for cross-account, for an S3 bucket

{
	"Version": "2012-10-17",
	"Statement": [
		"Sid": "111",
		"Effect": "Allow",
		"Principal": {
			"AWS": "arn:aws:iam::(account no):root"
		},
		"Action": "S3:*",
		"Resource": [
			"arn:aws:s3:::examplebucket/",
			  "arn:aws:s3:::examplebucket/*"
		]
	]
}

Policies on AWS Resources

There are AWS Resources like S3, Endpoints that can use a policy for example in this policy attached to a S3 can deny any access if the IP Address of the source is not 54.240.143.0/24

{
	"Version": "2012-10-17",
	"id": "S3PolicyId1",
	"Statement": [
		"Sid": "IPAllow",
		"Effect": "Allow",
		"Principal": "*",
		"Action": "S3:*",
		"Resource": "arn:aws:s3:::examplebucket/",
		"Resource": "arn:aws:s3:::examplebucket/*"
"Condition": {
			"IpAddress": {"aws:SourceIp": "54.240.143.0/24"}
		}
	]
}

This is called a bucket policy.

IAM groups

An IAM group is a collection of IAM users. Groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users. For example, you could have a group called Admins and give that group the types of permissions that administrators typically need. Any user in that group automatically has the permissions that are assigned to the group. If a new user joins your organization and needs administrator privileges, you can assign the appropriate permissions by adding the user to that group. Similarly, if a person changes jobs in your organization, instead of editing that user's permissions, you can remove him or her from the old groups and add him or her to the appropriate new groups.

IAM roles

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

IAM Security Best Practices

  • Lock away your AWS account root user access keys

You use an access key (an access key ID and secret access key) to make programmatic requests to AWS. However, do not use your AWS account root user access key. The access key for your AWS account root user gives full access to all your resources for all AWS services, including your billing information. You cannot reduce the permissions associated with your AWS account root user access key.

Therefore, protect your root user access key like you would your credit card numbers or any other sensitive secret.

  • Create individual IAM users

Don't use your AWS account root user credentials to access AWS, and don't give your credentials to anyone else. Instead, create individual users for anyone who needs access to your AWS account. Create an IAM user for yourself as well, give that user administrative permissions, and use that IAM user for all your work.

  • Use groups to assign permissions to IAM users

Instead of defining permissions for individual IAM users, it's usually more convenient to create groups that relate to job functions (administrators, developers, accounting, etc.). Next, define the relevant permissions for each group. Finally, assign IAM users to those groups. All the users in an IAM group inherit the permissions assigned to the group. That way, you can make changes for everyone in a group in just one place. As people move around in your company, you can simply change what IAM group their IAM user belongs to.

  • Grant least privilege

When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.

Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.

  • Get started using permissions with AWS managed policies

Providing your employees with only the permissions they need requires time and detailed knowledge of IAM policies. Employees need time to learn which AWS services they want or need to use. Administrators need time to learn about and test IAM.

To get started quickly, you can use AWS managed policies to give your employees the permissions they need to get started. These policies are already available in your account and are maintained and updated by AWS. For more information about AWS managed policies

  • Use customer managed policies instead of inline policies

For custom policies, AWS recommend that you use managed policies instead of inline policies. A key advantage of using these policies is that you can view all of your managed policies in one place in the console. You can also view this information with a single AWS CLI or AWS API operation. Inline policies are policies that exist only on an IAM identity (user, group, or role). Managed policies are separate IAM resources that you can attach to multiple identities.

  • Use access levels to review IAM permissions

To improve the security of your AWS account, you should regularly review and monitor each of your IAM policies. Make sure that your policies grant the least privilege that is needed to perform only the necessary actions.

When you review a policy, you can view the policy summary that includes a summary of the access level for each service within that policy. AWS categorizes each service action into one of five access levels based on what each action does: List, Read, Write, Permissions management, or Tagging. You can use these access levels to determine which actions to include in your policies.

  • Configure a strong password policy for your users

If you allow users to change their own passwords, create a custom password policy that requires them to create strong passwords and rotate their passwords periodically. On the Account Settings page of the IAM console, you can create a custom password policy for your account. You upgrade from the AWS default password policy to define password requirements, such as minimum length, whether it requires non alphabetic characters, and how frequently it must be rotated.

  • Enable MFA

For extra security, we recommend that you require multi-factor authentication (MFA) for all users in your account. With MFA, users have a device that generates a response to an authentication challenge. Both the user's credentials and the device-generated response are required to complete the sign-in process. If a user's password or access keys are compromised, your account resources are still secure because of the additional authentication requirement.

The response is generated in one of the following ways:

  • Virtual and hardware MFA devices generate a code that you view on the app or device and then enter on the sign-in screen.
  • U2F security keys generate a response when you tap the device. The user does not manually enter a code on the sign-in screen.

  • Use roles for applications that run on Amazon EC2 instances

Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions, but that isn't a user or group. Roles also don't have their own permanent set of credentials the way IAM users do. In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated for you.

When you launch an EC2 instance, you can specify a role for the instance as a launch parameter. Applications that run on the EC2 instance can use the role's credentials when they access AWS resources. The role's permissions determine what the application is allowed to do.

  • Use roles to delegate permissions

Don't share security credentials between accounts to allow users from another AWS account to access resources in your AWS account. Instead, use IAM roles. You can define a role that specifies what permissions the IAM users in the other account are allowed. You can also designate which AWS accounts have the IAM users that are allowed to assume the role. To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles

  • Do not share access keys

Access keys provide programmatic access to AWS. Do not embed access keys within unencrypted code or share these security credentials between users in your AWS account. For applications that need access to AWS, configure the program to retrieve temporary security credentials using an IAM role. To allow your users individual programmatic access, create an IAM user with personal access keys.

  • Rotate credentials regularly

Change your own passwords and access keys regularly, and make sure that all IAM users in your account do as well. That way, if a password or access key is compromised without your knowledge, you limit how long the credentials can be used to access your resources. You can apply a custom password policy to your account to require all your IAM users to rotate their AWS Management Console passwords. You can also choose how often they must do so.

  • Remove unnecessary credentials

Remove IAM user credentials (passwords and access keys) that are not needed. For example, if you created an IAM user for an application that does not use the console, then the IAM user does not need a password. Similarly, if a user only uses the console, remove their access keys. Passwords and access keys that have not been used recently might be good candidates for removal. You can find unused passwords or access keys using the console, using the CLI or API, or by downloading the credentials report.

  • Use policy conditions for extra security

To the extent that it's practical, define the conditions under which your IAM policies allow access to a resource. For example, you can write conditions to specify a range of allowable IP addresses that a request must come from. You can also specify that a request is allowed only within a specified date range or time range. You can also set conditions that require the use of SSL or MFA (multi-factor authentication). For example, you can require that a user has authenticated with an MFA device in order to be allowed to terminate an Amazon EC2 instance.

  • Monitor activity in your AWS account

You can use logging features in AWS to determine the actions users have taken in your account and the resources that were used. The log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.

Logging features available in the following AWS services:

Amazon CloudFront, AWS CloudTrail, Amazon CloudWatch, AWS Config, Amazon Simple Storage Service (Amazon S3)

Resources