blog

The Power of AWS Service Control Policies in a Multi-Account Environment

Author: Kalin Iliev, Cloud infrastructure Engineer

For companies looking to move to the Cloud, setting up a multi-account environment is increasingly becoming a common approach. Yet, this can be a complex, often mismanaged undertaking for those that are unaware of how to harness the power of AWS’ Service Control Policies.

Introducing a multi-account environment primarily involves creating dedicated accounts to ensure resource isolation, security, and scalability. For those on the AWS platform, there are many benefits to be taken advantage of throughout this process – some which often get overlooked – like utilising AWS Organisations.

AWS Organisations allows for both a controlling ‘parent’ account as well as ‘child’ accounts for new members added under the same organisation. This provides companies with­­­ an easy and efficient way to manage the rapidly growing number of new accounts under one organisation on the AWS platform.

Within AWS Organisations, it is possible to logically group the accounts in a hierarchical structure of Organisational Units (OU) to control access on different levels by granting a common access to a group of accounts with similar characteristics and purpose.

Prior to starting their cloud migration, it is vital that organisations define their baseline requirements and ensure governance using security, compliance and operations guardrails. Part of the AWS Organisation feature set, Service Control Policies (SCP) act as powerful and efficient instruments in assisting with the compliance of these requirements. Once enabled, the ‘parent’ account gains full control over the child account permissions – which are assigned to respective account users or roles.

It should be noted here that AWS Identity and Access Management (IAM) polices are still required to give the entities permissions before applying SCPs from the organisation. It is important to clarify that IAM and SCP policies have similar syntax but a different function.

How do SCPs come into use?

SCPs are used to forbid or limit access to certain AWS services or features, while also allowing access to the rest of the services in a more secure and cost-effective way. SCPs can be attached to the root of the organisation, to an OU or an individual account, and once attached the policy affects all accounts underneath it. On top of this, each OU can have one or more child OUs.

Example Organisation Units (OU) structure

Example Organisation Units (OU) structure

Every organisation will create its own OU structure whereby SCPs are applied to OUs. Although it is possible, attaching an SCP to the organisational root is not recommended as it applies to all accounts in the organisation, which may not always be the desired effect. Attaching an SCP to an account directly in most cases is done if the limit of attached policies (5 SCPs per OU) is reached. Additionally, some policies can be combined into one if attached to the same OU.

Another limit that is often hit is the number of characters allowed in SCP. To decrease this number, any whitespace, such as characters and line breaks that are outside quotation marks in the policy, can be removed by using an automated visual editor.

How to group the accounts

As per best practice for building a multi-account environment in AWS; AWS security, logging, networking services should all be enabled and centrally configured for all accounts in the organisation so that we can have a group of “Core” accounts to host these services. Another example category of accounts could be “Sandbox” accounts, which can be used as a playground by developers and other teams to experiment with AWS services. A third group could include “Application” accounts with the major purpose of running AWS application workloads and similar actions. More groups and sub-groups can be created based on the needs and separate accounts by departments, application development lifecycles and projects.

Once the AWS Organisational structure is created and defined then the SCPs can start applying.

The following are a few examples of the SCPs that are recommended to customers setting up an environment in AWS. Certainly, there are more to add based on the specific requirements.

By default, AWS Organizations attaches an AWS managed policy called ‘FullAWSAccess’ to the root and all OUs and accounts – allowing any account to access any service or operation. SCPs explicitly deny access to undesired services and actions.

How to restrict services to only one region

One essential restriction to start with is isolating service operations by AWS regions. By default, resources can be created in either of the available regions around the globe, no matter the location. Most of the organisations select one or a few regions to operate in. It would be reasonable to apply a policy that prevents users from creating resources outside of these regions. There are several global AWS services such as IAM and Route 53 that need to be excluded to avoid the policy effect. “NotAction” is a policy statement that helps to accomplish this. After the policy is applied, users will be able to create resource only in the London region(eu-west-2).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllServicesOutsideLondonRegion",
      "Effect": "Deny",
      "NotAction": [
        "autoscaling:*",
        "aws-marketplace:*",
        "cloudfront:*",
        "globalaccelerator:*",
        "iam:*",
        "importexport:*",
        "lambda:*",
        "kms:*",
        "organizations:*",
        "route53:*",
        "route53resolver:*",
        "sts:*",
        "support:*",
        "waf:*",
        "wellarchitected:*",
        "servicequotas:*",
        "budgets:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-west-2"
          ]
        }
      }
    }
  ]
}

Enabled services protection

Deploying resources in a multi-account environment requires IAM roles in each account. A service control policy that prevents users from deleting and modifying these IAM roles and the respective IAM policies should also be in place. Any resources that may have been created in each account according to the baseline requirements should also be protected from change. These include IAM users, identity providers, budgets, configured security and logging services including CloudTrail, AWS Config, GuardDuty, CloudWatch, and VPC Flow Logs.

Encryption enforcement

As part of pursuing the goal of securing the environment, encryption should be enforced for any AWS services used to store data in one form or another. A policy enforcing encryption should be applied to all accounts in the organisation, including the sandbox accounts – so that it can be attached to all parent OUs.

The following policy does not allow creating EBS volumes if they are unencrypted. There should be a similar policy for uploading files to S3 buckets and creating RDS instances.

{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyUnEncryptedEBSVolumes",
            "Effect": "Deny",
            "Action": "ec2:CreateVolume",
            "Resource": "arn:aws:ec2:*:*:volume/*",
            "Condition": {
                "Bool": {
                    "ec2:Encrypted": "false"
                }
            }
        }
    ]
}

Restrictions in Sandbox accounts

When it comes to Sandbox accounts, in addition to securing resource access, ways to optimise the resource costs should also be sought out. As a first step, the AWS services that have been agreed to be used should be whitelisted. Why to give access to services that are out of the company business scope? The statement “NotAction” used in conjunction with the “Deny” effect becomes useful again to deny all services except those listed in the statement.

Configuring “AWS Budgets” in each sandbox account is recommended to monitor usage and cost and notify users and management teams when a threshold is reached. There should be a policy denying budget modifications if such is created. For the allowed services, some features and options can be disallowed that add extra cost if enabled.

The following policy allows creating RDS instances but with selected RDS instance types and engines only (PostgreSQL, MySQL, MS SQL Express Edition, MS SQL Standard Edition). Furthermore, for example, the creation of Multi-AZ or provisioned IOPS RDS instances could be denied to avoid unnecessary charges, especially in sandbox accounts. The policy denies these features as well.

{
      "Version": "2012-10-17",
      "Statement": [
    {
        "Sid": "AllowSpecificRDSEnginesAndInstanceTypesOnly",
        "Effect": "Deny",
        "Action": [
            "rds:CreateDBInstance"
        ],
        "Resource": "arn:aws:rds:*:*:db:*",
        "Condition": {
            "StringNotLikeIfExists": {
                "rds:DatabaseEngine": [
                  "postgres", "mysql", "sqlserver-ex*", 
"sqlserver-se*"
                ]
            },
            "StringNotEquals": {
                "rds:DatabaseClass": [
"db.t3.micro", "db.t3.small", "db.t3.medium",  "db.t2.micro", 
"db.t2.small", "db.t2.medium", "db.m4.large"
                ] 
            }
        }
    },
    {
        "Sid": "DenyMultiAzRDS",
        "Effect": "Deny",
        "Action": [
            "rds:CreateDBInstance",
            "rds:ModifyDBInstance"
        ],
        "Resource": "arn:aws:rds:*:*:db:*",
        "Condition": {
            "Bool": {
               "rds:MultiAz": "true"
          }
        }
    },
    {
       "Sid": "DenyPIOPSRDS",
       "Effect": "Deny",
       "Action": "rds:CreateDBInstance",
       "Resource": "arn:aws:rds:*:*:db:*",
       "Condition": {
          "NumericNotEquals": {
              "rds:Piops": "0"
         }
       }
    }
  ]
}

Conclusion

All available features and methods should be considered in order to configure a secure infrastructure. When properly tested and applied, AWS Service Control Policies, are a suitable addition that complete our AWS multi-account environment solution, ensuring appropriate resource usage and optimisation and safe individuals’ navigation throughout the environment.

References

https://aws.amazon.com/organizations/

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html

https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-in-aws-organizations/