Using SCPs as Deny Lists – Designing a Multi-Account AWS Environment for Complex Organizations – SAP-C02 Study Guide

Using SCPs as Deny Lists

AWS Organizations, by default, attaches a managed SCP named FullAWSAccess to every root and OU structure upon creation. It is up to you to define additional SCPs at each level to limit the permissions as needed, by adding deny statements in the policies of these SCPs. For example, the following SCP blocks access to the Amazon RDS service:

{

  “Version”: “2012-10-17”,

  “Statement”: [

    {

      “Sid”: “DenyRDSAccess”,

      “Effect”: “Deny”,

      “Action”: “rds:*”,

      “Resource”: “*”

    }

  ]

}

You can leverage SCPs to prevent all sorts of actions, such as the following:

• To ensure that no one in your organization deploys anything in AWS Regions outside of specific pre-approved Regions
• To prevent users or roles in your organization from making damaging changes (especially to resources that may be managed centrally by a specific team, such as your security policies or your network topology)
• To prevent member accounts from leaving the organization
• To prevent users from disabling AWS Config or changing its rules

For more examples, please see the link to the AWS documentation in the Further Reading section.

Using SCPs as Allow Lists

If you want to use SCPs as allow lists, you must replace the AWS-managed FullAWSAccess SCP mentioned previously with one or more SCPs that explicitly allow only those services and actions you want to authorize. Note that when you remove the FullAWSAccess SCP, all actions are implicitly denied. The code in the following example grants explicit permissions to perform all actions on Amazon Elastic Compute Cloud (EC2) and Amazon S3 services, but implicitly denies access to any other service:

{

  “Version”: “2012-10-17”,

  “Statement”: [

    {

      “Effect”: “Allow”,

      “Action”: [

        “ec2:*”,

        “s3:*”

      ],

      “Resource”: “*”

    }

  ]

}

As we have seen, SCPs are extremely powerful as their action scope is potentially broad (single or multiple OUs, or even an entire organization). They can prove especially useful in protecting your key resources from being altered but also efficiently limiting the scope of what users and roles can do across multiple accounts.

Account Management at Scale with AWS Organizations

Beyond creating, structuring, managing accounts, and enforcing global security, backup, and tagging policies, AWS Organizations also allows you to scale the management of multiple other AWS services throughout an entire organization.

Nowadays, many different AWS services and features integrate with AWS Organizations to allow the central management of the resources they handle. We have already seen a few of them, such as backup and tagging. Another one, Control Tower, will be the subject of the next section. You will soon learn about several others in the coming chapters of this book, such as AWS Config, AWS Security Hub, Amazon GuardDuty, AWS Service Catalog, AWS Single Sign-On (AWS SSO), and AWS CloudTrail, to name a few. This list is by no means exhaustive, so for a complete list, please check the AWS Organizations documentation, as AWS Organizations keeps evolving and the list of integrated AWS services keeps growing.

Before we close this section on AWS Organizations, make sure to familiarize yourself with the quotas affecting it by looking at the AWS documentation at https://packt.link/5hQUP. Some of the quotas cannot be altered (you can have only one root in an organization and its depth is limited to five levels), while others can be raised by submitting a ticket to AWS Support (for instance, the number of accounts in an organization is ten by default; this is, luckily, only a soft limit).

The following section will introduce a service that is meant to enforce governance best practices at scale—Control Tower.