View a markdown version of this page

Theme 5: Establish a data perimeter - AWS Prescriptive Guidance
Related best practicesImplementing this themeMonitoring this theme

Theme 5: Establish a data perimeter

Essential Eight strategies covered

Restrict administrative privileges

A data perimeter is a set of preventive guardrails in your AWS environment that help make sure that only trusted identities are accessing trusted resources from expected networks. These guardrails serve as always-on boundaries that help protect your data across a broad set of AWS accounts and resources. These organisation-wide guardrails do not replace your existing fine-grained access controls. Instead, they help improve your security strategy by making sure that all AWS Identity and Access Management (IAM) users, roles, and resources adhere to a set of defined security standards.

You can establish a data perimeter by using policies that prevent access from outside of an organisation boundary, typically created in AWS Organizations. The three primary perimeter authorization conditions used to establish a data perimeter are:

  • Trusted identities – Principals (IAM roles or users) within your AWS accounts, or AWS services acting on your behalf.

  • Trusted resources – Resources that are in your AWS accounts or are managed by AWS services acting on your behalf.

  • Expected networks – Your on-premises data centres and virtual private clouds (VPCs), or the networks of AWS services acting on your behalf.

Consider implementing data perimeters between environments of different data classifications, such as OFFICIAL:SENSITIVE or PROTECTED, or different risk levels, such as development, test, or production. For more information, see Building a data perimeter on AWS (AWS whitepaper) and Establishing a data perimeter on AWS: Overview (AWS blog post).

Related best practices in the AWS Well-Architected Framework

Implementing this theme

Implement identity controls

  • Allow only trusted identities to access your resources – Use resource-based policies with the condition keys aws:PrincipalOrgID and aws:PrincipalIsAWSService. This allows only principals from your AWS organization and from AWS to access your resources.

  • Allow trusted identities only from your network – Use VPC endpoint policies with the condition keys aws:PrincipalOrgID and aws:PrincipalIsAWSService. This allows only principals from your AWS organization and from AWS to access services through VPC endpoints.

Implement resource controls

  • Allow your identities to access only trusted resources – Use service control policies (SCPs) with the condition key aws:ResourceOrgID. This allows your identities to access only resources in your AWS organization.

  • Allow access to trusted resources only from your network – Use VPC endpoint policies with the condition key aws:ResourceOrgID. This allows your identities to access services only through VPC endpoints that are part of your AWS organization.

Implement network controls

  • Allow identities to access resources only from expected networks – Use SCPs with the condition keys aws:SourceIp, aws:SourceVpc, aws:SourceVpce, and aws:ViaAWSService. This allows your identities to access resources only from expected IP addresses, VPCs, and VPC endpoints, and through AWS services.

  • Allow access to your resources only from expected networks – Use resource-based policies with the condition keys aws:SourceIp, aws:SourceVpc, aws:SourceVpce, aws:ViaAWSService, and aws:PrincipalIsAWSService. This allows access to your resources only from expected IPs, from expected VPCs, from expected VPC endpoints, through AWS services, or when the calling identity is an AWS service.

Monitoring this theme

Monitor policies

  • Implement mechanisms to review SCPs, IAM policies, and VPC endpoint policies

Implement the following AWS Config rules

  • SERVICE_VPC_ENDPOINT_ENABLED