Using AWS Organizations for security
AWS Organizations
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
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
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.
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.