|
| 1 | +# Examples of service-specific controls |
| 2 | + |
| 3 | +Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. SPDX-License-Identifier: CC-BY-SA-4.0 |
| 4 | + |
| 5 | +## Description |
| 6 | + |
| 7 | +This folder contains examples of RCPs with service-specific controls you might want to enforce when implementing a data perimeter for a service. |
| 8 | + |
| 9 | +Use the following example RCPs individually or in combination: |
| 10 | + |
| 11 | +* [network_perimeter_vpceorgid_rcp](network_perimeter_vpceorgid_rcp.json) - Enforces network perimeter controls using aws:VpceOrgID on [supported services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpceorgid). |
| 12 | + |
| 13 | +This folder also contains examples of resource-based policies that enforce identity and network perimeter controls for services that are currently not supported by resource control policies (RCPs): |
| 14 | + |
| 15 | +* [api_gateway_policy](api_gateway_policy.json) - Enforces identity and network perimeter controls on [Amazon API Gateway](https://aws.amazon.com/api-gateway/) resources. |
| 16 | +* [sns_topic_policy](sns_topic_policy.json) - Enforces identity and network perimeter controls on [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/) resources. |
| 17 | + |
| 18 | +Because developers will be creating resources such as Amazon SNS topics on a regular basis, you might need to implement automation to enforce identity and network perimeter controls when those resources are created or their policies are changed. One option is to use custom [AWS Config rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules.html)_._ Alternatively, you can choose to enforce resource deployment through [AWS Service Catalog](https://aws.amazon.com/servicecatalog/?aws-service-catalog.sort-by=item.additionalFields.createdDate&aws-service-catalog.sort-order=desc) or a CI/CD pipeline. With the AWS Service Catalog approach, you can have identity and network perimeter controls built into the centrally controlled products that are made available to developers to deploy within their accounts. With the CI/CD pipeline approach, the pipeline can have built-in compliance checks that enforce identity and network perimeter controls during the deployment. If you are deploying resources with your CI/CD pipeline by using [AWS CloudFormation](https://aws.amazon.com/cloudformation/), see the blog post [Proactively keep resources secure and compliant with AWS CloudFormation Hooks](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/). |
| 19 | + |
| 20 | +Note that the policy examples in this folder do not represent a complete list of valid data access patterns, and they are intended for you to tailor and extend them to suit the needs of your environment. Additionally, these examples do not grant any permissions; they only restrict access by explicitly denying specific data access patterns. You still have to grant appropriate permissions with explicit `Allow` statements in identity-based or resource-based policies. |
| 21 | + |
| 22 | +## Included data access patterns |
| 23 | + |
| 24 | +The following policy statements are included in the RCP examples, each statement representing specific data access patterns. See the [resource_control_policies](../) for description of data access patterns and policy statements used in the resource-based policy examples. |
| 25 | + |
| 26 | +These policy statements demonstrate using `aws:ResourceTag/tag-key` to exclude specific resources from the control. Note that this key only works with resources that [support authorization based on tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). For details on supported service actions, see the [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html). For resources not yet supporting `aws:ResourceTag/tag-key`, you can use `aws:ResourceAccount` or `aws:ResourceOrgPaths` to exclude resources owned by specific AWS accounts, or the `NotResource` IAM policy element to exclude specific resource Amazon Resource Names (ARNs). Alternatively, you can use a service-specific version of `aws:ResourceTag/tag-key` such as `s3:ExistingObjectTag`, if available. |
| 27 | + |
| 28 | +### "Sid":"EnforceNetworkPerimeterVpceOrgID" |
| 29 | + |
| 30 | +This policy statement is included in the [network_perimeter_vpceorgid_rcp](network_perimeter_vpceorgid_rcp.json). It limits access to expected networks with the aws:VpceOrgID condition key for [supported services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpceorgid) and for IAM principals tagged with the `dp:include:network` tag set to `true` and federated users. Expected networks are defined as follows: |
| 31 | + |
| 32 | +* Your organization’s on-premises data centers and static egress points in AWS such as a NAT gateway that are specified by IP ranges (`<my-corporate-cidr>`) in the policy statement. |
| 33 | +* Your organization’s VPCs that are specified by the organization ID (`<my-org-id>`) in the policy statement. |
| 34 | +* Networks of AWS services that use your credentials to access resources using [forward access sessions (FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) as denoted by `aws:ViaAWSService` in the policy statement. This access pattern applies when you access data via an AWS service, and that service takes subsequent actions on your behalf by using your IAM credentials. |
| 35 | +* Networks of AWS services that use [service principals](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) to access resources on your behalf are denoted by `aws:PrincipalIsAWSService` in the policy statement. Use the `"Sid": "EnforceConfusedDeputyProtection"` in the [identity_perimeter_rcp](../identity_perimeter_rcp.json) to further restrict AWS service actions so that they can only interact with your resources when performing operations on behalf of accounts that you own. |
| 36 | +* Networks of AWS services that use [service roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html) to access resources on your behalf as denoted by `arn:aws:iam::*:role/aws:ec2-infrastructure` in the policy statement. |
| 37 | +* Networks of trusted third parties are specified by their account IDs (`<third-party-account-a>` and `<third-party-account-b>`) in the policy statement. |
| 38 | + |
| 39 | +Additional considerations: |
| 40 | +* We recommend that you use aws:VpceOrgID only if all of the services you want to restrict access to are currently supported. Using this condition key with unsupported services can lead to unintended authorization results. If you need to enforce the restriction on a wider range of services, consider using aws:SourceVpc as demonstrated in the [network_perimeter_rcp](../network_perimeter_rcp.json). See [Establishing a data perimeter on AWS: Allow access to company data only from expected networks](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-access-to-company-data-only-from-expected-networks/) for more details. |
| 41 | + |
| 42 | +* This policy statement exempts identities that are tagged with `dp:exclude:network` set to `true` from the network perimeter guardrail. Note that it is not recommended to have this exception in the policy unless it is accompanied by [`"Sid": "EnforceOrgIdentities"`](../#sidenforceorgidentities). This helps ensure that an account outside of your Organizations organization cannot tag their identities with `dp:exclude:network` to circumvent your network perimeter controls. |
| 43 | + |
| 44 | +Example data access patterns: |
| 45 | + |
| 46 | +* *Amazon Athena query*. When an application running in your VPC [creates an Athena query](https://docs.aws.amazon.com/athena/latest/ug/getting-started.html), Athena uses the application’s credentials to make subsequent requests to Amazon S3 to read data from your bucket and return results. |
| 47 | +* *Elastic Beanstalk operations.* When a user [creates an application by using Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/applications.html), Elastic Beanstalk launches an environment and uses your user’s credentials to create and configure other AWS resources such as Amazon EC2 instances. |
| 48 | +* *Amazon S3 server-side encryption with AWS KMS (SSE-KMS)*. When a user uploads an object to an Amazon S3 bucket with the default [SSE-KMS encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) enabled, Amazon S3 makes a subsequent request to [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) to generate a data key from your customer master key (CMK) to encrypt the object. The call to AWS KMS is signed by using the user’s credentials and comes from the service network. A similar pattern is observed when a user tries to download an encrypted object when Amazon S3 calls AWS KMS to decrypt the key that was used to encrypt the object. Other services such as AWS Secrets Manager use a similar integration with AWS KMS. |
| 49 | +* *Amazon EBS volume decryption*. When you mount an encrypted Amazon EBS volume to an Amazon EC2 instance, Amazon EC2 calls AWS KMS to decrypt the data key that was used to encrypt the volume. The call to AWS KMS is signed by an IAM role, `arn:aws:iam::*:role/aws:ec2-infrastructure`, which is created in your account by Amazon EC2, and comes from the service network. |
| 50 | +* *Elastic Load Balancing (ELB) access logging*. In some AWS Regions, [Classic Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html#attach-bucket-policy) and [Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html#access-logging-bucket-permissions) use AWS account credentials that belong to an AWS service to publish logs to your Amazon S3 buckets. Because the call to Amazon S3 comes from the service network, the `aws:PrincipalAccount` condition key in the resource control policy should contain the ELB account ID if access logging is enabled. |
| 51 | +* *Amazon FinSpace data encryption*. To encrypt data at rest, [Amazon FinSpace](https://aws.amazon.com/finspace/) uses AWS account credentials that belong to the service to access your AWS KMS customer managed key. Because the call to AWS KMS comes from the service network, the `aws:PrincipalAccount` condition key in the resource control policy should contain the [FinSpace environment infrastructure account](https://docs.aws.amazon.com/finspace/latest/userguide/data-sharing-lake-formation.html). You can find the ID of the infrastructure account that's dedicated to your FinSpace environment on the environment page of the FinSpace console. |
0 commit comments