Building a Data Perimeter on AWS

Publication date: April 26, 2022 (Document history)

Many organizations want to implement perimeter controls to help protect against unintended access and configuration errors through always-on guardrails. This paper outlines the best practices and available services for creating a perimeter around your identities, resources, and networks in AWS.

Are you Well-Architected?

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

For more expert guidance and best practices for your cloud architecture—reference architecture deployments, diagrams, and whitepapers—refer to the AWS Architecture Center.

Introduction

In traditional, on-premises data center environments, a trusted network and strong authentication are the foundation of security. They establish a high-level perimeter to help prevent untrusted entities from coming in and data from going out. This perimeter provides a clear boundary of trust and ownership. When customers think about creating an AWS perimeter as part of their responsibility for security “in the cloud” in the AWS Shared Responsibility Model, they want to achieve the same outcomes. They want to draw a circle around their AWS resources, like Amazon Simple Storage Service (S3) buckets and Amazon Simple Queue Service (SQS) queues, that clearly separates “my AWS” from other customers.

The circle that defines an AWS perimeter is typically represented as an AWS organization managed by AWS Organizations. AWS Organizations is an account management service that lets you consolidate multiple AWS accounts into an organization that you create and centrally manage.

Each AWS account you own is a logical container for AWS identities, resources, and networks. The AWS organization is a grouping of all of those items into a single entity. Along with on-premises networks and systems that access AWS resources, it is what most customers think of as the perimeter of “my AWS”.

The perimeter defines the things you “intend” or “expect” to happen. It refers to the access patterns among your identities, resources, and networks that should be allowed. Using those three elements, we want to make the following assertion to define our perimeter’s goal: access is allowed if - and only if - the identity is trusted, the resource is trusted, and the network is expected.

If any of these conditions are false, then the access inside the perimeter is “unintended” and should be denied. The perimeter is composed of controls implemented on your identities, resources, and networks to ensure the necessary conditions are true.

This paper discusses the perimeter objectives and how the applied controls prevent unintended access patterns, particularly to data. It is designed to help customers understand how to create a complete AWS data perimeter as part of their responsibility in the AWS Shared Responsibility Model.

A high-level depiction of defining a perimeter around your AWS resources to prevent interaction with unintended AWS Identity and Access Management (IAM) principals, unintended resources, and unexpected networks