How To Get Started With Identity And Access Management (IAM) on AWS
In our previous blog post, we talked about Identity And Access Management (IAM) in the context of Amazon Web Services (AWS), how it works, its features, and its benefits.
In this blog post, we walk you through how you can get started with implementing Identity And Access Management (IAM) in AWS.
But before we get started with the process, here is a quick introduction to the key terminologies related to AWS IAM that we will be using throughout this blog post.
Key Terms Related To AWS IAM
Identity
In AWS, identity refers to a user, group, role, or application. The identities are created through IAM and policies attached to them. This allows administrators to better manage and secure users within an AWS account.
Principal
A principal is an identity (user or application) that signs in and makes a request to AWS.
Root User
In AWS IAM, a root user is a superuser who has complete account privileges. The root user is the identity that is first used to create an Amazon account and has complete access to all Amazon services and resources in that account.
Authentication
Authentication is the process of defining and verifying an identity. It can be done in different ways- with username and password combination, access key and secret key, or temporary credentials. In simple terms, it can be understood as the process of signing in to AWS using your credentials. Generally, only an authenticated user can send requests to AWS.
Authorization
In AWS, authorization refers to access management. It determines what an identity can access after it has been authenticated. Access management is done by creating policies that are attached to identities and define the permissions, i.e. what an identity is allowed to do.
How To Get Started With AWS IAM?
In order to use the management console, you need to sign in to your AWS account. The sign-in process depends on whether you are a root user or a regular IAM user. The root user is the first user and creates the other IAM administrators and IAM users.
1. Signing In
IAM can be accessed by AWS users in the following ways:
Management Console
The management console is a browser-based graphical user interface (GUI) that allows you to access the AWS services. To be able to log in to the management console, you will need your username-password combination along with the AWS root login URL.
Command Line Interface
The AWS command-line interface (CLI) is a powerful tool that allows you to not just access the IAM but also to execute AWS tasks and execute scripts. Access from CLI requires access keys consisting of two parts, namely, Access Key ID and Secret Access Key.
Software Development Kit
You can also access IAM from libraries provided in the software development kit (SDK).
Application Programming Interface (API)
IAM can also be accessed programmatically using HTTPS APIs. This also requires Access Key ID and Secret Access Key to authenticate requests.
2. Configure IAM Users
As a security best practice root user account must not be shared and a new IAM user should be created for each person that requires administrator access. Each new user will have a username and password combination. Enabling MFA is optional but recommended. It is also highly recommended to enforce a strong password policy and require a password reset after the first sign-in.
3. Configure Groups, Roles, And Applications
IAM Groups
IAM groups, i.e. a set of users, helps administrators better manage users. Each group has certain policies and permissions attached to it. When a new user needs to be added to the AWS account, they can simply be added to the group. This ensures that the policies and permissions are consistent and there are no lapses in their application.
IAM Roles
An IAM role is an IAM identity with specific policies and permissions but not associated with any unique user. A role does not have unique credentials such as username-password combinations or access keys. Instead, a role can be assumed by any identity that needs it and it provides the user with temporary security credentials for the session.
IAM roles can also be used to delegate access to identities that don’t normally have access to certain AWS resources. Roles make it easy to give a user or application certain permissions without having to share the access key.
Applications
An application can be given programmatic access to AWS services via access keys.
4. Set Authentication
Authentication in AWS is done in one of the following ways:
Internal Identity Provider
The internal identity provider service of AWS is sufficient for most small to medium-sized businesses and nothing additional is required.
External Identity Provider
Businesses, especially large enterprises may prefer to use their existing directory services or web applications, which provide web identity for authentication. External Identity Providers can be used by creating an IAM identity provider and establishing a trust relationship between that identity and the AWS account. AWS IAM needs the external identity provider to be compatible with either Security Assertion Markup Language 2.0 (SAML 2.0) or OpenID Connect (OIDC).
5. Set Authorization
Authorization is called Policies in AWS and can be set in different levels and can overlap. The policies define what the identities, they are attached to, can do. Whenever a request is made, AWS checks the attached policies for permissions and determines whether the request is to be allowed or not.
The following six types of policies are supported by AWS:
Identity-Based Policies
Identity-based policies grant permissions to identities, i.e. users, groups to which users belong, or roles. They can be classified as follows:
Managed Policies
Managed Policies are standalone policies that can be applied to multiple identities. These policies may be created and managed by AWS or by the customer.
Inline Policies
Inline Policies are those that are directly applied to a single user, group, or role. This kind of policy has a one-to-one relationship with the identity it is applied to and is deleted when the identity is deleted.
2. Resource-Based Policy
Resource-based policies attach inline to resources. They grant permissions to the principal that is specified in the policy and specify who has access to and what actions they can perform on the resource.
3. Permissions Boundaries
A permissions boundary is used to set the maximum permissions that an identity-based policy can grant to an IAM entity. Actions that are allowed by both the permissions boundary and the identity-based policies can be performed by an entity and an explicit denial in either policy overrides the allow.
However, permissions boundaries do not limit the resource-based policies that specify the user or role as the principal.
4. Service Control Policy
Service Control Policies (SCPs) are policies that specify the maximum permissions for an organization. SCPs also limit the permissions for entities in member accounts, including each AWS account root user, that are part of the Organization Unit (OU).
SCPs can be applied to all of your accounts by enabling all features in an Organization, which is an AWS service for grouping and centrally managing AWS accounts owned by a business.
5. Access Control Lists
Access control lists (ACLs) are service policies that offer a way for you to control which principals in another account can access your AWS resources. It cannot, however, be used to control the access of principles within the same account.
6. Session Policies
Session policies are policies passed as parameters for programmatically created temporary sessions for a role or federated user. The permissions for a session come from the intersection of the session policies with the identity-based policies for the IAM entity and with the resource-based policy.
Session policies, therefore, limit the total permissions granted by resource-based policy and identity-based policy.
6. Allowed Access
After a request is authenticated and authorized, the user is allowed access to perform operations on the AWS resources.
Operations refer to the actions, such as viewing, editing, creating, deleting, that an entity can do to a resource. An entity can perform only those actions that are included in a policy that applies to the principal or the affected resource.
Conclusion
AWS IAM is a critical security service that helps organizations control and secure access to their Amazon resources. There are a number of benefits of implementing IAM including fine-grained access control, ease of access management, and ensuring least-privilege permissions.
While IAM is offered by AWS at no additional cost, the burden of proper implementation of IAM falls on the customer, i.e. your organization. Proper implementation of AWS IAM requires a thorough understanding of the various AWS services, threat landscape, and security best practices. Despite its complexities, the implementation of AWS IAM is a must for reducing security and business risks resulting from external attacks as well as internal threats and errors.
Are you looking for help with AWS Security and Compliance? Reach out to us to know how we can help improve the security of your AWS environment.