AWS Identitiy and Access Management

aws / cloud / amazon / security / iam
aws / cloud / amazon / security / iam

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

When an AWS account is first created a single sign in identity (called the AWS account root user) that has complete access to all AWS services and resources in the account is also created, this identity is accessed by signing in with the email address and password used to create the account. It is strongly recommended that this account is not used for everyday tasks, including administrative ones.

It is recommended to create individual users for anyone who needs access to the AWS account, this way each IAM user can be given a unique set of security credentials and also be granted unique set of permissions. If necessary IAM user permissions can be revoked or changed at any time, the root user’s permissions are difficult to revoke and impossible to restrict.

IAM is not region specific, so the Users, Groups, Roles and Permissions have effect globally, i.e on all AWS regions.

IAM provides the following

  • Centralised control of the AWS account
  • Shared access to the AWS account and its resources
  • Identity federation (including Active Directory, Facebook, L:inkedIn etc)
  • Multifactor Authentication
  • Granular permissions
  • Provide temporary access for users/devices and services where necessary
  • Ability to set up a custom password rotation policy
  • Integration with many different AWS services
  • PCI DSS compliance

Identities

IAM identities are created to provide authentication for people and processes in the AWS account, they represent the user, and can be authenticated and then authorized to perform actions in AWS.

Users

Users represents the person or service who uses the IAM user to interact with AWS. A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI. Users can be given two types of authentication methods:

  • Access key ID and Secret access key
    • These are used to access AWS resources programatically
  • Username and password
    • These are used by people to logon to the AWS console

Upon creation of users there is an option to select what type of authentication method above the user needs (including both types). If the user(s) need programatic access the access key ID and secret access key can only be downloaded once during creation, if they are lost they need to be recreated (meaning the old ones will no longer work)

IAM users can be granted permissions by assigning it to a group that has appropriuate permission policies attached (the recommended way) or by attaching policies directly to the user. The latter may be useful when there is a need to give some members of a group more privilege than the other members.

Root User

This is the identity created when you first creat an AWS account, it is the combination of the email address and password used to create the AWS account.It has complete, unrestricted access to all resources in the AWS account, including access to billing information and the ability to change the password. This level of access is necessary to initially set up the account. however, it is not recommended for everyday access - IAM users should be created instead.

Groups

An IAM group is a collection of IAM users. They can be used to specify permissions for a collection of users, which can make those permissions easier to manage for those users. For example you can have a group called Developers that groups the type of permissions that developers would need. Any user in that group automactially has the permissions that are assigned to that group.

If a new developr joins the organisation you can assign the appropriate permissions by adding the user to that group, and when a develper leaves the organisations you just need to remove the user from the group instead of having to edit the user’s individual permissions.

This concept can be seen in many Access Control Systems (like Active Directory groups, for example)

Roles

An IAM role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.

Roles are a secure way to grant permissions to entities that are trusted, example entities include:

  • IAM user in another account
  • Application code running on an EC2 instance that needs to perform actions on AWS resources
  • An AWS service that needs to act on resources in your account to provide its features
  • Users from a corporate directory who use identity federation with SAML

Policies

A policy is an entity in AWS that, when attached to an identity or resource, defines their permissions. AWS evaluates these policies when a principal, such as a user, makes a request. Permissions in the policies determine whether the request is allowed or denied. Policies are stored in AWS as JSON documents attached to principals defineing permissions. The policy document includes the following elements:

  • Effect – whether the policy allows or denies access
  • Action – the list of actions that are allowed or denied by the policy
  • Resource – the list of resources on which the actions can occur
  • Condition (Optional) – the circumstances under which the policy grants permission

Policies are of the following two types;

Identity Based Policies

These are policies that can be attached to an identity like an IAM user, role or group, they control what actions that identity can perform, on which resources and under what conditions.

Identity based policies can be managed (standalone that can be attached to multiple users, groups and roles) or inline (embedded directly into a single user, group or role). Managed polices can be managed by AWS (for customers who are getting started with policies) or by Customer (For custom more precise controls)

Example Identity Based Policy JSON document:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}

Resource Based Policies

These are policies that are attached to resources such as Amazon S3 bucket, they control what actions a specified principal can perform on that resource and under what conditions. Resource-based policies are inline policies, and there are no managed resource-based policies.

Example Resource Base Policy JSON document:

{
  "Version": "2012-10-17",
  "Id": "S3-Account-Permissions",
  "Statement": [{
    "Sid": "1",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }]
}

Best Practices

Below are the recommendations to help secure AWS resources in the account

Locking away AWS Account Root User Access Keys

An access key (an access key ID and secret access key) is to make programmatic requests to AWS. The access key for the AWS account gives full access to all resources for all AWS services, including billing information. The permissions associated with your AWS account access key cannot be restricted. So it is stronly recommended not to use the root user access key.

Creating Individual IAM users

The AWS account user credentials should not be used or shared, individual IAM users should be created instead.

Enabling MFA for privileged users

For extra security, multi-factor authentication (MFA) should be enabled for privileged IAM users (users who are allowed access to sensitive resources or APIs). With MFA, users have a device that generates a unique authentication code (a one-time password, or OTP). Users must provide both their normal credentials (like their user name and password) and the OTP. The MFA device can either be a special piece of hardware, or it can be a virtual device (for example, it can run in an app on a smartphone, like Google Authenticator).

Using 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.

Using AWS Defined Policies to Assign Permissions Whenever Possible

It is recommended that you use the managed policies that are created and maintained by AWS to grant permissions whenever possible. A key advantage of using these policies is that they are maintained and updated by AWS as new services or new APIs are introduced.

Granting Least Privilege

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.

Configuring a Strong Password Policy for Your Users

If users are allowed to change their own passwords, require that they create strong passwords and that they rotate their passwords periodically.

Using 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.

Delegating by Using Roles Instead of by Sharing Credentials

You might need to allow users from another AWS account to access resources in your AWS account. If so, don’t share security credentials, such as access keys, between accounts. Instead, use IAM roles.

Rotating 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 password policy to your account to require all your IAM users to rotate their passwords, and you can choose how often they must do so.

Removing Unnecessary Credentials

Remove IAM user credentials (that is, passwords and access keys) that are not needed.

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.

 
comments powered by Disqus