Overview: AWS Service Control Policies (SCPs) are used within AWS Organizations to manage the maximum permissions for accounts within an organization. SCPs help you ensure that accounts only have access to the AWS services that are necessary for their function, thereby enhancing your security structure and minimizing the attack surface for the rogue administrators.

AWS Organizations allows enterprises to manage security settings, policies and services across AWS accounts that are grouped together in a hierarchical tree formation. One of the security features of the AWS Organizations is the service control policy (SCP), which provides the maximum permission boundary attached at the root of the AWS Organization thereby controlling all AWS account members, or to specific OUs containing AWS accounts in the AWS Organization hierarchy, or at the specific AWS account level.

The SCP and the entity being controlled must have matching permissions for the desired permissions to be allowed. Once an SCP has been enabled, permissions are allowed only if the permissions in the IAM policy and the SCP match. The types of permission policies that can be controlled by an SCP are identity-based policies for IAM users, roles, the root user in any AWS account, and resource-based policies.

NOTE: Service control policies do not affect the Management AWS Account or any service-linked roles that delegate the permissions assigned to each AWS service to carry out their assigned tasks.

Step 1: Understand AWS Organizations and SCPs

AWS Organizations: AWS Organization is an AWS service to consolidate multiple AWS Accounts into a hierarchy of OUs for the purpose of the following:
1. Simplified and Centralized Account Management

2. Consolidated Billing

3. Sharing Resources via RAM and

4. Applying SCPs to meet Governance requirements
You start with a standard AWS Account and use the same to create an Organization. This standard AWS Account that you use to create the Organization with BECOMES the Management or Master or Payer account. This Management Account can now invite other existing standard AWS accounts into the Organization or Create new AWS Accounts as MEMBER ACCOUNTS.

The Management and Members accounts may now be structured into a hierarchy using the Organization Root at the TOP and multi-level Organizational Units based on Business Units, Functions, or by Country location that can be used to group one of more AWS Member Accounts.AWS Organizations is a service that allows you to manage and govern your AWS accounts. It enables you to centrally manage billing, control access, compliance, and security across your AWS accounts.
Service Control Policies (SCPs): SCPs are policies that define the maximum permissions boundary that are available to an organization, organizational unit (OU), or the AWS account. IAM users including the Account Root Users in all the AWS Member Accounts with AdminstratorAccess as part of their Identity Policy, will be restricted by these SCP defined policies.

Step 2: Set Up AWS Organizations (If Not Already Set Up)

Sign in to the AWS Management Console using your root account.

Navigate to AWS Organizations:

Go to the AWS Organizations console at https://console.aws.amazon.com/organizations/.

If you haven’t set up AWS Organizations, follow the on-screen prompts to do so.

Create Organizational Units (OUs):

In the Organizations console, you can create OUs to group accounts that require similar restrictions. I have mine setup as shown below:

Step 3: Create a Service Control Policy (SCP)

Navigate to the SCPs Section:

In the AWS Organizations console, select Policies from the left-hand menu. If you are doing this for the first time, most of the policy types should be Disabled. Select Service Control Policies (SCPs)

Select Enable Service Control Policies

It should create a default FullAWSAccess managed policy for the entire AWS Organization with NO Restrictions to what any of the AWS Accounts can do.

Create a New Customer Managed SCP:

Click on Create policy.

Example: Restrict Access to Specific Services

Below is an example SCP that denies access to the Amazon S3 and AWS Lambda services for US-EAST-1 region:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3AndLambda",
      "Effect": "Deny",
      "Action": [
        "s3:*",
        "lambda:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Effect: This SCP denies access to S3 and Lambda, for the us-east-1 region.

Action: Defines the denial (in this case, S3 and Lambda actions).

Review and Create the SCP:

After writing the policy, click on Next, provide a name and description, review the policy, and then click Create policy. We will not attach the SCP now.

Let us now login to the Production AWS Account and ensure that we have access to S3 API Actions. I am logged in as iamadmin user with Administrator Access.

Lte us go to the Amazon S3 from the AWS Console. Try to create yourself a S3 Bucket (bucket name must be globally unique) and upload a test file to ensure that you have access to the S3 APIs. I was able to create a test bucket called 'mybucket267oa' and upload a sample picture to the bucket.

I will now log back into my Management AWS Account.

Step 4: Attach the SCP to Your Organization, OU, or specific AWS Account

Navigate to Your AWS Organizations:

Let us now attach the DenyS3AndLambda SCP to the Production Organization Unit within my AWS Organizations.

In the AWS Organizations console, go to the Accounts >> Click PROD OU >> Click Policies tab >> Attach.

Select the DenyS3AndLambda Customer Managed SCP >> Click Attach Policy

Step 5: Verify the SCP Implementation

Test the Policy:

Log in to the Production AWS account within the PROD OU (this is where we have attached the DenyS3AndLambda Customer Managed SCP.

We will now attempt to access the S3 service or Lambda that should be restricted according to DenyS3AndLambda SCP.

We can see below that access to non-allowed services (Amazon S3 Service) is denied while access to permitted services (Amazon EC2) should remain granted and unaffected.

There you have it. The DenyS3AndLambda SCP that we attached to the PROD OU, is now in effect and we don't have access to the S3 APIs.

Monitor and Audit:

Use AWS CloudTrail and AWS Config to monitor and audit access requests and actions taken in your AWS environment.

Step 6: Refine and Update SCPs as Needed

Review the SCPs Regularly:

As your organization evolves, regularly review and update your SCPs to ensure they align with your security and compliance requirements.

Add Exceptions or Adjust Policies:

If necessary, create new SCPs or modify existing ones to refine the restrictions or permissions.

Best Practices:

Least Privilege: Always start with the principle of least privilege. Only allow access to services that are essential.
Test SCPs: Test policies in a development environment before deploying them to production accounts.
Documentation: Document your SCPs and the rationale behind them for future reference and audits.
Granular Control: Use Conditions in SCPs to create more granular control, such as restricting access based on regions, VPCs, or IP ranges.

This guide should help you implement SCPs effectively in your AWS Organization, ensuring that your accounts have controlled and secure access to AWS services.

Getting Started: Restricting Access to AWS Services with AWS Service Control Policies (SCPs)