Ref: https://learn.cantrill.io/courses/1820301/lectures/41301373

DEMO: https://learn.cantrill.io/courses/1820301/lectures/41301374

• Summary
• Contents:

AWS Organizations - Service Control Policy (SCP)

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0600-IAM_ACCOUNTS_ORGS/00_LEARNINGAIDS/ServiceControlPolicies-1.png

• 🔧 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:
  1. The Organization Root → SCP affects whole organization (except management account)
  2. An Organizational Unit (OU) → SCP affects that OU & everything contained inside
     • SCPs are inherited down the organization's OU tree
  3. 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:
  1. 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)
  2. 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

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0600-IAM_ACCOUNTS_ORGS/00_LEARNINGAIDS/ServiceControlPolicies-2.png

• ❗ 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