Data Perimeter – Segregating AWS accounts and data

In large AWS environments, resources and users are sometimes segmented into units within an organization. This allows access and usage to be segregated. However, it is difficult to effectively control all resources at the organizational level. Data perimeter allows restrictions to be implemented at the organization level. This reduces the impact of compromised AWS accounts or misconfigurations.

This article briefly explains different policies that implement a data perimeter, illustrates them with examples, and defines the current limitations of these policies.

Article is also available in french 🇫🇷

Multi-tenant AWS architecture

For service segmentation purposes, an AWS architecture can be "multi-tenant,” meaning it is composed of several AWS accounts grouped into an organization.

Below is an example of a multi-tenant architecture:

Each AWS account is part of the organization and is structured into Organizational Units (OUs). A Management account allows the organization to be managed. Best practices for managing the organization’s Management account are detailed here

An AWS account is defined by a root account. This account is responsible for its resources and related billing. An AWS account is distinct from IAM accounts, which allow AWS access (AWS console, EC2 instance, etc.) but remain linked to an AWS root account.

The organization’s AWS console is available here. Also, the following AWS CLI command allows you to check whether your account is part of an organization (you must have the appropriate permissions):

$ aws organizations describe-organization

{
    "Organization": {
        "Id": "o-ajdtrvupik",
        "Arn": "arn:aws:organizations::[REDACTED]:organization/o-ajdtrvupik",
        "FeatureSet": "ALL",
        "MasterAccountArn": "arn:aws:organizations::[REDACTED]:account/o-ajdtrvupik/[REDACTED]",
        "MasterAccountId": "[REDACTED]",
        "MasterAccountEmail": "[REDACTED]@acceis.fr",
        "AvailablePolicyTypes": [
            {
                "Type": "SERVICE_CONTROL_POLICY",
                "Status": "ENABLED"
            }
        ]
    }
}

In the absence of the appropriate permissions, the presence of the predefined role AWSServiceRoleForOrganizations in IAM tells us that our account is part of an organization:

What is Data Perimeter?

According to Amazon:

A Data perimeter is a set of Guardrails permissions in your AWS environment that you use to ensure that only your trusted identities access trusted resources from the intended networks. Data perimeter permissions are designed to serve as permanent boundaries to protect your data across a wide range of AWS accounts and resources. These enterprise-wide permissions do not replace existing granular access controls. Rather, they help improve your security strategy by ensuring that all users, roles, and resources in AWS Identity and Access Management (IAM) adhere to a set of defined security standards.

The Data perimeter authorizes access based on:

• trusted identities: IAM principals in our AWS organization
• trusted resources: resources in our organization
• trusted network: VPC or on-premises network of our organization

Summarized in the following diagram:

The Data perimeter is set up using permission guardrails. The following three AWS capabilities are used:

• Service Control Policies (SCP): Policies defining deny or allow policies at the organization level on AWS accounts.
• Resource control policies: Policies that allow restrictions on organization resources to control access to them.
• VPC endpoint policies: Policies that attach to VPC endpoints to control which actions and resources can be accessed using a VPC endpoint. These policies will not be detailed in this article because they are configured at the account level and not at the organization level, unlike the previous two.

What threat scenarios should you protect against?

The goal is to prevent the use of and access to our resources outside the organization. External access can occur in the following cases:

• Theft or compromise of AWS credentials that could be reused by external attackers;
• Misconfigurations.
  The goal is also to restrict account access to only the organization’s resources.
  The following scenario is possible:
• A company uses AWS to host an application architecture, which includes a development zone and a production zone.
• On AWS, this manifests as an AWS organization with a Management account and two OUs, a development unit and a production unit. Each of these OUs contains several AWS accounts that are members of the organization.
• The development unit must be able to make resources available to the production unit (S3 buckets, for example), but not be able to expose resources outside this framework.

The purpose of the Data perimeter in this scenario is to limit data leakage in the event of misconfiguration or compromise of AWS credentials originating from the development unit.

Service Control Policies (SCP)

SCPs are a type of organizational policy that allows you to manage permissions within that organization.
A user’s effective permissions are the intersection between what is not restricted by SCPs at the organizational level and the permissions allowed via IAM on the AWS account.
SCPs can be attached at different levels of the organization and are evaluated as follows:

• An explicit service authorization must be present at each level of the organization tree: on the root account, the OUs, and finally on the AWS member account.
• An explicit prohibition must not be present in the tree: A prohibition in an OU will impact all accounts in that OU despite any explicit authorizations at their level.
• Finally, the account’s IAM permissions must authorize the action.

AWS provides more detailed information on SCP assessment.
However, actions or entities cannot be restricted by SCPs such as Management account.

By default, an account that is not part of the Management account does not have the rights to list SCPs:

$ aws organizations list-policies --filter SERVICE_CONTROL_POLICY --profil audit

An error occurred (AccessDeniedException) when calling the ListPolicies operation: You don't have permissions to access this resource.

This is because the organizations:ListPolicies permission is missing.
A Management account can therefore list the SCPs attached to a particular OU:

$ aws organizations list-policies-for-target --target-id <ou_id_ou> --filter SERVICE_CONTROL_POLICY --profil orga

{
    "Policies": [
        {
            "Id": "p-ji4vxdoi",
            "Arn": "arn:aws:organizations::[REDACTED]:policy/o-ajdtrvupik/service_control_policy/p-ji4vxdoi",
            "Name": "Allow S3 & list IAM",
            "Description": "grant full access to S3 bucket and allow to list IAM permissions of user",
            "Type": "SERVICE_CONTROL_POLICY",
            "AwsManaged": false
        }
    ]
}

The SCP configured here is as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "iam:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "forbidIAMCreation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser"
      ],
      "Resource": "*"
    }
  ]
}

This can be understood as follows:

• Allows all actions with the s3 and iam services;
• Explicitly prohibits all actions to create a user via iam.

In fact, if an attempt is made to create a user, the following error is returned:

In the absence of explicit permissions, services other than iam and s3 are not allowed. For example, it is not possible to list EC2 instances:

An SCP that provides additional security consists of restricting the IP addresses from which the account can perform AWS actions:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "NotIpAddress": {
        "aws:SourceIp": [ // Company exit IP
          "x.x.x.x",
          "x.x.x.x"
        ]
      }
    }
  }
}

However, SCPs have their limitations, as we will see in the next chapter.

Resource Control Policies

Why are other policies needed in addition to SCPs?
Let’s imagine that we want to prevent data leaks. For business reasons, developers need to be able to create S3 buckets, but with the following constraints:

• Access to S3 buckets must be from an organization account.
• Access must be from an organization IP address.

SCPs can be applied to AWS accounts or OUs, but not to resources such as S3 buckets. This is because, although the S3 bucket is created by a specific account, the restrictions affecting that account do not apply to it. If an account is external to the organization (or unauthenticated), we cannot apply SCPs to it. Access will therefore be allowed if the S3 bucket is misconfigured.
Resource Control Policies (RCP) are a type of organization policy that allow you to restrict permissions on an account’s resources.

These policies apply in the same way as SCPs, with restrictions on an OU or the root of the organization affecting the entire tree.

In our scenarion, an AWS account in an organization, for example, a developer account, can create an S3 bucket that is publicly accessible:

The Bucket policy allows read access to everyone:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::open-bucket-47684541374684"
        },
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::open-bucket-47684541374684/*"
        }
    ]
}

Bucket policies are a type of resource-based policies that are managed directly by the account and attach to specific resources such as S3 buckets.

In the absence of RCPs, anyone can then list the Bucket and access the files (the --no-sign-request option of the cli allows you to make the request without authentication):

$ aws s3 ls s3://open-bucket-47684541374684 --no-sign-request
2025-04-11 15:15:21         20 open-file.txt
$ aws s3 cp s3://open-bucket-47684541374684/open-file.txt /tmp/ --no-sign-request
download: s3://open-bucket-47684541374684/open-file.txt to /tmp/open-file.txt

The following RCP restricts operations on S3 buckets, unless accessed from an account in the organization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-[REDACTED]"
        }
      }
    }
  ]
}

Once applied, the previous requests are no longer possible:

$ aws s3 ls s3://open-bucket-47684541374684 --no-sign-request

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

The combination of different policies (RCP and SCP) is therefore very effective for controlling data exposure within an organization. However, Resource control policies are not supported by all resources.

The following services are supported:

• Amazon S3
• AWS Security Token Service
• AWS Key Management Service
• Amazon SQS
• AWS Secrets Manager

Unfortunately, this only applies to a few services.

Edge case

Presigned URL

If a Resource control policy is applied to the Buckets of an account to allow access only from accounts in our organization, and only permissions on AWS S3 are allowed (via SCP), is it still possible to share data from an S3 Bucket with a third party that is not part of the organization?

Yes, via presigned URLs:

Access is then possible for a third party:

$ curl "https://open-bucket-70[REDACTED].s3.eu-west-3.amazonaws.com/open-file.txt?response-content-disposition=inline&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Security-Token=IQo[REDACTED]&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIA[REDACTED]%2F20250513%2Feu-west-3%2Fs3%2Faws4_request&X-Amz-Date=20250513T081859Z&X-Amz-Expires=720&X-Amz-SignedHeaders=host&X-Amz-Signature=21de1ac6e[REDACTED]"
My S3 file content!

Why does this happen? Presigned URLs use AWS account identifiers. Accessing a presigned URL is therefore equivalent to using the account that created it; access is therefore authorized since it is part of the organization and the SCP and RCP allow it.

Hopefully, the SCPs implemented by the organization therefore apply. If an IP restriction is in place, it will be effective.

Shared resources and external targets

AWS lists several cases of resources that cannot be restricted by conditions such as aws:ResourceOrgID:

• Amazon Machine Images (AMIs)
• Amazon EBS Snapshots
• Amazon RDS Snapshots
• AWS Resource Access Manager (AWS RAM)
• Amazon CloudWatch Logs Subscription Filters
• Amazon EventBridge Targets

The above resources allow data to be shared with external accounts without allowing policies to be applied, as with S3 Buckets. For example, for an EBS snapshot:

In these cases, the corresponding features must be restricted by SCP, and then an exception must be created for a privileged IAM account.

Reference

• AWS – Blog Post Series: Establishing a Data Perimeter on AWS
• AWS – Terminology and concepts for AWS Organizations
• AWS Samples – Data Perimeter Policy Examples
• AWS – Service control policies
• AWS – SCP evaluation
• AWS – Resource control policies
• Hacking The Cloud – AWS Organizations Defaults & Pivoting