Data Perimeters: Beyond the Marketing

Data Perimeters: Beyond the Marketing

Speakers: Matt Luttrell, Principal Security Engineer, AWS

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=grGZYm6F8g4

Overview

In this insightful talk, Matt Luttrell, a Principal Security Engineer at AWS, delves into the often-complex world of data perimeters in cloud environments. Moving beyond the marketing hype, Luttrell provides a pragmatic and deeply technical examination of how data perimeters function within AWS, highlighting the "sharp edges" or "complicators" that can undermine their effectiveness. His team at AWS not only owns the conceptual framework for data perimeters but also manages an internal testing platform dedicated to validating that AWS services adhere to these critical security constraints.

The core of the presentation is an output of this rigorous internal testing, offering attendees a candid look at the challenges and practical solutions for implementing robust data perimeter controls. Luttrell systematically dissects three distinct types of perimeters—identity, resource, and network—ordering them by ascending complexity. For each, he details the common pitfalls and provides actionable strategies for security engineers and architects to navigate these complexities, ensuring that data perimeters truly serve as an organizational guardrail, preventing unauthorized access and data exfiltration.

This talk is crucial for any organization operating in AWS that seeks to establish strong boundaries around its sensitive data. It addresses the fundamental need to assert ownership over specific AWS resources and restrict interactions from external entities, a capability vital for compliance, intellectual property protection, and overall cloud security posture. Luttrell's expertise, stemming from his direct involvement in AWS's internal data perimeter initiatives, offers invaluable guidance for building more secure and resilient cloud architectures.

Background

▶ Watch: Introduction to data perimeters and talk overview (0:00)

The concept of a data perimeter in AWS is designed as a coarse-grained organizational guardrail. Its fundamental purpose is to allow an organization to declare, "This part of AWS belongs to me, and I don't want anybody else talking to it." This seemingly straightforward goal, however, quickly encounters significant complexities in the dynamic and interconnected AWS ecosystem. The reality often deviates from the ideal green-rectangle boundary, revealing numerous "complicators" that challenge the integrity of these perimeters.

Luttrell introduces a helpful "triangle" mental model to illustrate the interconnectedness of data perimeter controls: identity, resource, and network. To effectively control one aspect, such as identities, an organization must implement corresponding controls across both resources (via SCPs – Service Control Policies and resource policies) and networks (via VPC endpoint policies). The presentation systematically progresses through these three perimeters in an order of ascending complexity: the identity perimeter is generally the most straightforward to implement, while the network perimeter presents the most significant challenges.

The necessity for data perimeters arises from the inherent shared responsibility model and the vast flexibility of AWS. While AWS secures the underlying infrastructure, customers are responsible for securing their data and configurations. Without robust data perimeters, an organization's data could be accessed by unauthorized identities, exfiltrated to external resources, or compromised if credentials "walk" outside the trusted network boundary. Prior work in cloud security has often focused on individual account-level controls or network segmentation, but data perimeters aim for a broader, organizational-level enforcement, ensuring that all interactions stay within a defined trust boundary. The "complicators" discussed in the talk are essentially edge cases and legitimate service interactions that, if not properly accounted for, can inadvertently create bypasses or render perimeter controls ineffective.

Key Findings

▶ Watch: Implementing the identity perimeter with SCPs (1:57)

The central findings of Matt Luttrell's talk revolve around the structured approach to implementing data perimeters in AWS and the critical awareness of their inherent "sharp edges" or "complicators." The talk identifies three primary types of data perimeters: Identity Perimeter, Resource Perimeter, and Network Perimeter, each with increasing levels of implementation complexity.

A key finding is that while the theoretical concept of a data perimeter is clear, its practical application in AWS is fraught with scenarios where AWS services or common operational patterns can unintentionally bypass or weaken the intended controls. Luttrell’s team at AWS has identified these patterns through an internal testing platform, mapping individual AWS APIs to specific complicators. This proactive discovery by AWS itself underscores the difficulty of implementing these controls correctly without detailed guidance.

Specific technical findings include:

• The aws:PrincipalOrgID and aws:ResourceOrgID condition keys are fundamental for identity and resource perimeters, respectively, allowing for organization-wide enforcement.
• aws:VPCeOrgId is presented as the more scalable evolution of aws:SourceVPC for network perimeter controls, though its adoption is still progressing across services.
• Service Principals are a recurring theme across all perimeters, as they often act on a user's behalf but operate outside the direct control of an organization's perimeter policies, requiring specific exceptions or alternative controls.
• The talk highlights that data exfiltration protection is primarily achieved through the Resource Perimeter, preventing internal identities from interacting with external resources.
• Preventing credential exfiltration (credentials "taking a walk") is the domain of the Network Perimeter, ensuring credentials only function from trusted network locations.
• Crucially, Luttrell emphasizes that many mitigations for complicators require a "shift left" approach, focusing on controlling the control plane calls (e.g., CreateTrail, CreateAuthorizer) rather than solely relying on data plane enforcement.
• AWS is actively working to simplify these challenges, providing comprehensive guidance, reference policies, and lists of service-owned resources to aid customers in implementation.

Technical Deep Dive

▶ Watch: Sharp edges and complications for identity perimeter (3:09)

Matt Luttrell meticulously breaks down the implementation details and common "complicators" for each of the three data perimeter types in AWS.

Identity Perimeter

The Identity Perimeter aims to ensure that "only my identities can access my resources." This is achieved primarily through Service Control Policies (SCPs) that utilize the aws:PrincipalOrgID or aws:PrincipalAccount condition keys. These keys restrict access to principals (users, roles) belonging to a specified AWS organization or account. For legitimate service interactions, it's crucial to include service principals in these policies, but only when they are acting on your behalf. This is managed using the aws:PrincipalAWSService context key and the aws:SourceOrgID context key, which provides protection against confused deputy attacks.

The network control for the identity perimeter involves VPC endpoint policies. These policies are vital for preventing a scenario where an attacker brings external credentials into your network and uses them to communicate with their own (external) resources. VPC endpoint policies are the only AWS control to prevent this, and they achieve it by leveraging the aws:PrincipalOrgID context key to ensure that requests traversing the VPC endpoint belong to your organization.

Complicators for the Identity Perimeter include:

• SCP Support: Not all AWS services fully support SCPs, necessitating a fallback to resource policies for those services.
• Anonymous Requests: Certain valid use cases, such as curling an S3 bucket for patching purposes, involve anonymous requests. In such cases, the aws:PrincipalOrgID cannot be applied, requiring a separate policy statement to allow anonymous access to specific resources.
• Service Principals via VPC Endpoints: Services often pre-sign requests and return them to the user, who then executes them from their VPC. These requests, made by service principals, might not work if the VPC endpoint policy doesn't explicitly allow exceptions for these interactions.

Resource Perimeter

The Resource Perimeter is designed for data exfiltration protection, ensuring that "my principles should only be able to communicate with my resources." This is enforced using SCPs with the aws:ResourceOrgID or aws:ResourceAccount condition keys, restricting interactions to resources within your specified organization or account.

Significant complicators arise here:

• AWS-Owned Resources: Many AWS services utilize resources that are physically owned by AWS accounts, not your own, but are logically part of your environment. Examples include managed policies (which reside in AWS accounts) or certain S3 buckets exposed by services. These resources often have AWS in their ARN's account ID segment or a blank account ID (common for S3 buckets). To accommodate these, organizations must exempt them from resource perimeter policies, typically by their Resource ARN. AWS provides lists of these service-owned resources to aid in this.
• Service Proxy Patterns: This is a critical class of complicators where an AWS service acts as a proxy, making calls to resources on your behalf.
• CloudTrail: When creating a CloudTrail trail, you can specify an S3 bucket that doesn't belong to your organization. CloudTrail's service principal then makes requests to this external bucket, bypassing your aws:ResourceOrgID controls because the request originates from an AWS-owned network and principle.
• API Gateway Authorizers: An API Gateway REST API can use a Lambda function in another account as an authorizer. Every request to your API will then be forwarded by API Gateway's service principal to this external Lambda, again bypassing your resource perimeter.
• SNS Subscriptions: An SNS topic can subscribe to a random HTTP endpoint on the internet. In this case, there's no SigV4 signing, and no data perimeter controls apply to the outbound communication.

Mitigations for service proxy patterns involve:

• Shifting Left: Implement preventive controls on the control plane calls themselves (e.g., CreateTrail, CreateAuthorizer) to prevent the configuration of external resources.
• Service-Specific Keys: Some services offer granular condition keys, like SNS's sns:Endpoint and sns:Protocol, to restrict valid subscription targets.
• Infrastructure as Code (IaC) Scanning: Scan IaC templates for external account IDs, bucket names, or ARNs.
• Detection and Remediation: Centrally detect problematic configurations after deployment and automate remediation, comparing resource account IDs to your organization's.

The network story for the resource perimeter is simpler: extend existing VPC endpoint policies by adding the aws:ResourceOrgID condition key. A minor caveat is that some "unsigned" requests might have aws:ResourceOrgID but lack aws:PrincipalOrgID, requiring specific policy statements.

Network Perimeter

The Network Perimeter is the most complex and is designed to "prevent your credentials from taking a walk"—meaning, if credentials are stolen and used from an untrusted network (e.g., a coffee shop), they should fail. Controls for this perimeter include aws:SourceIp and aws:VPCeOrgId (a more scalable evolution of aws:SourceVPC) in SCPs and resource policies.

Complicators for the Network Perimeter:

• Service Role Credentials (e.g., Lambda): When a Lambda function assumes a role and executes code (e.g., putting an object to S3), the execution occurs from Lambda's internal AWS network, not your VPC. The source IP is unknown and dynamic, making aws:SourceIp controls ineffective.
• Mitigations:
• Enforce VPC Attachment: For all your compute (e.g., Lambda, EC2), use service-specific condition keys like aws:vpc-id or aws:subnet-id to ensure they are always launched within your VPC. Exceptions may be needed for logging requests that still traverse AWS's internal network.
• Exempt Inaccessible Roles: If a service role's credentials are not accessible to you (i.e., you can't pull them out and use them elsewhere), you can exempt these roles, as the credentials cannot "walk."
• Forward Access Sessions (FAST): Services like S3 can use your credentials to impersonate you and call other services (e.g., KMS) on your behalf. While your public IP is propagated downstream (making it logically appear as your request), the aws:VPCeOrgId is not propagated today.
• Mitigation: Create an exception in your network perimeter policy for requests made aws:ViaAWSService, effectively trusting AWS's internal network for these sessions.
• EFS ENI Communication: When an EFS file system is created, it drops an Elastic Network Interface (ENI) in your VPC. Data plane communication then occurs over this ENI, meaning EFS sees the private IP address of the ENI. Since private IPs shouldn't be hardcoded in policies, this requires a different approach.
• Mitigation: Exempt relevant EFS actions entirely from the network perimeter, as communication is guaranteed to be within your VPC via the ENI. This applies to other "database-like" services as well.
• Pre-signed URLs from Service Principals: When retrieving Lambda function code, Lambda pre-signs an S3 GetObject request to an AWS-owned bucket. The resulting pre-signed URL effectively allows the recipient to act as the service principal. If these pre-signed URL creds are compromised, the request originates from an AWS-owned resource, and the network is potentially not yours.
• Mitigation: There is "no real great mitigation" for this. The recommendation is to limit access to the specific APIs that can generate these pre-signed URLs from service principals.

Demo / Proof of Concept

▶ Watch: Handling AWS-owned resources in resource perimeter (4:33)

While Matt Luttrell's presentation did not feature a live demonstration or a hands-on proof of concept, the talk itself is presented as a direct output of AWS's sophisticated internal testing platform. This platform is continuously used to validate that individual AWS services and their APIs adhere to the stringent data perimeter constraints defined by AWS. Essentially, the "proof of concept" is the ongoing, large-scale validation work performed by Luttrell's team, with the insights shared in the talk serving as the practical findings and guidance derived from that extensive testing.

Defensive Implications

▶ Watch: CloudTrail's service principle writing to external buckets (6:07)

Implementing data perimeters effectively requires a strategic and informed approach. Defenders should consider the following implications and recommendations:

1. Phased Rollout: While the talk orders perimeters by complexity (Identity, Resource, Network), Luttrell acknowledges that some organizations might prioritize differently based on their risk profile. For instance, the Network Perimeter is often popular to implement first due to its value in preventing credential exfiltration. Regardless of the order, a phased rollout is crucial.
2. Scoping Strategies:

• Inclusion Tagging: Apply data perimeter controls to specific, sensitive principles or resources using tags.
• Workload-Specific Scoping: Leverage context keys like ec2:SourceInstanceARN to apply controls only to specific workloads (e.g., EC2 instances), simplifying the application of network perimeter controls when compute is known to be VPC-attached.
• OU/Account Scoping: Roll out controls incrementally, starting with a sandbox organization or account before expanding.

1. Greenfield Approach: For new AWS organizations, the most successful strategy is to implement data perimeter controls from day one. This ensures that developers build with these guardrails in place from the outset, minimizing retrofitting challenges.
2. Establish an Exception Process: Given the numerous "complicators" and legitimate business needs, a well-defined exception process is essential. Developers will inevitably encounter scenarios where standard perimeter controls interfere with valid workflows, and a streamlined process for requesting and reviewing exceptions is vital for operational agility.
3. Leverage AWS Guidance and Resources: Luttrell explicitly shares critical resources developed by his team:

• Complicator Guidance: A comprehensive mapping of individual AWS APIs to the identified complicators. This resource is invaluable for discovering potential bypasses without having to perform extensive research.
• Data Perimeter Policies: A collection of working policy examples that demonstrate how to incorporate the discussed context keys and exceptions into functional policies.
• Service-Owned Resources: A definitive list of resources (especially S3 buckets) owned by AWS services that need to be exempted from aws:ResourceOrgID policies.
• Trust AWS's Work: Luttrell encourages defenders to use this guidance, stating that much of the heavy lifting for discovery and policy formulation has already been done by AWS.

1. Validation and Testing: While challenging, validating the effectiveness of data perimeter controls is critical. Organizations should consider building internal test harnesses, similar to what AWS uses, to simulate various scenarios and confirm that controls are working as intended. Alternatively, placing "faith" in the well-vetted AWS-provided policy examples can be a starting point.
2. Awareness of Policy Size Limits: Although AWS has recently doubled SCP size limits, complex data perimeter policies, especially with numerous exceptions, can still approach these limits. Defenders should be aware of this constraint and anticipate the need for more compact policy abstractions in the future.
3. Understand Multi-Cloud Portability (Limitations): For multi-cloud environments, it's acknowledged that data perimeter concepts are still evolving, and portability between cloud providers (e.g., AWS and GCP) is not a current focus. Defenders should plan for distinct implementations in each cloud.
4. Proactive Control Plane Enforcement: For service proxy patterns, shift focus from reactive data plane monitoring to proactive control plane restrictions. This means preventing the configuration of external resources during the Create or Update API calls.

By integrating these defensive implications, organizations can move beyond a superficial understanding of data perimeters to build truly resilient and secure cloud environments.

Key Takeaways

• Data perimeters are crucial organizational guardrails in AWS, but their implementation is complex. They aim to restrict identities, resources, and network traffic to within an organization's defined boundaries.
• Three distinct perimeter types exist: Identity, Resource, and Network, with ascending complexity. Each requires specific AWS IAM condition keys (e.g., aws:PrincipalOrgID, aws:ResourceOrgID, aws:VPCeOrgId) for enforcement.
• "Complicators" (sharp edges) are common and can bypass perimeter controls. These often involve AWS service principals acting on your behalf, AWS-owned resources, or specific network interaction patterns like Forward Access Sessions.
• Effective mitigation often requires "shifting left" to control plane calls. Instead of only focusing on data plane traffic, prevent the configuration of problematic external resources at the API call level (e.g., CreateTrail).
• AWS provides extensive guidance, reference policies, and lists of service-owned resources. These resources are vital for navigating the complexities and should be leveraged to avoid redundant discovery efforts.
• A greenfield approach or a robust exception process is essential for successful adoption. Starting new organizations with perimeters in place or having a clear, managed process for exceptions helps integrate these controls into development workflows.

About the Speaker(s)

Matt Luttrell is a Principal Security Engineer at AWS. In this role, he plays a pivotal part in shaping AWS's security posture, specifically owning the concept and implementation of data perimeters. His team is also responsible for an internal testing platform that rigorously validates the adherence of various AWS services to data perimeter constraints. This deep involvement at the architectural and testing levels makes him a leading expert on the practical challenges and solutions for securing data within the AWS ecosystem.