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 |
|
IAM Identity-based policies SCPs |
|
Resource |
|
Resource-based policies |
|
Network |
|
VPC Endpoint Policies |
|
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 inAccount B
(an account outside of your perimeter) - Also, the Resource-based policies in
Account B
must allow the requester inAccount A
to access the resource
- For requests made from one AWS account to another, the requester in
⌨️ Mitigation
- Implement least privilege IAM Identity-based policies
- Focus on reducing standalone wildcards in
Resource
statements ("Resource": "*"
) - Explicitly list allowed resources when possible
- Focus on reducing standalone wildcards in
- 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
- specifying resources like
- Limit the scope of access to resources in specific accounts that are part of your organization by:
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
oraws:PrincipalOrgPathsIAM
policy conditions - Use IAM Access Analyzer to identify resource-based policies that are too permissive
- Limit access to intended IAM principals by specifying the
- Allow AWS service principals
- Use the
aws:PrincipalIsAWSService
condition Resource-based policies
- Use the
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
- Use the
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
oraws:PrincipalOrgPaths
policy conditions
- Prevent the use of unintended identities by specifying the
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 |
|
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
oraws: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
- Use either the
Summary of Mitigations¶
- Use least privilege IAM Identity-based policies and SCPs to prevent intended principals from accessing unintended resources
- Use an SCP to limit access to resources from expected network locations
- 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.
- Specifying the
- 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
- Using
- Block all outbound Internet access, except for required AWS endpoints and allowed external services that are dependencies for your workloads.
- Implement proxy-based solutions to manage out-of-Region requests so that Network Boundary controls are consistently applied
- 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
- 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)