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. AWS Organizations also provides several policies that enable you to centrally apply additional security controls to all the member accounts in your organizations. This section focuses on service control policies (SCPs), resource control policies (RCPs), and declarative policies.

With AWS Organizations, you can use SCPs and RCPs to apply permission guardrails at the AWS organization, OU, or account level. SCPs are guardrails that 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, the SCP is inherited by the child OUs and accounts under that OU. SCPs do not grant any permissions. Instead, they 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 more 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.

RCPs are guardrails that apply to resources within an organization’s accounts, regardless of whether the resources belong to the same organization. Like SCPs, RCPs don’t affect the resources in the management account and do not grant any permissions. When you attach an RCP to an OU, the RCP is inherited by the child OUs and accounts under the OU. RCPs provide central control over the maximum available permissions for resources in your organization and currently support a subset of AWS services. When you design SCPs for your OUs, we recommend that you evaluate changes by using the IAM policy simulator. You should also review the service last accessed data in IAM and use AWS CloudTrail to log service usage at the API level to understand the potential impact of SCP changes.

SCPs and RCPs are independent controls. You can choose to enable only SCPs or RCPs, or use both policy types together based on the access controls that you want to enforce. For example, if you want to prevent your organization’s principals from accessing resources outside your organization, you enforce this control by using SCPs. If you want to restrict or prevent external identities from accessing your resources, you enforce this control by using RCPs. For more information and use cases for RCPs and SCPs, see Using SCPs and RCPs in the AWS Organizations documentation.

You can use AWS Organizations declarative policies to centrally declare and enforce your desired configuration for a given AWS service at scale across an organization. For example, you can block public internet access to Amazon VPC resources across your organization. Unlike authorization policies such as SCPs and RCPs, declarative policies are enforced in an AWS service's control plane. Authorization policies regulate access to APIs, whereas declarative policies are applied directly at the service level to enforce durable intent. These policies help ensure that the baseline configuration for an AWS service is always maintained, even when the service introduces new features or APIs. The baseline configuration is also maintained when new accounts are added to an organization or when new principals and resources are created. Declarative policies can be applied to an entire organization or to specific OUs or accounts.

Every AWS account has a single root user that has full permissions to all AWS resources by default.  As a security best practice, we recommend that you don’t use the root user except for a few tasks that explicitly require a root user. If you manage multiple AWS accounts through AWS Organizations, you can centrally disable root sign-in and then perform root privileged actions on behalf of all member accounts. After you centrally manage root access for member accounts, you can delete the root user password, access keys, and signing certificates, and deactivate multi-factor authentication (MFA) for member accounts. New accounts that are created under centrally managed root access have no root user credentials by default. Member accounts can't sign in with their root user or perform password recovery for their root user.

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.

• RCPs apply to resources for a subset of AWS services. For more information, see List of AWS services that support RCPs in the AWS Organizations documentation. The default configuration of AWS Organizations supports using RCPs as deny lists. When you enable RCPs in your organization, an AWS managed policy called RCPFullAWSAccess is automatically attached to the organization root, every OU, and every account in your organization. You cannot detach this policy. This default RCP allows all principals and actions access to pass through RCP evaluation. This means that until you start creating and attaching RCPs, all your existing IAM permissions continue to operate as they did. This AWS managed policy does not grant access. You can then author new RCPs as a list of deny statements to block access to resources in your organization.