Building a Data Perimeter with Resource Control Policies

Ask most AWS teams how they stop data from leaving the organization and you will hear a list of controls that all live on the identity side of the equation: least-privilege policies, permission boundaries, service control policies that cap what principals in the organization can do. These are necessary, but they share a blind spot. They govern the identities you know about. They say nothing about a request to your resources from an identity you do not control, using credentials that leaked, from a principal in someone else’s account.

That is the gap Resource Control Policies were built to close. Where a service control policy sets a ceiling on what your principals can do, a resource control policy sets a ceiling on what anyone can do to your resources, regardless of whose credentials they hold. Together, the two form the enforcement backbone of a data perimeter: a durable boundary that only trusted identities, operating from trusted networks, can reach your trusted resources. For a security team, this is one of the most significant additions to the AWS authorization model in years, and it is still underused.

The problem SCPs could never solve

Service control policies only bind your own principals. An SCP is an organization-level guardrail that limits the maximum permissions of identities within your organization. It is genuinely powerful, but its scope is defined by membership: it can only ever restrict principals that belong to the accounts it governs. If a request to your S3 bucket comes from a principal outside your organization, the SCP has nothing to say about it, because that principal was never in scope.

Resource policies exist, but they do not scale as a control. You can attach a policy to an individual bucket, key, or queue that restricts access, and disciplined teams do. The trouble is coverage. A control that must be applied correctly to every resource, in every account, forever, is a control that will eventually be missed on the one resource that matters. Per-resource policies are a tool, not a perimeter, because a perimeter cannot have gaps and manual application always produces gaps.

Leaked credentials expose the gap immediately. The scenario that makes this concrete is credential leakage. An access key ends up in a public repository, a log, or an attacker’s hands. Least-privilege scoping limits what that key can do, which helps, but it does not answer the more fundamental question: should a request bearing those credentials, arriving from an untrusted network or an unexpected principal, ever be honored against your data at all? Without a resource-side ceiling, the answer defaults to yes as long as the identity policy permits it.

What a resource control policy does

It sets a maximum permission on resources, organization-wide. A resource control policy is applied at the organization or organizational-unit level, like an SCP, but it constrains access to the resources in those accounts rather than the actions of the principals in them. It becomes an outer boundary that no resource-based policy or identity policy can exceed. Where an SCP answers “what is the most my principals may do,” an RCP answers “what is the most anyone may do to my resources.”

It applies centrally, so coverage is inherited, not applied. The decisive advantage over per-resource policies is that an RCP attaches once at the organizational level and governs every applicable resource in scope automatically, including resources created tomorrow by a team that has never heard of the policy. This is what turns a good intention into a perimeter: new resources are born inside the boundary instead of needing to be manually enrolled into it.

It composes with SCPs rather than replacing them. The two policy types are complementary halves of the same idea. SCPs keep your principals inside their intended envelope; RCPs keep your resources reachable only from inside the trusted boundary. Neither alone is a data perimeter. Together they enforce the property you actually want, which is that trusted identities, and only trusted identities, can reach your data.

A concrete data-perimeter rule

Start with the identity perimeter on your data stores. A foundational RCP enforces that only principals from your own organization may access your storage, denying any request whose calling principal does not belong to the organization. Expressed against a service like S3, the intent is direct: deny access unless the requester is part of the organization, with a carefully considered exception for the AWS services that legitimately act on your behalf.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceOrgIdentityPerimeter",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "o-exampleorgid"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

Read the conditions carefully, because they carry the safety. The organization identifier condition is what draws the boundary, denying any principal that is not part of your organization. The service-principal condition is the pressure valve that prevents the policy from breaking the AWS services that access your resources on your behalf, such as logging and backup integrations. The variants that tolerate a missing key matter too, because an overly strict policy that denies on absence can lock out legitimate access in ways that are painful to diagnose.

Layer the network perimeter next. Once the identity boundary holds, the same mechanism extends to networks: deny access to your resources unless the request arrives from your known networks or through your organization’s private connectivity, with exceptions for the trusted service paths. The result is a boundary defined by the intersection of trusted identity and trusted network, which is precisely the definition of a data perimeter.

Deploying without breaking production

Model the blast radius before you enforce. The failure mode of any deny-by-default boundary is the legitimate access path nobody remembered. Cross-account analytics, a partner integration, a managed service that reaches in from outside the expected scope: each is a landmine. Before enforcing, mine your access logs to enumerate who and what actually touches the resources in scope, so the exceptions are discovered in analysis rather than in an outage.

Roll out in stages, narrow scope first. Apply the policy to a single non-critical organizational unit before widening it, and expand only after a period of clean operation. The central application that makes RCPs powerful also makes a mistake widely felt, so the discipline of a staged rollout is not optional. The goal is to reach full coverage without ever having caused a surprise.

Instrument for the denies you did not predict. Enforcement is not the end of the project. Access denials attributable to the perimeter are your richest source of truth about paths you did not know existed, some legitimate and some hostile. Monitoring those denials tells you whether the boundary is too tight, correctly tight, or actively repelling something it should.

The takeaway

A data perimeter is one of those controls whose value is invisible on a good day and decisive on a bad one. Most of the time it simply denies requests that were never going to come. On the day a credential leaks, a role is assumed by the wrong party, or an integration is misconfigured, it is the difference between a contained non-event and a disclosure. Resource Control Policies are what finally make that boundary enforceable at organization scale, without the coverage gaps that doomed the per-resource approach.

The teams that benefit will be the ones that treat the perimeter as infrastructure: modeled carefully, rolled out in stages, and monitored continuously. Applied that way, an RCP turns a leaked credential from a breach into a log entry, which is exactly what a perimeter is supposed to do.

---

CloudDefender maps the real access paths to your AWS resources and flags where an organization-wide data perimeter would hold or leak, so you can enforce Resource Control Policies with the exceptions already known rather than discovered in an outage.