Building an AWS Perimeter

Summary

This is a summary of the Building an AWS Perimeter Whitepaper, released in July 2021.

See the Appendixes for sample Policies.

Goal

• The circle that defines an AWS perimeter is typically represented as an AWS organization

• Assertion:

  • Access is allowed if - and only if - the identity is intended, the resource is intended, and the network is intended
  • Each component (identity, resource, and network) must implement a boundary to ensure that the necessary conditions are true

  Access in the Perimeter ⟺ (Only My IAM) ∧ (Only My Resource) ∧ (Only My Network)
  

Perimeter Objectives

Boundary	Restrict Access To	AWS Services Used	Description
Identity	Resources Networks	IAM Identity-based policies SCPs	IAM Identity-based policies are applied directly to IAM principals to define their permissions SCPs are a type of organization policy use to manage permissions in an Organization, and are applied to identities SCPs include the ability to define the expected network locations for interaction with intended AWS resources
Resource	IAM Networks	Resource-based policies	Resource-based policies are applied to AWS resources and define which IAM principals can interact with the resource, as well as what the expected networks are for access
Network	IAM Resources	VPC Endpoint Policies	A VPC endpoint enables a private VPC connection to supported AWS services without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection VPC Endpoint Policies provide a mechanism to prevent actions by unintended principals in both your VPC and on-premises networks They are additional IAM policies that are evaluated against all requests, regardless of whether the IAM principal or resource involved in the request is part of "my AWS" These policies are evaluated against all IAM principals, where IAM Identity-based policies and SCPs only apply to IAM principals that are part of your Organization

Perimeter Overview

Identity Boundary

The identity boundary consists of policies applied to the IAM principals that are part of “my AWS” and ensures that they only access intended resources (Only My Resources) from expected networks (Only My Networks).

Only My Resources

• Ensures that your intended IAM principals can’t access resources in AWS accounts outside the perimeter
• All access to unintended AWS resources involves cross-account access
  • For requests made from one AWS account to another, the requester in Account A (an account in "my AWS") must have an IAM Identity-based policies that allows them to make a request to the resource in Account B (an account outside of your perimeter)
  • Also, the Resource-based policies in Account B must allow the requester in Account A to access the resource

⌨️ Mitigation

• Implement least privilege IAM Identity-based policies
  • Focus on reducing standalone wildcards in Resource statements ("Resource": "*")
  • Explicitly list allowed resources when possible
• Configure SCPs as deny lists
  • Limit the scope of access to resources in specific accounts that are part of your organization by:
    • specifying resources like "arn:aws:ec2:*:123456789012:*" for actions that support specifying resource types
    • using the s3:ResourceAccount condition for Amazon S3 resources

Only My Networks

• There are several scenarios where AWS will act on your behalf with your IAM credentials from networks that AWS owns (e.g., CloudFormation)
• There are AWS services that run code you provide in compute environments that are not part of your network (e.g., Lambda)

⌨️ Mitigation

• Use SCPs, which applies to all of their intended principals and specifies the expected locations for data access
• For AWS services acting on your behalf, add exceptions via the aws:ViaAWSService IAM policy condition
• Force Lambda to use VPC:
  • enforce with IAM condition keys
  • use AWS Config Rules to audit this configuration
  • implement remediation with AWS Config Remediation Actions and AWS Systems Manager Automation documents
• Security Groups should be used to prevent access to AWS services that are hosted in customer VPCs, but are not authorized with IAM credentials

Resource Boundary

The resource boundary consists of resource-based policies applied to the AWS resources that are part of “my AWS” and ensures that they are only accessed by intended identities (Only My IAM) from expected networks (Only My Networks).

Only My IAM

• In certain cases, AWS services may use an IAM principal (a service principal) that is outside of your organization, specifically, to perform actions on your behalf (e.g., cloudtrail.amazonaws.com)

⌨️ Mitigation

• Enforce Resource-based policies
  • Limit access to intended IAM principals by specifying the aws:PrincipalOrgId IAM policy condition in the Resource-based policies
  • Implement a more granular restriction with the aws:PrincipalAccount or aws:PrincipalOrgPathsIAM policy conditions
  • Use IAM Access Analyzer to identify resource-based policies that are too permissive
• Allow AWS service principals
  • Use the aws:PrincipalIsAWSService condition Resource-based policies

Only My Networks

⌨️ Mitigation

• Specify what network locations are expected sources for access
  • Use the aws:SourceIp and `aws:SourceVpc conditions in the Resource-based policies
  • Optional because SCPs in the Identity Boundary provide the same outcome

Network Boundary

The network boundary consists of VPC endpoint policies applied to VPC endpoints in expected networks (your VPCs) that ensure only intended identities (Only My IAM) can access intended resources (Only My Resources) from your expected networks.

Only My IAM

⌨️ Mitigation

• Enforce VPC Endpoint Policies
  • Prevent the use of unintended identities by specifying the aws:PrincipalOrgId IAM policy condition in your network boundary
  • Implement a more granular restriction with the aws:PrincipalAccount or aws:PrincipalOrgPaths policy conditions

Only My Resources

• An endpoint policy can also be used to prevent access to unintended resources in a similar way that identity-based policies or SCPs do (optional)

---

Special Cases

Cross-Region Requests

• VPC endpoints only support routing AWS API calls to service endpoints that are in the same Region as the VPC endpoint itself
  • A call to PutObject in a different region would not traverse the VPC endpoint and would not have the endpoint policy applied to the request
• To ensure the intended security controls are applied, customers can handle cross-Region requests in two ways

⌨️ Mitigation

Prevent cross-Region API calls
Forward out of Region requests through a proxy	The local proxy can forward traffic to a peer proxy running in a VPC in the requested Region. The out-of-Region proxy sends the traffic to the appropriate VPC endpoint in its Region The local proxy uses AWS-provided VPC DNS An Outbound Amazon Route 53 Resolver Rule directs all out-of-Region domain names to an Inbound Route 53 Resolver endpoint in a VPC in the requested Region This resolver endpoint is co-located in the same VPC, with the necessary VPC endpoints The resolver returns the IP address of the appropriate VPC endpoint and the local proxy sends the traffic directly to the VPC endpoint in the requested Region

Preventing Access to Internal Credentials

• Except for the cases of credential theft or leakage, the only other way for an unintended entity to gain access to temporary credentials derived from IAM roles that are part of "my AWS", is through misconfigured IAM role trust policies
• The trust policy can be configured to ensure that no one from outside the account or organization can be authorized to assume the role

⌨️ Mitigation

• Ensure for all IAM role trust policies:
  • Use either the aws:PrincipalOrgId or aws:PrincipaOrgPaths condition when the trusted entity is an IAM principal
  • Exceptions can be created with an allow list of known, external, expected accounts and they should use the sts:ExternalId condition
  • The trusted entity is an AWS service, being either a service principal or IAM service-linked role

---

Summary of Mitigations

1. Use least privilege IAM Identity-based policies and SCPs to prevent intended principals from accessing unintended resources
2. Use an SCP to limit access to resources from expected network locations
3. Add defense in depth to resources that support Resource-based policies by
   • Specifying the aws:PrincipalOrgId condition to limit access to intended principals
   • Optionally add conditions to limit access to expected network locations
   • Use IAM Access Analyzer to review resource-based policy configuration
   • Use the aws:PrincipalIsAWSService condition to create exceptions in resource policies for AWS services
   • Use the s3:ResourceAccount condition to limit access to buckets in specific AWS accounts.
4. Use VPC Endpoint Policies to prevent unintended principals when interacting with AWS resources from your networks by:
   • Using aws:PrincipalOrgId as a condition in each statement
   • Preventing access to unintended resources
5. Block all outbound Internet access, except for required AWS endpoints and allowed external services that are dependencies for your workloads.
6. Implement proxy-based solutions to manage out-of-Region requests so that Network Boundary controls are consistently applied
7. Where AWS provides an option to run a resource publicly or inside a customer- owned VPC, use the VPC configuration and turn off the public access options in order to use Network Boundary controls
8. Configure IAM Role Trust Policies with condition statements, limiting access to only intended principals when the trusted entity is an IAM principal (as opposed to an AWS service principal)