|    |    |    |    |
| --- | --- | --- | --- |

  

* * *

[[_TOC_]]

* * *

**Purpose**
-----------

This document outlines a strategy for protecting data in transit. It follows Well-Architected best practices to define data protection in transit requirements, such as encryption standards, based on data classification to meet your organizational, legal, and compliance requirements. 

AWS ACM provides the following capabilities and benefits:

1.  Handles the complexity and security of creating and managing public and private SSL/TLS certificates by eliminating the need to manually create and manage key pairs and CSR.
2.  Supports email and DNS based domain validation.
3.  Supports cipher suites with Perfect Forward Secrecy.
4.  Supports one click certificates deployment and managed updates for AWS ALB/NLB, CloudFront, and API Gateway.
5.  Protects certificates private key with KMS encryption.
6.  Supports automatic rotation for AWS ACM generated certificates.
7.  Allows import of certificates acquired from 3rd party certificate providers.

**Implementation**
------------------

#### Services

\[Customer\] will enforce the use of HTTPs for all public connections and will utilize AWS ACM to provision and manage TLS certificates for \[Customer\] public services and applications. Implementing secure key and certificate management, enforce encryption in transit and authenticating network communications align to Well-Architected best practices.

\[Customer\] will be using the following mechanisms to protect data in transit:

1.  Protecting data in transit when managing AWS Services:
    1.  AWS Management Console, AWS CLI, and AWS SDKs use HTTPS API endpoints to connect to AWS services by default;
    2.  If developers are to programmatically construct requests to AWS services, they will select [HTTPS API endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) to connect to.
2.  Protecting corporate network access to AWS VPC:
    1.  IPSec VPN will be configured within Direct Connect links to connect from \[Customer\] data centers to the AWS environment. Implementation details can be found here (link to LZ artifact).
3.  Protecting end users access to applications running in AWS:
    1.  SSL termination will be performed on the AWS ALB/NLB or AWS CloudFront to offload CPU intensive SSL operations from application instances and to centralize management of SSL certificates. This also will allow to take advantage of AWS Shield Standard protection for most common attacks against the SSL protocol.
    2.  AWS ACM will be utilized to manage public certificates for AWS hosted resources whenever AWS ALB or CloudFront are used for the SSL termination.
    3.  Perfect Forward Secrecy can be enforced for applications running behind AWS ALB/NLB by selecting [ELBSecurityPolicy-FS-2018-06](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) security policy.
    4.  For majority of the applications, communication to the back-end instance will be unencrypted and protected by the AWS VPC built-in security components. For sensitive workloads, \[Customer\] may decide to implement end-to-end encryption with a certificate generated by AWS ACM Private CA. The decision will be made on an application-by-application basis.
4.  Protecting applications access to AWS Public Cloud Services:
    1.  VPC Endpoints will be used by applications running in the VPCs to connect to AWS services’ public endpoints. Implementation details can be found here (link to LZ artifact).
5.  Protecting administrative access to AWS Public Cloud Services:
    1.  Strategy for administrative access to EC2 instances is defined here (link to Compute Resource Protection Design page)
        

#### Pricing Information

1.  [AWS ACM](https://aws.amazon.com/certificate-manager/pricing)

#### Future State:

The following features can be considered for implementation in the future:

1.  [AWS ACM Private CA](https://docs.aws.amazon.com/acm-pca/latest/userguide/PcaWelcome.html)

 **Attachments:**