Using AWS Organizations for security - AWS Prescriptive Guidance

Using AWS Organizations for security

Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey.

AWS Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources. By using AWS Organizations, you can programmatically create new AWS accounts, allocate resources, group accounts to organize your workloads, and apply policies to accounts or groups of accounts for governance. An AWS organization consolidates your AWS accounts so that you can administer them as a single unit. It has one management account along with zero or more member accounts. Most of your workloads reside in member accounts, except for some centrally managed processes that must reside in either the management account or in accounts assigned as delegated administrators for specific AWS services. You can provide tools and access from a central location for your security team to manage security needs on behalf of an AWS organization. You can reduce resource duplication by sharing critical resources within your AWS organization. You can group accounts into AWS organizational units (OUs), which can represent different environments based on the workload's requirements and purpose.

With AWS Organizations, you can use service control policies (SCPs) to apply permission guardrails at the AWS organization, OU, or account level. These guardrails apply to principals within an organization's account, with the exception of the management account (which is one reason not to run workloads in this account). When you attach an SCP to an OU, it is inherited by the child OUs and accounts under the OU. SCPs do not grant any permissions. Instead, SCPs specify the maximum permissions for an AWS organization, OU, or account. You still need to attach identity-based or resource-based policies to principals or resources in your AWS accounts to actually grant permissions to them. For example, if an SCP denies access to all of Amazon S3, a principal affected by the SCP will not have access to Amazon S3 even if they are explicitly granted access through an IAM policy. For detailed information about how IAM policies are evaluated, the role of SCPs, and how access is ultimately granted or denied, see policy evaluation logic in the IAM documentation. 

AWS Control Tower offers a simplified way to set up and govern multiple accounts. It automates the setup of accounts in your AWS organization, automates provisioning, applies guardrails (which include preventive and detective controls), and provides you with a dashboard for visibility. An additional IAM management policy, a permissions boundary, is attached to specific IAM entities (users or roles) and sets the maximum permissions that an identity-based policy can grant to an IAM entity.

AWS Organizations helps you configure AWS services that apply to all your accounts. For example, you can configure central logging of all actions performed across your AWS organization by using AWS CloudTrail, and prevent member accounts from disabling logging. You can also centrally aggregate data for rules that you've defined by using AWS Config, so you can audit your workloads for compliance and react quickly to changes. You can use AWS CloudFormation StackSets to centrally manage AWS CloudFormation stacks across accounts and OUs in your AWS organization, so you can automatically provision a new account to meet your security requirements. 

The default configuration of AWS Organizations supports using SCPs as deny lists. By using a deny list strategy, member account administrators can delegate all services and actions until you create and attach an SCP that denies a specific service or set of actions. Deny statements require less maintenance than an allow list, because you don't have to update them when AWS adds new services. Deny statements are usually shorter in character length, so it's easier to stay within the maximum size for SCPs. In a statement where the Effect element has a value of Deny, you can also restrict access to specific resources, or define conditions for when SCPs are in effect. By contrast, an Allow statement in an SCP applies to all resources ("*") and cannot be restricted by conditions. For more information and examples, see Strategy for using SCPs in the AWS Organizations documentation.

Design considerations

  • Alternatively, to use SCPs as an allow list, you must replace the AWS managed FullAWSAccess SCP with an SCP that explicitly permits only those services and actions that you want to allow. For a permission to be enabled for a specified account, every SCP (from the root through each OU in the direct path to the account, and even attached to the account itself) must allow that permission. This model is more restrictive in nature and might be a fit for highly regulated and sensitive workloads. This approach requires you to explicitly allow every IAM service or action in the path from the AWS account to the OU.

  • Ideally, you would use a combination of deny list and allow list strategies. Use the allow list to define the list of allowed AWS services approved to be used within an AWS organization and attach this SCP at the root of your AWS organization. If you have a different set of services allowed per your development environment, you would attach the respective SCPs at each OU. You can then use the deny list to define enterprise guardrails by explicitly denying specific IAM actions.