AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.

IAM is universal, not regional. All accounts start with a root account, it has complete Admin access. New users created by default have no permissions and are assigned access key and secret key when first created. You will need to create a password (following the password policy, which can be customized) in order for that user to access the AWS console.

When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user.

Resources

The user, group, role, policy, and identity provider objects that are stored in IAM. As with other AWS services, you can add, edit, and remove resources from IAM.

Identities

The IAM resource objects that are used to identify and group. You can attach a policy to an IAM identity. These include users, groups, and roles.

Entities

The IAM resource objects that AWS uses for authentication. These include users and roles. Roles can be assumed by IAM users and roles in your or another account. They can also be assumed by users federated through a web identity or SAML.

Principals

A person or application that uses the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS.

 

IAM provides the following:

• Centralized control of AWS account
• Shared Access to your AWS acocunt
• Granular permissions
• Identity Federation (Active Directory, Facebook, etc)
• Multifactor Authentication
• Provide temporary access for users/devices and services where necessary
• Allows you to setup own password rotation policies
• Integrates with many different AWS services
• Supports PCI DSS Compliance

 

IAM is broken down into 4 main concepts:

1. Users – people who have access to AWS services
2. Groups – one or more person grouped with shared roles
3. Roles – the actual permission that is granted
4. Policies – definition of the permissions (there are many out-of-box policies provided by AWS as shown below)
   1. Policies are global
   2. In JSON format

 

Users

An AWS Identity and Access Management (IAM) user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials.

An IAM user with administrator permissions is not the same thing as the AWS account root user. For more information about the root user, see The AWS Account Root User. 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. Each IAM user is associated with one and only one AWS account. Because users are defined within your AWS account, they don’t need to have a payment method on file with AWS.

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.

You can access AWS in different ways depending on the user credentials:

Users may be in one or many groups. Group policies are defined (by an admin usually) on what those groups have permissions to. For example, there might be some AWS service that groups have permissions to. Lets assume those are read and write permissions, which are then two separate roles. The definition of those roles (that it can read or write) is defined by the policy which is managed by an administrator.

 

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.

Following are some important characteristics of groups:

 

Roles

An IAM identity that you can create in your account that has specific permissions. An IAM role has some similarities to an IAM user. Roles and users are both AWS identities with permissions 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.

Roles can be used by the following:

 

Policies

Policies are what defines the effect, actions, resources and optional conditions for user access in AWS. IAM policies are independed of region, so no region is specified in the policy. IAM policies are about authorization for an already-authenticated principal so no password info is included.

IAM policies are JSON files that track the version and statement. The statement defines what is allowed or not allowed. It is based on Actions and Resources (action-statements and resource-statements):

{
 "Version": "2017-12-01",
 "Statement": [
  {
   "Effect":"Allow",
   "Action": "*",
   "Resource": "*"
  }
 ]
}

Actions or resources that are not explicitly allowed are denied by default. The IAM console includes policy summary tables that describe the access level, resources, and conditions that are allowed or denied for each service in a policy. Policies are summarized in three tables: the policy summary, the service summary, and the action summary. The policy summary table includes a list of services. Choose a service there to see the service summary. This summary table includes a list of the actions and associated permissions for the chosen service. You can choose an action from that table to view the action summary. This table includes a list of resources and conditions for the chosen action.

Remember to always use strong and unique passwords, multi-factor authentication, Principle of Least Privileges and limit access to the root account. Note that AWS supports Federation and users maybe authenticated by third-party providers such as corporate Active Directory or internet providers such as Google, Amazon or Facebook.

 

STS

The AWS Security Token Service (STS) is a global web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users).

You can use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources. Temporary security credentials work almost identically to the long-term access key credentials that your IAM users can use, with the following differences:

These differences lead to the following advantages for using temporary credentials:

Temporary credentials are useful in scenarios that involve identity federation, delegation, cross-account access, and IAM roles. Note that EC2 roles are using temporary tokens when accessing resources.

• Federation: combining or joining a list of users in one domain (such as IAM) with a list of users in another domain (such as AD)
• Identity Broker: service that allows you to take an identity from point A and join it (federate it) to point B
• Identity Store: services like AD, Facebook, etc
• Identities: actual user

The Identity Broker authenticates the incoming user against the Identity Store (LDAP Directory shown above), then lets them pass into the STS service.

STS Token Service provides the following:

1. Access Key
2. Secret Access Key
3. Token
4. Duration

Identity Broker will pass this back to the user, which then the user uses to access whatever resource they need (in example above S3). S3 would verify the incoming token against IAM.

As an alternative to using the API, you can use one of the AWS SDKs, which consist of libraries and sample code for various programming languages and platforms (Java, Ruby, .NET, iOS, Android, etc.). The SDKs provide a convenient way to create programmatic access to STS.

Setting up STS

In setting up STS in AWS, there are 3 steps to follow:

1. Develop an Identity Broker to communicate with LDAP and AWS STS
2. Identity Broker always authenticates with LDAP first, then with AWS STS
3. Application then gets temporary access to AWS resources

Active Directory Integration

Below is a popular use case where users of an organization are leveraging their organization’s AD to sign on into AWS. This is using SAML based AuthN.

 

Access Analyzer

AWS IAM Access Analyzer helps you identify the resources in your account, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. This lets you identify unintended access to your resources and data, which is a security risk. An external entity can be another AWS account, a root user, an IAM user or role, a federated user, an AWS service, an anonymous user, or other entity that you can use to create a filter.

When you enable Access Analyzer, you create an analyzer for your account. Your account is the zone of trust for the analyzer. The analyzer monitors all of the supported resources within your zone of trust. Any access to resources by principals that are within your zone of trust is considered trusted. Once enabled, Access Analyzer analyzes the policies applied to all of the supported resources in your account. After the first analysis, Access Analyzer analyzes these policies periodically. If a new policy is added, or an existing policy is changed, Access Analyzer analyzes the new or updated policy within about 30 minutes.

 

Security

IAM falls under the security umbrella and there are some best practices to remember when working with security. Things such as following Least Privilege principle and remembering to adhere to AWS’s Shared Responsibility Model.

Shared Responsibility Model

 

Encryption

When accessing resources in AWS, there are a few different ways to enable encryption at transit or rest.

• Server Side Encryption (SSE)
  • Amazon S3-Managed Keys (SSE-S3) for S3 encryption
  • KMS-Manaaged Keys (SSE-KMS) for using the AWS Key Management Service
  • Customer-Provided Keys (SSE-C) for BYOK
• Client Side Encryption (CSE)
  • KMS managed master encryption keys (CSE-KMS)
  • Customer managed master encryption keys (CSE-C)

For key storage, the following services are available

• Key Management Service (KMS)
  • Supports customer software-based key managed
  • Integrates with many AWS services
  • Can be used directly from applications
• AWS CloudHSM
  • Hardware-based key management
  • Use directly from applications
  • FIPS 140-2 Compliance

 

References

AWS User Guide
https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html