It’s time for another stage check: a little pause to review everything so far, and make sure you are ready for the next batch of labs.

And yes, it gives me a little break — these don’t take as long to write — but if you don’t tell anyone, I won’t.

Labs You Should Have Completed

• Everything required in Stage Check 1

• https://slaw.securosis.com/p/enable-aws-organizations

• https://slaw.securosis.com/p/give-account-security-blanket-scps

• https://slaw.securosis.com/p/assume-role-centralized-logging-part-1

• https://slaw.securosis.com/p/secure-bucket-centralized-logging-part-2-resource-policies

• https://slaw.securosis.com/p/enabling-org-trail-centralized-logging-part-3

• https://slaw.securosis.com/p/bring-federation-sso

• https://slaw.securosis.com/p/another-sso-iam-identity-center-part-2

• https://slaw.securosis.com/p/aws-lego-organizing-org

• https://slaw.securosis.com/p/ous-scps-root-user-account-recovery

• https://slaw.securosis.com/p/notwhat-lock-regions-double-negative-scp

Video Review

What We Did and Why

Zooming out gives us a chance to step back and review not only what we’ve done, but why. The goal is to put the individual labs together to build a bigger picture, and show how they work together as parts of a whole.

• We created our Organization and turned our original account into a management account. This is absolutely foundational, and you will likely never work out of a single account again — except to either start a new org, or back up your rare collection of Hello Kitty NFTs. It’s okay, I don’t judge.

• We created our first Service Control Policy, which is an organization-based policy. I call these security blankets because they sit outside your account and restrict what you can do in the account. For our first one we blocked any use of the root account, and the API call to leave the organization, and then we applied it to the new account called SecurityAudit which we created.

  • Except: never forget an SCP CANNOT apply to an organization management account (ours is called CloudSLAW). The UX sometimes makes it look like the SCP protects management accounts, but it doesn’t. This is one reason we are building towards running all our org stuff from other accounts. And never, ever, EVER, run a workload/application in the org management account! I pity the fool who has to clean that mess up.

• We then started that process and migrated our CloudTrail to the SecurityAudit account. Pulling those logs out of the management account is an important security step. In a real environment we would create our logging account before turning on CloudTrail, but that doesn't fit the way I want to structure these labs.

• As part of that process we learned an essential skill: assuming a role. Hang out with AWS nerds long enough and you’ll just hear us say ‘AssumeRole’, like everyone should know what that means.

• We also learned how to write our first resource based policy. In this case the policy allows the management account to save CloudTrail logs into our new log account. Many things still have to actually run in the management account, but we can move management and storage out. This moved the storage — guess what some of our next labs will be?

• We then ran a few labs to set up the AWS IAM Identity Center. It used to just be called AWS SSO but someone got ambitious or something. This was the first step down the path of federation, where you have an identity provider and a relying party. Federation is the name of the game in cloud, whether AWS or Billy Bob’s Bait as a Service (BaaS).

• Then we expanded with a bunch of new organizational units (OUs), which are the folders that hold accounts and other folders. These are important because we place SCPs on OUs, and that’s how we build out policy-based security. This lets us manage security context and treat things like development different than production.

• After that we learned how to recover the root user account on an account we created with Organizations and never even set a password for (and that, people is, why the root lockout SCP is so important). To pull this off we had to move our SCP off the root of our org and use an Exceptions OU without any SCPs. This let us move SecurityAudit into the Exceptions OU, which dropped the root lockout policy. We recovered root, logged in, and changed the name to LogArchive because … that’s a better name, and I messed up.

  • Recovering root is something you will need to do someday, and we used a very secure way to handle such a delicate process.

• At this point we have our org. We have OUs set up, and a few AWS accounts in our Security OU. Everything except the management account (CloudSLAW) and the Exceptions OU has the root account blocked from doing anything by that SCP, and is stuck in the org because we also block the LeaveOrganization API call. We also moved to using Identity Center for logging in. All this is exactly what you would do in a real deployment.

• We finished this block of training by adding an SCP to lock out regions, which is another tool to keep in your pocket for the real world.

  • That was an opportunity to learn how to use a double negative in an AWS policy, which is very useful and powerful. In our case we used Deny with NotAction and StringNotEquals to block any API calls except global services from running anywhere besides Oregon and Virginia.

It’s a lot, but there wasn’t another good breakpoint in this series of labs. We are in a great position now, with an AWS organization that follows best practices and closely matches what you will encounter, even in very large enterprise deployments.

Here’s a diagram showing all the pieces:

Lesson: None

This was a lot, tying a lot of concepts together. Nothing new to throw at you this week — I just hope you see the big picture, and how all the LEGO connect to making a stronger structure.

-Rich