AWS organizations documentation change
Summary
Updated SCP evaluation documentation with expanded scenarios, added condition element mention, and restructured policy examples
Security assessment
The changes enhance documentation about security controls (SCPs) by clarifying policy evaluation logic, adding critical warnings about root-level allow requirements (Scenario 3), and explaining deny statement precedence (Scenario 6). While not fixing a specific vulnerability, these updates improve security guidance by highlighting misconfiguration risks and policy hierarchy impacts.
Diff
diff --git a/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md b/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md index d3ac767da..d729d2b4d 100644 --- a//organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md +++ b//organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md @@ -54 +54 @@ _Figure 3: Example organization structure with an`Deny` statement attached at Pr -While writing SCPs you can make use of a combination of `Allow` and `Deny` statements to allow intended actions and services in your organization. `Deny` statements are a powerful way to implement restrictions that should be true for a broader part of your organization or OUs because when they are applied at the root or the OU level they affect all the accounts under it. +While writing SCPs you can make use of a combination of `Allow` and `Deny` statements to allow intended actions and services in your organization. `Deny` statements are a powerful way to implement restrictions that should be true for a broader part of your organization or OUs because when they are applied at the root or the OU-level they affect all the accounts under it. @@ -56 +56 @@ While writing SCPs you can make use of a combination of `Allow` and `Deny` state -For example, you can implement a policy using `Deny` statements to [ Prevent member accounts from leaving the organization](./orgs_manage_policies_scps_examples_general.html#example-scp-leave-org) at the root level, which will be effective for all the accounts in the organization. +For example, you can implement a policy using `Deny` statements to [ Prevent member accounts from leaving the organization](./orgs_manage_policies_scps_examples_general.html#example-scp-leave-org) at the root-level, which will be effective for all the accounts in the organization. Deny statements also support condition element which can be helpful to create exceptions. @@ -117 +117 @@ JSON -Now, consider the following sample organization structure to understand how you can apply multiple SCPs at different levels in an organization. +To demonstrate how multiple service control policies (SCPs) can be applied in an AWS Organization, consider the following organizational structure and scenarios. @@ -119 +119 @@ Now, consider the following sample organization structure to understand how you - +### Scenario 1: Impact of Deny policies @@ -121 +121 @@ Now, consider the following sample organization structure to understand how you -The following table shows the effective policies in the Sandbox OU. +This scenario demonstrates how deny policies at higher levels in the organization impact all accounts below. When the Sandbox OU has both "Full AWS access" and "Deny S3 access" policies, and Account B has a "Deny EC2 access" policy, the result is that Account B cannot access S3 (from the OU-level deny) and EC2 (from its account-level deny). Account A does not have S3 access (from the OU-level deny). @@ -123,5 +123 @@ The following table shows the effective policies in the Sandbox OU. -Scenario | SCP at **Root** | SCP at **Sandbox** OU | SCP at **Account A** | Resultant policy at **Account A** | Resultant policy at **Account B** and **Account C** ----|---|---|---|---|--- -1 | Full AWS access | Full AWS access + deny S3 access | Full AWS access + deny EC2 access | No S3, no EC2 access | No S3 access -2 | Full AWS access | Allow EC2 access | Allow EC2 access | Allow EC2 access | Allow EC2 access -3 | Deny S3 access | Allow S3 access | Full AWS access | No service access | No service access + @@ -129 +125 @@ Scenario | SCP at **Root** | SCP at **Sandbox** OU | SCP at **Account A** | Resu -The following table shows the effective policies in the Workloads OU. +### Scenario 2: Allow policies must exist at every level @@ -131,5 +127,27 @@ The following table shows the effective policies in the Workloads OU. -Scenario | SCP at **Root** | SCP at **Workloads** OU | SCP at **Test** OU | Resultant policy at **Account D** | Resultant policies at **Production** OU, **Account E** and **Account F** ----|---|---|---|---|--- -1 | Full AWS access | Full AWS access | Full AWS access + deny EC2 access | No EC2 access | Full AWS access -2 | Full AWS access | Full AWS access | Allow EC2 access | Allow EC2 access | Full AWS access -3 | Deny S3 access | Full AWS access | Allow S3 access | No service access | No S3 access +This scenario shows how allow policies work in SCPs. For a service to be accessible, there must be an explicit allow at every level from the root down to the account. Here, as the Sandbox OU has an "Allow EC2 access" policy, which only explicitly allows EC2 service access, Account A and B will only have EC2 access. + + + +### Scenario 3: Impact of missing an Allow statement at the root-level + +Missing an "Allow" statement at the root-level in an SCP is a critical misconfiguration that will effectively block all access to AWS services and actions for all member accounts in your organization. + + + +### Scenario 4: Layered Deny statements and resulting permissions + +This scenario demonstrates a two-level deep OU structure. Both the Root and the Workloads OU have "Full AWS access", the Test OU has "Full AWS access" with "Deny EC2 access", and the Production OU has "Full AWS access". As a result, Account D has all service access except EC2 and Account E and F have all service access. + + + +### Scenario 5: Allow policies at the OU-level to restrict service access + +This scenario shows how allow policies can be used to restrict access to specific services. The Test OU has an "Allow EC2 access" policy, which means only EC2 services are permitted for Account D. The Production OU maintains "Full AWS access", so Accounts E and F have access to all services. This demonstrates how more restrictive allow policies can be implemented at the OU-level while maintaining a broader allow at the root-level. + + + +### Scenario 6: Root-level deny affects all accounts regardless of lower-level allows + +This scenario demonstrates that a deny policy at the root-level affects all accounts in the organization, regardless of allow policies at lower levels. The root has both "Full AWS access" and "Deny S3 access" policies. Even though the Test OU has an "Allow S3 access" policy, the root-level S3 deny takes precedence. Account D has no service access because the Test OU only allows S3 access, but S3 is denied at the root-level. Accounts E and F can access other services except for S3 because of the explicit deny at the root-level. + +