Chapter 8: An Ounce of Prevention – Planning Your Administrative Model

In a fast-paced enterprise setting, many practitioners find themselves building piecemeal solutions to complex business challenges in reaction to the changing demands and urgent deadlines imposed upon them by the business. As both Identity and Access Management (IAM) and the cloud are high-value, business-enabling technologies, it can be challenging to take the time before implementation to contemplate what a sustainable implementation pattern looks like for the business. Although engaging in this planning exercise may frustrate some stakeholders, organizations that fail to plan out their cloud administrative models often find themselves limited by their own short-term technical solutions. Solving use cases such as these should be a holistic, multi-step design and analysis process.

In this chapter, we will evaluate how we would like to apply an administrative model to the Redbeard Identity organization...

Technical requirements

To get the most out of this chapter, you will need an AWS account.

Evaluating the organization's current IAM capabilities

Our objective over the next few chapters is to look for ways to link an organization's existing identity management infrastructure and the organization itself to AWS. More specifically, we want every administrator to have access to the backplane of the AWS account or accounts where appropriate, and for these existing user identities to become available to applications hosted on AWS. This means we will need to connect an existing org's IAM infrastructure to AWS and apply the appropriate provisioning, governance, and authorization models to ensure that appropriate access is granted. As we just completed a review of the AWS identity services, next we must look at our organization's IAM capabilities.

First, we must take an inventory of the current identity management landscape, capabilities, and maturity for the organization as that will help inform our administrative model. In order to make these examples comparable...

Evaluating the business structure and account schema

As part of this exercise and others in the following chapters, we will be creating several user accounts inside a directory that we can use with various AWS services. Let's take a look at a sample account and its available attributes:

Table 8.1 – One user record from the organization

We've built this organization to include several users with diverse attribute values in order to set up several example scenarios that we are likely to see in an enterprise use case. To help us stay focused on how we are solving identity challenges on AWS rather than concerning ourselves with needing to remember names, each employee record is named for their job title. Furthermore, each account will track to a specific AWS use case or environment. We will dive into the details of the AWS organizational design in the next section. For now, let's look at all the accounts inside of our directory and a few key...

Designing the AWS organizational structure

Now that we have ascertained our organization's IAM capabilities, its business requirements for AWS integration, and the account schema, we can begin to lay the groundwork for how we will manage our organization's AWS accounts. While small organizations may be able to address their cloud workloads within a single account, enterprise-grade organizations often need to have additional regulatory and compliance requirements that demand additional segmentation between business units, job functions, and workloads. A well-planned multi-account structure will provide these benefits without increasing the administrative overhead.

Mapping business functions to OUs

We will do this through an AWS organization, OUs, and organizational SCPs. Before we begin the work of configuring all these things in the Management Console, it will be helpful to first come up with and document our plan for the organizational hierarchy. First is our management...

Summary

In this chapter, we took a few moments to plan out our administrative model for an enterprise AWS deployment. We did this so we could accommodate the business requirements with a full understanding of the organization's IAM maturity and current-state capabilities, which will help us design administrative patterns that will be supportive in the long term. Once we had thought through the use cases, requirements, and capabilities, we designed and applied some high-level OU SCPs that will govern all the AWS accounts that we will be administrating moving forward.

We will build upon this foundational work in the next two chapters. First, in the next chapter, we will connect Redbeard Identity's external IDP and provision our administrative users into AWS SSO. Then, in Chapter 11, Bringing Your Users into AWS, we will address authentication and authorization use cases for those users into the AWS backplane.

Questions

1. Which of these did we not consider when designing our administrative model?

   a. The number of employees in the organization

   b. Current-state IAM capability

   c. Business objectives

   d. Business function alignment

2. Why did our Suspended OU have the FullAWSAccess SCP when we did not attach it to that OU?

Further reading

• AWS best practices for organizations: https://aws.amazon.com/organizations/getting-started/best-practices/
• Best practices for OUs with organizations: https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog