Identity Access Management (IAM) is the most widely used AWS service. Amazon Web Services (AWS) offers high level data protection when compared to an on-premises environment, at a lower cost. It enables secure control access to AWS resources and services for the customers. Customers can create and manage AWS users as well as groups, and provides necessary permissions to allow or deny access to AWS resources. In a simple term IAM provides an infrastructure necessary to control authentication and authorization for its customers account.

Resource policies allow customers to granularly control who is able to access a specific resource and how they are able to use it across the entire cloud environment. With one click in the IAM console, customers can enable IAM Access Analyzer across their account to continuously analyze permissions granted using policies associated with their Amazon S3 buckets, AWS KMS keys, Amazon SQS queues, AWS IAM roles, and AWS Lambda functions.

IAM Access Analyzer continuously monitors policies for changes, meaning AWS customers no longer need to rely on intermittent manual checks in order to catch issues as policies are added or updated. Using IAM Access Analyzer, they can proactively address any resource policies that violate their security and governance best practices around resource sharing and protect their resources from unintended access. IAM Access Analyzer delivers comprehensive, detailed findings through the AWS IAM, Amazon S3, and AWS Security Hub consoles and also through its APIs. Findings can also be exported as a report for auditing purposes. IAM Access Analyzer findings provide definitive answers of who has public and cross-account access to AWS resources from outside an account.

AWS Identity Access Management Capabilities

AWS Identity and Access Management (IAM) enables customers to securely control access to AWS services and resources for their users.

Using IAM, customers can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

 IAM makes it easy to provide multiple users secure access to AWS resources.

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. Tags can be attached to IAM principals (users or roles) and to AWS resources. You can create a single ABAC policy or small set of policies for your IAM principals. These ABAC policies can be designed to allow operations when the principal’s tag matches the resource tag. ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome.

For example, you can create three roles with the access-project tag key. Set the tag value of the first role to Heart, the second to Sun, and the third to Lightning. You can then use a single policy that allows access when the role and the resource are tagged with the same value for access-project. For a detailed tutorial that demonstrates how to use ABAC in AWS, see IAM Tutorial: Define permissions to access AWS resources based on tags.

Multi Factor Authentication :-Customers can add two-factor authentication to their account and to individual customers (users) for extra security.

With MFA customers or their users must provide not only a password or access key to work with user account, but also a code from a specially configured device.

By using the Multi-factor authentication customers can easily add the two-factor authentication not only for their account but also for the individual users for more security.

AWS Identity and Access Management (IAM) lets customers manage several types of long-term security credentials for IAM users using the following

• Passwords:- Used to sign in to secure AWS pages, such as the AWS Management Console and the AWS Discussion Forums.
• Access keys:- Used to make programmatic calls to AWS from the AWS APIs, AWS CLI, AWS SDKs, or AWS Tools for Windows PowerShell.
• Amazon CloudFront key pairs:- Used for CloudFront to create signed URLs.
• SSH public keys:- Used to authenticate to AWS CodeCommit repositories.
• X.509 certificates:- Used to make secure SOAP-protocol requests to some AWS services.

Manage federated users and their permissions :- Customers can enable identity federation to allow existing identities (users, groups, and roles) in their enterprise to access the AWS Management Console, call AWS APIs, and access resources, without the need to create an IAM user for each identity.

• Access and Federation :– User can grant other people permission to administer and use resources in your AWS account without having to share your password or access key.

AWS offers multiple options for federating customers identities in AWS. One of them being  AWS Identity and Access Management (IAM) which enable users to sign in to their AWS accounts with their existing given credentials.

Manage IAM users:- AWS clients can grant other people permission to administer and use resources in their AWS account without having to share their password or access key. They can also create users in IAM, assign them individual security credentials (such as access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources. You can manage permissions in order to control which operations a user can perform. IAM users can be:

• Privileged administrators who need console access to manage your AWS resources.
• End users who need access to content in AWS.
• Systems that need privileges to programmatically access your data in AWS.

Securing Application Access:- AWS Identity and Access Management (IAM) helps customers control access and permissions to thier AWS services and resources, including compute instances and storage buckets. they also can use IAM features to securely give applications that run on EC2 instances the credentials that they need in order to access other AWS resources, like

• S3 buckets and RDS
• DynamoDB databases.

The AWS Security Token Service (STS):- IAM roles allow customers to delegate access to users or services that normally don’t have access to their organization’s AWS resources. IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls. In other word AWS customers don’t have to share long-term credentials or define permissions for each entity that requires access to a resource. Using the AWS Security Token Service (STS), that is a web service that enables customers to request temporary, limited-privilege credentials for IAM users or for users that they authenticate (federated users).

Customers do not have to distribute or embed long-term AWS security credentials with an application.

• Customers can provide access to their AWS resources to users without having to define an AWS identity for them.
• The temporary security credentials have a limited lifetime.
• After temporary security credentials expire, they cannot be reused.
• AWS STS are features of customers AWS account offered at no additional charge. However customers will bare that are charged they access other AWS services using your IAM users or AWS STS temporary security credentials.

Granular Permissions:- Granular permission enables customers to grant the permissions for different according to their resources. Customers can give the whole access to AWS services, while limiting the other users to read-only access along with the administrator EC2 instances in order to access the process of billing information. These services include;

Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift.

For other users, customers can allow

• Read-only access to just some S3 buckets,
• Permission to administer just some EC2 instances, or
• Access to customer billing information but nothing else.
• IAM also enables customers to add specific conditions such as time of day to control how a user can use AWS,
• Their originating IP address, whether they are using SSL, or
• Whether customers have authenticated with a multi-factor authentication device.

Principal

An entity in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role. You can grant permissions to access a resource in one of two ways:

Principal element in a policy to specify the principal that is allowed or denied access to a resource. AWS customers cannot use the Principal element in an IAM identity-based policy.  They can use it in the trust policies for IAM roles and in resource-based policies. Resource-based policies are policies that they embed directly in an IAM resource. For example, they can embed policies in an Amazon S3 bucket or an AWS KMS customer master key (CMK).

AWS customers can specify any of the following principals in a policy:

Use the Principal element in these ways:

Request

A Request is a process where a principal send to AWS in order to use the AWS Management Console, the AWS API, or the AWS CLI. The request includes:

• Actions or operations – The actions or operations that the principal wants to perform.
• Resources – The AWS resource object upon which the actions or operations are performed.
• Principal – The person or application that used an entity (user or role) to send the request. Information about the principal includes the policies that are associated with the entity that the principal used to sign in.
• Environment data – Information about the IP address, user agent, SSL enabled status, or the time of day.
• Resource data – Data related to the resource that is being requested. This can include information such as a DynamoDB table name or a tag on an Amazon EC2 instance.

AWS gathers the Request information into a request context, which is used to evaluate and authorize the request.

AUTHORIZATION

Authorization is a process of specifying exactly what actions a principal can and cannot perform in AWS resources. This will be possible after IAM has authenticated the principal, then IAM must manage the access of that principal to protect the client AWS infrastructure. Authorization is handled in IAM by defining specific privileges in policies and associating those policies with principals.

A policy is a JSON document that fully defines a set of permissions to access and manipulate AWS resources. JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write and it is also easy for machines to parse and generate. Policy documents contain one or more permissions, with each permission defining:

• Effect:– Allow or Deny.
• Service:– Most AWS Cloud services support granting access through IAM, including IAM itself.
• Resource:– The resource value specifies the specific AWS infrastructure for which this permission applies.
• Action:– Action value specifies the subset of actions within a service that the permission allows or denies.
• Condition:–The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.

RESOURCES

After AWS approves the operations of customers’ request, they can be performed on the related resources within their account. A resource is an object that exists within a service. the resources include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket. The service defines a set of actions that can be performed on each resource.

AUTHENTICATION

A principal must be authenticated (signed in to AWS) using their credentials to send a request to AWS.

To authenticate from the console as a root user, customers need to sign in with their email address and password.

• IAM provide customers their account ID or alias, and then their users name and password.
• Principal can be authenticated three ways :
  • By using User name and Password
  • By using access key, that’s a combination of an access key ID (20 characters) and an access secret key (40 characters).
  • Access Key/Session Token—When a process operates under an assumed role, the temporary security token provides an access key for authentication.

OPERATIONS

After the request has been authenticated and authorized, AWS approves the actions or operations in customers’ request. Operations are defined by a service, and include things that the customer can do to a resource, such as viewing, creating, editing, and deleting that resource. IAM supports approximately 40 actions for a user resource, including the following actions:

• CreateUser
• DeleteUser
• GetUser
• UpdateUser

To allow a principal to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource

Operations (Actions) are defined by a service that include things such as viewing, creating, editing, and deleting that resource by customers. In order to get granted in these Operations, Principals (Root user,IAM user, and Role) request need to pass Authentication and Authorization.

IAM user

An IAM user is an entity that customers create in AWS. The IAM user 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. A user in AWS consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the API or CLI. IAM user accounts are user accounts which customers can create for individual services offered by AWS.

Root Users can create IAM, and assign them individual security credentials such as words, access keys, passwords, and multi-factor authentication devices, or request temporary security credentials to provide users access to AWS services and resources.

• IAM user 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.
• Root users can create IAM users, attach group level policies or user level policies and share these IAM accounts with other entities.
  • Group level and user level policies restrict and authorize individual IAM users to AWS services under Root user account.
• IAM users are individuals who have been granted access to an AWS account. Each IAM user has three main components:
  • A user-name.
  • A password.
  • Permissions to access various resources.
• Customers have persistent identities set up through the IAM service to represent individual people or applications.

power user

The description of power user access given by AWS is “Provides full access to AWS services and resources, but does not allow management of Users and groups.” The power to manage user is the highest privilege operation in AWS thus it is provided to the administrative access policy only.

• Power users are just below the Root user and have all the privileges the Root user has with the exception of the ability to manage the IAM users.

Roles and Temporary Security Tokens

AWS IAM role is same as the user in which AWS identity with certain permission policies to determine specific identity that can or cannot be done with AWS. One can also use similar roles to delegate certain access to the users, applications or else services to have access to AWS resources.

• Roles are used to grant specific privileges to specific entities for a set duration of time. These entities can be authenticated by AWS.
  • AWS provides these entities with a temporary security token from the AWS Security Token Service (STS), which lifespan run between 5 min to 36 hours.
  • Customers can create roles in IAM and manage permissions to control which operations can be performed by the entity.
• Customers can also define which entity is allowed to assume the role. In addition, they can use service-linked roles to delegate permissions to AWS services that create and manage AWS resources on your behalf.
• Granting permissions to users from other AWS accounts, whether you control those accounts or not known as Cross-Account Access
• IAM users can temporarily assume a role to take on permissions for a specific task.
  • Temporary credentials are primarily used with IAM roles and automatically expire.
• A role can be assigned to a federated user who signs in using an external identity provider.
• IAM roles can be used for granting applications running on EC2 instances permissions to AWS API requests using instance profiles.
  • Only one role can be assigned to an EC2 instance at a time.
  • Using IAM roles for Amazon EC2 removes the need to store AWS credentials in a configuration
• IAM Role Delegation has two policies:
  • Permissions policy – grants the user of the role the required permissions on a resource.
  • Trust policy – specifies the trusted accounts that are allowed to assume the role.

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.

Groups

An IAM group is a collection of IAM users. Groups let Root users  specify permissions for multiple users, which can make it easier to manage the permissions for those users. Customers can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users. Any user in that group automatically has the permissions that are assigned to the group.

• A group is not an identity and cannot be identified as a principal in an IAM policy.
• Groups are collections of users and have policies attached to them.(admin, developers, human resources…)
• A group can contain many users, and a user can belong to multiple groups.
• Groups can’t be nested; they can contain only users, not other groups.
• Use the principal of least privilege when assigning permissions.
  • Customers cannot nest groups (groups within groups).

The “identity” aspect of AWS Identity and Access Management (IAM) helps customers with the question “Who is that user?”, often referred to as authentication. Instead of sharing their root user credentials with others, they can create individual IAM users within their account that correspond to users in their organization. IAM users are not separate accounts; they are users within customers’ accounts. Each user can have its own password for access to the AWS Management Console.

Using the following elements, IAM provides the infrastructure necessary to control authentication and authorization for customers’ accounts. They are Principal, Request, Authentication, Authorization, Actions (Operations), and Resource.

Principal

A principal is a an IAM entity or application that is allowed to interact with AWS resources, or that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user. A principal can be permanent or temporary, and it can represent a human or an application. The administrative IAM user is the first principle, which can allow the user for the particular services in order to assume a role.

• There are three types of principals: root users, IAM users, and roles/temporary security tokens.

Root User

The username and password customers used to create an AWS account for the first time is called root user account. This account contains one important right that no other account created under IAM will have – the right to delete the entire AWS account including all storage, all EC2 instances, containers and everything else for that matter.

• The account root user credentials are the email address used to create an account and a password. The root account has full administrative permissions and it cannot be restricted.
• It’s AWS recommendation that customers  not to use the root user for their everyday tasks.
• Best practice for root accounts:
  • Don’t use the root user credentials.
  • Don’t share the root user credentials.
  • Create an IAM user and assign administrative permissions as required.
  • Enable MFA

Amazon Cognito provides authentication, authorization, and user management for customers web and mobile apps. AWS customers users can sign in directly with a user name and password, or through a third party such as Facebook, Amazon, Google or Apple.

AWS Fargate is a technology that AWS customers can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With Fargate, they no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale their clusters, or optimize cluster packing.

Lock away the AWS root user access keys:- The access key for customers AWS account root user gives full access to all their resources for all AWS services, including customers’ billing information. Its important not to share AWS account root user password or access keys with anyone