AWS Cloud Operations & Migrations Blog

Maintain compliance using Service Control Policies and ensure they are always applied

Many of our customers manage multiple AWS accounts in AWS Organizations and utilize Service Control Policies (SCPs) to centrally manage permissions in their organization. SCPs offer central control over the maximum available permissions for every account in your organization and can be applied to an account, organization units (OUs), or the organization as a whole (root).

Administrators can use SCPs with AWS Organizations to establish controls adhered to by all IAM principals (users and roles). For more information, see Effects on permissions in the AWS Organizations User Guide, as well as Determining whether a request is allowed or denied within an account in the IAM User Guide.

Customers also have compliance that is either internal or from industry regulations, and many of those can be addressed via SCPs, such as region restrictions, user/role restrictions, services restrictions, and more. This blog post provides a solution for customers to provide that specific SCPs will be attached to OU(s) or AWS accounts, and, if they are detached, we can detect this, notify a compliance team (for example), and even conduct an automatic remediation action of reattaching the SCPs. This effectively provides a mechanism for the SCPs to be attached to our defined OU(s) and AWS accounts as planned.

Prerequisites

In order to follow the steps in this blog post, the following are required:

  • An organization in AWS Organizations with “All features” enabled in order to create and manage SCPs. For more information, see Creating and configuring an organization – AWS Organizations.
  • Access to the AWS management account in the organization, as the solution described here must be deployed in the aforementioned management account of your AWS Organizations.
  • Create a test SCP and attach it to a test OU with no AWS accounts attached in order to evaluate the solution behavior first — see Creating, updating, and deleting service control policies – AWS Organizations. This is an example SCP you can utilize that prevents member accounts in an organization from leaving it by blocking use of the LeaveOrganization API.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Remember that a deny permission always overrides an allow, so be aware of the impact and implications of SCPs that implement actions in this way, and always test thoroughly in test environments before going to production. Utilize Policy Staging OU to safely test impacting policy changes before applying them to production OUs and/or Accounts. See more on this at Organizing your AWS environment using multiple accounts.

Architecture

The solution will be running in our organization’s management account. It is composed of an Amazon EventBridge rule that keeps listening for a specific CloudTrail event “DetachPolicy” that is triggered when an SCP is detached from an OU(s) or an AWS account. This solution is configured to monitor CloudTrail events, and it listens for an action indicating that an SCP has been detached on a target OU or account.

If someone detaches the SCP from our target OU(s) or AWS accounts of enforcement, then EventBridge will capture the CloudTrail event and we’ll send an Amazon Simple Notification to our designated email addresses for a compliance audit (for example, this can be the company security team), and a trigger to an AWS Lambda will automate a remediation action of reattaching the SCP to our target OU(s)/AWS accounts.

The architecture starts with Detaching your pre-defined SCP on Organizations and that event will be captured in EventBridge, send an analertin Amazon SNS to your admin, and run a remediation Lambda to reattach the SCP.

Figure 1: Architecture diagram

  1. Create an Amazon SNS topic that will send an email notifying that the SCP was detached from our target OU(s)/AWS account. You can use the instructions in this link.
  2. Create the AWS Lambda Function below which we’ll be using later. Make sure to change the SNS Topic ARN in the code below to point to your SNS Topic that was created before.
Lambda function code:

import boto3
import json
def lambda_handler(event, context):
    # TODO implement
    print(event)
    client = boto3.client('organizations')

    # TODO check if it's needed or not
    try:
      response = client.attach_policy(
        PolicyId=event['detail']['requestParameters']['policyId'],
        TargetId=event['detail']['requestParameters']['targetId'],
      )

    except Exception as e:
      print("Something broke")
      # test e
    
    statuscode = "200" # event["statuscode"]

    if statuscode == "429":
        raise TooManyRequestsException('429 Too Many Requests')
    elif statuscode == "503":
        raise ServerUnavailableException('503 Server Unavailable')
    elif statuscode == "200":
        return '200 OK'
    else:
        raise UnknownException('Unknown error')
        sns_topic = ADD_YOUR_SNS_TOPIC_ARN
        sns = boto3.client('sns')
        response = sns.publish(
            TopicArn=sns_topic,
            Message=event["statuscode"],
            Subject='Error while running Automated SCP Detachment Remediation Lambda'
        )
        return response
    return {
      'statusCode': statuscode,
      'body': json.dumps(event["statuscode"])
      }

Then create an Amazon EventBridge rule by follow the instructions below:

Amazon EventBridge rule:

A rule in EventBridge will be created with the event pattern looking for that specific SCP and OU, Account, or Organization, and the targets will be our SCP and a remediation Lambda.

Figure 2: Amazon EventBridge rule

The EventBridge rule will have two targets:

  1. Choose the AWS Lambda function and Amazon SNS topic that you created before as targets.The Lambda function in Python that will conduct the remediation action of reattaching the SCP to our target OU(s)/AWS account.The Lambda function code runs the attach policy API from Organizations to attach our SCP to our target OU(s)/AWS account.

    If this action returns an error (e.g., due to Lambda throttling or because the SCP was already reattached via an IAM user/role), then we send an Amazon SNS email to the same topic with the error details.

    Input transformer explained in blog post.

    Figure 3: Input transformer Amazon EventBridge

  2. We’ll use the Input transformer in the “Configure input” section of the Amazon SNS target in order to make the message more human-readable.

Email received from SNS with the Input transformer with the alert:

An email will be received via Amazon SNS to the subscribers configured in the target SNS topic that we chose whenever the SCP is detached, showing which IAM principal conducted the action and also the name of the remediation Lambda that will try reattaching the SCP.

Figure 4: Email with Amazon SNS notification

Conclusion

This post described a solution that you can implement to enable a Service Control Policy to stay attached in specific OU(s) or AWS accounts in order to provide compliance standards in your company. This approach offers a powerful and an extra layer of security to organizations that need to drive their compliance standards by the use of SCPs that will remain applied and protect your environment against unauthorized operations.

About the authors

Matheus Arrais

Matheus Arrais is a Partner Solutions Architect. His focus is on multi-account strategy and management and governance services. He works closely with partners helping them to walk a successful journey within the AWS partnership and deliver the best solution for their customers. Outside work, Matheus has a passion for reading, drumming, and traveling.

Gabriel Costa

Gabriel Costa is a Partner Solutions Architect. He works with Consulting partners in their AWS partnership journey and building effective Cloud solutions for customers with a focus in management and governance tools inside AWS. Outside work Gabriel is a tech enthusiast, avid musician and a lover of all things art, philosophy and human collaboration.