# Configurar o acesso seguro e restringir o acesso ao conteúdo
<a name="SecurityAndPrivateContent"></a>

O CloudFront oferece várias opções para proteger o conteúdo que fornece. Veja a seguir algumas maneiras de usar o CloudFront para proteger e restringir o acesso ao conteúdo:
+ Configure conexões HTTPS
+ Impeça que usuários em locais geográficos específicos acessem o conteúdo
+ Exigir que os usuários acessem o conteúdo usando signed URLs ou signed cookies do CloudFront
+ Configure criptografia em nível de campo para campos de conteúdo específicos
+ Use o AWS WAF para controlar o acesso ao seu conteúdo

Também é necessário implementar uma arquitetura resiliente a DDoS para a infraestrutura e as aplicações. Para ter informações, consulte [AWS Best Practices for DDoS Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html).

Para obter informações adicionais, consulte:
+ [Proteger a entrega de conteúdo com o CloudFront](https://aws.amazon.com/cloudfront/security/)
+ [SIEM no Amazon OpenSearch Service](https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README.md)

**Topics**
+ [Usar HTTPS com o CloudFront](using-https.md)
+ [Usar nomes de domínio alternativos e HTTPS](using-https-alternate-domain-names.md)
+ [Autenticação TLS mútua com o CloudFront (mTLS de visualizador)](mtls-authentication.md)
+ [TLS mútua de origem com o CloudFront](origin-mtls-authentication.md)
+ [Veicular conteúdo privado com URLs e cookies assinados](PrivateContent.md)
+ [Restringir o acesso a uma origem da AWS](private-content-restricting-access-to-origin.md)
+ [Restringir o acesso aos Application Load Balancers](restrict-access-to-load-balancer.md)
+ [Restringir a distribuição geográfica do conteúdo](georestrictions.md)
+ [Use criptografia de nível de campo para ajudar a proteger dados confidenciais](field-level-encryption.md)

# Usar HTTPS com o CloudFront
<a name="using-https"></a>

É possível configurar o CloudFront para exigir que os visualizadores usem HTTPS para as suas conexões sejam criptografadas durante a comunicação do CloudFront com os visualizadores. Também é possível configurar o CloudFront para usar HTTPS com sua origem a fim de que as conexões sejam criptografadas quando o CloudFront se comunicar com os usuários.

Se você configurar o CloudFront para exigir HTTPS na comunicação com os visualizadores e com a origem, veja aqui o que acontece quando o CloudFront recebe uma solicitação:

1. Um visualizador envia uma solicitação HTTPS ao CloudFront. Há uma negociação SSL/TLS entre o visualizador e o CloudFront. No fim, o visualizador envia a solicitação em um formato criptografado.

1. Se o local da borda do CloudFront contiver uma resposta em cache, o CloudFront criptografará a resposta e a retornará ao visualizador. O visualizador, por sua vez, descriptografará a resposta.

1. Se o local da borda do CloudFront não contiver uma resposta em cache, o CloudFront realizará uma negociação SSL/TLS com a origem e, quando ela for concluída, encaminhará a solicitação para a origem em formato criptografado.

1. Sua origem descriptografa a solicitação, processa-a (gera uma resposta), criptografa-a e a devolve para o CloudFront.

1. O CloudFront descriptografa a resposta, criptografa-a novamente e a encaminha para o visualizador. O CloudFront também armazena em cache a resposta no local da borda para que ela esteja disponível na próxima vez que for solicitada.

1. O visualizador descriptografa a resposta.

O processo funciona basicamente da mesma forma, quer a origem seja um bucket do Amazon S3, um MediaStore ou uma origem personalizada, como um servidor HTTP/S.

**nota**  
Para ajudar a impedir ataques do tipo renegociação SSL, o CloudFront não é compatível com a renegociação para solicitações do visualizador e da origem.

Também é possível ativar a autenticação mútua para sua distribuição do CloudFront. Para obter mais informações, consulte [Autenticação TLS mútua com o CloudFront (mTLS de visualizador)TLS mútua de origem com o CloudFront](mtls-authentication.md).

Para obter informações sobre como exigir HTTPS entre os visualizadores e o CloudFront, e entre o CloudFront e a origem, consulte os tópicos a seguir.

**Topics**
+ [Exigir HTTPS entre os visualizadores e o CloudFront](using-https-viewers-to-cloudfront.md)
+ [Exigir HTTPS para uma origem personalizada](using-https-cloudfront-to-custom-origin.md)
+ [Exigir HTTPS para uma origem do Amazon S3](using-https-cloudfront-to-s3-origin.md)
+ [Protocolos e cifras compatíveis entre visualizadores e o CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
+ [Protocolos e criptografias compatíveis entre o CloudFront e a origem](secure-connections-supported-ciphers-cloudfront-to-origin.md)

# Exigir HTTPS na comunicação entre visualizadores e CloudFront
<a name="using-https-viewers-to-cloudfront"></a>

É possível configurar um ou mais comportamentos de cache na distribuição do CloudFront para exigir HTTPS para a comunicação entre os visualizadores e o CloudFront. Também é possível configurar um ou mais comportamentos de cache para permitir HTTP e HTTPS, de forma que o CloudFront exija HTTPS de alguns objetos, mas não de outros. As etapas de configuração dependem do nome de domínio sendo usado nos URLs do objeto:
+ Se estiver usando o nome de domínio atribuído pelo CloudFront à distribuição, como d111111abcdef8.cloudfront.net, altere a configuração **Política de protocolo de visualizador** de um ou mais comportamentos de cache para exigir comunicação HTTPS. Nessa configuração, o CloudFront fornece o certificado SSL/TLS. 

  Para alterar o valor de **Política de protocolo de visualizador** usando o console do CloudFront, consulte o procedimento apresentado posteriormente nesta seção.

  Para obter informações sobre como usar a API do CloudFront para alterar o valor do elemento `ViewerProtocolPolicy`, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*.
+ Se estiver usando o nome do seu próprio domínio, como example.com, você precisará alterar várias configurações do CloudFront. Você também precisa usar um certificado SSL/TLS fornecido pelo AWS Certificate Manager (ACM) ou importar um certificado de uma autoridade de certificação de terceiros para o ACM ou para o armazenamento de certificados do IAM. Para obter mais informações, consulte [Usar nomes de domínio alternativos e HTTPS](using-https-alternate-domain-names.md).

**nota**  
Para garantir que os objetos obtidos pelos visualizadores do CloudFront sejam criptografados na origem, sempre use HTTPS entre o CloudFront e a origem. Se você alterou recentemente de HTTP para HTTPS entre o CloudFront e a origem, recomendamos invalidar os objetos nos pontos de presença do CloudFront. O CloudFront retornará um objeto ao visualizador, independentemente de o protocolo usado por ele (HTTP ou HTTPS) corresponder ou não ao protocolo usado pelo CloudFront para obter o objeto. Para obter mais informações sobre como remover ou substituir objetos em uma distribuição, consulte [Adicionar, remover ou substituir conteúdo distribuído pelo CloudFront](AddRemoveReplaceObjects.md).

## Exigir HTTPS de visualizadores
<a name="configure-cloudfront-HTTPS-viewers"></a>

Para exigir HTTPS entre os visualizadores e o CloudFront para um ou mais comportamentos de cache, execute o procedimento a seguir.<a name="using-https-viewers-to-cloudfront-procedure"></a>

**Como configurar o CloudFront para exigir HTTPS entre os visualizadores e o CloudFront**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel superior do console do CloudFront, escolha o ID da distribuição que você deseja atualizar.

1. Na guia **Behaviors** (Comportamentos), selecione o comportamento de cache que você deseja atualizar e, em seguida, escolha **Edit** (Editar).

1. Especifique um dos seguintes valores para **Política de protocolo de visualizador**:  
**Redirect HTTP to HTTPS**  
Os visualizadores podem usar os dois protocolos. Solicitações HTTP `GET` e `HEAD` são automaticamente redirecionados para solicitações HTTPS. O CloudFront retorna o código de status HTTP 301 (movido permanentemente) com o novo URL HTTPS. Depois, o visualizador reenvia a solicitação para o CloudFront usando o URL de HTTPS.  
Se você enviar `POST`, `PUT`, `DELETE`, `OPTIONS` ou `PATCH` por HTTP com um comportamento de cache HTTP para HTTPS e a versão do protocolo de solicitação HTTP 1.1 ou superior, o CloudFront redirecionará a solicitação para um local HTTPS com um código de status HTTP 307 (redirecionamento temporário). Isso garante que a solicitação seja enviada novamente para o novo local usando o mesmo método e carga do corpo.  
Se você enviar solicitações `POST`, `PUT`, `DELETE`, `OPTIONS` ou `PATCH` por HTTP para comportamento de cache HTTPS com a versão do protocolo de solicitação inferior a HTTP 1.1, o CloudFront retornará um código de status HTTP 403 (proibido).
Quando um visualizador faz uma solicitação HTTP que é redirecionada para uma solicitação HTTPS, o CloudFront cobra pelas duas solicitações. Para a solicitação HTTP, a cobrança é somente pela solicitação e cabeçalhos retornados pelo CloudFront para o visualizador. Para a solicitação HTTPS, a cobrança é pela solicitação e pelos cabeçalhos e objeto retornados por sua origem.  
**HTTPS Only (Somente HTTPS)**  
Os visualizadores só podem acessar seu conteúdo se estiverem usando HTTPS. Se um visualizador enviar uma solicitação HTTP, em vez de HTTPS, o CloudFront retornará o código de status HTTP 403 (proibido) e não retornará o objeto.

1. Escolha **Salvar alterações**.

1. Repita as etapas 3 a 5 para cada comportamento de cache adicional para o qual você deseja exigir HTTPS entre os visualizadores e o CloudFront.

1. Antes de usar a configuração atualizada em um ambiente de produção, confirme:
   + Se o padrão de caminho de cada comportamento de cache se aplica apenas às solicitações nas quais os visualizadores devem usar HTTPS.
   + Se os comportamentos de cache estão listados na ordem em que você deseja que o CloudFront os avalie. Para obter mais informações, consulte [Padrão de caminho](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Se os comportamentos de cache estão roteando as solicitações para as origens corretas. 

# Exigir HTTPS na comunicação entre o CloudFront e a origem personalizada
<a name="using-https-cloudfront-to-custom-origin"></a>

Você pode exigir o uso de HTTPS na comunicação entre o CloudFront e sua origem.

**nota**  
Se a origem for um bucket do Amazon S3 configurado como um endpoint do site, não será possível configurar o CloudFront para usar HTTPS com a origem porque o Amazon S3 não é compatível com HTTPS para endpoints de site.

Para exigir HTTPS entre o CloudFront e sua origem, siga os procedimentos deste tópico para fazer o seguinte:

1. Em sua distribuição, altere a configuração **Origin Protocol Policy** (Política de protocolo da origem) para a origem.

1. Instale um certificado SSL/TLS no servidor de origem (isso não é necessário ao usar uma origem do Amazon S3 ou algumas outras origens da AWS).

**Topics**
+ [Exigir HTTPS para origens personalizadas](#using-https-cloudfront-to-origin-distribution-setting)
+ [Instalar um certificado SSL/TLS na origem personalizada](#using-https-cloudfront-to-origin-certificate)

## Exigir HTTPS para origens personalizadas
<a name="using-https-cloudfront-to-origin-distribution-setting"></a>

O procedimento a seguir explica como configurar o CloudFront para usar HTTPS para se comunicar com um balanceador de carga do Elastic Load Balancing, uma instância do Amazon EC2 ou outra origem personalizada. Para obter informações sobre como usar a API do CloudFront para atualizar uma distribuição, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*. <a name="using-https-cloudfront-to-custom-origin-procedure"></a>

**Como configurar o CloudFront para exigir HTTPS entre o CloudFront e a origem personalizada**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel superior do console do CloudFront, escolha o ID da distribuição que você deseja atualizar.

1. Na guia **Behaviors** (Comportamentos), selecione a origem que você deseja atualizar e, em seguida, escolha **Edit** (Editar).

1. Atualize as seguintes configurações:  
**Política de protocolo da origem**  
Altere **Origin Protocol Policy** para as origens aplicáveis à sua distribuição:  
   + **HTTPS Only (Somente HTTPS)**: o CloudFront usa HTTPS para se comunicar com a origem personalizada.
   + **Match Viewer (Corresponder visualizador)**: o CloudFront se comunica com a origem personalizada usando HTTP ou HTTPS, dependendo do protocolo da solicitação do visualizador. Por exemplo, se você escolher **Match Viewer (Corresponder visualizador)** para **Origin Protocol Policy (Política de protocolo de origem)** e o visualizador usar HTTPS para solicitar um objeto do CloudFront, o CloudFront também usará HTTPS para encaminhar a solicitação para a origem.

     Escolha **Match Viewer** somente se você especificar **Redirect HTTP to HTTPS** ou **HTTPS Only** em **Viewer Protocol Policy**.

     Observe que o CloudFront armazenará o objeto em cache somente uma vez se os visualizadores fizerem solicitações usando protocolos HTTP e HTTPS.  
**Origin SSL Protocols**  
Escolha os **Origin SSL Protocols** para as origens aplicáveis à sua distribuição. O protocolo SSLv3 é menos seguro, portanto, recomendamos que você escolha SSLv3 somente se a origem não for compatível com TLSv1 ou posterior. O handshake TLSv1 é compatível com as versões anteriores e posteriores do SSLv3, mas não com o TLSv1.1 e posterior. Quando você escolhe SSLv3, o CloudFront envia *somente* solicitações de handshake SSLv3.

1. Escolha **Salvar alterações**.

1. Repita as etapas 3 a 5 para cada origem adicional para a qual você deseja exigir HTTPS entre o CloudFront e a origem personalizada.

1. Antes de usar a configuração atualizada em um ambiente de produção, confirme:
   + Se o padrão de caminho de cada comportamento de cache se aplica apenas às solicitações nas quais os visualizadores devem usar HTTPS.
   + Se os comportamentos de cache estão listados na ordem em que você deseja que o CloudFront os avalie. Para obter mais informações, consulte [Padrão de caminho](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Os comportamentos de cache estão roteando solicitações para as origens nas quais você alterou a opção **Origin Protocol Policy**. 

## Instalar um certificado SSL/TLS na origem personalizada
<a name="using-https-cloudfront-to-origin-certificate"></a>

Você pode usar um certificado SSL/TLS das seguintes fontes na sua origem personalizada:
+ Se a origem for um balanceador de carga Elastic Load Balancing, você poderá usar um certificado fornecido pelo AWS Certificate Manager (ACM). Você também pode usar um certificado assinado por uma autoridade de certificação terceirizada reconhecida e importado no ACM.
+ Para origens diferentes de balanceadores de carga do Elastic Load Balancing, use um certificado assinado por uma autoridade de certificação (CA) confiável de terceiros, como a Comodo, a DigiCert ou a Symantec.

O certificado retornado da origem deve incluir um dos seguintes nomes de domínio:
+ O nome de domínio no campo **Origin domain** (Domínio de origem) da origem (o campo `DomainName` na API do CloudFront).
+ O nome do domínio no cabeçalho `Host`, se o comportamento do cache estiver configurado para encaminhar o cabeçalho `Host` para a origem.

Ao usar HTTPS para se comunicar com a origem, o CloudFront verifica se o certificado foi emitido por uma autoridade de certificação reconhecida. O CloudFront é compatível com as mesmas autoridades de certificação que o Mozilla. Para ver a lista atual, consulte [Mozilla Included CA Certificate List](https://wiki.mozilla.org/CA/Included_Certificates). Você não pode usar um certificado autoassinado para comunicação HTTPS entre o CloudFront e a origem.

**Importante**  
Se o servidor de origem retornar um certificado expirado, inválido ou autoassinado, ou a cadeia de certificados na ordem errada, o CloudFront interromperá a conexão TCP, retornará o código de status HTTP 502 (gateway inválido) ao visualizador e definirá o cabeçalho `X-Cache` como `Error from cloudfront`. Além disso, se toda a cadeia de certificados, inclusive o certificado intermediário, não estiver presente, o CloudFront interromperá a conexão TCP.

# Exigir HTTPS na comunicação entre o CloudFront e a origem do Amazon S3
<a name="using-https-cloudfront-to-s3-origin"></a>

Quando a origem é um bucket do Amazon S3, as opções para usar HTTPS para comunicação com o CloudFront dependem de como você está usando o bucket. Se o bucket do Amazon S3 estiver configurado como um endpoint de site, não será possível configurar o CloudFront para usar HTTPS para comunicação com a origem, pois o Amazon S3 não é compatível com conexões HTTPS nessa configuração.

Quando a origem é um bucket do Amazon S3 compatível com a comunicação HTTPS, o CloudFront encaminha as solicitações ao S3 usando o protocolo que os visualizadores usaram para enviar as solicitações. A definição padrão da configuração [Protocolo (somente origens personalizadas)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) é **Match Viewer (Corresponder visualizador)** e não pode ser alterada. No entanto, se você habilitar o controle de acesso à origem (OAC) para a origem do Amazon S3, a comunicação usada entre o CloudFront e o Amazon S3 dependerá das configurações. Para obter mais informações, consulte [Criar um controle de acesso à origem](private-content-restricting-access-to-s3.md#create-oac-overview-s3).

Para exigir HTTPS para comunicação entre o CloudFront e o Amazon S3, você deve alterar o valor de **Viewer Protocol Policy (Política de protocolo do visualizador)** para **Redirect HTTP to HTTPS (Redirecionar HTTP para HTTPS)** ou **HTTPS Only (Somente HTTPS)**. O procedimento mais adiante nesta seção explica como usar o console do CloudFront para alterar a **Viewer Protocol Policy (Política de protocolo do visualizador)**. Para informações sobre como usar a API do CloudFront para atualizar o elemento `ViewerProtocolPolicy` de uma distribuição, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*. 

Quando você usa HTTPS com um bucket do Amazon S3 compatível com a comunicação HTTPS, o Amazon S3 fornece o certificado SSL/TLS, portanto, você não precisa fazer isso.

## Exigir HTTPS para uma origem do Amazon S3
<a name="configure-cloudfront-HTTPS-S3-origin"></a>

O procedimento a seguir mostra como configurar o CloudFront para exigir HTTPS para a origem do Amazon S3.<a name="using-https-cloudfront-to-s3-origin-procedure"></a>

**Como configurar o CloudFront para exigir HTTPS para a origem do Amazon S3**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel superior do console do CloudFront, escolha o ID da distribuição que você deseja atualizar.

1. Na guia **Behaviors**, escolha o comportamento de cache que você deseja atualizar e, em seguida, escolha **Edit**.

1. Especifique um dos seguintes valores para **Viewer Protocol Policy**:  
**Redirect HTTP to HTTPS**  
Os visualizadores podem usar os dois protocolos, mas solicitações HTTP são automaticamente redirecionadas para HTTPS. O CloudFront retorna o código de status HTTP 301 (movido permanentemente) com o novo URL HTTPS. Depois, o visualizador reenvia a solicitação para o CloudFront usando o URL de HTTPS.  
O CloudFront não redireciona solicitações `DELETE`, `OPTIONS`, `PATCH`, `POST` ou `PUT` de HTTP para HTTPS. Se você configurar o redirecionamento de um comportamento de cache para HTTPS, o CloudFront responderá às solicitações HTTP `DELETE`, `OPTIONS`, `PATCH`, `POST` ou `PUT` para esse comportamento de cache com o código de status HTTP 403 (proibido).
Quando um visualizador faz uma solicitação HTTP que é redirecionada para uma solicitação HTTPS, o CloudFront cobra pelas duas solicitações. Para a solicitação HTTP, a cobrança é somente pela solicitação e cabeçalhos retornados pelo CloudFront para o visualizador. Para a solicitação HTTPS, a cobrança é pela solicitação e pelos cabeçalhos e objeto retornados por sua origem.  
**HTTPS Only**  
Os visualizadores só podem acessar seu conteúdo se estiverem usando HTTPS. Se um visualizador enviar uma solicitação HTTP, em vez de HTTPS, o CloudFront retornará o código de status HTTP 403 (proibido) e não retornará o objeto.

1. Escolha **Yes, Edit**.

1. Repita as etapas 3 a 5 para cada comportamento de cache adicional para o qual você deseja exigir HTTPS entre os visualizadores e o CloudFront, e entre o CloudFront e o S3.

1. Antes de usar a configuração atualizada em um ambiente de produção, confirme:
   + Se o padrão de caminho de cada comportamento de cache se aplica apenas às solicitações nas quais os visualizadores devem usar HTTPS.
   + Se os comportamentos de cache estão listados na ordem em que você deseja que o CloudFront os avalie. Para obter mais informações, consulte [Padrão de caminho](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Se os comportamentos de cache estão roteando as solicitações para as origens corretas. 

# Protocolos e cifras compatíveis entre visualizadores e o CloudFront
<a name="secure-connections-supported-viewer-protocols-ciphers"></a>

Ao [exigir HTTPS entre os visualizadores e a distribuição do CloudFront](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), escolha uma [política de segurança](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) que determine as seguintes configurações:
+ O protocolo SSL/TLS mínimo que o CloudFront usa para se comunicar com os visualizadores
+ As criptografias que o CloudFront pode usar para criptografar a comunicação com os visualizadores.

Para escolher uma política de segurança, especifique o valor aplicável para [Política de segurança (versão mínima de SSL/TLS)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy). A tabela a seguir lista os protocolos e as criptografias que o CloudFront pode usar para cada política de segurança.

Um visualizador deve ser compatível com pelo menos uma dessas criptografias compatíveis para estabelecer uma conexão HTTPS com o CloudFront. O CloudFront escolhe uma criptografia na ordem listada entre as criptografias compatíveis com o visualizador. Consulte também [Nomes de cifras OpenSSL, s2n e RFC](#secure-connections-openssl-rfc-cipher-names).


|  | Política de segurança |  | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Protocolos SSL/TLS compatíveis | 
| TLSv1.3 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLSv1.2 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| TLSv1.1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLSv1 | ♦ | ♦ | ♦ |  |  |  |  |  |  | 
| SSLv3 | ♦ |  |  |  |  |  |  |  |  | 
| Cifras TLSv1.3 compatíveis | 
| TLS\$1AES\$1128\$1GCM\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1AES\$1256\$1GCM\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | ♦ | 
| Cifras ECDSA compatíveis | 
| ECDHE-ECDSA-AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA-AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA-AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-ECDSA-AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA-CHACHA20-POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-ECDSA-AES256-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA-AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| Cifras RSA compatíveis | 
| ECDHE-RSA-AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA-AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA-AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-RSA-AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA-CHACHA20-POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-RSA-AES256-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA-AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| DES-CBC3-SHA | ♦ | ♦ |  |  |  |  |  |  |  | 
| RC4-MD5 | ♦ |  |  |  |  |  |  |  |  | 

## Nomes de cifras OpenSSL, s2n e RFC
<a name="secure-connections-openssl-rfc-cipher-names"></a>

O OpenSSL e o [s2n](https://github.com/awslabs/s2n) usam nomes diferentes para cifras que os padrões TLS usam ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246) e [RFC 8446](https://tools.ietf.org/html/rfc8446)). A tabela a seguir mapeia os nomes do OpenSSL e do s2n para o nome do RFC para cada cifra.

O CloudFront permite a troca de chaves clássicas e com segurança quântica. Com relação às trocas de chaves clássicas que usam curvas elípticas, o CloudFront permite o seguinte:
+ `prime256v1`
+ `X25519`
+ `secp384r1`

Com relação às trocas de chaves com segurança quântica, o CloudFront permite o seguinte:
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**nota**  
Somente é possível usar trocas de chaves com segurança quântica com o TLS 1.3. No TLS 1.2 e em versões anteriores, não é possível usar trocas de chaves com segurança quântica.

  Para saber mais, consulte os seguintes tópicos:
  + [Criptografia pós-quântica](https://aws.amazon.com/security/post-quantum-cryptography/)
  + [Algoritmos de criptografia e Serviços da AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
  + [Troca de chaves híbrida no TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)

Para ter mais informações sobre os requisitos de certificado para o CloudFront, consulte [Requisitos para usar certificados SSL/TLS com o CloudFront](cnames-and-https-requirements.md).


| Nome da cifra do OpenSSL e do s2n | Nome da criptografia RFC | 
| --- | --- | 
| Cifras TLSv1.3 compatíveis | 
| TLS\$1AES\$1128\$1GCM\$1SHA256 | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| TLS\$1AES\$1256\$1GCM\$1SHA384 | TLS\$1AES\$1256\$1GCM\$1SHA384 | 
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | TLS\$1CHACHA20\$1POLY1305\$1SHA256 | 
| Cifras ECDSA compatíveis | 
| ECDHE-ECDSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-ECDSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-ECDSA-CHACHA20-POLY1305 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1CHACHA20\$1POLY1305\$1SHA256 | 
| ECDHE-ECDSA-AES256-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| Cifras RSA compatíveis | 
| ECDHE-RSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-RSA-AES128-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256  | 
| ECDHE-RSA-AES128-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-RSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384  | 
| ECDHE-RSA-CHACHA20-POLY1305 | TLS\$1ECDHE\$1RSA\$1WITH\$1CHACHA20\$1POLY1305\$1SHA256 | 
| ECDHE-RSA-AES256-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384  | 
| ECDHE-RSA-AES256-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-GCM-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| AES256-GCM-SHA384 | TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| AES128-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES-CBC3-SHA  | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA  | 
| RC4-MD5 | TLS\$1RSA\$1WITH\$1RC4\$1128\$1MD5 | 

## Esquemas de assinatura compatíveis entre visualizadores e o CloudFront
<a name="secure-connections-viewer-signature-schemes"></a>

O CloudFront é compatível com os seguintes esquemas de assinatura para conexões entre visualizadores e o CloudFront.


|  | Política de segurança | Esquemas de assinatura | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 |  TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SECP256R1\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SECP384R1\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 

# Protocolos e criptografias compatíveis entre o CloudFront e a origem
<a name="secure-connections-supported-ciphers-cloudfront-to-origin"></a>

Se você optar por [exigir HTTPS entre o CloudFront e a origem](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy), poderá decidir [qual protocolo SSL/TLS permitir](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) para a conexão segura, e o CloudFront poderá conectar à origem usando qualquer uma das cifras ECDSA ou RSA listadas na tabela a seguir. A origem deve ser compatível com pelo menos uma dessas criptografias do CloudFront para estabelecer uma conexão HTTPS com a origem.

O OpenSSL e o [s2n](https://github.com/awslabs/s2n) usam nomes diferentes para cifras que os padrões TLS usam ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246) e [RFC 8446](https://tools.ietf.org/html/rfc8446)). A tabela a seguir inclui os nomes do OpenSSL e do s2n, bem como o nome da RFC, para cada cifra.

Para cifras com algoritmos de troca de chaves de curva elíptica, o CloudFront oferece suporte às seguintes curvas elípticas:
+ prime256v1
+ secp384r1
+ X25519


| Nome da cifra do OpenSSL e do s2n | Nome da criptografia RFC | 
| --- | --- | 
| Cifras ECDSA compatíveis | 
| ECDHE-ECDSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-ECDSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| Cifras RSA compatíveis | 
| ECDHE-RSA-AES256-GCM-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-RSA-AES256-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-RSA-AES256-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-RSA-AES128-GCM-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-RSA-AES128-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-RSA-AES128-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES-CBC3-SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA | 
| RC4-MD5 | TLS\$1RSA\$1WITH\$1RC4\$1128\$1MD5 | 

**Esquemas de assinatura compatíveis entre o CloudFront e a origem**

O CloudFront é compatível com os seguintes esquemas de assinatura para conexões entre o CloudFront e a origem.
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA1
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA1

# Usar nomes de domínio alternativos e HTTPS
<a name="using-https-alternate-domain-names"></a>

Se quiser usar seu nome de domínio nos URLs dos arquivos (por exemplo, `https://www.example.com/image.jpg`) e quiser que os visualizadores usem HTTPS, será necessário concluir as etapas dos tópicos a seguir. (Se você usar o nome de domínio de distribuição padrão do CloudFront nos seus URLs, por exemplo, `https://d111111abcdef8.cloudfront.net/image.jpg`, siga as orientações no tópico a seguir: [Exigir HTTPS na comunicação entre visualizadores e CloudFront](using-https-viewers-to-cloudfront.md).)

**Importante**  
Ao adicionar um certificado à sua distribuição, o CloudFront o propagará imediatamente para todos os pontos de presença. À medida que novos pontos de presença são disponibilizados, o CloudFront propaga o certificado para esses pontos também. Não é possível restringir os pontos de presença para os quais o CloudFront propaga os certificados.

**Topics**
+ [Escolher como o CloudFront atende a solicitações HTTPS](cnames-https-dedicated-ip-or-sni.md)
+ [Requisitos para usar certificados SSL/TLS com o CloudFront](cnames-and-https-requirements.md)
+ [Cotas no uso de certificados SSL/TLS com o CloudFront (somente HTTPS entre visualizadores e o CloudFront)](cnames-and-https-limits.md)
+ [Configurar nomes de domínio alternativos e HTTPS](cnames-and-https-procedures.md)
+ [Determinar o tamanho da chave pública em um certificado RSA SSL/TLS](cnames-and-https-size-of-public-key.md)
+ [Aumentar as cotas de certificados SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md)
+ [Trocar certificados SSL/TLS](cnames-and-https-rotate-certificates.md)
+ [Reverter um certificado SSL/TLS personalizado para o certificado padrão do CloudFront](cnames-and-https-revert-to-cf-certificate.md)
+ [Alternar de um certificado SSL/TLS personalizado com endereços IP dedicados para SNI](cnames-and-https-switch-dedicated-to-sni.md)

# Escolher como o CloudFront atende a solicitações HTTPS
<a name="cnames-https-dedicated-ip-or-sni"></a>

Se quiser que os visualizadores usem HTTPS e nomes de domínio alternativos para os arquivos, escolha uma das opções a seguir de como o CloudFront atende a solicitações HTTPS:
+ Usar a [indicação de nome de servidor (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication): recomendado
+ Use um endereço IP dedicado em cada ponto de presença

Esta seção explica como cada opção funciona.

## Usar SNI para atender a solicitações HTTPS (funciona para a maioria dos clientes)
<a name="cnames-https-sni"></a>

A [Indicação de nome de servidor (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) é uma extensão do protocolo TLS, compatível com os navegadores e clientes lançados após 2010. Se você configurar o CloudFront para atender a solicitações HTTPS usando SNI, ele associará seu nome de domínio alternativo a um endereço IP para cada ponto de presença. Quando um visualizador envia uma solicitação HTTPS para seu conteúdo, o DNS a roteia para o endereço IP do ponto de presença correto. O endereço IP para o seu nome de domínio é determinado durante a negociação do handshake SSL/TLS. O endereço IP não é dedicado à sua distribuição.

A negociação SSL/TLS ocorre no início do processo de estabelecimento de uma conexão HTTPS. Se o CloudFront não conseguir determinar imediatamente qual é o domínio da solicitação, ele interromperá a conexão. Veja o que acontece quando um visualizador compatível com SNI envia uma solicitação HTTP para seu conteúdo:

1. O visualizador recebe automaticamente o nome de domínio do URL da solicitação e o adiciona à extensão SNI da mensagem de saudações ao cliente TLS.

1. Quando o CloudFront recebe a mensagem de saudações ao cliente TLS, ele usa o nome de domínio na extensão SNI para encontrar a distribuição correspondente do CloudFront e envia de volta o certificado TLS associado.

1. O visualizador e o CloudFront executam a negociação SSL/TLS.

1. O CloudFront retorna o conteúdo solicitado para o visualizador.

Para obter uma lista atual dos navegadores compatíveis com SNI, consulte a entrada da Wikipedia [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication).

Se você quiser usar a SNI, mas o navegador de alguns dos seus usuário não forem compatíveis, há várias opções:
+ Configure o CloudFront para atender a solicitações HTTPS usando endereços IP dedicados, em vez de SNI. Para obter mais informações, consulte [Usar um endereço IP dedicado para atender a solicitações HTTPS (funciona para todos os clientes)](#cnames-https-dedicated-ip).
+ Use o certificado SSL/TLS do CloudFront, em vez de um certificado personalizado. Isso requer o uso do nome de domínio do CloudFront da sua distribuição nos URLs dos seus arquivos, por exemplo, `https://d111111abcdef8.cloudfront.net/logo.png`.

  Se você usar o certificado padrão do CloudFront, os visualizadores deverão oferecer suporte ao protocolo SSL TLSv1 ou posterior. O CloudFront não oferece suporte a SSLv3 com o certificado padrão do CloudFront.

  Também é necessário alterar o certificado SSL/TLS usado pelo CloudFront de um certificado personalizado para o certificado padrão do CloudFront:
  + Se você não usou sua distribuição para distribuir o conteúdo, poderá simplesmente alterar a configuração. Para obter mais informações, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md).
  + Caso contrário, será necessário criar uma distribuição do CloudFront e alterar os URLs dos seus arquivos para reduzir ou eliminar o tempo de indisponibilidade do conteúdo. Para obter mais informações, consulte [Reverter um certificado SSL/TLS personalizado para o certificado padrão do CloudFront](cnames-and-https-revert-to-cf-certificate.md).
+ Se você puder controlar qual navegador seus usuários usam, peça que atualizem-no para um que seja compatível com SNI.
+ Use HTTP, em vez de HTTPS.

## Usar um endereço IP dedicado para atender a solicitações HTTPS (funciona para todos os clientes)
<a name="cnames-https-dedicated-ip"></a>

A Indicação de Nome de Servidor (SNI) é uma maneira de associar uma solicitação a um domínio. Outra maneira é usar um endereço IP dedicado. Se tiver usuários que não podem fazer a atualização para um navegador ou cliente lançado após 2010, você poderá usar um endereço IP dedicado para atender a solicitações HTTPS. Para obter uma lista atual dos navegadores compatíveis com SNI, consulte a entrada da Wikipedia [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication). 

**Importante**  
Se você configurar o CloudFront para atender a solicitações HTTPS usando endereços IP dedicados, será cobrado um adicional por mês. A cobrança começará quando você associar seu certificado SSL/TLS a uma distribuição e habilitar a distribuição. Para mais informações sobre os preços do CloudFront, consulte [Definição de preços do Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing). Além disso, consulte [Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions).

Ao configurar o CloudFront para atender a solicitações HTTPS usando endereços IP dedicados, ele associará seu certificado a um endereço IP dedicado em cada local da borda. Veja o que acontece quando um visualizador envia uma solicitação HTTP para seu conteúdo:

1. O DNS roteia a solicitação para o endereço IP da sua distribuição no ponto de presença aplicável.

1. Se uma solicitação do cliente fornecer a extensão SNI na mensagem `ClientHello`, o CloudFront procurará uma distribuição associada a essa SNI.
   + Se houver correspondência, o CloudFront responderá à solicitação com o certificado SSL/TLS.
   + Se não houver correspondência, o CloudFront usa o endereço IP para identificar sua distribuição e determinar qual certificado SSL/TLS retornar para o visualizador.

1. O visualizador e o CloudFront executam uma negociação SSL/TLS usando seu certificado SSL/TLS.

1. O CloudFront retorna o conteúdo solicitado para o visualizador.

Este método funciona para todas as solicitações HTTPS, independentemente do navegador ou outro visualizador usado pelo usuário. 

**nota**  
IPs dedicados não são IPs estáticos e podem mudar com o tempo. O endereço IP que é retornado para o local da borda é alocado dinamicamente dos intervalos de endereços IP da [lista de servidores de borda do CloudFront](LocationsOfEdgeServers.md).  
Os intervalos de endereço IP para os servidores de borda do CloudFront estão sujeitos a alterações. Para receber uma notificação sobre as alterações de endereço IP, [assine as alterações de endereço IP público da AWS via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).

## Solicitar permissão para usar três ou mais certificados SSL/TLS com IP dedicado
<a name="cnames-and-https-multiple-certificates"></a>

Se precisar de permissão para associar de forma permanente três ou mais certificados SSL/TLS com IP dedicado ao CloudFront, execute o procedimento a seguir. Para mais detalhes sobre solicitações HTTPS, consulte [Escolher como o CloudFront atende a solicitações HTTPS](#cnames-https-dedicated-ip-or-sni).

**nota**  
Esse procedimento serve para usar três ou mais certificados com IP dedicado em todas as suas distribuições do CloudFront. O valor padrão é 2. Lembre-se de que você não pode associar mais de um certificado SSL a uma distribuição.  
É possível associar somente um único certificado SSL/TLS a uma distribuição do CloudFront por vez. Esse número é para o total de certificados SSL com IP dedicado que podem ser usados em todas as suas distribuições do CloudFront.<a name="cnames-and-https-multiple-certificates-procedure"></a>

**Como solicitar permissão para usar três ou mais certificados com uma distribuição do CloudFront**

1. Acesse o [Support Center](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions) e crie um caso.

1. Indique quantos certificados você precisa de permissão para usar e descreva as circunstâncias na solicitação. Atualizaremos sua conta o mais rápido possível.

1. Vá para o próximo procedimento.

# Requisitos para usar certificados SSL/TLS com o CloudFront
<a name="cnames-and-https-requirements"></a>

Os requisitos para certificados SSL/TLS estão descritos neste tópico. Eles se aplicam a ambas as opções a seguir, exceto conforme observado:
+ Certificados para o uso de HTTPS entre visualizadores e o CloudFront 
+ Certificados para o uso de HTTPS entre o CloudFront e sua origem

**Topics**
+ [Emissor do certificado](#https-requirements-certificate-issuer)
+ [Região da AWS para AWS Certificate Manager](#https-requirements-aws-region)
+ [Formato do certificado](#https-requirements-certificate-format)
+ [Certificados intermediários](#https-requirements-intermediate-certificates)
+ [Tipo de chave](#https-requirements-key-type)
+ [Chave privada](#https-requirements-private-key)
+ [Permissões](#https-requirements-permissions)
+ [Tamanho da chave do certificado](#https-requirements-size-of-public-key)
+ [Tipos de certificados compatíveis](#https-requirements-supported-types)
+ [Data de expiração e renovação do certificado](#https-requirements-cert-expiration)
+ [Nomes de domínio na distribuição do CloudFront e no certificado](#https-requirements-domain-names-in-cert)
+ [Versão mínima do protocolo SSL/TLS](#https-requirements-minimum-ssl-protocol-version)
+ [Versões de HTTP compatíveis](#https-requirements-supported-http-versions)

## Emissor do certificado
<a name="https-requirements-certificate-issuer"></a>

Recomendamos usar um certificado emitido pelo [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/). Para obter informações sobre como obter um certificado do ACM, consulte o *[Manual do usuário do AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*. Para usar um certificado do ACM com uma distribuição do CloudFront, solicite (ou importe) o certificado na região Leste dos EUA (Norte da Virgínia) (`us-east-1`).

 O CloudFront é compatível com as mesmas autoridades de certificação (CAs) da Mozilla. Portanto, se você não usa o ACM, use um certificado emitido por uma CA na [Lista de certificados CA incluídos no Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). 

Os certificados TLS usados pela origem que você especificou para sua distribuição do CloudFront também precisam ser emitidos pela CA na lista de certificados CA incluídos no Mozilla.

Para obter mais informações sobre como obter e instalar um certificado, consulte a documentação do software do servidor HTTP e a documentação da CA.

## Região da AWS para AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

Para usar um certificado no AWS Certificate Manager (ACM) a fim de exigir HTTPS entre visualizadores e o CloudFront, solicite (ou importe) o certificado na região Leste dos EUA (Norte da Virgínia) (`us-east-1`).

Para exigir HTTPS entre o CloudFront e a origem se estiver usando um balanceador de carga no Elastic Load Balancing como origem, você poderá solicitar ou importar um certificado de qualquer Região da AWS.

## Formato do certificado
<a name="https-requirements-certificate-format"></a>

O certificado deve estar no formato X.509 PEM. Esse será o formato padrão se você estiver usando o AWS Certificate Manager.

## Certificados intermediários
<a name="https-requirements-intermediate-certificates"></a>

Se você estiver usando uma autoridade de certificação (CA) de terceiros, indique todos os certificados intermediários na cadeia existente no arquivo `.pem`, começando com um para a CA que assinou o certificado do seu domínio. Normalmente, é possível encontrar um arquivo no site da sua CA com os certificados raiz e intermediários na ordem adequada da cadeia.

**Importante**  
Não inclua o seguinte: o certificado raiz, certificados intermediários não presentes no caminho de relação de confiança nem o certificado de chave pública da sua CA.

Veja um exemplo abaixo:

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
```

## Tipo de chave
<a name="https-requirements-key-type"></a>

O CloudFront é compatível com pares de chaves RSA e ECDSA públicas/privadas.

O CloudFront oferece suporte a conexões HTTPS para visualizadores e origens usando certificados RSA e ECDSA. Com o [AWS Certificate Manager (ACM)](https://console.aws.amazon.com/acm), é possível solicitar e importar certificados RSA ou ECDSA e, em seguida, associá-los à sua distribuição do CloudFront.

Para obter as listas de criptografias RSA e ECDSA compatíveis com o CloudFront que você pode negociar em conexões HTTPS, consulte [Protocolos e cifras compatíveis entre visualizadores e o CloudFront](secure-connections-supported-viewer-protocols-ciphers.md) e [Protocolos e criptografias compatíveis entre o CloudFront e a origem](secure-connections-supported-ciphers-cloudfront-to-origin.md).

## Chave privada
<a name="https-requirements-private-key"></a>

Se você estiver usando um certificado de uma autoridade de certificação (CA) terceirizada, observe: 
+ A chave privada deve ser correspondente à chave pública que está no certificado.
+ A chave privada deve estar no formato PEM.
+ A chave privada não pode ser criptografada com senha.

Se o AWS Certificate Manager (ACM) forneceu o certificado, ele não liberará a chave privada. A chave privada é armazenada no ACM para uso pelos serviços da AWS integrados a ele.

## Permissões
<a name="https-requirements-permissions"></a>

É necessário ter permissão para usar e importar o certificado SSL/TLS. Se você estiver usando o AWS Certificate Manager (ACM), recomendamos usar as permissões do AWS Identity and Access Management para restringir o acesso aos certificados. Para obter mais informações, consulte [Gerenciamento de identidade e acesso](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html) no *Manual do usuário do AWS Certificate Manager*.

## Tamanho da chave do certificado
<a name="https-requirements-size-of-public-key"></a>

O tamanho de chave de certificado aceito pelo CloudFront depende dos tipos da chave e do certificado.

**Para certificados RSA:**  
O CloudFront é compatível com chaves RSA de 1.024 bits, 2.048 bits, 3.072 bits e 4.096 bits. O tamanho máximo de chave de um certificado RSA usado com o CloudFront é de 4.096 bits.  
 Observe que o ACM emite certificados RSA com chaves de até 2048 bits. Para usar um certificado RSA de 3.072 bits ou 4.096 bits, você precisa obter o certificado externamente e importá-lo para o ACM a fim de que ele esteja disponível para uso com o CloudFront.   
Para obter informações sobre como determinar o tamanho da chave RSA, consulte [Determinar o tamanho da chave pública em um certificado RSA SSL/TLS](cnames-and-https-size-of-public-key.md).

**Para certificados ECDSA:**  
O CloudFront é compatível com chaves de 256 bits. Para usar um certificado ECDSA no ACM para exigir HTTPS entre visualizadores e o CloudFront, use a curva elíptica prime256v1.

## Tipos de certificados compatíveis
<a name="https-requirements-supported-types"></a>

O CloudFront é compatível com todos os tipos de certificados emitidos por uma autoridade de certificação confiável.

## Data de expiração e renovação do certificado
<a name="https-requirements-cert-expiration"></a>

Se estiver usando certificados obtidos de uma autoridade de certificação (CA) de terceiros, você será responsável por monitorar as datas de validade e renovar os certificados importados para o AWS Identity and Access Management (ACM) ou carregá-los para o armazenamento de certificados do AWS Certificate Manager antes que eles expirem.

**Importante**  
Para evitar problemas de expiração do certificado, renove ou reimporte seu certificado pelo menos 24 horas antes do valor `NotAfter` especificado em seu certificado atual. Se seu certificado expirar dentro de 24 horas, solicite um novo certificado do ACM ou importe um novo certificado para o ACM. Em seguida, associe o novo certificado à distribuição do CloudFront.  
O CloudFront pode continuar usando o certificado anterior enquanto a renovação ou reimportação estiver em andamento. Como esse processo é assíncrono, pode levar até 24 horas para o CloudFront mostrar suas alterações.

Se você estiver usando certificados fornecidos pelo ACM, ele gerenciará as renovações. Para obter mais informações, consulte [Renovação gerenciada](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) no *Guia do usuário do AWS Certificate Manager*.

## Nomes de domínio na distribuição do CloudFront e no certificado
<a name="https-requirements-domain-names-in-cert"></a>

Quando você usa uma origem personalizada, o certificado SSL/TLS na sua origem incluirá um nome de domínio no campo **Common Name** (Nome comum) e, possivelmente, vários outros no campo **Subject Alternative Names** (Nomes alternativos do sujeito). (O CloudFront oferece suporte a caracteres curinga em nomes de domínio de certificados.) 

Um dos nomes de domínio do certificado deve ser correspondente ao nome de domínio especificado em "Origin Domain Name". Se nenhum nome de domínio corresponder, o CloudFront retornará um código de status HTTP `502 (Bad Gateway)` para o visualizador.

**Importante**  
Ao adicionar um nome de domínio alternativo a uma distribuição, o CloudFront verifica se o nome de domínio alternativo está coberto pelo certificado que foi anexado. O certificado deve abranger o nome de domínio alternativo no campo de nome alternativo de assunto (SAN) do certificado. Isso significa que o campo SAN deve conter uma correspondência exata para o nome de domínio alternativo ou conter um curinga no mesmo nível do nome de domínio alternativo que você está adicionando.  
Para obter mais informações, consulte [Requisitos para o uso de nomes de domínio alternativos](CNAMEs.md#alternate-domain-names-requirements).

## Versão mínima do protocolo SSL/TLS
<a name="https-requirements-minimum-ssl-protocol-version"></a>

Se estiver usando endereços IP dedicados, defina a versão mínima do protocolo SSL/TLS para a conexão entre os visualizadores e o CloudFront escolhendo uma política de segurança.

Para obter mais informações, consulte [Política de segurança (versão mínima de SSL/TLS)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

## Versões de HTTP compatíveis
<a name="https-requirements-supported-http-versions"></a>

Se você associar um certificado a mais de uma distribuição do CloudFront, todas as distribuições associadas ao certificado deverão usar a mesma opção para [Versões de HTTP compatíveis](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions). Especifique essa opção ao criar ou atualizar uma distribuição do CloudFront.

# Cotas no uso de certificados SSL/TLS com o CloudFront (somente HTTPS entre visualizadores e o CloudFront)
<a name="cnames-and-https-limits"></a>

Observe as cotas a seguir para o uso de certificados SSL/TLS com o CloudFront. Essas cotas aplicam-se somente a certificados SSL/TLS provisionados usando o AWS Certificate Manager (ACM), importados para o ACM ou carregados no armazenamento de certificados do IAM para a comunicação HTTPS entre visualizadores e o CloudFront.

Para obter mais informações, consulte [Aumentar as cotas de certificados SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md).

**Número máximo de certificados por distribuição do CloudFront**  
É possível associar, no máximo, um certificado SSL/TLS a cada distribuição do CloudFront.

**Número máximo de certificados que podem ser importados para o ACM ou carregados no armazenamento de certificados do IAM**  
Se você obteve os certificados SSL/TLS de uma CA de terceiros, deverá armazená-los em um dos seguintes locais:  
+ **AWS Certificate Manager**: para obter a cota atual para o número de certificados do ACM, consulte [Cotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) no *Guia do usuário do AWS Certificate Manager*. A cota informada é um total que inclui os certificados provisionados usando o ACM e os certificados importados para o ACM.
+ **Armazenamento de certificados do IAM**: para obter a cota atual (anteriormente conhecida como limite) sobre o número de certificados que podem ser carregados no armazenamento de certificados do IAM para uma conta da AWS, consulte [Limites do IAM e do STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) no *Guia do usuário do IAM*. É possível solicitar um aumento de cotas no console do Service Quotas.

**Número máximo de certificados por conta da AWS (somente endereços IP dedicados)**  
Se você quiser atender a solicitações HTTPS usando endereços IP dedicados, observe:  
+ Por padrão, o CloudFront concede permissão para usar dois certificados com sua conta da AWS: um para uso diário e um para quando você precisar alternar certificados para várias distribuições.
+ Se precisar de mais de dois certificados SSL/TLS personalizados para a conta da AWS, solicite uma cota maior no console do Service Quotas.

**Usar o mesmo certificado para distribuições do CloudFront criadas com diferentes contas da AWS**  
Se estiver usando uma CA de terceiros e quiser usar o mesmo certificado com várias distribuições do CloudFront criadas usando diferentes contas da AWS, você deverá importar o certificado para o ACM ou fazer upload dele no armazenamento de certificados do IAM de cada conta da AWS.  
Se estiver usando certificados fornecidos pelo ACM, você não poderá configurar o CloudFront para usar os certificados criados por outra conta da AWS.

**Usar o mesmo certificado para o CloudFront e para outros serviços da AWS**  
Se você comprou um certificado de uma autoridade de certificação confiável, como Comodo, DigiCert ou Symantec, poderá usar o mesmo certificado para o CloudFront e para outros serviços da AWS. Se estiver importando o certificado para o ACM, precisará fazê-lo somente uma vez para usá-lo com vários serviços da AWS.  
Se estiver usando certificados fornecidos pelo ACM, eles serão armazenados nele.

**Usar o mesmo certificado para várias distribuições do CloudFront**  
É possível usar o mesmo certificado para uma ou todas as distribuições do CloudFront que você estiver usando para atender a solicitações HTTPS. Observe o seguinte:  
+ Você pode usar o mesmo certificado para atender a solicitações usando endereços IP dedicados e a SNI. 
+ Você pode associar apenas um certificado a cada distribuição.
+ Cada distribuição deve incluir um ou mais nomes de domínio alternativos que também aparecem no campo **Common Name (Nome comum)** ou **Subject Alternative Names (Nomes alternativos de assunto)** do certificado.
+ Se atende a solicitações HTTPS usando endereços IP dedicados e criou todas as suas distribuições usando a mesma conta da AWS, poderá reduzir significativamente seus custos usando o mesmo certificado para todas as distribuições. O CloudFront cobra por certificado, não por distribuição. 

  Por exemplo, imagine que você criou três distribuições usando a mesma conta da AWS e usa o mesmo certificado para todas elas. Você será cobrado apenas uma taxa pelo uso de endereços IP dedicados.

  No entanto, se você atende a solicitações HTTPS usando endereços IP dedicados e o mesmo certificado para criar distribuições do CloudFront em diferentes contas da AWS, a taxa pelo uso de endereços IP dedicados é cobrada de cada conta. Por exemplo, se você criar três distribuições usando três contas diferentes da AWS e usar o mesmo certificado para todas as distribuições, será cobrada a taxa total pelo uso de endereços IP dedicados de cada conta.

# Configurar nomes de domínio alternativos e HTTPS
<a name="cnames-and-https-procedures"></a>

Para usar nomes de domínio alternativos nos URLs dos seus arquivos e usar HTTPS entre os visualizadores e o CloudFront, execute os procedimentos aplicáveis.

**Topics**
+ [Receber um certificado SSL/TLS](#cnames-and-https-getting-certificates)
+ [Importar um certificado SSL/TLS](#cnames-and-https-uploading-certificates)
+ [Atualizar a distribuição do CloudFront](#cnames-and-https-updating-cloudfront)

## Receber um certificado SSL/TLS
<a name="cnames-and-https-getting-certificates"></a>

Obtenha um certificado SSL/TLS, se você ainda não tiver um. Para obter mais informações, consulte a documentação aplicável:
+ Para usar um certificado fornecido pelo AWS Certificate Manager (ACM), consulte o [Guia do usuário do AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/). Em seguida, vá para [Atualizar a distribuição do CloudFront](#cnames-and-https-updating-cloudfront).
**nota**  
É recomendável usar o ACM para provisionar, gerenciar e implantar os certificados SSL/TLS nos recursos gerenciados da AWS. Você deve solicitar um certificado ACM na região Leste dos EUA (Norte da Virgínia).
+ Para obter um certificado de uma autoridade de certificação (CA) terceirizada, consulte a documentação fornecida por ela. Se você tiver o certificado, continue no próximo procedimento.

## Importar um certificado SSL/TLS
<a name="cnames-and-https-uploading-certificates"></a>

Se você obteve seu certificado de uma CA de terceiros, importe-o para o ACM ou faça upload dele no armazenamento de certificados do IAM:

**ACM (recomendado)**  
O ACM permite importar certificados de terceiros pelo console do ACM, bem como de forma programática. Para obter informações sobre como importar um certificado para o ACM, consulte [Importação de certificados no AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) no *Guia do usuário do AWS Certificate Manager*. Você deve importar o certificado na região Leste dos EUA (Norte da Virgínia).

**Armazenamento de certificados do IAM**  
(Não recomendado) Use o comando da AWS CLI a seguir para carregar o certificado de terceiros no armazenamento de certificados do IAM.  

```
aws iam upload-server-certificate \
        --server-certificate-name CertificateName \
        --certificate-body file://public_key_certificate_file \
        --private-key file://privatekey.pem \
        --certificate-chain file://certificate_chain_file \
        --path /cloudfront/path/
```
Observe o seguinte:  
+ **Conta da AWS**: é necessário fazer upload do certificado no armazenamento de certificados do IAM com a mesma conta da AWS usada para criar sua distribuição do CloudFront.
+ **Parâmetro --path**: ao fazer upload do certificado no IAM, o valor do parâmetro `--path` (caminho do certificado) deve começar com `/cloudfront/`, por exemplo, `/cloudfront/production/` ou `/cloudfront/test/`. O caminho deve terminar com "/".
+ **Certificados existentes**: é necessário especificar valores para os parâmetros `--server-certificate-name` e `--path` diferentes dos valores associados aos certificados existentes.
+ **Uso do console do CloudFront**: o valor especificado para o parâmetro `--server-certificate-name` na AWS CLI, por exemplo, `myServerCertificate`, aparece na lista **SSL Certificate** (Certificado SSL) no console do CloudFront.
+ **Uso da API do CloudFront**: anote a string alfanumérica retornada pela AWS CLI. Por exemplo, `AS1A2M3P4L5E67SIIXR3J`. Esse é o valor especificado no elemento `IAMCertificateId`. O ARN do IAM, que também é retornado pela CLI, não é necessário.
Para obter mais informações sobre a AWS CLI, consulte o [Guia do usuário da AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) e a [Referência de comandos da AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).

## Atualizar a distribuição do CloudFront
<a name="cnames-and-https-updating-cloudfront"></a>

Para atualizar as configurações da sua distribuição, execute o seguinte procedimento:<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**Como configurar sua distribuição do CloudFront para nomes de domínio alternativos**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha o ID da distribuição que você deseja atualizar.

1. Na guia **General**, escolha **Edit**.

1. Atualize os seguintes valores:  
**Nome de domínio alternativo (CNAMEs)**  
Selecione **Add item** (Adicionar item) para adicionar os nomes de domínio alternativos aplicáveis. Separe os nomes de domínio com vírgulas ou digite cada nome de domínio em uma nova linha.  
**Certificado SSL personalizado**  
Selecione um certificado na lista suspensa.  
Até 100 certificados estão listados aqui. Se você tiver mais de 100 certificados e não estiver visualizando o certificado que quer adicionar, digite um ARN de certificado no campo para escolhê-lo.  
Se você fez o upload de um certificado para o armazenamento de certificados do IAM, mas ele não está listado e você não puder escolhê-lo digitando o nome no campo, revise o procedimento [Importar um certificado SSL/TLS](#cnames-and-https-uploading-certificates) para verificar se você carregou corretamente o certificado.   
Depois que associar seu certificado SSL/TLS à sua distribuição do CloudFront, não o exclua do ACM nem do armazenamento de certificados do IAM enquanto não removê-lo de todas as distribuições e todas as distribuições sejam implantadas.

1. Escolha **Save changes**.

1. Configurar o CloudFront para exigir HTTPS entre visualizadores e o CloudFront:

   1. Na guia **Behaviors**, escolha o comportamento de cache que você deseja atualizar e, em seguida, escolha **Edit**.

   1. Especifique um dos seguintes valores para **Viewer Protocol Policy**:  
**Redirect HTTP to HTTPS**  
Os visualizadores podem usar os dois protocolos, mas solicitações HTTP são automaticamente redirecionadas para HTTPS. O CloudFront retorna o código de status HTTP `301 (Moved Permanently)` junto com o novo URL de HTTPS. Depois, o visualizador reenvia a solicitação para o CloudFront usando o URL de HTTPS.  
O CloudFront não redireciona solicitações `DELETE`, `OPTIONS`, `PATCH`, `POST` ou `PUT` de HTTP para HTTPS. Se você configurar um comportamento de cache para redirecionar para HTTPS, o CloudFront responderá a solicitações HTTP `DELETE`, `OPTIONS`, `PATCH`, `POST` ou `PUT` desse comportamento de cache com o código de status HTTP `403 (Forbidden)`.
Quando um visualizador faz uma solicitação HTTP que é redirecionada para uma solicitação HTTPS, o CloudFront cobra pelas duas solicitações. Para a solicitação HTTP, a cobrança é somente pela solicitação e cabeçalhos retornados pelo CloudFront para o visualizador. Para a solicitação HTTPS, a cobrança é pela solicitação e pelos cabeçalhos e arquivo retornados por sua origem.  
**HTTPS Only**  
Os visualizadores só podem acessar seu conteúdo se estiverem usando HTTPS. Se um visualizador enviar uma solicitação HTTP, em vez de HTTPS, o CloudFront retornará o código de status HTTP `403 (Forbidden)` e não retornará o arquivo.

   1. Escolha **Yes, Edit**.

   1. Repita as etapas "a" a "c" para cada comportamento de cache adicional para o qual você deseja exigir HTTPS entre os visualizadores e o CloudFront.

1. Antes de usar a configuração atualizada em um ambiente de produção, confirme:
   + Se o padrão de caminho de cada comportamento de cache se aplica apenas às solicitações nas quais os visualizadores devem usar HTTPS.
   + Se os comportamentos de cache estão listados na ordem em que você deseja que o CloudFront os avalie. Para obter mais informações, consulte [Padrão de caminho](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Se os comportamentos de cache estão roteando as solicitações para as origens corretas. 

# Determinar o tamanho da chave pública em um certificado RSA SSL/TLS
<a name="cnames-and-https-size-of-public-key"></a>

Ao usar nomes de domínio alternativos do CloudFront e HTTPS, o tamanho máximo da chave pública em um certificado RSA SSL/TLS é de 4.096 bits. (Esse é o tamanho da chave, e não é o número de caracteres da chave pública.) Se você usa o AWS Certificate Manager para os certificados, embora o ACM seja compatível com chaves RSA maiores, não é possível usar as chaves maiores com o CloudFront.

Você pode determinar o tamanho da chave pública RSA executando o seguinte comando OpenSSL:

```
openssl x509 -in path and filename of SSL/TLS certificate -text -noout 
```

Onde:
+ `-in` especifica o caminho e nome do arquivo do certificado RSA SSL/TLS.
+ `-text` faz com que o OpenSSL exiba o tamanho da chave pública RSA em bits.
+ `-noout` impede que o OpenSSL exiba a chave pública.

Exemplos de resultado:

```
Public-Key: (2048 bit)
```

# Aumentar as cotas de certificados SSL/TLS
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

Há cotas para o número de certificados SSL que você pode importar para o AWS Certificate Manager (ACM) ou dos quais fazer upload para o AWS Identity and Access Management (IAM). Também há uma cota para o número de certificados SSL/TLS que podem ser usados com uma Conta da AWS ao configurar o CloudFront para atender a solicitações HTTPS usando endereços IP dedicados. No entanto, você pode solicitar cotas mais altas.

**Topics**
+ [Aumentar a cota de certificados importados para o ACM](#certificates-to-import-into-acm)
+ [Aumentar a cota de certificados carregados para o IAM](#certificates-to-upload-into-iam)
+ [Aumentar a cota de certificados usados com endereços IP dedicados](#certificates-using-dedicated-ip-address)

## Aumentar a cota de certificados importados para o ACM
<a name="certificates-to-import-into-acm"></a>

Para obter a cota do número de certificados que podem ser importados para o ACM, consulte [Cotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) no *Guia do usuário do AWS Certificate Manager*.

Para solicitar aumento de cota, use o console do Service Quotas. Para obter mais informações, consulte [Solicitar um aumento de cota no ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guia do usuário do Service Quotas.**.

## Aumentar a cota de certificados carregados para o IAM
<a name="certificates-to-upload-into-iam"></a>

Para saber a cota (anteriormente conhecida como limite) sobre o número de certificados que podem ser carregados no IAM, consulte [Limites do IAM e do STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) no *Guia do usuário do IAM*.

Para solicitar aumento de cota, use o console do Service Quotas. Para obter mais informações, consulte [Solicitar um aumento de cota no ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guia do usuário do Service Quotas.**.

## Aumentar a cota de certificados usados com endereços IP dedicados
<a name="certificates-using-dedicated-ip-address"></a>

Em relação à cota do número de certificados SSL que podem ser usados para cada Conta da AWS ao atender a solicitações HTTPS usando endereços IP dedicados, consulte [Cotas para certificados SSL](cloudfront-limits.md#limits-ssl-certificates).

Para solicitar aumento de cota, use o console do Service Quotas. Para obter mais informações, consulte [Solicitar um aumento de cota no ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guia do usuário do Service Quotas.**.

# Trocar certificados SSL/TLS
<a name="cnames-and-https-rotate-certificates"></a>

Quando os certificados SSL/TLS estão próximos da expiração, você precisa alterná-los para garantir a segurança da distribuição e evitar a interrupção do serviço para os visualizadores. Você pode alterná-los das seguintes maneiras:
+ Não é necessário alternar os certificados SSL/TLS fornecidos pelo AWS Certificate Manager (ACM). O ACM gerencia *automaticamente* as renovações dos certificados para você. Consulte mais informações em [Managed certificate renewal](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html) no *Guia do usuário do AWS Certificate Manager*.
+ Se estiver usando uma autoridade de certificação de terceiros e tiver importado certificados para o ACM (recomendado) ou feito upload desses certificados no armazenamento de certificados do IAM, ocasionalmente, será necessário substituir um certificado por outro.

  

**Importante**  
O ACM não gerencia as renovações de certificados adquiridos de autoridades de certificação de terceiros e importados para o ACM.
Se tiver configurado o CloudFront para atender a solicitações HTTPS usando endereços IP dedicados, você poderá receber uma cobrança adicional proporcional pelo uso de um ou mais certificados adicionais ao alterná-los. Recomendamos que você atualize suas distribuições para reduzir o custo adicional.

## Trocar certificados SSL/TLS
<a name="rotate-ssl-tls-certificate"></a>

Para alternar os certificados, execute o procedimento a seguir. Os visualizadores podem continuar acessando seu conteúdo enquanto você alterna os certificados e após a conclusão do processo.<a name="rotate-ssl-tls-certificates-proc"></a>

**Para alternar certificados SSL/TLS**

1. [Aumentar as cotas de certificados SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md) para determinar se você precisa de permissão para usar mais certificados SSL. Em caso afirmativo, solicite permissão e aguarde a concessão antes de continuar na etapa 2.

1. Importar o novo certificado para o ACM ou fazer upload dele no IAM. Para obter mais informações, consulte [Importar um certificado SSL/TLS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates) no *Guia do desenvolvedor do Amazon CloudFront*.

1. (Somente para certificados do IAM) Atualize as distribuições individualmente para usar o novo certificado. Para obter mais informações, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md).

1. (Opcional) Exclua o certificado anterior do ACM ou do IAM.
**Importante**  
Não exclua um certificado SSL/TLS enquanto não os remover de todas as distribuições e o status das distribuições atualizadas não for alterado para `Deployed`.

# Reverter um certificado SSL/TLS personalizado para o certificado padrão do CloudFront
<a name="cnames-and-https-revert-to-cf-certificate"></a>

Se configurou o CloudFront para usar HTTPS entre visualizadores e o CloudFront e configurou o CloudFront para usar um certificado SSL/TLS personalizado, você poderá alterar sua configuração para usar o certificado SSL/TLS padrão do CloudFront. O processo dependerá se você já tiver usado ou não a distribuição para distribuir seu conteúdo:
+ Se você não usou sua distribuição para distribuir o conteúdo, poderá simplesmente alterar a configuração. Para obter mais informações, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md).
+ Caso contrário, será necessário criar uma distribuição do CloudFront e alterar os URLs dos seus arquivos para reduzir ou eliminar o tempo de indisponibilidade do conteúdo. Para fazer isso, execute o procedimento a seguir.

## Reverter para o certificado padrão do CloudFront
<a name="revert-default-cloudfront-certificate"></a>

O procedimento a seguir mostra como reverter um certificado SSL/TLS personalizado para o certificado padrão do CloudFront.<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**Como reverter para o certificado padrão do CloudFront**

1. Crie uma distribuição do CloudFront com a configuração desejada. Em **SSL Certificate (Certificado SSL)**, escolha **Default CloudFront Certificate (Certificado padrão do CloudFront) (\$1.cloudfront.net)**. 

   Para obter mais informações, consulte [Criar uma distribuição](distribution-web-creating-console.md).

1. Para arquivos sendo distribuídos usando o CloudFront, atualize os URLs na aplicação para usar o nome de domínio atribuído pelo CloudFront à nova distribuição. Por exemplo, altere `https://www.example.com/images/logo.png` para `https://d111111abcdef8.cloudfront.net/images/logo.png`.

1. Exclua a distribuição associada a um certificado SSL/TLS personalizado ou atualize-a para alterar o valor de **SSL Certificate (Certificado SSL)** para **Default CloudFront Certificate (Certificado padrão do CloudFront) (\$1.cloudfront.net)**. Para obter mais informações, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md).
**Importante**  
Enquanto você não concluir essa etapa, a AWS continuará cobrando pelo uso de um certificado SSL/TLS personalizado.

1. (Opcional) Exclua seu certificado SSL/TLS personalizado.

   1. Execute o comando AWS CLI da `list-server-certificates` para obter o ID do certificado que você deseja excluir. Para obter mais informações, consulte [list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html) na *Referência de comandos da AWS CLI*.

   1. Execute o comando `delete-server-certificate` da AWS CLI para excluir o certificado. Para ter mais informações, consulte [delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html) na *Referência de comandos da AWS CLI*.

# Alternar de um certificado SSL/TLS personalizado com endereços IP dedicados para SNI
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

Se configurou o CloudFront para usar um certificado SSL/TLS personalizado com endereços IP dedicados, você poderá alternar para um certificado SSL/TLS personalizado com SNI e eliminar a cobrança associada a endereços IP dedicados.

**Importante**  
Essa atualização na configuração do CloudFront não afeta os visualizadores que oferecem suporte à SNI. Os visualizadores podem acessar seu conteúdo antes e depois da alteração, bem como enquanto a alteração está se propagando para pontos de presença do CloudFront. Os visualizadores não compatíveis com SNI não podem acessar seu conteúdo após a alteração. Para obter mais informações, consulte [Escolher como o CloudFront atende a solicitações HTTPS](cnames-https-dedicated-ip-or-sni.md). 

## Alternar do certificado personalizado para SNI
<a name="cloudfront-switch-custom-cert-sni"></a>

O procedimento a seguir mostra como alternar de um certificado SSL/TLS personalizado com endereços IP dedicados para SNI.<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**Para alternar de um certificado SSL/TLS personalizado com endereços IP dedicados para SNI**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha o ID da distribuição que você deseja visualizar ou atualizar.

1. Escolha **Distribution Settings**.

1. Na guia **General**, escolha **Edit**.

1. Em **Certificação SSL personalizada: *opcional***, desmarque **Suporte a clientes legados**.

1. Escolha **Yes, Edit**.

# Autenticação TLS mútua com o CloudFront (mTLS de visualizador)
<a name="mtls-authentication"></a>

A autenticação TLS mútua (autenticação Transport Layer Security mútua ou mTLS) é um protocolo de segurança que estende a autenticação TLS padrão exigindo autenticação bidirecional baseada em certificado, em que tanto o cliente quanto o servidor devem provar sua identidade antes de estabelecer uma conexão segura. Usando a TLS mútua, você pode garantir que somente clientes que apresentem certificados TLS confiáveis tenham acesso às suas distribuições do CloudFront.

## Como funciona
<a name="how-mtls-works"></a>

Em um handshake do TLS padrão, somente o servidor apresenta um certificado para provar sua identidade ao cliente. Com a TLS mútua, o processo de autenticação se torna bidirecional. Quando um cliente tenta se conectar a uma distribuição do CloudFront, o CloudFront solicita um certificado de cliente durante o handshake do TLS. Antes de estabelecer uma conexão segura, o cliente deve apresentar um certificado X.509 válido que o CloudFront valida em relação ao armazenamento confiável que você configurou.

O CloudFront realiza essa validação de certificado em locais da borda da AWS, eliminando a complexidade da autenticação de seus servidores de origem e mantendo os benefícios de desempenho global do CloudFront. É possível configurar a mTLS em dois modos: modo de verificação (que exige que todos os clientes apresentem certificados válidos) ou modo opcional (que valida os certificados quando apresentados, mas também permite conexões sem certificados).

## Casos de uso
<a name="mtls-use-cases"></a>

A autenticação TLS mútua com o CloudFront atende a vários cenários críticos de segurança em que os métodos tradicionais de autenticação são insuficientes:
+ **Autenticação de dispositivos com armazenamento em cache de conteúdo**: é possível autenticar consoles de jogos, dispositivos de IoT ou hardware empresarial antes de permitir o acesso a atualizações de firmware, downloads de jogos ou recursos internos. Cada dispositivo contém um certificado exclusivo que comprova a respectiva autenticidade e, ao mesmo tempo, se beneficia dos recursos de armazenamento em cache do CloudFront.
+ **Autenticação de API para API**: é possível proteger a comunicação de máquina para máquina entre parceiros comerciais confiáveis, sistemas de pagamento ou microsserviços. A autenticação baseada em certificado elimina a necessidade de segredos compartilhados ou chaves de API, além de fornecer uma verificação de identidade forte para trocas automatizadas de dados.

**Topics**
+ [Como funciona](#how-mtls-works)
+ [Casos de uso](#mtls-use-cases)
+ [Gerenciamento de armazenamentos confiáveis e certificados](trust-stores-certificate-management.md)
+ [Habilitar a TLS mútua para distribuições do CloudFront](enable-mtls-distributions.md)
+ [Associar uma função de conexão do CloudFront](connection-functions.md)
+ [Definir configurações adicionais](configuring-additional-settings.md)
+ [Cabeçalhos mTLS de visualizador para políticas de cache e encaminhados à origem](viewer-mtls-headers.md)
+ [Revogação usando a função de conexão e o KVS do CloudFront](revocation-connection-function-kvs.md)
+ [Observabilidade por meio de logs de conexão](connection-logs.md)

# Gerenciamento de armazenamentos confiáveis e certificados
<a name="trust-stores-certificate-management"></a>

Criar e configurar um armazenamento confiável é uma condição obrigatória para implementar a autenticação TLS mútua com o CloudFront. Os armazenamento confiáveis contêm os certificados da autoridade de certificação (CA) que o CloudFront usa para validar certificados de cliente durante o processo de autenticação.

## O que é armazenamento confiável?
<a name="what-is-trust-store"></a>

Um armazenamento confiável é um repositório de certificados CA que o CloudFront usa para validar certificados de cliente durante a autenticação TLS mútua. Os armazenamentos confiáveis contêm os certificados CA raiz e intermediários que formam a cadeia de confiança para autenticar certificados de cliente.

Quando você implementa a TLS mútua com o CloudFront, o armazenamento confiável define em quais autoridades de certificação você confia para emitir certificados de cliente válidos. O CloudFront valida cada certificado de cliente em relação ao seu armazenamento confiável durante o handshake do TLS. Somente clientes que apresentarem certificados vinculados a uma das CAs em seu armazenamento confiável serão autenticados com êxito.

No CloudFront, os armazenamentos confiáveis são recursos em nível de conta que podem ser associados a várias distribuições. Isso permite manter políticas consistentes de validação de certificados em toda a implantação do CloudFront e, ao mesmo tempo, simplificar o gerenciamento de certificados CA.

## Autoridades de certificação aceitas
<a name="ca-support"></a>

O CloudFront aceita certificados emitidos pela Autoridade de Certificação Privada da AWS e por autoridades de certificação privadas de terceiros. Essa flexibilidade permite que você use sua infraestrutura de certificados atual ou utilize os serviços de certificados gerenciados da AWS com base em seus requisitos organizacionais.
+ **Autoridade de Certificação Privada da AWS:** é possível usar certificados emitidos pela CA Privada da AWS, que fornece um serviço gerenciado de autoridade de certificação privada. Essa integração simplifica o gerenciamento do ciclo de vida do certificado e permite uma integração perfeita com outros serviços da AWS.
+ **Autoridades de certificação privadas de terceiros:** também é possível usar certificados de sua infraestrutura de autoridade de certificação privada atual, inclusive CAs empresariais ou outros provedores de certificados externos. Isso permite que você mantenha seus processos atuais de gerenciamento de certificados e, ao mesmo tempo, adicione os recursos de mTLS do CloudFront.

## Requisitos e especificações do certificado
<a name="certificate-requirements"></a>

Os armazenamentos confiáveis impõem requisitos específicos aos certificados CA que eles contêm:

### Requisitos de formato do certificado CA
<a name="ca-cert-format-requirements"></a>
+ **Formato:** PEM (Privacy Enhanced Mail).
+ **Limites de conteúdo:** os certificados devem estar dentro dos limites -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----.
+ **Comentários:** devem ser precedidos por um caractere \$1 e não devem conter nenhum caractere -.
+ **Quebras de linha:** não são permitidas linhas em branco entre certificados.

### Especificações de certificado permitidas
<a name="supported-cert-specs"></a>
+ **Tipo de certificado:** X.509v3.
+ **Tipos de chave pública:**
  + RSA 2048, RSA 3072, RSA 4096
  + ECDSA: secp256r1, secp384r1
+ **Algoritmos de assinatura:**
  + SHA256, SHA384, SHA512 com RSA
  + SHA256, SHA384, SHA512 com EC
  + SHA256, SHA384, SHA512 com RSASSA-PSS com MGF1

### Exemplo de formato de pacote de certificados
<a name="example-cert-bundle"></a>

Vários certificados (codificados por PEM):

```
# Root CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqiMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
# Intermediate CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqjMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
```

## Criar um armazenamento confiável
<a name="create-trust-store"></a>

Antes de criar um armazenamento confiável, é necessário fazer upload do pacote de certificados CA no formato PEM em um bucket do Amazon S3. O pacote de certificados deve conter todos os certificados CA raiz e intermediários confiáveis necessários para validar certificados de cliente.

O pacote de certificados CA é lido somente uma vez no S3 quando se cria um armazenamento confiável. Se futuras alterações forem feitas no pacote de certificados CA, será necessário atualizar o armazenamento confiável manualmente. Nenhuma sincronização é mantida entre o armazenamento confiável e o pacote de certificados CA do S3.

### Pré-requisitos
<a name="trust-store-prerequisites"></a>
+ Um pacote de certificados da autoridade de certificação (CA) carregado em um bucket do Amazon S3.
+ As permissões necessárias para criar recursos do CloudFront.

### Como criar um armazenamento confiável (console)
<a name="create-trust-store-console"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Armazenamentos confiáveis**.

1. Escolha **Criar armazenamento confiável**.

1. Em **Nome do armazenamento confiável**, insira um nome para o armazenamento confiável.

1. Em **Pacote da autoridade de certificação (CA)**, insira o caminho do Amazon S3 para o pacote de certificados CA no formato PEM.

1. Escolha **Criar armazenamento confiável**.

### Como criar um armazenamento confiável (AWS CLI)
<a name="create-trust-store-cli"></a>

```
aws cloudfront create-trust-store \
  --name MyTrustStore \
  --certificate-authority-bundle-s3-location Bucket=my-bucket,Key=ca-bundle.pem \
  --tags Items=[{Key=Environment,Value=Production}]
```

## Associar o armazenamento confiável a distribuições
<a name="associate-trust-store"></a>

Após a criação de um armazenamento confiável, é necessário associá-lo a uma distribuição do CloudFront para habilitar a autenticação TLS mútua.

### Pré-requisitos
<a name="associate-prerequisites"></a>
+ Uma distribuição existente do CloudFront com a política de protocolo de visualizador somente HTTPS habilitada e o suporte a HTTP3 desabilitado.

### Como associar um armazenamento confiável usando (console)
<a name="associate-trust-store-console"></a>

Há duas formas de associar um armazenamento confiável no console do CloudFront: por meio da página de detalhes do armazenamento confiável ou por meio da página de configurações de distribuição.

**Associar um armazenamento confiável por meio da página de detalhes do armazenamento confiável:**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Armazenamentos confiáveis**.

1. Escolha o nome do armazenamento confiável que você deseja associar.

1. Escolha **Associar a distribuições**.

1. Configure as opções disponíveis de mTLS de visualizador:
   + **Modo de validação de certificados de cliente:** escolha entre o modo obrigatório e o opcional. No modo obrigatório, todos os clientes devem apresentar certificados. No modo opcional, os clientes que apresentam certificados são validados, enquanto os clientes que não apresentam certificados têm acesso permitido.
   + **Anunciar nomes de CA do armazenamento confiável:** escolha se deseja anunciar os nomes de CA em seu armazenamento confiável para clientes durante o handshake do TLS.
   + **Ignorar a data de expiração do certificado:** escolha se deseja permitir conexões com certificados expirados (outros critérios de validação ainda se aplicam).
   + **Função de conexão:** uma função de conexão opcional pode ser associada para permitir/negar conexões com base em outros critérios personalizados.

1. Selecione uma ou mais distribuições para associar ao armazenamento confiável. Apenas distribuições com HTTP3 desabilitado e com comportamentos de cache somente HTTPS permitem mTLS de visualizador.

1. Selecione **Associar**.

**Associar um armazenamento confiável por meio da página de configurações de distribuição:**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Selecione a distribuição que você deseja associar.

1. Na guia **Geral**, no contêiner **Configurações**, escolha **Editar** no canto superior direito.

1. Role até a parte inferior da página, no contêiner **Conectividade**, ative a opção **mTLS de visualizador**.

1. Configure as opções disponíveis de mTLS de visualizador:
   + **Modo de validação de certificados de cliente:** escolha entre o modo obrigatório e o opcional. No modo obrigatório, todos os clientes devem apresentar certificados. No modo opcional, os clientes que apresentam certificados são validados, enquanto os clientes que não apresentam certificados têm acesso permitido.
   + **Anunciar nomes de CA do armazenamento confiável:** escolha se deseja anunciar os nomes de CA em seu armazenamento confiável para clientes durante o handshake do TLS.
   + **Ignorar a data de expiração do certificado:** escolha se deseja permitir conexões com certificados expirados (outros critérios de validação ainda se aplicam).
   + **Função de conexão:** uma função de conexão opcional pode ser associada para permitir/negar conexões com base em outros critérios personalizados.

1. Escolha **Salvar alterações** no canto inferior direito.

### Como associar um armazenamento confiável (AWS CLI)
<a name="associate-trust-store-cli"></a>

Os armazenamentos confiáveis podem ser associados a distribuições por meio da propriedade DistributionConfig.ViewerMtlsConfig. Isso significa que primeiro precisamos buscar a configuração de distribuição e, em seguida, fornecer a ViewerMtlsConfig em uma solicitação UpdateDistribution subsequente.

```
// First fetch the distribution
aws cloudfront get-distribution {DISTRIBUTION_ID}

// Update the distribution config, for example:
Distribution config, file://distConf.json: 
{
  ...other fields,
  ViewerMtlsConfig: {
    Mode: 'required',
    TrustStoreConfig: {
        AdvertiseTrustStoreCaNames: false,
        IgnoreCertificateExpiry: true,
        TrustStoreId: {TRUST_STORE_ID}
    }
  }
}

aws cloudfront update-distribution \
   --id {DISTRIBUTION_ID} \
   --if-match {ETAG} \
   --distribution-config file://distConf.json
```

## Gerenciar armazenamentos confiáveis
<a name="manage-trust-stores"></a>

### Exibir detalhes do armazenamento confiável
<a name="view-trust-store-details"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Armazenamentos confiáveis**.

1. Escolha o nome do armazenamento confiável para visualizar a página de detalhes.

A página de detalhes mostra:
+ nome e ID do armazenamento confiável;
+ número de certificados CA;
+ data de criação e data da última modificação;
+ distribuições associadas.
+ Tags

### Modificar um armazenamento confiável
<a name="modify-trust-store"></a>

Para substituir um pacote de certificados CA:

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Armazenamentos confiáveis**.

1. Escolha o nome do armazenamento confiável.

1. Escolha **Ações** e **Editar**.

1. Em **Pacote de autoridade de certificação (CA)**, insira o local do Amazon S3 do arquivo PEM do pacote de CA atualizado.

1. Escolha **Atualizar armazenamento confiável**.

### Excluir um armazenamento confiável
<a name="delete-trust-store"></a>

**Pré-requisitos:** primeiro, você deve desassociar o armazenamento confiável de todas as distribuições do CloudFront.

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Armazenamentos confiáveis**.

1. Escolha o nome do armazenamento confiável.

1. Escolha **Excluir armazenamento confiável**.

1. Escolha **Delete** para confirmar.

### Próximas etapas
<a name="trust-store-next-steps"></a>

Depois de criar e associar o armazenamento confiável a uma distribuição do CloudFront, você pode continuar habilitando a autenticação TLS mútua em sua distribuição e definir configurações adicionais, como encaminhar cabeçalhos de certificados às suas origens. Para ver instruções detalhadas sobre como habilitar a mTLS em suas distribuições, consulte [Habilitar a TLS mútua para distribuições do CloudFront](enable-mtls-distributions.md).

# Habilitar a TLS mútua para distribuições do CloudFront
<a name="enable-mtls-distributions"></a>

## Pré-requisitos e requisitos
<a name="mtls-prerequisites-requirements"></a>

O modo de verificação mútua de TLS do CloudFront exige que todos os clientes apresentem certificados válidos durante o handshake do TLS e rejeita conexões sem certificados válidos. Antes de habilitar a TLS mútua em uma distribuição do CloudFront, você deve:
+ Criar um armazenamento confiável com certificados de sua autoridade de certificação.
+ Associar o ID do armazenamento confiável à distribuição do CloudFront.
+ Garantir que todos os comportamentos de cache da distribuição usem uma política de protocolo de visualizador somente HTTPS.
+ Verificar se sua distribuição está usando HTTP/2, que é a configuração padrão (não é possível usar HTTP/3 com mTLS de visualizador).

**nota**  
A autenticação TLS mútua requer conexões HTTPS entre visualizadores e o CloudFront. Não é possível habilitar a mTLS em uma distribuição com qualquer comportamento de cache que permita conexões HTTP.

## Habilitar a TLS mútua (console)
<a name="enable-mtls-console"></a>

### Para novas distribuições
<a name="enable-mtls-new-distributions"></a>

Não é possível configurar a mTLS de visualizador no processo de criação de uma distribuição no console do CloudFront. Primeiro, crie a distribuição usando qualquer meio (console, CLI e API) e, em seguida, edite as configurações da distribuição para habilitar a mTLS de visualizador de acordo com as instruções de distribuição abaixo.

### Para distribuições existentes
<a name="enable-mtls-existing-distributions"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Na lista de distribuição, selecione a distribuição a ser modificada.

1. A política de protocolo de visualizador deve estar definida como **Redirecionar HTTP para HTTPS** ou **Somente HTTPS** para todos os comportamentos de cache. (É possível escolher a guia **Comportamentos de cache** para visualizar e atualizar qualquer comportamento de cache com políticas de protocolo HTTP.)

1. Escolha a guia **Geral**.

1. Na seção **Configurações**, escolha **Editar**.

1. Na seção **Conectividade**, encontre **Autenticação mútua (mTLS) de visualizador**.

1. Ative a opção **Habilitar autenticação mútua**.

1. Em **Modo de validação de certificado de cliente**, selecione **Obrigatório** (todos os clientes devem apresentar certificados) ou **Opcional** (os clientes podem apresentar certificados opcionalmente).

1. Em **Armazenamento confiável**, selecione o armazenamento confiável criado anteriormente.

1. (Opcional) Ative a opção **Anunciar nomes de CA do armazenamento confiável** se quiser que o CloudFront envie nomes de CA aos clientes durante o handshake do TLS.

1. (Opcional) Ative a opção **Ignorar a data de expiração do certificado** se quiser permitir conexões com certificados expirados.

1. Escolha **Salvar alterações**.

## Habilitar a TLS mútua (AWS CLI)
<a name="enable-mtls-cli"></a>

### Para novas distribuições
<a name="enable-mtls-cli-new"></a>

O seguinte exemplo mostra como criar um arquivo de configuração de distribuição (distribution-config.json) que inclua configurações de mTLS:

```
{
  "CallerReference": "cli-example-1",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "my-origin",
        "DomainName": "example.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "my-origin",
    "ViewerProtocolPolicy": "https-only",
    "MinTTL": 0,
    "ForwardedValues": {
      "QueryString": false,
      "Cookies": {
        "Forward": "none"
      }
    }
  },
  "ViewerCertificate": {
    "CloudFrontDefaultCertificate": true
  },
  "ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
  },
  "Enabled": true
}
```

Crie a distribuição com a mTLS habilitada usando o seguinte exemplo de comando:

```
aws cloudfront create-distribution --distribution-config file://distribution-config.json
```

### Para distribuições existentes
<a name="enable-mtls-cli-existing"></a>

Obtenha a configuração de distribuição atual usando o seguinte comando de exemplo:

```
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 --output json > dist-config.json
```

Edite o arquivo para adicionar configurações de mTLS. Adicione a seguinte seção de exemplo à configuração da distribuição:

```
"ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
}
```

Remova o campo ETag do arquivo, mas salve o respectivo valor separadamente.

Obtenha a configuração com a nova configuração usando o seguinte comando de exemplo:

```
aws cloudfront update-distribution \
    --id E1A2B3C4D5E6F7 \
    --if-match YOUR-ETAG-VALUE \
    --distribution-config file://dist-config.json
```

## Políticas de protocolo de visualizador
<a name="viewer-protocol-policies"></a>

Ao usar a TLS mútua, todos os comportamentos de cache da distribuição devem ser configurados com uma política de protocolo de visualização somente HTTPS:
+ **Redirecionar HTTP para HTTPS**: redireciona solicitações HTTP para HTTPS antes de realizar a validação do certificado.
+ **Somente HTTPS**: aceita somente solicitações HTTPS e executa a validação do certificado.

**nota**  
Não é possível usar a política de protocolo de visualizador HTTP e HTTPS com TLS mútua, pois as conexões HTTP não podem realizar a validação do certificado.

## Próximas etapas
<a name="enable-mtls-next-steps"></a>

Depois de habilitar o TLS de visualizador em uma distribuição do CloudFront, é possível associar as funções de conexão para implementar uma lógica personalizada de validação de certificados. As funções de conexão permitem estender os recursos integrados de autenticação mTLS com regras de validação personalizadas, verificação de revogação de certificados e registro em log. Para ver detalhes sobre como criar e associar funções de conexão, consulte [Associar uma função de conexão do CloudFront](connection-functions.md).

# Associar uma função de conexão do CloudFront
<a name="connection-functions"></a>

As funções de conexão do CloudFront permitem implementar uma lógica personalizada de validação de certificados durante handshakes do TLS, oferecendo extensões aos recursos integrados de autenticação mTLS.

## O que são funções de conexão?
<a name="what-are-connection-functions"></a>

As funções de conexão são funções JavaScript executadas no handshake do TLS após a validação de certificados de cliente. O certificado de cliente validado é transmitido à função de conexão, momento em que a função de conexão pode determinar se deseja conceder acesso ou não. Para ter informações mais detalhadas sobre como funções de conexão, consulte [Personalizar na borda com o CloudFront Functions](cloudfront-functions.md).

## Como as funções de conexão funcionam com a mTLS
<a name="how-connection-functions-work"></a>

Quando um cliente tenta estabelecer uma conexão mTLS com uma distribuição do CloudFront, ocorre a seguinte sequência de eventos:

1. O cliente inicia o handshake do TLS com o local da borda do CloudFront.

1. O CloudFront solicita e recebe o certificado do cliente.

1. O CloudFront executa a validação padrão do certificado em relação ao armazenamento confiável.

1. Se o certificado passar pela validação padrão, o CloudFront invocará a função de conexão. Se **IgnoreCertificateExpiry** estiver habilitada em **ViewerMtlsConfig**, os certificados expirados, mas válidos, também serão transmitidos à função de conexão. Se os certificados de cliente forem inválidos, as funções de conexão não serão invocadas.

1. A função de conexão recebe informações analisadas do certificado e detalhes da conexão.

1. A função toma a decisão de permitir/negar com base em uma lógica personalizada.

1. O CloudFront conclui ou encerra a conexão TLS com base em sua decisão.

As funções de conexão são invocadas tanto para o modo de verificação quanto para o modo opcional (quando os clientes apresentam certificados).

## Criar uma função de conexão
<a name="create-connection-function"></a>

É possível criar funções de conexão usando o console do CloudFront ou a AWS CLI.

### Como criar uma função de conexão (console)
<a name="create-connection-function-console"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Selecione **Functions ** (Funções) no painel de navegação.

1. Escolha a guia **Funções de conexão** e selecione **Criar função de conexão**.

1. Insira um nome de função que seja exclusivo em sua conta da AWS.

1. Escolha **Continuar**.

1. No editor de funções, escreva o código JavaScript para validação do certificado. O manipulador de função deve chamar allow ou deny.

1. Opcional: um armazenamento KeyValue pode ser associado à função de conexão para implementar o controle de revogação.

1. Escolha **Salvar alterações**.

### Como criar uma função de conexão (AWS CLI)
<a name="create-connection-function-cli"></a>

O seguinte exemplo mostra como criar uma função de conexão:

Escreva o código da função em um arquivo separado (por exemplo, code.js):

```
function connectionHandler(connection) {
  connection.allow();
}
```

```
aws cloudfront create-connection-function \
  --name "certificate-validator" \
  --connection-function-config '{
      "Comment": "Client certificate validation function",
      "Runtime": "cloudfront-js-2.0"
  }' \
  --connection-function-code fileb://code.js
```

## Estrutura do código da função de conexão
<a name="connection-function-code-structure"></a>

As funções de conexão implementam uma função connectionHandler que recebe um objeto de conexão contendo informações de certificado e conexão. A função deve usar `connection.allow()` ou `connection.deny()` para tomar uma decisão sobre a conexão.

### Exemplo de uma função de conexão básica
<a name="basic-connection-function-example"></a>

O seguinte exemplo mostra uma função de conexão simples que verifica o campo de assunto de certificados de cliente:

```
function connectionHandler(connection) {
    // Only process if a certificate was presented
    if (!connection.clientCertificate) {
        console.log("No certificate presented");
        connection.deny();
    }
    
    // Check the subject field for specific organization
    const subject = connection.clientCertificate.certificates.leaf.subject;
    if (!subject.includes("O=ExampleCorp")) {
        console.log("Certificate not from authorized organization");
       connection.deny();
    } else {
        // All checks passed
        console.log("Certificate validation passed");
        connection.allow();
    }
}
```

A especificação completa das propriedades do certificado do cliente disponíveis no objeto de conexão é apresentada aqui:

```
{
  "connectionId": "Fdb-Eb7L9gVn2cFakz7wWyBJIDAD4-oNO6g8r3vXDV132BtnIVtqDA==", // Unique identifier for this TLS connection
  "clientIp": "203.0.113.42", // IP address of the connecting client (IPv4 or IPv6)
  "clientCertificate": {
    "certificates": {
      "leaf": {
        "subject": "CN=client.example.com,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate holder
        "issuer": "CN=Example Corp Intermediate CA,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate authority that issued this certificate
        "serialNumber": "4a:3f:5c:92:d1:e8:7b:6c", // Unique serial number assigned by the issuing CA (hexadecimal)
        "validity": {
          "notBefore": "2024-01-15T00:00:00Z", // Certificate validity start date (ISO 8601 format)
          "notAfter": "2025-01-14T23:59:59Z"   // Certificate expiration date (ISO 8601 format)
        },
        "sha256Fingerprint": "a1b2c3d4e5f6...abc123def456", // SHA-256 hash of the certificate (64 hex characters)
      },
    },
  },
}
```

## Associar uma função de conexão
<a name="associate-connection-function-section"></a>

Depois de criar uma função de conexão, é necessário publicá-la no estágio ATIVO e associá-la à distribuição.

### Como publicar e associar uma função de conexão (console)
<a name="publish-associate-console"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Selecione **Funções** no painel de navegação

1. Escolha a guia **Funções de conexão** e selecione uma função de conexão.

1. Escolha **Publicar** para movê-la para o estágio ATIVO.

1. Escolha **Adicionar associação** na tabela de distribuições associadas abaixo da seção de publicação.

1. Selecione a distribuição com a mTLS de visualizador habilitada que você deseja associar.

Alternativamente, as funções de conexão publicadas também podem ser associadas na página de detalhes da distribuição.

1. Acesse a página inicial do console, na qual todas as suas distribuições estão listadas.

1. Selecione a distribuição que você deseja associar.

1. Escolha a guia **Geral**.

1. Na seção **Configurações**, escolha **Editar**.

1. Na seção **Conectividade**, encontre **Autenticação mútua (mTLS) de visualizador**.

1. Em **Função de conexão**, selecione sua função.

1. Escolha **Salvar alterações**.

### Como associar uma função de conexão (AWS CLI)
<a name="associate-connection-function-cli"></a>

O seguinte exemplo mostra como associar uma função de conexão a uma distribuição:

```
// DistributionConfig:
{
   ...other settings,
    "ConnectionFunctionAssociation": {
        "Id": "cf_30c2CV2elHwCoInb3LtcaUJkZeD"
    }
}
```

## Casos de uso de funções de conexão
<a name="connection-function-use-cases"></a>

As funções de conexão permitem vários casos de uso avançados de mTLS:
+ **Validação de atributos do certificado**: verifique campos específicos nos certificados de cliente, como requisitos da unidade organizacional ou padrões de nome alternativo de assunto.
+ **Verificação de revogação de certificados**: implemente uma verificação personalizada de revogação de certificados usando KeyValueStore para armazenar números de série de certificados revogados.
+ **Políticas de certificado baseadas em IP**: utilize políticas de certificado diferentes com base no endereço IP do cliente ou em restrições geográficas.
+ **Validação de vários locatários**: implemente regras de validação específicas para locatários em que diferentes requisitos de certificado se apliquem com base em nomes de host ou atributos de certificado.

**nota**  
As funções de conexão são executadas uma vez por conexão de cliente durante o handshake do TLS.  
As funções de conexão só podem permitir ou negar conexões, não modificar solicitações/respostas HTTP.  
Somente funções no estágio ATIVO (publicadas) podem ser associadas a distribuições.  
Cada distribuição pode ter no máximo uma função de conexão.

## Próximas etapas
<a name="connection-function-next-steps"></a>

Após a associação de uma função de conexão a uma distribuição do CloudFront, é possível definir configurações opcionais para personalizar o comportamento da implementação de mTLS. Para ver instruções detalhadas sobre como definir configurações adicionais, como um modo opcional de validação de certificados de cliente, consulte [Definir configurações adicionais](configuring-additional-settings.md).

# Definir configurações adicionais
<a name="configuring-additional-settings"></a>

Após a habilitação da autenticação TLS mútua básica, é possível definir configurações adicionais para personalizar o comportamento da autenticação para casos de uso e requisitos específicos.

## Modo opcional de validação de certificados de cliente
<a name="optional-mode"></a>

O CloudFront oferece um modo opcional de validação de certificados de cliente que valida os certificados de cliente que são apresentados, mas permite o acesso aos clientes que não apresentam certificados.

### Comportamento do modo opcional
<a name="optional-mode-behavior"></a>
+ Concede conexão a clientes com certificados válidos (certificados inválidos são negados).
+ Permite a conexão com clientes sem certificados.
+ Permite cenários variados de autenticação de clientes por meio de uma única distribuição.

O modo opcional é ideal em migrações graduais para a autenticação mTLS, pois permite clientes com certificados e clientes sem certificados ou mantém a compatibilidade com versões anteriores de clientes legados.

**nota**  
No modo opcional, as funções de conexão são invocadas mesmo quando os clientes não apresentam certificados. Isso permite que você implemente uma lógica personalizada, como registrar em log o endereço IP dos clientes ou aplicar políticas diferentes com base na apresentação ou não de certificados.

### Como configurar o modo opcional (console)
<a name="configure-optional-mode-console"></a>

1. Nas configurações de distribuição, acesse a guia **Geral** e escolha **Editar**.

1. Role até a seção **Autenticação mútua (mTLS) de visualizador** no contêiner **Conectividade**.

1. Em **Modo de validação de certificados de cliente**, selecione **Opcional**.

1. Salve as alterações.

### Como configurar o modo opcional (AWS CLI)
<a name="configure-optional-mode-cli"></a>

O seguinte exemplo mostra como configurar um o modo opcional:

```
"ViewerMtlsConfig": {
   "Mode": "optional",
   ...other settings
}
```

## Anúncio da autoridade de certificação
<a name="ca-advertisement"></a>

O campo AdvertiseTrustStoreCaNames controla se o CloudFront envia a lista de nomes de CA confiáveis aos clientes durante o handshake do TLS, ajudando os clientes a selecionar o certificado apropriado.

### Como configurar o anúncio da CA (console)
<a name="configure-ca-advertisement-console"></a>

1. Nas configurações de distribuição, acesse a guia **Geral** e escolha **Editar**.

1. Role até a seção **Autenticação mútua (mTLS) de visualizador** no contêiner **Conectividade**.

1. Marque ou desmarque a caixa de seleção **Anunciar nomes de CA do armazenamento confiável**.

1. Escolha **Salvar alterações**.

### Como configurar o anúncio da CA (AWS CLI)
<a name="configure-ca-advertisement-cli"></a>

O seguinte exemplo mostra como habilitar o anúncio da CA:

```
"ViewerMtlsConfig": {
   "Mode": "required", // or "optional"
   "TrustStoreConfig": {
      "AdvertiseTrustStoreCaNames": true,
      ...other settings
   } 
}
```

## Tratamento de expiração de certificados
<a name="certificate-expiration-handling"></a>

A propriedade IgnoreCertificateExpiry determina como o CloudFront responde a certificados de cliente expirados. Por padrão, o CloudFront rejeita certificados de clientes expirados, mas é possível configurá-lo para aceitá-los quando necessário. Normalmente, essa opção é habilitada para dispositivos com certificados expirados que não podem ser atualizados imediatamente.

### Como configurar o tratamento de expiração de certificados (console)
<a name="configure-expiration-console"></a>

1. Nas configurações de distribuição, acesse a guia **Geral** e escolha **Editar**.

1. Role até a seção **Autenticação mútua (mTLS) de visualizador** no contêiner **Conectividade**.

1. Marque ou desmarque a caixa de seleção **Ignorar a data de expiração do certificado**.

1. Escolha **Salvar alterações**.

### Como configurar o tratamento de expiração de certificados (AWS CLI)
<a name="configure-expiration-cli"></a>

O seguinte exemplo mostra como ignorar a expiração de certificados:

```
"ViewerMtlsConfig": {
  "Mode": "required", // or "optional"
  "TrustStoreConfig": {
     "IgnoreCertificateExpiry": false,
     ...other settings
  }
}
```

**nota**  
**IgnoreCertificateExpiry** aplica-se somente à data de validade dos certificados. Todas as outras verificações de validação de certificados ainda se aplicam (como cadeia de confiança e validação de assinatura).

## Próximas etapas
<a name="additional-settings-next-steps"></a>

Depois de definir as configurações adicionais, você pode configurar o encaminhamento de cabeçalhos transmitir as informações do certificado às suas origens, implementar a revogação do certificado usando as funções de conexão e o KeyValueStore e habilitar os logs de conexão para monitoramento. Para ver detalhes sobre como encaminhar as informações do certificado às origens, consulte [Encaminhar cabeçalhos às origens](viewer-mtls-headers.md).

# Cabeçalhos mTLS de visualizador para políticas de cache e encaminhados à origem
<a name="viewer-mtls-headers"></a>

Ao usar a autenticação TLS mútua, o CloudFront pode extrair informações dos certificados de cliente e encaminhá-las às origens como cabeçalhos HTTP. Isso permite que os servidores de origem acessem detalhes do certificado sem implementar a respectiva lógica de validação.

Os seguintes cabeçalhos estão disponíveis para a criação de comportamentos de cache:


| Nome do cabeçalho | Descrição | Valor de exemplo | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Serial-Number | Representação hexadecimal do número de série do certificado. | 4a:3f:5c:92:d1:e8:7b:6c | 
| CloudFront-Viewer-Cert-Issuer | Representação de string RFC2253 do nome distinto (DN) do emissor. | CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=US | 
| CloudFront-Viewer-Cert-Subject | Representação de string RFC2253 do nome distinto (DN) do assunto. | CN=client\$1.com,OU=client-3,O=mTLS,ST=Washington,C=US | 
| CloudFront-Viewer-Cert-Present | Pode ser 1 (presente) ou 0 (não presente) para indicar se o certificado está ou não presente. Esse valor é sempre 1 no modo Obrigatório. | 1 | 
| CloudFront-Viewer-Cert-Sha256 | O hash SHA256 do certificado de cliente. | 01fbf94fef5569753420c349f49adbfd80af5275377816e3ab1fb371b29cb586 | 

Para solicitações à origem, além dos cabeçalhos acima disponíveis para comportamentos de cache dois cabeçalhos adicionais são fornecidos:


| Nome do cabeçalho | Descrição | Valor de exemplo | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Validity | Formato ISO8601 da data notBefore e notAfter. | CloudFront-Viewer-Cert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z | 
| CloudFront-Viewer-Cert-Pem | Formato PEM codificado em URL do certificado de entidade final. | CloudFront-Viewer-Cert-Pem: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A | 

## Configurar o encaminhamento de cabeçalhos
<a name="configure-header-forwarding"></a>

### Console
<a name="configure-headers-console"></a>

No modo de verificação, o CloudFront adiciona automaticamente os cabeçalhos CloudFront-Viewer-Cert-\$1 a todas as solicitações de visualizador. Para encaminhar todos os cabeçalhos à origem:

1. Na página principal “Listar distribuições”, selecione a distribuição com mTLS de visualizador habilitada e acesse a guia **Comportamentos**.

1. Selecione o comportamento de cache e escolha **Editar**.

1. Na seção **Política de solicitação à origem**, escolha **Criar política** ou selecione uma política existente

1. Os seguintes cabeçalhos devem estar incluídos na política de solicitação à origem:
   + CloudFront-Viewer-Cert-Serial-Number
   + CloudFront-Viewer-Cert-Issuer
   + CloudFront-Viewer-Cert-Subject
   + CloudFront-Viewer-Cert-Present
   + CloudFront-Viewer-Cert-Sha256
   + CloudFront-Viewer-Cert-Validity
   + CloudFront-Viewer-Cert-Pem

1. Escolha **Criar** (para novas políticas) ou **Salvar alterações** (para políticas existentes).

1. Selecione a política em seu comportamento de cache e salve as alterações.

### Usar a AWS CLI
<a name="configure-headers-cli"></a>

O seguinte exemplo mostra como criar uma política de solicitação à origem que inclua cabeçalhos mTLS para o modo de verificação:

```
aws cloudfront create-origin-request-policy \
  --origin-request-policy-config '{
    "Name": "MTLSHeadersPolicy",
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": {
        "Quantity": 5,
        "Items": [
          "CloudFront-Viewer-Cert-Serial-Number",
          "CloudFront-Viewer-Cert-Issuer",
          "CloudFront-Viewer-Cert-Subject",
          "CloudFront-Viewer-Cert-Validity",
          "CloudFront-Viewer-Cert-Pem"
        ]
      }
    },
    "CookiesConfig": {
      "CookieBehavior": "none"
    },
    "QueryStringsConfig": {
      "QueryStringBehavior": "none"
    }
  }'
```

## Considerações sobre processamento de cabeçalhos
<a name="header-processing-considerations"></a>

Ao trabalhar com cabeçalhos de certificados, considere estas práticas recomendadas:
+ **Validação do cabeçalho:** verifique os valores do cabeçalho do certificado em sua origem como uma medida de segurança adicional.
+ **Limites de tamanho do cabeçalho:** como os cabeçalhos de certificado PEM podem ser grandes, confirme se seu servidor de origem consegue processá-los.
+ **Considerações sobre cache:** o uso de cabeçalhos de certificado na chave de cache aumenta a fragmentação do cache.
+ **Solicitações entre origens:** se sua aplicação usar CORS, talvez seja necessário configurá-la para permitir os cabeçalhos do certificado.

## Próximas etapas
<a name="headers-next-steps"></a>

Depois de configurar o encaminhamento de cabeçalhos, você pode implementar a verificação de revogação de certificados usando funções de conexão e o KeyValueStore do CloudFront. Para ver detalhes sobre a implementação de verificações de revogação, consulte [Revogação usando a função de conexão e o KVS do CloudFront](revocation-connection-function-kvs.md).

# Revogação usando a função de conexão e o KVS do CloudFront
<a name="revocation-connection-function-kvs"></a>

É possível implementar a verificação de revogação de certificados para autenticação TLS mútua associando funções de conexão e o KeyValueStore do CloudFront. Essa abordagem oferece um mecanismo de revogação de certificados escalável e em tempo real que complementa a validação de certificados integrada do CloudFront.

Funções de conexão são funções em JavaScript executadas durante o estabelecimento da conexão TLS nos locais da borda do CloudFront que permitem implementar uma lógica de validação de certificados personalizada para autenticação mTLS. Para ter informações mais detalhadas sobre como funções de conexão, consulte [Associar uma função de conexão do CloudFront](connection-functions.md).

## Como a revogação de certificados funciona com as funções de conexão
<a name="how-revocation-works"></a>

A validação padrão de certificados do CloudFront verifica a cadeia de certificados, a assinatura e a expiração, mas não inclui a verificação integrada de revogação de certificados. Por meio de funções de conexão, é possível implementar a verificação de revogação personalizada durante o handshake do TLS.

O processo de revogação de certificados funciona da seguinte maneira:

1. O número de série dos certificados revogados é armazenado em um KeyValueStore do CloudFront.

1. Quando um cliente apresenta um certificado, a função de conexão é invocada.

1. A função compara o número de série do certificado com o número presente no KeyValueStore.

1. Se o número de série for encontrado no armazenamento, o certificado será revogado.

1. A função nega a conexão para certificados revogados.

Essa abordagem oferece uma verificação de revogação quase em tempo real na rede de borda global do CloudFront.

## Configurar o KeyValueStore para certificados revogados
<a name="setup-kvs-revoked-certs"></a>

Primeiro, crie um KeyValueStore para armazenar os números de série dos certificados revogados:

### Como criar um KeyValueStore (console)
<a name="create-kvs-console"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, selecione **Armazenamentos de chave-valor**.

1. Selecione **Criar armazenamento de chave-valor**.

1. Insira um nome para o armazenamento de chave-valor (p. ex., certificados revogados).

1. (Opcional) Adicione uma descrição.

1. Selecione **Criar armazenamento de chave-valor**.

### Como criar um KeyValueStore (AWS CLI)
<a name="create-kvs-cli"></a>

O seguinte exemplo mostra como criar um KeyValueStore:

```
aws cloudfront create-key-value-store \
  --name "revoked-certificates" \
  --comment "Store for revoked certificate serial numbers"
```

## Importar números de série de certificados revogados
<a name="import-revoked-serials"></a>

Após a criação de um KeyValueStore, é necessário importar o número de série dos certificados revogados:

### Preparar os dados de revogação
<a name="prepare-revocation-data"></a>

Crie um arquivo JSON com o número de série dos certificados revogados:

```
{
  "data": [
    {
      "key": "ABC123DEF456",
      "value": ""
    },
    {
      "key": "789XYZ012GHI",
      "value": ""
    }
  ]
}
```

### Importar do S3
<a name="import-from-s3"></a>

1. Faça upload do arquivo JSON em um bucket do S3.

1. Importe o arquivo para o KeyValueStore:

   ```
   aws cloudfront create-key-value-store \
     --name "revoked-certificates" \
     --import-source '{
       "SourceType": "S3",
       "SourceARN": "arn:aws:s3:::amzn-s3-demo-bucket1/revoked-serials.json"
     }'
   ```

## Criar uma função de conexão para verificação de revogação
<a name="create-revocation-connection-function"></a>

Crie uma função de conexão que compare o número de série dos certificados com os números presentes no KeyValueStore:

### Exemplo de código de função de conexão
<a name="revocation-function-example"></a>

O seguinte exemplo mostra uma função de conexão que realiza a verificação de revogação de certificados:

```
import cf from 'cloudfront';

async function connectionHandler(connection) {
    const kvsHandle = cf.kvs();
    
    // Get client certificate serial number
    const clientSerialNumber = connection.clientCertificate.certificates.leaf.serialNumber;
    
    // Check if the serial number exists in the KeyValueStore
    const isRevoked = await kvsHandle.exists(clientSerialNumber.replaceAll(':', ''));
    
    if (isRevoked) {
        console.log(`Certificate ${clientSerialNumber} is revoked. Denying connection.`);
        connection.logCustomData(`REVOKED:${clientSerialNumber}`);
        connection.deny();
    } else {
        console.log(`Certificate ${clientSerialNumber} is valid. Allowing connection.`);
        connection.allow();
    }
    
}
```

### Como criar a função de conexão (AWS CLI)
<a name="create-revocation-function-cli"></a>

O seguinte exemplo mostra como criar uma função de conexão associada ao KeyValueStore:

```
aws cloudfront create-connection-function \
  --name "revocation-checker" \
  --connection-function-config '{
      "Comment": "Certificate revocation checking function",
      "Runtime": "cloudfront-js-2.0",
      "KeyValueStoreAssociations": {
          "Quantity": 1,
          "Items": [
              {
                  "KeyValueStoreARN": "arn:aws:cloudfront::123456789012:key-value-store/revoked-certificates"
              }
          ]
      }
  }' \
  --connection-function-code fileb://revocation-checker.js
```

## Associar a função à sua distribuição
<a name="associate-revocation-function"></a>

Depois de criar e publicar a função de conexão, associe-a à sua distribuição do CloudFront habilitada para mTLS, conforme descrito na seção [Associar uma função de conexão do CloudFront](connection-functions.md).

# Observabilidade por meio de logs de conexão
<a name="connection-logs"></a>

Os logs de conexão do CloudFront oferecem evidências detalhadas dos eventos de autenticação TLS mútua, permitindo o monitoramento da validação de certificados, o acompanhamento das tentativas de conexão e a solução de problemas de autenticação.

## O que são logs de conexão?
<a name="what-are-connection-logs"></a>

Os logs de conexão capturam informações detalhadas sobre handshakes do TLS e validação de certificados para distribuições habilitadas para TLS mútua. Diferentemente dos logs de acesso padrão que registram informações de solicitação HTTP, os logs de conexão se concentram especificamente em fatores da fase de estabelecimento da conexão TLS, como:
+ status da conexão (êxito/falha);
+ detalhes do certificado do cliente;
+ protocolo TLS e informações sobre cifras;
+ métricas de tempo de conexão;
+ dados personalizados das funções de conexão.

Esses logs oferecem ampla visibilidade dos eventos de autenticação baseados em certificados, o que ajuda a monitorar a segurança, solucionar problemas e atender aos requisitos de conformidade.

## Habilitar logs de conexão
<a name="enable-connection-logs"></a>

Os logs de conexão estão disponíveis somente para distribuições com a autenticação TLS mútua habilitada. É possível enviar logs de conexão a vários destinos, como CloudWatch Logs, Amazon Data Firehose e Amazon S3.

### Pré-requisitos
<a name="connection-logs-prerequisites"></a>

Antes de habilitar os logs de conexão:
+ Configure a autenticação TLS mútua para a distribuição do CloudFront.
+ Habilite os logs de conexão para a distribuição do CloudFront.
+ Verifique se você tem as permissões necessárias para o destino de registro em log escolhido.
+ Para entrega entre contas, configure as políticas apropriadas do IAM.

### Como habilitar os logs de conexão (console)
<a name="enable-connection-logs-console"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Na lista de distribuição, selecione sua distribuição habilitada para mTLS.

1. Escolha a guia **Logging** (Registrar em log).

1. Escolha **Adicionar**.

1. Selecione o serviço para receber os logs:
   + **CloudWatch Logs**
   + **Firehose**
   + **Amazon S3**

1. Em **Destino**, selecione o recurso para o serviço escolhido:
   + Para o CloudWatch Logs, insira o **nome do grupo de logs**.
   + Para o Firehose, selecione **Fluxo de entrega do Firehose**.
   + Para o Amazon S3, insira o **nome do bucket** (adicionando, opcionalmente, um prefixo).

1. (Opcional) Configurar definições adicionais:
   + **Seleção de campo:** selecione campos de log específicos a serem incluídos.
   + **Formato de saída:** escolha entre JSON, Plain, w3c, Raw ou Parquet (somente no S3).
   + **Delimitador de campo:** especifique como separar os campos de log.

1. Selecione **Save changes** (Salvar alterações)

### Como habilitar os logs de conexão (AWS CLI)
<a name="enable-connection-logs-cli"></a>

O seguinte exemplo mostra como habilitar os logs de conexão usando a API do CloudWatch:

```
# Step 1: Create a delivery source
aws logs put-delivery-source \
  --name "cf-mtls-connection-logs" \
  --resource-arn "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7" \
  --log-type CONNECTION_LOGS

# Step 2: Create a delivery destination
aws logs put-delivery-destination \
  --name "s3-destination" \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket1"

# Step 3: Create the delivery
aws logs create-delivery \
  --delivery-source-name "cf-mtls-connection-logs" \
  --delivery-destination-arn "arn:aws:logs:us-east-1:123456789012:delivery-destination:s3-destination"
```

**nota**  
Ao usar a API do CloudWatch, é necessário especificar a região Leste dos EUA (Norte da Virgínia) (us-east-1), mesmo ao entregar logs a outras regiões.

## Campos de log de conexão
<a name="connection-log-fields"></a>

Os logs de conexão incluem informações detalhadas sobre cada tentativa de conexão TLS:


| Campo | Descrição | Exemplo | 
| --- | --- | --- | 
| eventTimestamp | Carimbo de data/hora no formato ISO 8601 indicando quando a conexão foi estabelecida ou falhou. | 1731620046814 | 
| connectionId | Identificador exclusivo para a conexão TLS. | oLHiEKbQSn8lkvJfA3D4gFowK3\$1iZ0g4i5nMUjE1Akod8TuAzn5nzg== | 
| connectionStatus |  Status da tentativa de conexão mTLS.  | Success ou Failed | 
| clientIp | Endereço IP do cliente que está se conectando. | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 
| clientPort | Porta usada pelo cliente. | 12137 | 
| serverIp | Endereço IP do servidor de borda do CloudFront. | 99.84.71.136 | 
| distributionId | ID da distribuição do CloudFront. | E2DX1SLDPK0123 | 
| distributionTenantId | ID do locatário da distribuição do CloudFront (quando aplicável). | dt\$12te1Ura9X3R2iCGNjW123 | 
| tlsProtocol | Versão do protocolo TLS. | TLSv1.3 | 
| tlsCipher | Conjunto de cifras TLS usado para a conexão. | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| tlsHandshakeDuration | Duração do handshake do TLS em milissegundos. | 153 | 
| tlsSni | Valor da Indicação de Nome de Servidor do handshake do TLS. | d111111abcdef8.cloudfront.net | 
| clientLeafCertSerialNumber | Número de série do certificado do cliente. | 00:b1:43:ed:93:d2:d8:f3:9d | 
| clientLeafCertSubject | Campo de assunto do certificado do cliente. | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=client.test.mtls.net | 
| clientLeafCertIssuer | Campo do emissor do certificado do cliente. | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=test.mtls.net | 
| clientLeafCertValidity | Período de validade do certificado do cliente. | NotBefore=2025-06-05T23:28:21Z;NotAfter=2125-05-12T23:28:21Z | 
| connectionLogCustomData | Dados personalizados adicionados por meio de funções de conexão. | REVOKED:00:b1:43:ed:93:d2:d8:f3:9d | 

## Códigos de erro de conexão
<a name="connection-error-codes"></a>

```
Failed:ClientCertMaxChainDepthExceeded
Failed:ClientCertMaxSizeExceeded
Failed:ClientCertUntrusted
Failed:ClientCertNotYetValid
Failed:ClientCertExpired
Failed:ClientCertTypeUnsupported
Failed:ClientCertInvalid
Failed:ClientCertIntentInvalid
Failed:ClientCertRejected
Failed:ClientCertMissing
Failed:TcpError
Failed:TcpTimeout
Failed:ConnectionFunctionError
Failed:ConnectionFunctionDenied
Failed:Internal
Failed:UnmappedConnectionError
```

Quando as conexões falham, o CloudFront registra códigos de motivo específicos:


| Código | Descrição | 
| --- | --- | 
| ClientCertMaxChainDepthExceeded | Profundidade máxima da cadeia de certificados excedida. | 
| ClientCertMaxSizeExceeded | Tamanho máximo do certificado excedido. | 
| ClientCertUntrusted | O certificado não é confiável. | 
| ClientCertNotYetValid | O certificado ainda não é válido. | 
| ClientCertExpired | O certificado está vencido. | 
| ClientCertTypeUnsupported | O tipo de certificado não é compatível. | 
| ClientCertInvalid | O certificado é inválido. | 
| ClientCertIntentInvalid | A intenção do certificado é inválida. | 
| ClientCertRejected | Certificado rejeitado por validação personalizada. | 
| ClientCertMissing | O certificado não existe. | 
| TcpError |  Ocorreu um erro ao tentar estabelecer uma conexão.  | 
| TcpTimeout |  Não foi possível estabelecer a conexão dentro do período de tempo limite.  | 
| ConnectionFunctionError |  Uma exceção não detectada foi lançada durante a execução da função de conexão.  | 
| Interno |  Ocorreu um erro interno de serviço.  | 
| UnmappedConnectionError |  Ocorreu um erro que não se enquadra em nenhuma das outras categorias.  | 

# TLS mútua de origem com o CloudFront
<a name="origin-mtls-authentication"></a>

A autenticação TLS mútua (autenticação Transport Layer Security mútua ou mTLS) é um protocolo de segurança que estende a autenticação TLS padrão exigindo autenticação bidirecional baseada em certificado, em que tanto o cliente quanto o servidor devem provar sua identidade antes de estabelecer uma conexão segura.

## mTLS de visualizador versus mTLS de origem
<a name="viewer-mtls-vs-origin-mtls"></a>

A autenticação mútua (mTLS) pode ser habilitada entre os visualizadores e a distribuição do CloudFront (mTLS de visualizador) e/ou também entre a distribuição do CloudFront e a origem (mTLS de origem). Esta documentação refere-se à configuração de mTLS de origem. Para ter informações sobre a configuração de mTLS de visualizador, consulte [Autenticação TLS mútua com o CloudFront (mTLS de visualizador)TLS mútua de origem com o CloudFront](mtls-authentication.md).

A mTLS de origem permite que o CloudFront se autentique em servidores de origem usando certificados de cliente. Com a mTLS de origem, é possível garantir que somente as distribuições autorizadas do CloudFront estabeleçam conexões com os servidores de aplicações, o que ajuda a oferecer proteção contra tentativas de acesso não autorizado.

**nota**  
Em conexões mTLS de origem, o CloudFront atua como cliente e apresenta o respectivo certificado de cliente ao servidor de origem durante o handshake do TLS. O CloudFront não realiza a confirmação da validade ou do status de revogação do certificado do cliente. Isso é responsabilidade do servidor de origem. A infraestrutura de origem deve ser configurada para validar o certificado do cliente com relação ao armazenamento confiável, verificar a expiração do certificado e realizar verificações de revogação (como validação de CRL ou OCSP) de acordo com os requisitos de segurança. A função do CloudFront se limita à apresentação do certificado. Toda a lógica de validação de certificados e todas as políticas de segurança são aplicadas pelos servidores de origem.

## Como funciona
<a name="how-origin-mtls-works"></a>

Em um handshake do TLS padrão entre o CloudFront e a origem, somente o servidor de origem apresenta um certificado para provar sua identidade ao CloudFront. Com a mTLS de origem, o processo de autenticação é bidirecional. Quando o CloudFront tenta se conectar ao servidor de origem, ele apresenta um certificado de cliente durante o handshake do TLS. O servidor de origem valida esse certificado com relação ao armazenamento confiável antes de estabelecer a conexão segura.

## Casos de uso
<a name="origin-mtls-use-cases"></a>

A mTLS de origem atende a vários cenários críticos de segurança em que os métodos tradicionais de autenticação criam custos operacionais indiretos:
+ **Segurança em ambiente híbrido e multinuvem**: é possível proteger conexões entre o CloudFront e origens hospedadas fora da AWS ou origens públicas na AWS. Isso elimina a necessidade de gerenciar listas de permissões de IP ou soluções de cabeçalho personalizadas, oferecendo autenticação consistente baseada em certificados na AWS, em data centers on-premises e em provedores terceiros. Empresas de mídia, varejistas e empresas que operam infraestrutura distribuída se beneficiam de controles de segurança padronizados em toda a infraestrutura.
+ **API B2B e segurança de backend**: é possível proteger suas APIs e microsserviços de backend contra tentativas de acesso direto e, ao mesmo tempo, manter os benefícios de desempenho do CloudFront. Plataformas de SaaS, sistemas de processamento de pagamentos e aplicações empresarias com requisitos rígidos de autenticação podem verificar se as solicitações de API se originam somente de distribuições autorizadas do CloudFront, evitando ataques man-in-the-middle e tentativas de acesso não autorizado.

## Importante: requisitos do servidor de origem
<a name="important-origin-server-requirements"></a>

A mTLS de origem exige que os servidores de origem sejam configurados para permitir autenticação TLS mútua. A infraestrutura de origem deve ser capaz de:
+ Solicitar e validar certificados de cliente durante handshakes do TLS.
+ Manter um armazenamento confiável com os certificados da autoridade de certificação que emitiu os certificados de cliente do CloudFront.
+ Registrar e monitorar eventos de conexão TLS mútua.
+ Gerenciar políticas de validação de certificados e lidar com falhas de autenticação.

O CloudFront gerencia a apresentação de certificados do lado do cliente, mas os servidores de origem são responsáveis por validar esses certificados e gerenciar a conexão TLS mútua. Para habilitar a mTLS de origem no CloudFront, a infraestrutura de origem deve estar configurada corretamente.

## Introdução
<a name="how-origin-mtls-getting-started"></a>

Para implementar a mTLS de origem com o CloudFront, será necessário importar o certificado do cliente no AWS Certificate Manager, configurar o servidor de origem para exigir a TLS mútua e habilitar a mTLS de origem na distribuição do CloudFront. As seções a seguir oferecem instruções detalhadas para cada tarefa de configuração.

**Topics**
+ [mTLS de visualizador versus mTLS de origem](#viewer-mtls-vs-origin-mtls)
+ [Como funciona](#how-origin-mtls-works)
+ [Casos de uso](#origin-mtls-use-cases)
+ [Importante: requisitos do servidor de origem](#important-origin-server-requirements)
+ [Introdução](#how-origin-mtls-getting-started)
+ [Gerenciamento de certificados com o AWS Certificate Manager](origin-certificate-management-certificate-manager.md)
+ [Habilitar a TLS mútua de origem para distribuições do CloudFront](origin-enable-mtls-distributions.md)
+ [Usar o CloudFront Functions com a TLS mútua de origem](origin-mtls-cloudfront-functions.md)

# Gerenciamento de certificados com o AWS Certificate Manager
<a name="origin-certificate-management-certificate-manager"></a>

O [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) armazena os certificados de cliente que o CloudFront apresenta aos servidores de origem durante a autenticação TLS mútua de origem.

## Autoridades de certificação aceitas
<a name="origin-ca-support"></a>

A mTLS de origem do CloudFront exige certificados de cliente com uso estendido de chave (EKU) para autenticação de cliente TLS. Devido a esse requisito, é necessário emitir certificados da autoridade de certificação e importá-los para o AWS Certificate Manager. Os recursos automáticos de provisionamento e renovação de certificados do ACM não estão disponíveis para certificados de cliente de mTLS de origem. A mTLS de origem do CloudFront atende a certificados de cliente de duas origens:
+ **Autoridade de Certificação Privada da AWS:** é possível emitir certificados da CA Privada da AWS usando modelos de certificado que incluem autenticação de cliente TLS no campo “Uso estendido de chave” (como o modelo EndEntityClientAuthCertificate). Depois de emitir o certificado da CA Privada da AWS, você deve importá-lo para o ACM na região Leste dos EUA (Norte da Virgínia) (us-east-1). Essa abordagem oferece os benefícios de segurança da CA Privada da AWS, bem como controle sobre o gerenciamento do ciclo de vida dos certificados.
+ **Autoridades de certificação privadas de terceiros:** também é possível emitir certificados de sua infraestrutura de autoridade de certificação privada existente e importá-los para o ACM. Isso permite que você mantenha seus processos atuais de gerenciamento de certificados e, ao mesmo tempo, utilize os recursos de mTLS de origem do CloudFront. Os certificados devem incluir a autenticação de cliente TLS no campo “Uso estendido de chave” e precisam estar no formato PEM, com o certificado, a chave privada e a cadeia de certificados.

**Importante**  
Tanto para a CA Privada da AWS quanto para CAs de terceiros, você é responsável por monitorar as datas de expiração dos certificados e importar certificados renovados para o ACM antes da expiração. O recurso de renovação automática do ACM não se aplica a certificados importados usados para mTLS de origem.

## Requisitos e especificações do certificado
<a name="origin-certificate-requirements"></a>

### Requisitos dos certificados de cliente
<a name="origin-ca-cert-format-requirements"></a>
+ **Formato:** PEM (Privacy Enhanced Mail).
+ **Componentes:** certificado, chave privada e cadeia de certificados.
+ **Profundidade máxima da cadeia de certificados:** 3 (certificado de entidade final \$1 certificado intermediário \$1 certificado raiz).
+ **Tamanho máximo da cadeia de certificados:** 64 KB.
+ **Tamanho do certificado:** não pode ser superior a 96 KB.
+ **Tamanho máximo da chave privada:** 5 KB (restrição do ACM).
+ **Máximo de ARNs exclusivos de certificados mTLS de origem que podem ser adicionados ou modificados por chamada de API de criação ou atualização da distribuição do CloudFront**: 5.
+ **Região: os certificados devem ser armazenados no ACM na região** Leste dos EUA (Norte da Virgínia) (us-east-1).

### Especificações de certificado permitidas
<a name="origin-supported-cert-specs"></a>
+ **Tipo de certificado:** X.509v3.
+ **Algoritmos de chave pública:**
  + RSA: 2.048 bits.
  + ECDSA: P-256.
+ **Algoritmos de assinatura:**
  + SHA256, SHA384, SHA512 com RSA
  + SHA256, SHA384, SHA512 com ECDSA.
  + SHA256, SHA384, SHA512 com RSASSA-PSS com MGF1
+ **Uso estendido de chave (obrigatório):** o certificado requer a extensão de uso estendido da chave (EKU) definida como autenticação de cliente TLS, o que garante que ele seja autorizado para fins de mTLS.

### Requisitos dos certificados de servidor
<a name="origin-server-certificate-requirements"></a>

Os servidores de origem devem apresentar certificados de autoridades de certificação confiáveis publicamente durante o handshake de TLS mútua. Para ver detalhes sobre os requisitos dos certificados de servidor de origem, consulte [Requisitos para usar certificados SSL/TLS com o CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate).

### Solicitar ou importar um certificado
<a name="origin-request-import-certificate"></a>

Para habilitar a mTLS de origem, é necessário ter um certificado de cliente disponível no ACM.

#### Solicitar e importar um certificado da CA Privada da AWS
<a name="request-certificate-aws-private-ca"></a>

Pré-requisitos:
+ Uma Autoridade de Certificação Privada da AWS configurada em sua conta.
+ Permissão para emitir certificados da CA Privada da AWS.
+ Permissão para importar certificados para o ACM.
+ Um ARN de [modelo de certificado](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) com `Extended key usage:TLS web client authentication` adequado ao seu caso de uso.
+ Instalação do OpenSSL, da AWS CLI e do jq (para análise de JSON).

##### Como solicitar um certificado da CA privada e importar para o ACM (AWS CLI)
<a name="request-certificate-cli"></a>

1. Defina o ARN da CA privada em uma variável para facilitar a reutilização.

   ```
   PCA_ARN="arn:aws:acm-pca:region:account:certificate-authority/12345678..."
   ```

1. Use o OpenSSL para gerar uma chave privada ECDSA P-256 (curva prime256v1) e uma solicitação de assinatura de certificado (CSR), o que garante que o sinalizador -nodes seja usado para manter a chave privada não criptografada, conforme exigido para a importação do ACM.

   ```
   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
       -keyout private.key \
       -out request.csr \
       -subj "/CN=client.example.com"
   ```

1. Envie a CSR à CA Privada da AWS para emitir um certificado e obter o ARN do certificado recém-emitido.

   ```
   CERT_ARN=$(aws acm-pca issue-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --csr fileb://request.csr \
       --signing-algorithm "SHA256WITHECDSA" \
       --validity Value=365,Type="DAYS" \
       --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
       --query 'CertificateArn' --output text)
   ```

1. Recupere o pacote de certificados da CA Privada da AWS usando o comando get-certificate, que exibe o certificado de entidade final e a cadeia, e use o jq para separá-los em arquivos distintos.

   ```
   # Retrieve the full certificate bundle in JSON format
   aws acm-pca get-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --certificate-arn "$CERT_ARN" \
       --output json > full_cert.json
   
   # Split into Leaf and Chain
   jq -r '.Certificate' full_cert.json > leaf_cert.pem
   jq -r '.CertificateChain' full_cert.json > cert_chain.pem
   ```

1. Importe a chave privada não criptografada, o certificado de entidade final e a cadeia de certificados para o AWS Certicate Manager, usando o protocolo fileb:// para manipular corretamente os dados do arquivo binário na CLI.

   ```
   aws acm import-certificate \
       --certificate fileb://leaf_cert.pem \
       --private-key fileb://private.key \
       --certificate-chain fileb://cert_chain.pem \
       --region us-east-1 \
       --query 'CertificateArn' \
       --output text
   ```

#### Importar um certificado de uma CA de terceiros
<a name="import-certificate-third-party-ca"></a>

Pré-requisitos:
+ O certificado, a chave privada não criptografada e a cadeia de certificados da autoridade de certificação devem ser codificados em PEM.
+ O certificado deve incluir o uso estendido de chave para autenticação de cliente TLS.
+ Permissões para importar certificados no ACM.

##### Como importar um certificado para o ACM (AWS CLI).
<a name="import-certificate-cli"></a>

```
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text
```

#### Próximas etapas
<a name="certificate-next-steps"></a>

Depois de obter ou importar o certificado de cliente no ACM, você pode configurar o servidor de origem para exigir a autenticação TLS mútua e habilitar a mTLS de origem na distribuição do CloudFront. Para ver instruções sobre como habilitar a mTLS de origem no CloudFront, consulte a próxima seção, “Habilitar a TLS mútua de origem para distribuições do CloudFront”.

# Habilitar a TLS mútua de origem para distribuições do CloudFront
<a name="origin-enable-mtls-distributions"></a>

Depois de obter um certificado de cliente por meio do AWS Certificate Manager e configurar o servidor de origem para exigir TLS mútua, você pode habilitar a mTLS de origem na distribuição do CloudFront.

## Pré-requisitos e requisitos
<a name="origin-mtls-prerequisites-requirements"></a>

Antes de habilitar a mTLS de origem em uma distribuição do CloudFront, você deve:
+ Um certificado de cliente armazenado no AWS Certificate Manager na região Leste dos EUA (Norte da Virgínia) (us-east-1).
+ Servidores de origem configurados para exigir a autenticação TLS mútua e validar certificados de cliente.
+ Servidores de origem que apresentem certificados de autoridades de certificação confiáveis publicamente.
+ Permissões para modificar distribuições do CloudFront.
+ A mTLS de origem só está disponível nos planos de preços Business, Premium ou Pagamento conforme o uso.

**nota**  
A mTLS de origem pode ser configurada para origens personalizadas (inclusive origens hospedadas fora da AWS) e origens da AWS que permitem TLS mútua, como o Application Load Balancer e o API Gateway.

**Importante**  
Os seguintes recursos do CloudFront não permitem mTLS de origem:  
**Tráfego gRPC:** não é possível usar o protocolo gRPC para origens com a mTLS de origem habilitada.
**Conexões WebSocket:** não é possível usar o protocolo WebSocket para origens com a mTLS de origem habilitada.
**Origens de VPC:** não é possível usar a mTLS de origem com origens de VPC.
**Acionadores de solicitação de origem e resposta de origem com o Lambda@Edge:** não é possível usar funções do Lambda@Edge nas posições de solicitação de origem e resposta de origem com a mTLS de origem.
**POPs incorporados:** não é possível usar a mTLS de origem para POPs incorporados.

## Habilitar a mTLS de origem
<a name="origin-enable-mtls-per-origin"></a>

A configuração por origem permite que especificar certificados de cliente diferentes para origens diferentes na mesma distribuição. Essa abordagem oferece flexibilidade máxima quando as origens têm requisitos de autenticação diferentes.

### Para novas distribuições (console)
<a name="origin-enable-mtls-new-distributions"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha **Criar distribuição**.

1. Selecione um plano de preços: escolha **Business**, **Premium** ou **Pagamento conforme o uso** (a mTLS de origem não está disponível no plano gratuito).

1. Na seção de configurações de origem, escolha “Outro” em “Tipo de origem”.

1. Na seção **Configurações de origem**, selecione **Personalizar configurações de origem**.

1. Configure a primeira origem (nome de domínio, protocolo etc.).

1. Na configuração da origem, encontre **mTLS**.

1. Ative a **mTLS**.

1. Em **Certificado de cliente**, selecione seu certificado no AWS Certificate Manager.

1. (Opcional) Adicione outras origens com as respectivas configurações de mTLS de origem.

1. Conclua as configurações de distribuição restantes e escolha **Criar distribuição**.

### Para distribuições existentes (console)
<a name="origin-enable-mtls-existing-distributions"></a>

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Na lista de distribuição, selecione a distribuição a ser modificada. (Observação: sua distribuição deve estar em um plano de preços **Pro ou Premium ou Pagamento conforme o uso**. Do contrário, será necessário atualizar o plano de preços antes de habilitar a mTLS de origem).

1. Escolha a guia **Origens**.

1. Selecione a origem que você deseja configurar e escolha **Editar**.

1. Nas configurações de origem, encontre **mTLS**.

1. Ative a **mTLS**.

1. Em **Certificado de cliente**, selecione seu certificado no AWS Certificate Manager. [Observação: somente certificados de cliente com a propriedade EKU (uso estendido de chave) definida como “Autenticação de cliente TLS” serão listados.]

1. Selecione **Save changes** (Salvar alterações)

1. Repita o procedimento para as demais origens conforme necessário.

## Usar a AWS CLI
<a name="origin-enable-mtls-cli"></a>

Para configuração por origem, especifique as configurações de mTLS de origem na configuração de cada origem:

```
{
  "Origins": {
    "Quantity": 2,
    "Items": [
      {
        "Id": "origin-1",
        "DomainName": "api.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-1"
        }
      },
      {
        "Id": "origin-2",
        "DomainName": "backend.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-2"
        }
      }
    ]
  }
}
```

**nota**  
O CloudFront não fornecerá o certificado de cliente se o servidor não o solicitar, permitindo que a conexão prossiga normalmente.

## Próximas etapas
<a name="origin-enable-mtls-next-steps"></a>

Após a habilitação da mTLS de origem na distribuição do CloudFront, é possível monitorar eventos de autenticação usando os logs de acesso do CloudFront.

# Usar o CloudFront Functions com a TLS mútua de origem
<a name="origin-mtls-cloudfront-functions"></a>

O CloudFront Functions oferece computação leve e sem servidor na borda para personalizar a entrega de conteúdo. Ao usar a TLS mútua de origem com o CloudFront Functions, é necessário conhecer limitações e comportamentos específicos em relação à seleção e manipulação da origem.

## Operações compatíveis do CloudFront Functions
<a name="supported-cloudfront-functions-operations"></a>

O CloudFront Functions pode interagir com origens com a mTLS de origem habilitada das seguintes formas:

### updateRequestOrigin()
<a name="update-request-origin-function"></a>

A função updateRequestOrigin() permite poucas modificações ao trabalhar com origens com a mTLS de origem habilitada:
+ **Alternar entre origens de mTLS de origem:** é possível atualizar a solicitação para rotear para uma origem diferente que use a mTLS de origem, desde que ambas as origens usem o **mesmo certificado de cliente**. Isso permite implementar uma lógica de roteamento personalizada e, ao mesmo tempo, manter a autenticação TLS mútua.
+ **Desabilitar a mTLS de origem:** é possível alternar de uma origem habilitada para mTLS para uma origem não mTLS definindo `mTLSConfig: 'off'` na função. Isso oferece flexibilidade para desabilitar condicionalmente a autenticação TLS mútua com base nas características da solicitação.

#### Exemplo: alternar entre origens de mTLS de origem com o mesmo certificado
<a name="example-switching-mtls-origins"></a>

```
function handler(event) {
    var request = event.request;

    // Route to different origin based on request path
    if (request.uri.startsWith('/api/v2')) {
        request.origin = {
            domainName: 'api-v2.example.com',
            customHeaders: {},
            // Both origins must use the same certificate
        };
    }

    return request;
}
```

#### Exemplo: desativação condicional da mTLS de origem
<a name="example-disabling-mtls"></a>

```
function handler(event) {
    var request = event.request;

    // Disable mTLS for specific paths
    if (request.uri.startsWith('/public')) {
        request.origin = {
            domainName: 'public-origin.example.com',
            customHeaders: {},
            mTLSConfig: 'off'
        };
    }

    return request;
}
```

## Operações não compatíveis do CloudFront Functions
<a name="unsupported-cloudfront-functions-operations"></a>

Não é possível usar as seguintes operações do CloudFront Functions com origens com a mTLS de origem habilitada na disponibilidade ao público:

### selectRequestOriginById()
<a name="select-request-origin-by-id-function"></a>

A função `selectRequestOriginById()` não pode selecionar uma origem que tenha a mTLS de origem habilitada. A tentativa de selecionar uma origem com a mTLS de origem habilitada por meio dessa função gera um erro de validação.

Se seu caso de uso exigir seleção dinâmica de origem com mTLS de origem, use `updateRequestOrigin()` em vez disso, para garantir que todas as origens de destino usem o mesmo certificado de cliente.

### createRequestOriginGroup()
<a name="create-request-origin-group-function"></a>

A função `createRequestOriginGroup()` não permite a criação de grupos de origens que incluam origens com a mTLS de origem habilitada. Grupos de origens que incluem origens com mTLS de origem não podem ser criados dinamicamente por meio do CloudFront Functions.

Se você precisar de recursos de failover de origem com mTLS de origem, configure grupos de origens diretamente nas configurações de distribuição do CloudFront em vez de criá-los dinamicamente em funções.

# Veicular conteúdo privado com URLs e cookies assinados
<a name="PrivateContent"></a>

Várias empresas que distribuem conteúdo pela Internet querem restringir o acesso a documentos, dados de negócio, streams de mídia ou conteúdo destinado a usuários selecionados, por exemplo, que pagaram uma taxa. Para fornecer esse conteúdo privado com segurança usando o CloudFront, é possível:
+ Solicitar que os usuários acessem o conteúdo privado usando signed URLs ou signed cookies especiais do CloudFront. 
+ Solicitar que os usuários acessem seu conteúdo usando URLs do CloudFront e não URLs que acessam conteúdo diretamente no servidor de origem (por exemplo, o Amazon S3 ou um servidor HTTP privado). Não é necessário solicitar URLs do CloudFront, mas recomendamos fazer isso para impedir que os usuários ignorem as restrições especificadas em signed URLs ou signed cookies.

Para obter mais informações, consulte [Restringir o acesso a arquivos](private-content-overview.md).

## Como fornecer conteúdo privado
<a name="private-content-task-list"></a>

Para configurar o CloudFront para fornecer conteúdo privado, siga estas etapas:

1. (Opcional, mas recomendado) Solicite que seus usuários acessem o conteúdo apenas pelo CloudFront. O método usado dependerá se você estiver usando o Amazon S3 ou origens personalizadas:
   + **Amazon S3**: consulte [Restringir o acesso a uma origem do Amazon S3](private-content-restricting-access-to-s3.md).
   + **Origem personalizada**: consulte [Restringir o acesso a arquivos em origens personalizadas](private-content-overview.md#forward-custom-headers-restrict-access).

   As origens personalizadas incluem o Amazon EC2, buckets do Amazon S3 configurados como endpoints de site, o Elastic Load Balancing e seus próprios servidores web HTTP.

1. Especifique os *grupos de chaves confiáveis* ou *assinantes confiáveis* que você deseja usar para criar signed URLs ou cookies. Recomendamos que você use grupos de chaves confiáveis. Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

1. Crie seu aplicativo para responder a solicitações de usuários autorizados com signed URLs ou cabeçalhos `Set-Cookie` que definem signed cookies. Siga as etapas em um dos tópicos abaixo: 
   + [Usar URLs assinados](private-content-signed-urls.md)
   + [Usar cookies assinados](private-content-signed-cookies.md)

   Se você não tiver certeza sobre qual método usar, consulte [Decidir usar URLs ou cookies assinados](private-content-choosing-signed-urls-cookies.md).

**Topics**
+ [Como fornecer conteúdo privado](#private-content-task-list)
+ [Restringir o acesso a arquivos](private-content-overview.md)
+ [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md)
+ [Decidir usar URLs ou cookies assinados](private-content-choosing-signed-urls-cookies.md)
+ [Usar URLs assinados](private-content-signed-urls.md)
+ [Usar cookies assinados](private-content-signed-cookies.md)
+ [Comandos do Linux e OpenSSL para criptografia e codificação base64](private-content-linux-openssl.md)
+ [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md)

# Restringir o acesso a arquivos
<a name="private-content-overview"></a>

É possível controlar o acesso do usuário ao seu conteúdo privado de duas maneiras:
+ [Restringir o acesso a arquivos em caches do CloudFront](#private-content-overview-edge-caches).
+ Restrinja o acesso a arquivos na sua origem de uma das seguintes maneiras:
  + [Configure um controle de acesso à origem (OAC) para seu bucket do Amazon S](private-content-restricting-access-to-s3.md).
  + [Configurar cabeçalhos personalizados para um servidor HTTP privado (uma origem personalizada)](#forward-custom-headers-restrict-access).

## Restringir o acesso a arquivos em caches do CloudFront
<a name="private-content-overview-edge-caches"></a>

É possível configurar o CloudFront para exigir que os usuários acessem seus arquivos usando *signed URLs* ou *signed cookies*. Depois, desenvolva sua aplicação para criar e distribuir signed URLs para usuários autenticados ou para enviar cabeçalhos `Set-Cookie` que definem signed cookies para usuários autenticados. (Para conceder a alguns usuários acesso de longo prazo a um pequeno número de arquivos, você também pode criar URLs assinados manualmente.) 

Ao criar signed URLs ou cookies para controlar o acesso a seus arquivos, você pode especificar as seguintes restrições:
+ Uma data e hora de expiração do URL. 
+ (Opcional) A data e a hora em que o URL se torna válido.
+ (Opcional) O endereço IP ou os endereços dos computadores que podem ser usados para acessar seu conteúdo. 

É adicionado hash ou assinatura a parte de um signed URL ou signed cookie usando a chave privada de um par de chaves públicas/privadas. Quando alguém usa um signed URL ou signed cookie para acessar um arquivo, o CloudFront compara as partes assinada e não assinada do URL ou cookie. Se elas não corresponderem, o CloudFront não fornecerá o arquivo.

É necessário usar chaves privadas RSA 2048 ou ECDSA 256 para assinar URLs ou cookies.

## Restringir o acesso a arquivos em buckets do Amazon S3
<a name="private-content-overview-s3"></a>

Também é possível proteger o conteúdo no bucket do Amazon S3 para que os usuários possam acessá-lo por meio da distribuição especificada do CloudFront, mas não possam acessá-lo diretamente usando URLs do Amazon S3. Isso impede que alguém ignore o CloudFront e use o URL do Amazon S3 para obter o conteúdo ao qual você deseja restringir o acesso. Essa etapa não exige o uso de signed URLs, mas recomendamos que você o faça.

Para solicitar que os usuários acessem seu conteúdo por URLs do CloudFront, siga estas etapas:
+ Conceda uma permissão de *controle de acesso à origem* do CloudFront para ler os arquivos no bucket do S3.
+ Crie o controle de acesso à origem e associe-o à sua distribuição do CloudFront.
+ Remova a permissão para usar URLs do Amazon S3 para ler os arquivos de todas as demais pessoas.

Para obter mais informações, consulte [Restringir o acesso a uma origem do Amazon S3](private-content-restricting-access-to-s3.md).

## Restringir o acesso a arquivos em origens personalizadas
<a name="forward-custom-headers-restrict-access"></a>

Se você usar uma origem personalizada, pode configurar os cabeçalhos personalizados para restringir o acesso. Para o CloudFront obter seus arquivos de uma origem personalizada, os arquivos devem estar acessíveis pelo CloudFront usando uma solicitação padrão HTTP (ou HTTPS). Mas, ao usar cabeçalhos personalizados, é possível restringir ainda mais o acesso ao conteúdo para que os usuários possam acessá-lo apenas por meio do CloudFront, e não diretamente. Essa etapa não exige o uso de signed URLs, mas recomendamos que você o faça.

Para exigir que os usuários acessem o conteúdo por meio do CloudFront, altere as seguintes configurações em suas distribuições do CloudFront:

**Cabeçalhos personalizados de origem**  
Configure o CloudFront para encaminhar cabeçalhos personalizados para sua origem. Consulte [Configurar o CloudFront para adicionar cabeçalhos personalizados às solicitações de origem](add-origin-custom-headers.md#add-origin-custom-headers-configure).

**Política de protocolo do visualizador**  
Configure a distribuição para exigir que os visualizadores usem HTTPS para acessar o CloudFront. Consulte [Política de protocolo do visualizador](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy). 

**Política de protocolo da origem**  
Configure sua distribuição para exigir que o CloudFront use o mesmo protocolo que os visualizadores para encaminhar solicitações para a origem. Consulte [Protocolo (somente origens personalizadas)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy). 

Depois de fazer essas alterações, atualize sua aplicação na origem personalizada para aceitar somente solicitações que incluam os cabeçalhos personalizados que você configurou o CloudFront para enviar.

A combinação de **Viewer Protocol Policy (Política de protocolo do visualizador)** e **Origin Protocol Policy (Política de protocolo da origem)** garante que os cabeçalhos personalizados sejam criptografados em trânsito. No entanto, recomendamos que você execute periodicamente o seguinte, para alternar os cabeçalhos personalizados encaminhados pelo CloudFront para sua origem:

1. Atualize sua distribuição do CloudFront para começar a encaminhar um novo cabeçalho para sua origem personalizada.

1. Atualize sua aplicação para aceitar o novo cabeçalho como confirmação de que a solicitação é proveniente do CloudFront.

1. Quando as solicitações não incluírem mais o cabeçalho que você estiver substituindo, atualize a aplicação para não aceitar mais o cabeçalho antigo como confirmação de que a solicitação é proveniente do CloudFront.

# Especificar os assinantes que podem criar URLs e cookies assinados
<a name="private-content-trusted-signers"></a>

**Topics**
+ [Escolher entre grupos de chaves confiáveis (recomendado) e Contas da AWS](#choosing-key-groups-or-AWS-accounts)
+ [Criar pares de chaves para os assinantes](#private-content-creating-cloudfront-key-pairs)
+ [Reformatar a chave privada (somente .NET e Java)](#private-content-reformatting-private-key)
+ [Adicionar um assinante a uma distribuição](#private-content-adding-trusted-signers)
+ [Alternar pares de chaves](#private-content-rotating-key-pairs)

Para criar signed URLs ou cookies, é necessário um *assinante*. Um assinante é um grupo de chaves confiável criado no CloudFront ou uma conta da AWS que contém um par de chaves do CloudFront. Recomendamos que você use grupos de chaves confiáveis com signed URLs e cookies. Para obter mais informações, consulte [Escolher entre grupos de chaves confiáveis (recomendado) e Contas da AWS](#choosing-key-groups-or-AWS-accounts).

O assinante tem duas finalidades:
+ Assim que você adicionar o assinante à sua distribuição, o CloudFront começará a exigir que os visualizadores usem signed URLs ou signed cookies para acessar seus arquivos.
+ Ao criar signed URLs ou cookies, você usa a chave privada do par de chaves do assinante para assinar uma parte do URL ou do cookie. Quando alguém solicita um arquivo restrito, o CloudFront compara a assinatura no URL ou cookie com o URL ou cookie não assinado, para verificar se ele não foi adulterado. O CloudFront também verifica se o URL ou cookie é válido, ou seja, se a data e hora de expiração não passou, por exemplo.

Ao especificar um assinante, você também especifica indiretamente os arquivos que exigem signed URLs ou cookies adicionando o assinante a um comportamento de cache. Caso sua distribuição tenha somente um comportamento de cache, os visualizadores deverão usar signed URLs ou cookies para acessar qualquer arquivo na distribuição. Se criar vários comportamentos de cache e adicionar assinantes a alguns deles, mas não a outros, você poderá solicitar que os visualizadores usem signed URLs ou cookies para acessar alguns arquivos e não outros.

Para especificar os assinantes (as chaves privadas) com permissão para criar signed URLs ou signed cookies e adicionar os assinantes à sua distribuição do CloudFront, execute as seguintes tarefas:

1. Decida se pretende utilizar um grupo de chaves confiável ou uma Conta da AWS como assinante. Recomendamos o uso de um grupo de chaves confiável. Para obter mais informações, consulte [Escolher entre grupos de chaves confiáveis (recomendado) e Contas da AWS](#choosing-key-groups-or-AWS-accounts).

1. Para o assinante que você escolheu na etapa 1, crie um par de chaves pública/privada. Para obter mais informações, consulte [Criar pares de chaves para os assinantes](#private-content-creating-cloudfront-key-pairs).

1. Se você estiver usando .NET ou Java para criar signed URLs ou cookies, reformate a chave privada. Para obter mais informações, consulte [Reformatar a chave privada (somente .NET e Java)](#private-content-reformatting-private-key).

1. Na distribuição para a qual você está criando signed URLs ou cookies, especifique o assinante. Para obter mais informações, consulte [Adicionar um assinante a uma distribuição](#private-content-adding-trusted-signers).

## Escolher entre grupos de chaves confiáveis (recomendado) e Contas da AWS
<a name="choosing-key-groups-or-AWS-accounts"></a>

Para usar signed URLs ou cookies, é necessário um *assinante*. Um assinante é um grupo de chaves confiável criado no CloudFront ou uma Conta da AWS que contenha um par de chaves do CloudFront. Recomendamos que você use grupos de chaves confiáveis, pelos seguintes motivos:
+ Com os grupos de chaves do CloudFront, não é necessário usar o usuário root da conta da AWS para gerenciar as chaves públicas para URLs assinados e cookies do CloudFront. As [práticas recomendadas da AWS](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root) aconselham não usar o usuário root, exceto quando estritamente necessário.
+ Com os grupos de chaves do CloudFront, é possível gerenciar chaves públicas, grupos de chaves e assinantes confiáveis usando a API do CloudFront. É possível usar a API para automatizar a criação de chaves e a alternância de chaves. Quando você usa o usuário-raiz da AWS, é necessário usar o Console de gerenciamento da AWS para gerenciar pares de chaves do CloudFront, por isso o processo não pode ser automatizado.
+ Como você pode gerenciar grupos de chaves com a API do CloudFront, também é possível usar as políticas de permissões do AWS Identity and Access Management (IAM) para limitar as ações permitidas aos diferentes usuários. Por exemplo, é possível permitir que os usuários façam upload de chaves públicas, mas não excluí-las. Ou, é possível permitir que os usuários excluam chaves públicas, mas somente quando determinadas condições forem atendidas, como usar autenticação multifator, enviar a solicitação de uma determinada rede ou enviar a solicitação dentro de um determinado intervalo de data e hora.
+ Com grupos de chaves do CloudFront, é possível associar um número maior de chaves públicas à sua distribuição do CloudFront, proporcionando mais flexibilidade na forma como você usa e gerencia as chaves públicas. Por padrão, é possível associar até quatro grupos de chaves a uma única distribuição e ter até cinco chaves públicas em um grupo de chaves.

  Ao usar a conta da AWS do usuário-raiz para gerenciar pares de chaves do CloudFront, você só poderá ter até dois pares de chaves ativos do CloudFront por conta da AWS.

## Criar pares de chaves para os assinantes
<a name="private-content-creating-cloudfront-key-pairs"></a>

Cada assinante usado para criar signed URLs ou signed cookies do CloudFront deve ter um par de chaves pública/privada. O assinante usa sua chave privada para assinar o URL ou os cookies e o CloudFront usa a chave pública para verificar a assinatura.

A maneira como você cria um par de chaves depende se você usa um grupo de chaves confiável como assinante (recomendado) ou um par de chaves do CloudFront. Para obter mais informações, consulte as seções a seguir. O par de chaves que criar deve atender aos seguintes requisitos:
+ Deve ser um par de chaves SSH-2 RSA 2048 ou ECDSA 256.
+ Ele deve estar no formato PEM codificado em base64.

Para ajudar a proteger sias aplicações, recomendamos que você alterne os pares de chaves periodicamente. Para obter mais informações, consulte [Alternar pares de chaves](#private-content-rotating-key-pairs).

### Criar um par de chaves para um grupo de chaves confiável (recomendado)
<a name="create-key-pair-and-key-group"></a>

Para criar um par de chaves para um grupo de chaves confiável, execute as seguintes etapas:

1. Crie o par de chaves pública/privada.

1. Faça upload da chave pública no CloudFront.

1. Adicione a chave pública a um grupo de chaves do CloudFront.

Para obter mais informações, consulte os procedimentos a seguir.<a name="private-content-uploading-cloudfront-public-key-procedure"></a>

**Para criar um par de chaves**
**nota**  
As etapas a seguir usam OpenSSL como um exemplo de método para criar um par de chaves. Há várias outras maneiras de criar um par de chaves RSA ou ECDSA.

1. Execute um dos seguintes comandos de exemplo:
   + O comando de exemplo a seguir usa OpenSSL para gerar um par de chaves RSA com um tamanho de 2.048 bits e salvar no arquivo chamado `private_key.pem`.

     ```
     openssl genrsa -out private_key.pem 2048
     ```
   + O comando de exemplo a seguir usa OpenSSL para gerar um par de chaves ECDSA com a curva `prime256v1` e salvar no arquivo chamado `private_key.pem`.

     ```
     openssl ecparam -name prime256v1 -genkey -noout -out privatekey.pem
     ```

1. O arquivo resultante contém a chave pública e a privada. O comando de exemplo a seguir extrai a chave pública do arquivo chamado `private_key.pem`.

   ```
   openssl rsa -pubout -in private_key.pem -out public_key.pem
   ```

   Faça upload da chave pública (no arquivo `public_key.pem`) posteriormente, no procedimento a seguir.

**Como carregar a chave pública no CloudFront**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No menu de navegação, escolha **Public keys (Chaves públicas)**.

1. Selecione **Create public key** (Criar chave pública).

1. Na janela **Create public key** (Criar chave pública), faça o seguinte:

   1. Em **Key name (Nome da chave)**, digite um nome para identificar a chave pública.

   1. Em **Key value (Valor da chave)**, cole a chave pública. Se você seguiu as etapas no procedimento anterior, a chave pública está no arquivo chamado `public_key.pem`. Para copiar e colar o conteúdo da chave pública, é possível:
      + Usar o comando **cat** na linha de comando do macOS ou do Linux, da seguinte forma:

        ```
        cat public_key.pem
        ```

        Copie a saída desse comando e cole-a no campo **Key value (Valor da chave)**.
      + Abra o arquivo `public_key.pem` com um editor de texto simples, como o Notepad (no Windows) ou o TextEdit (no macOS). Copie o conteúdo do arquivo e cole-o no campo **Key value (Valor da chave)**.

   1. (Opcional) Em **Comment (Comentário)**, adicione um comentário para descrever a chave pública.

   Quando terminar, escolha **Add (Adicionar)**.

1. Registre o ID da chave pública. Ele será usado posteriormente quando você criar signed URLs ou cookies como o valor do campo `Key-Pair-Id`.

**Como adicionar a chave pública a um grupo de chaves**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No menu de navegação, escolha **Key groups (Grupos de chaves)**.

1. Escolha **Add key group (Adicionar grupo de chaves)**.

1. Na página **Create key group (Criar grupo de chaves)** faça o seguinte:

   1. Em **Key group name (Nome do grupo de chaves)**, digite um nome para identificar o grupo de chaves.

   1. (Opcional) Em **Comment (Comentário)**, digite um comentário para descrever o grupo de chaves.

   1. Em **Public keys (Chaves públicas)**, selecione a chave pública a ser adicionada ao grupo de chaves e escolha **Add (Adicionar)**. Repita essa etapa para cada chave pública que você deseja adicionar ao grupo de chaves.

1. Escolha **Create key group (Criar grupo de chaves)**.

1. Registre o nome do grupo de chaves. Ele será usado posteriormente para associar o grupo de chaves a um comportamento de cache em uma distribuição do CloudFront. (Na API do CloudFront, use o ID do grupo de chaves para associar o grupo de chaves a um comportamento de cache.)

### Criar um par de chaves do CloudFront (não recomendado, requer o usuário-raiz da Conta da AWS)
<a name="create-key-pair-aws-account"></a>

**Importante**  
Recomendamos que você crie uma chave pública para um grupo de chaves confiável em vez de seguir estas etapas. Para a maneira recomendada de criar chaves públicas para signed URLs e signed cookies, consulte [Criar um par de chaves para um grupo de chaves confiável (recomendado)](#create-key-pair-and-key-group).

É possível criar um par de chaves do CloudFront das seguintes maneiras:
+ Crie um par de chaves no Console de gerenciamento da AWS e faça download da chave privada. Consulte o procedimento a seguir.
+ Crie um par de chaves RSA usando uma aplicação, como o OpenSSL, e faça upload da chave pública no Console de gerenciamento da AWS. Para mais informações sobre como criar um par de chaves RSA, consulte [Criar um par de chaves para um grupo de chaves confiável (recomendado)](#create-key-pair-and-key-group).<a name="private-content-creating-cloudfront-key-pairs-procedure"></a>

**Para criar pares de chaves do CloudFront no Console de gerenciamento da AWS**

1. Faça login no Console de gerenciamento da AWS usando as credenciais do usuário-raiz da conta da AWS.
**Importante**  
Usuários do IAM não podem criar pares de chaves do CloudFront. É necessário fazer login usando as credenciais de usuário-raiz para criar pares de chaves.

1. Escolha o nome da sua conta e selecione **My Security Credentials (Minhas credenciais de segurança)**.

1. Escolha **CloudFront key pairs (Pares de chaves do CloudFront)**.

1. Confirme se você não têm mais de um par de chaves ativo. Não será possível criar um par de chaves se você já tiver dois pares de chaves ativos.

1. Selecione **Create a new key pair (Criar um par de chaves)**.
**nota**  
Também é possível criar um par de chaves próprio e fazer upload da chave pública. Os pares de chaves do CloudFront são compatíveis com chaves de 1024, 2048 ou 4096 bits.

1. Na caixa de diálogo **Create Key Pair (Criar par de chaves)**, escolha **Download Private Key File (Fazer download do arquivo de chave privada)** e salve o arquivo no computador.
**Importante**  
Salve a chave privada do par de chaves do CloudFront em um local seguro e defina as permissões no arquivo para que somente os usuários administradores desejados possam lê-lo. Se alguém obtiver sua chave privada, poderá gerar signed URLs e cookies válidos e fazer download do seu conteúdo. Não é possível gerar a chave privada novamente. Portanto, se perder ou excluí-la, crie outro par de chaves do CloudFront.

1. Anote o ID do seu par de chaves. (No Console de gerenciamento da AWS, ele é chamado de **ID de chave de acesso**.) Ele será usado quando você criar signed URLs ou cookies.

## Reformatar a chave privada (somente .NET e Java)
<a name="private-content-reformatting-private-key"></a>

Se estiver usando .NET ou Java para criar signed URLs ou cookies, você não poderá usar a chave privada do par de chaves no formato padrão PEM para criar a assinatura. Em vez disso, faça o seguinte:
+ **Framework .NET**: converta a chave privada no formato XML usado pelo framework .NET. Várias ferramentas estão disponíveis.
+ **Java**: converta a chave privada no formato DER. Uma maneira de fazer isso é com o comando OpenSSL a seguir. No comando a seguir, `private_key.pem` é o nome do arquivo que contém a chave privada formatada em PEM e `private_key.der` é o nome do arquivo que contém a chave privada formatada em DER depois que o comando é executado.

  ```
  openssl pkcs8 -topk8 -nocrypt -in private_key.pem -inform PEM -out private_key.der -outform DER
  ```

  Para garantir que o codificador funcione corretamente, adicione o JAR para as APIs de criptografia Java Bouncy Castle do seu projeto e adicione o provedor do Bouncy Castle.

## Adicionar um assinante a uma distribuição
<a name="private-content-adding-trusted-signers"></a>

Um assinante é o grupo de chaves confiável (recomendado) ou o par de chaves do CloudFront que pode criar signed URLs e signed cookies para uma distribuição. Para usar signed URLs ou signed cookies com uma distribuição do CloudFront, é necessário especificar um assinante.

Os assinantes estão associados a comportamentos de cache. Isso permite exigir signed URLs ou cookies para alguns arquivos e não para outros na mesma distribuição. Uma distribuição requer signed URLs ou cookies somente para arquivos associados aos comportamentos de cache correspondentes.

Da mesma forma, um assinante só pode assinar URLs ou cookies para arquivos associados aos comportamentos de cache correspondentes. Por exemplo, se você tiver um assinante para um comportamento de cache e um assinante diferente para outro comportamento de cache, nenhum dos dois assinantes poderão criar signed URLs ou cookies para arquivos associados ao outro comportamento de cache.

**Importante**  
Antes de adicionar um assinante à sua distribuição, faça o seguinte:  
Defina os padrões de caminho nos comportamentos de cache e a sequência de comportamentos de cache cuidadosamente para que você não dê aos usuários acesso indesejado ao seu conteúdo ou impeça que eles acessem o conteúdo que você deseja que esteja disponível para todos.  
Por exemplo, imagine que uma solicitação corresponda ao padrão de caminho de dois comportamentos de cache. O primeiro comportamento de cache não requer signed URLs ou cookies, mas o segundo comportamento de cache, sim. Os usuários poderão acessar os arquivos sem usar signed URLs ou signed cookies porque o CloudFront processa o comportamento de cache associado à primeira correspondência.  
Para obter mais informações sobre padrões de caminho, consulte [Padrão de caminho](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
Para uma distribuição que você já esteja usando para distribuir conteúdo, certifique-se de que esteja pronto para começar a gerar signed URLs e cookies antes de adicionar um assinante. Quando você adiciona um assinante, o CloudFront rejeita as solicitações que não incluam um signed URL ou signed cookie válido.

É possível adicionar assinantes à sua distribuição usando o console ou a API do CloudFront.

------
#### [ Console ]

As etapas a seguir mostram como adicionar um grupo de chaves confiável como assinante. Também é possível adicionar uma Conta da AWS como signatário confiável, mas isso não é recomendado.<a name="private-content-adding-trusted-signers-console-procedure"></a>

**Como adicionar um assinante a uma distribuição usando o console**

1. Registre o ID do grupo de chaves que você deseja usar como signatário confiável. Para obter mais informações, consulte [Criar um par de chaves para um grupo de chaves confiável (recomendado)](#create-key-pair-and-key-group).

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha a distribuição com os arquivos você deseja proteger com signed URLs ou cookies.
**nota**  
Para adicionar um assinante a uma nova distribuição, especifique as mesmas configurações descritas na etapa 6 ao criar a distribuição.

1. Escolha a guia **Behaviors**.

1. Selecione o comportamento de cache com o padrão de caminho corresponde aos arquivos que você deseja proteger com signed URLs ou cookies e escolha **Edit (Editar)**.

1. Na página **Edit Behavior (Editar Comportamento)** faça o seguinte:

   1. Em **Restrict Viewer Access (Use Signed URLs or Signed Cookies) (Restringir acesso do visualizador (Usar signed URLs ou signed Cookies))**, escolha **Yes (Sim)**.

   1. Em **Trusted Key Groups or Trusted Signer (Grupos de chaves confiáveis ou signatário confiável)**, escolha **Trusted Key Groups (Grupos de chaves confiáveis)**.

   1. Em **Trusted Key Groups (Grupos de chaves confiáveis)**, escolha o grupo de chaves a ser adicionado e escolha **Add (Adicionar)**. Repita se quiser adicionar mais de um grupo de chaves.

1. Escolha **Yes, Edit (Sim, editar)** para atualizar o comportamento do cache.

------
#### [ API ]

É possível usar a API do CloudFront para adicionar um grupo de chaves confiável como assinante. É possível adicionar um assinante a uma distribuição existente ou a uma nova distribuição. Em qualquer caso, especifique os valores no elemento `TrustedKeyGroups`.

Também é possível adicionar uma Conta da AWS como signatário confiável, mas isso não é recomendado.

Consulte os seguintes tópicos na *Referência da API do Amazon CloudFront*:
+ **Atualizar uma distribuição existente**: [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
+ **Criar uma nova distribuição**: [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)

------

## Alternar pares de chaves
<a name="private-content-rotating-key-pairs"></a>

Recomendamos que você alterne (mude) periodicamente seus pares de chaves para signed URLs e cookies. Para alternar os pares de chaves que você estiver usando para criar signed URLs ou cookies sem invalidar os URLs ou os cookies que ainda não expiraram, execute as seguintes tarefas:

1. Crie um par de chaves e adicione a chave pública a um grupo de chaves. Para obter mais informações, consulte [Criar um par de chaves para um grupo de chaves confiável (recomendado)](#create-key-pair-and-key-group).

1. Se você criou um grupo de chaves na etapa anterior, [adicione-o à distribuição como assinante](#private-content-adding-trusted-signers).
**Importante**  
Não remova nenhuma chave pública existente do grupo de chaves ou nenhum grupo de chaves da distribuição ainda. Somente adicione os novos.

1. Atualize sua aplicação para criar assinaturas usando a chave privada do novo par de chaves. Confirme se os signed URLs ou cookies com as novas chaves privadas estão funcionando.

1. Espere passar a data de expiração dos URLs ou cookies que foram assinados usando a chave privada antiga. Depois, remova a chave pública antiga do grupo de chaves. Se você criou um grupo de chaves na etapa 2, remova o grupo de chaves antigo da sua distribuição.

# Decidir usar URLs ou cookies assinados
<a name="private-content-choosing-signed-urls-cookies"></a>

Os signed URLs e signed cookies do CloudFront fornecem a mesma funcionalidade básica: eles permitem controlar quem pode acessar seu conteúdo. Se você quiser fornecer conteúdo privado pelo CloudFront e estiver tentando decidir se usará signed URLs ou signed cookies, considere as informações a seguir.

Use signed URLs nos seguintes casos:
+ Você quer restringir o acesso a arquivos individuais, por exemplo, o download de uma instalação para seu aplicativo.
+ Seus usuários estão usando um cliente (por exemplo, um cliente HTTP personalizado) incompatível com cookies.

Use signed cookies nos seguintes casos:
+ Você quer fornecer acesso a vários arquivos restritos, por exemplo, todos os arquivos de um vídeo no formato HLS ou todos os arquivos da área de assinantes de um site.
+ Você não quer alterar seus URLs atuais.

Se você não estiver usando URLs assinados e seus URLs (não assinados) contiverem um dos seguintes parâmetros de string de consulta, você não poderá usar signed URLs ou signed cookies:
+ `Expires`
+ `Policy`
+ `Signature`
+ `Key-Pair-Id`

O CloudFront pressupõe que os URLs que contenham um desses parâmetros de query string sejam signed URLs, portanto, não analisará os signed cookies.

## Usar URLs e cookies assinados
<a name="private-content-using-signed-urls-and-cookies"></a>

Signed URLs têm precedência sobre signed cookies. Se você usar signed URLs e signed cookies para controlar o acesso aos mesmos arquivos e um visualizador usar um signed URL para solicitar um arquivo, o CloudFront determinará se retornará o arquivo para o visualizador com base somente no signed URL.

# Usar URLs assinados
<a name="private-content-signed-urls"></a>

Um signed URL inclui informações adicionais, por exemplo, uma data e hora de expiração, que proporcionam a você mais controle sobre o acesso a seu conteúdo. Essas informações adicionais são descritas em uma declaração de política, que é baseada em uma política padrão ou personalizada. As diferenças entre a política padrão e a personalizada estão explicadas nas duas próximas seções.

**nota**  
Você pode criar alguns signed URLs usando políticas padrão e outros usando políticas personalizadas para a mesma distribuição.

**Topics**
+ [Decidir usar políticas predefinidas ou personalizadas para URLs assinados](#private-content-choosing-canned-custom-policy)
+ [Como signed URLs funcionam](#private-content-how-signed-urls-work)
+ [Decidir o tempo de validade de URLs assinados](#private-content-overview-choosing-duration)
+ [Quando o CloudFront confere a data e hora de validade de um URL assinado?](#private-content-check-expiration)
+ [Código de exemplo e ferramentas de terceiros](#private-content-overview-sample-code)
+ [Criar um URL assinado usando uma política predefinida](private-content-creating-signed-url-canned-policy.md)
+ [Criar um URL assinado usando uma política personalizada](private-content-creating-signed-url-custom-policy.md)

## Decidir usar políticas predefinidas ou personalizadas para URLs assinados
<a name="private-content-choosing-canned-custom-policy"></a>

Ao criar um signed URL, você grava uma declaração de política no formato JSON que especifica as restrições no signed URL, por exemplo, por quanto tempo o URL é válido. Você pode usar uma política padrão ou personalizada. Veja uma comparação entre as duas:


****  

| Descrição | Política padrão | Política personalizada | 
| --- | --- | --- | 
| Você pode reutilizar a declaração de política para vários arquivos. Para reutilizar a declaração de política, é necessário usar caracteres curinga no objeto `Resource`. Para obter mais informações, consulte [Valores especificados na declaração de política para um signed URL que usa uma política personalizada](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-statement-values).)  | Não | Sim | 
| Você pode especificar a data e a hora em que os usuários podem começar a acessar seu conteúdo. | Não | Sim (opcional) | 
| Você pode especificar a data e a hora em que os usuários não podem mais acessar seu conteúdo. | Sim | Sim | 
| Você pode especificar o endereço IP ou vários endereços IP dos usuários que podem acessar seu conteúdo. | Não | Sim (opcional) | 
| O signed URL inclui uma versão da política codificada em base64, resultando em um URL mais longo. | Não | Sim | 

Para obter informações sobre como criar signed URLs usando uma política *padrão*, consulte [Criar um URL assinado usando uma política predefinida](private-content-creating-signed-url-canned-policy.md).

Para obter informações sobre como criar signed URLs usando uma política *personalizada*, consulte [Criar um URL assinado usando uma política personalizada](private-content-creating-signed-url-custom-policy.md).

## Como signed URLs funcionam
<a name="private-content-how-signed-urls-work"></a>

A seguir, uma visão geral de como configurar o CloudFront e o Amazon S3 para signed URLs e como o CloudFront responde quando um usuário usa um signed URL para solicitar um arquivo. 

1. Na sua distribuição do CloudFront, especifique um ou mais grupos de chaves confiáveis, que contenham as chaves públicas que o CloudFront pode usar para verificar a assinatura do URL. Use as chaves privadas correspondentes para assinar os URLs.

   O CloudFront permite URLs assinados com assinaturas de chave RSA 2048 e ECDSA 256.

   Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

1. Desenvolva sua aplicação para determinar se um usuário deve ter acesso a seu conteúdo e criar signed URLs para os arquivos ou partes da aplicação às quais você deseja restringir o acesso. Para obter mais informações, consulte os tópicos a seguir:
   + [Criar um URL assinado usando uma política predefinida](private-content-creating-signed-url-canned-policy.md)
   + [Criar um URL assinado usando uma política personalizada](private-content-creating-signed-url-custom-policy.md)

1. Um usuário solicita um arquivo para o qual você deseja exigir signed URLs.

1. Seu aplicativo verifica se o usuário está autorizado a acessar o arquivo: ele fez login, pagou para acessar o conteúdo ou atendeu a outro requisito de acesso.

1. O aplicativo cria e retorna um signed URL para o usuário.

1. O signed URL permite que o usuário faça download ou transmita o conteúdo.

   Essa etapa é automática; o usuário geralmente não precisa fazer nada a mais para acessar o conteúdo. Por exemplo, se um usuário estiver acessando seu conteúdo em um navegador da Web, a aplicação retornará o signed URL para o navegador. O navegador imediatamente usa o signed URL para acessar o arquivo no ponto de presença de caches do CloudFront sem intervenção do usuário.

1. O CloudFront usa a chave pública para validar a assinatura e confirmar se o URL não foi adulterado. Se a assinatura for inválida, a solicitação será rejeitada. 

   Se a assinatura for válida, o CloudFront analisará a declaração de política no URL (ou criará uma se você estiver usando uma política padrão) para confirmar se a solicitação continua válida. Por exemplo, se você especificou uma data e hora de início e término para o URL, o CloudFront confirmará se o usuário está tentando acessar o conteúdo durante o período de acesso permitido. 

   Se a solicitação cumprir os requisitos da declaração de política, o CloudFront executará as operações padrão: determinar se o arquivo já está no ponto de presença de caches, encaminhar a solicitação para a origem, se necessário, e retornar o arquivo para o usuário.

**nota**  
Se um URL não assinado contiver parâmetros de string de consulta, certifique-se de incluí-los na parte do URL que você assinar. Se você adicionar uma string de consulta a um signed URL depois de assiná-lo, o URL retornará um status HTTP 403.

## Decidir o tempo de validade de URLs assinados
<a name="private-content-overview-choosing-duration"></a>

Você pode distribuir conteúdo privado usando um signed URL válido apenas por um período curto (possivelmente por apenas alguns minutos). URLs assinados válidos por um curto período são bons para distribuir conteúdo imediato a um usuário para uma finalidade específica, como a distribuição de aluguéis de filmes ou downloads de música para os clientes sob demanda. Caso seu signed URLs sejam válidos apenas por um curto período, gere-os automaticamente usando um aplicativo desenvolvido por você. Quando o usuário começar a fazer download de um arquivo ou a reproduzir um arquivo de mídia, o CloudFront comparará a hora de expiração do URL com a hora atual para determinar se o URL continua válido.

Você também pode distribuir conteúdo privado usando um signed URL válido por um período mais longo (possivelmente por anos). Signed URLs válidos por um período mais longo são úteis para distribuir conteúdo privado para usuários conhecidos, como a distribuição de um plano de negócios para investidores ou de materiais de treinamento para funcionários. É possível desenvolver uma aplicação para gerar esses URLs assinados de longo prazo para você.

## Quando o CloudFront confere a data e hora de validade de um URL assinado?
<a name="private-content-check-expiration"></a>

O CloudFront verifica a data e hora de expiração de um signed URL no momento da solicitação HTTP. Se um cliente começar a fazer download de um grande arquivo logo antes da hora de expiração, o download será concluído mesmo se passar a hora de expiração durante o download. Se a conexão TCP cair e o cliente tentar reiniciar o download após a hora de expiração, ocorrerá falha no download.

Se o cliente usar Range GETs para obter um arquivo em partes menores, ocorrerá falha em qualquer solicitação GET que ocorrer após a hora de expiração. Para obter mais informações sobre Range GETs, consulte [Como o CloudFront processa solicitações parciais de um objeto (Range GETs)](RangeGETs.md).

## Código de exemplo e ferramentas de terceiros
<a name="private-content-overview-sample-code"></a>

Para obter um código de exemplo que cria a parte assinada e com hash dos signed URLs, consulte os seguintes tópicos:
+ [Criar uma assinatura de URL usando Perl](CreateURLPerl.md)
+ [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md)
+ [Criar uma assinatura de URL usando C\$1 e o .NET Framework](CreateSignatureInCSharp.md)
+ [Criar uma assinatura de URL usando Java](CFPrivateDistJavaDevelopment.md)

# Criar um URL assinado usando uma política predefinida
<a name="private-content-creating-signed-url-canned-policy"></a>

Para criar um signed URL usando uma política enlatada, conclua as etapas a seguir.<a name="private-content-creating-signed-url-canned-policy-procedure"></a>

**Para criar um signed URL usando uma política padrão**

1. Se você estiver usando o .NET ou Java para criar signed URLs e não tiver reformatado a chave privada do seu par de chaves para do formato padrão .pem para um formato compatível com o .NET ou Java, faça isso agora. Para obter mais informações, consulte [Reformatar a chave privada (somente .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concatene os valores a seguir. Você pode usar o formato neste exemplo de URL assinado. 

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Expires=1767290400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F
   ```

   Remova todos os espaços vazios (inclusive caracteres de nova linha e de tabulação). Pode ser necessário incluir caracteres de escape na string do código do aplicativo. Todos os valores têm um tipo de `String`.  
**1. *URL base do arquivo***  
O URL base é o URL do CloudFront usado para acessar o arquivo se você não estivesse usando signed URLs, inclusive seus próprios parâmetros de query string, se houver. No exemplo anterior, o URL de base é `https://d111111abcdef8.cloudfront.net/image.jpg`. Para mais informações sobre o formato dos URLs para distribuições, consulte [Personalizar o formato do URL para arquivos no CloudFront](LinkFormat.md).  
   + O URL do CloudFront a seguir é para um arquivo de imagem em uma distribuição (usando o nome de domínio do CloudFront). Observe que `image.jpg` está em um diretório `images`. O caminho para o arquivo no URL deve corresponder ao caminho para o arquivo no servidor HTTP ou no bucket do Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + O seguinte URL do CloudFront inclui uma query string:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Os URLs do CloudFront a seguir são para arquivos de imagem em uma distribuição. Ambos usam um nome de domínio alternativo. O segundo inclui uma string de consulta:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + O URL do CloudFront a seguir é para um arquivo de imagem em uma distribuição que usa um nome de domínio alternativo e o protocolo HTTPS:

     `https://www.example.com/images/image.jpg`  
** 2. `?`**  
O `?` indica que os parâmetros de string de consulta seguem o URL base. Inclua o `?` mesmo que você não especifique nenhum parâmetro de consulta.  
Você pode especificar os parâmetros de consulta a seguir em qualquer ordem.  
**3. *Seus parâmetros de string de consulta, se houver*`&`**  
(Opcional) Você pode inserir seus próprios parâmetros de string de consulta. Para fazer isso, adicione um e comercial (`&`) entre cada um, como `color=red&size=medium`. Você pode especificar parâmetros de string de consulta em qualquer ordem dentro do URL.  
Seus parâmetros de string de consulta não podem ser especificados como `Expires`, `Signature` ou `Key-Pair-Id`.  
** 4. `Expires=`*data e hora no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC)***  
A data e a hora em que você deseja que o URL pare de permitir acesso ao arquivo.  
Especifique a data e hora de expiração no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Por exemplo, 1.º de janeiro de 2026 10h UTC é convertido em `1767290400` no formato de hora do Unix, conforme mostrado no exemplo no início deste tópico.   
Para usar o tempo de época, especifique um número inteiro de 64 bits para uma data que não seja posterior a `9223372036854775807` (sexta-feira, 11 de abril de 2262 às 23:47:16.854 UTC).  
  
Para ter informações sobre UTC, consulte [RFC 3339, Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339).  
** 5. `&Signature=`*versão assinada e com hash da declaração de política***  
Uma versão assinada, com hash e codificação base64 da declaração de política do JSON. Para obter mais informações, consulte [Criar uma assinatura para um URL assinado que use uma política predefinida](#private-content-canned-policy-creating-signature).  
** 6. `&Key-Pair-Id=`*ID da chave pública do CloudFront cuja chave privada correspondente está sendo usada para gerar a assinatura***  
O ID de uma chave pública do CloudFront, por exemplo, `K2JCJMDEHXQW5F`. O ID da chave pública informa ao CloudFront qual chave pública deve ser usada para validar o signed URL. O CloudFront compara as informações da assinatura com as informações da declaração de política para verificar se o URL não foi adulterado.  
Essa chave pública deve pertencer a um grupo de chaves que seja um signatário confiável na distribuição. Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

## Criar uma assinatura para um URL assinado que use uma política predefinida
<a name="private-content-canned-policy-creating-signature"></a>

Para criar a assinatura de um URL que use uma política predefinida, siga estes procedimentos.

**Topics**
+ [Criar uma declaração de política para um URL assinado que use uma política predefinida](#private-content-canned-policy-creating-policy-statement)
+ [Criar uma assinatura para um URL assinado que use uma política predefinida](#private-content-canned-policy-signing-policy-statement)

### Criar uma declaração de política para um URL assinado que use uma política predefinida
<a name="private-content-canned-policy-creating-policy-statement"></a>

Ao criar um signed URL usando uma política padrão, o parâmetro `Signature` será uma versão assinada e com hash de uma declaração de política. Para signed URLs que usam uma política padrão, a declaração de política não é incluída no URL, como é feito nos signed URLs que usam uma política personalizada. Para criar a declaração de política, siga o procedimento abaixo.<a name="private-content-canned-policy-creating-policy-statement-procedure"></a>

**Para criar a declaração de política para um signed URL que usa uma política padrão**

1. Crie a declaração de política usando o formato JSON a seguir e a codificação de caracteres UTF-8. Inclua todas as pontuações e outros valores literais exatamente como especificado. Para obter informações sobre os parâmetros `Resource` e `DateLessThan`, consulte [Valores especificados na declaração de política para um signed URL que usa uma política padrão](#private-content-canned-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Remova todas os espaços em branco (inclusive caracteres de nova linha e de tabulação) da declaração de política. Pode ser necessário incluir caracteres de escape na string do código do aplicativo.

#### Valores especificados na declaração de política para um signed URL que usa uma política padrão
<a name="private-content-canned-policy-statement-values"></a>

Ao criar uma declaração de política para uma política padrão, especifique os valores a seguir.

**Recurso**  
Você pode especificar apenas um valor para `Resource`.
O URL base, com suas query strings, se houver, sem os parâmetros `Expires`, `Signature` e `Key-Pair-Id` do CloudFront, por exemplo:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Observe o seguinte:  
+ **Protocolo**: o valor deve começar com `http://` ou `https://`.
+ **Parâmetros de query string** :se você não tiver query strings, omita o ponto de interrogação.
+ **Nomes de domínio alternativos**: se especificar um nome de domínio alternativo (CNAME) no URL, você deverá especificá-lo ao fazer referência ao arquivo na sua página da web ou aplicação. Não especifique o URL do Amazon S3 do objeto.

**DateLessThan**  
A data e hora de expiração do URL no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Por exemplo, 1.º de janeiro de 2026 10h UTC é convertido em 1357034400 no formato de hora do Unix.  
Esse valor deve corresponder ao valor do parâmetro de query string `Expires` do signed URL. Não coloque os valores entre aspas.  
Para obter mais informações, consulte [Quando o CloudFront confere a data e hora de validade de um URL assinado?](private-content-signed-urls.md#private-content-check-expiration).

#### Exemplo de declaração de política para um signed URL que usa uma política padrão
<a name="private-content-canned-policy-creating-policy-statement-example"></a>

Ao usar o seguinte exemplo de declaração de política em um URL, assinado, um usuário pode acessar o arquivo `https://d111111abcdef8.cloudfront.net/horizon.jpg` até 1.º de janeiro de 2026, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Criar uma assinatura para um URL assinado que use uma política predefinida
<a name="private-content-canned-policy-signing-policy-statement"></a>

Para criar o valor para o parâmetro `Signature` em um signed URL, assine e adicione um hash à declaração de política criada em [Criar uma declaração de política para um URL assinado que use uma política predefinida](#private-content-canned-policy-creating-policy-statement).

Para obter mais informações e exemplos de como adicionar hash, assinar e codificar a declaração de política, consulte:
+ [Comandos do Linux e OpenSSL para criptografia e codificação base64](private-content-linux-openssl.md)
+ [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-canned-policy-creating-signature-download-procedure"></a>

**Opção 1: Como criar uma assinatura usando uma política enlatada**

1. Use a função de hash SHA-1 e a chave privada RSA ou ECDSA gerada para assinar e adicionar um hash à declaração de política criada no procedimento [Para criar a declaração de política para um signed URL que usa uma política padrão](#private-content-canned-policy-creating-policy-statement-procedure). Use a versão da declaração de política que não inclui mais espaços em branco.

   Para a chave privada exigida pela função hash, use uma chave privada que tenha a chave pública em um grupo de chaves confiável ativo para a distribuição.
**nota**  
O método usado para assinar e adicionar um hash à declaração de política depende da sua linguagem de programação e plataforma. Para obter o código de exemplo, consulte [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md).

1. Remova os espaços em branco (inclusive caracteres de nova linha e de tabulação) da string assinada e com hash.

1. Codifique a string usando codificação base64 MIME. Para obter mais informações, consulte [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) em *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Substitua os caracteres inválidos da query string de um URL por caracteres válidos. A tabela a seguir indica os caracteres válidos e inválidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html)

1. Inclua o valor resultante no seu signed URL depois de `&Signature=` e volte para [Para criar um signed URL usando uma política padrão](#private-content-creating-signed-url-canned-policy-procedure) para concluir a concatenação das partes dele.

# Criar um URL assinado usando uma política personalizada
<a name="private-content-creating-signed-url-custom-policy"></a>

Para criar um URL assinado usando uma política personalizada, execute o procedimento a seguir.<a name="private-content-creating-signed-url-custom-policy-procedure"></a>

**Para criar um signed URL usando uma política personalizada**

1. Se você estiver usando o .NET ou Java para criar signed URLs e não tiver reformatado a chave privada do seu par de chaves para do formato padrão .pem para um formato compatível com o .NET ou Java, faça isso agora. Para obter mais informações, consulte [Reformatar a chave privada (somente .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concatene os valores a seguir. Você pode usar o formato neste exemplo de URL assinado.

   

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIyMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F
   ```

   Remova todos os espaços vazios (inclusive caracteres de nova linha e de tabulação). Pode ser necessário incluir caracteres de escape na string do código do aplicativo. Todos os valores têm um tipo de `String`.  
**1. *URL base do arquivo***  
O URL base é o URL do CloudFront usado para acessar o arquivo se você não estivesse usando signed URLs, inclusive seus próprios parâmetros de query string, se houver. No exemplo anterior, o URL de base é `https://d111111abcdef8.cloudfront.net/image.jpg`. Para mais informações sobre o formato dos URLs para distribuições, consulte [Personalizar o formato do URL para arquivos no CloudFront](LinkFormat.md).  
Os exemplos a seguir mostram os valores que você especifica para suas distribuições.  
   + O URL do CloudFront a seguir é para um arquivo de imagem em uma distribuição (usando o nome de domínio do CloudFront). Observe que `image.jpg` está em um diretório `images`. O caminho para o arquivo no URL deve corresponder ao caminho para o arquivo no servidor HTTP ou no bucket do Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + O seguinte URL do CloudFront inclui uma query string:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Os URLs do CloudFront a seguir são para arquivos de imagem em uma distribuição. Os dois usam um nome de domínio alternativo; o segundo inclui uma query string:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + O URL do CloudFront a seguir é para um arquivo de imagem em uma distribuição que usa um nome de domínio alternativo e o protocolo HTTPS:

     `https://www.example.com/images/image.jpg`  
**2. `?`**  
O `?` indica que os parâmetros de string de consulta seguem o URL base. Inclua o `?` mesmo que você não especifique nenhum parâmetro de consulta.  
Você pode especificar os parâmetros de consulta a seguir em qualquer ordem.  
**3. *Seus parâmetros de string de consulta, se houver*`&`**  
(Opcional) Você pode inserir seus próprios parâmetros de string de consulta. Para fazer isso, adicione um e comercial (&) entre cada um, como `color=red&size=medium`. Você pode especificar parâmetros de string de consulta em qualquer ordem dentro do URL.  
Seus parâmetros de string de consulta não podem ser especificados como `Policy`, `Signature` ou `Key-Pair-Id`.
Se você adicionar seus próprios parâmetros, inclua `&` depois de cada um deles, inclusive o último.   
**4. `Policy=`*versão da declaração de política codificada em base***  
Sua declaração de política no formato JSON, sem espaços em branco e com codificação base64. Para obter mais informações, consulte [Criar uma declaração de política para um URL assinado que use uma política personalizada](#private-content-custom-policy-statement).  
A declaração de política controla o acesso que um signed URL concede a um usuário. Ela inclui o URL do arquivo, uma data e hora de expiração, uma data e hora opcionais em que o URL se torna válido e um endereço IP opcional ou intervalo de endereços IP que tenha permissão para acessar o arquivo.  
**5. `&Signature=`*versão assinada e com hash da declaração de política***  
Uma versão assinada, com hash e codificação base64 da declaração de política do JSON. Para obter mais informações, consulte [Criar uma assinatura para um URL que use uma política personalizada](#private-content-custom-policy-creating-signature).  
**6. `&Key-Pair-Id=`*ID da chave pública do CloudFront cuja chave privada correspondente está sendo usada para gerar a assinatura***  
O ID de uma chave pública do CloudFront, por exemplo, `K2JCJMDEHXQW5F`. O ID da chave pública informa ao CloudFront qual chave pública deve ser usada para validar o signed URL. O CloudFront compara as informações da assinatura com as informações da declaração de política para verificar se o URL não foi adulterado.  
Essa chave pública deve pertencer a um grupo de chaves que seja um signatário confiável na distribuição. Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

## Criar uma declaração de política para um URL assinado que use uma política personalizada
<a name="private-content-custom-policy-statement"></a>

Conclua as etapas a seguir para criar uma declaração de política para um signed URL que usa uma política personalizada.

Para obter exemplos de declarações de política que controlam o acesso a arquivos de diversas formas, consulte [Exemplos de declaração de política para um signed URL que usa uma política personalizada](#private-content-custom-policy-statement-examples).<a name="private-content-custom-policy-creating-policy-procedure"></a>

**Para criar a declaração de política para um signed URL que usa uma política personalizada**

1. Crie a declaração de política usando o formato JSON a seguir. Substitua os símbolos menor que (`<`) e maior que (`>`) e as descrições contidas neles por seus próprios valores. Para obter mais informações, consulte [Valores especificados na declaração de política para um signed URL que usa uma política personalizada](#private-content-custom-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "<Optional but recommended: URL of the file>",
               "Condition": {
                   "DateLessThan": {
   	                "AWS:EpochTime": <Required: ending date and time in Unix time format and UTC>
                   },
                   "DateGreaterThan": {
   	                "AWS:EpochTime": <Optional: beginning date and time in Unix time format and UTC>
                   },
                   "IpAddress": {
   	                "AWS:SourceIp": "<Optional: IP address>"
                   }
               }
           }
       ]
   }
   ```

   Observe o seguinte:
   + É possível incluir somente uma declaração na política.
   + Use a codificação de caracteres UTF-8.
   + Inclua todas as pontuações e nomes de parâmetro exatamente como especificado. Abreviações de nomes de parâmetro não são aceitas.
   + A ordem dos parâmetros na seção `Condition` não é importante.
   + Para obter informações sobre os valores de `Resource`, `DateLessThan`, `DateGreaterThan` e `IpAddress`, consulte [Valores especificados na declaração de política para um signed URL que usa uma política personalizada](#private-content-custom-policy-statement-values).

1. Remova todas os espaços em branco (inclusive caracteres de nova linha e de tabulação) da declaração de política. Pode ser necessário incluir caracteres de escape na string do código do aplicativo.

1. Codifique a declaração de política usando codificação base64 MIME. Para obter mais informações, consulte [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) em *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Substitua os caracteres inválidos da query string de um URL por caracteres válidos. A tabela a seguir indica os caracteres válidos e inválidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Inclua o valor resultante ao seu signed URL depois de `Policy=`.

1. Crie uma assinatura para o signed URL adicionando hash, assinando e codificando em Base64 a declaração de política. Para obter mais informações, consulte [Criar uma assinatura para um URL que use uma política personalizada](#private-content-custom-policy-creating-signature).

### Valores especificados na declaração de política para um signed URL que usa uma política personalizada
<a name="private-content-custom-policy-statement-values"></a>

Ao criar uma declaração de política para uma política personalizada, especifique os valores a seguir.

**Recurso**  
O URL, incluindo quaisquer strings de consulta, mas excluindo os parâmetros `Policy`, `Signature` e `Key-Pair-Id` do CloudFront. Por exemplo:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg\?size=large&license=yes`  
Você pode especificar somente um valor para `Resource`.  
Você pode omitir o parâmetro `Resource` de uma política, mas isso significa que qualquer pessoa com o signed URL poderá acessar *todos* os arquivos de *qualquer* distribuição associada ao par de chaves usado para criar o signed URL.
Observe o seguinte:  
+ **Protocolo**: o valor deve começar com `http://`, `https://` ou `*://`.
+ **Parâmetros da string de consulta**: se o URL tiver parâmetros da string de consulta, não use um caractere de barra invertida (`\`) para escapar do caractere de ponto de interrogação (`?`) que inicia a string de consulta. Por exemplo:

  `https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`
+ **Caracteres curinga**: é possível usar caracteres curinga no URL da política. Os seguintes caracteres curinga são compatíveis:
  + asterisco (`*`), que corresponde a zero ou mais caracteres
  + ponto de interrogação (`?`) corresponde exatamente a um caractere

  Quando o CloudFront combina o URL na política com o URL na solicitação HTTP, o URL na política é dividido em quatro seções (protocolo, domínio, caminho e string de consulta) da seguinte forma:

  `[protocol]://[domain]/[path]\?[query string]`

  Quando você usa um caractere curinga no URL da política, a correspondência de curingas se aplica somente dentro dos limites da seção que contém o curinga. Por exemplo, considere este signed URL em uma política:

  `https://www.example.com/hello*world`

  Neste exemplo, o caractere curinga asterisco (`*`) só se aplica à seção do caminho, portanto, ele corresponde aos URLs `https://www.example.com/helloworld` e `https://www.example.com/hello-world`, mas não corresponde ao URL `https://www.example.net/hello?world`.

  As seguintes exceções se aplicam aos limites da seção para a correspondência de curingas:
  + Um asterisco final na seção do caminho implica um asterisco na seção da string de consulta. Por exemplo, `http://example.com/hello*` equivale a `http://example.com/hello*\?*`.
  + Um asterisco final na seção do domínio implica um asterisco nas seções do caminho e da string de consulta. Por exemplo, `http://example.com*` equivale a `http://example.com*/*\?*`.
  + Um URL na política pode omitir a seção do protocolo e começar com um asterisco na seção do domínio. Nesse caso, a seção do protocolo é definida implicitamente como um asterisco. Por exemplo, o URL `*example.com` em uma política é equivalente a `*://*example.com/`.
  + Um asterisco por si só (`"Resource": "*"`) corresponde a qualquer URL.

  Por exemplo, o valor `https://d111111abcdef8.cloudfront.net/*game_download.zip*` em uma política corresponde a todos os seguintes URLs:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nomes de domínio alternativos**: se você especificar um nome de domínio alternativo (CNAME) no URL na política, A solicitação HTTP deverá usar o nome do domínio alternativo na sua página da web ou aplicação. Não especifique o URL do Amazon S3 para o arquivo em uma política.

**DateLessThan**  
A data e hora de expiração do URL no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Na política, não coloque os valores entre aspas. Para obter informações sobre UTC, consulte [Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339).  
Por exemplo, 31 de janeiro de 2023, 10h UTC é convertido em 1675159200 no formato de hora do Unix.  
Esse é o único parâmetro obrigatório na seção `Condition`. O CloudFront requer esse valor para impedir que os usuários tenham acesso permanente ao seu conteúdo privado.  
Para obter mais informações, consulte . [Quando o CloudFront confere a data e hora de validade de um URL assinado?](private-content-signed-urls.md#private-content-check-expiration)

**DateGreaterThan (opcional)**  
Uma data e hora de início opcional do URL no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Os usuários não podem acessar o arquivo antes ou na data e hora especificadas. Não coloque os valores entre aspas. 

**IpAddress (opcional)**  
O endereço IP do cliente que está fazendo a solicitação HTTP. Observe o seguinte:  
+ Para permitir o acesso de qualquer endereço IP ao arquivo, omita o parâmetro `IpAddress`.
+ É possível especificar um ou vários endereços IP. Por exemplo, você não pode usar a política que permitir o acesso se o endereço IP do cliente estiver em um de dois intervalos separados.
+ Para permitir o acesso de um único endereço IP, especifique:

  `"`*IPv4 IP address*`/32"`
+ Você deve especificar os intervalos de endereço IP no formato CIDR IPv4 padrão (por exemplo, `192.0.2.0/24`). Para obter mais informações, consulte [Encaminhamento Entre Domínios Sem Classificação (CIDR): A atribuição do endereço da Internet e o plano de agregação](https://tools.ietf.org/html/rfc4632).
**Importante**  
Endereços IP no formato IPv6, como 2001:0db8:85a3::8a2e:0370:7334, não são compatíveis. 

  Se você estiver usando uma política personalizada que inclui `IpAddress`, não permita o IPv6 para a distribuição. Se você quiser restringir o acesso a um conteúdo por endereço IP e oferecer suporte a solicitações IPv6 para outro tipo de conteúdo, crie duas distribuições. Para obter mais informações, consulte [Habilitar IPv6 (solicitações do visualizador)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

## Exemplos de declaração de política para um signed URL que usa uma política personalizada
<a name="private-content-custom-policy-statement-examples"></a>

Os exemplos de declaração de política a seguir mostram como controlar o acesso a um arquivo específico, todos os arquivos de um diretório ou todos os arquivos associados a um ID de par de chaves. Os exemplos também mostram como controlar o acesso de um único endereço IP ou um intervalo de endereços IP e como evitar que os usuários usem o signed URL após a data e hora especificadas.

Se você copiar e colar qualquer um desses exemplos, remova os espaços em branco (inclusive caracteres de nova linha e de tabulação), substitua os valores pelos seus próprios valores e inclua um caractere de nova linha após a chave de fechamento (`}`).

Para obter mais informações, consulte [Valores especificados na declaração de política para um signed URL que usa uma política personalizada](#private-content-custom-policy-statement-values).

**Topics**
+ [Exemplo de declaração de política: acessar um arquivo de um intervalo de endereços IP](#private-content-custom-policy-statement-example-one-object)
+ [Exemplo de declaração de política: acessar todos os arquivos de um diretório em um intervalo de endereços IP](#private-content-custom-policy-statement-example-all-objects)
+ [Exemplo de declaração de política: acessar todos os arquivos associados a um ID de par de chaves de um endereço IP](#private-content-custom-policy-statement-example-one-ip)

### Exemplo de declaração de política: acessar um arquivo de um intervalo de endereços IP
<a name="private-content-custom-policy-statement-example-one-object"></a>

O exemplo a seguir de política personalizada em um signed URL especifica que um usuário pode acessar o arquivo `https://d111111abcdef8.cloudfront.net/game_download.zip` de endereços IP no intervalo `192.0.2.0/24` até 31 de janeiro de 2023, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

### Exemplo de declaração de política: acessar todos os arquivos de um diretório em um intervalo de endereços IP
<a name="private-content-custom-policy-statement-example-all-objects"></a>

O exemplo a seguir de política personalizada permite criar signed URLs para qualquer arquivo no diretório `training`, conforme indicado pelo caractere curinga (`*`) no parâmetro `Resource`. Os usuários podem acessar o arquivo de um endereço IP no intervalo `192.0.2.0/24` até 31 de janeiro de 2023, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

Cada signed URL com o qual você usa essa política tem um URL que identifica um arquivo específico, por exemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Exemplo de declaração de política: acessar todos os arquivos associados a um ID de par de chaves de um endereço IP
<a name="private-content-custom-policy-statement-example-one-ip"></a>

O exemplo de política personalizada a seguir permite que você crie signed URLs para qualquer arquivo associado a qualquer distribuição, conforme indicado pelo caractere curinga `*` no parâmetro `Resource`. O signed URL deve usar o protocolo `https://`, não o `http://`. O usuário deve usar o endereço IP `192.0.2.10/32`. (O valor `192.0.2.10/32` na notação CIDR se refere a um único endereço IP, `192.0.2.10`.) Os arquivos estão disponíveis somente de 31 de janeiro de 2023, 10h UTC, a 2 de fevereiro de 2023, 10h UTC:

```
{
    "Statement": [
       {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1675159200
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675332000
                }
            }
        }
    ]
}
```

Cada signed URL com o qual você usa essa política tem um URL que identifica um arquivo específico em uma distribuição específica do CloudFront, por exemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

O signed URL também inclui um ID de par de chaves, que deve estar associado a um grupo de chaves confiável na distribuição (d111111abcdef8.cloudfront.net) especificada no URL.

## Criar uma assinatura para um URL que use uma política personalizada
<a name="private-content-custom-policy-creating-signature"></a>

A assinatura de um signed URL que usa uma política personalizada é uma versão da declaração de política com hash, assinada e codificada em base64. Para criar uma assinatura para uma política personalizada, conclua as etapas a seguir.

Para obter mais informações e exemplos de como adicionar hash, assinar e codificar a declaração de política, consulte:
+ [Comandos do Linux e OpenSSL para criptografia e codificação base64](private-content-linux-openssl.md)
+ [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-custom-policy-creating-signature-download-procedure"></a>

**Opção 1: Como criar uma assinatura usando uma política personalizada**

1. Use a função de hash SHA-1 e a chave privada RSA ou ECDSA gerada para assinar e adicionar um hash JSON à declaração de política criada no procedimento [Para criar a declaração de política para um signed URL que usa uma política personalizada](#private-content-custom-policy-creating-policy-procedure). Use a versão da declaração de política que não inclui mais espaços em branco, mas que ainda não foi codificada em base64.

   Para a chave privada exigida pela função hash, use uma chave privada que tenha a chave pública em um grupo de chaves confiável ativo para a distribuição.
**nota**  
O método usado para assinar e adicionar um hash à declaração de política depende da sua linguagem de programação e plataforma. Para obter o código de exemplo, consulte [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md).

1. Remova os espaços em branco (inclusive caracteres de nova linha e de tabulação) da string assinada e com hash.

1. Codifique a string usando codificação base64 MIME. Para obter mais informações, consulte [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) em *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Substitua os caracteres inválidos da query string de um URL por caracteres válidos. A tabela a seguir indica os caracteres válidos e inválidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Inclua o valor resultante no seu signed URL depois de `&Signature=` e volte para [Para criar um signed URL usando uma política personalizada](#private-content-creating-signed-url-custom-policy-procedure) para concluir a concatenação das partes dele.

# Usar cookies assinados
<a name="private-content-signed-cookies"></a>

Os signed cookies do CloudFront permitem controlar quem pode acessar seu conteúdo quando você não quiser alterar seus URLs atuais ou quando quiser fornecer acesso a vários arquivos restritos, por exemplo, todos os arquivos da área de assinantes de um site. Este tópico explica as considerações ao usar signed cookies e descreve como defini-los usando políticas padrão e personalizadas.

**Topics**
+ [Decidir usar políticas predefinidas ou personalizadas para cookies assinados](#private-content-choosing-canned-custom-cookies)
+ [Como signed cookies funcionam](#private-content-how-signed-cookies-work)
+ [Evitar o uso indevido de cookies assinados](#private-content-signed-cookie-misuse)
+ [Quando o CloudFront confere a data e hora de validade de um cookie assinado](#private-content-check-expiration-cookie)
+ [Código de exemplo e ferramentas de terceiros](#private-content-overview-sample-code-cookies)
+ [Definir cookies assinados usando uma política predefinida](private-content-setting-signed-cookie-canned-policy.md)
+ [Definir cookies assinados usando uma política personalizada](private-content-setting-signed-cookie-custom-policy.md)
+ [Criar cookies assinados usando PHP](signed-cookies-PHP.md)

## Decidir usar políticas predefinidas ou personalizadas para cookies assinados
<a name="private-content-choosing-canned-custom-cookies"></a>

Ao criar um signed cookie, você grava uma declaração de política no formato JSON que especifica as restrições no signed cookie, por exemplo, por quanto tempo o cookie é válido. Você pode usar políticas padrão ou personalizadas. A tabela a seguir compara as políticas personalizadas e padrão:


****  

| Descrição | Política padrão | Política personalizada | 
| --- | --- | --- | 
| Você pode reutilizar a declaração de política para vários arquivos. Para reutilizar a declaração de política, é necessário usar caracteres curinga no objeto `Resource`. Para obter mais informações, consulte [Valores especificados na declaração de uma política personalizada para signed cookies](private-content-setting-signed-cookie-custom-policy.md#private-content-custom-policy-statement-cookies-values).)  | Não | Sim | 
| Você pode especificar a data e a hora em que os usuários podem começar a acessar seu conteúdo | Não | Sim (opcional) | 
| Você pode especificar a data e a hora em que os usuários não podem mais acessar seu conteúdo | Sim | Sim | 
| Você pode especificar o endereço IP ou vários endereços IP dos usuários que podem acessar seu conteúdo | Não | Sim (opcional) | 

Para obter informações sobre como criar signed cookies usando uma política padrão, consulte [Definir cookies assinados usando uma política predefinida](private-content-setting-signed-cookie-canned-policy.md).

Para obter informações sobre como criar signed cookies usando uma política personalizada, consulte [Definir cookies assinados usando uma política personalizada](private-content-setting-signed-cookie-custom-policy.md).

## Como signed cookies funcionam
<a name="private-content-how-signed-cookies-work"></a>

A seguir, uma visão geral de como configurar o CloudFront para signed cookies e como o CloudFront responde quando um usuário envia uma solicitação que contenha um signed cookie. 

1. Na sua distribuição do CloudFront, especifique um ou mais grupos de chaves confiáveis, que contenham as chaves públicas que o CloudFront pode usar para verificar a assinatura do URL. Use as chaves privadas correspondentes para assinar os URLs.

   Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

1. Desenvolva seu aplicativo para determinar se um usuário deve ter acesso a seu conteúdo e, em caso afirmativo, para enviar três cabeçalhos `Set-Cookie` para o visualizador. (Cada cabeçalho `Set-Cookie` pode conter somente um par de nome/valor, e um signed cookie do CloudFront requer três pares de nome/valor.) Você deve enviar os cabeçalhos `Set-Cookie` para o visualizador antes de ele solicitar o conteúdo privado. Se você definir uma hora de expiração breve no cookie, envie mais três cabeçalhos `Set-Cookie` em resposta a solicitações subsequentes para que o usuário continue tendo acesso.

   Normalmente, a distribuição do CloudFront terá pelo menos dois comportamentos de cache: um que não exige autenticação e um que exige. A página de erro da parte segura do site inclui um redirecionador ou link para uma página de login.

   Se você configurar sua distribuição para armazenar arquivos em cache com base em cookies, o CloudFront não armazenará arquivos separados com base nos atributos nos signed cookies.

1. Um usuário faz login em seu site e paga pelo conteúdo ou cumpre outro requisito de acessar.

1. O aplicativo retorna os cabeçalhos `Set-Cookie` na resposta, e o visualizador armazena os pares de nome-valor.

1. O usuário solicita um arquivo.

   O navegador do usuário ou outro visualizador obtém os pares de nome-valor da etapa 4 e os adiciona à solicitação em um cabeçalho `Cookie`. Esse é o signed cookie.

1. O CloudFront usa a chave pública para validar a assinatura no signed cookie e confirmar se o cookie não foi adulterado. Se a assinatura for inválida, a solicitação será rejeitada.

   Se a assinatura do cookie for válida, o CloudFront analisará a declaração de política no cookie (ou criará uma se você estiver usando uma política padrão) para confirmar se a solicitação continua válida. Por exemplo, se você especificou uma data e hora de início e término para o cookie, o CloudFront confirmará se o usuário está tentando acessar o conteúdo durante o período de acesso permitido.

   Se a solicitação cumprir os requisitos da declaração de política, o CloudFront fornecerá o conteúdo, como o faz com conteúdo não restrito: determina se o arquivo já está no ponto de presença de caches, encaminha a solicitação para a origem, se necessário, e retorna o arquivo para o usuário.

## Evitar o uso indevido de cookies assinados
<a name="private-content-signed-cookie-misuse"></a>

Se você especificar o parâmetro `Domain` em um cabeçalho `Set-Cookie`, especifique o valor mais preciso possível para reduzir o possível acesso por alguém com o mesmo nome de domínio raiz. Por exemplo, app.example.com é preferível a example.com, especialmente quando você não tem o controle sobre example.com. Isso ajuda a evitar que alguém acesse seu conteúdo de www.example.com.

Para ajudar a evitar esse tipo de ataque:
+ Exclua os atributos de cookie `Expires` e `Max-Age` para que o cabeçalho `Set-Cookie` crie um cookie de sessão. Cookies de sessão são automaticamente excluídos quando o usuário fecha o navegador, diminuindo a possibilidade de alguém obter acesso não autorizado ao seu conteúdo.
+ Inclua o atributo `Secure` para que o cookie seja criptografado quando o visualizador incluí-lo em uma solicitação.
+ Quando possível, use uma política personalizada e inclua o endereço IP do visualizador.
+ No atributo `CloudFront-Expires`, especifique o menor tempo de expiração razoável com base em quanto tempo você deseja que os usuários tenham acesso a seu conteúdo.

## Quando o CloudFront confere a data e hora de validade de um cookie assinado
<a name="private-content-check-expiration-cookie"></a>

Para determinar se um signed cookie continua válido, o CloudFront verifica a data e hora de expiração dele no momento da solicitação HTTP. Se um cliente começar a fazer download de um grande arquivo logo antes da hora de expiração, o download será concluído mesmo se passar a hora de expiração durante o download. Se a conexão TCP cair e o cliente tentar reiniciar o download após a hora de expiração, ocorrerá falha no download.

Se o cliente usar Range GETs para obter um arquivo em partes menores, ocorrerá falha em qualquer solicitação GET que ocorrer após a hora de expiração. Para obter mais informações sobre Range GETs, consulte [Como o CloudFront processa solicitações parciais de um objeto (Range GETs)](RangeGETs.md).

## Código de exemplo e ferramentas de terceiros
<a name="private-content-overview-sample-code-cookies"></a>

O código de exemplo do conteúdo privado mostra apenas como criar a assinatura para signed URLs. No entanto, o processo de criação de uma assinatura para um signed cookie é semelhante, ou seja, a maior parte do código de exemplo é relevante. Para saber mais, consulte os seguintes tópicos: 
+ [Criar uma assinatura de URL usando Perl](CreateURLPerl.md)
+ [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md)
+ [Criar uma assinatura de URL usando C\$1 e o .NET Framework](CreateSignatureInCSharp.md)
+ [Criar uma assinatura de URL usando Java](CFPrivateDistJavaDevelopment.md)

# Definir cookies assinados usando uma política predefinida
<a name="private-content-setting-signed-cookie-canned-policy"></a>

Para definir um signed cookie usando uma política padrão, execute as seguintes etapas. Para criar a assinatura, consulte [Criar uma assinatura para um cookie assinado que use uma política predefinida](#private-content-canned-policy-signature-cookies).<a name="private-content-setting-signed-cookie-canned-policy-procedure"></a>

**Para definir um signed cookie usando uma política padrão**

1. Se estiver usando o .NET ou o Java para criar signed cookies e não tiver reformatado a chave privada de seu par de chaves do formato padrão .pem para um formato compatível com o .NET ou o Java, faça isso agora. Para obter mais informações, consulte [Reformatar a chave privada (somente .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programe seu aplicativo para enviar três cabeçalhos `Set-Cookie` para os visualizadores aprovados. São necessários três cabeçalhos `Set-Cookie` porque cada cabeçalho `Set-Cookie` pode conter somente um par de nome/valor, e um signed cookie do CloudFront requer três pares. Os pares de nome-valor são: `CloudFront-Expires`, `CloudFront-Signature` e `CloudFront-Key-Pair-Id`. Os valores devem estar presentes no visualizador antes de um usuário fazer a primeira solicitação de um arquivo ao qual você deseja controlar o acesso. 
**nota**  
Em geral, recomendamos que você exclua os atributos `Expires` e `Max-Age`. A exclusão dos atributos faz com que o navegador exclua o cookie quando o usuário fecha o navegador, diminuindo a possibilidade de alguém obter acesso não autorizado ao seu conteúdo. Para obter mais informações, consulte [Evitar o uso indevido de cookies assinados](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Os nomes dos atributos de cookie fazem distinção entre letras maiúsculas e minúsculas**. 

   As quebras de linha são incluídas apenas para tornar os atributos mais legíveis.

   ```
   Set-Cookie: 
   CloudFront-Expires=date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC); 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Opcional) `Domain`**  
O nome de domínio do arquivo solicitado. Se você não especificar um atributo `Domain`, o valor padrão será o nome de domínio do URL, e ele se aplica apenas ao nome de domínio em questão, não aos subdomínios. Se você especificar um atributo `Domain`, ele também será aplicado aos subdomínios. Um ponto inicial no nome de domínio (por exemplo, `Domain=.example.com`) é opcional. Além disso, se você especificar um atributo `Domain`, o nome de domínio do URL e o valor do atributo `Domain` deverão ser correspondentes.  
É possível especificar o nome de domínio atribuído pelo CloudFront à sua distribuição, por exemplo, d111111abcdef8.cloudfront.net, mas é possível especificar \$1.cloudfront.net para o nome de domínio.  
Se você quiser usar um nome de domínio alternativo, como example.com nos URLs, deverá adicioná-lo à sua distribuição, independentemente de especificá-lo no atributo `Domain` ou não. Para obter mais informações, consulte [Nomes de domínio alternativos (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).  
**(Opcional) `Path`**  
O caminho do arquivo solicitado. Se você não especificar um atributo `Path`, o valor padrão será o caminho do URL.  
**`Secure`**  
Exige que o visualizador criptografe os cookies antes de enviar uma solicitação. Recomendamos que você envie o cabeçalho `Set-Cookie` por uma conexão HTTPS para garantir que os atributos de cookie estejam protegidos de ataques a intermediários.  
**`HttpOnly`**  
Define como o navegador (quando compatível) interage com o valor do cookie. Com `HttpOnly`, os valores dos cookies são inacessíveis ao JavaScript. Essa precaução pode ajudar a mitigar os ataques conhecidos como cross-site scripting (XSS). Consulte mais informações em [Using HTTP cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies).  
**`CloudFront-Expires`**  
Especifique a data e hora de expiração no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Por exemplo, 1.º de janeiro de 2026 10h UTC é convertido em 1357034400 no formato de hora do Unix.   
Para usar o tempo de época, especifique um número inteiro de 64 bits para uma data que não seja posterior a `9223372036854775807` (sexta-feira, 11 de abril de 2262 às 23:47:16.854 UTC).  
Para obter informações sobre UTC, consulte a *RFC 3339, Date and Time on the Internet: Timestamps*, [https://tools.ietf.org/html/rfc3339](https://tools.ietf.org/html/rfc3339).  
**`CloudFront-Signature`**  
Uma versão assinada, com hash e codificação base64 de uma declaração de política do JSON. Para obter mais informações, consulte [Criar uma assinatura para um cookie assinado que use uma política predefinida](#private-content-canned-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
O ID de uma chave pública do CloudFront, por exemplo, `K2JCJMDEHXQW5F`. O ID da chave pública informa ao CloudFront qual chave pública deve ser usada para validar o signed URL. O CloudFront compara as informações da assinatura com as informações da declaração de política para verificar se o URL não foi adulterado.  
Essa chave pública deve pertencer a um grupo de chaves que seja um signatário confiável na distribuição. Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

O exemplo a seguir mostra cabeçalhos de `Set-Cookie` de um signed cookie quando você está usando o nome de domínio associado à sua distribuição nas URLs de seus arquivos:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
```

O exemplo a seguir mostra cabeçalhos de `Set-Cookie` de um signed cookie quando você está usando o nome de domínio alternativo example.org nas URLs de seus arquivos:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/images/*; Secure; HttpOnly
```

Se você quiser usar um nome de domínio alternativo, como example.com nos URLs, deverá adicioná-lo à sua distribuição, independentemente de especificá-lo no atributo `Domain` ou não. Para obter mais informações, consulte [Nomes de domínio alternativos (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

## Criar uma assinatura para um cookie assinado que use uma política predefinida
<a name="private-content-canned-policy-signature-cookies"></a>

Para criar a assinatura de um cookie que use uma política predefinida, siga estes procedimentos.

**Topics**
+ [Criar uma declaração de política para um cookie assinado que use uma política predefinida](#private-content-canned-policy-statement-cookies)
+ [Assinar a declaração de política para criar uma assinatura para um cookie assinado que use uma política predefinida](#private-content-canned-policy-cookies-signing-policy-statement)

### Criar uma declaração de política para um cookie assinado que use uma política predefinida
<a name="private-content-canned-policy-statement-cookies"></a>

Ao definir um signed cookie que usa uma política padrão, o atributo `CloudFront-Signature` será uma versão assinada e com hash de uma declaração de política. Para signed cookies que usam uma política padrão, a declaração de política não é incluída no cabeçalho `Set-Cookie`, como é feito nos signed cookies que usam uma política personalizada. Para criar a declaração de política, conclua as etapas a seguir.<a name="private-content-canned-policy-statement-cookies-procedure"></a>

**Para criar uma declaração de política para um signed cookie que usa uma política padrão**

1. Crie a declaração de política usando o formato JSON a seguir e a codificação de caracteres UTF-8. Inclua todas as pontuações e outros valores literais exatamente como especificado. Para obter informações sobre os parâmetros `Resource` e `DateLessThan`, consulte [Valores especificados na declaração de uma política padrão para signed cookies](#private-content-canned-policy-statement-cookies-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Remova todas os espaços em branco (inclusive caracteres de nova linha e de tabulação) da declaração de política. Pode ser necessário incluir caracteres de escape na string do código do aplicativo.

#### Valores especificados na declaração de uma política padrão para signed cookies
<a name="private-content-canned-policy-statement-cookies-values"></a>

Ao criar uma declaração de política para uma política padrão, especifique os valores a seguir:

**Recurso**  
O URL base, inclusive suas query strings, se houver, por exemplo:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Você pode especificar apenas um valor para `Resource`.  
Observe o seguinte:  
+ **Protocolo**: o valor deve começar com `http://` ou `https://`.
+ **Parâmetros de query string** :se você não tiver query strings, omita o ponto de interrogação.
+ **Nomes de domínio alternativos**: se especificar um nome de domínio alternativo (CNAME) no URL, você deverá especificá-lo ao fazer referência ao arquivo na sua página da web ou aplicação. Não especifique o URL do Amazon S3 para o arquivo.

**DateLessThan**  
A data e hora de expiração do URL no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Não coloque os valores entre aspas.  
Por exemplo, 16 de março de 2015, 10h UTC é convertido para 1426500000 no formato de hora do Unix.  
Esse valor deve corresponder ao valor do atributo `CloudFront-Expires` no cabeçalho `Set-Cookie`. Não coloque os valores entre aspas.  
Para obter mais informações, consulte [Quando o CloudFront confere a data e hora de validade de um cookie assinado](private-content-signed-cookies.md#private-content-check-expiration-cookie).

#### Exemplo de declaração de política para uma política padrão
<a name="private-content-canned-policy-cookies-sample-policy-statement"></a>

Ao usar o seguinte exemplo de declaração de política em um signed cookie, um usuário pode acessar o arquivo `https://d111111abcdef8.cloudfront.net/horizon.jpg` até 16 de março de 2015, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1426500000
                }
            }
        }
    ]
}
```

### Assinar a declaração de política para criar uma assinatura para um cookie assinado que use uma política predefinida
<a name="private-content-canned-policy-cookies-signing-policy-statement"></a>

Para criar o valor para o atributo `CloudFront-Signature` em um cabeçalho `Set-Cookie`, assine e adicione um hash à declaração de política criada em [Para criar uma declaração de política para um signed cookie que usa uma política padrão](#private-content-canned-policy-statement-cookies-procedure). 

Para obter mais informações e exemplos de como adicionar hash, assinar e codificar a declaração de política, consulte os seguintes tópicos:
+ [Comandos do Linux e OpenSSL para criptografia e codificação base64](private-content-linux-openssl.md)
+ [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-canned-policy-cookie-creating-signature-procedure"></a>

**Para criar uma assinatura para um signed cookie usando uma política padrão**

1. Use a função de hash SHA-1 e o RSA para assinar e adicionar um hash à declaração de política criada no procedimento [Para criar uma declaração de política para um signed cookie que usa uma política padrão](#private-content-canned-policy-statement-cookies-procedure). Use a versão da declaração de política que não inclui mais espaços em branco.

   Para a chave privada exigida pela função hash, use uma chave privada que tenha a chave pública em um grupo de chaves confiável ativo para a distribuição.
**nota**  
O método usado para assinar e adicionar um hash à declaração de política depende da sua linguagem de programação e plataforma. Para obter o código de exemplo, consulte [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md).

1. Remova os espaços em branco (inclusive caracteres de nova linha e de tabulação) da string assinada e com hash.

1. Codifique a string usando codificação base64 MIME. Para obter mais informações, consulte [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) em *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Substitua os caracteres inválidos da query string de um URL por caracteres válidos. A tabela a seguir indica os caracteres válidos e inválidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html)

1. Inclua o valor resultante no cabeçalho `Set-Cookie` para o par de nome-valor `CloudFront-Signature`. Em seguida, volte para [Para definir um signed cookie usando uma política padrão](#private-content-setting-signed-cookie-canned-policy-procedure) e adicione o cabeçalho `Set-Cookie` em `CloudFront-Key-Pair-Id`.

# Definir cookies assinados usando uma política personalizada
<a name="private-content-setting-signed-cookie-custom-policy"></a>

Para definir um signed cookie que usa uma política personalizada, execute as etapas a seguir.<a name="private-content-setting-signed-cookie-custom-policy-procedure"></a>

**Para definir um signed cookie usando uma política personalizada**

1. Se você estiver usando o .NET ou Java para criar signed URLs e não tiver reformatado a chave privada do seu par de chaves para do formato padrão .pem para um formato compatível com o .NET ou Java, faça isso agora. Para obter mais informações, consulte [Reformatar a chave privada (somente .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programe seu aplicativo para enviar três cabeçalhos `Set-Cookie` para os visualizadores aprovados. São necessários três cabeçalhos `Set-Cookie` porque cada cabeçalho `Set-Cookie` pode conter somente um par de nome/valor, e um signed cookie do CloudFront requer três pares. Os pares de nome-valor são: `CloudFront-Policy`, `CloudFront-Signature` e `CloudFront-Key-Pair-Id`. Os valores devem estar presentes no visualizador antes de um usuário fazer a primeira solicitação de um arquivo ao qual você deseja controlar o acesso. 
**nota**  
Em geral, recomendamos que você exclua os atributos `Expires` e `Max-Age`. Isso faz com que o navegador exclua o cookie quando o usuário fecha o navegador, diminuindo a possibilidade de alguém obter acesso não autorizado ao seu conteúdo. Para obter mais informações, consulte [Evitar o uso indevido de cookies assinados](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Os nomes dos atributos de cookie fazem distinção entre letras maiúsculas e minúsculas**. 

   As quebras de linha são incluídas apenas para tornar os atributos mais legíveis.

   ```
   Set-Cookie: 
   CloudFront-Policy=base64 encoded version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Opcional) `Domain`**  
O nome de domínio do arquivo solicitado. Se você não especificar um atributo `Domain`, o valor padrão será o nome de domínio do URL, e ele se aplica apenas ao nome de domínio em questão, não aos subdomínios. Se você especificar um atributo `Domain`, ele também será aplicado aos subdomínios. Um ponto inicial no nome de domínio (por exemplo, `Domain=.example.com`) é opcional. Além disso, se você especificar um atributo `Domain`, o nome de domínio do URL e o valor do atributo `Domain` deverão ser correspondentes.  
É possível especificar o nome de domínio atribuído pelo CloudFront à sua distribuição, por exemplo, d111111abcdef8.cloudfront.net, mas é possível especificar \$1.cloudfront.net para o nome de domínio.  
Se você quiser usar um nome de domínio alternativo, como example.com nos URLs, deverá adicioná-lo à sua distribuição, independentemente de especificá-lo no atributo `Domain` ou não. Para obter mais informações, consulte [Nomes de domínio alternativos (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).  
**(Opcional) `Path`**  
O caminho do arquivo solicitado. Se você não especificar um atributo `Path`, o valor padrão será o caminho do URL.  
**`Secure`**  
Exige que o visualizador criptografe os cookies antes de enviar uma solicitação. Recomendamos que você envie o cabeçalho `Set-Cookie` por uma conexão HTTPS para garantir que os atributos de cookie estejam protegidos de ataques a intermediários.  
**`HttpOnly`**  
Exige que o visualizador envie o cookie apenas em solicitações HTTP ou HTTPS.  
**`CloudFront-Policy`**  
Sua declaração de política no formato JSON, sem espaços em branco e com codificação base64. Para obter mais informações, consulte [Criar uma assinatura para um cookie assinado que use uma política personalizada](#private-content-custom-policy-signature-cookies).  
A declaração de política controla o acesso que um signed cookie concede a um usuário. Ela inclui os arquivos que o usuário pode acessar, uma data e hora de expiração, uma data e hora opcionais em que o URL se torna válido e um endereço IP opcional ou intervalo de endereços IP que tenham permissão para acessar o arquivo.  
**`CloudFront-Signature`**  
Uma versão assinada, com hash e codificação base64 da declaração de política do JSON. Para obter mais informações, consulte [Criar uma assinatura para um cookie assinado que use uma política personalizada](#private-content-custom-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
O ID de uma chave pública do CloudFront, por exemplo, `K2JCJMDEHXQW5F`. O ID da chave pública informa ao CloudFront qual chave pública deve ser usada para validar o signed URL. O CloudFront compara as informações da assinatura com as informações da declaração de política para verificar se o URL não foi adulterado.  
Essa chave pública deve pertencer a um grupo de chaves que seja um signatário confiável na distribuição. Para obter mais informações, consulte [Especificar os assinantes que podem criar URLs e cookies assinados](private-content-trusted-signers.md).

## Exemplos de cabeçalhos `Set-Cookie` para políticas personalizadas
<a name="example-set-cookie-headers-custom-policy"></a>

Veja os exemplos a seguir de pares de cabeçalhos `Set-Cookie`. 

Se quiser usar um nome de domínio alternativo, como exemplo.org nos URLs, deverá adicioná-lo à sua distribuição, independentemente de especificá-lo no atributo `Domain` ou não. Para saber mais, consulte [Nomes de domínio alternativos (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

**Example Exemplo 1**  
É possível usar os cabeçalhos `Set-Cookie` de um signed cookie quando estiver usando o nome de domínio associado à sua distribuição nos URLs dos seus arquivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Exemplo 2**  
É possível usar cabeçalhos `Set-Cookie` de um signed cookie quando você estiver usando um nome de domínio alternativo (exemplo.org) nos URLs dos seus arquivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
```

**Example Exemplo 3**  
É possível usar os pares de cabeçalho `Set-Cookie` de uma solicitação assinada quando estiver usando o nome de domínio associado à sua distribuição nos URLs dos seus arquivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=dd111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Exemplo 4**  
É possível usar os pares de cabeçalho `Set-Cookie` de uma solicitação assinada quando estiver usando um nome de domínio alternativo (exemplo.org) associado à sua distribuição nos URLs dos seus arquivos.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
```

## Criar uma declaração de política para um cookie assinado que use uma política personalizada
<a name="private-content-custom-policy-statement-cookies"></a>

Para criar uma declaração de política para uma política personalizada, conclua as etapas a seguir. Para obter vários exemplos de declaração de política que controlam o acesso a arquivos de diversas formas, consulte [Exemplos de declaração de política para um signed cookie que usa uma política personalizada](#private-content-custom-policy-statement-signed-cookies-examples).<a name="private-content-custom-policy-statement-cookies-procedure"></a>

**Para criar a declaração de política para um signed cookie que usa uma política personalizada**

1. Crie a declaração de política usando o formato JSON a seguir.

   ```
   {
       "Statement": [
           {
               "Resource": "URL of the file",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime":required ending date and time in Unix time format and UTC
                   },
                   "DateGreaterThan": {
                       "AWS:EpochTime":optional beginning date and time in Unix time format and UTC
                   },
                   "IpAddress": {
                       "AWS:SourceIp": "optional IP address"
                   }
               }
           }
       ]
   }
   ```

   Observe o seguinte:
   + Você pode incluir apenas uma instrução.
   + Use a codificação de caracteres UTF-8.
   + Inclua todas as pontuações e nomes de parâmetro exatamente como especificado. Abreviações de nomes de parâmetro não são aceitas.
   + A ordem dos parâmetros na seção `Condition` não é importante.
   + Para obter informações sobre os valores de `Resource`, `DateLessThan`, `DateGreaterThan` e `IpAddress`, consulte [Valores especificados na declaração de uma política personalizada para signed cookies](#private-content-custom-policy-statement-cookies-values).

1. Remova todas os espaços em branco (inclusive caracteres de nova linha e de tabulação) da declaração de política. Pode ser necessário incluir caracteres de escape na string do código do aplicativo.

1. Codifique a declaração de política usando codificação base64 MIME. Para obter mais informações, consulte [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) em *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Substitua os caracteres inválidos da query string de um URL por caracteres válidos. A tabela a seguir indica os caracteres válidos e inválidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Inclua o valor resultante em seu cabeçalho `Set-Cookie` depois de `CloudFront-Policy=`.

1. Crie uma assinatura para o cabeçalho `Set-Cookie` em `CloudFront-Signature` adicionando hash, assinando e codificando em base64 a declaração de política. Para obter mais informações, consulte [Criar uma assinatura para um cookie assinado que use uma política personalizada](#private-content-custom-policy-signature-cookies).

### Valores especificados na declaração de uma política personalizada para signed cookies
<a name="private-content-custom-policy-statement-cookies-values"></a>

Ao criar uma declaração de política para uma política personalizada, especifique os valores a seguir.

**Recurso**  
O URL base, inclusive suas query strings, se houver:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Se você omitir o parâmetro `Resource`, os usuários poderão acessar todos os arquivos associados a qualquer distribuição associada ao par de chaves usado para criar o signed URL.
Você pode especificar apenas um valor para `Resource`.  
Observe o seguinte:  
+ **Protocolo**: o valor deve começar com `http://` ou `https://`.
+ **Parâmetros de query string** :se você não tiver query strings, omita o ponto de interrogação.
+ **Curingas**: é possível usar o caractere curinga que corresponde a zero ou mais caracteres (\$1) ou o caractere curinga que corresponde a exatamente um caractere (?) em qualquer lugar na string. Por exemplo, o valor:

  `https://d111111abcdef8.cloudfront.net/*game_download.zip*`

  incluiria os seguintes arquivos:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nomes de domínio alternativos**: se especificar um nome de domínio alternativo (CNAME) no URL, você deverá especificá-lo ao fazer referência ao arquivo na sua página da web ou aplicação. Não especifique o URL do Amazon S3 para o arquivo.

**DateLessThan**  
A data e hora de expiração do URL no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Não coloque os valores entre aspas.  
Por exemplo, 16 de março de 2015, 10h UTC é convertido para 1426500000 no formato de hora do Unix.  
Para obter mais informações, consulte [Quando o CloudFront confere a data e hora de validade de um cookie assinado](private-content-signed-cookies.md#private-content-check-expiration-cookie).

**DateGreaterThan (opcional)**  
Uma data e hora de início opcional do URL no formato de hora do Unix (em segundos) e no Tempo Universal Coordenado (UTC). Os usuários não podem acessar o arquivo antes ou na data e hora especificadas. Não coloque os valores entre aspas. 

**IpAddress (opcional)**  
O endereço IP do cliente que está fazendo a solicitação GET. Observe o seguinte:  
+ Para permitir o acesso de qualquer endereço IP ao arquivo, omita o parâmetro `IpAddress`.
+ Você pode especificar um ou vários endereços IP. Por exemplo, você não pode definir que a política permita o acesso se o endereço IP do cliente estiver em um de dois intervalos separados.
+ Para permitir o acesso de um único endereço IP, especifique:

  `"`*IPv4 IP address*`/32"`
+ Você deve especificar os intervalos de endereço IP no formato CIDR IPv4 padrão (por exemplo, `192.0.2.0/24`). Para obter mais informações, acesse a *RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan*, [https://tools.ietf.org/html/rfc4632](https://tools.ietf.org/html/rfc4632).
**Importante**  
Endereços IP no formato IPv6, como 2001:0db8:85a3::8a2e:0370:7334, não são compatíveis. 

  Se você estiver usando uma política personalizada que inclui `IpAddress`, não permita o IPv6 para a distribuição. Se você quiser restringir o acesso a um conteúdo por endereço IP e oferecer suporte a solicitações IPv6 para outro tipo de conteúdo, crie duas distribuições. Para obter mais informações, consulte [Habilitar IPv6 (solicitações do visualizador)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) no tópico [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

## Exemplos de declaração de política para um signed cookie que usa uma política personalizada
<a name="private-content-custom-policy-statement-signed-cookies-examples"></a>

Os exemplos de declaração de política a seguir mostram como controlar o acesso a um arquivo específico, todos os arquivos de um diretório ou todos os arquivos associados a um ID de par de chaves. Os exemplos também mostram como controlar o acesso de um único endereço IP ou um intervalo de endereços IP e como evitar que os usuários usem o signed cookie após a data e hora especificadas.

Se você copiar e colar qualquer um desses exemplos, remova os espaços em branco (inclusive caracteres de nova linha e de tabulação), substitua os valores pelos seus próprios valores e inclua um caractere de nova linha após a chave de fechamento ( \$1 ).

Para obter mais informações, consulte [Valores especificados na declaração de uma política personalizada para signed cookies](#private-content-custom-policy-statement-cookies-values).

**Topics**
+ [Exemplo de declaração de política: acessar um arquivo de um intervalo de endereços IP](#private-content-custom-policy-statement-signed-cookies-example-one-object)
+ [Exemplo de declaração de política: acessar todos os arquivos de um diretório em um intervalo de endereços IP](#private-content-custom-policy-statement-signed-cookies-example-all-objects)
+ [Exemplo de declaração de política: acessar todos os arquivos associados a um ID de par de chaves de um endereço IP](#private-content-custom-policy-statement-signed-cookies-example-one-ip)

### Exemplo de declaração de política: acessar um arquivo de um intervalo de endereços IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-object"></a>

O exemplo a seguir de política personalizada em um signed cookie especifica que um usuário pode acessar o arquivo `https://d111111abcdef8.cloudfront.net/game_download.zip` de endereços IP no intervalo `192.0.2.0/24` até 1.º de janeiro de 2023, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Exemplo de declaração de política: acessar todos os arquivos de um diretório em um intervalo de endereços IP
<a name="private-content-custom-policy-statement-signed-cookies-example-all-objects"></a>

O exemplo a seguir de política personalizada permite criar signed cookies para qualquer arquivo no diretório `training`, conforme indicado pelo caractere curinga "\$1" no parâmetro `Resource`. Os usuários podem acessar o arquivo de um endereço IP no intervalo `192.0.2.0/24` até 1º de janeiro de 2013, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

Cada signed cookie em que você usa essa política inclui um URL base que identifica um arquivo específico, por exemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Exemplo de declaração de política: acessar todos os arquivos associados a um ID de par de chaves de um endereço IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-ip"></a>

O exemplo a seguir de política personalizada permite definir signed cookies para qualquer arquivo associado a qualquer distribuição, conforme indicado pelo caractere curinga "\$1" no parâmetro `Resource`. O usuário deve usar o endereço IP `192.0.2.10/32`. (O valor `192.0.2.10/32` na notação CIDR se refere a um único endereço IP, `192.0.2.10`.) Os arquivos estão disponíveis apenas de 1º de janeiro de 2013, 10h UTC, a 2 de janeiro de 2013, 10h UTC:

```
{
    "Statement": [
        {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1767290400
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767376800
                }
            }
        }
    ]
}
```

Cada signed cookie em que você usa essa política inclui um URL base que identifica um arquivo específico em uma distribuição específica do CloudFront, por exemplo:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

O signed cookie também inclui o ID de um par de chaves, que deve estar associado a um grupo de chaves confiável na distribuição (d111111abcdef8.cloudfront.net) especificada no URL base.

## Criar uma assinatura para um cookie assinado que use uma política personalizada
<a name="private-content-custom-policy-signature-cookies"></a>

A assinatura de um signed cookie que usa uma política personalizada é uma versão da declaração de política com hash, assinada e codificada em base64. 

Para obter mais informações e exemplos de como adicionar hash, assinar e codificar a declaração de política, consulte:
+ [Comandos do Linux e OpenSSL para criptografia e codificação base64](private-content-linux-openssl.md)
+ [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-custom-policy-signature-cookies-procedure"></a>

**Para criar uma assinatura para um signed cookie usando uma política personalizada**

1. Use a função de hash SHA-1 e o RSA para assinar e adicionar um hash à declaração de política do JSON criada no procedimento [Para criar a declaração de política para um signed URL que usa uma política personalizada](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-creating-policy-procedure). Use a versão da declaração de política que não inclui mais espaços em branco, mas que ainda não foi codificada em base64.

   Para a chave privada exigida pela função hash, use uma chave privada que tenha a chave pública em um grupo de chaves confiável ativo para a distribuição.
**nota**  
O método usado para assinar e adicionar um hash à declaração de política depende da sua linguagem de programação e plataforma. Para obter o código de exemplo, consulte [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md).

1. Remova os espaços em branco (inclusive caracteres de nova linha e de tabulação) da string assinada e com hash.

1. Codifique a string usando codificação base64 MIME. Para obter mais informações, consulte [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) em *RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies*.

1. Substitua os caracteres inválidos da query string de um URL por caracteres válidos. A tabela a seguir indica os caracteres válidos e inválidos.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Inclua o valor resultante no cabeçalho `Set-Cookie` para o par de nome-valor `CloudFront-Signature=` e volte para [Para definir um signed cookie usando uma política personalizada](#private-content-setting-signed-cookie-custom-policy-procedure) adicionar o cabeçalho `Set-Cookie` em `CloudFront-Key-Pair-Id`.

# Criar cookies assinados usando PHP
<a name="signed-cookies-PHP"></a>

O exemplo de código a seguir é semelhante ao exemplo em [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md), em que ele cria um link para um vídeo. No entanto, em vez de assinar o URL no código, esse exemplo assina os cookies com a função `create_signed_cookies()`. O player do lado do cliente usa os cookies para autenticar cada solicitação à distribuição do CloudFront.

Essa abordagem é útil para transmitir conteúdo, como HTTP Live Streaming (HLS) ou Dynamic Adaptive Streaming over HTTP (DASH), em que o cliente precisa fazer várias solicitações para recuperar o manifesto, os segmentos e os ativos de reprodução relacionados. Ao usar cookies assinados, o cliente pode autenticar cada solicitação sem precisar gerar um novo URL assinado para cada segmento. 

**nota**  
A criação de uma assinatura de URL é apenas uma parte do processo de fornecimento de conteúdo privado por meio de cookies assinados. Para obter mais informações, consulte [Usar cookies assinados](private-content-signed-cookies.md).



**Topics**
+ [Criar a assinatura RSA SHA-1](#create-rsa-sha-1signature-cookies)
+ [Criar os cookies assinados](#create-the-signed-cookie)
+ [Código completo](#full-code-signed-cookies)

As seções a seguir dividem o exemplo de código em partes individuais. Você pode encontrar o [exemplo de código](#full-code-signed-cookies) completo abaixo.

## Criar a assinatura RSA SHA-1
<a name="create-rsa-sha-1signature-cookies"></a>

Este exemplo faz o seguinte:

1. A função `rsa_sha1_sign` cria o hash e assina a declaração de política. Os argumentos necessários são uma declaração de política e a chave privada que corresponde a uma chave pública que está em um grupo de chaves confiável para sua distribuição.

1. Em seguida, a função `url_safe_base64_encode` cria uma versão da assinatura segura para URL.

   ```
   function rsa_sha1_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid);
       openssl_free_key($pkeyid);
       return $signature;
   }
   
   function url_safe_base64_encode($value) {
       $encoded = base64_encode($value);
       return str_replace(
           array('+', '=', '/'),
           array('-', '_', '~'),
           $encoded);
   }
   ```

## Criar os cookies assinados
<a name="create-the-signed-cookie"></a>

O código a seguir constrói e cria os cookies assinados, usando os seguintes atributos de cookie: `CloudFront-Expires`, `CloudFront-Signature` e `CloudFront-Key-Pair-Id`. O código usa uma política personalizada.

```
function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null) {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    $encoded_signature = url_safe_base64_encode($signature);

    return array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );
}
```

Para obter mais informações, consulte [Definir cookies assinados usando uma política personalizada](private-content-setting-signed-cookie-custom-policy.md).

## Código completo
<a name="full-code-signed-cookies"></a>

O exemplo de código a seguir oferece uma demonstração completa de como criar cookies assinados do CloudFront com PHP. Você pode baixar o exemplo completo no arquivo [demo-php.zip](samples/demo-php.zip).

No exemplo a seguir, é possível modificar o elemento `$policy Condition` para permitir os intervalos de endereços IPv4 e IPv6. Por exemplo, consulte [Como usar endereços do IPv6 em políticas do IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) no *Guia do usuário do Amazon Simple Storage Service*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid);
    openssl_free_key($pkeyid);
    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null) {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    $encoded_signature = url_safe_base64_encode($signature);

    return array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );
}



$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';
$base_url = 'https://d1234.cloudfront.net';

$expires = time() + 3600; // 1 hour from now

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];


// For HLS manifest and segments (using wildcard)
$hls_resource = $base_url . '/sign/*';
$signed_cookies = create_signed_cookies($hls_resource, $private_key_filename, $key_pair_id, $expires, $client_ip);

// Set the cookies
$cookie_domain = parse_url($base_url, PHP_URL_HOST);
foreach ($signed_cookies as $name => $value) {
    setcookie($name, $value, $expires, '/', $cookie_domain, true, true);
}

?>

<!DOCTYPE html>
<html>
<head>
    <title>CloudFront Signed HLS Stream with Cookies</title>
</head>
<body>
    <h1>Amazon CloudFront Signed HLS Stream with Cookies</h1>
    <h2>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h2>
    
    <div id='hls-video'>
        <video id="video" width="640" height="360" controls></video>
    </div>

    <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
    <script>
        var video = document.getElementById('video');
        var manifestUrl = '<?php echo $base_url; ?>/sign/manifest.m3u8';
        
        if (Hls.isSupported()) {
            var hls = new Hls();
            hls.loadSource(manifestUrl);
            hls.attachMedia(video);
        }
        else if (video.canPlayType('application/vnd.apple.mpegurl')) {
            video.src = manifestUrl;
        }
    </script>
</body>
</html>
```

Em vez de usar cookies assinados, você pode usar URLs assinados. Para obter mais informações, consulte [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md).

# Comandos do Linux e OpenSSL para criptografia e codificação base64
<a name="private-content-linux-openssl"></a>

Você pode usar o comando de linha de comando do Linux a seguir e o OpenSSL para adicionar hash e assinar a declaração de política, codificar a assinatura em base64 e substituir caracteres inválidos dos parâmetros de query string do URL por caracteres válidos.

Para obter informações sobre o OpenSSL, acesse [https://www.openssl.org](https://www.openssl.org).

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha1 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

No comando anterior:
+ `cat` lê o arquivo `policy`.
+ `tr -d "\n" | tr -d " \t\n\r"` remove os espaços em branco e o caractere de nova linha que foram adicionados por `cat`.
+ O OpenSSL adiciona hash ao arquivo usando SHA-1 e o assina usando o arquivo de chave privada `private_key.pem`. A assinatura da chave privada pode ser RSA 2048 ou ECDSA 256.
+ O OpenSSL codifica em base64 a instrução de política assinada e com hash.
+ `tr` O substitui os caracteres inválidos dos parâmetros de string de consulta do URL pelos caracteres válidos.

Consulte mais exemplos de código que demonstram como criar uma assinatura em [Exemplos de código para criar uma assinatura para um signed URL](PrivateCFSignatureCodeAndExamples.md).

# Exemplos de código para criar uma assinatura para um signed URL
<a name="PrivateCFSignatureCodeAndExamples"></a>

Esta seção inclui exemplos de aplicativos para download que demonstram como criar assinaturas para signed URLs. Os exemplos estão disponíveis em Perl, PHP, C\$1 e Java. Você pode usar qualquer um dos exemplos para criar signed URLs. O script Perl é executado nas plataformas Linux e macOS. O exemplo PHP funciona em qualquer servidor com PHP. O exemplo C\$1 usa o .NET Framework.

Para obter um código de exemplo em JavaScript (Node.js), consulte [Criar URLs assinados do Amazon CloudFront em Node.js](https://aws.amazon.com/blogs/developer/creating-amazon-cloudfront-signed-urls-in-node-js/) no Blog do desenvolvedor da AWS.

Para ver um código de exemplo em Python, consulte [Generate a signed URL for Amazon CloudFront](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#examples) na *Referência de API do AWS SDK for Python (Boto3)* e [este código de exemplo](https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst) no repositório do Boto3 no GitHub.

**Topics**
+ [Criar uma assinatura de URL usando Perl](CreateURLPerl.md)
+ [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md)
+ [Criar uma assinatura de URL usando C\$1 e o .NET Framework](CreateSignatureInCSharp.md)
+ [Criar uma assinatura de URL usando Java](CFPrivateDistJavaDevelopment.md)

# Criar uma assinatura de URL usando Perl
<a name="CreateURLPerl"></a>

Esta seção inclui um script Perl para plataformas Linux/Mac que você pode usar para criar a assinatura para conteúdo privado. Para criar a assinatura, execute o script com argumentos de linha de comando que especificam o URL do CloudFront, o caminho para a chave privada do assinante, o ID da chave e uma data de expiração para o URL. A ferramenta também pode decodificar signed URLs. 

**nota**  
A criação de uma assinatura de URL é apenas uma parte do processo de fornecimento de conteúdo privado usando um signed URL. Para obter mais informações sobre o todo o processo, consulte [Usar URLs assinados](private-content-signed-urls.md). 

**Topics**
+ [Fonte do script Perl para criar um signed URL](#CreateURLPerlScriptSource)

## Fonte do script Perl para criar um signed URL
<a name="CreateURLPerlScriptSource"></a>

O seguinte código-fonte Perl pode ser usado para criar uma URL assinada para CloudFront. Os comentários no código incluem informações sobre as opções da linha de comando e os recursos da ferramenta.

```
#!/usr/bin/perl -w

# Copyright 2008 Amazon Technologies, Inc.  Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License. You may obtain a copy of the License at:
#
# https://aws.amazon.com/apache2.0
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and limitations under the License.

=head1 cfsign.pl

cfsign.pl - A tool to generate and verify Amazon CloudFront signed URLs

=head1 SYNOPSIS

This script uses an existing RSA key pair to sign and verify Amazon CloudFront signed URLs

View the script source for details as to which CPAN packages are required beforehand. 

For help, try:

cfsign.pl --help

URL signing examples:

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --policy sample_policy.json --private-key privkey.pem --key-pair-id mykey

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --expires 1257439868 --private-key privkey.pem --key-pair-id mykey

URL decode example:

cfsign.pl --action decode --url "http//mydist.cloudfront.net/?Signature=AGO-PgxkYo99MkJFHvjfGXjG1QDEXeaDb4Qtzmy85wqyJjK7eKojQWa4BCRcow__&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovLypicmFkbS5qcGciLCJDb25kaXRpb24iOnsiSXBBZGRyZXNzIjp7IkFXUzpTb3VyY2VJcCI6IjEwLjUyLjE3LjkvMCJ9LCJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI1MjUyMDgzMH19fV19Cg__&Key-Pair-Id=mykey"


To generate an RSA key pair, you can use openssl and the following commands:

# Generate a 2048 bit key pair
openssl genrsa -out private-key.pem 2048
openssl rsa -in private-key.pem -pubout -out public-key.pem


=head1 OPTIONS

=over 8

=item B<--help>

Print a help message and exits.

=item B<--action> [action]

The action to execute.  action can be one of:

  encode - Generate a signed URL (using a canned policy or a user policy)
  decode - Decode a signed URL

=item B<--url>

The URL to en/decode

=item B<--stream>

The stream to en/decode

=item B<--private-key>

The path to your private key.

=item B<--key-pair-id>

The key pair identifier.

=item B<--policy>

The CloudFront policy document.

=item B<--expires>

The Unix epoch time when the URL is to expire. If both this option and
the --policy option are specified, --policy will be used. Otherwise, this 
option alone will use a canned policy.

=back

=cut

use strict;
use warnings;

# you might need to use CPAN to get these modules.
# run perl -MCPAN -e "install <module>" to get them.
# The openssl command line will also need to be in your $PATH.
use File::Temp qw/tempfile/;
use File::Slurp;
use Getopt::Long;
use IPC::Open2;
use MIME::Base64 qw(encode_base64 decode_base64);
use Pod::Usage;
use URI;

my $CANNED_POLICY 
    = '{"Statement":[{"Resource":"<RESOURCE>","Condition":{"DateLessThan":{"AWS:EpochTime":<EXPIRES>}}}]}';

my $POLICY_PARAM      = "Policy";
my $EXPIRES_PARAM     = "Expires";
my $SIGNATURE_PARAM   = "Signature";
my $KEY_PAIR_ID_PARAM = "Key-Pair-Id";

my $verbose = 0;
my $policy_filename = "";
my $expires_epoch = 0;
my $action = "";
my $help = 0;
my $key_pair_id = "";
my $url = "";
my $stream = "";
my $private_key_filename = "";

my $result = GetOptions("action=s"      => \$action,
                        "policy=s"      => \$policy_filename,
                        "expires=i"     => \$expires_epoch,
                        "private-key=s" => \$private_key_filename,
                        "key-pair-id=s" => \$key_pair_id,
                        "verbose"       => \$verbose,
                        "help"          => \$help,
                        "url=s"         => \$url,
                        "stream=s"      => \$stream,
                    );

if ($help or !$result) {
    pod2usage(1);
    exit;
}

if ($url eq "" and $stream eq "") {
    print STDERR "Must include a stream or a URL to encode or decode with the --stream or --url option\n";
    exit;
}

if ($url ne "" and $stream ne "") {
    print STDERR "Only one of --url and --stream may be specified\n";
    exit;
}

if ($url ne "" and !is_url_valid($url)) {
    exit;
}

if ($stream ne "") {
    exit unless is_stream_valid($stream);

    # The signing mechanism is identical, so from here on just pretend we're
    # dealing with a URL
    $url = $stream;
} 

if ($action eq "encode") {
    # The encode action will generate a private content URL given a base URL, 
    # a policy file (or an expires timestamp) and a key pair id parameter
    my $private_key;
    my $public_key;
    my $public_key_file;
    
    my $policy;
    if ($policy_filename eq "") {
        if ($expires_epoch == 0) {
            print STDERR "Must include policy filename with --policy argument or an expires" . 
                          "time using --expires\n";            
        }
        
        $policy = $CANNED_POLICY;
        $policy =~ s/<EXPIRES>/$expires_epoch/g;
        $policy =~ s/<RESOURCE>/$url/g;
    } else {
        if (! -e $policy_filename) {
            print STDERR "Policy file $policy_filename does not exist\n";
            exit;
        }
        $expires_epoch = 0; # ignore if set
        $policy = read_file($policy_filename);
    }

    if ($private_key_filename eq "") {
        print STDERR "You must specific the path to your private key file with --private-key\n";
        exit;
    }

    if (! -e $private_key_filename) {
        print STDERR "Private key file $private_key_filename does not exist\n";
        exit;
    }

    if ($key_pair_id eq "") {
        print STDERR "You must specify a key pair id with --key-pair-id\n";
        exit;
    }

    my $encoded_policy = url_safe_base64_encode($policy);
    my $signature = rsa_sha1_sign($policy, $private_key_filename);
    my $encoded_signature = url_safe_base64_encode($signature);

    my $generated_url = create_url($url, $encoded_policy, $encoded_signature, $key_pair_id, $expires_epoch);


    if ($stream ne "") {
        print "Encoded stream (for use within a swf):\n" . $generated_url . "\n";
        print "Encoded and escaped stream (for use on a webpage):\n" .  escape_url_for_webpage($generated_url) . "\n"; 
    } else {
        print "Encoded URL:\n" . $generated_url . "\n";
    }
} elsif ($action eq "decode") {
    my $decoded = decode_url($url);
    if (!$decoded) {
        print STDERR "Improperly formed URL\n";
        exit;
    }

    print_decoded_url($decoded);
} else {
    # No action specified, print help.  But only if this is run as a program (caller will be empty)
    pod2usage(1) unless caller();
}

# Decode a private content URL into its component parts
sub decode_url {
    my $url = shift;

    if ($url =~ /(.*)\?(.*)/) {
        my $base_url = $1;
        my $params = $2;

        my @unparsed_params = split(/&/, $params);
        my %params = ();
        foreach my $param (@unparsed_params) {
            my ($key, $val) = split(/=/, $param);
            $params{$key} = $val;
        }

        my $encoded_signature = "";
        if (exists $params{$SIGNATURE_PARAM}) {
            $encoded_signature = $params{"Signature"};
        } else {
            print STDERR "Missing Signature URL parameter\n";
            return 0;
        }

        my $encoded_policy = "";
        if (exists $params{$POLICY_PARAM}) {
            $encoded_policy = $params{$POLICY_PARAM};
        } else {
            if (!exists $params{$EXPIRES_PARAM}) {
                print STDERR "Either the Policy or Expires URL parameter needs to be specified\n";
                return 0;    
            }
            
            my $expires = $params{$EXPIRES_PARAM};
            
            my $policy = $CANNED_POLICY;
            $policy =~ s/<EXPIRES>/$expires/g;
            
            my $url_without_cf_params = $url;
            $url_without_cf_params =~ s/$SIGNATURE_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$POLICY_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$EXPIRES_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$KEY_PAIR_ID_PARAM=[^&]*&?//g;
            
            if ($url_without_cf_params =~ /(.*)\?$/) {
                $url_without_cf_params = $1;
            }
            
            $policy =~ s/<RESOURCE>/$url_without_cf_params/g;
            
            $encoded_policy = url_safe_base64_encode($policy);
        }

        my $key = "";
        if (exists $params{$KEY_PAIR_ID_PARAM}) {
            $key = $params{$KEY_PAIR_ID_PARAM};
        } else {
            print STDERR "Missing $KEY_PAIR_ID_PARAM parameter\n";
            return 0;
        }

        my $policy = url_safe_base64_decode($encoded_policy);

        my %ret = ();
        $ret{"base_url"} = $base_url;
        $ret{"policy"} = $policy;
        $ret{"key"} = $key;

        return \%ret;
    } else {
        return 0;
    }
}

# Print a decoded URL out
sub print_decoded_url {
    my $decoded = shift;

    print "Base URL: \n" . $decoded->{"base_url"} . "\n";
    print "Policy: \n" . $decoded->{"policy"} . "\n";
    print "Key: \n" . $decoded->{"key"} . "\n";
}

# Encode a string with base 64 encoding and replace some invalid URL characters
sub url_safe_base64_encode {
    my ($value) = @_;

    my $result = encode_base64($value);
    $result =~ tr|+=/|-_~|;

    return $result;
}

# Decode a string with base 64 encoding.  URL-decode the string first
# followed by reversing any special character ("+=/") translation.
sub url_safe_base64_decode {
    my ($value) = @_;

    $value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
    $value =~ tr|-_~|+=/|;

    my $result = decode_base64($value);

    return $result;
}

# Create a private content URL
sub create_url {
    my ($path, $policy, $signature, $key_pair_id, $expires) = @_;
    
    my $result;
    my $separator = $path =~ /\?/ ? '&' : '?';
    if ($expires) {
        $result = "$path$separator$EXPIRES_PARAM=$expires&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    } else {
        $result = "$path$separator$POLICY_PARAM=$policy&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    }
    $result =~ s/\n//g;

    return $result;
}

# Sign a document with given private key file.
# The first argument is the document to sign
# The second argument is the name of the private key file
sub rsa_sha1_sign {
    my ($to_sign, $pvkFile) = @_;
    print "openssl sha1 -sign $pvkFile $to_sign\n";

    return write_to_program($pvkFile, $to_sign);
}

# Helper function to write data to a program
sub write_to_program {
my ($keyfile, $data) = @_;
unlink "temp_policy.dat" if (-e "temp_policy.dat");
unlink "temp_sign.dat" if (-e "temp_sign.dat");

write_file("temp_policy.dat", $data);

system("openssl dgst -sha1 -sign \"$keyfile\" -out temp_sign.dat temp_policy.dat");

my $output = read_file("temp_sign.dat");

    return $output;
}

# Read a file into a string and return the string
sub read_file {
    my ($file) = @_;

    open(INFILE, "<$file") or die("Failed to open $file: $!");
    my $str = join('', <INFILE>);
    close INFILE;

    return $str;
}

sub is_url_valid {
    my ($url) = @_;

    # HTTP distributions start with http[s]:// and are the correct thing to sign
    if ($url =~ /^https?:\/\//) {
        return 1;
    } else {
        print STDERR "CloudFront requires absolute URLs for HTTP distributions\n";
        return 0;
    }
}

sub is_stream_valid {
    my ($stream) = @_;

    if ($stream =~ /^rtmp:\/\// or $stream =~ /^\/?cfx\/st/) {
        print STDERR "Streaming distributions require that only the stream name is signed.\n";
        print STDERR "The stream name is everything after, but not including, cfx/st/\n";
        return 0;
    } else {
        return 1;
    }
}

# flash requires that the query parameters in the stream name are url
# encoded when passed in through javascript, etc.  This sub handles the minimal
# required url encoding.
sub escape_url_for_webpage {
    my ($url) = @_;

    $url =~ s/\?/%3F/g;
    $url =~ s/=/%3D/g;
    $url =~ s/&/%26/g;

    return $url;
}

1;
```

# Criar uma assinatura de URL usando PHP
<a name="CreateURL_PHP"></a>

Qualquer servidor da web que execute PHP pode usar esse exemplo de código PHP para criar declarações de política e assinaturas para distribuições privadas do CloudFront. O exemplo completo cria uma página da web ativa com links de signed URL que reproduzem um streaming de vídeo usando streaming do CloudFront. Você pode baixar o exemplo completo no arquivo [demo-php.zip](samples/demo-php.zip).

**Observações**  
A criação de uma assinatura de URL é apenas uma parte do processo de fornecimento de conteúdo privado usando um signed URL. Para obter mais informações sobre o todo o processo, consulte [Usar URLs assinados](private-content-signed-urls.md). 
Você também pode criar URLs assinados usando a classe `UrlSigner` no AWS SDK para PHP. Para obter mais informações, consulte [Classe UrlSigner](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CloudFront.UrlSigner.html) na *Referência de API do AWS SDK para PHP*.

**Topics**
+ [Criar a assinatura RSA SHA-1](#sample-rsa-sign)
+ [Criar uma política predefinida](#sample-canned-policy)
+ [Criar uma política personalizada](#sample-custom-policy)
+ [Exemplo de código completo](#full-example)

As seções a seguir dividem o exemplo de código em partes individuais. Você pode encontrar o [Exemplo de código completo](#full-example) abaixo.

## Criar a assinatura RSA SHA-1
<a name="sample-rsa-sign"></a>

Este exemplo faz o seguinte:
+ A função `rsa_sha1_sign` cria o hash e assina a declaração de política. Os argumentos necessários são uma declaração de política e a chave privada que corresponde a uma chave pública que está em um grupo de chaves confiável para sua distribuição. 
+ Em seguida, a função `url_safe_base64_encode` cria uma versão da assinatura segura para URL.

```
function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with 
    // the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}
```

O trecho de código a seguir usa as funções `get_canned_policy_stream_name()` e `get_custom_policy_stream_name()` para criar uma política predefinida e uma personalizada. O CloudFront usa as políticas para criar o URL para transmitir o vídeo, bem como especificar o tempo de expiração. 

Em seguida, você pode usar uma política predefinida ou uma política personalizada para determinar como gerenciar o acesso ao seu conteúdo. Para ter mais informações sobre qual escolher, consulte a seção [Decidir usar políticas predefinidas ou personalizadas para URLs assinados](private-content-signed-urls.md#private-content-choosing-canned-custom-policy).

## Criar uma política predefinida
<a name="sample-canned-policy"></a>

O código de exemplo a seguir cria uma declaração de política *padrão* para a assinatura. 

**nota**  
A variável `$expires` é um carimbo de data/hora que deve ser um número inteiro, não uma string.

```
function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}
```

Para obter mais informações sobre políticas padrão, consulte [Criar um URL assinado usando uma política predefinida](private-content-creating-signed-url-canned-policy.md).

## Criar uma política personalizada
<a name="sample-custom-policy"></a>

O código de exemplo a seguir cria uma declaração de política *personalizada* para a assinatura. 

```
function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}
```

Para obter mais informações sobre políticas personalizadas, consulte [Criar um URL assinado usando uma política personalizada](private-content-creating-signed-url-custom-policy.md).

## Exemplo de código completo
<a name="full-example"></a>

O exemplo de código a seguir fornece uma demonstração completa de como criar signed URLs do CloudFront com PHP. Você pode baixar o exemplo completo no arquivo [demo-php.zip](samples/demo-php.zip).

No exemplo a seguir, é possível modificar o elemento `$policy` `Condition` para permitir os intervalos de endereços do IPv4 e do IPv6. Por exemplo, consulte [Como usar endereços do IPv6 em políticas do IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) no *Guia do usuário do Amazon Simple Storage Service*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_stream_name($stream, $policy, $signature, $key_pair_id, $expires) {
    $result = $stream;
    // if the stream already contains query parameters, attach the new query parameters to the end
    // otherwise, add the query parameters
    $separator = strpos($stream, '?') == FALSE ? '?' : '&';
    // the presence of an expires time means we're using a canned policy
    if($expires) {
        $result .= $separator . "Expires=" . $expires . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }
    // not using a canned policy, include the policy itself in the stream name
    else {
        $result .= $separator . "Policy=" . $policy . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }

    // new lines would break us, so remove them
    return str_replace('\n', '', $result);
}


function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}

function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}


// Path to your private key.  Be very careful that this file is not accessible
// from the web!

$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';

// Make sure you have "Restrict viewer access" enabled on this path behaviour and using the above Trusted key groups (recommended).
$video_path = 'https://example.com/secure/example.mp4';

$expires = time() + 300; // 5 min from now
$canned_policy_stream_name = get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires);

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$policy =
'{'.
    '"Statement":['.
        '{'.
            '"Resource":"'. $video_path . '",'.
            '"Condition":{'.
                '"IpAddress":{"AWS:SourceIp":"' . $client_ip . '/32"},'.
                '"DateLessThan":{"AWS:EpochTime":' . $expires . '}'.
            '}'.
        '}'.
    ']' .
    '}';
$custom_policy_stream_name = get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy);

?>

<html>

<head>
    <title>CloudFront</title>
</head>

<body>
    <h1>Amazon CloudFront</h1>
    <h2>Canned Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?></h3>
    <br />

    <div id='canned'>The canned policy video will be here: <br>
    
        <video width="640" height="360" autoplay muted controls>
        <source src="<?php echo $canned_policy_stream_name; ?>" type="video/mp4">
        Your browser does not support the video tag.
        </video>
    </div>

    <h2>Custom Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h3>
    <div id='custom'>The custom policy video will be here: <br>

         <video width="640" height="360" autoplay muted controls>
         <source src="<?php echo $custom_policy_stream_name; ?>" type="video/mp4">
         Your browser does not support the video tag.
        </video>
    </div> 

</body>

</html>
```

Para obter exemplos adicionais de URL assinado, consulte estes tópicos:
+ [Criar uma assinatura de URL usando Perl](CreateURLPerl.md)
+ [Criar uma assinatura de URL usando C\$1 e o .NET Framework](CreateSignatureInCSharp.md)
+ [Criar uma assinatura de URL usando Java](CFPrivateDistJavaDevelopment.md)

Em vez de usar URLs assinados para criar a assinatura, você pode usar cookies assinados. Para obter mais informações, consulte [Criar cookies assinados usando PHP](signed-cookies-PHP.md).

# Criar uma assinatura de URL usando C\$1 e o .NET Framework
<a name="CreateSignatureInCSharp"></a>

Os exemplos de C\$1 desta seção implementam um exemplo de aplicação que demonstra como criar assinaturas para distribuições privadas do CloudFront usando declarações de política padrão e personalizada. Alguns dos exemplos são as funções de utilitário com base no [AWS SDK para .NET](https://aws.amazon.com/sdkfornet) que podem ser úteis em aplicações .NET.

Você também pode criar URLs assinados e cookies com o uso do SDK para .NET. Na *Referência de API do SDK para .NET*, consulte os seguintes tópicos:
+ **URLs assinados**: [AmazonCloudFrontUrlSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontUrlSigner.html) 
+ **Cookies assinados**: [AmazonCloudFrontCookieSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontCookieSigner.html) 

Para fazer download do código, acesse [Código de assinatura em C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip).

**Observações**  
As classes `AmazonCloudFrontUrlSigner` e `AmazonCloudFrontCookieSigner` foram movidas para um pacote separado. Para ter mais informações sobre como usá-las, consulte [CookieSigner e UrlSigner](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html#net-dg-v4-CookieSigner-UrlSigner) no *Guia do desenvolvedor do AWS SDK para .NET (V4)*. 
A criação de uma assinatura de URL é apenas uma parte do processo de fornecimento de conteúdo privado usando um signed URL. Para obter mais informações, consulte [Usar URLs assinados](private-content-signed-urls.md). Para ter mais informações sobre como usar cookies assinados, consulte [Usar cookies assinados](private-content-signed-cookies.md).

## Usar uma chave RSA no .NET Framework
<a name="rsa-key-sdk-net"></a>

Para usar uma chave RSA no .NET Framework, converta o arquivo .pem da AWS fornecido no formato XML usado pelo .NET Framework.

Após a conversão, o arquivo de chave privada do RSA ficará no seguinte formato:

**Example : chave privada do RSA no formato XML do .NET Framework**  <a name="RSAPrivateKeyXML.NETFrameworkFormat"></a>

```
<RSAKeyValue>
  <Modulus>
    wO5IvYCP5UcoCKDo1dcspoMehWBZcyfs9QEzGi6Oe5y+ewGr1oW+vB2GPB
    ANBiVPcUHTFWhwaIBd3oglmF0lGQljP/jOfmXHUK2kUUnLnJp+oOBL2NiuFtqcW6h/L5lIpD8Yq+NRHg
    Ty4zDsyr2880MvXv88yEFURCkqEXAMPLE=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    5bmKDaTz
    npENGVqz4Cea8XPH+sxt+2VaAwYnsarVUoSBeVt8WLloVuZGG9IZYmH5KteXEu7fZveYd9UEXAMPLE==
  </P>
  <Q>
    1v9l/WN1a1N3rOK4VGoCokx7kR2SyTMSbZgF9IWJNOugR/WZw7HTnjipO3c9dy1Ms9pUKwUF4
    6d7049EXAMPLE==
  </Q>
  <DP>
    RgrSKuLWXMyBH+/l1Dx/I4tXuAJIrlPyo+VmiOc7b5NzHptkSHEPfR9s1
    OK0VqjknclqCJ3Ig86OMEtEXAMPLE==
  </DP>
  <DQ>
    pjPjvSFw+RoaTu0pgCA/jwW/FGyfN6iim1RFbkT4
    z49DZb2IM885f3vf35eLTaEYRYUHQgZtChNEV0TEXAMPLE==
  </DQ>
  <InverseQ>
    nkvOJTg5QtGNgWb9i
    cVtzrL/1pFEOHbJXwEJdU99N+7sMK+1066DL/HSBUCD63qD4USpnf0myc24in0EXAMPLE==</InverseQ>
  <D>
      Bc7mp7XYHynuPZxChjWNJZIq+A73gm0ASDv6At7F8Vi9r0xUlQe/v0AQS3ycN8QlyR4XMbzMLYk
      3yjxFDXo4ZKQtOGzLGteCU2srANiLv26/imXA8FVidZftTAtLviWQZBVPTeYIA69ATUYPEq0a5u5wjGy
      UOij9OWyuEXAMPLE=
   </D>
</RSAKeyValue>
```

## Método de assinatura de política padrão em C\$1
<a name="canned-policy-signed-url-net"></a>

O seguinte código C\$1 cria um URL assinado que usa uma política padrão executando as seguintes etapas:
+ Cria uma declaração de política.
+ Adiciona hash à declaração de política usando SHA1 e assina o resultado usando RSA e a chave privada com a chave pública correspondente que está em um grupo de chaves confiável.
+ Codifica em base64 a declaração de política assinada e com hash e substitui os caracteres especiais para tornar a string segura para ser usada como parâmetro de solicitação de URL.
+ Concatena os valores.

Para obter a implementação completa, consulte o exemplo em [Código de assinatura em C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**nota**  
O `keyId` é exibido quando você faz upload de uma chave pública no CloudFront. Para ter mais informações, consulte ![\[6\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : método de assinatura de política predefinida em C\$1**  <a name="ExampleCannedPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCannedPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string pathToPolicyStmnt, 
    string pathToPrivateKey, string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-pathToPolicyStmnt, 
    // 5-pathToPrivateKey, 6-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);

    // Create the policy statement.
    string strPolicy = CreatePolicyStatement(pathToPolicyStmnt,
        urlString, 
        DateTime.Now, 
        DateTime.Now.Add(timeSpanInterval), 
        "0.0.0.0/0");
    if ("Error!" == strPolicy) return "Invalid time frame." + 
        "Start time cannot be greater than end time.";

    // Copy the expiration time defined by policy statement.
    string strExpiration = CopyExpirationTimeFromPolicy(strPolicy);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    using (SHA1CryptoServiceProvider 
        cryptoSHA1 = new SHA1CryptoServiceProvider())
    {
        bufferPolicy = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA and 
        // create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter rsaFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        rsaFormatter.SetHashAlgorithm("SHA1");
        byte[] signedPolicyHash = rsaFormatter.CreateSignature(bufferPolicy);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedPolicyHash);

        // Concatenate the URL, the timestamp, the signature, 
        // and the key pair ID to form the signed URL.
        return urlString + 
            "?Expires=" + 
            strExpiration + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Método de assinatura de política personalizada em C\$1
<a name="custom-policy-signed-url-net"></a>

O seguinte código C\$1 cria um URL assinado que usa uma política personalizada executando as seguintes etapas:

1. Cria uma declaração de política.

1. Codifica a declaração de política em base64 e substitui os caracteres especiais para tornar a string segura para ser usada como parâmetro de solicitação de URL.

1. Adiciona hash a declaração de política usando SHA1 e criptografa o resultado usando RSA e a chave privada com a chave pública correspondente que está em um grupo de chaves confiável.

1. Codifica em base64 a declaração de política com hash e substitui os caracteres especiais para tornar a string segura para ser usada como parâmetro de solicitação de URL.

1. Concatena os valores.

Para obter a implementação completa, consulte o exemplo em [Código de assinatura em C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**nota**  
O `keyId` é exibido quando você faz upload de uma chave pública no CloudFront. Para ter mais informações, consulte ![\[6\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : método de assinatura de política personalizada em C\$1**  <a name="ExampleCustomPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCustomPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string startIntervalFromNow, 
    string ipaddress, string pathToPolicyStmnt, string pathToPrivateKey, 
    string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-starttimeFromNow, 
    // 5-ip_address, 6-pathToPolicyStmt, 7-pathToPrivateKey, 8-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);
    TimeSpan timeSpanToStart = GetDurationByUnits(durationUnits, 
        startIntervalFromNow);
    if (null == timeSpanToStart) 
        return "Invalid duration units." + 
            "Valid options: seconds, minutes, hours, or days";
            
    string strPolicy = CreatePolicyStatement(
        pathToPolicyStmnt, urlString, DateTime.Now.Add(timeSpanToStart), 
        DateTime.Now.Add(timeSpanInterval), ipaddress);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Convert the policy statement to URL-safe base64 encoding and 
    // replace unsafe characters + = / with the safe characters - _ ~

    string urlSafePolicy = ToUrlSafeBase64String(bufferPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    byte[] bufferPolicyHash;
    using (SHA1CryptoServiceProvider cryptoSHA1 = 
        new SHA1CryptoServiceProvider())
    {
        bufferPolicyHash = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA 
        // and create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter RSAFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        RSAFormatter.SetHashAlgorithm("SHA1");
        byte[] signedHash = RSAFormatter.CreateSignature(bufferPolicyHash);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedHash);

        return urlString + 
            "?Policy=" + 
            urlSafePolicy + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Métodos utilitários para geração de assinaturas
<a name="utility-methods-signed-url"></a>

Os métodos a seguir obtêm a declaração de política de um arquivo e analisam os intervalos de tempo para a geração de assinatura.

**Example : métodos utilitários para geração de assinaturas**  <a name="UtilityMethodsForSignatureGeneration"></a>

```
public static string CreatePolicyStatement(string policyStmnt, 
   string resourceUrl, 
   DateTime startTime, 
   DateTime endTime, 
   string ipAddress)
   
{
   // Create the policy statement.
   FileStream streamPolicy = new FileStream(policyStmnt, FileMode.Open, FileAccess.Read);
   using (StreamReader reader = new StreamReader(streamPolicy))
   {
      string strPolicy = reader.ReadToEnd();

      TimeSpan startTimeSpanFromNow = (startTime - DateTime.Now);
      TimeSpan endTimeSpanFromNow = (endTime - DateTime.Now);
      TimeSpan intervalStart = 
         (DateTime.UtcNow.Add(startTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
      TimeSpan intervalEnd = 
         (DateTime.UtcNow.Add(endTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

      int startTimestamp = (int)intervalStart.TotalSeconds; // START_TIME
      int endTimestamp = (int)intervalEnd.TotalSeconds;  // END_TIME

      if (startTimestamp > endTimestamp)
         return "Error!";

      // Replace variables in the policy statement.
      strPolicy = strPolicy.Replace("RESOURCE", resourceUrl);
      strPolicy = strPolicy.Replace("START_TIME", startTimestamp.ToString());
      strPolicy = strPolicy.Replace("END_TIME", endTimestamp.ToString());
      strPolicy = strPolicy.Replace("IP_ADDRESS", ipAddress);
      strPolicy = strPolicy.Replace("EXPIRES", endTimestamp.ToString());
      return strPolicy;
   }   
}

public static TimeSpan GetDuration(string units, string numUnits)
{
   TimeSpan timeSpanInterval = new TimeSpan();
   switch (units)
   {
      case "seconds":
         timeSpanInterval = new TimeSpan(0, 0, 0, int.Parse(numUnits));
         break;
      case "minutes":
         timeSpanInterval = new TimeSpan(0, 0, int.Parse(numUnits), 0);
         break;
      case "hours":
         timeSpanInterval = new TimeSpan(0, int.Parse(numUnits), 0 ,0);
         break;
      case "days":
         timeSpanInterval = new TimeSpan(int.Parse(numUnits),0 ,0 ,0);
         break;
      default:
         Console.WriteLine("Invalid time units;" + 
            "use seconds, minutes, hours, or days");
         break;
   }
   return timeSpanInterval;
}

private static TimeSpan GetDurationByUnits(string durationUnits, 
   string startIntervalFromNow)
{
   switch (durationUnits)
   {
      case "seconds":
         return new TimeSpan(0, 0, int.Parse(startIntervalFromNow));
      case "minutes":
         return new TimeSpan(0, int.Parse(startIntervalFromNow), 0);
      case "hours":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0);
      case "days":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0, 0);
      default:
         return new TimeSpan(0, 0, 0, 0);
   }
}

public static string CopyExpirationTimeFromPolicy(string policyStatement)
{
   int startExpiration = policyStatement.IndexOf("EpochTime");
   string strExpirationRough = policyStatement.Substring(startExpiration + 
      "EpochTime".Length);
   char[] digits = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
         
   List<char> listDigits = new List<char>(digits);
   StringBuilder buildExpiration = new StringBuilder(20);
         
   foreach (char c in strExpirationRough)
   {
      if (listDigits.Contains(c))
         buildExpiration.Append(c);
   }
   return buildExpiration.ToString();   
}
```

Consulte também
+ [Criar uma assinatura de URL usando Perl](CreateURLPerl.md)
+ [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md)
+ [Criar uma assinatura de URL usando Java](CFPrivateDistJavaDevelopment.md)

# Criar uma assinatura de URL usando Java
<a name="CFPrivateDistJavaDevelopment"></a>

Além do exemplo de código a seguir, você pode usar [a classe de utilitário `CloudFrontUrlSigner` no AWS SDK para Java (versão 1)](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/cloudfront/CloudFrontUrlSigner.html) para criar [signed URLs do CloudFront](private-content-signed-urls.md).

Para ver mais exemplos, consulte [Crie URLs e cookies assinados usando um SDK da AWS](https://docs.aws.amazon.com/code-library/latest/ug/cloudfront_example_cloudfront_CloudFrontUtilities_section.html) na *Biblioteca de códigos de exemplos de códigos do SDK da AWS*. 

**nota**  
Criar um signed URL é somente uma parte do processo de [fornecimento de conteúdo privado com o CloudFront](PrivateContent.md). Para obter mais informações sobre o todo o processo, consulte [Usar URLs assinados](private-content-signed-urls.md).

O exemplo a seguir mostra como criar um signed URL do CloudFront.

**Example Política Java e métodos de criptografia de assinatura**  <a name="ExampleJavaPolicyAndSignatureEncryptionMethods"></a>

```
package org.example;

import java.time.Instant;
import java.time.temporal.ChronoUnit;
import software.amazon.awssdk.services.cloudfront.CloudFrontUtilities;
import software.amazon.awssdk.services.cloudfront.model.CannedSignerRequest;
import software.amazon.awssdk.services.cloudfront.url.SignedUrl;

public class Main {

    public static void main(String[] args) throws Exception {
        CloudFrontUtilities cloudFrontUtilities = CloudFrontUtilities.create();
        Instant expirationDate = Instant.now().plus(7, ChronoUnit.DAYS);
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net";
        String keyPairId = "K1UA3WV15I7JSD";
        CannedSignerRequest cannedRequest = CannedSignerRequest.builder()
                .resourceUrl(resourceUrl)
                .privateKey(new java.io.File("/path/to/private_key.pem").toPath())
                .keyPairId(keyPairId)
                .expirationDate(expirationDate)
                .build();
        SignedUrl signedUrl = cloudFrontUtilities.getSignedUrlWithCannedPolicy(cannedRequest);
        String url = signedUrl.url();
        System.out.println(url);

    }
}
```

Consulte também:
+ [Criar uma assinatura de URL usando Perl](CreateURLPerl.md)
+ [Criar uma assinatura de URL usando PHP](CreateURL_PHP.md)
+ [Criar uma assinatura de URL usando C\$1 e o .NET Framework](CreateSignatureInCSharp.md)

# Restringir o acesso a uma origem da AWS
<a name="private-content-restricting-access-to-origin"></a>

É possível configurar o CloudFront e algumas origens da AWS de uma forma que ofereça os seguintes benefícios:
+ Restringir o acesso à origem da AWS para que ela não fique acessível ao público.
+ Garantir que os visualizadores (usuários) possam acessar o conteúdo na origem da AWS somente por meio da distribuição especificada do CloudFront. Isso impede que os visualizadores acessem o conteúdo diretamente da origem ou por meio de uma distribuição inesperada do CloudFront.

Para fazer isso, configure o CloudFront para enviar solicitações autenticadas para a origem da AWS e configure a origem da AWS para permitir acesso às solicitações autenticadas do CloudFront. Para ter mais informações, consulte os tópicos a seguir para obter os tipos compatíveis de origens da AWS.

**Topics**
+ [Restringe o acesso a uma origem do AWS Elemental MediaPackage v2.](private-content-restricting-access-to-mediapackage.md)
+ [Restringir o acesso a uma origem da AWS Elemental MediaStore](private-content-restricting-access-to-mediastore.md)
+ [Restringir o acesso a uma origem do URL de função do AWS Lambda](private-content-restricting-access-to-lambda.md)
+ [Restringir o acesso a uma origem do Amazon S3](private-content-restricting-access-to-s3.md)
+ [Restringe o acesso com origens de VPC.](private-content-vpc-origins.md)

# Restringe o acesso a uma origem do AWS Elemental MediaPackage v2.
<a name="private-content-restricting-access-to-mediapackage"></a>

O CloudFront fornece *controle de acesso à origem* (OAC) para restringir o acesso a uma origem do MediaPackage v2.

**nota**  
O OAC do CloudFront só é compatível com o MediaPackage v2. O MediaPackage v1 não é compatível.

**Topics**
+ [Criar um novo OAC](#create-oac-overview-mediapackage)
+ [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-mediapackage)

## Criar um novo OAC
<a name="create-oac-overview-mediapackage"></a>

Conclua as etapas descritas nos tópicos a seguir para configurar um novo OAC no CloudFront.

**Topics**
+ [Pré-requisitos](#oac-prerequisites-mediapackage)
+ [Conceder permissão ao CloudFront para acessar a origem do MediaPackage v2](#oac-permission-to-access-mediapackage)
+ [Criar o OAC](#create-oac-mediapackage)

### Pré-requisitos
<a name="oac-prerequisites-mediapackage"></a>

Antes de criar e configurar o controle de acesso à origem, você deve ter uma distribuição do CloudFront com uma origem do MediaPackage v2. Para obter mais informações, consulte [Usar um contêiner do MediaStore ou um canal do MediaPackage](DownloadDistS3AndCustomOrigins.md#concept_AWS_Media).

### Conceder permissão ao CloudFront para acessar a origem do MediaPackage v2
<a name="oac-permission-to-access-mediapackage"></a>

Antes de criar um controle de acesso à origem ou configurá-lo em uma distribuição do CloudFront, este deve ter permissão para acessar a origem do MediaPackage v2. Faça isso depois de criar uma distribuição do CloudFront, mas antes de adicionar o OAC à origem do MediaPackage v2 na configuração de distribuição.

Use uma política do IAM para permitir que a entidade principal do serviço do CloudFront (`cloudfront.amazonaws.com`) acesse a origem. O elemento `Condition` na política permite que o CloudFront acesse a origem do MediaPackage v2 *somente* quando a solicitação for em nome da distribuição do CloudFront que contém a origem do MediaPackage v2. Essa é a distribuição com a origem do MediaPackage v2 à qual você deseja adicionar o OAC.

**Example : política do IAM que permite acesso somente leitura a uma distribuição do CloudFront com OAC habilitado**  
A política a seguir permite que a distribuição do CloudFront (`E1PDK09ESKHJWT`) acesse a origem do MediaPackage v2. A origem é o ARN especificado para o elemento `Resource`.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {"Service": "cloudfront.amazonaws.com"},
            "Action": "mediapackagev2:GetObject",
            "Resource": "arn:aws:mediapackagev2:us-east-1:123456789012:channelGroup/channel-group-name/channel/channel-name/originEndpoint/origin_endpoint_name",
            "Condition": {
                "StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT"}
            }
        }
    ]
}
```

**Observações**  
Se você habilitou o recurso MQAR e o controle de acesso à origem (OAC), adicione a ação `mediapackagev2:GetHeadObject` à política do IAM. O MQAR requer essa permissão para enviar solicitações `HEAD` à origem do MediaPackage v2. Para ter mais informações sobre o MQAR, consulte [Resiliência com Reconhecimento de Qualidade da Mídia](media-quality-score.md).
Se você criar uma distribuição que não tenha permissão para sua origem do MediaPackage v2, é possível escolher **Copy policy** (Copiar política) no console do CloudFront e, depois, escolher **Update endpoint permissions** (Atualizar permissões de endpoint). Em seguida, é possível anexar a permissão copiada ao endpoint. Para ter mais informações, consulte [Endpoint policy fields](https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-policy.html) (Campos de política de endpoint) no *Guia do usuário do AWS Elemental MediaPackage*. 

### Criar o OAC
<a name="create-oac-mediapackage"></a>

Para criar um OAC, é possível usar o Console de gerenciamento da AWS, o CloudFormation, a AWS CLI ou a API do CloudFront.

------
#### [ Console ]

**Para criar um OAC**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, selecione **Origem access** (Acesso à origem).

1. Selecione **Create control setting** (Criar configuração de controle).

1. No formulário **Create new OAC** (Criar novo OAC), faça o seguinte:

   1. Informe um **Name** (Nome) e (opcionalmente) uma **Description** (Descrição) para o OAC.

   1. Em **Signing behavior** (Comportamento de assinatura), recomendamos que deixe a configuração padrão (**Sign requests (recommended)** [Solicitações de assinatura (recomendado)]. Para obter mais informações, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-mediapackage).

1. Em **Origin type** (Tipo de origem), selecione **MediaPackage v2**. 

1. Escolha **Criar**.
**dica**  
Depois que criar OAC, anote o **Name** (Nome). Você precisará dele no procedimento a seguir.

**Como adicionar um OAC a uma origem do MediaPackage v2 em uma distribuição**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha uma distribuição com uma origem do MediaPackage v2 à qual você deseja adicionar o OAC e, depois, selecione a guia **Origins** (Origens).

1. Selecione a origem do MediaPackage v2 à qual você deseja adicionar o OAC e, depois, **Edit** (Editar).

1. Selecione **HTTPS only** (Somente HTTPS) para o **Protocol** (Protocolo) de sua origem.

1. No menu suspenso **Origin access control** (Controle de acesso à origem), selecione o nome do OAC que você deseja usar.

1. Escolha **Salvar alterações**.

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas à origem do MediaPackage v2.

------
#### [ CloudFormation ]

Para criar um OAC com o CloudFormation, use o tipo de recurso `AWS::CloudFront::OriginAccessControl`. O exemplo a seguir mostra a sintaxe do modelo CloudFormation no formato YAML, para criar um OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediapackagev2
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obter mais informações, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) no *Guia do usuário do AWS CloudFormation*.

------
#### [ CLI ]

Para criar um controle de acesso à origem com a AWS Command Line Interface (AWS CLI), use o comando **aws cloudfront create-origin-access-control**. É possível usar um arquivo de entrada para fornecer os parâmetros de entrada do comando, em vez de especificar cada parâmetro individual como entrada na linha de comando.

**Como criar um controle de acesso à origem (CLI com arquivo de entrada)**

1. Use o comando a seguir para criar um arquivo chamado `origin-access-control.yaml`. Esse arquivo contém todos os parâmetros de entrada para o comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra o arquivo `origin-access-control.yaml` que você acabou de criar. Edite o arquivo para adicionar um nome para o OAC, uma descrição (opcional) e alterar `SigningBehavior` para `always`. Salve o arquivo.

   Para obter mais informações sobre outras configurações de OAC, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-mediapackage).

1. Use o comando a seguir para criar o controle de acesso à origem usando parâmetros de entrada do arquivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote o valor do `Id` na saída do comando. Você precisa dele para adicionar o OAC a uma origem do MediaPackage v2 em uma distribuição do CloudFront.

**Como anexar um OAC a uma origem do MediaPackage v2 em uma distribuição existente (CLI com arquivo de entrada)**

1. Use o comando a seguir para salvar a configuração da distribuição do CloudFront à qual você deseja adicionar o OAC. A distribuição deve ter uma origem do MediaPackage v2.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra o arquivo chamado `dist-config.yaml` que você acabou de criar. Edite o arquivo fazendo as seguintes alterações:
   + No objeto `Origins`, adicione o ID do OAC ao campo chamado `OriginAccessControlId`.
   + Remova o valor do campo chamado `OriginAccessIdentity`, se houver.
   + Renomeie o campo `ETag` para `IfMatch`, mas não altere o valor do campo.

   Ao concluir, salve o arquivo.

1. Use o comando a seguir para atualizar a distribuição para usar o controle de acesso à origem.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas à origem do MediaPackage v2.

------
#### [ API ]

Para criar um OAC com a API do CloudFront, use [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obter mais informações sobre os campos especificados nessa chamada de API, consulte a documentação de referência de API do seu AWS SDK ou de outro cliente de API.

Assim que criar um controle de acesso à origem, é possível anexá-lo a uma origem do MediaPackage v2 em uma distribuição usando uma das seguintes chamadas de API:
+ Para anexá-lo a uma distribuição existente, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para anexá-lo a uma nova distribuição, use [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para as duas chamadas de API, forneça o ID de OAC no campo `OriginAccessControlId`, dentro de uma origem. Para mais informações sobre os outros campos especificados nessas chamadas de API, consulte [Referência de configurações de todas as distribuições](distribution-web-values-specify.md) e a documentação de referência da API do AWS SDK ou de outro cliente de API.

------

## Configurações avançadas para controle de acesso à origem
<a name="oac-advanced-settings-mediapackage"></a>

O atributo de OAC do CloudFront inclui configurações avançadas destinadas somente a casos de uso específicos. Use as configurações recomendadas, a menos que você precise usar as configurações avançadas para uma necessidade específica.

O OAC contém uma configuração chamada **Signing behavior** (Comportamento de assinatura) (no console) ou `SigningBehavior` (na API, na CLI e no CloudFormation). Essa configuração fornece as seguintes opções:

**Always sign origin requests (recommended setting) [Sempre assinar solicitações de origem (configuração recomendada)]**  
Recomendamos usar essa configuração, chamada **Sign requests (recommended)** [Assinar solicitações (recomendado)] no console, ou `always` na API, na CLI e no CloudFormation. Com essa configuração, o CloudFront sempre assina todas as solicitações enviadas à origem do MediaPackage v2.

**Never sign origin requests (Nunca assinar solicitações de origem)**  
Essa configuração é chamada **Do not sign requests** (Não assinar solicitações) no console ou `never` na API, na CLI e no CloudFormation. Use essa configuração para desativar o OAC para todas as origens em todas as distribuições que usam esse OAC. Isso pode economizar tempo e esforço em comparação com a remoção individual de um OAC de todas as origens e distribuições que o usam. Com essa configuração, o CloudFront não assina nenhuma solicitação enviada à origem do MediaPackage v2.  
Para usar essa configuração, a origem do MediaPackage v2 deve estar acessível de forma pública. Se você usar essa configuração com uma origem do MediaPackage v2 que não esteja acessível de forma pública, o CloudFront não poderá acessar a origem. A origem do MediaPackage v2 retorna erros ao CloudFront e o CloudFront transmite esses erros aos visualizadores. Para ter mais informações, consulte o exemplo de política do MediaPackage v2 para [Políticas e permissões no MediaPackage](https://docs.aws.amazon.com/mediapackage/latest/userguide/policies-permissions.html) no *Guia do usuário do AWS Elemental MediaPackage*.

**Não substituir o cabeçalho `Authorization` do visualizador (cliente)**  
Essa configuração é chamada **Do not override authorization header** (Não substituir o cabeçalho de autorização) no console ou `no-override` na API, na CLI e no CloudFormation. Use essa configuração quando quiser que o CloudFront assine solicitações de origem somente quando a solicitação do visualizador correspondente não incluir um cabeçalho `Authorization`. Com essa configuração, o CloudFront transmite o cabeçalho `Authorization` da solicitação do visualizador quando houver, mas assina a solicitação de origem (adicionando seu próprio cabeçalho `Authorization`) quando a solicitação do visualizador não inclui um cabeçalho `Authorization`.  
Para transmitir o cabeçalho `Authorization` da solicitação do visualizador, você *deve* adicionar o cabeçalho `Authorization` a uma [política de cache](controlling-the-cache-key.md) para todos os comportamentos de cache que usam origens do MediaPackage v2 associadas a esse controle de acesso à origem.

# Restringir o acesso a uma origem da AWS Elemental MediaStore
<a name="private-content-restricting-access-to-mediastore"></a>

O CloudFront fornece *controle de acesso à origem* (OAC) para restringir o acesso a uma origem do AWS Elemental MediaStore.

**Topics**
+ [Criar um controle de acesso à origem](#create-oac-overview-mediastore)
+ [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-mediastore)

## Criar um controle de acesso à origem
<a name="create-oac-overview-mediastore"></a>

Conclua as etapas descritas nos tópicos a seguir para configurar um novo controle de acesso à origem no CloudFront.

**Topics**
+ [Pré-requisitos](#oac-prerequisites-mediastore)
+ [Conceder permissão ao CloudFront para acessar a origem do MediaStore](#oac-permission-to-access-mediastore)
+ [Criar o controle de acesso à origem](#create-oac-mediastore)

### Pré-requisitos
<a name="oac-prerequisites-mediastore"></a>

Antes de criar e configurar o controle de acesso à origem, você deve ter uma distribuição do CloudFront com uma origem do MediaStore. 

### Conceder permissão ao CloudFront para acessar a origem do MediaStore
<a name="oac-permission-to-access-mediastore"></a>

Antes de criar um controle de acesso à origem ou configurá-lo em uma distribuição do CloudFront, este deve ter permissão para acessar a origem do MediaStore. Faça isso depois de criar uma distribuição do CloudFront, mas antes de adicionar o OAC à origem do MediaStore na configuração de distribuição. 

Use uma política de contêiner do MediaStore para permitir que a entidade principal do serviço do CloudFront (`cloudfront.amazonaws.com`) acesse a origem. Use um elemento `Condition` na política para permitir que o CloudFront acesse o contêiner do MediaStore somente quando a solicitação for em nome da distribuição do CloudFront que contém a origem do MediaStore. Essa é a distribuição com a origem do MediaStore à qual você deseja adicionar o OAC.

Veja a seguir exemplos de políticas de contêiner do MediaStore que permitem que uma distribuição do CloudFront acesse uma origem do MediaStore.

**Example Política de contêiner do MediaStore que permite acesso somente leitura a uma distribuição do CloudFront com OAC habilitado**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadOnly",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/<container name>/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**Example Política de contêiner do MediaStore que permite acesso de leitura e gravação a uma distribuição do CloudFront com OAC habilitado**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadWrite",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject",
                  "mediastore:PutObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/container-name/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**nota**  
Para permitir o acesso de gravação, você deve configurar **Allowed HTTP methods** (Métodos HTTP permitidos) para incluir`PUT` nas configurações de comportamento de sua distribuição do CloudFront.

### Criar o controle de acesso à origem
<a name="create-oac-mediastore"></a>

Para criar um OAC, você pode usar o Console de gerenciamento da AWS, o CloudFormation, a AWS CLI ou a API do CloudFront.

------
#### [ Console ]

**Como criar um controle de acesso à origem**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, selecione **Origem access** (Acesso à origem).

1. Selecione **Create control setting** (Criar configuração de controle).

1. No formulário **Create control setting** (Criar configuração de controle), faça o seguinte:

   1. No painel **Details** (Detalhes), insira um **Name** (Nome) e (opcionalmente) uma **Description** (Descrição) para o controle de acesso à origem.

   1. No painel **Settings** (Configurações), recomendamos que você deixe a configuração padrão (**Sign requests (recommended)** [Solicitações de assinatura (recomendado)]. Para obter mais informações, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-mediastore).

1. Selecione MediaStore no menu suspenso **Origin type** (Tipo de origem).

1. Escolha **Criar**.

   Depois que o OAC for criado, anote o **Name** (Nome). Você precisará dele no procedimento a seguir.

**Como adicionar um controle de acesso à origem a uma origem do MediaStore em uma distribuição**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha uma distribuição com uma origem do MediaStore à qual você deseja adicionar o OAC e, depois, selecione a guia **Origins** (Origens).

1. Selecione a origem do MediaStore à qual você deseja adicionar o OAC e, depois, **Edit** (Editar).

1. Selecione **HTTPS only** (Somente HTTPS) para o **Protocol** (Protocolo) de sua origem.

1. No menu suspenso **Origin access control** (Controle de acesso à origem), selecione o OAC que você deseja usar.

1. Escolha **Salvar alterações**.

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas à origem de bucket do MediaStore.

------
#### [ CloudFormation ]

Para criar um controle de acesso à origem (OAC) com o CloudFormation, use o tipo de recurso `AWS::CloudFront::OriginAccessControl`. O exemplo a seguir mostra a sintaxe do modelo CloudFormation no formato YAML, para criar um controle de acesso à origem.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediastore
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obter mais informações, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) no *Guia do usuário do AWS CloudFormation*.

------
#### [ CLI ]

Para criar um controle de acesso à origem com a AWS Command Line Interface (AWS CLI), use o comando **aws cloudfront create-origin-access-control**. É possível usar um arquivo de entrada para fornecer os parâmetros de entrada do comando, em vez de especificar cada parâmetro individual como entrada na linha de comando.

**Como criar um controle de acesso à origem (CLI com arquivo de entrada)**

1. Use o comando a seguir para criar um arquivo chamado `origin-access-control.yaml`. Esse arquivo contém todos os parâmetros de entrada para o comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra o arquivo `origin-access-control.yaml` que você acabou de criar. Edite o arquivo para adicionar um nome para o OAC, uma descrição (opcional) e alterar `SigningBehavior` para `always`. Salve o arquivo.

   Para obter mais informações sobre outras configurações de OAC, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-mediastore).

1. Use o comando a seguir para criar o controle de acesso à origem usando parâmetros de entrada do arquivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote o valor do `Id` na saída do comando. Você precisa dele para adicionar o OAC a uma origem do MediaStore em uma distribuição do CloudFront.

**Como anexar um OAC a uma origem do MediaStore em uma distribuição existente (CLI com arquivo de entrada)**

1. Use o comando a seguir para salvar a configuração da distribuição do CloudFront à qual você deseja adicionar o OAC. A distribuição deve ter uma origem do MediaStore.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra o arquivo chamado `dist-config.yaml` que você acabou de criar. Edite o arquivo fazendo as seguintes alterações:
   + No objeto `Origins`, adicione o ID do OAC ao campo chamado `OriginAccessControlId`.
   + Remova o valor do campo chamado `OriginAccessIdentity`, se houver.
   + Renomeie o campo `ETag` para `IfMatch`, mas não altere o valor do campo.

   Ao concluir, salve o arquivo.

1. Use o comando a seguir para atualizar a distribuição para usar o controle de acesso à origem.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas à origem do MediaStore.

------
#### [ API ]

Para criar um controle de acesso à origem com a API do CloudFront, use [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obter mais informações sobre os campos especificados nessa chamada de API, consulte a documentação de referência de API do seu AWS SDK ou de outro cliente de API.

Assim que criar um controle de acesso à origem, você pode anexá-lo a uma origem do MediaStore em uma distribuição usando uma das seguintes chamadas de API:
+ Para anexá-lo a uma distribuição existente, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para anexá-lo a uma nova distribuição, use [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para as duas chamadas de API, forneça o ID de controle de acesso à origem no campo `OriginAccessControlId`, dentro de uma origem. Para mais informações sobre os outros campos especificados nessas chamadas de API, consulte [Referência de configurações de todas as distribuições](distribution-web-values-specify.md) e a documentação de referência da API do AWS SDK ou de outro cliente de API.

------

## Configurações avançadas para controle de acesso à origem
<a name="oac-advanced-settings-mediastore"></a>

O recurso de controle de acesso à origem do CloudFront inclui configurações avançadas destinadas somente a casos de uso específicos. Use as configurações recomendadas, a menos que você precise usar as configurações avançadas para uma necessidade específica.

O controle de acesso à origem contém uma configuração chamada **Signing behavior** (Comportamento de assinatura) (no console) ou `SigningBehavior` (na API, na CLI e no CloudFormation). Essa configuração fornece as seguintes opções:

**Always sign origin requests (recommended setting) [Sempre assinar solicitações de origem (configuração recomendada)]**  
Recomendamos usar essa configuração, chamada **Sign requests (recommended)** [Assinar solicitações (recomendado)] no console, ou `always` na API, na CLI e no CloudFormation. Com essa configuração, o CloudFront sempre assina todas as solicitações enviadas à origem do MediaStore.

**Never sign origin requests (Nunca assinar solicitações de origem)**  
Essa configuração é chamada **Do not sign requests** (Não assinar solicitações) no console ou `never` na API, na CLI e no CloudFormation. Use essa configuração para desativar o controle de acesso à origem para todas as origens em todas as distribuições que usam esse controle. Isso pode economizar tempo e esforço em comparação com a remoção individual de um controle de acesso à origem de todas as origens e distribuições que o usam. Com essa configuração, o CloudFront não assina nenhuma solicitação enviada à origem do MediaStore.  
Para usar essa configuração, a origem do MediaStore deve estar acessível ao público. Se você usar essa configuração com uma origem do MediaStore que não esteja acessível ao público, o CloudFront não poderá acessar a origem. A origem do MediaStore retorna erros ao CloudFront e o CloudFront transmite esses erros aos visualizadores. Para ter mais informações, consulte o exemplo de política de contêiner do MediaStore para [acesso público de leitura por HTTPS](https://docs.aws.amazon.com/mediastore/latest/ug/policies-examples-public-https.html).

**Não substituir o cabeçalho `Authorization` do visualizador (cliente)**  
Essa configuração é chamada **Do not override authorization header** (Não substituir o cabeçalho de autorização) no console ou `no-override` na API, na CLI e no CloudFormation. Use essa configuração quando quiser que o CloudFront assine solicitações de origem somente quando a solicitação do visualizador correspondente não incluir um cabeçalho `Authorization`. Com essa configuração, o CloudFront transmite o cabeçalho `Authorization` da solicitação do visualizador quando houver, mas assina a solicitação de origem (adicionando seu próprio cabeçalho `Authorization`) quando a solicitação do visualizador não inclui um cabeçalho `Authorization`.  
Para transmitir o cabeçalho `Authorization` da solicitação do visualizador, você *deve* adicionar o cabeçalho `Authorization` a uma [política de cache](controlling-the-cache-key.md) para todos os comportamentos de cache que usam origens do MediaStore associadas a esse controle de acesso à origem.

# Restringir o acesso a uma origem do URL de função do AWS Lambda
<a name="private-content-restricting-access-to-lambda"></a>

O CloudFront fornece *controle de acesso à origem* (OAC) para restringir o acesso a uma origem do URL da função do Lambda.

**Topics**
+ [Criar um OAC](#create-oac-overview-lambda)
+ [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-lambda)
+ [Exemplo de código de modelo](#example-template-code-lambda-oac)

## Criar um OAC
<a name="create-oac-overview-lambda"></a>

Conclua as etapas descritas nos tópicos a seguir para configurar um novo OAC no CloudFront.

**Importante**  
Se você usar os métodos `PUT` ou `POST` com o URL da função do Lambda, os usuários deverão calcular o SHA256 do corpo e incluir o valor de hash da carga útil no cabeçalho `x-amz-content-sha256` ao enviar a solicitação ao CloudFront. O Lambda não é compatível com cargas úteis não conectadas.

**Topics**
+ [Pré-requisitos](#oac-prerequisites-lambda)
+ [Conceder permissão ao CloudFront para acessar o URL da função do Lambda](#oac-permission-to-access-lambda)
+ [Criar o OAC](#create-oac-lambda)

### Pré-requisitos
<a name="oac-prerequisites-lambda"></a>

Antes de criar e configurar o OAC, você deve ter uma distribuição do CloudFront com um URL da função do Lambda como origem. Para usar o OAC, você deve especificar o `AWS_IAM` como valor para o parâmetro `AuthType`. Para obter mais informações, consulte [Usar um URL da função do Lambda](DownloadDistS3AndCustomOrigins.md#concept_lambda_function_url).

### Conceder permissão ao CloudFront para acessar o URL da função do Lambda
<a name="oac-permission-to-access-lambda"></a>

Antes de criar um OAC ou configurá-lo em uma distribuição do CloudFront, este deve ter permissão para acessar o URL da função do Lambda. Faça isso depois de criar uma distribuição do CloudFront, mas antes de adicionar o OAC ao URL da função do Lambda na configuração de distribuição.

**nota**  
Para atualizar a política do IAM para o URL da função do Lambda, você deve usar o AWS Command Line Interface (AWS CLI). Não há suporte para a edição da política do IAM no console do Lambda, no momento.

O comando AWS CLI a seguir concede ao serviço de entidade principal (`cloudfront.amazonaws.com`) do CloudFront acesso ao URL da função do Lambda. O elemento `Condition` na política permite que o CloudFront acesse o Lambda *somente* quando a solicitação for em nome da distribuição do CloudFront que contém o URL da função do Lambda. Essa é a distribuição com a origem do URL da função do Lambda à qual você deseja adicionar o OAC.

**Example : comando da AWS CLI para atualizar uma política e permitir acesso somente leitura a uma distribuição do CloudFront com OAC habilitado**  
O comando da AWS CLI a seguir permite que a distribuição do CloudFront (`E1PDK09ESKHJWT`) acesse o *`FUNCTION_URL_NAME`* do Lambda.

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipal" \
--action "lambda:InvokeFunctionUrl" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipalInvokeFunction" \
--action "lambda:InvokeFunction" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

**nota**  
Se você criar uma distribuição e ela não tiver permissão para o URL da função do Lambda, é possível selecionar **Copy CLI command** (Copiar comando CLI) no console do CloudFront e, em seguida, inserir esse comando no seu terminal de linha de comando. Para ter mais informações, consulte [Conceder acesso de função aos Serviços da AWS](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) no *Guia do desenvolvedor do AWS Lambda*. 

### Criar o OAC
<a name="create-oac-lambda"></a>

Para criar um OAC, é possível usar o Console de gerenciamento da AWS, o CloudFormation, a AWS CLI ou a API do CloudFront.

------
#### [ Console ]

**Para criar um OAC**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, selecione **Origem access** (Acesso à origem).

1. Selecione **Create control setting** (Criar configuração de controle).

1. No formulário **Create new OAC** (Criar novo OAC), faça o seguinte:

   1. Informe um **Name** (Nome) e (opcionalmente) uma **Description** (Descrição) para o OAC.

   1. Em **Signing behavior** (Comportamento de assinatura), recomendamos que deixe a configuração padrão (**Sign requests (recommended)** [Solicitações de assinatura (recomendado)]. Para obter mais informações, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-lambda).

1. Em **Origin type** (Tipo de origem), selecione **Lambda**. 

1. Escolha **Criar**.
**dica**  
Depois que criar OAC, anote o **Name** (Nome). Você precisará dele no procedimento a seguir.

**Como adicionar um controle de acesso à origem a um URL da função do Lambda em uma distribuição**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha uma distribuição com um URL da função do Lambda ao qual você deseja adicionar o OAC e, depois, selecione a guia **Origins** (Origens).

1. Selecione o URL da função do Lambda ao qual você deseja adicionar o OAC e, depois, **Edit** (Editar).

1. Selecione **HTTPS only** (Somente HTTPS) para o **Protocol** (Protocolo) de sua origem.

1. No menu suspenso **Origin access control** (Controle de acesso à origem), selecione o nome do OAC que você deseja usar.

1. Escolha **Salvar alterações**.

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas ao URL da função do Lambda.

------
#### [ CloudFormation ]

Para criar um OAC com o CloudFormation, use o tipo de recurso `AWS::CloudFront::OriginAccessControl`. O exemplo a seguir mostra a sintaxe do modelo CloudFormation no formato YAML, para criar um OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: lambda
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obter mais informações, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) no *Guia do usuário do AWS CloudFormation*.

------
#### [ CLI ]

Para criar um controle de acesso à origem com a AWS Command Line Interface (AWS CLI), use o comando **aws cloudfront create-origin-access-control**. É possível usar um arquivo de entrada para fornecer os parâmetros de entrada do comando, em vez de especificar cada parâmetro individual como entrada na linha de comando.

**Como criar um controle de acesso à origem (CLI com arquivo de entrada)**

1. Use o comando a seguir para criar um arquivo chamado `origin-access-control.yaml`. Esse arquivo contém todos os parâmetros de entrada para o comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra o arquivo `origin-access-control.yaml` que você acabou de criar. Edite o arquivo para adicionar um nome para o OAC, uma descrição (opcional) e alterar `SigningBehavior` para `always`. Salve o arquivo.

   Para obter mais informações sobre outras configurações de OAC, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-lambda).

1. Use o comando a seguir para criar o controle de acesso à origem usando parâmetros de entrada do arquivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote o valor do `Id` na saída do comando. Você precisa dele para adicionar o OAC a um URL da função do Lambda em uma distribuição do CloudFront.

**Como anexar um OAC a um URL da função do Lambda em uma distribuição existente (CLI com arquivo de entrada)**

1. Use o comando a seguir para salvar a configuração da distribuição do CloudFront à qual você deseja adicionar o OAC. A distribuição deve ter um URL da função do Lambda como origem.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra o arquivo chamado `dist-config.yaml` que você acabou de criar. Edite o arquivo fazendo as seguintes alterações:
   + No objeto `Origins`, adicione o ID do OAC ao campo chamado `OriginAccessControlId`.
   + Remova o valor do campo chamado `OriginAccessIdentity`, se houver.
   + Renomeie o campo `ETag` para `IfMatch`, mas não altere o valor do campo.

   Ao concluir, salve o arquivo.

1. Use o comando a seguir para atualizar a distribuição para usar o controle de acesso à origem.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas ao URL da função do Lambda.

------
#### [ API ]

Para criar um OAC com a API do CloudFront, use [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obter mais informações sobre os campos especificados nessa chamada de API, consulte a documentação de referência de API do seu AWS SDK ou de outro cliente de API.

Assim que criar um controle de acesso à origem, é possível anexá-lo a um URL da função do Lambda em uma distribuição usando uma das seguintes chamadas de API:
+ Para anexá-lo a uma distribuição existente, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para anexá-lo a uma nova distribuição, use [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para as duas chamadas de API, forneça o ID de OAC no campo `OriginAccessControlId`, dentro de uma origem. Para ter mais informações sobre os outros campos especificados nessas chamadas de API, consulte a documentação de referência da API do SDK ou de outro cliente de API da AWS.

------

## Configurações avançadas para controle de acesso à origem
<a name="oac-advanced-settings-lambda"></a>

O atributo de OAC do CloudFront inclui configurações avançadas destinadas somente a casos de uso específicos. Use as configurações recomendadas, a menos que você precise usar as configurações avançadas para uma necessidade específica.

O OAC contém uma configuração chamada **Signing behavior** (Comportamento de assinatura) (no console) ou `SigningBehavior` (na API, na CLI e no CloudFormation). Essa configuração fornece as seguintes opções:

**Always sign origin requests (recommended setting) [Sempre assinar solicitações de origem (configuração recomendada)]**  
Recomendamos usar essa configuração, chamada **Sign requests (recommended)** [Assinar solicitações (recomendado)] no console, ou `always` na API, na CLI e no CloudFormation. Com essa configuração, o CloudFront sempre assina todas as solicitações enviadas ao URL da função do Lambda.

**Never sign origin requests (Nunca assinar solicitações de origem)**  
Essa configuração é chamada **Do not sign requests** (Não assinar solicitações) no console ou `never` na API, na CLI e no CloudFormation. Use essa configuração para desativar o OAC para todas as origens em todas as distribuições que usam esse OAC. Isso pode economizar tempo e esforço em comparação com a remoção individual de um OAC de todas as origens e distribuições que o usam. Com essa configuração, o CloudFront não assina nenhuma solicitação enviada ao URL da função do Lambda.  
Para usar essa configuração, o URL da função do Lambda deve estar acessível de forma pública. Se você usar essa configuração com um URL da função do Lambda que não esteja acessível de forma pública, o CloudFront não poderá acessar a origem. A origem do URL da função do Lambda retorna erros ao CloudFront e o CloudFront transmite esses erros aos visualizadores. Para ter mais informações, consulte [Modelo de segurança e autenticação para URLs de função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) no *Guia do usuário do AWS Lambda*.

**Não substituir o cabeçalho `Authorization` do visualizador (cliente)**  
Essa configuração é chamada **Do not override authorization header** (Não substituir o cabeçalho de autorização) no console ou `no-override` na API, na CLI e no CloudFormation. Use essa configuração quando quiser que o CloudFront assine solicitações de origem somente quando a solicitação do visualizador correspondente não incluir um cabeçalho `Authorization`. Com essa configuração, o CloudFront transmite o cabeçalho `Authorization` da solicitação do visualizador quando houver, mas assina a solicitação de origem (adicionando seu próprio cabeçalho `Authorization`) quando a solicitação do visualizador não inclui um cabeçalho `Authorization`.  
+ Se usar essa configuração, você deverá especificar a assinatura do Signature versão 4 para o URL da função do Lambda em vez do nome ou CNAME da distribuição do CloudFront. Quando o CloudFront encaminha o cabeçalho `Authorization` da solicitação do visualizador para o URL da função do Lambda, o Lambda valida a assinatura em relação ao host do domínio de URL do Lambda. Se a assinatura não for baseada no domínio de URL do Lambda, o host na assinatura não corresponderá ao host usado pela origem do URL do Lambda. Isso significa que a solicitação falhará, ocasionando um erro de validação da assinatura.
+ Para transmitir o cabeçalho de `Authorization` da solicitação do visualizador, você *deve* adicionar o cabeçalho de `Authorization` a uma [política de cache](controlling-the-cache-key.md) para todos os comportamentos de cache que usam URLs da função do Lambda associados a esse controle de acesso à origem.

## Exemplo de código de modelo
<a name="example-template-code-lambda-oac"></a>

Se a origem do CloudFront for um URL da função do Lambda associado a um OAC, você poderá usar o script do Python a seguir para carregar arquivos na função do Lambda com o método `POST`. 

Esse código pressupõe que você configurou o OAC com o comportamento de assinatura padrão definido como **Sempre assinar solicitações para a origem** e que você não selecionou a configuração **Não substituir o cabeçalho de autorização**.

Essa configuração permite que o OAC gerencie a autorização SigV4 corretamente com o Lambda usando o nome de host do Lambda. A carga útil é assinada usando SigV4 da identidade do IAM autorizada para o URL da função do Lambda, que é designada como o tipo `IAM_AUTH`. 

O modelo demonstra como lidar com valores de hash de carga útil assinados no cabeçalho x-amz-content-sha256 para solicitações `POST` do lado do cliente. Esse modelo foi projetado especificamente para gerenciar cargas úteis de dados de formulário. Ele permite o upload seguro de arquivos para um URL da função do Lambda por meio do CloudFront e usa mecanismos de autenticação da AWS para garantir que somente solicitações autorizadas acessem a função do Lambda.

**O código inclui as seguintes funcionalidades:**  
Atende ao requisito de incluir o hash da carga útil no cabeçalho x-amz-content-sha256.
Usa a autenticação SigV4 para acesso seguro ao AWS service (Serviço da AWS).
Permite uploads de arquivos usando dados de formulário de várias partes.
Inclui tratamento de erros para exceções de solicitação.

```
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests
import hashlib
import os


def calculate_body_hash(body):
    return hashlib.sha256(body).hexdigest()


def sign_request(request, credentials, region, service):
    sigv4 = SigV4Auth(credentials, service, region)
    sigv4.add_auth(request)


def upload_file_to_lambda(cloudfront_url, file_path, region):
    # AWS credentials
    session = boto3.Session()
    credentials = session.get_credentials()

    # Prepare the multipart form-data
    boundary = "------------------------boundary"

    # Read file content
    with open(file_path, 'rb') as file:
        file_content = file.read()

    # Get the filename from the path
    filename = os.path.basename(file_path)

    # Prepare the multipart body
    body = (
        f'--{boundary}\r\n'
        f'Content-Disposition: form-data; name="file"; filename="{filename}"\r\n'
        f'Content-Type: application/octet-stream\r\n\r\n'
    ).encode('utf-8')
    body += file_content
    body += f'\r\n--{boundary}--\r\n'.encode('utf-8')

    # Calculate SHA256 hash of the entire body
    body_hash = calculate_body_hash(body)

    # Prepare headers
    headers = {
        'Content-Type': f'multipart/form-data; boundary={boundary}',
        'x-amz-content-sha256': body_hash
    }

    # Create the request
    request = AWSRequest(
        method='POST',
        url=cloudfront_url,
        data=body,
        headers=headers
    )

    # Sign the request
    sign_request(request, credentials, region, 'lambda')

    # Get the signed headers
    signed_headers = dict(request.headers)

    # Print request headers before sending
    print("Request Headers:")
    for header, value in signed_headers.items():
        print(f"{header}: {value}")

    try:
        # Send POST request with signed headers
        response = requests.post(
            cloudfront_url,
            data=body,
            headers=signed_headers
        )

        # Print response status and content
        print(f"\nStatus code: {response.status_code}")
        print("Response:", response.text)

        # Print response headers
        print("\nResponse Headers:")
        for header, value in response.headers.items():
            print(f"{header}: {value}")

    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")


# Usage
cloudfront_url = "https://d111111abcdef8.cloudfront.net"
file_path = r"filepath"
region = "us-east-1"  # example: "us-west-2"

upload_file_to_lambda(cloudfront_url, file_path, region)
```

# Restringir o acesso a uma origem do Amazon S3
<a name="private-content-restricting-access-to-s3"></a>

O CloudFront fornece duas maneiras para enviar solicitações autenticadas a uma origem do Amazon S3: *controle de acesso à origem* (OAC) e *identidade do acesso de origem* (OAI). O OAC ajuda a proteger suas origens, assim como no Amazon S3. 

*Recomendamos* que você use o OAC em vez disso, pois é possível usá-lo com os seguintes recursos:
+ Todos os buckets do Amazon S3 em todas as Regiões da AWS; por exemplo, regiões opcionais lançadas após dezembro de 2022.
+ [Criptografia do lado do servidor com o AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS) do Amazon S3
+ Solicitações dinâmicas (`PUT` e `DELETE`) para o Amazon S3

A OAI não é compatível com esses recursos ou requer outras soluções alternativas nesses cenários. Se você já estiver usando a OAI e quiser migrar, consulte [Migrar da identidade do acesso de origem (OAI) para o controle de acesso à origem (OAC)](#migrate-from-oai-to-oac).

**Observações**  
Ao usar o CloudFront OAC com origens de bucket do Amazon S3, você deve definir a **Propriedade de objeto do Amazon S3** como **Proprietário do bucket aplicado**, o padrão para novos buckets do Amazon S3. Se você precisar de ACLs, use a configuração **Proprietário do bucket preferido** para manter o controle sobre os objetos enviados via CloudFront.
Se usar um bucket do Amazon S3 configurado como um [endpoint de site](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html), você deverá configurá-lo com o CloudFront como uma origem personalizada. Isso significa que você não pode usar o OAC (nem a OAI). O OAC não é compatível com o redirecionamento de origem usando o Lambda@Edge.

Os tópicos a seguir descrevem como usar o OAC com uma origem do Amazon S3. 

**Tópicos**
+ [Criar um controle de acesso à origem](#create-oac-overview-s3)
+ [Excluir uma distribuição com um OAC anexado a um bucket do S3](#delete-oac-distribution-s3)
+ [Migrar da identidade do acesso de origem (OAI) para o controle de acesso à origem (OAC)](#migrate-from-oai-to-oac)
+ [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-s3)

## Criar um controle de acesso à origem
<a name="create-oac-overview-s3"></a>

Conclua as etapas descritas nos tópicos a seguir para configurar um novo controle de acesso à origem no CloudFront.

**Topics**
+ [Pré-requisitos](#oac-prerequisites-s3)
+ [Conceder permissão ao CloudFront para acessar o bucket do S3](#oac-permission-to-access-s3)
+ [Criar o controle de acesso à origem](#create-oac-s3)

### Pré-requisitos
<a name="oac-prerequisites-s3"></a>

Antes de criar e configurar o controle de acesso à origem (OAC), você deve ter uma distribuição do CloudFront com uma origem de bucket do Amazon S3. Essa origem deve ser um bucket normal do S3, não um bucket configurado como [endpoint de site](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html). Para obter mais informações sobre como configurar uma distribuição do CloudFront com uma origem de bucket do S3, consulte [Conceitos básicos de uma distribuição padrão do CloudFront](GettingStarted.SimpleDistribution.md).

**Importante**  
Ao usar o OAC para proteger a origem do Amazon S3, a comunicação entre o CloudFront e o Amazon S3 é *sempre* por meio de HTTPS, mas somente quando você escolhe *sempre assinar solicitações*. Você deve escolher **Assinar solicitações (recomendado)** no console ou especificar `always` na API do CloudFront, na AWS CLI ou no CloudFormation.   
Se você escolher a opção **Não assinar solicitações** ou **Não substituir o cabeçalho de autorização**, o CloudFront usará o protocolo de conexão que você especificou nas seguintes políticas:  
[Política de protocolo do visualizador](using-https-viewers-to-cloudfront.md) 
[Política de protocolo da origem](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) (somente origens personalizadas)
Por exemplo, se você escolher **Não substituir o cabeçalho de autorização** e quiser usar HTTPS entre o CloudFront e a origem do Amazon S3, use **Redirecionar HTTP para HTTPS** ou **Somente HTTPS** para a [política de protocolo do visualizador](using-https-viewers-to-cloudfront.md).

### Conceder permissão ao CloudFront para acessar o bucket do S3
<a name="oac-permission-to-access-s3"></a>

Antes de criar um controle de acesso à origem (OAC) ou configurá-lo em uma distribuição do CloudFront, verifique se o CloudFront tem permissão para acessar a origem do bucket do S3. Faça isso depois de criar uma distribuição do CloudFront, mas antes de adicionar o OAC à origem do S3 na configuração de distribuição.

Use uma [política de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) do S3 para permitir que a entidade principal do serviço do CloudFront (`cloudfront.amazonaws.com`) acesse o bucket. Use um elemento `Condition` na política para permitir que o CloudFront acesse o bucket somente quando a solicitação for em nome da distribuição do CloudFront que contém a origem do S3. Essa é a distribuição com a origem do S3 à qual você deseja adicionar o OAC.

Para obter informações sobre como adicionar ou modificar uma política de bucket, consulte [Adicionar uma política de bucket usando o console do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) no *Guia do usuário do Amazon S3*.

Veja a seguir exemplos de política de bucket do S3 que permitem que uma distribuição do CloudFront com OAC habilitado acesse uma origem do S3.

**Example Política de bucket do S3 que permite acesso somente leitura a uma distribuição do CloudFront com OAC habilitado**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
        }
      }
    }
  ]
}
```

**Example Política de bucket do S3 que permite acesso de leitura e gravação a uma distribuição do CloudFront com OAC habilitado**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID>"
        }
      }
    }
  ]
}
```

#### SSE-KMS
<a name="oac-permissions-sse-kms"></a>

Se os objetos na origem do bucket do S3 forem criptografados usando [criptografia do lado do servidor com o AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), a distribuição do CloudFront deverá ter permissão para usar a chave do AWS KMS. Para conceder permissão a uma distribuição do CloudFront para usar a chave do KMS, adicione uma instrução à [política de chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). Para obter informações sobre como modificar uma política de chaves, consulte [Alterar uma política de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) no *Guia do desenvolvedor do AWS Key Management Service*.

**Example Declaração de política de chaves do KMS**  
O exemplo a seguir mostra uma instrução de política do AWS KMS que permite que a distribuição do CloudFront com OAC acesse uma chave KMS para SSE-KMS.  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
}
```

### Criar o controle de acesso à origem
<a name="create-oac-s3"></a>

Para criar um controle de acesso à origem (OAC), você pode usar o Console de gerenciamento da AWS, o CloudFormation, a AWS CLI ou a API do CloudFront.

------
#### [ Console ]

**Como criar um controle de acesso à origem**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, selecione **Origem access** (Acesso à origem).

1. Selecione **Create control setting** (Criar configuração de controle).

1. No formulário **Create control setting** (Criar configuração de controle), faça o seguinte:

   1. No painel **Details** (Detalhes), insira um **Name** (Nome) e (opcionalmente) uma **Description** (Descrição) para o controle de acesso à origem.

   1. No painel **Settings** (Configurações), recomendamos que você deixe a configuração padrão (**Sign requests (recommended)** [Solicitações de assinatura (recomendado)]. Para obter mais informações, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-s3).

1. Selecione S3 no menu suspenso **Origin type** (Tipo de origem).

1. Escolha **Criar**.

   Depois que o OAC for criado, anote o **Name** (Nome). Você precisará dele no procedimento a seguir.

**Como adicionar um controle de acesso à origem a uma origem do S3 em uma distribuição**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha uma distribuição com uma origem do S3 à qual você deseja adicionar o OAC e, depois, selecione a guia **Origins** (Origens).

1. Selecione a origem do S3 à qual você deseja adicionar o OAC e, depois, **Edit** (Editar).

1. Em **Origin access** (Acesso à origem), selecione **Origin access control settings (recommended)** (Configurações de controle de acesso à origem [recomendado]).

1. No menu suspenso **Origin access control** (Controle de acesso à origem), selecione o OAC que você deseja usar.

1. Escolha **Salvar alterações**.

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas à origem do bucket do S3.

------
#### [ CloudFormation ]

Para criar um controle de acesso à origem (OAC) com o CloudFormation, use o tipo de recurso `AWS::CloudFront::OriginAccessControl`. O exemplo a seguir mostra a sintaxe do modelo CloudFormation no formato YAML, para criar um controle de acesso à origem.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4
```

Para obter mais informações, consulte [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) no *Guia do usuário do AWS CloudFormation*.

------
#### [ CLI ]

Para criar um controle de acesso à origem com a AWS Command Line Interface (AWS CLI), use o comando **aws cloudfront create-origin-access-control**. É possível usar um arquivo de entrada para fornecer os parâmetros de entrada do comando, em vez de especificar cada parâmetro individual como entrada na linha de comando.

**Como criar um controle de acesso à origem (CLI com arquivo de entrada)**

1. Use o comando a seguir para criar um arquivo chamado `origin-access-control.yaml`. Esse arquivo contém todos os parâmetros de entrada para o comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Abra o arquivo `origin-access-control.yaml` que você acabou de criar. Edite o arquivo para adicionar um nome para o OAC, uma descrição (opcional) e alterar `SigningBehavior` para `always`. Salve o arquivo.

   Para obter mais informações sobre outras configurações de OAC, consulte [Configurações avançadas para controle de acesso à origem](#oac-advanced-settings-s3).

1. Use o comando a seguir para criar o controle de acesso à origem usando parâmetros de entrada do arquivo `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Anote o valor do `Id` na saída do comando. Você precisa dele para adicionar o OAC a uma origem de bucket do S3 em uma distribuição do CloudFront.

**Como anexar um OAC a uma origem de bucket do S3 em uma distribuição existente (CLI com arquivo de entrada)**

1. Use o comando a seguir para salvar a configuração da distribuição do CloudFront à qual você deseja adicionar o OAC. A distribuição deve ter uma origem de bucket do S3.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Abra o arquivo chamado `dist-config.yaml` que você acabou de criar. Edite o arquivo fazendo as seguintes alterações:
   + No objeto `Origins`, adicione o ID do OAC ao campo chamado `OriginAccessControlId`.
   + Remova o valor do campo chamado `OriginAccessIdentity`, se houver.
   + Renomeie o campo `ETag` para `IfMatch`, mas não altere o valor do campo.

   Ao concluir, salve o arquivo.

1. Use o comando a seguir para atualizar a distribuição para usar o controle de acesso à origem.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

A distribuição começa a ser implantada em todos os locais da borda do CloudFront. Quando um local da borda recebe a nova configuração, ele assina todas as solicitações enviadas à origem do bucket do S3.

------
#### [ API ]

Para criar um controle de acesso à origem com a API do CloudFront, use [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Para obter mais informações sobre os campos especificados nessa chamada de API, consulte a documentação de referência de API do seu AWS SDK ou de outro cliente de API.

Assim que criar um controle de acesso à origem, você pode anexá-lo a uma origem de bucket do S3 em uma distribuição usando uma das seguintes chamadas de API:
+ Para anexá-lo a uma distribuição existente, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Para anexá-lo a uma nova distribuição, use [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Para as duas chamadas de API, forneça o ID de controle de acesso à origem no campo `OriginAccessControlId`, dentro de uma origem. Para mais informações sobre os outros campos especificados nessas chamadas de API, consulte [Referência de configurações de todas as distribuições](distribution-web-values-specify.md) e a documentação de referência da API do AWS SDK ou de outro cliente de API.

------

## Excluir uma distribuição com um OAC anexado a um bucket do S3
<a name="delete-oac-distribution-s3"></a>

Se precisar excluir uma distribuição com um OAC anexado a um bucket do S3, exclua a distribuição antes de excluir a origem do bucket do S3. Como alternativa, inclua a Região no nome de domínio de origem. Se isso não for possível, é possível remover o OAC da distribuição mudando para público antes da exclusão. Para obter mais informações, consulte [Excluir uma distribuição](HowToDeleteDistribution.md).

## Migrar da identidade do acesso de origem (OAI) para o controle de acesso à origem (OAC)
<a name="migrate-from-oai-to-oac"></a>

Para migrar de uma identidade do acesso de origem (OAI) herdada para um controle de acesso à origem (OAC), primeiro atualize a origem do bucket do S3 para permitir que a OAI e a distribuição com OAC habilitado acessem o conteúdo do bucket. Isso garante que o CloudFront nunca perca o acesso ao bucket durante a transição. Para permitir que a OAI e a distribuição com OAC habilitado acessem um bucket do S3, atualize a [política de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) para incluir duas instruções, uma para cada tipo de entidade principal.

O exemplo de política de bucket do S3 a seguir permite que uma OAI e uma distribuição com OAC habilitado acessem uma origem do S3.

**Example Política de bucket do S3 que permite acesso somente leitura para uma OAI e uma distribuição do CloudFront com OAC habilitado**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
                }
            }
        },
        {
            "Sid": "AllowLegacyOAIReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

Depois de atualizar a política de bucket da origem do S3 para permitir o acesso à OAI e ao OAC, você pode atualizar a configuração de distribuição para usar o OAC em vez da OAI. Para obter mais informações, consulte [Criar um controle de acesso à origem](#create-oac-overview-s3).

Depois que a distribuição estiver totalmente implantada, você poderá remover a declaração na política de bucket que permite o acesso à OAI. Para obter mais informações, consulte [Conceder permissão ao CloudFront para acessar o bucket do S3](#oac-permission-to-access-s3).

## Configurações avançadas para controle de acesso à origem
<a name="oac-advanced-settings-s3"></a>

O recurso de controle de acesso à origem do CloudFront inclui configurações avançadas destinadas somente a casos de uso específicos. Use as configurações recomendadas, a menos que você precise usar as configurações avançadas para uma necessidade específica.

O controle de acesso à origem contém uma configuração chamada **Signing behavior** (Comportamento de assinatura) (no console) ou `SigningBehavior` (na API, na CLI e no CloudFormation). Essa configuração fornece as seguintes opções:

**Always sign origin requests (recommended setting) [Sempre assinar solicitações de origem (configuração recomendada)]**  
Recomendamos usar essa configuração, chamada **Sign requests (recommended)** [Assinar solicitações (recomendado)] no console, ou `always` na API, na CLI e no CloudFormation. Com essa configuração, o CloudFront sempre assina todas as solicitações enviadas à origem do bucket do S3.

**Never sign origin requests (Nunca assinar solicitações de origem)**  
Essa configuração é chamada **Do not sign requests** (Não assinar solicitações) no console ou `never` na API, na CLI e no CloudFormation. Use essa configuração para desativar o controle de acesso à origem para todas as origens em todas as distribuições que usam esse controle. Isso pode economizar tempo e esforço em comparação com a remoção individual de um controle de acesso à origem de todas as origens e distribuições que o usam. Com essa configuração, o CloudFront não assina nenhuma solicitação enviada à origem do bucket do S3.  
Para usar essa configuração, a origem do bucket do S3 deve estar acessível ao público. Se você usar essa configuração com uma origem de bucket do S3 que não esteja acessível ao público, o CloudFront não poderá acessar a origem. A origem do bucket do S3 retorna erros ao CloudFront e o CloudFront transmite esses erros aos visualizadores.

**Não substituir o cabeçalho `Authorization` do visualizador (cliente)**  
Essa configuração é chamada **Do not override authorization header** (Não substituir o cabeçalho de autorização) no console ou `no-override` na API, na CLI e no CloudFormation. Use essa configuração quando quiser que o CloudFront assine solicitações de origem somente quando a solicitação do visualizador correspondente não incluir um cabeçalho `Authorization`. Com essa configuração, o CloudFront transmite o cabeçalho `Authorization` da solicitação do visualizador quando houver, mas assina a solicitação de origem (adicionando seu próprio cabeçalho `Authorization`) quando a solicitação do visualizador não inclui um cabeçalho `Authorization`.  
Para transmitir o cabeçalho `Authorization` da solicitação do visualizador, você *deve* adicionar o cabeçalho `Authorization` a uma [política de cache](controlling-the-cache-key.md) para todos os comportamentos de cache que usam origens de bucket do S3 associadas a esse controle de acesso à origem.

## Usar uma identidade de acesso à origem (herdada, não recomendado)
<a name="private-content-restricting-access-to-s3-oai"></a>

### Visão geral da identidade do acesso de origem
<a name="private-content-restricting-access-to-s3-overview"></a>

A *identidade do acesso de origem* (OAI) do CloudFront fornece funcionalidade semelhante ao *controle de acesso à origem* (OAC), mas não funciona em todos os cenários. O OAI não é compatível especificamente com:
+ Buckets do Amazon S3 em todas as Regiões da AWS, inclusive regiões opcionais.
+ [Criptografia do lado do servidor com o AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS) do Amazon S3
+ Solicitações dinâmicas (`PUT`, `POST` ou `DELETE`) para o Amazon S3
+ Novas Regiões da AWS lançadas após janeiro de 2023

**dica**  
Em vez disso, recomendamos usar o OAC. Para configurar o OAC, consulte [Criar um controle de acesso à origem](#create-oac-overview-s3). Para obter informações sobre como migrar da OAI para o OAC, consulte [Migrar da identidade do acesso de origem (OAI) para o controle de acesso à origem (OAC)](#migrate-from-oai-to-oac).

### Conceder permissão a uma identidade de acesso à origem para ler arquivos no bucket do Amazon S3
<a name="private-content-granting-permissions-to-oai"></a>

Ao criar uma OAI ou adicionar uma a uma distribuição com o console do CloudFront, é possível atualizar automaticamente a política de bucket do Amazon S3 para conceder à OAI permissão para acessar seu bucket. Você também pode optar por criar ou atualizar manualmente a política do bucket. Seja qual for o método usado, você ainda deverá revisar as permissões para se certificar de que:
+ Sua OAI do CloudFront pode acessar arquivos no bucket em nome dos visualizadores que os solicitam por meio do CloudFront.
+ Os visualizadores não podem usar URLs do Amazon S3 para acessar seus arquivos fora do CloudFront.

**Importante**  
Se você configurar o CloudFront para aceitar e encaminhar todos os métodos HTTP compatíveis com o CloudFront, certifique-se de conceder à OAI do CloudFront as permissões desejadas. Por exemplo, se você configurar o CloudFront para aceitar e encaminhar solicitações que usem o método `DELETE`, configure sua política de bucket para lidar com as solicitações `DELETE` de maneira adequada, para que os visualizadores possam excluir somente os arquivos desejados.

#### Usar políticas de bucket do Amazon S3
<a name="private-content-updating-s3-bucket-policies"></a>

É possível conceder a uma OAI do CloudFront acesso a arquivos em um bucket do Amazon S3 criando ou atualizando a política de bucket das seguintes maneiras:
+ Usando a guia **Permissions** (Permissões) do bucket do Amazon S3 no [console do Amazon S3](https://console.aws.amazon.com/s3/home).
+ Usando o [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html) na API do Amazon S3.
+ Usando o [console do CloudFront](https://console.aws.amazon.com/cloudfront/v4/home). Ao adicionar uma OAI às suas configurações de origem no console do CloudFront, é possível escolher **Yes, update the bucket policy** (Sim, atualizar a política de bucket) para informar o CloudFront para atualizar a política de bucket em seu nome.

Se você atualizar a política de bucket manualmente, certifique-se de:
+ Especificar a OAI correta como `Principal` na política.
+ Conceder à OAI as permissões necessárias para acessar objetos em nome dos visualizadores.

Para obter mais informações, consulte as seções a seguir.

##### Especificar uma OAI como `Principal` em uma política de bucket
<a name="private-content-updating-s3-bucket-policies-principal"></a>

Para especificar uma OAI como `Principal` em uma política de bucket do Amazon S3, use o nome do recurso da Amazon (ARN) da OAI, que inclui o respectivo ID. Por exemplo:

```
"Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
}
```

Encontre o ID do OAI no console do CloudFront **Security** (Segurança), **Origin access** (Acesso à origem), **Identities (legacy)** (Identidades [legado]). Como alternativa, use [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) na API do CloudFront.

##### Conceder permissões a uma OAI
<a name="private-content-updating-s3-bucket-policies-permissions"></a>

Para conceder permissões à OAI para acessar objetos em seu bucket do Amazon S3, use ações na política que se relacionem a operações de API específicas do Amazon S3. Por exemplo, a ação `s3:GetObject` possibilita que a OAI leia objetos no bucket. Para obter mais informações, consulte os exemplos na seção a seguir, ou consulte [Ações do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) no *Guia do usuário do Amazon Simple Storage Service*.

##### Exemplos de política de bucket do Amazon S3
<a name="private-content-updating-s3-bucket-policies-examples"></a>

Os exemplos a seguir mostram políticas de bucket do Amazon S3 que permitem que a OAI do CloudFront acesse um bucket do S3.

Encontre o ID do OAI no console do CloudFront **Security** (Segurança), **Origin access** (Acesso à origem), **Identities (legacy)** (Identidades [legado]). Como alternativa, use [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) na API do CloudFront.

**Example Política de bucket do Amazon S3 que concede à OAI acesso de leitura**  
O exemplo a seguir permite que a OAI leia objetos no bucket especificado (`s3:GetObject`).    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

**Example Política de bucket do Amazon S3 que concede à OAI acesso de leitura e gravação**  
O exemplo a seguir permite que a OAI leia e grave objetos no bucket especificado (`s3:GetObject` e `s3:PutObject`). Isso permite que os visualizadores façam upload de arquivos no bucket do Amazon S3 por meio do CloudFront.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

#### Usar ACLs de objeto do Amazon S3 (não recomendado)
<a name="private-content-updating-s3-acls"></a>

**Importante**  
Recomendamos o [uso de políticas de bucket do Amazon S3](#private-content-updating-s3-bucket-policies) para conceder a uma OAI acesso a um bucket do S3. Você pode usar listas de controle de acesso (ACLs) conforme descrito nesta seção, mas não recomendamos fazê-lo.  
O Amazon S3 recomenda a configuração de [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) (Propriedade do objeto do S3) como **bucket owner enforced** (aplicado pelo proprietário do bucket), o que significa que as ACLs estão desabilitadas para o bucket e os objetos nele contidos. Ao aplicar essa configuração para Object Ownership (Propriedade de objeto), você deve usar políticas de bucket para conceder acesso à OAI (consulte a seção anterior).  
Esta seção a seguir é apenas para casos de uso herdados que exigem ACLs.

É possível conceder a uma OAI do CloudFront acesso a arquivos em um bucket do Amazon S3 criando ou atualizando a ACL do arquivo das seguintes maneiras:
+ Usando a guia **Permissions** (Permissões) do objeto do Amazon S3 no [console do Amazon S3](https://console.aws.amazon.com/s3/home).
+ Usando [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html) na API do Amazon S3.

Ao conceder acesso a uma OAI usando uma ACL, é necessário especificar a OAI por meio de seu ID de usuário canônico do Amazon S3. No console do CloudFront, é possível encontrar este ID em **Security** (Segurança), **Origin access** (Acesso à origem), **Identities (legacy)** (Identidades [legado]). Se estiver usando a API do CloudFront, use o valor do elemento `S3CanonicalUserId` retornado quando você criou a OAI ou chame [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) na API do CloudFront.

### Usar uma identidade de acesso à origem nas regiões do Amazon S3 compatíveis apenas com a autenticação Signature versão 4
<a name="private-content-origin-access-identity-signature-version-4"></a>

As regiões mais recentes do Amazon S3 exigem o uso do Signature Version 4 para solicitações autenticadas. (Para ver as versões de assinatura com suporte em cada região do Amazon S3, consulte [Endpoints e cotas do Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) na *Referência geral da AWS*). Se estiver usando uma identidade de acesso de origem e seu bucket estiver em uma das regiões que exijam o Signature versão 4, observe o seguinte:
+ As solicitações `DELETE`, `GET`, `HEAD`, `OPTIONS` e `PATCH` são compatíveis sem qualificações.
+ `POST`As solicitações não são compatíveis.

# Restringe o acesso com origens de VPC.
<a name="private-content-vpc-origins"></a>

É possível usar o CloudFront para fornecer conteúdo de aplicações que estão hospedadas em sub-redes privadas da nuvem privada virtual (VPC). Você pode usar Application Load Balancers (ALBs), Network Load Balancers (NLBs) e instâncias do EC2 em sub-redes privadas como origens de VPC.

Veja abaixo alguns motivos pelos quais pode ser interessante usar origens de VPC:
+ **Segurança**: as origens de VPC são projetadas para aprimorar o procedimento de segurança da aplicação colocando os balanceadores de carga e as instâncias do EC2 em sub-redes privadas, o que torna o CloudFront o único ponto de entrada. As solicitações dos usuários são transmitidas do CloudFront para as origens de VPC por meio de uma conexão privada e segura, fornecendo segurança adicional para as aplicações.
+ **Gerenciamento**: as origens de VPC reduzem o custo operacional indireto necessário para estabelecer uma conectividade segura entre o CloudFront e as origens. Além de poder mover as origens para sub-redes privadas sem acesso público, você não precisa implementar listas de controle de acesso (ACLs) ou outros mecanismos para restringir o acesso às origens. Dessa forma, não é necessário investir em trabalho de desenvolvimento não diferenciado para proteger aplicações web com o CloudFront. 
+ **Escalabilidade e desempenho**: como as origens de VPC ajudam a proteger aplicações web, você tem mais tempo para se concentrar no desenvolvimento de aplicações empresariais essenciais e, ao mesmo tempo, melhorar a segurança e manter alto desempenho e escalabilidade global com o CloudFront. As origens de VPC simplificam o gerenciamento de segurança e reduzem a complexidade operacional para que você use o CloudFront como o único ponto de entrada para suas aplicações.

**dica**  
O CloudFront permite o compartilhamento de origens de VPC entre Contas da AWS independentemente de elas estarem ou não em sua organização. É possível compartilhar as origens de VPC no console do CloudFront ou usar o AWS Resource Access Manager (AWS RAM). Para obter mais informações, consulte [Trabalhar com recursos compartilhados no CloudFront](sharing-resources.md).

## Pré-requisitos
<a name="vpc-origin-prerequisites"></a>

Antes de criar uma origem de VPC para sua distribuição do CloudFront, é necessário concluir o seguinte:

### Configuração de VPC
<a name="vpc-configuration"></a>

**Crie uma nuvem privada virtual (VPC) na Amazon VPC** em uma das Regiões da AWS nas quais é possível usar origens de VPC. Para ter informações sobre como criar uma VPC, consulte [Criar uma VPC e outros recursos de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-and-other-resources) no *Manual do usuário da Amazon VPC*. Para obter uma lista de regiões compatíveis, consulte [Tabela de Regiões da AWS que permitem o uso de origens de VPC](#vpc-origins-supported-regions).

Sua VPC deve incluir o seguinte:
+ **Gateway da internet**: você precisa adicionar um gateway da internet à VPC que contém seus recursos da origem de VPC. O gateway da internet é necessário para indicar que a VPC pode receber tráfego da internet. Ele não é usado para rotear o tráfego para origens dentro da sub-rede, e você não precisa atualizar as políticas de roteamento.
+ **Sub-rede privada com pelo menos um endereço IPv4 disponível**: o CloudFront faz o roteamento para a sub-rede usando uma interface de rede elástica (ENI) autogerenciada que o CloudFront cria depois que você define seu recurso da VPC de origem com o CloudFront. Você deve ter pelo menos um endereço IPv4 disponível na sub-rede privada para que o processo de criação da ENI seja bem-sucedido. O endereço IPv4 pode ser privado, e não há custo adicional para isso. Sub-redes somente IPv6 não são compatíveis.

### Recursos de origem
<a name="origin-resources"></a>

Na sub-rede privada, inicie um Application Load Balancer, um Network Load Balancer ou uma instância do EC2 para usar como origem. O recurso que você inicia deve estar totalmente implantado e no status Ativo para que seja possível usá-lo em uma origem de VPC.

**Restrições de origem:**
+ Não é possível adicionar Gateway Load Balancers como origens.
+ Não é possível adicionar Network Load Balancers de pilha dupla como origem.
+ Não é possível adicionar Network Load Balancers com receptores TLS como origem.
+ Para ser usado como origem de VPC, um Network Load Balancer deve ter um grupo de segurança anexado a ele.

### Configuração do security group
<a name="security-group-configuration"></a>

Os recursos de origem de VPC (Application Load Balancer, Network Load Balancer ou instância do EC2) devem ter um grupo de segurança anexado. Quando uma origem de VPC é criada, o CloudFront cria automaticamente um grupo de segurança gerenciado pelo serviço com o padrão denominado `CloudFront-VPCOrigins-Service-SG`. Esse grupo de segurança é totalmente gerenciado pela AWS e não deve ser editado.

Para permitir que o tráfego do CloudFront chegue à origem de VPC, atualize o grupo de segurança anexado ao recurso de origem (ALB, NLB ou instância do EC2) para permitir o tráfego de entrada usando um dos seguintes métodos:
+ **Opção 1:** permitir o tráfego da lista de prefixos gerenciados do CloudFront. Para obter mais informações, consulte [Use a lista de prefixos gerenciados do CloudFront](LocationsOfEdgeServers.md#managed-prefix-list). Isso também pode ser feito antes da criação da origem de VPC.
+ **Opção 2:** permitir o tráfego do grupo de segurança gerenciado pelo serviço do CloudFront (`CloudFront-VPCOrigins-Service-SG`). Isso só pode ser feito depois que a origem de VPC for criada e o grupo de segurança gerenciado pelo serviço for criado. Essa configuração é ainda mais restritiva, pois restringe o tráfego somente às suas distribuições do CloudFront.

**Importante**  
Não crie um grupo de segurança próprio com um nome que comece com `CloudFront-VPCOrigins-Service-SG`. Esse é um padrão de nomenclatura da AWS reservado para grupos de segurança gerenciados por serviços. Para ter mais informações, consulte [Crie um grupo de segurança para a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html).

### Restrições de protocolo e recurso
<a name="protocol-feature-restrictions"></a>

As origens de VPC não admitem o seguinte:
+ WebSockets
+ Tráfego gRPC.
+ Acionadores de solicitação à origem e de resposta da origem com o Lambda@Edge.

## Criar uma origem de VPC (nova distribuição)
<a name="new-vpc-origin"></a>

O procedimento a seguir mostra como criar uma origem de VPC para uma nova distribuição do CloudFront no console do CloudFront. Você também pode usar as operações de API [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html) e [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) com a AWS CLI ou com um SDK da AWS.

**Como criar uma origem de VPC para uma nova distribuição do CloudFront**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha **Origens de VPC** e **Criar uma origem de VPC**.

1. Preencha os campos obrigatórios. Em **ARN da origem**, selecione o ARN do Application Load Balancer, do Network Load Balancer ou da instância do EC2. Se você não vir o ARN, poderá copiar o ARN do seu recurso específico e colá-lo aqui.

1. Escolha **Criar origem**.

1. Aguarde até que o status da origem de VPC mude para **Implantado**. Esse processo pode levar até 15 minutos.

1. Escolha **Distribuições** e **Criar distribuição**.

1. Em **Domínio da origem**, selecione seu recurso de origens de VPC na lista suspensa.

   Se a origem de VPC for uma instância do EC2, copie e cole o **nome DNS do IP privado** da instância no campo **Domínio da origem**.

1. Finalize a criação da distribuição. Para obter mais informações, consulte [Criar uma distribuição do CloudFront no console](distribution-web-creating-console.md#create-console-distribution).

## Criar uma origem de VPC (distribuição existente)
<a name="existing-vpc-origin"></a>

O procedimento a seguir mostra como criar uma origem de VPC para uma distribuição existente do CloudFront no console do CloudFront, o que ajuda a garantir a disponibilidade contínua de suas aplicações. Você também pode usar as operações de API [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html) e [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html) com a AWS CLI ou um SDK da AWS.

Ou então você pode optar por adicionar a origem de VPC à distribuição existente sem criar uma distribuição de teste.

**Como criar uma origem de VPC para uma distribuição existente do CloudFront**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha **Origens de VPC** e **Criar uma origem de VPC**.

1. Preencha os campos obrigatórios. Em **ARN da origem**, selecione o ARN do Application Load Balancer, do Network Load Balancer ou da instância do EC2. Se você não vir o ARN, poderá copiar o ARN do seu recurso específico e colá-lo aqui.

1. Escolha **Criar origem**.

1. Aguarde até que o status da origem de VPC mude para **Implantado**. Esse processo pode levar até 15 minutos.

1. No painel de navegação, escolha **Distribuições**.

1. Escolha o ID da distribuição.

1. Na guia **Geral**, em **Implantação contínua**, escolha **Criar distribuição de preparação**. Para obter mais informações, consulte [Usar a implantação contínua do CloudFront para testar com segurança as alterações na configuração da CDN](continuous-deployment.md).

1. Siga as etapas no assistente **Criar distribuição de preparação** para criar uma distribuição de preparação. Inclua as seguintes etapas:
   + Em **Origens**, escolha **Criar origem**.
   + Em **Domínio da origem**, selecione seu recurso de origens de VPC no menu suspenso.

     Se a origem de VPC for uma instância do EC2, copie e cole o **nome DNS do IP privado** da instância no campo **Domínio da origem**.
   + Escolha **Criar origem**.

1. Em sua distribuição de preparação, teste a origem de VPC.

1. Mova a configuração da distribuição de preparação para sua distribuição primária. Para obter mais informações, consulte [Promover a configuração de uma distribuição de preparação](working-with-staging-distribution-continuous-deployment-policy.md#promote-staging-distribution-configuration).

1. Remova o acesso público à sua origem de VPC configurando a sub-rede como privada. Depois de fazer isso, a origem de VPC não poderá ser descoberta pela internet, mas o CloudFront ainda terá acesso privado a ela. Para ter mais informações, consulte [Associar ou desassociar uma sub-rede de uma tabela de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AssociateSubnet) no *Manual do usuário da Amazon VPC*.

## Atualizar uma origem de VPC
<a name="update-vpc-origin"></a>

O procedimento a seguir mostra como atualizar uma origem de VPC para uma distribuição do CloudFront no console do CloudFront. Você também pode usar as operações de API [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) e [UpdateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateVpcOrigin.html) com a AWS CLI ou um SDK da AWS.

**Como atualizar uma origem de VPC para sua distribuição do CloudFront**

1. Abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Distribuições**.

1. Escolha o ID da distribuição.

1. Escolha a guia **Behaviors**.

1. Observe que a origem de VPC não deve ser a origem padrão para seu comportamento de cache. 

1. Escolha a guia **Origens**.

1. Selecione a origem de VPC que você vai atualizar e escolha **Excluir**. Isso dissocia a origem de VPC da sua distribuição. Repita as etapas de 2 a 7 para dissociar a origem de VPC de quaisquer outras distribuições.

1. Escolha **Origens de VPC**.

1. Selecione a origem de VPC e escolha **Editar**.

1. Faça suas atualizações e escolha **Atualizar origem de VPC**.

1. Aguarde até que o status da origem de VPC mude para **Implantado**. Esse processo pode levar até 15 minutos.

1. No painel de navegação, escolha **Distribuições**.

1. Escolha o ID da distribuição.

1. Escolha a guia **Origens**.

1. Escolha **Criar origem**.

1. Em **Domínio da origem**, selecione seu recurso de origens de VPC no menu suspenso.

   Se a origem de VPC for uma instância do EC2, copie e cole o **nome DNS do IP privado** da instância no campo **Domínio da origem**.

1. Escolha **Criar origem**. Isso associa novamente a origem de VPC à sua distribuição. Repita as etapas 12 a 17 para associar a origem de VPC atualizada a quaisquer outras distribuições.

## Tabela de Regiões da AWS que permitem o uso de origens de VPC
<a name="vpc-origins-supported-regions"></a>

No momento, é possível usar origens de VPC nas Regiões da AWS comerciais a seguir. Exceções da Zona de Disponibilidade (AZ) são anotadas.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)

# Restringir o acesso aos Application Load Balancers
<a name="restrict-access-to-load-balancer"></a>

Você pode usar Application Load Balancers internos e voltados para a internet com o Amazon CloudFront. Também é possível usar Application Load Balancers internos em sub-redes privadas com o CloudFront utilizando origens de VPC. As origens de VPC do CloudFront permitem que você forneça conteúdo de aplicações hospedadas em sub-redes VPC privadas sem as expor à internet pública. Para obter mais informações, consulte [Restringe o acesso com origens de VPC.](private-content-vpc-origins.md).

Se você estiver usando um Application Load Balancer voltado para a internet com CloudFront, poderá usar as mitigações de segurança a seguir para impedir que os usuários acessem diretamente um Application Load Balancer e permitir acesso somente por meio do CloudFront.

1. Configure o CloudFront para adicionar um cabeçalho HTTP personalizado às solicitações enviadas ao Application Load Balancer.

1. Configure o Application Load Balancer para encaminhar apenas solicitações que contenham o cabeçalho HTTP personalizado.

1. Exija HTTPS para melhorar a segurança dessa solução.

O CloudFront também pode ajudar a reduzir a latência e até mesmo absorver alguns ataques de negação distribuída de serviço (DDoS).

Se seu caso de uso exigir acesso duplo a aplicações web por meio do CloudFront e do Application Load Balancer diretamente pela internet, considere dividir suas APIs de aplicação web da seguinte forma:
+ APIs que devem passar pelo CloudFront. Nesse caso, considere usar um Application Load Balancer privado separado como origem.
+ APIs que exigem acesso por meio do Application Load Balancer. Nesse caso, você ignora o CloudFront.

Para uma aplicação web ou outro conteúdo fornecido por um Application Load Balancer voltado à internet no Elastic Load Balancing, o CloudFront pode armazenar objetos em cache e disponibilizá-los diretamente aos usuários (espectadores), reduzindo a carga no Application Load Balancer. Um balanceador de carga voltado para a internet tem um nome de DNS que pode ser resolvido publicamente e roteia solicitações de clientes até destinos na internet.

Para obter mais informações, consulte os tópicos a seguir. Depois de concluir essas etapas, os usuários só podem acessar seu Application Load Balancer por meio do CloudFront.

**Topics**
+ [Configurar o CloudFront para adicionar um cabeçalho HTTP personalizado às solicitações](#restrict-alb-add-custom-header)
+ [Configurar um Application Load Balancer para encaminhar apenas solicitações que contenham um cabeçalho específico](#restrict-alb-route-based-on-header)
+ [(Opcional) Melhorar a segurança dessa solução](#restrict-alb-improve-security)
+ [(Opcional) Limite o acesso à origem usando a lista de prefixos gerenciada pela AWS para o CloudFront](#limit-access-to-origin-using-aws-managed-prefixes)

## Configurar o CloudFront para adicionar um cabeçalho HTTP personalizado às solicitações
<a name="restrict-alb-add-custom-header"></a>

Você pode configurar o CloudFront para adicionar um cabeçalho HTTP personalizado às solicitações enviadas para sua origem (neste caso, um Application Load Balancer).

**Importante**  
Esse caso de uso depende de manter em segredo o nome e o valor do cabeçalho personalizado. Se o nome e o valor do cabeçalho não forem secretos, outros clientes HTTP poderão incluí-los em solicitações enviadas diretamente para o Application Load Balancer. Isso pode fazer com que o Application Load Balancer se comporte como se as solicitações viessem do CloudFront quando não o fizessem. Para evitar isso, mantenha o nome e o valor do cabeçalho personalizado em segredo.

É possível configurar o CloudFront para adicionar um cabeçalho HTTP personalizado às solicitações à origem com o console do CloudFront, o CloudFormation ou a API do CloudFront.

**Para adicionar um cabeçalho HTTP personalizado (console do CloudFront)**  
No console do CloudFront, use a configuração **Origin Custom Headers (Cabeçalhos personalizados de origem)** em **Origin Settings (Configurações de origem)**. Insira o **nome do cabeçalho** e o respectivo **valor**.  
Na produção, use valores e nomes de cabeçalho gerados aleatoriamente. Trate os nomes e os valores do cabeçalho como credenciais seguras; por exemplo, nomes de usuário e senhas.
Você pode editar a configuração **Origin Custom Headers (Cabeçalhos personalizados de origem)** ao criar ou editar uma origem para uma distribuição existente do CloudFront e ao criar uma nova distribuição. Para obter mais informações, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md) e [Criar uma distribuição](distribution-web-creating-console.md).

**Para adicionar um cabeçalho HTTP personalizado (CloudFormation)**  
Em um modelo do CloudFormation, use a propriedade `OriginCustomHeaders`, como mostrado no exemplo a seguir.  
O nome e o valor do cabeçalho neste exemplo são apenas para demonstração. Na produção, use valores gerados aleatoriamente. Trate o nome e o valor do cabeçalho como uma credencial segura, como um nome do usuário e senha.

```
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TestDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Origins:
          - DomainName: app-load-balancer.example.com
            Id: Example-ALB
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
              OriginSSLProtocols:
                - TLSv1.2
            OriginCustomHeaders:
               - HeaderName: X-Custom-Header
                 HeaderValue: random-value-1234567890
        Enabled: 'true'
        DefaultCacheBehavior:
          TargetOriginId: Example-ALB
          ViewerProtocolPolicy: allow-all
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
        PriceClass: PriceClass_All
        ViewerCertificate:
          CloudFrontDefaultCertificate: 'true'
```
Para ter mais informações, consulte as propriedades [Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) e [OriginCustomHeader](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origincustomheader.html) no *Guia do usuário do AWS CloudFormation*.

**Para adicionar um cabeçalho HTTP personalizado (API do CloudFront)**  
Na API do CloudFront, use o objeto `CustomHeaders` dentro de `Origin`. Para obter mais informações, consulte [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) e [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront* e a documentação do seu SDK ou outro cliente de API.

Há alguns nomes de cabeçalho que não é possível especificar como cabeçalhos personalizados de origem. Para obter mais informações, consulte [Cabeçalhos personalizados que o CloudFront não pode adicionar às solicitações da origem](add-origin-custom-headers.md#add-origin-custom-headers-denylist).

## Configurar um Application Load Balancer para encaminhar apenas solicitações que contenham um cabeçalho específico
<a name="restrict-alb-route-based-on-header"></a>

Depois de configurar o CloudFront para adicionar um cabeçalho HTTP personalizado às solicitações enviadas ao Application Load Balancer (consulte a [seção anterior](#restrict-alb-add-custom-header)), é possível configurar o balanceador de carga para encaminhar apenas solicitações que contenham esse cabeçalho personalizado. Para isso, adicione uma nova regra e modifique a regra padrão no listener de seu balanceador de carga.

**Pré-requisitos**  
Para usar os procedimentos a seguir, você precisa de um Application Load Balancer com pelo menos um listener. Se você ainda não criou um, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) no *Guia do usuário de Application Load Balancers*.

Os procedimentos a seguir modificam um listener HTTPS. Você pode usar o mesmo processo para modificar um listener HTTP.

**Para atualizar as regras em um listener do Application Load Balancer**

1. Adicione uma nova regra. Use as instruções de [Adicionar uma regra](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule) com as seguintes modificações:
   + Adicione a regra ao balanceador de carga que é a origem da distribuição do CloudFront.
   + Em **Adicionar condição**, escolha o **Cabeçalho HTTP**. Especifique o nome e o valor do cabeçalho HTTP que você adicionou como um cabeçalho personalizado de origem no CloudFront.
   + Em **Adicionar ação**, escolha **Encaminhar para**. Escolha o grupo de destino para o qual deseja encaminhar as solicitações.

1. Edite a regra padrão no receptor do balanceador de carga. Use as instruções de [Editar uma regra](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule) com as seguintes modificações:
   + Edite a regra padrão do balanceador de carga que é a origem da distribuição do CloudFront.
   + Exclua a ação padrão e, em **Adicionar ação**, escolha **Retornar resposta fixa**. 
   + Para **Response code (Código de resposta)**, insira **403**.
   + Para **Response body (Corpo de resposta)**, insira **Access denied**.

Ao concluir essas etapas, o receptor do balanceador de carga terá duas regras. Uma regra encaminha solicitações que contêm o cabeçalho HTTP (solicitações que vêm do CloudFront). A outra regra envia uma resposta fixa a todas as outras solicitações (solicitações que não vêm do CloudFront).

Você pode verificar se a solução funciona enviando uma solicitação para a distribuição do CloudFront e outra para o Application Load Balancer. A solicitação ao CloudFront retorna sua aplicação ou conteúdo da Web e a enviada diretamente ao Application Load Balancer retorna uma resposta `403` com a mensagem de texto simples `Access denied`.

## (Opcional) Melhorar a segurança dessa solução
<a name="restrict-alb-improve-security"></a>

Para melhorar a segurança dessa solução, configure sua distribuição do CloudFront para usar sempre HTTPS ao enviar solicitações ao Application Load Balancer. Lembre-se, essa solução só funciona se você mantiver o nome e o valor do cabeçalho personalizado em segredo. Usar HTTPS pode ajudar a impedir que um bisbilhoteiro descubra o nome e o valor do cabeçalho. Também recomendamos alternar o nome e o valor do cabeçalho periodicamente.

**Usar HTTPS para solicitações de origem**  
Para configurar o CloudFront para usar HTTPS em solicitações de origem, defina a configuração de **Origin Protocol Policy (Política de protocolo de origem)** como **HTTPS Only (Somente HTTPS)**. Essa configuração está disponível no console do CloudFront, no CloudFormation e na API do CloudFront. Para obter mais informações, consulte [Protocolo (somente origens personalizadas)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy).

O seguinte também se aplica ao configurar o CloudFront para usar HTTPS em solicitações de origem:
+ Você deve configurar o CloudFront para encaminhar o cabeçalho `Host` para a origem com a política de solicitação de origem. É possível usar a [política de solicitação de origem gerenciada do AllViewer](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer).
+ Certifique-se de que o Application Load Balancer tem um receptor HTTPS (conforme mostrado [na seção anterior](#restrict-alb-route-based-on-header)). Para obter mais informações, consulte [Criar um listener HTTPS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) no *Guia do usuário de Application Load Balancers*. Usar um receptor HTTPS requer que você tenha um certificado SSL/TLS que corresponda ao nome de domínio que é roteado para o Application Load Balancer.
+ Os certificados SSL/TLS para o CloudFront só podem ser solicitados (ou importados) na Região da AWS `us-east-1` no AWS Certificate Manager (ACM). Como o CloudFront é um serviço global, ele distribui automaticamente o certificado da região `us-east-1` para todas as regiões associadas à sua distribuição do CloudFront.
  + Por exemplo, se você tiver um Application Load Balancer (ALB) na região `ap-southeast-2`, deverá configurar certificados SSL/TLS na região `ap-southeast-2` (para usar HTTPS entre o CloudFront e a origem do ALB) e na região `us-east-1` (para usar HTTPS entre os visualizadores e o CloudFront). Ambos os certificados devem corresponder ao nome de domínio que é encaminhado para o Application Load Balancer. Para obter mais informações, consulte [Região da AWS para AWS Certificate Manager](cnames-and-https-requirements.md#https-requirements-aws-region).
+ Se os usuários finais (também conhecidos como *visualizadores*ou *clientes*) da sua aplicação Web puderem usar HTTPS, você também poderá configurar o CloudFront para preferir (ou até mesmo exigir) conexões HTTPS dos usuários finais. Para fazer isso, use a configuração **Política de protocolo de visualizador)**. Você pode ajustá-la para redirecionar usuários finais de HTTP para HTTPS, ou para rejeitar solicitações que usam HTTP. Essa configuração está disponível no console do CloudFront, no CloudFormation e na API do CloudFront. Para obter mais informações, consulte [Política de protocolo do visualizador](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy).

**Alternar o nome e o valor do cabeçalho**  
Além de usar HTTPS, também recomendamos alternar o nome e o valor do cabeçalho periodicamente. As etapas de alto nível para fazer isso são as seguintes:

1. Configure o CloudFront para adicionar um cabeçalho HTTP personalizado adicional às solicitações enviadas ao Application Load Balancer.

1. Atualize a regra do listener do Application Load Balancer para encaminhar solicitações que contenham esse cabeçalho HTTP personalizado adicional.

1. Configure o CloudFront para parar de adicionar o cabeçalho HTTP personalizado original às solicitações enviadas ao Application Load Balancer.

1. Atualize a regra do listener do Application Load Balancer para interromper o encaminhamento de solicitações que contenham o cabeçalho HTTP personalizado original.

Para obter mais informações sobre como realizar essas etapas, consulte as seções anteriores.

## (Opcional) Limite o acesso à origem usando a lista de prefixos gerenciada pela AWS para o CloudFront
<a name="limit-access-to-origin-using-aws-managed-prefixes"></a>

Para restringir ainda mais o acesso ao seu Application Load Balancer, é possível configurar o grupo de segurança associado ao Application Load Balancer para que ele só aceite tráfego do CloudFront quando o serviço estiver usando uma lista de prefixos gerenciada pela AWS. Isso evita que o tráfego que não se origina do CloudFront chegue ao seu Application Load Balancer na camada de rede (camada 3) ou na camada de transporte (camada 4).

Para ter mais informações, consulte a postagem do blog [Limitar o acesso às suas origens usando a lista de prefixos gerenciada pela AWS do Amazon CloudFront](https://aws.amazon.com//blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/).

# Restringir a distribuição geográfica do conteúdo
<a name="georestrictions"></a>

É possível usar *restrições geográficas*, também conhecidas como *bloqueios geográficos*, para impedir que usuários em localizações geográficas específicas acessem o conteúdo que você está distribuindo por meio de uma distribuição do Amazon CloudFront. Para usar restrições geográficas, você tem duas opções:
+ Use o recurso de restrições geográficas do CloudFront. Use essa opção para restringir o acesso a todos os arquivos associados a uma distribuição e restringir o acesso no nível do país.
+ Usar um serviço de geolocalização de terceiros. Use essa opção para restringir o acesso a um subconjunto de arquivos associados a uma distribuição ou restringir o acesso a uma granularidade mais específica no nível do país.

**Topics**
+ [Usar estrições geográficas do CloudFront](#georestrictions-cloudfront)
+ [Usar um serviço de geolocalização de terceiros](#georestrictions-geolocation-service)

## Usar estrições geográficas do CloudFront
<a name="georestrictions-cloudfront"></a>

Quando um usuário solicita seu conteúdo, o CloudFront normalmente o fornece, independentemente de onde o usuário está localizado. Se precisar impedir que usuários de alguns países acessem seu conteúdo, você poderá usar o recurso de restrições geográficas do CloudFront para executar uma das seguintes ações:
+ Conceder aos usuários acesso ao conteúdo somente se estiverem em um dos países aprovados na lista de permissões.
+ Impedir que os usuários acessem o conteúdo se estiverem em um dos países proibidos na lista de bloqueio.

Por exemplo, se a solicitação for proveniente de um país em que você não estiver autorizado a distribuir o conteúdo, poderá usar as restrições geográficas do CloudFront para bloquear a solicitação.

**nota**  
O CloudFront determina a localização de seus usuários usando um banco de dados de terceiros. A precisão do mapeamento entre os endereços IP e os países varia de acordo com a região. Com base em testes recentes, a precisão geral é de 99,8%. Se o CloudFront não conseguir determinar a localização de um usuário, ele fornecerá o conteúdo solicitado pelo usuário.

Veja como as restrições geográficas funcionam:

1. Imagine que você tenha direitos para distribuir o conteúdo apenas em Liechtenstein. Você deve atualizar a distribuição do CloudFront e adicionar uma lista de permissões que contenha somente Liechtenstein. (Ou é possível adicionar uma lista de bloqueio com todos os países, exceto Liechtenstein.)

1. Um usuário em Mônaco solicita seu conteúdo, e o DNS encaminha a solicitação ao local de borda do CloudFront em Milão, na Itália.

1. O local da borda em Milão procura sua distribuição e determina que o usuário em Mônaco não pode baixar seu conteúdo.

1. O CloudFront retorna um código de status HTTP `403 (Forbidden)` ao usuário.

Opcionalmente, você pode configurar o CloudFront para retornar uma mensagem de erro personalizada para o usuário e especificar por quanto tempo o CloudFront deve armazenar a resposta de erro em cache para o arquivo solicitado. O valor de padrão é de 10 segundos. Para obter mais informações, consulte [Criar uma página de erro personalizada para códigos de status HTTP específicos](creating-custom-error-pages.md).

As restrições geográficas se aplicam a toda uma distribuição. Se precisar aplicar uma restrição a parte de seu conteúdo e uma restrição diferente (ou nenhuma) a outra parte, você deverá criar distribuições distintas do CloudFront ou [usar um serviço de geolocalização de terceiros](#georestrictions-geolocation-service).

Se você habilitar [logs padrão](AccessLogs.md) (logs de acesso) do CloudFront, poderá identificar as solicitações recusadas pelo CloudFront procurando as entradas de log nas quais o valor de `sc-status` (o código de status HTTP) for `403`. No entanto, se usar somente os logs padrão, não será possível distinguir uma solicitação recusada pelo CloudFront com base na localização do usuário de uma solicitação recusada pelo CloudFront porque o usuário não tem permissão para acessar o arquivo por outro motivo. Se você tiver um serviço de geolocalização de terceiros, como Digital Element ou MaxMind, poderá identificar a localização das solicitações com base no endereço IP da coluna `c-ip` (IP do cliente) nos logs de acesso. Para obter mais informações sobre os logs padrão do CloudFront, consulte [Logs de acesso (logs padrão)](AccessLogs.md).

O procedimento a seguir explica como usar o console do CloudFront para adicionar restrições geográficas a uma distribuição existente. Para obter informações sobre como usar o console para criar uma distribuição, consulte [Criar uma distribuição](distribution-web-creating-console.md).<a name="restrictions-geo-procedure"></a>

**Como adicionar restrições geográficas à distribuição na Web do CloudFront (console)**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Distribuições** e selecione a distribuição que deseja atualizar.

1. Escolha a guia **Segurança** e selecione **Restrições geográficas**.

1. Escolha **Edit (Editar)**.

1. Selecione **Allow list** (Lista de permissões), para criar uma lista de países permitidos, ou **Block list** (Lista de bloqueio), para criar uma lista de países bloqueados.

1. Adicione os países desejados à lista e escolha **Save changes** (Salvar as alterações).

## Usar um serviço de geolocalização de terceiros
<a name="georestrictions-geolocation-service"></a>

Com o recurso de restrições geográficas do CloudFront, é possível controlar a distribuição do conteúdo em nível de país para todos os arquivos que estão sendo distribuídos com uma distribuição da web específica. Se tiver um caso de uso para restrições geográficas em que as restrições não sigam limites de país, ou se quiser restringir o acesso a apenas alguns arquivos distribuídos por determinada distribuição, você poderá combinar o CloudFront com um serviço de geolocalização de terceiros. Isso confere a você controle do conteúdo com base não apenas no país, mas também na cidade, no CEP ou no código postal, ou até mesmo na latitude e na longitude.

Se você usar um serviço de geolocalização de terceiros, recomendamos usar URLs assinados do CloudFront, que permitem especificar uma data e hora de expiração do URL. Além disso, recomendamos que você use um bucket do Amazon S3 como origem. Isso possibilita usar um [controle de acesso à origem](private-content-restricting-access-to-s3.md) do CloudFront para impedir que os usuários acessem seu conteúdo diretamente da origem. Para obter mais informações sobre URLs assinados e controle de acesso à origem, consulte [Veicular conteúdo privado com URLs e cookies assinados](PrivateContent.md).

As etapas a seguir explicam como controlar o acesso aos seus arquivos usando um serviço de geolocalização de terceiros.

**Como usar um serviço de geolocalização de terceiros para restringir o acesso a arquivos em uma distribuição do CloudFront**

1. Obtenha uma conta com um serviço de geolocalização.

1. Faça upload do conteúdo em um bucket do Amazon S3.

1. Configure o Amazon CloudFront e o Amazon S3 para fornecer conteúdo privado. Para obter mais informações, consulte [Veicular conteúdo privado com URLs e cookies assinados](PrivateContent.md).

1. Configure seu aplicativo web para:
   + Envie o endereço IP de cada solicitação de usuário para o serviço de geolocalização.
   + Avalie o valor de retorno do serviço de geolocalização para determinar se o usuário está em um local no qual você deseja que o CloudFront distribua seu conteúdo.
   + Se você quiser distribuir o conteúdo para a localização do usuário, gere um URL assinado para o conteúdo do CloudFront. Se não quiser distribuir o conteúdo para essa localização, retorne o código de status HTTP `403 (Forbidden)` para o usuário. É também possível configurar o CloudFront para retornar uma mensagem de erro personalizada. Para obter mais informações, consulte [Criar uma página de erro personalizada para códigos de status HTTP específicos](creating-custom-error-pages.md).

   Para obter mais informações, consulte a documentação do serviço de geolocalização que você estiver usando.

Você pode usar uma variável do servidor da Web para obter os endereços IP dos usuários que estiverem acessando seu site. Observe as seguintes advertências:
+ Se o servidor da Web não estiver conectado à Internet por um balanceador de carga, você poderá usar uma variável de servidor da Web para obter o endereço IP remoto. No entanto, esse endereço IP nem sempre é o endereço IP do usuário. Ele pode ser o endereço IP de um servidor de proxy, dependendo de como o usuário está conectado à Internet.
+ Se o servidor da web estiver conectado à Internet por um load balancer, uma variável dele poderá conter o endereço IP do load balancer, não do usuário. Nessa configuração, recomendamos que você use o último endereço IP do cabeçalho HTTP `X-Forwarded-For`. Esse cabeçalho normalmente contém mais de um endereço IP, e a maioria deles são para proxies ou balanceadores de carga. O último endereço IP da lista é o que tem maior probabilidade de estar associado à localização geográfica do usuário.

Se o servidor da Web não estiver conectado a um balanceador de carga, recomendamos que você use variáveis de servidor da Web, em vez do cabeçalho `X-Forwarded-For`, para evitar a falsificação do endereço IP.

# Use criptografia de nível de campo para ajudar a proteger dados confidenciais
<a name="field-level-encryption"></a>

Com o Amazon CloudFront, é possível impor conexões seguras de ponta a ponta a servidores de origem usando HTTPS. A criptografia no nível de campo acrescenta uma camada adicional de segurança que permite proteger dados específicos em todo o processamento do sistema, de modo que apenas alguns aplicativos possam vê-los.

A criptografia no nível de campo habilita permitir que usuários faça upload de informações confidenciais com segurança nos servidores web. As informações confidenciais fornecidas pelos usuários são criptografadas na borda, próximo ao usuário, e permanecem criptografadas em toda a pilha de aplicativos. Essa criptografia garante que somente os aplicativos que precisam dos dados e que têm as credenciais para descriptografá-los possam fazê-lo.

Para usar a criptografia no nível de campo, ao configurar a distribuição do CloudFront, especifique o conjunto de campos nas solicitações POST que você quer que sejam criptografados e a chave pública a ser usada para criptografá-los. Você pode criptografar até 10 campos de dados em uma solicitação. (Não é possível criptografar todos os dados em uma solicitação com criptografia no nível de campo; é preciso especificar campos individuais para criptografar.)

Quando a solicitação HTTPS com criptografia no nível de campo é encaminhada para a origem, e a solicitação é roteada em todo o subsistema ou aplicativo de origem, os dados confidenciais ainda são criptografados, reduzindo o risco de uma violação dos dados ou da perda acidental de dados confidenciais. Os componentes que precisam acessar os dados confidenciais por motivos comerciais, como um sistema de processamento de pagamento que precisa de acesso a um número de crédito, podem usar a chave privada apropriada para descriptografar e acessar os dados.

**nota**  
Para usar a criptografia no nível de campo, a origem deve oferecer suporte à codificação em partes.

![\[Criptografia em nível de campo no CloudFront\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/fleoverview.png)


A criptografia no nível de campo do CloudFront usa criptografia assimétrica, também conhecida como criptografia de chave pública. Basta você fornecer uma chave pública para o CloudFront e todos os dados confidenciais especificados são criptografados automaticamente. A chave que você fornece ao CloudFront não pode ser usada para descriptografar os valores criptografados; somente sua chave privada poderá fazer isso.

![\[Criptografar apenas dados confidenciais\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/encryptedfields.png)


**Topics**
+ [Visão geral da criptografia no nível de campo](#field-level-encryption-overview)
+ [Configurar a criptografia em nível de campo](#field-level-encryption-setting-up)
+ [Descriptografar campos de dados na origem](#field-level-encryption-decrypt)

## Visão geral da criptografia no nível de campo
<a name="field-level-encryption-overview"></a>

As etapas a seguir fornecem uma visão geral de como configurar a criptografia no nível de campo. Para obter as etapas específicas, consulte [Configurar a criptografia em nível de campo](#field-level-encryption-setting-up).

1. **Obtenha um par de chaves pública e privada.** É necessário obter e adicionar a chave pública antes de iniciar a configuração da criptografia no nível de campo do CloudFront.

1. **Crie um perfil de criptografia no nível de campo.** Os perfis de criptografia no nível de campo, que são criados no CloudFront, definem os campos que você deseja criptografar.

1. **Crie uma configuração de criptografia no nível de campo.** A configuração especifica os perfis a serem usados, com base no tipo de conteúdo da solicitação ou em um argumento de consulta, para criptografar campos de dados específicos. Também é possível escolher as opções de comportamento de encaminhamento de solicitações desejadas para diferentes situações. Por exemplo, você pode definir o comportamento para quando o nome do perfil especificado pelo argumento da consulta de um URL de solicitação não existir no CloudFront.

1. **Vincule um comportamento de cache.** Vincule a configuração a um comportamento de cache de uma distribuição para especificar quando o CloudFront deverá criptografar os dados.

## Configurar a criptografia em nível de campo
<a name="field-level-encryption-setting-up"></a>

Siga essas etapas para começar a usar a criptografia no nível de campo. Para saber mais sobre cotas (anteriormente conhecidas como limites) na criptografia em nível de campo, consulte [Cotas](cloudfront-limits.md).
+ [Etapa 1: Criar um par de chaves do RSA](#field-level-encryption-setting-up-step1)
+ [Etapa 2: Adicionar uma chave pública ao CloudFront](#field-level-encryption-setting-up-step2)
+ [Etapa 3: Criar um perfil de criptografia no nível de campo](#field-level-encryption-setting-up-step3)
+ [Etapa 4: Criar uma configuração](#field-level-encryption-setting-up-step4)
+ [Etapa 5: Adicionar uma configuração ao comportamento de cache](#field-level-encryption-setting-up-step5)

### Etapa 1: Criar um par de chaves do RSA
<a name="field-level-encryption-setting-up-step1"></a>

Para começar a usar, é necessário criar um par de chaves RSA que inclua uma chave pública e uma chave privada. A chave pública permite que o CloudFront criptografe dados e a chave privada permite que os componentes na origem descriptografem os campos que foram criptografados. Você pode usar o OpenSSL ou outra ferramenta para criar um par de chaves. O tamanho da chave deve ser de 2048 bits.

Por exemplo, se estiver usando OpenSSL, poderá usar o seguinte comando para gerar um par de chaves de 2.048 bits e salvá-lo no arquivo `private_key.pem`:

```
openssl genrsa -out private_key.pem 2048
```

O arquivo resultante contém a chave pública e a privada. Para extrair a chave pública do arquivo, execute o seguinte comando:

```
openssl rsa -pubout -in private_key.pem -out public_key.pem
```

O arquivo de chave pública (`public_key.pem`) contém o valor de chave codificada que você colar na etapa seguinte.

### Etapa 2: Adicionar uma chave pública ao CloudFront
<a name="field-level-encryption-setting-up-step2"></a>

Após obter o par de chaves RSA, adicione a sua chave pública ao CloudFront.<a name="field-level-encryption-setting-up-step2-procedure"></a>

**Como adicionar sua chave pública ao CloudFront (console)**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. No painel de navegação, escolha **Public key**.

1. Escolha **Add public key (Adicionar chave pública)**.

1. Em **Key name**, digite um nome exclusivo para a chave. O nome não pode conter espaços e só pode incluir caracteres alfanuméricos, sublinhados (\$1) e hífens (-). O número máximo de caracteres é 128.

1. Em **Key value (Valor de chave)**, cole o valor da chave pública codificada, incluindo as linhas `-----BEGIN PUBLIC KEY-----` e `-----END PUBLIC KEY-----`.

1. Em **Comment**, adicione um comentário opcional. Por exemplo, você pode incluir a data de expiração para a chave pública.

1. Escolha **Adicionar**.

É possível adicionar mais chaves para uso com o CloudFront repetindo as etapas desse procedimento.

### Etapa 3: Criar um perfil de criptografia no nível de campo
<a name="field-level-encryption-setting-up-step3"></a>

Depois de adicionar pelo menos uma chave pública ao CloudFront, crie um perfil que informe ao CloudFront quais campos serão criptografados.<a name="field-level-encryption-setting-up-step3-procedure"></a>

**Para criar um perfil de criptografia no nível de campo (console)**

1. No painel de navegação, escolha **Field-level encryption**.

1. Escolha **Create profile (Criar perfil)**.

1. Preencha os seguintes campos:  
**Profile name**  
Digite um nome exclusivo para o perfil. O nome não pode conter espaços e só pode incluir caracteres alfanuméricos, sublinhados (\$1) e hífens (-). O número máximo de caracteres é 128.  
**Nome da chave pública**  
Na lista suspensa, escolha o nome de uma chave pública que você adicionou ao CloudFront na etapa 2. O CloudFront usa a chave para criptografar os campos especificados neste perfil.  
**Nome do provedor**  
Digite uma frase que ajude a identificar a chave, como o provedor que forneceu o par de chaves. Essas informações, juntamente com a chave privada, são necessárias quando os aplicativos descriptografam os campos de dados. O nome do provedor não pode conter espaços e só pode incluir caracteres alfanuméricos, dois pontos (:), sublinhados (\$1) e hífens (-). O número máximo de caracteres é 128.  
**Padrão do nome do campo para correspondência**  
Digite os nomes dos campos de dados, ou padrões que identifiquem nomes de campos de dados na solicitação, a serem criptografados pelo CloudFront. Escolha a opção \$1 para adicionar todos os campos que você deseja criptografar com essa chave.  
Para o padrão do nome de campo, você pode digitar o nome inteiro do campo de dados, como DateOfBirth ou apenas a primeira parte do nome seguido por um caractere curinga (\$1), como CreditCard\$1. O padrão do nome de campo deve incluir apenas caracteres alfanuméricos, colchetes ([ e ]), pontos (.), sublinhados (\$1) e hífens (-), além do caractere opcional curinga (\$1).  
Certifique-se de que você não está usando caracteres sobrepostos para padrões diferentes de nomes de campos. Por exemplo, se você tiver o padrão de nome de campo ABC\$1, não poderá adicionar um outro padrão de nome de campo que seja AB\$1. Além disso, os nomes dos campos diferenciam maiúsculas de minúsculas, e o número máximo de caracteres que podem ser usados é 128.  
**Comentário**  
(Opcional) Digite um comentário sobre este perfil. O número máximo de caracteres que você pode usar é 128.

1. Após preencher os campos, escolha **Create profile (Criar perfil)**.

1. Se você deseja adicionar mais perfis, escolha **Add profile**.

### Etapa 4: Criar uma configuração
<a name="field-level-encryption-setting-up-step4"></a>

Depois que criar um ou mais perfis de criptografia no nível de campo, crie uma configuração para especificar o tipo de conteúdo da solicitação que inclua os dados a serem criptografados, o perfil a ser usado na criptografia e outras opções especificando como você deseja que o CloudFront processe a criptografia.

Por exemplo, quando o CloudFront não puder criptografar os dados, você poderá especificar se ele deve bloquear ou encaminhar uma solicitação para a origem nos seguintes cenários:
+ **Quando o tipo de conteúdo de uma solicitação não estiver em uma configuração**: se não tiver adicionado um tipo de conteúdo a uma configuração, você poderá especificar se o CloudFront deve encaminhar a solicitação com esse tipo de conteúdo para a origem sem criptografar os campos de dados ou bloquear a solicitação e retornar um erro.
**nota**  
Se você adicionar um tipo de conteúdo a uma configuração, mas não tiver especificado um perfil para usar com esse tipo, o CloudFront sempre encaminhará as solicitações com esse tipo de conteúdo para a origem.
+ **Quando o nome de perfil fornecido em um argumento de consulta for desconhecido**: ao especificar o argumento de consulta `fle-profile` com um nome de perfil que não existe para a distribuição, você poderá especificar se o CloudFront deve enviar a solicitação para a origem sem criptografar os campos de dados ou bloquear a solicitação e retornar um erro.

Em uma configuração, você também pode especificar se um perfil fornecido como um argumento de consulta em uma URL poderá substituir o perfil que foi mapeado para o tipo de conteúdo dessa consulta. Por padrão, o CloudFront usará o perfil que você mapeou para um tipo de conteúdo, se houver um perfil especificado. Isso permite que você tenha um perfil que é usado por padrão, mas que possa decidir, em determinadas solicitações, que deseja impor um perfil diferente.

Assim, por exemplo, é possível especificar (em sua configuração) **SampleProfile** como o perfil do argumento de consulta a ser usado. Depois, você poderá usar o URL `https://d1234.cloudfront.net?fle-profile=SampleProfile` em vez de `https://d1234.cloudfront.net`, para que o CloudFront use **SampleProfile** para essa solicitação, em vez do perfil configurado para o tipo de conteúdo da solicitação.

Você pode criar até 10 configurações para uma única conta e, em seguida, associar uma das configurações ao comportamento de cache de qualquer distribuição da conta.<a name="field-level-encryption-setting-up-step4-procedure"></a>

**Para criar uma configuração de criptografia no nível de campo (console)**

1. Na página **Field-level encryption (Criptografia de nível de campo)**, escolha **Create configuration (Criar configuração)**.

   Observação: se você não tiver criado pelo menos um perfil, não verá a opção para criar uma configuração.

1. Preencha os seguintes campos para especificar o perfil a ser usado. (Alguns campos não podem ser alterados.)  
**Tipo de conteúdo (não pode ser alterado)**  
O tipo do conteúdo é definido como `application/x-www-form-urlencoded` e não pode ser alterado.  
**ID do perfil padrão (opcional)**  
Na lista suspensa, escolha o perfil que você deseja mapear para o tipo de conteúdo no campo **Content type** (Tipo de conteúdo).  
**Formato do conteúdo (não pode ser alterado)**  
O formato do conteúdo é definido como `URLencoded` e não pode ser alterado.

1. Se quiser alterar o comportamento padrão do CloudFront para as opções a seguir, marque a caixa de seleção apropriada.  
**Encaminhar solicitação para a origem quando o tipo de conteúdo da solicitação não está configurado**  
Marque esta caixa de seleção se você quiser permitir que a solicitação vá para a origem *caso você não tenha especificado um perfil a ser usado para o tipo de conteúdo da solicitação*.  
**Substituir perfil de um tipo de conteúdo por um argumento de consulta fornecido**  
Marque esta caixa de seleção se você quiser permitir que um perfil fornecido em um argumento de consulta *substitua o perfil que você especificou para um tipo de conteúdo*.

1. Se você marcar a caixa de seleção permitindo que um argumento de consulta substitua o perfil padrão, deverá preencher os seguintes campos adicionais para a configuração. É possível criar até cinco desses mapeamentos de argumento de consulta para usar com as consultas.  
**Argumento de consulta**  
Digite o valor que deseja incluir nas URLs para o argumento de consulta `fle-profile`. Esse valor informa o CloudFront para usar o ID do perfil (que você especificará no próximo campo) associado a esse argumento de consulta para a criptografia no nível do campo para essa consulta.  
O número máximo de caracteres que você pode usar é 128. O valor não pode incluir espaços e deve usar apenas caracteres alfanuméricos, traço (-), ponto (.), sublinhado (\$1), asterisco (\$1), sinal de mais (\$1) e porcentagem (%).  
**ID do perfil**  
Na lista suspensa, escolha o perfil que deseja associar ao valor que você digitou em **Query argument** (Argumento de consulta).  
**Encaminhar solicitação para a origem quando o perfil especificado em um argumento de consulta não existe**  
Marque esta caixa de seleção se você quiser permitir que a solicitação vá para a origem *caso o perfil especificado em um argumento de consulta não esteja definido no CloudFront*.

### Etapa 5: Adicionar uma configuração ao comportamento de cache
<a name="field-level-encryption-setting-up-step5"></a>

Para usar a criptografia no nível de campo, vincule uma configuração ao comportamento de cache de uma distribuição adicionando o ID da configuração como um valor para a sua distribuição.

**Importante**  
Para vincular uma configuração de criptografia em nível de campo a um comportamento de cache, a distribuição deve ser configurada para sempre usar HTTPS e aceitar solicitações HTTP `POST` e `PUT` de visualizadores. Isso significa que:  
A opção **Viewer Protocol Policy (Política de protocolo do visualizador)** do comportamento de cache deve ser definida como **Redirect HTTP to HTTPS (Redirecionar HTTP para HTTPS)** ou **HTTPS Only (Somente HTTPS)**. (No CloudFormation ou na API do CloudFront, `ViewerProtocolPolicy` deve ser definido como `redirect-to-https` ou `https-only`.)
A opção **Allowed HTTP Methods (Métodos HTTP permitidos)** do comportamento de cache deve ser definida como **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. (No CloudFormation ou na API do CloudFront, `AllowedMethods` deve ser definido como `GET`, `HEAD`, `OPTIONS`, `PUT`, `POST`, `PATCH`, `DELETE`. É possível defini-los em qualquer ordem.)
A opção **Origin Protocol Policy (Política de protocolo de origem)** deve ser definida como **Match Viewer (Corresponder ao visualizador)** ou **HTTPS Only (Somente HTTPS)**. (No CloudFormation ou na API do CloudFront, `OriginProtocolPolicy` deve ser definido como `match-viewer` ou `https-only`.)

Para obter mais informações, consulte [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

## Descriptografar campos de dados na origem
<a name="field-level-encryption-decrypt"></a>

O CloudFront criptografa os campos de dados usando o [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html). Os dados permanecem criptografados em toda a pilha de aplicativos e podem ser acessados somente por aplicativos que tenham as credenciais necessárias para descriptografá-los.

Após a criptografia, o texto cifrado é codificado em base64. Quando as suas aplicações descriptografam o texto na origem, elas primeiro devem decodificar o texto cifrado e, em seguida, usar o SDK de criptografia da AWS para descriptografar os dados.

O exemplo de código a seguir ilustra como os aplicativos podem descriptografar dados na origem. Observe o seguinte: 
+ Para simplificar, este exemplo carrega chaves públicas e privadas (em formato DER) a partir de arquivos do diretório de trabalho. Na prática, você pode armazenar a chave privada em um local offline seguro, como um módulo de segurança de hardware offline, e distribuir a chave pública para a equipe de desenvolvimento.
+ O CloudFront usa informações específicas ao criptografar os dados, e o mesmo conjunto de parâmetros deve ser usado na origem para descriptografá-los. Os parâmetros que o CloudFront usa ao inicializar a MasterKey incluem:
  + PROVIDER\$1NAME: você especificou esse valor quando criou um perfil de criptografia no nível de campo. Use o mesmo valor aqui.
  + KEY\$1NAME: você criou um nome para sua chave pública quando fez upload para o CloudFront e especificou o nome da chave no perfil. Use o mesmo valor aqui.
  + ALGORITMO: o CloudFront usa `RSA/ECB/OAEPWithSHA-256AndMGF1Padding` como o algoritmo para criptografia e, portanto, o mesmo algoritmo deve ser usado para descriptografar os dados.
+ Se você executar o seguinte programa de exemplo com um texto cifrado como entrada, a saída dos dados descriptografados será exibida em seu console. Para obter mais informações, consulte o [Código de exemplo em Java](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html) no SDK de criptografia da AWS.

### Código de exemplo
<a name="field-level-encryption-decrypt-sample"></a>

```
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;

import org.apache.commons.codec.binary.Base64;

import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoResult;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;

/**
 * Sample example of decrypting data that has been encrypted by CloudFront field-level encryption.
 */
public class DecryptExample {

    private static final String PRIVATE_KEY_FILENAME = "private_key.der";
    private static final String PUBLIC_KEY_FILENAME = "public_key.der";
    private static PublicKey publicKey;
    private static PrivateKey privateKey;

    // CloudFront uses the following values to encrypt data, and your origin must use same values to decrypt it.
    // In your own code, for PROVIDER_NAME, use the provider name that you specified when you created your field-level
    // encryption profile. This sample uses 'DEMO' for the value.
    private static final String PROVIDER_NAME = "DEMO";
    // In your own code, use the key name that you specified when you added your public key to CloudFront. This sample
    // uses 'DEMOKEY' for the key name.
    private static final String KEY_NAME = "DEMOKEY";
    // CloudFront uses this algorithm when encrypting data.
    private static final String ALGORITHM = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding";

    public static void main(final String[] args) throws Exception {

        final String dataToDecrypt = args[0];

        // This sample uses files to get public and private keys.
        // In practice, you should distribute the public key and save the private key in secure storage.
        populateKeyPair();

        System.out.println(decrypt(debase64(dataToDecrypt)));
    }

    private static String decrypt(final byte[] bytesToDecrypt) throws Exception {
        // You can decrypt the stream only by using the private key.

        // 1. Instantiate the SDK
        final AwsCrypto crypto = new AwsCrypto();

        // 2. Instantiate a JCE master key
        final JceMasterKey masterKey = JceMasterKey.getInstance(
                publicKey,
                privateKey,
                PROVIDER_NAME,
                KEY_NAME,
                ALGORITHM);

        // 3. Decrypt the data
        final CryptoResult <byte[], ? > result = crypto.decryptData(masterKey, bytesToDecrypt);
        return new String(result.getResult());
    }

    // Function to decode base64 cipher text.
    private static byte[] debase64(final String value) {
        return Base64.decodeBase64(value.getBytes());
    }

    private static void populateKeyPair() throws Exception {
        final byte[] PublicKeyBytes = Files.readAllBytes(Paths.get(PUBLIC_KEY_FILENAME));
        final byte[] privateKeyBytes = Files.readAllBytes(Paths.get(PRIVATE_KEY_FILENAME));
        publicKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(PublicKeyBytes));
        privateKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(privateKeyBytes));
    }
}
```