SCP (Service Control Policies) Blocklist & Allowlist strategies | Deep Dive.

SCP (Service Control Policies) Blocklist & Allowlist strategies - Deep Dive.

Scope:

•        Intro,
•        Blocklist Strategy (Deny List)
•        Allowlist Strategy,
•        Best Practice (Hybrid Approach),
•        Review of  SCPs,
•        SCP Evaluation Logic,
•        SCP Strategies Overview,
•        Allowlist Strategy (Deny-by-default),
•        Blocklist Strategy (Allow-by-default),
•        Hybrid Strategy (Recommended in Enterprises),
•        Regional Restrictions (Common Guardrail),
•        SCP Management Best Practices,
•        Real-world Implementation Flow,
•        Visual SCP Strategy Architecture.

 Intro:

• AWS Service Control Policies (SCPs) define the maximum available permissions for IAM principals within an organization's member accounts. 

NB:

• Strategies for managing these guardrails generally fall into two categories: 

Blocklist Strategy (Deny List)

This is the default and most common approach in AWS. 

• Mechanism: Keep the AWS-managed FullAWSAccess policy attached to the root, Organizational Units (OUs), and accounts to allow all services by default.
• Implementation: twtech add custom SCPs containing explicit "Deny" statements for specific services or actions it wants to prohibit.
• Pros: Easier to maintain because you don't need to update policies every time AWS releases a new service. 
• Deny statements also support Conditions and Resource restrictions, which "Allow" statements in SCPs do not.
• Cons: Requires constant vigilance to block new risky services as they become available. 

Allowlist Strategy

This approach follows a "default deny" stance, offering the highest level of restriction. 

• Mechanism: wtech must remove the default FullAWSAccess policy and replace it with custom SCPs that explicitly "Allow" only approved services.
• Implementation: For a service to be usable, it must be explicitly allowed at every level of the hierarchy—from the organization root, through every intermediate OU, down to the member account.
• Pros: Best for high-compliance or zero-trust environments where only vetted workflows are permitted.
• Cons: Extremely high maintenance; users will be unable to use any new AWS service until twtech manually adds it to every policy in the inheritance path.

Best Practice (Hybrid Approach)

Many organizations use a combination of both:

• Use an Allowlist at the root or high-level OUs to define which major AWS services are approved for corporate use.
• Use a Blocklist (Deny statements) at more specific OUs to enforce enterprise-wide guardrails, such as restricting regions or preventing the deletion of security tools like CloudTrail.

1. Review of  SCPs

• Service Control Policies (SCPs) are organization-level guardrails that define the maximum permissions available to IAM entities (users, roles, groups) in any AWS account within an Organization.

NB:

Service Control Policies (SCPs):

• Don’t grant permissions directly.
• Filter what permissions IAM policies can grant.
• Are evaluated alongside IAM policies.
• Both must allow an action.

NB:

SCP = Permission boundary across accounts (Org, OU, or Account).

 2. SCP Evaluation Logic (When a request is made):

Policy Type	Purpose	Must Allow?
AWS Organizations SCP	Define max available permissions	✅
IAM Identity Policy	Define granted permissions	✅
Resource Policy	Optional, resource-specific control	✅ (if applicable)
Session Policy / Permission Boundary	Further limit effective permissions	✅

NB:

 If any of these denies, the action is blocked.

 3. SCP Strategies Overview

NB:

Two primary strategies are used to control access:

Strategy	Description	Typical Use Case
Allowlist (Deny-by-default)	Explicitly allow only approved services/actions; everything else is implicitly denied.	High-security or compliance environments (e.g., regulated workloads, GovCloud, PCI).
Blocklist (Allow-by-default)	Allow all AWS services except explicitly denied ones.	General-purpose accounts, development/test environments, or partial control scenarios.

4. Allowlist Strategy (Deny-by-default)

Concept

twtech defines an SCP that explicitly allows a specific subset of AWS services (e.g., EC2, S3, CloudTrail) and implicitly denies everything else.

#  twtech-Sample

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechAllowList",

      "Effect": "Allow",

      "Action": [

        "ec2:*",

        "s3:*",

        "cloudtrail:*"

      ],

      "Resource": "*"

    }

  ]

}

NB: 

Everything not listed in the Action array is denied.

 Pros

• Strong security control and predictability.
• Prevents access to new AWS services until explicitly approved.
• Ideal for highly regulated workloads.

 Cons

• High maintenance:
• every new service requires policy updates.
• May block dependencies if not tested carefully.
• Inhibits developer agility.

 5. Blocklist Strategy (Allow-by-default)

 Concept

twtech creates an SCP that denies access to specific services or operations it don’t want used (e.g., aws-portal:*, support:*, or regions not in scope).

# twtech-Sample

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechDenyCertainServices",

      "Effect": "Deny",

      "Action": [

        "aws-portal:*",

        "support:*",

        "cur:*"

      ],

      "Resource": "*"

    }

  ]

}

Pros

• Minimal maintenance effort.
• New AWS services are available by default.
• Good for innovation and flexibility.

 Cons

• Risk of accidental use of new, unapproved, or costly services.
• Can’t “pre-deny” unknown new services.

 6. Hybrid Strategy (Recommended in Enterprises)

Most mature organizations adopt a hybrid approach:

• Allowlist at the root or sensitive OU level for foundational workloads.
• Blocklist at developer/test OUs to prevent misuse.
• Combine with Tag-based IAM controls, permission boundaries, and AWS Control Tower Guardrails.

# Sample Hierarchy diagram:

 7. Regional Restrictions (Common Guardrail)

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechDenyUnsupportedRegions",

      "Effect": "Deny",

      "Action": "*",

      "Resource": "*",

      "Condition": {

        "StringNotEquals": {

          "aws:RequestedRegion": [

            "us-east-2",

            "us-west-2"

          ]

        }

      }

    }

  ]

}

NB: 

This ensures workloads only run in approved regions.

 8. SCP Management Best Practices

Category	Best Practice
Design	Start with least privilege (Allowlist for critical OUs).
Testing	Validate in sandbox OUs before applying Org-wide.
Versioning	Use descriptive Sid and version control (e.g., in Git).
Change Management	Automate SCP deployment via AWS CloudFormation StackSets or IaC pipelines.
Auditing	Regularly review SCPs via AWS Config and IAM Access Analyzer.

 9. Real-world Implementation Flow:

1. Define organizational structure (OUs).
2. Attach baseline SCPs (root-level guardrails).
3. Apply OU-specific SCPs (restrict per environment).
4. Validate via Access Analyzer & simulation tools.
5. Continuously monitor via AWS Config conformance packs.

 10. Visual  SCP Strategy Architecture with:

• OU hierarchy.
• Allowlist vs Blocklist placement.
• SCP evaluation flow.