The purpose of this Data Perimeters Blog Post Series is to provide prescriptive guidance about establishing your data perimeter at scale, including key security and implementation considerations. These blog posts cover in depth the objectives and foundational elements needed to enforce identity, resource, and network data perimeters, and how to use a risk-based approach to apply the relevant controls.
Blog post 1: Overview of establishing a data perimeter on AWS
For your sensitive data on AWS, you should implement security controls, including identity and access management, infrastructure security, and data protection. AWS recommends that you set up multiple accounts as your workloads grow to isolate applications and data with specific security requirements. AWS tools can help you establish a data perimeter between your multiple accounts, while blocking unintended access from outside of your organization. Data perimeters on AWS span many different features and capabilities. Based on your security requirements, you should decide which capabilities are appropriate for your organization.
This first blog post about data perimeters explains which AWS Identity and Access Management (IAM) features and capabilities you can use to establish a data perimeter on AWS. The subsequent posts provide implementation guidance and IAM policy examples for establishing your identity, resource, and network data perimeters.
Blog post 2: Allow only trusted identities to access company data
AWS offers a set of capabilities you can use to implement a data perimeter to help prevent unintended access. One type of unintended access that companies want to prevent is access to corporate data by users who do not belong to the company. A combination of IAM features and capabilities can help you achieve this goal in AWS while fostering innovation and agility form the identity perimeter. This blog post provides an overview of some of the security risks the identity perimeter is designed to address, policy examples, and implementation guidance for establishing the perimeter.
Blog post 3: Allow only trusted resources from my organization
Companies that store and process data on AWS want to prevent transfers of that data to or from locations outside of their company’s control. This is to support security strategies, such as data loss prevention, or to comply with the terms and conditions set forth by various regulatory and privacy agreements. On AWS, a resource perimeter is a set of IAM features and capabilities that you can use to build your defense-in-depth protection against unintended data transfers. In this blog post, you learn about the benefits and implementation considerations when you define your resource perimeter.
Blog post 4: Allow access to company data only from expected networks
A key part of protecting your organization’s nonpublic, sensitive data is to understand who can access it and from where. To restrict access to authorized users from known locations, you should be familiar with the expected network access patterns and establish organization-wide guardrails to limit access to known networks. Additionally, you should verify that the credentials associated with your IAM principals are usable only within these expected networks. In this blog post, you learn about the benefits and implementation considerations of defining your network perimeter.
Blog post 5: Require services to be created only within expected networks
In this post, we demonstrate how to use preventative controls to ensure that your resources are deployed within your virtual private cloud (VPC) so that you can effectively enforce network perimeter controls. We also explore detective controls you can use to detect the lack of adherence to this VPC requirement.
Other related blog posts
IAM makes it easier for you to manage permissions for AWS services accessing your resources
by Ilya Epshteyn and Harsha Sharma, 05/04/2021