Section 1: IAM and AWS – Critical Concepts, Definitions, and Tools
Identity is the most granular unit of security. To ensure the confidentiality, integrity, and availability of a system, that system's infrastructure, applications, APIs, and endpoints must all be identifiable, authenticated, and authorized in order to perform its functions. The AWS platform operates under a rigid identity-centric model. Bridging that model with your own organization's identity implementation can be daunting. At the end of this section, you will understand the industry-standard and AWS-specific IAM terminology that will be referenced throughout this book. You will also learn about best-practice access management patterns and the tools available to implement said patterns within AWS.
This part of the book comprises the following chapters:
- Chapter 1, An Introduction to IAM and AWS IAM Concepts
- Chapter 2, An Introduction to the AWS CLI
- Chapter 3, IAM User Management
- Chapter 4, Access Management, Policies, and Permissions
- Chapter 5, Introducing Amazon Cognito
- Chapter 6, Introduction to AWS Organizations and AWS Single Sign-On
- Chapter 7, Other AWS Identity Services
Chapter 1: An Introduction to IAM and AWS IAM Concepts
Identity is the perimeter of security, and every transaction, capability, administrative event, and infrastructure component of cloud providers such as Amazon Web Services (AWS) ultimately depends upon identity services to govern all its capabilities. If that scope wasn't large enough already, tying AWS' native capabilities to an existing enterprise, customer, administrative, or infrastructure identity deployment can seem so complex as to make it difficult for cloud identity administrators to know how or where to start. This book will help you overcome the paralysis caused by the capabilities of the platform by approaching the implementation of AWS IAM (IAM) in a use case driven fashion, informed by real experiences working in large enterprise AWS environments.
By the end of this chapter, you will be familiar with the foundational concepts of IAM and see how they are applied within an organization. You will learn the purpose of the AWS IAM service, its components, and how they all work together to secure access to AWS resources. Finally, you'll use the AWS Management Console to create and manage AWS IAM resources, including IAM users, groups, and policies.
This chapter will cover the following topics:
- Understanding IAM
- Exploring AWS IAM
- Putting it all together
Technical requirements
To get the most out of this chapter, you will need the following:
- A web browser
- An AWS account
Understanding IAM
Identity is the most granular unit of security. The users, services, and systems that interact with infrastructure, applications, APIs, and endpoints must all be identified, authenticated, and authorized in order to perform their functions. The AWS platform operates under a rigid identity-centric model. Bridging that model with your own organization's identity implementation can be daunting.
Identity practitioners can (and do) argue about the minutiae and nuances of the terminology used within IAM. However, for our purposes, we can afford to use a broad definition of IAM in AWS:
''Identity & Access Management is the discipline of managing the life cycle of digital accounts that correspond to and are under the control of a person and ensuring that only the correct resources are accessed by the correct actor under the correct context.''
For something purported as a simple definition, that sure is a mouthful. However, if we break the statement down into its constituent components and consider a typical use case, it affords us an opportunity to see how many technical disciplines you may already be familiar with that relate to IAM:
''Managing the life cycle of digital accounts that correspond to and are under the control of a person…''
In layman's terms, we have these digital accounts that can be used to access computer systems. These accounts either directly or indirectly map to a person. This means that the account is either a digital representation of that person or the person owns and controls those accounts. That person can demonstrate proof of control of those accounts and is accountable for actions taken with those accounts. And those accounts have a life cycle, meaning under certain conditions they are created, under other conditions they may change, and at some point, they may eventually cease to be.
This is called identity management. Identity management is responsible for the following:
- Keeping accounts up to date
- Keeping downstream consumers of those accounts synchronized with the authoritative sources that define the account
- Provisioning and deprovisioning accounts entirely from various data stores
In short, it's a collection of processes responsible for managing account life cycle events in accordance with business, legal, or technical controls. These controls trigger life cycle events for accounts, such as account creation, modification, and disablement. What those life cycle events are will vary depending upon the event, type of account, business, and requirements of the system using those identities.
Now, let's look at the rest of the definition:
''…and ensuring that only the correct resources are accessed by the correct actor under the correct context.''
Those accounts, having been created, can be used to execute specific activities. What they can do is determined by rules and policies. In order to do anything, the account must first provide proof that whoever or whatever is using it to perform an activity is actually allowed to do so. That proof comes through a shared secret that validates the authenticity of the actor behind the account. This second part of our IAM definition addresses something called access management. Access management addresses the authentication of the account (proving you are who you say you are) and the authorization of that account (proving that you are allowed to do what you are trying to do with that account) to access resources or to perform certain tasks in accordance with established policies.
IAM applied to real-world use cases
To understand this better, and to provide a flimsy pretext to introduce some additional concepts that are not so easily derived from that definition of IAM, let's imagine what happens when someone joins a new company. To help visualize all the actors, systems, and life cycle events in play, take a look at the diagram in Figure 1.1.
In this example, Bob has applied for a sales role at a large identity services organization called Redbeard Identity, which has a reasonably mature internal IAM program, application portfolio, and cloud platform capabilities. Bob's identity experience actually began long before he got to the point where the hiring manager was prepared to make an offer, because in order to apply for the position, he had to create a profile inside of Redbeard Identity's candidate management system.
Important note
The Redbeard Identity organization will be the organization referenced for several use cases and scenarios throughout this book. Whereas real organizations typically have a fixed enterprise architecture, we will adjust the architecture, capabilities, services, user accounts, and other characteristics of the Redbeard Identity organization from chapter to chapter in whatever ways we need to best demonstrate the material of that chapter. Please don't be confused if our example organization's characteristics are not entirely consistent throughout the book.
This marks the first identity life cycle event in Bob's onboarding journey: user account creation. Bob, as a user of the candidate management system, is providing self-issued, unverified information about himself such as his name, contact information, and details about his work history. As there is neither external proof nor an outside source of control validating the information he enters into this system, his candidate account is considered a low-assurance record. As long as Bob remains merely a candidate for the sales role, that low level of assurance is sufficient for the purpose that the candidate record system account serves:
Figure 1.1 – Example of IAM life cycle events and flows
Bob knows his craft well, is an impressive salesman, and aces his interviews. After the details are agreed upon, the hiring manager sends Bob the offer letter confirming the details of his role, along with instructions for accepting the offer. Bob accepts...
