Let’s examine how AWS Organizations helps you manage and improve some aspects of Enterprise-wide security and compliance. This discussion builds on the previous post detailing how AWS Organizations help you manage many AWS accounts and their costs.
AWS Organizations provide a number of additional security features, the one we’ll examine today is Service Control Policy.
Narrowing the Scope of AWS with Service Control Policy
AWS Organizations support a type of policy called Service Control Policy (SCP), which provides administrators of the Organization “control over the AWS services and API actions that each account can access.”
SCP lets you express this control by restricting which AWS services and API actions are available to a portion of the Organization. Policies can be applied to the root, an Organizational Unit, or an individual linked account.
When an AWS account, user, or role attempts to execute an API action, AWS’ security policy engine will verify that Service Control Policy permits use of that action in the account in addition to the IAM policies that are local to the AWS account. Account principals are limited to the actions in the greenish intersection of SCP and IAM policies. When an IAM policy local to the account grants access to an API action that SCP denies, the action will be denied. As the fine manual says, “Organization permissions overrule account permissions.”
Service Control Policies enable you to Allow or Deny entire services or specific API calls. When Service Control Policy is enabled and an API action is not explicitly Allowed or if it is Deny‘d, then the action will be denied. The default policy applied to accounts in an Organization is the FullAWSAccess policy, which permits all services and actions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
If you had an account dedicated to IAM development and testing, you might consider restricting what can go on in that account by starting with a Service Control Policy named IAMDevAndTest:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowIAMDev",
"Effect": "Allow",
"Action": [
"iam:*",
"sts:*"
],
"Resource": [
"*"
]
}
]
}
This policy permits use of only the entire Identity and Access (IAM) and Security Token Service (STS) APIs. Normally, full access to IAM is extraordinarily powerful, but with the IAMDevAndTest service control policy in place, access to all other services will be blocked. So, if someone gives themselves permission to launch EC2 instances in the IAM sandbox account and then tries to provision a fleet of Bitcoin miners, the ec2: RunInstances api call will be denied.
Since a Service Control Policy can be attached at any level of the Organization, you can construct a ‘policy layer cake’ using the Organizational hierarchy and account-level IAM to enable APIs appropriate for each account’s use case.
Service Control Policy can be an effective Architecture and Security governance and compliance tool. For example, you might use SCP to enforce use of HIPAA compliant AWS services that support your organization’s architectural strategy. SCP allows architects or a Cloud Center of Excellence to declare what services and actions are permitted and the most burdensome compliance work for the organization’s policy is offloaded to AWS. If you manage your policies using infrastructure as code tools, the policies are also easily inspectable, reviewable, versioned, and more.
But Wait, There’s More!
Individual AWS Security services such as Config, IAM, Security Hub, and more have been integrated with the AWS Organizations management model to enable consolidated management and views of Security concerns. Each one of these has own story, but there is a definite trend to provide tools to manage large collections of accounts so that your enterprise can grow securely.
I’d love to hear about what you’ve learned from your experiences with AWS Organizations and services like Service Control Policy. Drop me a note!
#NoDrama
