Using AWS Organizations for security

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 should 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 all users and roles within the covered accounts. When you attach an SCP to an OU, it flows down and affects all the branches (OUs) and leaves (accounts) beneath it. 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 more information about the types of IAM policies, see the IAM resources section. When you attach an SCP to your OU, the SCP limits permissions for principals in all associated member accounts. For example, you can apply an SCP that restricts users from launching resources in AWS Regions that you have not explicitly allowed.

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 principals (users or roles) and sets the maximum permissions that an identity-based policy can grant to an IAM principal.

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, and that is the approach we recommend. 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 Strategies for using SCPs in the AWS Organizations documentation.

Design consideration

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 can be a good fit for highly regulated and sensitive workloads. This approach requires maintenance, because you must explicitly allow every IAM action in the path from the AWS account to the OU, and some of the actions might need to be implemented by a separate team, such as central security or identity and access management.