Identity-Based Policies

    If you have been using AWS for any length of time, then you will be most familiar with this type of policy. Identity-based IAM policies in AWS are a way to manage permissions and control access for individual users, groups, or roles within your AWS accounts. You can attach these policies to identities created within the IAM service. These policies then define what actions those identities can perform and what resources they can access.

    For example, suppose a group had a policy attached to it that allows full Amazon S3 access. The group users would be granted permissions based on this and any other policies bound to the group, which makes the policy an identity-based policy. By using identity-based IAM policies, you can ensure that each user, group, or role in your AWS account has the appropriate level of access to AWS resources.

    They help enforce security, control resource usage, and adhere to the principle of least privilege. In the case of an identity-based policy that would help enforce security, control resource usage, and adhere to the principle of least privilege, consider the following scenario. Your company hosts multiple Amazon S3 buckets for different purposes, ranging from marketing assets to sensitive financial reports.

By crafting specific identity-based policies, the organization ensures that access permissions align with team roles. For instance, the marketing team is granted read-only access to the Marketing bucket, the finance team receives read and write permissions for the FinancialReports bucket, and the sales team gains full access to the OrderStatements bucket. IAM groups are created associating these policies with corresponding teams, facilitating easy management and modification of permissions as the organization evolves. This approach not only enhances security by adhering to the principle of least privilege but also allows efficient resource usage, adaptability to changing roles, and streamlined auditing for compliance purposes.

Identity-based policies can be AWS managed, customer managed, or inline policies. The three types of identity-based policies are discussed in detail here:

• AWS-managed policies: These are predefined, ready-to-use policies that can be found within IAM. AWS-managed IAM policies are created and maintained by AWS experts and thus adhere to the best security and access control practices. These policies are designed to provide secure and granular access to AWS services and resources. They are automatically updated by AWS when new services or actions are added or when security best practices change. This means you don’t have to spend time and effort manually managing and updating the policy versions.

You can filter out only the AWS-managed policies from the IAM service from the AWS Management Console. Navigate to Policies and use the search bar to select the filter options.

Then choose the AWS managed policy type.

Figure : The Policies management screen

The preceding screenshot shows how you can select the AWS-managed policies. Once selected, it will then filter out any customer-managed policies that you might have previously created.

Figure : List of AWS-managed policies in the AWS account

    Once you have the AWS-managed policy filter on, you can combine that with a search of the service or types of permissions you are trying to provide to your user, group, or role. In the preceding screenshot, a filter has been applied so that only policies containing the Admin name will appear in the search results.

• Customer-managed policies: These are policies that you have customized to fit your specific need for a user, group, or role. For instance, there might not be an AWS-managed policy that specifically meets your organization’s needs. As a result, you may need to either copy and customize an existing managed policy or create your policy from scratch. You can use the visual editor to do so or write it yourself using the JavaScript Object Notation (JSON) format. Customer-managed identity-based policies give you much more granular control over how you want to manage identity access than AWS-managed policies.
•     Inline policies: These are different from both AWS and customer-managed policies in the sense that inline policies are embedded directly into the identity object. For example, customer-managed policies are stored in IAM as separate objects and can then be assigned to multiple identities, such as groups, roles, and users. Inline policies are not stored as individual objects; they only exist within the entity that they are created in—users or roles. Show in the figure presents a diagrammatic representation of the differences between managed and inline policies.

Figure : Managed versus inline policies in IAM

It is recommended to use managed policies instead of inline policies whenever possible. Managed policies are easily visible within IAM, while inline policies are embedded within identities and not as easily visible. Managed policies, as their name suggests, are managed by AWS, and therefore are updated by the AWS service team as new services are added to the platform or as other best practices are discovered. This takes an element of micromanagement and responsibility off of you and your team. However, conversely, a permission to a service might be added (or possibly removed) that you had not expected. All in all, using a managed policy if available is preferable in most cases since it will save you from looking up all the possible services needed for the role and having any future services updated automatically.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Users versus Roles versus Groups in IAM

    It is important for you to understand the differences between users, groups, and roles and their overall purposes within access control. This will help you architect and implement the most appropriate and effective access control for users and identities.

In AWS IAM, users represent individual identities, such as team members or applications, that interact with AWS resources. Each user is assigned a unique username and security credentials, which can include passwords or access keys. Users can be granted specific permissions to access and perform actions on AWS resources. For example, you can create a user named Emma and permit them to manage EC2 instances. Users are typically used to grant access to specific individuals or applications within your environment.

Roles, on the other hand, are used to grant temporary permissions to entities assuming those IAM roles, such as users or AWS services. Roles are not assigned to specific individuals but are assumed by trusted entities when needed. They enable secure delegation of access without the need to share long-term credentials. For example, you can create a Lambda Developer role and then define the permissions required to develop and deploy AWS Lambda functions. Then, users or services can assume this role temporarily to gain the necessary permissions. Roles are beneficial in scenarios where users or services need to access AWS resources on an as-needed basis that does not grant permanent access keys or passwords.

Groups are logical collections of users. Instead of assigning permissions to individual users, you can create groups and set permissions to those groups. This approach helps simplify permissions management, especially when multiple users require the same level of access to AWS resources. For example, you can create a DatabaseAdmins group that contains permissions to manage specific AWS services. You can then add multiple users to that group, and they will inherit the permissions assigned to it. By using groups, you can easily manage and update permissions for multiple users at once, ensuring consistent access.

Figure shows the hierarchy of IAM. Identities are composed of users, groups, and roles, and groups are made up of one or more users. IAM authorizes its identities using permissions, which comprise policies, and policies are made up of statements. With an understanding of the different identities that can authenticate using the IAM service and how they get their authorizations.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Terms to Understand for IAM

        To gain a comprehensive understanding of IAM, there is some terminology that you need to become familiar with, some of which you have already encountered in this book. This section highlights these key terms and provides their definitions. These don’t need to be memorized for the Security Specialty exam per se, as there will be no direct questions on the terminology. However, they appear frequently in the questions, so knowing their meaning is critical so you fully understand the question or answer.

These terms are listed here:

• Principal: An application or person that uses either the AWS root account user, an IAM user, or an IAM role to authenticate to the specified account and make requests. This is someone or something that can take action on an AWS resource.

• Resources: A resource is any item that you can work with inside an AWS account. Examples of a resource are a Lambda function, an EC2 instance, or a Relational Data Service (RDS) database.

• Entities: An entity can be an IAM user, a federated user, or a user coming in from an IdP. It could also be an assumed IAM role in the context of AWS, and it is simply the IAM resource object that AWS uses for authentication.

• Identities: The resources used to identify who is using the services are known as identities in IAM. These are your users, groups, and roles. With a grasp of the overall IAM service and terminology, you will next be introduced to two concepts that are easy to confuse: authentication and authorization.

Authorization versus Authentication

        Authorization and authentication are crucial in IAM. Even though the two terms seem incredibly similar and are used in conjunction quite frequently, it is essential to understand the difference between them as you move further into access and identity management. Understanding these differences is crucial for building secure and effective systems as these two concepts serve distinct but complementary roles in the realm of information security:

• Authentication: Authentication is the process of verifying who you claim to be. The system asks who you are, and you will often respond with a username and password. However, there can be times when you respond with a secure session token, such as an access token or a JSON

Web Token (JWT). Authentication is about answering the questions Who are you? and Can you verify who you say you are?

• Authorization: Authorization takes place after authentication and establishes what you are allowed to do. Rules and policies govern what you are authorized to access. In the world of computing, this can be relayed through a token, such as a bearer token or JWT that grants you access to services or Application Programming Interfaces (APIs).

The processes of authentication and authorization are illustrated in Figure

Thant Zin Phyo@Cracky (MCT, MCE, MVP)