Establishing a Data Perimeter on AWS

Establishing a Data Perimeter on AWS

Speakers: Liam Wadman, Solutions Architect, AWS Identity; Tatyana Yatskevich, Solutions Architect, AWS Identity

Conference: RSAC 2024

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

Overview

In an era where data is considered the "new oil," its protection is paramount for businesses across all sectors. This talk, delivered by Liam Wadman and Tatyana Yatskevich, Solutions Architects with AWS Identity, delves into the critical need for establishing robust security boundaries around an organization's most valuable asset: its data. They introduce the concept of a data perimeter on AWS, a policy-driven framework designed to prevent unauthorized data movement and access in a rapidly evolving cloud landscape.

The session addresses the inherent challenges of securing modern, distributed IT environments, where traditional network-centric security models fall short. As organizations embrace cloud services, SaaS applications, and hybrid workforces, the definition of a "corporate environment" becomes fluid, complicating data loss prevention and access control. The speakers highlight the difficulty of scaling manual permissions management in large organizations and the risks associated with delegated administrative access.

This article explores how AWS customers can leverage native AWS policy types to define explicit organizational boundaries, ensuring that only trusted identities can interact with trusted resources from expected networks. The framework aims to establish "security invariants" that deny access regardless of misconfigurations or malicious intent, serving as a critical coarse-grained container around the granular principle of least privilege. The discussion provides practical, production-grade policy examples, using a generative AI workload as a concrete case study.

Background

▶ Watch: Introduction and the critical value of data (0:00)

The evolution of enterprise security has seen a significant shift from the well-defined, on-premises network perimeters of the past to the highly distributed and API-driven environments of today. Historically, organizations relied on a DMZ (Demilitarized Zone), fortified with firewalls, DLP (Data Loss Prevention) appliances, WAFs (Web Application Firewalls), and proxies to segregate internal trusted networks from the untrusted internet. This model, while effective for its time, struggled with the rise of internal threats and the "blanket trust" often afforded to internal systems.

The advent of Software as a Service (SaaS) marked the first major disruption. Companies began outsourcing core applications like CRM and HR software to cloud providers, introducing a new, external security perimeter. Early SaaS security often relied on basic username/password authentication, with more advanced options like SAML (Security Assertion Markup Language) and IP allow lists becoming available later. This created a bifurcated security model, with on-premises and cloud assets requiring separate, often inconsistent, protection strategies.

Today's landscape is even more complex, characterized by hybrid cloud deployments, extensive SaaS footprints, and intricate business-to-business (B2B) integrations. These integrations, often relying on OAuth or other trust relationships, further blur the lines of the traditional perimeter. The speakers emphasize that the core challenge is securing API-driven assets – services like Amazon S3 buckets, Amazon DynamoDB tables, and the AWS Management Console – which do not conform to traditional network security paradigms. Unlike servers with distinct IP addresses where firewalls can control traffic to specific ports, API endpoints are shared across many customers. A single IP address might represent a vast number of S3 buckets, making IP-based filtering at the network edge insufficient for granular resource control. This fundamental difference necessitates a new approach to defining and enforcing security boundaries.

Furthermore, the scale of modern cloud operations, especially within large AWS Organizations, makes centralized, manual permissions management impractical. The delegation of administrative tasks to various teams and business units, while necessary for agility, introduces a risk of misconfigurations that could inadvertently expose sensitive data. This confluence of factors — the shift to API-driven services, the complexity of hybrid and multi-SaaS environments, and the challenges of delegated administration — underscores the urgent need for a robust, scalable, and policy-driven framework like the data perimeter.

Key Findings

▶ Watch: Core challenge 1: Ensuring employee-only access to assets (2:50)

The core contribution of this talk is the introduction and detailed explanation of the data perimeter framework on AWS. This framework is defined as a set of permissions guard rails that establish an organizational boundary around an organization's AWS assets using native AWS policy. Its primary goal is to prevent communication between an organization's AWS assets and those that do not belong to it, and vice versa.

Crucially, the speakers clarify that a data perimeter is not a replacement for the principle of least privilege. Instead, it acts as a coarse-grained container or an outer layer of defense. While least privilege ensures that individuals and services only have the permissions absolutely necessary for their tasks, the data perimeter provides security invariants – overarching rules that deny access regardless of specific, potentially misconfigured, least privilege grants. This means even if an identity is accidentally or maliciously granted overly permissive access, the data perimeter policies can still prevent unauthorized data movement or access outside the defined organizational boundary.

The data perimeter framework is broken down into three interdependent sub-perimeters, each with two associated control statements:

1. Identity Perimeter: Focuses on who can access resources.

• Only my trusted identities can access my resources: Ensures that IAM roles and users belonging to the organization can only interact with the organization's own resources.
• Only trusted identities can access my network: Restricts the use of credentials within the organization's network to identities belonging to the organization, preventing the use of external or compromised credentials from within the corporate network.

1. Resource Perimeter: Focuses on what resources can be accessed.

• Only my trusted resources can be accessed by my identities: Guarantees that the organization's IAM roles and users can only access resources owned by the organization.
• Only trusted resources can be accessed from my networks: Ensures that even from within the organization's networks, only its own resources can be reached.

1. Network Perimeter: Focuses on where access originates from.

• Only expected networks can be used by my identities: Limits the use of the organization's IAM roles and users to predefined trusted AWS networks (VPCs) or public IP address ranges.
• Only expected networks can be used to access my resources: Specifies that the organization's resources can only be accessed from its designated trusted networks.

To implement these control statements, the framework leverages three primary AWS policy types:

• VPC Endpoint Policy: Controls traffic originating from within an AWS VPC to AWS API services, without traversing the public internet.
• Resource-Based Policy: Attached directly to specific AWS resources (e.g., S3 buckets, KMS keys) to control access to those resources.
• Service Control Policy (SCP): Applied at the AWS Organizations level, these policies enforce maximum permissions for all IAM identities (roles, users, and even the root account) within member accounts of the organization.

A critical enabler for this framework is AWS Organizations, which allows for the logical grouping and management of multiple AWS accounts. The organization's unique ID (o-xxxxxxxxxx) becomes a powerful condition key in IAM policies (aws:PrincipalOrgID, aws:ResourceOrgID, aws:SourceOrgID), enabling the explicit definition of trust boundaries based on organizational ownership.

Technical Deep Dive

▶ Watch: Core challenge 2: Preventing data movement outside corporate environment (4:50)

Implementing a data perimeter on AWS involves a strategic application of VPC Endpoint Policies, Resource-Based Policies, and Service Control Policies (SCPs), often in conjunction with specific IAM condition keys that reference an AWS Organization ID. The speakers detail how these policies work together to enforce the six control statements across the Identity, Resource, and Network Perimeters.

Policy Types in Detail

1. VPC Endpoint Policy:

• Purpose: These policies control access to AWS services from within a Virtual Private Cloud (VPC) via a VPC endpoint. VPC endpoints allow private connectivity to AWS services without requiring an internet gateway, NAT (Network Address Translation) device, or VPN connection.
• Application: They are attached to the VPC endpoint itself.
• Data Perimeter Use: Primarily used to enforce the statements "Only my trusted identities can access my network" and "Only trusted resources can be accessed from my network." For example, a VPC endpoint policy could deny access to an S3 bucket if the calling principal is not part of the organization, or if the target S3 bucket is outside the organization. This policy acts as an egress control, ensuring that traffic leaving your VPC via the endpoint adheres to organizational boundaries.

1. Resource-Based Policy:

• Purpose: These policies are attached directly to specific AWS resources that support them, such as Amazon S3 buckets, AWS KMS keys, Amazon DynamoDB tables, and Amazon SQS queues. They define who or what (principals) can access the resource and what actions they can perform.
• Application: Defined within the resource configuration itself (e.g., S3 bucket policy).
• Data Perimeter Use: Critical for enforcing "Only my trusted identities can access my resources" and "Only expected networks can be used to access my resources." A key aspect is the ability to enable cross-account access for legitimate business needs while simultaneously preventing unintended external access. This is achieved by using the aws:PrincipalOrgID condition key to restrict access to principals belonging to the specified AWS Organization. For AWS services acting on behalf of an organization (e.g., AWS CloudTrail logging events to S3), the aws:SourceOrgID condition key ensures that the service request originates from within the organization.

1. Service Control Policy (SCP):

• Purpose: SCPs are powerful organizational policies managed within AWS Organizations. They define the maximum permissions that can be granted to any IAM user, IAM role, or even the AWS root account user within any member account of the organization. They do not grant permissions; rather, they filter and restrict what permissions can ever be effective.
• Application: Applied at the Organization Root, Organizational Unit (OU), or individual account level within AWS Organizations.
• Data Perimeter Use: SCPs are instrumental in enforcing "Only my trusted resources can be accessed by my identities" and "Only expected networks can be used by my identities." They act as a top-level guardrail, ensuring that no identity within the organization can perform actions that violate the data perimeter, even if a resource-based policy or identity-based policy might otherwise permit it. Condition keys like aws:ResourceOrgID (to ensure identities only access resources within the organization) and network-specific conditions like aws:SourceVpc or aws:SourceIp (to restrict identity usage to trusted networks) are commonly employed.

Generative AI Workload Example

To illustrate the practical application, Tatyana walked through a simplified generative AI architecture comprising deep learning training and inference phases. The training phase uses curated data stored in an Amazon S3 bucket, while the inference phase utilizes Amazon Bedrock foundational models.

Threat Scenario 1: Unintentional External Access to Training Data

• Problem: A data owner might unintentionally misconfigure an S3 bucket policy, granting external access to highly sensitive training data (e.g., PII, financial information).
• Data Perimeter Control: Resource-based policy on the S3 training data bucket.
• Logic: A Deny statement is added to the bucket policy that prevents access if the aws:PrincipalOrgID (the ID of the organization to which the calling principal belongs) does not match the organization's ID. This ensures only identities from the organization can access the bucket.
• AWS Service Exception: For AWS services like CloudTrail that need to write logs to the S3 bucket, a separate Deny statement is used with the aws:SourceOrgID condition key. This ensures that when an AWS service accesses the resource, it does so on behalf of the organization and the request originates from within the organization.

Threat Scenario 2: Internal Threat Actor Training on External Data

• Problem: An internal threat actor configures the AI model to train on an external, non-corporate S3 bucket, potentially leading to poisoned output or data exfiltration to an untrusted environment.
• Data Perimeter Control: Service Control Policy (SCP) applied to the relevant IAM roles used by the AI model.
• Logic: An SCP is deployed across the organization that includes a Deny statement for S3 actions (e.g., s3:GetObject) if the aws:ResourceOrgID (the ID of the organization that owns the target resource) does not match the organization's ID. This prevents any identity within the organization from accessing S3 buckets outside of the organization's control. This effectively creates a "resource perimeter" for identities.

Threat Scenario 3: Access from Untrusted Networks (Leaked Credentials)

• Problem: Developers managing AI models might accidentally leak their credentials into public code repositories. If these credentials are then used from an unauthorized network, sensitive resources like Amazon Bedrock models could be accessed.
• Data Perimeter Control: Service Control Policy (SCP) applied to the relevant IAM roles or users.
• Logic: An SCP is implemented that includes a Deny statement for relevant service actions (e.g., bedrock:*) if the aws:SourceIp (the public IP address of the request origin) is not within the organization's defined trusted public CIDR ranges, or if aws:SourceVpc (the ID of the VPC from which the request originates) is not one of the organization's trusted VPCs. This ensures that corporate credentials can only be used from expected and controlled network environments. Exceptions might be necessary for specific AWS services that operate from AWS-managed networks.

These examples highlight how the different policy types, especially when combined with organization-specific condition keys, create a comprehensive set of guard rails that are difficult to bypass, even with misconfigured individual permissions.

Demo / Proof of Concept

▶ Watch: Traditional perimeter security model in the pre-cloud era (7:00)

While not a live demonstration, Tatyana Yatskevich walked through a practical application of the data perimeter framework using a simplified generative AI workload architecture. This walkthrough served as a proof of concept for how the described policies would be implemented to address specific threat vectors.

The sample architecture depicted two phases: deep learning training and inference.

1. Training Phase: Involves feeding a model with curated data stored in an Amazon S3 bucket.
2. Inference Phase: A human or machine interacts with a GenAI application (e.g., a chatbot), sending prompts to the model and receiving responses. The talk specifically mentioned Amazon Bedrock for leveraging managed foundational models.

For this architecture, three common threat scenarios were analyzed, and corresponding data perimeter controls were outlined using AWS policy examples:

• Scenario 1: Data owner granting external access to training data. This was addressed by applying a resource-based policy on the S3 bucket, utilizing the aws:PrincipalOrgID condition key to deny access to any identity not belonging to the organization. An exception for AWS services was detailed using aws:SourceOrgID.
• Scenario 2: Internal threat actor configuring the model to train on external data. This was mitigated by an Service Control Policy (SCP), which used the aws:ResourceOrgID condition key to prevent identities within the organization from accessing resources outside of it.
• Scenario 3: Access to resources (like a Bedrock model) from untrusted networks due to leaked credentials. This was handled by another SCP leveraging network-related condition keys such as aws:SourceIp and aws:SourceVpc to ensure corporate credentials are only used from expected network locations.

This detailed, architectural walkthrough effectively demonstrated the practical application of the data perimeter concepts and the specific policy constructs required, providing a clear blueprint for implementation without the need for a live coding session.

Defensive Implications

▶ Watch: Corporate footprint evolution: Rise of SaaS and cloud solutions (9:00)

Implementing a data perimeter fundamentally changes how organizations approach security in AWS. The speakers provided several crucial defensive implications and calls to action for security teams:

1. Prioritize and Threat Model: Before implementing any policies, organizations must conduct thorough threat modeling. Identify the highest-risk assets and the most impactful threat vectors. This helps prioritize which of the six data perimeter control statements will yield the most value for the effort invested. Don't try to implement everything at once; focus on the most critical data and scenarios first.

1. Test in Non-Production Environments — Rigorously: A stern warning was issued: "The one thing you should not do is apply them directly in production without testing." Data perimeter policies, especially SCPs, are powerful and can inadvertently block legitimate access if not carefully crafted and tested. Organizations must integrate policy testing into their SDLC (Software Development Life Cycle), using non-production environments to validate that policies achieve their intended security goals without causing operational disruption.

1. Leverage AWS Organizations: For any organization with multiple AWS accounts, AWS Organizations is a foundational service for implementing data perimeters. It provides the central management point for Service Control Policies (SCPs) and enables the use of PrincipalOrgID, ResourceOrgID, and SourceOrgID condition keys, which are essential for defining organizational boundaries in policies.

1. Start with Sample Policies: AWS provides a public GitHub repository with sample data perimeter policies and extensive documentation. This resource is invaluable for getting started, offering pre-written policies for various AWS services (S3, KMS, etc.) that can be adapted to specific organizational needs. The speakers encourage community engagement with this repository, including raising issues and submitting pull requests.

1. Combine with Least Privilege: A data perimeter is a coarse-grained container and augments, rather than replaces, the principle of least privilege. Defenders must continue to ensure that all IAM roles and users have only the minimum necessary permissions. The data perimeter acts as an overarching guardrail, catching egregious misconfigurations or malicious attempts that might slip past granular least privilege controls. Regularly review and right-size permissions alongside data perimeter implementation.

1. Extend Beyond AWS: The underlying principles of the data perimeter framework are universally applicable. Defenders should apply the same six security objectives – ensuring only trusted identities, resources, and networks are involved – to all cloud models, including other cloud providers and SaaS applications. The goal is to establish consistent security invariants across the entire digital estate, regardless of where the data resides.

By following these defensive strategies, organizations can establish a robust, policy-driven security posture that significantly reduces the risk of unauthorized data access and exfiltration in complex cloud environments.

Key Takeaways

• Traditional network perimeter security models are insufficient for protecting API-driven cloud assets and complex, distributed environments.
• The data perimeter framework on AWS provides a policy-driven approach to establish clear organizational boundaries, preventing unauthorized data movement and access.
• This framework comprises three sub-perimeters (Identity, Resource, Network) enforced by six control statements, acting as security invariants that complement the principle of least privilege.
• Core AWS policy types – VPC Endpoint Policy, Resource-Based Policy, and Service Control Policy (SCP) – are leveraged, with AWS Organizations and condition keys like aws:PrincipalOrgID, aws:ResourceOrgID, aws:SourceOrgID, aws:SourceIp, and aws:SourceVpc being critical enablers.
• Successful implementation requires thorough threat modeling to prioritize controls and rigorous testing in non-production environments to avoid operational disruptions.
• The concepts of data perimeters are broadly applicable and should be extended to secure assets across all cloud providers and SaaS applications, not just AWS.

About the Speaker(s)

Liam Wadman is a Solutions Architect with AWS Identity. His expertise lies in helping customers design and implement robust identity and access management solutions within the AWS ecosystem. In this talk, Liam provided the foundational understanding of data perimeters, contrasting them with traditional security models and outlining the core concepts.

Tatyana Yatskevich is also a Solutions Architect with AWS Identity. She specializes in deep diving into the practical application of AWS security controls. During the session, Tatyana demonstrated how to construct and apply specific, production-grade AWS policies to build a data perimeter, using a generative AI workload as a concrete example to illustrate the technical details and condition keys involved.