Chapter 4: Access Management, Policies, and Permissions

The Access Management model of AWS is based on policies. At a high level, we can use these policies to determine what an AWS identity object or resource can do to or with a resource or service within an AWS account. Of course, this quickly becomes very complicated once we must apply and manage policies across the multiple places where they may have been applied. We may also need to customize the existing access policies within an AWS account, or even create new policies from scratch to accommodate our own use cases. This chapter does not represent a complete compendium of knowledge regarding the complexities of access management in AWS, but it will introduce you to the foundational concepts required to understand and solve several common authorization use cases.

With this knowledge as your foundation, you will be able to strategically select further areas of study based on your own personal or professional requirements.

...

Technical requirements

To get the most out of this chapter, you will need the following:

• An AWS account
• A workstation running the AWS CLI
• A text editor or IDE to edit JSON/YAML files, such as Microsoft Visual Studio Code

What is access management?

As the two words that make up the ''AM'' of IAM, access management represents one of the core functions of IAM as an enabling technology. Access management covers two things, the first of which is the validation that a request comes from a legitimate source. To frame that in AWS IAM terms, it means that it can provide the shared secrets affiliated with their IAM user account to prove the request is valid. This is the authentication side of access management; we dealt with how to authenticate AWS IAM user accounts in depth in Chapter 3, IAM User Management.

The second function of access management is to make sure that the request itself is authorized. This is to say that there is nothing about the request, such as the target of the action, or the location of the object or requestor, or anything else that runs afoul of the rules that apply to that specific request and requestor, which then determine what they should and should not be...

Introducing the AWS access policy types

We've mentioned the word policy before. In an organizational, regulatory, or legal setting, a policy represents the rules, patterns, and guidance meant to steer a decision-making process. In the context of IAM, a policy is how things such as business logic, security controls, and compliance requirements are translated into an access management system, such as AWS IAM. Within AWS IAM, policy are objects that specifically spell out the permissions of a principal or resource they are attached to. This can be seen in the following diagram:

Figure 4.1 – An example of policy objects that can apply to one or more AWS objects

Access policies can apply to IAM objects, as shown in the preceding diagram. They can also apply to specific AWS objects, such as S3 buckets, or even across multiple AWS accounts under the management of an AWS Organization.

In some regards, an AWS access policy can be thought of as a &apos...

The anatomy of an AWS JSON policy document

Most, but not all, policy types are written and stored as JSON documents within AWS. These include identity-based policies, resource-based policies, permissions boundaries, organizational service control policies, and session policies. Access control lists use a distinct syntax, depending on the service where it is being applied:

Figure 4.2 – A policy document, its components, and the elements of its statements

Let's take a look at the preceding diagram. Here, we can see a logical example of a policy document and its constituent components. Within the main document, there is a Top-level element that contains policy-wide information, followed by one or more statements. Each of these statements describes a permission or entitlement through the information contained within its individual elements.

We can see these elements within the JSON of a policy document by examining any of the existing policies available...

Exploring the AWS policy types

There are more than a few policy objects available within AWS. Every request and action within an AWS account is evaluated against these policies at execution time. Since that is a lot of moving parts determining permissions, let's take a look at the six major policy types and how they are used.

Identity-based policies

Identity-based policies are the policies that determine what an identity object can do. These policies are JSON documents that spell out the user, group, or role that can perform the action, the resources that those actions can be performed on, and the conditions under which those actions are valid. These identity-based policies are better understood by some further categorization into three additional policy types, which we will now explore in greater detail.

AWS managed policies

AWS IAM comes prepopulated with several hundred policy objects. They are not natively used in a new AWS account; they are simply available for...

Policy evaluation

Now that we've looked at all the policy types available to us within AWS, the question becomes, how do each of these policy types interact with each other, and is there some sort of order or operations in play among them for processing requests? Fortunately, there is an overall pattern of evaluation logic that we can follow to see how an action is evaluated. Unfortunately, there are plenty of exceptions and nuances – more than can be reasonably detailed here. Whereas it is still valuable to understand how requests are generally assessed by AWS IAM, it is always prudent to review the service-specific documentation for unique behaviors.

First, there are a few overarching rules:

• The AWS root account has full access by default.
• Requests from all other principals are denied by default.
• For identity-based policies and resource-based policies, an explicitly enumerated allow statement will override the default deny.
• Organizational service...

Governance

We've spent the last several pages detailing the mechanics of access management and authorization. It may seem tautological as to why we would want to enact a sound access management policy; we want to protect our AWS resources. However, there are also legal and regulatory requirements that we need to fulfill, such as least privilege, evidence of events, and audit. We will now look at a couple tools available to us to fulfill the governance requirements that come with access management.

Access Analyzer

Access Analyzer is a feature of AWS IAM that helps highlight potential weaknesses in existing authorization policy. As we've seen over the course of this chapter, there are many inputs, options, and places where a policy change could have unintended consequences for access control. As we start intertwining additional AWS accounts, and perhaps even AWS accounts not owned or managed by our own organization, it becomes increasingly important (and difficult) to...

Summary

Now that you've made it through this chapter, you should be familiar with the basics of AWS access management. Though we've reviewed the high-level components we need in order to be conversant on this topic and move forward, it is prudent to be cautious when it comes to access management and entitlements. Many security incidents that stem from excessive entitlements having been applied in an environment in the name of expediency. As such, consider this chapter a primer on learning how to learn more deeply about this topic, and consider the access management challenges that will surface throughout the remainder of this book.

The next chapter will see us shift from purely focusing on AWS IAM and looking at AWS as an infrastructure as a service offering. AWS Cognito is a service designed to offer applications simplified identity services, including user management, authentication, and authorization. Whereas we will reference many of the topics we introduced at the...

Questions

1. What is access management?
2. What is a policy document?
3. What is a statement within a policy document?
4. How many values are available for the Effect element and what are they?
5. Name the six major policy types available in AWS.
6. Describe why permissions boundaries and service control policies do not actually grant access to anything.
7. What tools are available to assist with access management audit and governance for AWS IAM and what do they do?

Further reading

• Condition – AWS User Guide
• Variables – AWS User Guide