Ref: https://learn.cantrill.io/courses/1820301/lectures/41301373
DEMO: https://learn.cantrill.io/courses/1820301/lectures/41301374
AWS Organizations - Service Control Policy (SCP)
- 🔧 JSON document that restricts permissions of an organization’s MEMBER accounts
- ‼️ Does NOT GRANT any permissions!! ONLY RESTRICTS what can be granted!
- An SCP can be thought of as an account permission boundary
- ‼️ Management account is NOT affected/restricted by SCPs!!!
- Best practice: don't use management account for everyday tasks in production environments (it can't be restricted and there's higher risk of messing up)
- ‼️ Can (indirectly) restrict the root user of an account!!!
- The account root user can't be restricted inside its own AWS account…
- ❗ …But an SCP is an (external) account permission boundary → it restricts the WHOLE account, INCLUDING its root user!
- An SCP can be attached to:
- The Organization Root → SCP affects whole organization (except management account)
- An Organizational Unit (OU) → SCP affects that OU & everything contained inside
- SCPs are inherited down the organization's OU tree
- An individual member account

- By default, SCPs start by not restricting anything in the organization
- When first enabling SCPs, a
FullAWSAccess
policy is applied to the whole organization
- If you remove this policy, the implicit deny will take over → SCPs will restrict EVERYTHING in the organization (except the management account)
- Two use architectures/paradigms:
- ALLOW LIST → Block by default
- Remove default
FullAWSAccess
policy, then add SCPs that granularly select which services are allowed in the organization
- 👍 More secure
- 👎 Easier to make mistakes (e.g. allow wrong service)
- 👎 More admin overhead (if a new service is released and you need it, must update SCP to allow it)
- DENY LIST → Allow by default
- Keep default
FullAWSAccess
policy, add extra SCPs that granularly deny services
- 👎 Many services allowed by default → less secure than allow lists
- 👍 Less admin overhead (new services don't need to be allowed) → RECOMMENDED architecture
Identity/Resource Policies and SCPs Overlap

- âť—Â SCPs must overlap with IAM identity and/or resource policies to grant permission to an identity in an account
- Think of allow permissions like a Venn diagram (only grant if allowed by both)
- Remember that, by themselves, SCPs don't grant permissions
- 💡 If an SCP grants access to S3, but the identity in an account affected by the SCP doesn't have an identity policy that allows S3, OR the S3 bucket doesn't have a bucket policy that allows this access, then the identity can NOT access S3 (no matter what SCP says)
- SCPs follow “implicit DENY < explicit ALLOW < explicit DENY” paradigm
- The combination/Venn Diagram of SCPs + ID/resource policies also follows this paradigm