Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Configuration d’un accès sécurisé et restriction de l’accès au contenu
<a name="SecurityAndPrivateContent"></a>

CloudFront propose plusieurs options pour sécuriser le contenu qu'il diffuse. Vous pouvez utiliser les méthodes suivantes CloudFront pour sécuriser et restreindre l'accès au contenu :
+ Configurer les connexions HTTPS.
+ Empêcher les utilisateurs situés dans des points géographiques spécifiques d’accéder au contenu
+ Obliger les utilisateurs à accéder au contenu à l'aide de cookies CloudFront signés URLs ou signés
+ Configurer le chiffrement au niveau du champ pour des champs de contenu spécifiques
+  AWS WAF À utiliser pour contrôler l'accès à votre contenu

Vous devez également implémenter une architecture DDo résiliente aux S pour votre infrastructure et vos applications. Pour plus d'informations, consultez la section [AWS Meilleures pratiques en matière de résilience DDo S.](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html)

Pour plus d'informations, consultez les éléments suivants :
+ [Sécurisez la diffusion de votre contenu avec CloudFront](https://aws.amazon.com/cloudfront/security/)
+ [SIEM sur Amazon Service OpenSearch ](https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README.md)

**Topics**
+ [Utilisez le protocole HTTPS avec CloudFront](using-https.md)
+ [Utilisation de noms de domaines alternatifs et HTTPS](using-https-alternate-domain-names.md)
+ [Authentification TLS mutuelle avec CloudFront (Viewer MTLS)](mtls-authentication.md)
+ [Origin Mutual TLS avec CloudFront](origin-mtls-authentication.md)
+ [Diffusez du contenu privé avec des cookies signés URLs et signés](PrivateContent.md)
+ [Restreindre l'accès à une AWS origine](private-content-restricting-access-to-origin.md)
+ [Restriction de l’accès aux Application Load Balancers](restrict-access-to-load-balancer.md)
+ [Restriction de la distribution géographique de votre contenu](georestrictions.md)
+ [Utilisation du chiffrement au niveau du champ pour faciliter la protection des données sensibles](field-level-encryption.md)

# Utilisez le protocole HTTPS avec CloudFront
<a name="using-https"></a>

Vous pouvez configurer CloudFront pour obliger les utilisateurs à utiliser le protocole HTTPS afin que les connexions soient chiffrées lors des CloudFront communications avec les spectateurs. Vous pouvez également CloudFront configurer l'utilisation du protocole HTTPS avec votre origine afin que les connexions soient cryptées lorsque CloudFront vous communiquez avec votre origine.

Si vous configurez CloudFront pour exiger le protocole HTTPS à la fois pour communiquer avec les spectateurs et pour communiquer avec votre origine, voici ce qui se passe lorsque CloudFront vous recevez une demande :

1. Un utilisateur envoie une demande HTTPS à CloudFront. Il y a une SSL/TLS négociation ici entre le spectateur et CloudFront. La visionneuse finit par envoyer la requête dans un format chiffré.

1. Si l'emplacement CloudFront périphérique contient une réponse mise en cache, CloudFront chiffre la réponse et la renvoie au visualiseur, qui la déchiffre.

1. Si l'emplacement CloudFront périphérique ne contient pas de réponse mise en cache, CloudFront effectue une négociation SSL/TLS avec votre origine et, une fois la négociation terminée, transmet la demande à votre origine dans un format crypté.

1. Votre origine déchiffre la demande, la traite (génère une réponse), chiffre la réponse et renvoie la réponse à. CloudFront

1. CloudFront déchiffre la réponse, la chiffre à nouveau et la transmet au lecteur. CloudFrontmet également en cache la réponse dans l'emplacement périphérique afin qu'elle soit disponible la prochaine fois qu'elle sera demandée.

1. La visionneuse déchiffre la réponse.

Le processus fonctionne essentiellement de la même manière, MediaStore que votre origine soit un compartiment Amazon S3 ou une origine personnalisée telle qu'un serveur HTTP/S.

**Note**  
Pour aider à contrecarrer les attaques de type renégociation SSL, CloudFront ne prend pas en charge la renégociation pour les demandes du destinataire et de l'origine.

Vous pouvez également activer l'authentification mutuelle pour votre CloudFront distribution. Pour de plus amples informations, veuillez consulter [Authentification TLS mutuelle avec CloudFront (Viewer MTLS)Origin Mutual TLS avec CloudFront](mtls-authentication.md).

Pour savoir comment exiger le protocole HTTPS entre les utilisateurs et CloudFront, entre CloudFront et votre origine, consultez les rubriques suivantes.

**Topics**
+ [Exiger le protocole HTTPS entre les spectateurs et CloudFront](using-https-viewers-to-cloudfront.md)
+ [Exigence du protocole HTTPS vers une origine personnalisée](using-https-cloudfront-to-custom-origin.md)
+ [Exigence du protocole HTTPS vers une origine Amazon S3](using-https-cloudfront-to-s3-origin.md)
+ [Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
+ [Protocoles et chiffrements pris en charge entre CloudFront et l'origine](secure-connections-supported-ciphers-cloudfront-to-origin.md)

# Exiger le protocole HTTPS pour la communication entre les spectateurs et CloudFront
<a name="using-https-viewers-to-cloudfront"></a>

Vous pouvez configurer un ou plusieurs comportements de cache dans votre CloudFront distribution afin d'exiger le protocole HTTPS pour la communication entre les utilisateurs et CloudFront. Vous pouvez également configurer un ou plusieurs comportements de cache pour autoriser à la fois le HTTP et le HTTPS, ce qui CloudFront nécessite le protocole HTTPS pour certains objets mais pas pour d'autres. Les étapes de configuration dépendent du nom de domaine que vous utilisez dans l'objet URLs :
+ Si vous utilisez le nom de domaine CloudFront attribué à votre distribution, tel que d111111abcdef8.cloudfront.net, vous modifiez le paramètre **Viewer Protocol Policy** pour un ou plusieurs comportements de cache afin d'exiger une communication HTTPS. Dans cette configuration, CloudFront fournit le SSL/TLS certificat. 

  Pour modifier la valeur de **Viewer Protocol Policy** à l'aide de la CloudFront console, reportez-vous à la procédure décrite plus loin dans cette section.

  Pour plus d'informations sur l'utilisation de l' CloudFront API pour modifier la valeur de l'`ViewerProtocolPolicy`élément, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
+ Si vous utilisez votre propre nom de domaine, comme example.com, vous devez modifier plusieurs paramètres CloudFront. Vous devez également utiliser un SSL/TLS certificat fourni par AWS Certificate Manager (ACM) ou importer un certificat d'une autorité de certification tierce dans ACM ou dans le magasin de certificats IAM. Pour de plus amples informations, veuillez consulter [Utilisation de noms de domaines alternatifs et HTTPS](using-https-alternate-domain-names.md).

**Note**  
Si vous voulez vous assurer que les objets que les spectateurs obtiennent CloudFront étaient chiffrés lorsqu'ils CloudFront sont arrivés de chez vous, utilisez toujours le protocole HTTPS entre CloudFront et votre origine. Si vous êtes récemment passé du protocole HTTP au protocole HTTPS entre CloudFront et votre origine, nous vous recommandons d'invalider les objets situés dans des emplacements CloudFront périphériques. CloudFront renverra un objet à un visualiseur, que le protocole utilisé par le visualiseur (HTTP ou HTTPS) corresponde ou non au protocole CloudFront utilisé pour obtenir l'objet. Pour plus d'informations sur la suppression ou le remplacement des objets dans une distribution, consultez [Ajouter, supprimer ou remplacer du contenu CloudFront diffusé](AddRemoveReplaceObjects.md).

## Exigence du protocole HTTPS pour les utilisateurs
<a name="configure-cloudfront-HTTPS-viewers"></a>

Pour exiger le protocole HTTPS entre les utilisateurs et CloudFront pour un ou plusieurs comportements de cache, effectuez la procédure suivante.<a name="using-https-viewers-to-cloudfront-procedure"></a>

**Pour configurer CloudFront afin d'exiger le protocole HTTPS entre les spectateurs et CloudFront**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet supérieur de la CloudFront console, choisissez l'ID de la distribution que vous souhaitez mettre à jour.

1. Dans l’onglet **Comportements**, choisissez le comportement de cache à mettre à jour, puis sélectionnez **Modifier**.

1. Spécifiez l’une des valeurs suivantes pour **Politique de protocole d’utilisateur** :  
**Redirect HTTP to HTTPS**  
Les visionneuses peuvent utiliser les deux protocoles. Le HTTP `GET` et les `HEAD` requêtes sont automatiquement redirigés vers les requêtes HTTPS. CloudFront renvoie le code d'état HTTP 301 (déplacé définitivement) ainsi que la nouvelle URL HTTPS. Le téléspectateur soumet ensuite à nouveau la demande à CloudFront l'aide de l'URL HTTPS.  
Si vous envoyez`POST`,`PUT`, `DELETE``OPTIONS`, ou `PATCH` via HTTP avec un comportement de cache HTTP vers HTTPS et une version du protocole de requête HTTP 1.1 ou supérieure, CloudFront redirige la demande vers un emplacement HTTPS avec un code d'état HTTP 307 (redirection temporaire). Cette approche garantit le nouvel envoi de la demande vers le nouvel emplacement à l'aide de la même méthode et de la même charge utile du corps.  
Si vous envoyez`POST`, `PUT` `DELETE``OPTIONS`, ou des `PATCH` requêtes via HTTP vers HTTPS, le comportement du cache avec une version du protocole de requête inférieure à HTTP 1.1 CloudFront renvoie un code d'état HTTP 403 (interdit).
Quand un utilisateur émet une requête HTTP redirigée vers une requête HTTPS, CloudFront perçoit des frais pour les deux requêtes. Pour la requête HTTP, les frais concernent uniquement la demande et les en-têtes CloudFront renvoyés au lecteur. Pour la requête HTTPS, le montant correspond à la requête ainsi qu'aux en-têtes et à l'objet renvoyés par votre origine.  
**HTTPS Only**  
Les visionneuses ne peuvent accéder au contenu que si elles utilisent le protocole HTTPS. Si un utilisateur envoie une requête HTTP au lieu d'une requête HTTPS, il CloudFront renvoie le code d'état HTTP 403 (Interdit) et ne renvoie pas l'objet.

1. Sélectionnez **Enregistrer les modifications**.

1. Répétez les étapes 3 à 5 pour chaque comportement de cache supplémentaire pour lequel vous souhaitez exiger le protocole HTTPS entre les utilisateurs et CloudFront.

1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
   + Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
   + Les comportements du cache sont répertoriés dans l'ordre dans lequel vous CloudFront souhaitez les évaluer. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Les comportements de cache acheminent les requêtes vers les origines correctes. 

# Exigez le protocole HTTPS pour la communication entre CloudFront et votre origine personnalisée
<a name="using-https-cloudfront-to-custom-origin"></a>

Vous pouvez exiger le protocole HTTPS pour la communication entre CloudFront et votre origine.

**Note**  
Si votre origine est un compartiment Amazon S3 configuré comme point de terminaison de site Web, vous ne pouvez pas le configurer CloudFront pour utiliser le protocole HTTPS avec votre origine, car Amazon S3 ne prend pas en charge le protocole HTTPS pour les points de terminaison de sites Web.

Pour exiger le protocole HTTPS entre CloudFront et votre origine, suivez les procédures décrites dans cette rubrique pour effectuer les opérations suivantes :

1. Dans votre distribution, modifiez le paramètre **Stratégie de protocole d'origine** pour l'origine.

1. Installez un SSL/TLS certificat sur votre serveur d'origine (cela n'est pas obligatoire lorsque vous utilisez une origine Amazon S3 ou certaines autres AWS origines).

**Topics**
+ [Exigence du protocole HTTPS pour les origines personnalisées](#using-https-cloudfront-to-origin-distribution-setting)
+ [Installez un SSL/TLS certificat sur votre origine personnalisée](#using-https-cloudfront-to-origin-certificate)

## Exigence du protocole HTTPS pour les origines personnalisées
<a name="using-https-cloudfront-to-origin-distribution-setting"></a>

La procédure suivante explique comment configurer l'utilisation du protocole HTTPS CloudFront pour communiquer avec un équilibreur de charge Elastic Load Balancing, une instance Amazon EC2 ou une autre origine personnalisée. Pour plus d'informations sur l'utilisation de l' CloudFront API pour mettre à jour une distribution, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*. <a name="using-https-cloudfront-to-custom-origin-procedure"></a>

**Pour configurer CloudFront afin d'exiger le protocole HTTPS entre CloudFront et votre origine personnalisée**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet supérieur de la CloudFront console, choisissez l'ID de la distribution que vous souhaitez mettre à jour.

1. Dans l’onglet **Comportements**, sélectionnez l’origine à mettre à jour, puis choisissez **Modifier**.

1. Modifiez les paramètres suivants :  
**Origin Protocol Policy**  
Modifiez le paramètre **Stratégie de protocole d'origine** pour les origines concernées de votre distribution :  
   + **HTTPS uniquement** : CloudFront utilise uniquement le protocole HTTPS pour communiquer avec votre origine personnalisée.
   + **Match Viewer** : CloudFront communique avec votre origine personnalisée via HTTP ou HTTPS, selon le protocole de la demande du spectateur. Par exemple, si vous choisissez **Match Viewer** for **Origin Protocol Policy** et que le lecteur utilise le protocole HTTPS pour demander un objet CloudFront, il utilise CloudFront également le protocole HTTPS pour transférer la demande à votre source.

     Ne sélectionnez **Identique à l’utilisateur** que si vous affectez la valeur **Rediriger HTTP vers HTTPS** ou **HTTPS uniquement** au paramètre **Stratégie de protocole d’utilisateur**.

     CloudFront ne met en cache l'objet qu'une seule fois, même si les utilisateurs font des demandes à l'aide des protocoles HTTP et HTTPS.  
**Origin SSL Protocols**  
Choisissez les **Protocoles SSL d'origine** pour les origines concernées de votre distribution. Le SSLv3 protocole étant moins sécurisé, nous vous recommandons de choisir SSLv3 uniquement si votre origine ne le prend pas en charge TLSv1 ou plus tard. La TLSv1 poignée de main est à la fois rétrocompatible avec la version 1 et les versions ultérieures SSLv3, mais pas avec la version TLSv1 .1 et les versions ultérieures. Lorsque vous le souhaitez SSLv3, envoie CloudFront *uniquement* des demandes de SSLv3 poignée de main.

1. Sélectionnez **Enregistrer les modifications**.

1. Répétez les étapes 3 à 5 pour chaque origine supplémentaire pour laquelle vous souhaitez exiger le protocole HTTPS entre CloudFront et votre origine personnalisée.

1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
   + Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
   + Les comportements du cache sont répertoriés dans l'ordre dans lequel vous CloudFront souhaitez les évaluer. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Les comportements de cache acheminent les requêtes vers les origines pour lesquelles vous avez modifié le paramètre **Stratégie de protocole d'origine**. 

## Installez un SSL/TLS certificat sur votre origine personnalisée
<a name="using-https-cloudfront-to-origin-certificate"></a>

Vous pouvez utiliser un SSL/TLS certificat provenant des sources suivantes sur votre origine personnalisée :
+ Si votre origine est un équilibreur de charge Elastic Load Balancing, vous pouvez utiliser un certificat fourni par AWS Certificate Manager (ACM). Vous pouvez également utiliser un certificat signé par une autorité de certification tierce reconnue et importé dans ACM.
+ Pour les origines autres que les équilibreurs de charge Elastic Load Balancing, vous devez utiliser un certificat signé par une autorité de certification (CA) tierce de confiance, par exemple Comodo ou DigiCert Symantec.

Le certificat renvoyé depuis l'origine doit comprendre l'un des noms de domaine suivants :
+ Le nom de domaine dans le champ du **domaine Origin** de l'origine (le `DomainName` champ de l' CloudFront API).
+ Nom du domaine dans l’en-tête `Host`, si le comportement du cache est configuré pour transférer l'en-tête `Host` de l'origine.

Lorsque CloudFront vous utilisez le protocole HTTPS pour communiquer avec votre origine, CloudFront vérifie que le certificat a été émis par une autorité de certification fiable. CloudFront supporte les mêmes autorités de certification que Mozilla. Pour obtenir la liste actuelle, consultez [Liste des certificats CA inclus dans Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). Vous ne pouvez pas utiliser de certificat auto-signé pour les communications HTTPS entre CloudFront et votre origine.

**Important**  
Si le serveur d'origine renvoie un certificat expiré, un certificat non valide ou un certificat auto-signé, ou s'il renvoie la chaîne de certificats dans le mauvais ordre, CloudFront abandonne la connexion TCP, renvoie le code d'état HTTP 502 (Bad Gateway) au visualiseur et définit l'`X-Cache`en-tête sur. `Error from cloudfront` De même, si la chaîne complète de certificats, y compris le certificat intermédiaire, n'est pas présente, CloudFront supprime la connexion TCP.

# Exiger le protocole HTTPS pour la communication entre votre Amazon S3 CloudFront et votre point d'origine
<a name="using-https-cloudfront-to-s3-origin"></a>

Lorsque votre origine est un compartiment Amazon S3, les options d'utilisation du protocole HTTPS pour les communications avec ce CloudFront dernier dépendent de la manière dont vous utilisez le compartiment. Si votre compartiment Amazon S3 est configuré comme point de terminaison de site Web, vous ne pouvez pas le configurer CloudFront pour utiliser le protocole HTTPS pour communiquer avec votre origine, car Amazon S3 ne prend pas en charge les connexions HTTPS dans cette configuration.

Lorsque votre origine est un compartiment Amazon S3 qui prend en charge les communications HTTPS, CloudFront transmet les demandes à S3 en utilisant le protocole utilisé par les utilisateurs pour envoyer les demandes. La valeur par défaut du paramètre [Protocole (origines personnalisées uniquement)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) est **Identique à l’utilisateur** et elle ne peut pas être modifiée. Toutefois, si vous activez le contrôle d'accès à l'origine (OAC) pour votre origine Amazon S3, la communication utilisée entre Amazon S3 CloudFront et Amazon S3 dépend de vos paramètres. Pour de plus amples informations, veuillez consulter [Création d’un nouveau contrôle d’accès d’origine](private-content-restricting-access-to-s3.md#create-oac-overview-s3).

Si vous souhaitez exiger le protocole HTTPS pour les communications entre Amazon S3 CloudFront et Amazon S3, vous devez modifier la valeur de **Viewer Protocol Policy** pour **rediriger le HTTP vers HTTPS** ou **HTTPS uniquement**. La procédure décrite plus loin dans cette section explique comment utiliser la CloudFront console pour modifier la **politique du protocole Viewer**. Pour plus d'informations sur l'utilisation de l' CloudFront API pour mettre à jour l'`ViewerProtocolPolicy`élément d'une distribution, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*. 

Lorsque vous utilisez le protocole HTTPS avec un compartiment Amazon S3 qui prend en charge la communication HTTPS, Amazon S3 fournit le SSL/TLS certificat, vous n'avez donc pas à le faire.

## Exigence du protocole HTTPS pour une origine Amazon S3
<a name="configure-cloudfront-HTTPS-S3-origin"></a>

La procédure suivante explique comment configurer CloudFront pour exiger le protocole HTTPS sur votre origine Amazon S3.<a name="using-https-cloudfront-to-s3-origin-procedure"></a>

**Pour configurer CloudFront afin d'exiger le protocole HTTPS pour votre origine Amazon S3**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet supérieur de la CloudFront console, choisissez l'ID de la distribution que vous souhaitez mettre à jour.

1. Sous l’onglet **Comportements**, choisissez le comportement de cache à mettre à jour, puis cliquez sur **Modifier**.

1. Spécifiez l’une des valeurs suivantes pour **Politique de protocole d’utilisateur** :  
**Redirect HTTP to HTTPS**  
Les utilisateurs peuvent utiliser les deux protocoles, mais les requêtes HTTP sont automatiquement redirigées vers les requêtes HTTPS. CloudFront renvoie le code d'état HTTP 301 (déplacé définitivement) ainsi que la nouvelle URL HTTPS. Le téléspectateur soumet ensuite à nouveau la demande à CloudFront l'aide de l'URL HTTPS.  
CloudFront ne redirige pas `DELETE``OPTIONS`,`PATCH`,`POST`, ou les `PUT` requêtes de HTTP vers HTTPS. Si vous configurez un comportement de cache pour rediriger vers HTTPS, vous CloudFront répondez au HTTP`DELETE`,`OPTIONS`, `PATCH``POST`, ou aux `PUT` demandes relatives à ce comportement de cache avec le code d'état HTTP 403 (Interdit).
Quand un utilisateur émet une requête HTTP redirigée vers une requête HTTPS, CloudFront perçoit des frais pour les deux requêtes. Pour la requête HTTP, les frais concernent uniquement la demande et les en-têtes CloudFront renvoyés au lecteur. Pour la requête HTTPS, le montant correspond à la requête ainsi qu'aux en-têtes et à l'objet renvoyés par votre origine.  
**HTTPS Only**  
Les visionneuses ne peuvent accéder au contenu que si elles utilisent le protocole HTTPS. Si un utilisateur envoie une requête HTTP au lieu d'une requête HTTPS, il CloudFront renvoie le code d'état HTTP 403 (Interdit) et ne renvoie pas l'objet.

1. Choisissez **Oui, Modifier**.

1. Répétez les étapes 3 à 5 pour chaque comportement de cache supplémentaire pour lequel vous souhaitez exiger le protocole HTTPS entre les utilisateurs et CloudFront entre CloudFront et S3.

1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
   + Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
   + Les comportements du cache sont répertoriés dans l'ordre dans lequel vous CloudFront souhaitez les évaluer. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Les comportements de cache acheminent les requêtes vers les origines correctes. 

# Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront
<a name="secure-connections-supported-viewer-protocols-ciphers"></a>

Lorsque vous avez [besoin du protocole HTTPS entre les spectateurs et votre CloudFront distribution](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), vous devez choisir une [politique de sécurité](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) qui détermine les paramètres suivants :
+  SSL/TLS Protocole minimal CloudFront utilisé pour communiquer avec les spectateurs.
+ Les chiffrements qui CloudFront peuvent être utilisés pour chiffrer la communication avec les spectateurs.

Pour choisir une stratégie de sécurité, spécifiez la valeur applicable pour [Politique de sécurité ( SSL/TLS version minimale)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy). Le tableau suivant répertorie les protocoles et les chiffrements qui CloudFront peuvent être utilisés pour chaque politique de sécurité.

Un utilisateur doit prendre en charge au moins l'un des chiffrements pris en charge pour établir une connexion HTTPS avec. CloudFront CloudFront choisit un chiffre dans l'ordre indiqué parmi les chiffrements pris en charge par le lecteur. Consultez également [Noms de chiffrement OpenSSL, s2n et RFC](#secure-connections-openssl-rfc-cipher-names).


|  | Politique de sécurité |  | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv11.1\$12016 | TLSv12.2\$12018 | TLSv12.2\$12019 | TLSv12.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
|  SSL/TLS Protocoles pris en charge | 
| TLSv13. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLSv12. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| TLSv11. | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLSv1 | ♦ | ♦ | ♦ |  |  |  |  |  |  | 
| SSLv3 | ♦ |  |  |  |  |  |  |  |  | 
| Chiffrements TLSv1 1.3 pris en charge | 
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | ♦ | 
| Chiffrements ECDSA pris en charge | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-ECDSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| Chiffrements RSA pris en charge | 
| ECDHE-RSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-RSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-RSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-GCM- SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| CBC3DES-SHA | ♦ | ♦ |  |  |  |  |  |  |  | 
| RC4-MD5 | ♦ |  |  |  |  |  |  |  |  | 

## Noms de chiffrement OpenSSL, s2n et RFC
<a name="secure-connections-openssl-rfc-cipher-names"></a>

OpenSSL et [s2n](https://github.com/awslabs/s2n) utilisent des noms de chiffrement différents de ceux utilisés par les standards TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), et [RFC 8446](https://tools.ietf.org/html/rfc8446)). Le tableau suivant met en correspondance les noms OpenSSL et s2n avec le nom RFC pour chaque chiffrement.

CloudFront prend en charge les échanges de clés classiques et quantiques. Pour les échanges de clés classiques utilisant des courbes elliptiques, CloudFront prend en charge les éléments suivants :
+ `prime256v1`
+ `X25519`
+ `secp384r1`

Pour les échanges de clés sécurisés quantiques, prend en CloudFront charge les éléments suivants :
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**Note**  
Les échanges de clés sécurisés quantiques ne sont pris en charge qu'avec TLS 1.3. TLS 1.2 et les versions antérieures ne prennent pas en charge les échanges de clés sécurisés quantiques.

  Pour plus d’informations, consultez les rubriques suivantes :
  + [Cryptographie post-quantique](https://aws.amazon.com/security/post-quantum-cryptography/)
  + [Algorithmes de cryptographie et Services AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
  + [Échange de clés hybride dans TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)

Pour plus d'informations sur les exigences en matière de certificats pour CloudFront, consultez[Exigences relatives à l'utilisation de SSL/TLS certificats avec CloudFront](cnames-and-https-requirements.md).


| Nom de chiffrement OpenSSL et s2n | Nom de chiffrement RFC | 
| --- | --- | 
| Chiffrements TLSv1 1.3 pris en charge | 
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | TLS\$1AES\$1128\$1GCM\$1 SHA256 | 
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | TLS\$1AES\$1256\$1GCM\$1 SHA384 | 
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | 
| Chiffrements ECDSA pris en charge | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1AVEC\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-ECDSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1ECDSA\$1AVEC\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | 
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| Chiffrements RSA pris en charge | 
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256  | 
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384  | 
| ECDHE-RSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1RSA\$1AVEC\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | 
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384  | 
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-GCM- SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| AES256-GCM- SHA384 | TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| AES128-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| CBC3DES-SHA  | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA  | 
| RC4-MD5 | TLS\$1RSA\$1AVEC\$1 \$1128\$1 RC4 MD5 | 

## Schémas de signature pris en charge entre les spectateurs et CloudFront
<a name="secure-connections-viewer-signature-schemes"></a>

CloudFront prend en charge les schémas de signature suivants pour les connexions entre les spectateurs etCloudFront.


|  | Politique de sécurité | Schémas de signature | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv11.1\$12016 | TLSv12.2\$12018 | TLSv12.2\$12019 |  TLSv12.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1R1\$1 SECP256 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1R1\$1 SECP384 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 

# Protocoles et chiffrements pris en charge entre CloudFront et l'origine
<a name="secure-connections-supported-ciphers-cloudfront-to-origin"></a>

Si vous choisissez d'[exiger le protocole HTTPS entre CloudFront et votre origine](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy), vous pouvez décider [quel SSL/TLS protocole autoriser](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) la connexion sécurisée, et vous CloudFront pouvez vous connecter à l'origine à l'aide de l'un des chiffrements ECDSA ou RSA répertoriés dans le tableau suivant. Votre origine doit prendre en charge au moins un de ces chiffrements pour CloudFront établir une connexion HTTPS avec votre origine.

OpenSSL et [s2n](https://github.com/awslabs/s2n) utilisent des noms de chiffrement différents de ceux utilisés par les standards TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), et [RFC 8446](https://tools.ietf.org/html/rfc8446)). Le tableau suivant inclut les noms OpenSSL et s2n avec le nom RFC pour chaque chiffrement.

Pour les chiffrements utilisant des algorithmes d'échange de clés à courbe elliptique, CloudFront prend en charge les courbes elliptiques suivantes :
+ prime256v1
+ secp384r1
+ X25519


| Nom de chiffrement OpenSSL et s2n | Nom de chiffrement RFC | 
| --- | --- | 
| Chiffrements ECDSA pris en charge | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1AVEC\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| Chiffrements RSA pris en charge | 
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-RSA- -SHA AES128 | 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 | 
| CBC3DES-SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA | 
| RC4-MD5 | TLS\$1RSA\$1AVEC\$1 \$1128\$1 RC4 MD5 | 

**Schémas de signature pris en charge entre CloudFront et l'origine**

CloudFront prend en charge les schémas de signature suivants pour les connexions entre CloudFront et l'origine.
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA256
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA384
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA512
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA224
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA256
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA384
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA512
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA224
+ SCHÉMA DE SIGNATURE TLS\$1RSA\$1 \$1 PKCS1 SHA1
+ SCHÉMA DE SIGNATURE TLS\$1ECDSA\$1 SHA1

# Utilisation de noms de domaines alternatifs et HTTPS
<a name="using-https-alternate-domain-names"></a>

Si vous souhaitez utiliser votre propre nom de domaine URLs pour vos fichiers (par exemple,`https://www.example.com/image.jpg`) et que vous souhaitez que vos lecteurs utilisent le protocole HTTPS, vous devez suivre les étapes décrites dans les rubriques suivantes. (Si vous utilisez le nom de domaine de CloudFront distribution par défaut dans votre URLs, par exemple`https://d111111abcdef8.cloudfront.net/image.jpg`, suivez plutôt les instructions de la rubrique suivante :[Exiger le protocole HTTPS pour la communication entre les spectateurs et CloudFront](using-https-viewers-to-cloudfront.md).)

**Important**  
Lorsque vous ajoutez un certificat à votre distribution, le certificat est CloudFront immédiatement propagé à tous ses emplacements périphériques. Tandis que de nouveaux emplacements périphériques deviennent disponibles, CloudFront leur transmet également le certificat. Vous ne pouvez pas restreindre les emplacements périphériques vers lesquels les certificats sont CloudFront propagés.

**Topics**
+ [Choisissez le mode de CloudFront traitement des requêtes HTTPS](cnames-https-dedicated-ip-or-sni.md)
+ [Exigences relatives à l'utilisation de SSL/TLS certificats avec CloudFront](cnames-and-https-requirements.md)
+ [Quotas d'utilisation des SSL/TLS certificats avec CloudFront (HTTPS entre utilisateurs et CloudFront uniquement)](cnames-and-https-limits.md)
+ [Configuration de noms de domaines alternatifs et HTTPS](cnames-and-https-procedures.md)
+ [Déterminer la taille de la clé publique dans un certificat SSL/TLS RSA](cnames-and-https-size-of-public-key.md)
+ [Augmenter les quotas de SSL/TLS certificats](increasing-the-limit-for-ssl-tls-certificates.md)
+ [Rotation SSL/TLS des certificats](cnames-and-https-rotate-certificates.md)
+ [Revenir d'un SSL/TLS certificat personnalisé au certificat par défaut CloudFront](cnames-and-https-revert-to-cf-certificate.md)
+ [Passez d'un SSL/TLS certificat personnalisé avec adresses IP dédiées à un certificat SNI](cnames-and-https-switch-dedicated-to-sni.md)

# Choisissez le mode de CloudFront traitement des requêtes HTTPS
<a name="cnames-https-dedicated-ip-or-sni"></a>

Si vous souhaitez que vos utilisateurs utilisent le protocole HTTPS et utilisent des noms de domaine alternatifs pour vos fichiers, choisissez l'une des options suivantes pour le traitement CloudFront des requêtes HTTPS :
+ Utilisation de [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) – recommandée
+ Utilisez une adresse IP dédiée dans chaque emplacement périphérique

Cette section explique le mode de fonctionnement de chaque option.

## Utilisation d’une extension SNI pour traiter les demandes HTTPS (fonctionne pour la plupart des clients)
<a name="cnames-https-sni"></a>

[Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) est une extension du protocole TLS prise en charge par les navigateurs et les clients lancés après 2010. Si vous configurez CloudFront pour répondre aux demandes HTTPS à l'aide du SNI, CloudFront associez votre nom de domaine alternatif à une adresse IP pour chaque emplacement périphérique. Lorsqu’un utilisateur envoie une demande HTTPS pour votre contenu, DNS achemine la demande vers l’adresse IP de l’emplacement périphérique correct. L'adresse IP de votre nom de domaine est déterminée lors de la négociation de la SSL/TLS poignée de main ; l'adresse IP n'est pas dédiée à votre distribution.

La SSL/TLS négociation a lieu au début du processus d'établissement d'une connexion HTTPS. S'il n'est pas CloudFront possible de déterminer immédiatement à quel domaine la demande est destinée, la connexion est interrompue. Lorsqu’une visionneuse prenant en charge SNI envoie une requête HTTPS pour obtenir votre contenu, voici ce qui se passe :

1. L’utilisateur récupère automatiquement le nom de domaine à partir de l’URL de la demande et l’ajoute à l’extension SNI du message TLS client hello.

1. Lorsqu'il CloudFront reçoit le client TLS hello, il utilise le nom de domaine de l'extension SNI pour trouver la CloudFront distribution correspondante et renvoie le certificat TLS associé.

1. Le spectateur et les CloudFront SSL/TLS négociateurs.

1. CloudFront renvoie le contenu demandé au spectateur.

Pour une liste actuelle des navigateurs qui prennent en charge l’extension SNI, consultez l’entrée [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication) de Wikipedia.

Si vous souhaitez utiliser l’extension SNI mais que certains navigateurs de vos utilisateurs ne la prennent pas en charge, vous disposez des solutions suivantes :
+ Configurez CloudFront pour répondre aux requêtes HTTPS en utilisant des adresses IP dédiées au lieu du SNI. Pour de plus amples informations, veuillez consulter [Utilisation d’une adresse IP dédiée pour traiter les demandes HTTPS (fonctionne pour tous les clients)](#cnames-https-dedicated-ip).
+ Utilisez le certificat CloudFront SSL/TLS au lieu d'un certificat personnalisé. Cela nécessite que vous utilisiez le nom de CloudFront domaine de votre distribution dans celui URLs de vos fichiers, par exemple,`https://d111111abcdef8.cloudfront.net/logo.png`.

  Si vous utilisez le CloudFront certificat par défaut, les utilisateurs doivent prendre en charge le protocole SSL TLSv1 ou une version ultérieure. CloudFront n'est pas compatible SSLv3 avec le CloudFront certificat par défaut.

  Vous devez également remplacer le SSL/TLS certificat CloudFront utilisé par le certificat personnalisé par le CloudFront certificat par défaut :
  + Si vous n’avez pas utilisé votre distribution pour transmettre votre contenu, vous pouvez juste modifier la configuration. Pour de plus amples informations, veuillez consulter [Mettre à jour une distribution](HowToUpdateDistribution.md).
  + Si vous avez utilisé votre distribution pour distribuer votre contenu, vous devez créer une nouvelle CloudFront distribution et modifier la URLs distribution de vos fichiers afin de réduire ou d'éliminer le temps pendant lequel votre contenu n'est pas disponible. Pour de plus amples informations, veuillez consulter [Revenir d'un SSL/TLS certificat personnalisé au certificat par défaut CloudFront](cnames-and-https-revert-to-cf-certificate.md).
+ Si vous pouvez contrôler le navigateur employé par vos utilisateurs, demandez-leur de mettre leur navigateur à niveau afin qu’il accepte l’extension SNI.
+ Utilisez HTTP au lieu de HTTPS.

## Utilisation d’une adresse IP dédiée pour traiter les demandes HTTPS (fonctionne pour tous les clients)
<a name="cnames-https-dedicated-ip"></a>

L’utilisation d’une extension SNI (Server Name Indication) est une façon d’associer une demande à un domaine. Une autre méthode consiste à utiliser une adresse IP dédiée. Si vous avez des utilisateurs qui ne peuvent pas effectuer une mise à niveau vers un navigateur ou un client lancé après 2010, vous pouvez utiliser une adresse IP dédiée pour servir les demandes HTTPS. Pour une liste actuelle des navigateurs qui prennent en charge l’extension SNI, consultez l’entrée [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication) de Wikipedia. 

**Important**  
Si vous configurez CloudFront pour répondre aux requêtes HTTPS à l'aide d'adresses IP dédiées, vous devrez payer des frais mensuels supplémentaires. Les frais commencent lorsque vous associez votre SSL/TLS certificat à une distribution et que vous activez la distribution. Pour plus d'informations sur CloudFront les tarifs, consultez [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing). Consultez également [Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions).

Lorsque vous configurez CloudFront pour répondre aux demandes HTTPS à l'aide d'adresses IP dédiées, CloudFront associez votre certificat à une adresse IP dédiée dans chaque emplacement CloudFront périphérique. Lorsqu’une visionneuse envoie une requête HTTPS pour obtenir votre contenu, voici ce qui se passe :

1. DNS achemine la requête à l’adresse IP de votre distribution dans l’emplacement périphérique concerné.

1. Si une demande du client fournit l'extension SNI dans le `ClientHello` message, CloudFront recherche une distribution associée à ce SNI.
   + S'il y a une correspondance, CloudFront répond à la demande avec le certificat SSL/TLS.
   + S'il n'y a pas de correspondance, CloudFront utilise plutôt l'adresse IP pour identifier votre distribution et pour déterminer le certificat SSL/TLS à renvoyer au lecteur.

1. Le visualiseur et CloudFront effectuez la SSL/TLS négociation à l'aide de votre certificat SSL/TLS.

1. CloudFront renvoie le contenu demandé au spectateur.

Cette méthode fonctionne pour toutes les requêtes HTTPS, quel que soit le navigateur ou autre client employé par l’utilisateur. 

**Note**  
 IPs Les objets dédiés ne sont pas statiques IPs et peuvent changer au fil du temps. L'adresse IP renvoyée pour l'emplacement périphérique est allouée dynamiquement à partir des plages d'adresses IP de la [liste des serveurs CloudFront périphériques](LocationsOfEdgeServers.md).  
Les plages d'adresses IP pour les serveurs CloudFront Edge sont sujettes à modification. Pour être informé des modifications d'adresse IP, [abonnez-vous à la section Changements d'adresse IP AWS publique via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).

## Demander l'autorisation d'utiliser au moins trois SSL/TLS certificats IP dédiés
<a name="cnames-and-https-multiple-certificates"></a>

Si vous avez besoin d'une autorisation pour associer de manière permanente au moins trois certificats IP dédiés SSL/TLS CloudFront, effectuez la procédure suivante. Pour de plus amples informations sur les requêtes HTTPS, consultez [Choisissez le mode de CloudFront traitement des requêtes HTTPS](#cnames-https-dedicated-ip-or-sni).

**Note**  
Cette procédure permet d'utiliser au moins trois certificats IP dédiés dans vos CloudFront distributions. La valeur par défaut est 2. N’oubliez pas que vous ne pouvez pas lier plusieurs certificats SSL à une distribution.  
Vous ne pouvez associer qu'un seul SSL/TLS certificat à une CloudFront distribution à la fois. Ce nombre correspond au nombre total de certificats IP SSL dédiés que vous pouvez utiliser dans toutes vos CloudFront distributions.<a name="cnames-and-https-multiple-certificates-procedure"></a>

**Pour demander l'autorisation d'utiliser trois certificats ou plus avec une CloudFront distribution**

1. Accédez au [Centre de support et créez une demande](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions).

1. Indiquez le nombre de certificats dont vous avez besoin et décrivez les circonstances de votre demande. Nous mettrons votre compte à jour dès que possible.

1. Poursuivez avec la procédure suivante.

# Exigences relatives à l'utilisation de SSL/TLS certificats avec CloudFront
<a name="cnames-and-https-requirements"></a>

Les exigences relatives aux SSL/TLS certificats sont décrites dans cette rubrique. Elles s’appliquent, sauf indication contraire, aux deux certificats suivants :
+ Certificats pour l'utilisation du protocole HTTPS entre les utilisateurs et CloudFront 
+ Certificats pour l'utilisation du protocole HTTPS entre CloudFront et votre origine

**Topics**
+ [Auteur du certificat](#https-requirements-certificate-issuer)
+ [Région AWS pour AWS Certificate Manager](#https-requirements-aws-region)
+ [Format du certificat](#https-requirements-certificate-format)
+ [Certificats intermédiaires](#https-requirements-intermediate-certificates)
+ [Type de clé](#https-requirements-key-type)
+ [Clé privée](#https-requirements-private-key)
+ [Permissions](#https-requirements-permissions)
+ [Taille de la clé de certificat](#https-requirements-size-of-public-key)
+ [Types de certificats pris en charge](#https-requirements-supported-types)
+ [Date d’expiration de certificat et renouvellement](#https-requirements-cert-expiration)
+ [Noms de domaine dans la CloudFront distribution et dans le certificat](#https-requirements-domain-names-in-cert)
+ [Version minimale SSL/TLS du protocole](#https-requirements-minimum-ssl-protocol-version)
+ [Versions de HTTP prises en charge](#https-requirements-supported-http-versions)

## Auteur du certificat
<a name="https-requirements-certificate-issuer"></a>

Nous vous recommandons d’utiliser un certificat public délivré par [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/). Pour plus d’informations sur l’obtention d’un certificat auprès d’ACM, reportez-vous au *[Guide de l’utilisateur AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*. Pour utiliser un certificat ACM avec une CloudFront distribution, assurez-vous de demander (ou d'importer) le certificat dans la région USA Est (Virginie du Nord) (`us-east-1`).

 CloudFront prend en charge les mêmes autorités de certification (CAs) que Mozilla. Par conséquent, si vous n'utilisez pas ACM, utilisez un certificat émis par une autorité de certification figurant sur la [liste des certificats d'autorité de certification inclus par Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). 

Les certificats TLS utilisés par l'origine que vous avez spécifiée pour votre CloudFront distribution doivent également être émis par l'autorité de certification figurant sur la liste des certificats d'autorité de certification inclus par Mozilla.

Pour plus de détails sur l’obtention et l’installation d’un certificat, consultez la documentation du logiciel de votre serveur HTTP et celle de l’autorité de certification.

## Région AWS pour AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

Pour utiliser un certificat dans AWS Certificate Manager (ACM) afin d'exiger le protocole HTTPS entre les utilisateursCloudFront, assurez-vous de demander (ou d'importer) le certificat dans la région de l'est des États-Unis (Virginie du Nord) (`us-east-1`).

Si vous souhaitez exiger le protocole HTTPS entre CloudFront et votre origine, et que vous utilisez un équilibreur de charge dans Elastic Load Balancing comme origine, vous pouvez demander ou importer le certificat dans n'importe quel Région AWS type de certificat.

## Format du certificat
<a name="https-requirements-certificate-format"></a>

Le certificat doit être au format PEM X.509. Il s’agit du format par défaut si vous utilisez AWS Certificate Manager.

## Certificats intermédiaires
<a name="https-requirements-intermediate-certificates"></a>

Si vous utilisez une autorité de certification tierce, indiquez tous les certificats intermédiaires dans la chaîne de certificats du fichier `.pem`, en commençant par celui de l’autorité de certification qui a signé le certificat de votre domaine. En règle générale, vous trouverez sur le site web de votre autorité de certification un fichier répertoriant les certificats racines et intermédiaires dans l’ordre approprié pour la chaîne.

**Important**  
N’incluez par les éléments suivants : le certificat racine, les certificats intermédiaires non approuvés ou le certificat de la clé publique de votre autorité de certification.

Voici un exemple :

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

## Type de clé
<a name="https-requirements-key-type"></a>

CloudFront prend en charge les paires de clés publiques-privées RSA et ECDSA.

CloudFront prend en charge les connexions HTTPS aux utilisateurs et aux origines à l'aide de certificats RSA et ECDSA. Avec [AWS Certificate Manager (ACM)](https://console.aws.amazon.com/acm), vous pouvez demander et importer des certificats RSA ou ECDSA, puis les associer à votre distribution. CloudFront 

Pour obtenir la liste des chiffrements RSA et ECDSA pris en charge par ces protocoles CloudFront que vous pouvez négocier dans le cadre de connexions HTTPS, consultez et. [Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront](secure-connections-supported-viewer-protocols-ciphers.md) [Protocoles et chiffrements pris en charge entre CloudFront et l'origine](secure-connections-supported-ciphers-cloudfront-to-origin.md)

## Clé privée
<a name="https-requirements-private-key"></a>

Si vous utilisez un certificat d’une autorité de certification tierce, notez les points suivants : 
+ La clé privée doit correspondre à la clé publique qui se trouve dans le certificat.
+ La clé privée doit être au format PEM.
+ La clé privée ne peut pas être chiffrée avec un mot de passe.

Si AWS Certificate Manager (ACM) a fourni le certificat, ACM ne libère pas la clé privée. La clé privée est stockée dans ACM pour être utilisée par les AWS services intégrés à ACM.

## Permissions
<a name="https-requirements-permissions"></a>

Vous devez être autorisé à utiliser et à importer le SSL/TLS certificat. Si vous utilisez AWS Certificate Manager (ACM), nous vous recommandons d'utiliser Gestion des identités et des accès AWS des autorisations pour restreindre l'accès aux certificats. Pour plus d’informations, consultez [Gestion des identités et des accès](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html) dans le *Guide de l’utilisateur AWS Certificate Manager *.

## Taille de la clé de certificat
<a name="https-requirements-size-of-public-key"></a>

La taille de clé de certificat CloudFront prise en charge dépend du type de clé et de certificat.

**Pour les certificats RSA :**  
CloudFront prend en charge les clés RSA 1024 bits, 2048 bits, 3072 bits et 4096 bits. La longueur de clé maximale pour un certificat RSA que vous utilisez CloudFront est de 4 096 bits.  
 Notez qu’ACM émet des certificats RSA avec des clés limitées à 2 048 bits. Pour utiliser un certificat RSA 3072 bits ou 4096 bits, vous devez obtenir le certificat en externe et l'importer dans ACM, après quoi vous pourrez l'utiliser. CloudFront   
Pour en savoir plus sur la façon de déterminer la taille d’une clé RSA, consultez [Déterminer la taille de la clé publique dans un certificat SSL/TLS RSA](cnames-and-https-size-of-public-key.md).

**Pour les certificats ECDSA :**  
CloudFront prend en charge les clés de 256 bits. Pour utiliser un certificat ECDSA dans ACM afin d'exiger le protocole HTTPS entre les utilisateurs CloudFront, utilisez la courbe elliptique prime256v1.

## Types de certificats pris en charge
<a name="https-requirements-supported-types"></a>

CloudFront prend en charge tous les types de certificats émis par une autorité de certification fiable.

## Date d’expiration de certificat et renouvellement
<a name="https-requirements-cert-expiration"></a>

Si vous utilisez des certificats que vous obtenez d'une autorité de certification (CA) tierce, vous devez surveiller les dates d'expiration des certificats et renouveler les certificats que vous importez dans AWS Certificate Manager (ACM) ou que vous téléchargez dans le magasin de Gestion des identités et des accès AWS certificats avant leur expiration.

**Important**  
Pour éviter les problèmes liés à l’expiration d’un certificat, renouvelez ou réimportez votre certificat au moins 24 heures avant la valeur `NotAfter` de votre certificat actuel. Si votre certificat expire dans les 24 heures, demandez un nouveau certificat à ACM ou importez-en un nouveau dans ACM. Associez ensuite le nouveau certificat à la CloudFront distribution.  
CloudFront peut continuer à utiliser le certificat précédent pendant que le renouvellement ou la réimportation de votre certificat est en cours. Il s'agit d'un processus asynchrone qui peut prendre jusqu'à 24 heures avant que vos modifications ne CloudFront soient affichées.

Si vous utilisez des certificats fournis par ACM, ACM gère automatiquement le renouvellement des certificats. Pour plus d'informations, consultez [Renouvellement géré](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) dans le *Guide de l'utilisateur AWS Certificate Manager *.

## Noms de domaine dans la CloudFront distribution et dans le certificat
<a name="https-requirements-domain-names-in-cert"></a>

Lorsque vous utilisez une origine personnalisée, le SSL/TLS certificat associé à votre origine inclut un nom de domaine dans le champ **Nom commun**, et éventuellement plusieurs autres dans le champ **Noms alternatifs du sujet**. (CloudFront prend en charge les caractères génériques dans les noms de domaine des certificats.) 

L’un des noms de domaines du certificat doit correspondre au nom de domaine spécifié pour le nom du domaine d’origine. Si aucun nom de domaine ne correspond, CloudFront renvoie le code `502 (Bad Gateway)` d'état HTTP au lecteur.

**Important**  
Lorsque vous ajoutez un autre nom de domaine à une distribution, CloudFront vérifiez que le nom de domaine alternatif est couvert par le certificat que vous avez joint. Le certificat doit couvrir le nom de domaine alternatif dans le champ SAN du certificat. Cela signifie que le champ SAN doit contenir une correspondance exacte pour le nom de domaine alternatif ou un caractère générique au même niveau que le nom de domaine alternatif que vous ajoutez.  
Pour de plus amples informations, veuillez consulter [Exigences relatives à l’utilisation de noms de domaines alternatifs](CNAMEs.md#alternate-domain-names-requirements).

## Version minimale SSL/TLS du protocole
<a name="https-requirements-minimum-ssl-protocol-version"></a>

Si vous utilisez des adresses IP dédiées, définissez la version minimale SSL/TLS du protocole pour la connexion entre les utilisateurs et CloudFront choisissez une politique de sécurité.

Pour plus d’informations, consultez [Politique de sécurité ( SSL/TLS version minimale)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).

## Versions de HTTP prises en charge
<a name="https-requirements-supported-http-versions"></a>

Si vous associez un certificat à plusieurs CloudFront distributions, toutes les distributions associées au certificat doivent utiliser la même option pour[Versions de HTTP prises en charge](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions). Vous spécifiez cette option lorsque vous créez ou mettez à jour une CloudFront distribution.

# Quotas d'utilisation des SSL/TLS certificats avec CloudFront (HTTPS entre utilisateurs et CloudFront uniquement)
<a name="cnames-and-https-limits"></a>

Notez les quotas suivants concernant l'utilisation de SSL/TLS certificats avecCloudFront. Ces quotas s'appliquent uniquement aux SSL/TLS certificats que vous fournissez à l'aide de AWS Certificate Manager (ACM), que vous importez dans ACM ou que vous téléchargez dans le magasin de certificats IAM pour les communications HTTPS entre les utilisateurs et. CloudFront

Pour de plus amples informations, veuillez consulter [Augmenter les quotas de SSL/TLS certificats](increasing-the-limit-for-ssl-tls-certificates.md).

**Nombre maximum de certificats par CloudFront distribution**  
Vous pouvez associer un SSL/TLS certificat au maximum à chaque CloudFront distribution.

**Nombre maximal de certificats que vous pouvez importer dans ACM ou télécharger dans le magasin de certificats IAM**  
Si vous avez obtenu vos SSL/TLS certificats auprès d'une autorité de certification tierce, vous devez les stocker dans l'un des emplacements suivants :  
+ **AWS Certificate Manager** – Pour connaître le quota actuel sur le nombre de certificats ACM, consultez [Quotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) dans le *Guide de l’utilisateur AWS Certificate Manager *. Le quota indiquée est un total qui inclut les certificats que vous mettez en service à l’aide d’ACM et les certificats que vous importez dans ACM.
+ **Magasin de certificats IAM** : pour connaître le quota actuel (anciennement connu sous le nom de limite) du nombre de certificats que vous pouvez télécharger vers le magasin de certificats IAM pour un AWS compte, consultez la section [Limites IAM et STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) dans le guide de l'utilisateur *IAM*. Vous pouvez demander une augmentation de quota dans la console Service Quotas.

**Nombre maximum de certificats par AWS compte (adresses IP dédiées uniquement)**  
Si vous souhaitez diffuser des requêtes HTTPS en utilisant des adresses IP dédiées, notez les points suivants :  
+ Par défaut, vous CloudFront autorise à utiliser deux certificats avec votre AWS compte, l'un pour un usage quotidien et l'autre pour les cas où vous devez alterner les certificats pour plusieurs distributions.
+ Si vous avez besoin de plus de deux SSL/TLS certificats personnalisés pour votre AWS compte, vous pouvez demander un quota plus élevé dans la console Service Quotas.

**Utilisez le même certificat pour les CloudFront distributions créées à l'aide de AWS comptes différents**  
Si vous utilisez une autorité de certification tierce et que vous souhaitez utiliser le même certificat avec plusieurs CloudFront distributions créées à l'aide de AWS comptes différents, vous devez importer le certificat dans ACM ou le télécharger dans le magasin de certificats IAM une fois pour chaque AWS compte.  
Si vous utilisez des certificats fournis par ACM, vous ne pouvez pas configurer CloudFront pour utiliser des certificats créés par un autre AWS compte.

**Utiliser le même certificat pour CloudFront et pour les autres AWS services**  
Si vous avez acheté un certificat auprès d'une autorité de certification fiable telle que Comodo ou Symantec, vous pouvez utiliser le même certificat pour CloudFront et pour d'autres AWS services. DigiCert Si vous importez le certificat dans ACM, vous ne devez l’importer qu’une seule fois pour l’utiliser pour plusieurs services AWS .  
Si vous utilisez les certificats fournis par ACM, ces certificats sont stockés dans ACM.

**Utiliser le même certificat pour plusieurs CloudFront distributions**  
Vous pouvez utiliser le même certificat pour tout ou partie des distributions CloudFront que vous utilisez pour diffuser les requêtes HTTPS. Notez ce qui suit :  
+ Vous pouvez utiliser le même certificat pour diffuser les requêtes utilisant des adresses IP dédiées et pour celles utilisant l’extension SNI. 
+ Vous ne pouvez associer qu’un seul certificat à chaque distribution.
+ Chaque distribution doit inclure un ou plusieurs noms de domaines alternatifs qui apparaissent aussi dans les champs **Common Name** ou **Subject Alternative Name** du certificat.
+ Si vous envoyez des requêtes HTTPS à l'aide d'adresses IP dédiées et que vous avez créé toutes vos distributions en utilisant le même AWS compte, vous pouvez réduire considérablement vos coûts en utilisant le même certificat pour toutes les distributions. CloudFront des frais pour chaque certificat, et non pour chaque distribution. 

  Supposons, par exemple, que vous créez trois distributions en utilisant le même AWS compte et que vous utilisiez le même certificat pour les trois distributions. Un seul montant correspondant à l’usage des adresses IP dédiées vous sera facturé.

  Toutefois, si vous envoyez des requêtes HTTPS à l'aide d'adresses IP dédiées et que vous utilisez le même certificat pour créer CloudFront des distributions sur différents AWS comptes, les frais d'utilisation des adresses IP dédiées sont facturés à chaque compte. Par exemple, si vous créez trois distributions en utilisant trois AWS comptes différents et que vous utilisez le même certificat pour les trois distributions, les frais d'utilisation des adresses IP dédiées sont facturés à chaque compte.

# Configuration de noms de domaines alternatifs et HTTPS
<a name="cnames-and-https-procedures"></a>

Pour utiliser des noms de domaine alternatifs dans vos fichiers et URLs pour utiliser le protocole HTTPS entre les utilisateurs CloudFront, suivez les procédures applicables.

**Topics**
+ [Obtenir un SSL/TLS certificat](#cnames-and-https-getting-certificates)
+ [Importer un SSL/TLS certificat](#cnames-and-https-uploading-certificates)
+ [Mettez à jour votre CloudFront distribution](#cnames-and-https-updating-cloudfront)

## Obtenir un SSL/TLS certificat
<a name="cnames-and-https-getting-certificates"></a>

Obtenez un SSL/TLS certificat si vous n'en avez pas déjà un. Pour plus d'informations, consultez la documentation pertinente :
+ Pour utiliser un certificat fourni par AWS Certificate Manager (ACM), consultez le [guide de l'AWS Certificate Manager utilisateur](https://docs.aws.amazon.com/acm/latest/userguide/). Passez ensuite à [Mettez à jour votre CloudFront distribution](#cnames-and-https-updating-cloudfront).
**Note**  
Nous vous recommandons d'utiliser ACM pour provisionner, gérer et déployer des SSL/TLS certificats sur des ressources AWS gérées. Vous devez demander un certificat ACM dans la région USA Est (Virginie du Nord).
+ Pour obtenir un certificat auprès d’une autorité de certification tierce, consultez la documentation fournie par l’autorité de certification. Lorsque vous avez obtenu le certificat, passez à la procédure suivante.

## Importer un SSL/TLS certificat
<a name="cnames-and-https-uploading-certificates"></a>

Si vous avez obtenu votre certificat auprès d’une autorité de certification tierce, importez-le dans ACM ou chargez-le dans le magasin de certificats IAM :

**ACM (recommandé)**  
ACM vous permet d’importer des certificats tiers à partir de la console ACM, ainsi que par programmation. Pour plus d’informations sur l’importation d’un certificat dans ACM, consultez [Importation de certificats dans AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) dans le *Guide de l’utilisateur AWS Certificate Manager *. Vous devez importer le certificat dans la région USA Est (Virginie du Nord).

**Magasin de certificats IAM**  
(Non recommandé) Utilisez la AWS CLI commande suivante pour télécharger votre certificat tiers dans le magasin de certificats 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/
```
Notez ce qui suit :  
+ **AWS compte** : vous devez télécharger le certificat dans le magasin de certificats IAM en utilisant le même AWS compte que celui que vous avez utilisé pour créer votre CloudFront distribution.
+ **Paramètre --path** : lorsque vous chargez le certificat dans IAM, la valeur du paramètre `--path` (chemin du certificat) doit commencer par `/cloudfront/`, comme `/cloudfront/production/` ou `/cloudfront/test/`. Le chemin doit se terminer par un caractère /.
+ **Certificats existants** : vous devez affecter aux paramètres `--server-certificate-name` et `--path` des valeurs différentes de celles qui sont associées aux certificats existants.
+ **Utilisation de la CloudFront console** — La valeur que vous spécifiez pour le `--server-certificate-name` paramètre dans AWS CLI, par exemple`myServerCertificate`, apparaît dans la liste des **certificats SSL** de la CloudFront console.
+ **Utilisation de l' CloudFront API** — Prenez note de la chaîne alphanumérique AWS CLI renvoyée, `AS1A2M3P4L5E67SIIXR3J` par exemple. Il s’agit de la valeur que vous spécifierez dans l’élément `IAMCertificateId`. Vous n’avez pas besoin de l’ARN IAM, que renvoie également la CLI.
Pour plus d'informations sur le AWS CLI, consultez le [guide de l'AWS Command Line Interface utilisateur](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) et le manuel de [référence des AWS CLI commandes](https://docs.aws.amazon.com/cli/latest/reference/).

## Mettez à jour votre CloudFront distribution
<a name="cnames-and-https-updating-cloudfront"></a>

Pour mettre à jour les paramètres de votre distribution, procédez comme suit :<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**Pour configurer votre CloudFront distribution pour les noms de domaine alternatifs**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez l’ID de la distribution que vous souhaitez mettre à jour.

1. Sous l’onglet **General**, choisissez **Edit**.

1. Mettez à jour les valeurs suivantes :  
**Nom de domaine alternatif (CNAME)**  
Choisissez **Ajouter un élément** pour ajouter les noms de domaine alternatifs applicables. Séparez les noms de domaines par des virgules ou saisissez chaque nom de domaine sur une nouvelle ligne.  
**Certificat SSL personnalisé**  
Sélectionnez un certificat dans la liste déroulante.  
Jusqu’à 100 certificats sont répertoriés ici. Si vous avez plus de 100 certificats et que vous ne voyez pas le certificat que vous souhaitez ajouter, vous pouvez taper un nom ARN de certificat dans le champ pour le choisir.  
Si vous avez chargé un certificat dans le magasin de certificats IAM mais qu’il n’apparaît pas dans la liste et que vous ne pouvez pas le choisir en tapant son nom dans le champ, revoyez la procédure [Importer un SSL/TLS certificat](#cnames-and-https-uploading-certificates) afin de vérifier si vous avez bien chargé le certificat.   
Après avoir associé votre SSL/TLS certificat à votre CloudFront distribution, ne le supprimez pas d'ACM ou du magasin de certificats IAM tant que vous n'avez pas retiré le certificat de toutes les distributions et que toutes les distributions n'ont pas été déployées.

1. Sélectionnez **Enregistrer les modifications**.

1. Configurez CloudFront pour exiger le protocole HTTPS entre les spectateurs et CloudFront :

   1. Sous l’onglet **Comportements**, choisissez le comportement de cache à mettre à jour, puis sélectionnez **Modifier**.

   1. Spécifiez l’une des valeurs suivantes pour **Politique de protocole d’utilisateur** :  
**Redirect HTTP to HTTPS**  
Les utilisateurs peuvent utiliser les deux protocoles, mais les requêtes HTTP sont automatiquement redirigées vers les requêtes HTTPS. CloudFront renvoie le code d'état HTTP `301 (Moved Permanently)`, ainsi que la nouvelle URL HTTPS. Le téléspectateur soumet ensuite à nouveau la demande à CloudFront l'aide de l'URL HTTPS.  
CloudFront ne redirige pas `DELETE``OPTIONS`,`PATCH`,`POST`, ou les `PUT` requêtes de HTTP vers HTTPS. Si vous configurez un comportement de cache pour rediriger vers HTTPS, vous CloudFront répondez au HTTP`DELETE`,`OPTIONS`, `PATCH``POST`, ou aux `PUT` demandes relatives à ce comportement de cache avec un code d'état HTTP`403 (Forbidden)`.
Lorsqu'un utilisateur fait une requête HTTP qui est redirigée vers une requête HTTPS, les deux requêtes sont CloudFront facturées. Pour la requête HTTP, le montant correspond uniquement à la requête et aux en-têtes que CloudFront renvoie à l'utilisateur. Pour la requête HTTPS, le montant correspond à la requête ainsi qu’aux en-têtes et au fichier renvoyés par votre origine.  
**HTTPS Only**  
Les visionneuses ne peuvent accéder au contenu que si elles utilisent le protocole HTTPS. Si un utilisateur envoie une requête HTTP au lieu d'une requête HTTPS, il CloudFront renvoie le code d'état HTTP `403 (Forbidden)` et ne renvoie pas le fichier.

   1. Choisissez **Oui, Modifier**.

   1. Répétez les étapes a à c pour chaque comportement de cache supplémentaire pour lequel vous souhaitez exiger HTTPS entre les visionneuses et CloudFront.

1. Vérifiez les éléments suivants avant d’utiliser la configuration mise à jour dans un environnement de production :
   + Le modèle de chemin de chaque comportement de cache s’applique uniquement aux requêtes pour lesquelles vous souhaitez que les visionneuses utilisent HTTPS.
   + Les comportements de cache sont répertoriés dans l'ordre dans lequel vous voulez que CloudFront les évalue. Pour de plus amples informations, veuillez consulter [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Les comportements de cache acheminent les requêtes vers les origines correctes. 

# Déterminer la taille de la clé publique dans un certificat SSL/TLS RSA
<a name="cnames-and-https-size-of-public-key"></a>

Lorsque vous utilisez des noms de domaine CloudFront alternatifs et le protocole HTTPS, la taille maximale de la clé publique d'un certificat SSL/TLS RSA est de 4 096 bits. (Il s’agit de la taille de la clé, et non pas du nombre de caractères figurant dans la clé publique.) Si vous utilisez AWS Certificate Manager pour vos certificats, bien qu'ACM prenne en charge les clés RSA de plus grande taille, vous ne pouvez pas utiliser les clés les plus grandes avec. CloudFront

Vous pouvez déterminer la taille de la clé publique RSA en exécutant la commande OpenSSL suivante :

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

Où :
+ `-in`indique le chemin et le nom de fichier de votre certificat SSL/TLS RSA.
+ `-text` permet à OpenSSL d’afficher la longueur de la clé publique RSA en bits.
+ `-noout` empêche OpenSSL d’afficher la clé publique.

Exemple de sortie :

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

# Augmenter les quotas de SSL/TLS certificats
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

Il existe des quotas quant au nombre de SSL/TLS certificats que vous pouvez importer dans AWS Certificate Manager (ACM) ou télécharger vers Gestion des identités et des accès AWS (IAM). Il existe également un quota sur le nombre de SSL/TLS certificats que vous pouvez utiliser avec et Compte AWS lorsque vous configurez CloudFront pour répondre aux requêtes HTTPS en utilisant des adresses IP dédiées. Cependant, vous pouvez demander des quotas plus élevés.

**Topics**
+ [Augmentation du quota de certificats importés dans ACM](#certificates-to-import-into-acm)
+ [Augmentation du quota de certificats téléchargés vers IAM](#certificates-to-upload-into-iam)
+ [Augmentation du quota de certificats utilisés avec des adresses IP dédiées](#certificates-using-dedicated-ip-address)

## Augmentation du quota de certificats importés dans ACM
<a name="certificates-to-import-into-acm"></a>

Pour connaître le quota du nombre de certificats que vous pouvez importer dans ACM, consultez la page [Quotas](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) dans le *Guide de l’utilisateur AWS Certificate Manager *.

Pour demander l’augmentation d’un quota, utilisez la console Service Quotas. Pour plus d’informations, consultez [Demande d’augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l’utilisateur Service Quotas*.

## Augmentation du quota de certificats téléchargés vers IAM
<a name="certificates-to-upload-into-iam"></a>

Pour connaître le quota (auparavant appelé limite) lié au nombre de certificats que vous pouvez charger dans IAM, consultez [Limites IAM et STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) dans le *Guide de l’utilisateur IAM*.

Pour demander l’augmentation d’un quota, utilisez la console Service Quotas. Pour plus d’informations, consultez [Demande d’augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l’utilisateur Service Quotas*.

## Augmentation du quota de certificats utilisés avec des adresses IP dédiées
<a name="certificates-using-dedicated-ip-address"></a>

Pour connaître le quota du nombre de certificats SSL que vous pouvez utiliser pour chacun Compte AWS lorsque vous répondez à des requêtes HTTPS à l'aide d'adresses IP dédiées, consultez[Quotas sur les certificats SSL](cloudfront-limits.md#limits-ssl-certificates).

Pour demander l’augmentation d’un quota, utilisez la console Service Quotas. Pour plus d’informations, consultez [Demande d’augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l’utilisateur Service Quotas*.

# Rotation SSL/TLS des certificats
<a name="cnames-and-https-rotate-certificates"></a>

Lorsque vos SSL/TLS certificats sont sur le point d'expirer, vous devez les alterner pour garantir la sécurité de votre distribution et éviter toute interruption de service pour vos spectateurs. Vous pouvez effectuer leur rotation selon les méthodes suivantes :
+ Pour les SSL/TLS certificats fournis par AWS Certificate Manager (ACM), il n'est pas nécessaire de les faire pivoter. ACM gère *automatiquement* le renouvellement des certificats. Pour plus d’informations, consultez [Renouvellement géré des certificats](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html) dans le *Guide de l’utilisateur AWS Certificate Manager *.
+ Si vous utilisez une autorité de certification tierce et que vous avez importé des certificats dans ACM (recommandé) ou que vous en avez chargé dans le magasin de certificats IAM, vous devez parfois remplacer un certificat par un autre.

  

**Important**  
ACM ne gère pas le renouvellement des certificats que vous obtenez auprès d’autorités de certification tierces et importez dans ACM.
Si vous avez configuré CloudFront pour traiter les requêtes HTTPS à l'aide d'adresses IP dédiées, l'utilisation d'un ou de plusieurs certificats supplémentaires peut vous être facturée au prorata pendant la rotation des certificats. Nous vous recommandons de mettre à jour vos distributions pour réduire les frais supplémentaires.

## Rotation SSL/TLS des certificats
<a name="rotate-ssl-tls-certificate"></a>

Pour faire tourner vos certificats, exécutez la procédure suivante. Les utilisateurs peuvent continuer d’accéder à votre contenu pendant la rotation des certificats, ainsi qu’une fois le processus terminé.<a name="rotate-ssl-tls-certificates-proc"></a>

**Pour alterner SSL/TLS les certificats**

1. [Augmenter les quotas de SSL/TLS certificats](increasing-the-limit-for-ssl-tls-certificates.md) pour déterminer si vous avez besoin de l’autorisation d’utiliser Plus de certificats SSL. Si c’est le cas, demandez l’autorisation et attendez que celle-ci vous soit accordée avant de passer à l’étape 2.

1. Importez le nouveau certificat dans ACM ou chargez-le dans IAM. Pour plus d'informations, consultez [Importation d'un SSL/TLS certificat](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates) dans le manuel *Amazon CloudFront Developer Guide*.

1. (Pour les certificats IAM uniquement) Mettez vos distributions à jour une à la fois pour utiliser le nouveau certificat. Pour de plus amples informations, veuillez consulter [Mettre à jour une distribution](HowToUpdateDistribution.md).

1. (Facultatif) Supprimez le certificat précédent d’ACM ou d’IAM.
**Important**  
Ne supprimez pas un SSL/TLS certificat tant que vous ne l'avez pas supprimé de toutes les distributions et tant que le statut des distributions que vous avez mises à jour n'est plus le même`Deployed`.

# Revenir d'un SSL/TLS certificat personnalisé au certificat par défaut CloudFront
<a name="cnames-and-https-revert-to-cf-certificate"></a>

Si vous avez configuré CloudFront pour utiliser le protocole HTTPS entre les utilisateurs et CloudFront, et si vous avez configuré CloudFront pour utiliser un SSL/TLS certificat personnalisé, vous pouvez modifier votre configuration pour utiliser le certificat CloudFront SSL/TLS par défaut. Le processus varie selon que vous avez utilisé ou non votre distribution pour transmettre votre contenu :
+ Si vous n’avez pas utilisé votre distribution pour transmettre votre contenu, vous pouvez juste modifier la configuration. Pour de plus amples informations, veuillez consulter [Mettre à jour une distribution](HowToUpdateDistribution.md).
+ Si vous avez utilisé votre distribution pour distribuer votre contenu, vous devez créer une nouvelle CloudFront distribution et modifier la URLs distribution de vos fichiers afin de réduire ou d'éliminer le temps pendant lequel votre contenu n'est pas disponible. Pour ce faire, procédez comme suit.

## Revenir au certificat par défaut CloudFront
<a name="revert-default-cloudfront-certificate"></a>

La procédure suivante explique comment passer d'un SSL/TLS certificat personnalisé au CloudFront certificat par défaut.<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**Pour revenir au certificat par défaut CloudFront**

1. Créez une nouvelle CloudFront distribution avec la configuration souhaitée. Pour **Certificat SSL**, choisissez **Certificat par défaut CloudFront (\$1.cloudfront.net)**. 

   Pour de plus amples informations, veuillez consulter [Créer une distribution](distribution-web-creating-console.md).

1. Pour les fichiers que vous distribuez en utilisant CloudFront, mettez-les à jour URLs dans votre application pour utiliser le nom de domaine CloudFront attribué à la nouvelle distribution. Remplacez, par exemple, `https://www.example.com/images/logo.png` par `https://d111111abcdef8.cloudfront.net/images/logo.png`.

1. Supprimez la distribution associée à un certificat SSL/TLS personnalisé ou mettez-la à jour pour remplacer la valeur du certificat **SSL par CloudFront certificat** **par défaut (**\$1.cloudfront.net). Pour de plus amples informations, veuillez consulter [Mettre à jour une distribution](HowToUpdateDistribution.md).
**Important**  
Jusqu'à ce que vous ayez terminé cette étape, l'utilisation d'un SSL/TLS certificat personnalisé AWS continue de vous être facturée.

1. (Facultatif) Supprimez votre SSL/TLS certificat personnalisé.

   1. Exécutez la AWS CLI commande `list-server-certificates` pour obtenir l'ID du certificat que vous souhaitez supprimer. Pour plus d’informations, consultez [list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html) dans la *Référence des commandes de l’AWS CLI *.

   1. Exécutez la AWS CLI commande `delete-server-certificate` pour supprimer le certificat. Pour plus d’informations, consultez [delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html) dans la *Référence des commandes de l’AWS CLI *.

# Passez d'un SSL/TLS certificat personnalisé avec adresses IP dédiées à un certificat SNI
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

Si vous avez configuré CloudFront pour utiliser un SSL/TLS certificat personnalisé avec des adresses IP dédiées, vous pouvez passer à un SSL/TLS certificat personnalisé avec SNI à la place et éliminer les frais associés aux adresses IP dédiées.

**Important**  
Cette mise à jour de votre CloudFront configuration n'a aucun effet sur les utilisateurs qui prennent en charge le SNI. Les spectateurs peuvent accéder à votre contenu avant et après la modification, ainsi que pendant que la modification se propage aux zones CloudFront périphériques. Les utilisateurs qui ne prennent pas en charge l’extension SNI ne peuvent plus accéder à votre contenu après le changement. Pour de plus amples informations, veuillez consulter [Choisissez le mode de CloudFront traitement des requêtes HTTPS](cnames-https-dedicated-ip-or-sni.md). 

## Conversion d’un certificat personnalisé à une extension SNI
<a name="cloudfront-switch-custom-cert-sni"></a>

La procédure suivante explique comment passer d'un SSL/TLS certificat personnalisé avec des adresses IP dédiées au SNI.<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**Pour passer d'un SSL/TLS certificat personnalisé avec adresses IP dédiées à un certificat SNI**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez l’ID de la distribution que vous souhaitez afficher ou mettre à jour.

1. Choisissez **Paramètres de distribution**.

1. Sous l’onglet **General**, choisissez **Edit**.

1. Dans **Certification SSL personnalisée – *facultatif***, désélectionnez **Prise en charge de clients hérités**.

1. Choisissez **Oui, Modifier**.

# Authentification TLS mutuelle avec CloudFront (Viewer MTLS)
<a name="mtls-authentication"></a>

L'authentification TLS mutuelle (Mutual Transport Layer Security Authentication — MTLS) est un protocole de sécurité qui étend l'authentification TLS standard en exigeant une authentification bidirectionnelle basée sur des certificats, dans laquelle le client et le serveur doivent prouver leur identité avant d'établir une connexion sécurisée. Grâce au protocole TLS mutuel, vous pouvez vous assurer que seuls les clients présentant des certificats TLS fiables ont accès à vos CloudFront distributions.

## Comment ça marche
<a name="how-mtls-works"></a>

Dans un handshake TLS standard, seul le serveur présente un certificat prouvant son identité au client. Avec le protocole TLS mutuel, le processus d'authentification devient bidirectionnel. Lorsqu'un client tente de se connecter à votre CloudFront distribution, il CloudFront demande un certificat client lors de la prise de contact TLS. Le client doit présenter un certificat X.509 valide par rapport à votre magasin de confiance configuré avant d'établir la connexion sécurisée. CloudFront 

CloudFront effectue cette validation des certificats sur des sites AWS périphériques, déchargeant ainsi vos serveurs d'origine de la complexité de l'authentification tout en préservant les avantages en termes CloudFront de performances globales. Vous pouvez configurer les MTL selon deux modes : le mode vérification (qui oblige tous les clients à présenter des certificats valides) ou le mode facultatif (qui valide les certificats lorsqu'ils sont présentés mais autorise également les connexions sans certificat).

## Cas d’utilisation
<a name="mtls-use-cases"></a>

L'authentification TLS mutuelle CloudFront répond à plusieurs scénarios de sécurité critiques dans lesquels les méthodes d'authentification traditionnelles sont insuffisantes :
+ **Authentification des appareils avec mise en cache du contenu** : vous pouvez authentifier les consoles de jeu, les appareils IoT ou le matériel de l'entreprise avant d'autoriser l'accès aux mises à jour du microprogramme, aux téléchargements de jeux ou aux ressources internes. Chaque appareil contient un certificat unique qui prouve son authenticité tout en bénéficiant des fonctionnalités CloudFront de mise en cache.
+ **API-to-API authentification** - Vous pouvez sécuriser les machine-to-machine communications entre des partenaires commerciaux de confiance, des systèmes de paiement ou des microservices. L'authentification basée sur des certificats élimine le besoin de partager des secrets ou des clés d'API tout en fournissant une vérification d'identité solide pour les échanges de données automatisés.

**Topics**
+ [Comment ça marche](#how-mtls-works)
+ [Cas d’utilisation](#mtls-use-cases)
+ [Trust Stores et gestion des certificats](trust-stores-certificate-management.md)
+ [Activer le protocole TLS mutuel pour les distributions CloudFront](enable-mtls-distributions.md)
+ [Associer une fonction CloudFront de connexion](connection-functions.md)
+ [Configuration de paramètres supplémentaires](configuring-additional-settings.md)
+ [En-têtes MTLS Viewer pour les politiques de cache et transférés à l'origine](viewer-mtls-headers.md)
+ [Révocation à l'aide de la fonction CloudFront de connexion et du KVS](revocation-connection-function-kvs.md)
+ [Observabilité à l'aide des journaux de connexion](connection-logs.md)

# Trust Stores et gestion des certificats
<a name="trust-stores-certificate-management"></a>

La création et la configuration d'un trust store sont obligatoires pour implémenter l'authentification TLS mutuelle avec CloudFront. Les magasins de confiance contiennent les certificats de l'autorité de certification (CA) CloudFront utilisés pour valider les certificats clients lors du processus d'authentification.

## Qu'est-ce qu'un trust store ?
<a name="what-is-trust-store"></a>

Un trust store est un référentiel de certificats CA CloudFront utilisé pour valider les certificats clients lors de l'authentification TLS mutuelle. Les magasins de confiance contiennent les certificats racine et intermédiaires de l'autorité de certification qui forment la chaîne de confiance pour authentifier les certificats clients.

Lorsque vous implémentez le protocole TLS mutuel avec CloudFront, le trust store définit les autorités de certification auxquelles vous faites confiance pour délivrer des certificats clients valides. CloudFront valide chaque certificat client par rapport à votre magasin de confiance lors de la prise de contact TLS. Seuls les clients présentant des certificats liés à l'un des certificats CAs de votre magasin de confiance seront authentifiés avec succès.

Les dépôts de confiance CloudFront sont des ressources au niveau du compte que vous pouvez associer à plusieurs distributions. Cela vous permet de maintenir des politiques de validation des certificats cohérentes sur l'ensemble de votre CloudFront déploiement tout en simplifiant la gestion des certificats CA.

## Assistance aux autorités de certification
<a name="ca-support"></a>

CloudFront prend en charge les certificats émis à la fois par une autorité de certification AWS privée et par des autorités de certification privées tierces. Cette flexibilité vous permet d'utiliser votre infrastructure de certificats existante ou de tirer parti des services de certificats AWS gérés en fonction des besoins de votre organisation.
+ **AWS Autorité de certification privée :** vous pouvez utiliser des certificats émis par AWS Private CA, qui fournit un service d'autorité de certification privée géré. Cette intégration simplifie la gestion du cycle de vie des certificats et permet une intégration parfaite avec d'autres AWS services.
+ **Autorités de certification privées tierces :** vous pouvez également utiliser des certificats provenant de votre infrastructure d'autorité de certification privée existante, y compris des fournisseurs de certificats d'entreprise CAs ou d'autres fournisseurs de certificats tiers. Cela vous permet de maintenir vos processus actuels de gestion des certificats tout en ajoutant CloudFront des fonctionnalités mTLS.

## Exigences et spécifications relatives aux certificats
<a name="certificate-requirements"></a>

Les magasins de confiance ont des exigences spécifiques concernant les certificats CA qu'ils contiennent :

### Exigences relatives au format des certificats CA
<a name="ca-cert-format-requirements"></a>
+ **Format : format** PEM (Privacy Enhanced Mail)
+ **Limites du contenu : les certificats doivent être placés dans les limites** -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----
+ **Commentaires :** Doit être précédé d'un caractère \$1 et ne peut contenir aucun caractère -
+ **Sauts de ligne :** aucune ligne vide n'est autorisée entre les certificats

### Spécifications des certificats pris en charge
<a name="supported-cert-specs"></a>
+ **Type de certificat : X.509v3**
+ **Types de clés publiques :**
  + RSA 2048, RSA 3072, RSA 4096
  + ECDSA : secp256r1, secp384r1
+ **Algorithmes de signature :**
  + SHA256 SHA384, SHA512 avec RSA
  + SHA256 SHA384, SHA512 avec EC
  + SHA256 SHA384, SHA512 avec RASSA-PSS avec MGF1

### Exemple de format de bundle de certificats
<a name="example-cert-bundle"></a>

Certificats multiples (codés 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-----
```

## Créez un trust store
<a name="create-trust-store"></a>

Avant de créer un trust store, vous devez télécharger votre bundle de certificats CA au format PEM dans un compartiment Amazon S3. Le bundle de certificats doit contenir tous les certificats d'autorité de certification racine et intermédiaire sécurisés nécessaires à la validation de vos certificats clients.

Le bundle de certificats CA n'est lu qu'une seule fois depuis S3 lors de la création d'un trust store. Si de futures modifications sont apportées au bundle de certificats CA, le trust store devra être mis à jour manuellement. Aucune synchronisation n'est maintenue entre le trust store et le bundle de certificats S3 CA.

### Conditions préalables
<a name="trust-store-prerequisites"></a>
+ Un bundle de certificats de votre autorité de certification (CA) chargé dans un compartiment Amazon S3
+ Les autorisations nécessaires pour créer des CloudFront ressources

### Pour créer un trust store (console)
<a name="create-trust-store-console"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, choisissez **Trust stores**.

1. Choisissez **Create trust store**.

1. Dans **Nom de la boutique de confiance**, entrez le nom de votre boutique de confiance.

1. Pour le **bundle d'autorité de certification (CA)**, entrez le chemin Amazon S3 vers votre bundle de certificats CA au format PEM.

1. Choisissez **Create trust store**.

### Pour créer un trust store (AWS CLI)
<a name="create-trust-store-cli"></a>

```
aws cloudfront create-trust-store \
  --name MyTrustStore \
  --ca-certificates-bundle-source '{"CaCertificatesBundleS3Location":{"Bucket":"my-bucket","Key":"ca-bundle.pem","Region":"bucket-region"}}' \
  --tags Items=[{Key=Environment,Value=Production}]
```

## Associez Trust Store aux distributions
<a name="associate-trust-store"></a>

Après avoir créé un trust store, vous devez l'associer à une CloudFront distribution pour permettre l'authentification TLS mutuelle.

### Conditions préalables
<a name="associate-prerequisites"></a>
+ Une CloudFront distribution existante avec la politique de protocole de visualisation HTTPS uniquement activée et le HTTP3 support désactivé.

### Pour associer un trust store (console)
<a name="associate-trust-store-console"></a>

Il existe deux manières d'associer un trust store dans la CloudFront console : via la page de détails du trust store ou via la page des paramètres de distribution.

**Associer un trust store via la page de détails du trust store :**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, choisissez **Trust stores**.

1. Choisissez le nom du trust store que vous souhaitez associer.

1. Choisissez **Associer à la distribution**.

1. Configurez les options mTLS du Viewer disponibles :
   + **Mode de validation du certificat client :** choisissez entre le mode obligatoire et le mode facultatif. En mode obligatoire, tous les clients sont tenus de présenter des certificats. En mode facultatif, les clients qui présentent des certificats sont validés, tandis que les clients qui ne présentent pas de certificats sont autorisés à y accéder.
   + **Publiez les noms des autorités de certification de confiance :** choisissez si vous souhaitez annoncer les noms des autorités de certification de votre boutique de confiance aux clients lors de la poignée de main TLS.
   + **Ignorer la date d'expiration du certificat :** choisissez si vous souhaitez autoriser les connexions avec des certificats expirés (les autres critères de validation s'appliquent toujours).
   + **Fonction de connexion :** une fonction de connexion optionnelle peut être associée aux allow/deny connexions en fonction d'autres critères personnalisés.

1. Sélectionnez une ou plusieurs distributions à associer au trust store. Seules les distributions dont les comportements de cache sont HTTP3 désactivés ou dont les comportements de cache sont uniquement HTTPS peuvent prendre en charge les fichiers MTL Viewer.

1. Choisissez **Associer**.

**Associer un trust store via la page des paramètres de distribution :**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Sélectionnez la distribution que vous souhaitez associer

1. Sous l'onglet **Général**, dans le conteneur **Paramètres**, choisissez **Modifier** dans le coin supérieur droit

1. Faites défiler la page vers le bas, dans le conteneur de **connectivité**, activez le commutateur **Viewer mTLS**

1. Configurez les options mTLS du Viewer disponibles :
   + **Mode de validation du certificat client :** choisissez entre le mode obligatoire et le mode facultatif. En mode obligatoire, tous les clients sont tenus de présenter des certificats. En mode facultatif, les clients qui présentent des certificats sont validés, tandis que les clients qui ne présentent pas de certificats sont autorisés à y accéder.
   + **Publiez les noms des autorités de certification de confiance :** choisissez si vous souhaitez annoncer les noms des autorités de certification de votre boutique de confiance aux clients lors de la poignée de main TLS.
   + **Ignorer la date d'expiration du certificat :** choisissez si vous souhaitez autoriser les connexions avec des certificats expirés (les autres critères de validation s'appliquent toujours).
   + **Fonction de connexion :** une fonction de connexion optionnelle peut être associée aux allow/deny connexions en fonction d'autres critères personnalisés.

1. Choisissez **Enregistrer les modifications** dans le coin inférieur droit.

### Pour associer un trust store (AWS CLI)
<a name="associate-trust-store-cli"></a>

Les magasins de confiance peuvent être associés aux distributions via le DistributionConfig. ViewerMtlsConfig propriété. Cela signifie que nous devons d'abord récupérer la configuration de distribution, puis la fournir ViewerMtlsConfig dans une UpdateDistribution demande ultérieure.

```
// 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
```

## Gérez les magasins de confiance
<a name="manage-trust-stores"></a>

### Afficher les détails de Trust Store
<a name="view-trust-store-details"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, choisissez **Trust stores**.

1. Choisissez le nom du trust store pour afficher sa page de détails.

La page de détails présente :
+ Nom et identifiant du magasin de confiance
+ Nombre de certificats CA
+ Date de création et date de dernière modification
+ Distributions associées
+ Étiquettes

### Modifier un trust store
<a name="modify-trust-store"></a>

Pour remplacer le bundle de certificats CA :

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, choisissez **Trust stores**.

1. Choisissez le nom du trust store.

1. Choisissez **Actions**, puis **Modifier**.

1. Pour le **bundle d'autorité de certification (CA)**, entrez l'emplacement Amazon S3 du fichier PEM du bundle CA mis à jour.

1. Choisissez **Update Trust Store**.

### Supprimer un trust store
<a name="delete-trust-store"></a>

**Conditions préalables :** vous devez d'abord dissocier le trust store de toutes les CloudFront distributions.

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, choisissez **Trust stores**.

1. Choisissez le nom du trust store.

1. Choisissez **Supprimer le trust store**.

1. Choisissez **Supprimer** pour confirmer.

### Étapes suivantes
<a name="trust-store-next-steps"></a>

Après avoir créé et associé votre trust store à une CloudFront distribution, vous pouvez activer l'authentification TLS mutuelle sur votre distribution et configurer des paramètres supplémentaires tels que le transfert des en-têtes de certificats vers vos origines. Pour obtenir des instructions détaillées sur l'activation des MTLs sur vos distributions, consultez[Activer le protocole TLS mutuel pour les distributions CloudFront](enable-mtls-distributions.md).

# Activer le protocole TLS mutuel pour les distributions CloudFront
<a name="enable-mtls-distributions"></a>

## Prérequis et exigences
<a name="mtls-prerequisites-requirements"></a>

CloudFrontle mode de vérification TLS mutuelle oblige tous les clients à présenter des certificats valides lors de la prise de contact TLS et rejette les connexions sans certificats valides. Avant d'activer le protocole TLS mutuel sur une CloudFront distribution, assurez-vous d'avoir :
+ Création d'un magasin de confiance avec les certificats de votre autorité de certification
+ Associez le trust store à votre CloudFront distribution
+ Garantie que tous les comportements du cache de distribution utilisent une politique de protocole de visualisation HTTPS uniquement
+ Assurez-vous que votre distribution utilise le protocole HTTP/2 (paramètre par défaut, Viewer mTLS, n'est pas pris en charge sur HTTP/3)

**Note**  
L'authentification TLS mutuelle nécessite des connexions HTTPS entre les utilisateurs et CloudFront. Vous ne pouvez pas activer le protocole MTL sur une distribution dont les comportements de cache prennent en charge les connexions HTTP.

## Activer le protocole TLS mutuel (console)
<a name="enable-mtls-console"></a>

### Pour les nouvelles distributions
<a name="enable-mtls-new-distributions"></a>

Les fichiers MTL Viewer ne peuvent pas être configurés lors de la création d'une nouvelle distribution dans la CloudFront console. Créez d'abord la distribution par n'importe quel moyen (console, CLI, API), puis modifiez les paramètres de distribution pour activer Viewer MTL conformément aux instructions de distribution existantes ci-dessous.

### Pour les distributions existantes
<a name="enable-mtls-existing-distributions"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans la liste de distribution, sélectionnez la distribution que vous souhaitez modifier.

1. Assurez-vous que la politique du protocole Viewer est définie sur **Rediriger le HTTP vers HTTPS** ou **HTTPS uniquement** pour tous les comportements du cache. (Vous pouvez choisir l'onglet **Comportements du cache** pour afficher et mettre à jour les comportements du cache conformément aux politiques du protocole HTTP.)

1. Choisissez l'onglet **Général**.

1. Dans la section **Settings** (Paramètres), choisissez **Edit** (Modifier).

1. Dans la section **Connectivité**, recherchez l'**authentification mutuelle (mTLS) du visualiseur**.

1. Activez **Activer l'authentification mutuelle**.

1. Pour **le mode de validation du certificat client**, sélectionnez **Obligatoire** (tous les clients doivent présenter des certificats) ou **Facultatif** (les clients peuvent éventuellement présenter des certificats).

1. Pour **Trust store**, sélectionnez le trust store que vous avez créé précédemment.

1. (Facultatif) Activez **Advertise trust store CA names** si vous souhaitez envoyer des noms CloudFront d'autorité de certification aux clients lors de la prise de contact TLS.

1. (Facultatif) Activez l'option **Ignorer la date d'expiration du certificat** si vous souhaitez autoriser les connexions avec des certificats expirés.

1. Sélectionnez **Enregistrer les modifications**.

## Activer le protocole TLS mutuel (AWS CLI)
<a name="enable-mtls-cli"></a>

### Pour les nouvelles distributions
<a name="enable-mtls-cli-new"></a>

L'exemple suivant montre comment créer un fichier de configuration de distribution (distribution-config.json) qui inclut les paramètres 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
}
```

Créez la distribution avec mTLS activé à l'aide de l'exemple de commande suivant :

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

### Pour les distributions existantes
<a name="enable-mtls-cli-existing"></a>

Obtenez la configuration de distribution actuelle à l'aide de l'exemple de commande suivant :

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

Modifiez le fichier pour ajouter les paramètres mTLS. Ajoutez la section d'exemple suivante à votre configuration de distribution :

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

Supprimez le ETag champ du fichier mais enregistrez sa valeur séparément.

Mettez à jour la distribution avec la nouvelle configuration à l'aide de l'exemple de commande suivant :

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

## Politiques du protocole Viewer
<a name="viewer-protocol-policies"></a>

Lorsque vous utilisez le protocole TLS mutuel, tous les comportements du cache de distribution doivent être configurés selon une politique de protocole de visualisation HTTPS uniquement :
+ **Rediriger le HTTP vers HTTPS :** redirige les requêtes HTTP vers le protocole HTTPS avant de procéder à la validation du certificat.
+ **HTTPS uniquement :** accepte uniquement les requêtes HTTPS et effectue la validation des certificats.

**Note**  
La politique du protocole d'affichage HTTP et HTTPS n'est pas prise en charge avec le protocole TLS mutuel, car les connexions HTTP ne peuvent pas effectuer de validation de certificat.

## Étapes suivantes
<a name="enable-mtls-next-steps"></a>

Après avoir activé Viewer TLS sur votre CloudFront distribution, vous pouvez associer des fonctions de connexion pour implémenter une logique de validation de certificat personnalisée. Les fonctions de connexion vous permettent d'étendre les capacités d'authentification mTLS intégrées grâce à des règles de validation personnalisées, à la vérification de la révocation des certificats et à la journalisation. Pour plus de détails sur la création et l'association de fonctions de connexion, consultez[Associer une fonction CloudFront de connexion](connection-functions.md).

# Associer une fonction CloudFront de connexion
<a name="connection-functions"></a>

CloudFront Les fonctions de connexion vous permettent d'implémenter une logique de validation de certificat personnalisée lors des connexions TLS, en fournissant des extensions aux fonctionnalités d'authentification MTLS intégrées.

## Que sont les fonctions de connexion ?
<a name="what-are-connection-functions"></a>

Les fonctions de connexion sont JavaScript des fonctions qui s'exécutent pendant le handshake TLS une fois que les certificats clients ont été validés. Le certificat client validé est transmis à la fonction de connexion, qui peut alors prendre une décision supplémentaire quant à l'octroi ou non de l'accès. Pour des informations détaillées sur les fonctions de connexion, consultez[Personnalisez à la périphérie avec CloudFront Functions](cloudfront-functions.md).

## Comment les fonctions de connexion fonctionnent avec les MTLs
<a name="how-connection-functions-work"></a>

Lorsqu'un client tente d'établir une connexion mTLS avec votre CloudFront distribution, la séquence suivante se produit :

1. Le client lance une prise de contact TLS avec un CloudFront emplacement périphérique.

1. CloudFront demande et reçoit un certificat client.

1. CloudFront effectue la validation standard des certificats par rapport à Trust Store.

1. Si le certificat passe la validation standard, CloudFront invoque votre fonction de connexion. S'il **IgnoreCertificateExpiry**est activé dans votre **ViewerMtlsConfig**, vos certificats expirés (mais valides pour le reste) sont également transmis à la fonction de connexion. Si les certificats clients ne sont pas valides, les fonctions de connexion ne seront pas invoquées.

1. Votre fonction de connexion reçoit les informations de certificat et les détails de connexion analysés.

1. Votre fonction prend une allow/deny décision basée sur une logique personnalisée.

1. CloudFront termine ou met fin à la connexion TLS selon votre décision.

Les fonctions de connexion sont invoquées à la fois pour le mode de vérification et le mode facultatif (lorsque les clients présentent des certificats).

## Création d'une fonction de connexion
<a name="create-connection-function"></a>

Vous pouvez créer des fonctions de connexion à l'aide de la CloudFront console ou de la AWS CLI.

### Pour créer une fonction de connexion (console)
<a name="create-connection-function-console"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, choisissez **Fonctions**.

1. Choisissez l'onglet **Fonctions de connexion**, puis sélectionnez **Créer une fonction de connexion**.

1. Entrez un nom de fonction unique au sein de votre AWS compte.

1. Sélectionnez **Continuer**.

1. Dans l'éditeur de fonctions, écrivez votre JavaScript code pour la validation du certificat. Le gestionnaire de fonctions doit appeler allow ou deny.

1. Facultatif : un KeyValue magasin peut être associé à la fonction de connexion pour implémenter le contrôle de révocation.

1. Sélectionnez **Enregistrer les modifications**.

### Pour créer une fonction de connexion (AWS CLI)
<a name="create-connection-function-cli"></a>

L'exemple suivant montre comment créer une fonction de connexion :

Écrivez le code de votre fonction dans un fichier séparé, par exemple 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
```

## Structure du code de la fonction de connexion
<a name="connection-function-code-structure"></a>

Les fonctions de connexion implémentent la fonction ConnectionHandler qui reçoit un objet de connexion contenant le certificat et les informations de connexion. Votre fonction doit utiliser l'un `connection.allow()` ou `connection.deny()` l'autre ou prendre une décision concernant la connexion.

### Exemple de fonction de connexion de base
<a name="basic-connection-function-example"></a>

L'exemple suivant montre une fonction de connexion simple qui vérifie le champ objet des certificats clients :

```
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();
    }
}
```

La spécification complète des propriétés du certificat client disponibles sur l'objet de connexion est disponible ici :

```
{
  "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)
      },
    },
  },
}
```

## Associer une fonction de connexion
<a name="associate-connection-function-section"></a>

Après avoir créé votre fonction de connexion, vous devez la publier sur la scène LIVE et l'associer à votre distribution.

### Pour publier et associer une fonction de connexion (console)
<a name="publish-associate-console"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, sélectionnez **Functions**

1. Choisissez l'onglet **Fonctions de connexion** et sélectionnez votre fonction de connexion.

1. Choisissez **Publier** pour le déplacer vers la scène LIVE.

1. Choisissez **Ajouter une association** dans le tableau des distributions associé situé sous la section de publication.

1. Sélectionnez la distribution à laquelle Viewer mTLS est activé et que vous souhaitez associer.

Les fonctions de connexion publiées de manière alternative peuvent également être associées à partir de la page de détails de distribution.

1. Accédez à la page d'accueil de la console où toutes vos distributions sont répertoriées.

1. Sélectionnez la distribution que vous souhaitez associer.

1. Choisissez l'onglet **Général**.

1. Dans la section **Settings** (Paramètres), choisissez **Edit** (Modifier).

1. Dans la section **Connectivité**, recherchez l'**authentification mutuelle (mTLS) du visualiseur**.

1. Pour **Fonction de connexion**, sélectionnez votre fonction.

1. Sélectionnez **Enregistrer les modifications**.

### Pour associer une fonction de connexion (AWS CLI)
<a name="associate-connection-function-cli"></a>

L'exemple suivant montre comment associer une fonction de connexion à une distribution :

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

## Cas d'utilisation des fonctions de connexion
<a name="connection-function-use-cases"></a>

Les fonctions de connexion permettent plusieurs cas d'utilisation avancés des MTL :
+ **Validation des attributs de certificat** : vérifiez des champs spécifiques dans les certificats clients, tels que les exigences relatives aux unités organisationnelles ou les modèles de noms alternatifs des sujets.
+ **Vérification de la révocation des certificats** - Mettez en œuvre une vérification personnalisée de la révocation des certificats KeyValueStore pour stocker les numéros de série des certificats révoqués.
+ **Politiques de certification basées sur l'IP** : appliquez différentes politiques de certification en fonction des adresses IP des clients ou des restrictions géographiques.
+ **Validation multi-locataires** : implémentez des règles de validation spécifiques au locataire dans lesquelles différentes exigences de certificat s'appliquent en fonction des noms d'hôte ou des attributs des certificats.

**Note**  
Les fonctions de connexion s'exécutent une fois par connexion client lors de la prise de contact TLS.  
Les fonctions de connexion peuvent uniquement autoriser ou refuser les connexions, pas modifier les requêtes/réponses HTTP.  
Seules les fonctions de scène LIVE (publiées) peuvent être associées aux distributions.  
Chaque distribution peut avoir au plus une fonction de connexion.

## Étapes suivantes
<a name="connection-function-next-steps"></a>

Après avoir associé une fonction de connexion à votre CloudFront distribution, vous pouvez configurer des paramètres facultatifs pour personnaliser le comportement de votre implémentation mTLS. Pour obtenir des instructions détaillées sur la configuration de paramètres supplémentaires tels qu'un mode de validation de certificat client facultatif, consultez[Configuration de paramètres supplémentaires](configuring-additional-settings.md).

# Configuration de paramètres supplémentaires
<a name="configuring-additional-settings"></a>

Après avoir activé l'authentification TLS mutuelle de base, vous pouvez configurer des paramètres supplémentaires pour personnaliser le comportement d'authentification en fonction de cas d'utilisation et d'exigences spécifiques.

## Validation du certificat client Mode facultatif
<a name="optional-mode"></a>

CloudFront propose un autre mode facultatif de validation des certificats clients qui valide les certificats clients présentés mais autorise l'accès aux clients qui ne présentent pas de certificats.

### Comportement du mode facultatif
<a name="optional-mode-behavior"></a>
+ Accorde la connexion aux clients dotés de certificats valides (les certificats non valides sont refusés).
+ Permet la connexion aux clients sans certificat
+ Permet des scénarios d'authentification client mixtes via une distribution unique.

Le mode optionnel est idéal pour la migration progressive vers l'authentification mTLS, la prise en charge des clients détenteurs de certificats et des clients dépourvus de certificats, ou le maintien de la rétrocompatibilité avec les anciens clients.

**Note**  
En mode facultatif, les fonctions de connexion sont toujours invoquées même lorsque les clients ne présentent pas de certificats. Cela vous permet d'implémenter une logique personnalisée telle que la journalisation des adresses IP des clients ou l'application de politiques différentes en fonction de la présentation des certificats.

### Pour configurer le mode facultatif (console)
<a name="configure-optional-mode-console"></a>

1. Dans vos paramètres de distribution, accédez à l'onglet **Général**, puis choisissez **Modifier**.

1. Accédez à la section **Authentification mutuelle (mTLS) du visualiseur** dans le conteneur de **connectivité**.

1. Pour **le mode de validation du certificat client**, sélectionnez **Facultatif**.

1. Enregistrez les modifications.

### Pour configurer le mode facultatif (AWS CLI)
<a name="configure-optional-mode-cli"></a>

L'exemple suivant montre comment configurer le mode facultatif :

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

## Publicité de l'autorité de certification
<a name="ca-advertisement"></a>

Le AdvertiseTrustStoreCaNames champ contrôle si CloudFront la liste des noms d'autorités de certification fiables est envoyée aux clients lors de la prise de contact TLS, afin d'aider les clients à sélectionner le certificat approprié.

### Pour configurer la publicité CA (console)
<a name="configure-ca-advertisement-console"></a>

1. Dans vos paramètres de distribution, accédez à l'onglet **Général**, puis choisissez **Modifier**.

1. Accédez à la section **Authentification mutuelle (mTLS) du visualiseur** dans le conteneur de **connectivité**.

1. Cochez ou désélectionnez la case **Advertise Trust Store CA names**.

1. Sélectionnez **Enregistrer les modifications**.

### Pour configurer la publicité CA (AWS CLI)
<a name="configure-ca-advertisement-cli"></a>

L'exemple suivant montre comment activer la publicité CA :

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

## Gestion de l'expiration des certificats
<a name="certificate-expiration-handling"></a>

La IgnoreCertificateExpiry propriété détermine le mode CloudFront de réponse aux certificats clients expirés. Par défaut, CloudFront rejette les certificats clients expirés, mais vous pouvez le configurer pour les accepter si nécessaire. Ceci est généralement activé pour les appareils dont les certificats ont expiré et qui ne peuvent pas être facilement mis à jour.

### Pour configurer la gestion de l'expiration des certificats (console)
<a name="configure-expiration-console"></a>

1. Dans vos paramètres de distribution, accédez à l'onglet **Général**, puis choisissez **Modifier**.

1. Accédez à la section **Authentification mutuelle (mTLS) Viewer** du conteneur de **connectivité**.

1. Cochez ou désélectionnez la case **Ignorer la date d'expiration du certificat**.

1. Sélectionnez **Enregistrer les modifications**.

### Pour configurer la gestion de l'expiration des certificats (AWS CLI)
<a name="configure-expiration-cli"></a>

L'exemple suivant montre comment ignorer l'expiration d'un certificat :

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

**Note**  
**IgnoreCertificateExpiry**ne s'applique qu'aux dates de validité des certificats. Tous les autres contrôles de validation des certificats s'appliquent toujours (chaîne de confiance, validation de signature).

## Étapes suivantes
<a name="additional-settings-next-steps"></a>

Après avoir configuré des paramètres supplémentaires, vous pouvez configurer le transfert d'en-têtes pour transmettre les informations de certificat à vos origines, implémenter la révocation des certificats à l'aide des fonctions de connexion et KeyValueStore activer les journaux de connexion à des fins de surveillance. Pour plus de détails sur le transfert des informations de certificat vers les origines, voir [Transférer les en-têtes vers les origines](viewer-mtls-headers.md).

# En-têtes MTLS Viewer pour les politiques de cache et transférés à l'origine
<a name="viewer-mtls-headers"></a>

Lorsque vous utilisez l'authentification TLS mutuelle, CloudFront vous pouvez extraire des informations des certificats clients et les transmettre à vos origines sous forme d'en-têtes HTTP. Cela permet à vos serveurs d'origine d'accéder aux détails des certificats sans implémenter de logique de validation des certificats.

Les en-têtes suivants sont disponibles pour créer des comportements de cache :


| Nom de l’en-tête | Description | Exemple de valeur | 
| --- | --- | --- | 
| CloudFront-Numéro de série Viewer-Cert | Représentation hexadécimale du numéro de série du certificat | 4a : 3 f : 5 c : 92 : d : e 8 : 7 b : 6 c | 
| CloudFront-Viewer-Cert-Emetteur | RFC2253 représentation sous forme de chaîne du nom distinctif (DN) de l'émetteur | CN=Rootcamtls.com, OU = Rootca, O = MTLS, L = Seattle, ST = Washington, C = États-Unis | 
| CloudFront-Viewer-Cert-Sujet | RFC2253 représentation sous forme de chaîne du nom distinctif (DN) du sujet | CN=Client\$1.com, OU = Client-3, O = MTLS, ST = Washington, C = États-Unis | 
| CloudFront-Viewer-Cert-Present | 1 (présent) ou 0 (absent) indiquant si le certificat est présent. Cette valeur est toujours égale à 1 en mode obligatoire. | 1 | 
| CloudFront-Viewer-Cert-Sha256 | Le SHA256 hachage du certificat client | 01fbf94fef5569753420c349f49adbfd80af5275377816e3ab1fb371b29cb586 | 

Pour les demandes d'origine, deux en-têtes supplémentaires sont fournis, en plus des en-têtes ci-dessus mis à disposition pour les comportements du cache. En raison de la taille potentielle de l' CloudFront-Viewer-Cert-Pemen-tête, l'en-tête n'est pas exposé aux fonctions périphériques (Lambda @Edge ou CloudFront Functions) et est uniquement transmis à l'origine.


| Nom de l’en-tête | Description | Exemple de valeur | 
| --- | --- | --- | 
| CloudFront-Validité du certificat de visualisation | ISO8601 format des dates NotBefore et NotAfter | CloudFront- Validité du certificat d'affichage : =2024-09-21T 01:50:17 Z ; NotBefore =2024-09-20T 01:50:17 Z NotAfter | 
| CloudFront-Viewer-Cert-Pem | Format PEM codé par URL du certificat feuille | CloudFront-Viewer-Cert-Pem : -----BEGIN%20CERTIFICATE-----%0AMIIG<... réduit... > NmrUlw %0A----END%20CERTIFICAT------------A | 

## Configurer le transfert d'en-têtes
<a name="configure-header-forwarding"></a>

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

En mode vérification, ajoute CloudFront automatiquement les en-têtes CloudFront-Viewer-Cert -\$1 à toutes les demandes des utilisateurs. Pour transférer ces en-têtes vers votre source :

1. Sur la page principale des distributions de la liste, sélectionnez votre distribution avec les lecteurs MTL activés et accédez à l'onglet **Comportements**

1. Sélectionnez le comportement du cache et choisissez **Modifier**

1. Dans la section **Politique de demande d'origine**, choisissez **Créer une politique** ou sélectionnez une politique existante

1. Assurez-vous que les en-têtes suivants sont inclus dans la politique de demande d'origine :
   + CloudFront-Numéro de série Viewer-Cert
   + CloudFront-Viewer-Cert-Emetteur
   + CloudFront-Viewer-Cert-Sujet
   + CloudFront-Viewer-Cert-Present
   + Cloudfront Viewer-Cert-Sha256
   + CloudFront-Validité du certificat de visualisation
   + CloudFront-Viewer-Cert-Pem

1. Choisissez **Créer** (pour les nouvelles politiques) ou **Enregistrer les modifications** (pour les politiques existantes)

1. Sélectionnez la politique dans le comportement de votre cache et enregistrez les modifications

### Utilisation de la AWS CLI
<a name="configure-headers-cli"></a>

L'exemple suivant montre comment créer une politique de demande d'origine qui inclut les en-têtes mTLS pour le mode vérification :

```
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"
    }
  }'
```

## Considérations relatives au traitement des en-
<a name="header-processing-considerations"></a>

Lorsque vous travaillez avec des en-têtes de certificat, tenez compte des meilleures pratiques suivantes :
+ **Validation des en-têtes :** vérifiez les valeurs des en-têtes des certificats à l'origine comme mesure de sécurité supplémentaire
+ **Limites de taille des en-têtes :** les en-têtes des certificats PEM peuvent être volumineux, assurez-vous que votre serveur d'origine peut les gérer
+ **Considérations relatives au cache :** l'utilisation d'en-têtes de certificat dans votre clé de cache augmente la fragmentation du cache
+ **Demandes d'origine croisée :** si votre application utilise le CORS, vous devrez peut-être le configurer pour autoriser les en-têtes de certificat

## Étapes suivantes
<a name="headers-next-steps"></a>

Après avoir configuré le transfert d'en-têtes, vous pouvez implémenter la vérification de révocation des certificats à l'aide des fonctions de CloudFront connexion et KeyValueStore. Pour plus de détails sur la mise en œuvre des contrôles de révocation, consultez[Révocation à l'aide de la fonction CloudFront de connexion et du KVS](revocation-connection-function-kvs.md).

# Révocation à l'aide de la fonction CloudFront de connexion et du KVS
<a name="revocation-connection-function-kvs"></a>

Vous pouvez implémenter le contrôle de révocation des certificats pour l'authentification TLS mutuelle en combinant les fonctions de CloudFront connexion avec. KeyValueStore Cette approche fournit un mécanisme de révocation des certificats évolutif et en temps réel qui complète CloudFront la validation des certificats intégrée.

Les fonctions de connexion sont des JavaScript fonctions qui s'exécutent lors de l'établissement de la connexion TLS sur des sites CloudFront périphériques et vous permettent de mettre en œuvre une logique de validation de certificat personnalisée pour l'authentification MTLS. Pour des informations détaillées sur les fonctions de connexion, consultez[Associer une fonction CloudFront de connexion](connection-functions.md).

## Comment fonctionne la révocation des certificats avec Connection Functions
<a name="how-revocation-works"></a>

CloudFrontla validation standard des certificats vérifie la chaîne de certificats, la signature et l'expiration, mais n'inclut pas le contrôle intégré de révocation des certificats. En utilisant les fonctions de connexion, vous pouvez implémenter un contrôle de révocation personnalisé lors de la prise de contact TLS.

Le processus de révocation des certificats se déroule comme suit :

1. Stockez les numéros de série des certificats révoqués dans un CloudFront KeyValueStore.

1. Lorsqu'un client présente un certificat, votre fonction de connexion est invoquée.

1. La fonction compare le numéro de série du certificat au KeyValueStore.

1. Si le numéro de série se trouve dans le magasin, le certificat est révoqué.

1. Votre fonction refuse la connexion pour les certificats révoqués.

Cette approche permet de vérifier les near-real-time révocations sur CloudFront le réseau périphérique mondial.

## Configuration KeyValueStore pour les certificats révoqués
<a name="setup-kvs-revoked-certs"></a>

Tout d'abord, créez un KeyValueStore pour stocker les numéros de série des certificats révoqués :

### Pour créer une KeyValueStore (console)
<a name="create-kvs-console"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, sélectionnez **Key value stores**.

1. Choisissez **Créer un magasin de valeurs clés**.

1. Entrez un nom pour votre magasin de valeurs clés (par exemple, certificats révoqués).

1. (Facultatif) Ajoutez une description.

1. Choisissez **Créer un magasin de valeurs clés**.

### Pour créer une KeyValueStore (AWS CLI)
<a name="create-kvs-cli"></a>

L'exemple suivant montre comment créer un KeyValueStore :

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

## Importer les numéros de série des certificats révoqués
<a name="import-revoked-serials"></a>

Après avoir créé un KeyValueStore, vous devez importer les numéros de série des certificats révoqués :

### Préparer les données de révocation
<a name="prepare-revocation-data"></a>

Créez un fichier JSON avec les numéros de série de vos certificats révoqués :

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

### Importer des données depuis S3
<a name="import-from-s3"></a>

1. Téléchargez le fichier JSON dans un compartiment S3

1. Importez le fichier dans votre 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"
     }'
   ```

## Créer une fonction de connexion pour vérifier les révocations
<a name="create-revocation-connection-function"></a>

Créez une fonction de connexion qui vérifie les numéros de série des certificats par rapport à vos KeyValueStore :

### Exemple de code de fonction de connexion
<a name="revocation-function-example"></a>

L'exemple suivant montre une fonction de connexion qui vérifie la révocation des certificats :

```
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();
    }
    
}
```

### Pour créer la fonction de connexion (AWS CLI)
<a name="create-revocation-function-cli"></a>

L'exemple suivant montre comment créer une fonction de connexion avec KeyValueStore association :

```
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
```

## Associez la fonction à votre distribution
<a name="associate-revocation-function"></a>

Après avoir créé et publié votre fonction de connexion, associez-la à votre CloudFront distribution compatible MTLS comme décrit dans la section. [Associer une fonction CloudFront de connexion](connection-functions.md)

# Observabilité à l'aide des journaux de connexion
<a name="connection-logs"></a>

CloudFront les journaux de connexion fournissent une visibilité détaillée sur les événements d'authentification TLS mutuels, ce qui vous permet de surveiller la validation des certificats, de suivre les tentatives de connexion et de résoudre les problèmes d'authentification.

## Que sont les journaux de connexion ?
<a name="what-are-connection-logs"></a>

Les journaux de connexion capturent des informations détaillées sur les connexions TLS et la validation des certificats pour les distributions mutuelles compatibles TLS. Contrairement aux journaux d'accès standard qui enregistrent les informations relatives aux requêtes HTTP, les journaux de connexion se concentrent spécifiquement sur la phase d'établissement de la connexion TLS, notamment :
+ État de la connexion (succès/échec)
+ Détails du certificat client
+ Protocole TLS et informations de chiffrement
+ Métriques de synchronisation des connexions
+ Données personnalisées provenant de Connection Functions

Ces journaux fournissent une visibilité complète sur les événements d'authentification basés sur des certificats, ce qui vous aide à surveiller la sécurité, à résoudre les problèmes et à respecter les exigences de conformité.

## Activer les journaux de connexion
<a name="enable-connection-logs"></a>

Les journaux de connexion ne sont disponibles que pour les distributions où l'authentification TLS mutuelle est activée. Vous pouvez envoyer des journaux de connexion vers plusieurs destinations, notamment CloudWatch Logs, Amazon Data Firehose et Amazon S3.

### Conditions préalables
<a name="connection-logs-prerequisites"></a>

Avant d'activer les journaux de connexion :
+ Configurez le protocole TLS mutuel pour votre distribution CloudFront 
+ Activez les journaux de connexion pour votre CloudFront distribution
+ Assurez-vous de disposer des autorisations requises pour la destination de journalisation que vous avez choisie
+ Pour la livraison entre comptes, configurez les politiques IAM appropriées

### Pour activer les journaux de connexion (console)
<a name="enable-connection-logs-console"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans la liste de distribution, sélectionnez votre distribution compatible MTLS.

1. Sélectionnez l'onglet **Logging** (Journalisation).

1. Choisissez **Ajouter**.

1. Sélectionnez le service pour recevoir vos journaux :
   + **CloudWatch Journaux**
   + **Firehose**
   + **Amazon S3**

1. Pour **Destination**, sélectionnez la ressource correspondant au service que vous avez choisi :
   + Pour CloudWatch Logs, entrez le **nom du groupe de logs**
   + **Pour Firehose, sélectionnez le flux de diffusion Firehose**
   + Pour Amazon S3, entrez le **nom du compartiment** (éventuellement avec un préfixe)

1. (Facultatif) Configurez des paramètres supplémentaires :
   + **Sélection des champs :** sélectionnez les champs de journal spécifiques à inclure.
   + **Format de sortie :** Choisissez entre JSON, Plain, W3C, Raw ou Parquet (S3 uniquement).
   + **Délimiteur de champs :** spécifiez comment séparer les champs du journal.

1. Choisissez **Enregistrer les modifications**

### Pour activer les journaux de connexion (AWS CLI)
<a name="enable-connection-logs-cli"></a>

L'exemple suivant montre comment activer les journaux de connexion à l'aide de l' CloudWatch API :

```
# 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"
```

**Note**  
Lorsque vous utilisez l' CloudWatch API, vous devez spécifier la région USA Est (Virginie du Nord) (us-east-1) même lorsque vous distribuez des logs à d'autres régions.

## Champs du journal de connexion
<a name="connection-log-fields"></a>

Les journaux de connexion contiennent des informations détaillées sur chaque tentative de connexion TLS :


| Champ | Description | Exemple | 
| --- | --- | --- | 
| eventTimestamp | Horodatage ISO 8601 lorsque la connexion a été établie ou a échoué | 1731620046814 | 
| connectionId | Identifiant unique pour la connexion TLS | oLHiEKbQSn8lkvJfA3D4gFowK3\$1iZ0g4i5nMUjE1Akod8TuAzn5nzg== | 
| connectionStatus |  État de la tentative de connexion mTLS.  | Success ou Failed | 
| clientIp | Adresse IP du client qui se connecte | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 
| clientPort | Port utilisé par le client | 12137 | 
| serverIp | Adresse IP du serveur CloudFront Edge | 99.84.71.136 | 
| distributionId | CloudFront ID de distribution | E2DX1SLDPK0123 | 
| distributionTenantId | CloudFront ID du locataire de distribution (le cas échéant) | dt\$12te1Ura9X3R2iCGNjW123 | 
| tlsProtocol | Version du protocole TLS utilisée | TLSv1.3 | 
| tlsCipher | Suite de chiffrement TLS utilisée pour la connexion | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| tlsHandshakeDuration | Durée de la poignée de main TLS en millisecondes | 153 | 
| tlsSni | Valeur d'indication du nom du serveur issue de la poignée de contact TLS | d111111abcdef8.cloudfront.net | 
| clientLeafCertSerialNumber | Numéro de série du certificat du client | 00:b1:43:ed:93:d2:d8:f3:9d | 
| clientLeafCertSubject | Champ d'objet du certificat du client | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=client.test.mtls.net | 
| clientLeafCertIssuer | Champ émetteur du certificat du client | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=test.mtls.net | 
| clientLeafCertValidity | Période de validité du certificat du client | NotBefore=2025-06-05T23:28:21Z;NotAfter=2125-05-12T23:28:21Z | 
| connectionLogCustomData | Données personnalisées ajoutées via les fonctions de connexion | REVOKED:00:b1:43:ed:93:d2:d8:f3:9d | 

## Codes d'erreur de connexion
<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
```

Lorsque les connexions échouent, CloudFront enregistre des codes de motif spécifiques :


| Code | Description | 
| --- | --- | 
| ClientCertMaxChainDepthExceeded | Profondeur maximale de la chaîne de certificats dépassée | 
| ClientCertMaxSizeExceeded | Taille maximale du certificat dépassée | 
| ClientCertUntrusted | Le certificat n'est pas fiable | 
| ClientCertNotYetValid | Le certificat n'est pas encore valide | 
| ClientCertExpired | Le certificat est expiré | 
| ClientCertTypeUnsupported | Le type de certificat n'est pas pris en charge | 
| ClientCertInvalid | Le certificat n'est pas valide | 
| ClientCertIntentInvalid | L'intention du certificat n'est pas valide | 
| ClientCertRejected | Certificat rejeté par validation personnalisée | 
| ClientCertMissing | Le certificat est manquant | 
| TcpError |  Une erreur s'est produite lors de la tentative d'établissement d'une connexion  | 
| TcpTimeout |  La connexion n'a pas pu être établie dans le délai imparti  | 
| ConnectionFunctionError |  Une exception non détectée a été déclenchée lors de l'exécution de la fonction de connexion  | 
| Internal (Interne) |  Une erreur de service interne s'est produite  | 
| UnmappedConnectionError |  Une erreur s'est produite qui ne correspond à aucune des autres catégories  | 

# Origin Mutual TLS avec CloudFront
<a name="origin-mtls-authentication"></a>

L'authentification TLS mutuelle (Mutual Transport Layer Security Authentication — MTLS) est un protocole de sécurité qui étend l'authentification TLS standard en exigeant une authentification bidirectionnelle basée sur des certificats, dans laquelle le client et le serveur doivent prouver leur identité avant d'établir une connexion sécurisée.

## MTL Viewer et MTL Origin
<a name="viewer-mtls-vs-origin-mtls"></a>

L'authentification mutuelle (MTL) peut être activée entre les spectateurs et votre CloudFront distribution (MTL des spectateurs), and/or ainsi qu'entre votre CloudFront distribution et l'origine (MTL d'origine). Cette documentation concerne la configuration des MTL d'origine. Pour la configuration MTL du viewer, reportez-vous à :[Authentification TLS mutuelle avec CloudFront (Viewer MTLS)Origin Mutual TLS avec CloudFront](mtls-authentication.md).

Origin mTLS permet CloudFront de s'authentifier auprès de vos serveurs d'origine à l'aide de certificats clients. Avec les MTL d'origine, vous pouvez vous assurer que seules vos CloudFront distributions autorisées peuvent établir des connexions avec vos serveurs d'applications, ce qui contribue à la protection contre les tentatives d'accès non autorisées.

**Note**  
Dans les connexions MTL d'origine, CloudFront agit en tant que client et présente son certificat client à votre serveur d'origine lors de la prise de contact TLS. CloudFront n'effectue pas de validation de la validité ou du statut de révocation du certificat client. Cela relève de la responsabilité de votre serveur d'origine. Votre infrastructure d'origine doit être configurée pour valider le certificat client par rapport à son magasin de confiance, vérifier l'expiration du certificat et effectuer des contrôles de révocation (tels que la validation CRL ou OCSP) conformément à vos exigences de sécurité. CloudFrontson rôle se limite à présenter le certificat ; toutes les logiques de validation des certificats et les politiques de sécurité sont appliquées par vos serveurs d'origine.

## Comment ça marche
<a name="how-origin-mtls-works"></a>

Lors d'une prise de contact TLS standard entre CloudFront et une origine, seul le serveur d'origine présente un certificat pour prouver son identité. CloudFront Avec les MTL d'origine, le processus d'authentification devient bidirectionnel. Lorsque vous CloudFront tentez de vous connecter à votre serveur d'origine, CloudFront présente un certificat client lors de la prise de contact TLS. Votre serveur d'origine valide ce certificat par rapport à son magasin de confiance avant d'établir la connexion sécurisée.

## Cas d’utilisation
<a name="origin-mtls-use-cases"></a>

Origin MTLS répond à plusieurs scénarios de sécurité critiques dans lesquels les méthodes d'authentification traditionnelles génèrent une surcharge opérationnelle :
+ **Sécurité hybride et multicloud** : vous pouvez sécuriser les connexions CloudFront et les origines hébergées à l'extérieur AWS ou les origines publiques sur AWS. Ainsi, il n'est plus nécessaire de gérer des listes d'adresses IP autorisées ou des solutions d'en-tête personnalisées, en fournissant une authentification cohérente AWS basée sur des certificats dans les centres de données locaux et les fournisseurs tiers. Les entreprises du secteur des médias, les détaillants et les entreprises exploitant une infrastructure distribuée bénéficient de contrôles de sécurité standardisés sur l'ensemble de leur infrastructure.
+ **API B2B et sécurité du backend** : vous pouvez protéger votre backend APIs et vos microservices contre les tentatives d'accès direct tout en préservant CloudFront les avantages en termes de performances. Les plateformes SaaS, les systèmes de traitement des paiements et les applications d'entreprise soumis à des exigences d'authentification strictes peuvent vérifier que les demandes d'API proviennent uniquement de CloudFront distributions autorisées, empêchant ainsi man-in-the-middle les attaques et les tentatives d'accès non autorisées.

## Important : configuration requise pour le serveur Origin
<a name="important-origin-server-requirements"></a>

Origin MTLS nécessite que vos serveurs d'origine soient configurés pour prendre en charge l'authentification TLS mutuelle. Votre infrastructure d'origine doit être capable de :
+ Demande et validation de certificats clients lors des handshakes TLS
+ Gestion d'une banque de confiance avec les certificats de l'autorité de certification qui CloudFront a émis les certificats clients
+ Enregistrement et surveillance des événements de connexion TLS mutuels
+ Gestion des politiques de validation des certificats et gestion des échecs d'authentification

CloudFront gère la présentation des certificats côté client, mais vos serveurs d'origine sont responsables de la validation de ces certificats et de la gestion de la connexion TLS mutuelle. Assurez-vous que votre infrastructure d'origine est correctement configurée avant d'activer les MTL d'origine dans CloudFront.

## Prise en main
<a name="how-origin-mtls-getting-started"></a>

Pour implémenter les MTL d'origine avec CloudFront, vous devez importer le certificat client dans AWS Certificate Manager, configurer votre serveur d'origine pour qu'il exige le protocole TLS mutuel et activer les MTL d'origine sur votre distribution. CloudFront Les sections suivantes fournissent des step-by-step instructions pour chaque tâche de configuration.

**Topics**
+ [MTL Viewer et MTL Origin](#viewer-mtls-vs-origin-mtls)
+ [Comment ça marche](#how-origin-mtls-works)
+ [Cas d’utilisation](#origin-mtls-use-cases)
+ [Important : configuration requise pour le serveur Origin](#important-origin-server-requirements)
+ [Prise en main](#how-origin-mtls-getting-started)
+ [Gestion des certificats avec AWS Certificate Manager](origin-certificate-management-certificate-manager.md)
+ [Activer le protocole TLS mutuel d'origine pour les distributions CloudFront](origin-enable-mtls-distributions.md)
+ [Utilisation de CloudFront fonctions avec Origin Mutual TLS](origin-mtls-cloudfront-functions.md)

# Gestion des certificats avec AWS Certificate Manager
<a name="origin-certificate-management-certificate-manager"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) stocke les certificats clients présentés à vos serveurs d'origine lors de l'authentification TLS mutuelle d'origine. CloudFront 

## Assistance aux autorités de certification
<a name="origin-ca-support"></a>

CloudFront origin mTLS nécessite des certificats clients avec utilisation étendue des clés (EKU) pour l'authentification client TLS. En raison de cette exigence, vous devez émettre des certificats auprès de votre autorité de certification et les importer dans AWS Certificate Manager. Les fonctionnalités de provisionnement et de renouvellement automatiques des certificats d'ACM ne sont pas disponibles pour les certificats clients MTL d'origine. CloudFront origin mTLS prend en charge les certificats clients provenant de deux sources :
+ **AWS Autorité de certification privée :** vous pouvez émettre des certificats depuis AWS une autorité de certification privée à l'aide de modèles de certificats qui incluent l'authentification du client TLS dans le champ Extended Key Usage (tel que le EndEntityClientAuthCertificate modèle). Après avoir émis le certificat par AWS Private CA, vous devez l'importer dans ACM dans la région USA Est (Virginie du Nord) (us-east-1). Cette approche offre les avantages de sécurité de l'autorité de certification AWS privée tout en vous permettant de contrôler la gestion du cycle de vie des certificats.
+ **Autorités de certification privées tierces :** vous pouvez également émettre des certificats à partir de votre infrastructure d'autorité de certification privée existante et les importer dans ACM. Cela vous permet de maintenir vos processus actuels de gestion des certificats tout en tirant CloudFront parti des capacités MTL d'origine. Les certificats doivent inclure l'authentification du client TLS dans le champ Utilisation étendue de la clé et doivent être au format PEM avec le certificat, la clé privée et la chaîne de certificats.

**Important**  
Que ce soit pour une autorité de certification AWS privée ou tierce CAs, vous êtes responsable de la surveillance des dates d'expiration des certificats et de l'importation des certificats renouvelés dans ACM avant leur expiration. La fonction de renouvellement automatique d'ACM ne s'applique pas aux certificats importés utilisés pour les MTL d'origine.

## Exigences et spécifications relatives aux certificats
<a name="origin-certificate-requirements"></a>

### Exigences relatives aux certificats clients
<a name="origin-ca-cert-format-requirements"></a>
+ **Format : format** PEM (Privacy Enhanced Mail)
+ **Composants :** certificat, clé privée et chaîne de certificats
+ **Profondeur maximale de la chaîne de certificats :** 3 (certificat feuille \$1 certificat intermédiaire \$1 certificat racine)
+ **Taille maximale de la chaîne de certificats :** 64 Ko
+ **Taille du certificat :** ne peut pas dépasser 96 Ko
+ **Taille maximale de la clé privée :** 5 Ko (restriction ACM)
+ **Nombre maximum de certificats mTLS d'origine uniques ARNs pouvant être ajoutés ou modifiés par appel d'API de création ou de mise à jour d'une CloudFront distribution : 5**
+ **Région :** Les certificats doivent être stockés dans ACM dans la région USA Est (Virginie du Nord) (us-east-1)

### Spécifications des certificats pris en charge
<a name="origin-supported-cert-specs"></a>
+ **Type de certificat : X.509v3**
+ **Algorithmes à clé publique :**
  + RSA : 2048 bits
  + ECDSA : P-256
+ **Algorithmes de signature :**
  + SHA256 SHA384, SHA512 avec RSA
  + SHA256 SHA384, SHA512 avec ECDSA
  + SHA256 SHA384, SHA512 avec RASSA-PSS avec MGF1
+ **Utilisation étendue des clés (obligatoire) :** le certificat nécessite que l'extension Extended Key Usage (EKU) soit définie sur Authentification client TLS, afin de garantir qu'il est autorisé aux fins du protocole MTL

### Exigences relatives aux certificats de serveur
<a name="origin-server-certificate-requirements"></a>

Vos serveurs d'origine doivent présenter des certificats provenant d'autorités de certification reconnues publiquement lors de la prise de contact TLS mutuelle. Pour obtenir des informations complètes sur les exigences relatives aux certificats du serveur d'origine, consultez la section [Exigences relatives à l'utilisation de SSL/TLS certificats avec CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate).

### Demander ou importer un certificat
<a name="origin-request-import-certificate"></a>

Avant d'activer les MTL d'origine, vous devez disposer d'un certificat client dans ACM.

#### Demander et importer un certificat auprès de AWS Private CA
<a name="request-certificate-aws-private-ca"></a>

Prérequis :
+ Une autorité de certification AWS privée configurée dans votre compte
+ Autorisation d'émettre des certificats depuis AWS une autorité de certification privée
+ Autorisation d'importer des certificats dans ACM
+ Un [modèle de certificat](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) (ARN) adapté à votre cas d'utilisation `Extended key usage:TLS web client authentication`
+ Installez OpenSSL AWS , CLI et jq (pour analyser le JSON).

##### Pour demander un certificat à la PCA et l'importer dans ACM (CLI)AWS
<a name="request-certificate-cli"></a>

1. Définissez votre ARN CA privé dans une variable pour une réutilisation plus facile.

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

1. Utilisez OpenSSL pour générer une clé privée ECDSA P-256 (courbe prime256v1) et une demande de signature de certificat (CSR), en vous assurant que l'indicateur -nodes est utilisé pour que la clé privée ne soit pas chiffrée, comme l'exige l'importation ACM.

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

1. Soumettez le CSR à votre autorité de certification AWS privée pour émettre un certificat, qui renvoie l'ARN du nouveau certificat.

   ```
   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. Récupérez le bundle de certificats auprès de AWS PCA à l'aide de la commande get-certificate, qui renvoie à la fois le certificat leaf et la chaîne, puis utilisez jq pour les séparer en fichiers distincts.

   ```
   # 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. Importez la clé privée, le certificat feuille et la chaîne de certificats non chiffrés dans AWS ACM, en utilisant le protocole fileb ://pour gérer correctement les données des fichiers binaires dans la 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
   ```

#### Importer un certificat depuis une autorité de certification tierce
<a name="import-certificate-third-party-ca"></a>

Prérequis :
+ Un certificat, une clé privée non chiffrée et une chaîne de certificats de votre autorité de certification au format PEM
+ Le certificat doit inclure l'utilisation étendue des clés pour l'authentification du client TLS
+ Autorisations d'importation de certificats dans ACM

##### Pour importer un certificat dans 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
```

#### Étapes suivantes
<a name="certificate-next-steps"></a>

Après avoir obtenu ou importé votre certificat client dans ACM, vous pouvez configurer votre serveur d'origine pour exiger une authentification TLS mutuelle et activer les MTL d'origine sur votre distribution. CloudFront Pour obtenir des instructions sur l'activation du protocole MTL d'origine dans CloudFront, consultez la section suivante « Activer le protocole TLS mutuel d'origine pour les CloudFront distributions ».

# Activer le protocole TLS mutuel d'origine pour les distributions CloudFront
<a name="origin-enable-mtls-distributions"></a>

Après avoir obtenu un certificat client via AWS Certificate Manager et configuré votre serveur d'origine pour qu'il exige le protocole TLS mutuel, vous pouvez activer les MTL d'origine sur votre CloudFront distribution.

## Prérequis et exigences
<a name="origin-mtls-prerequisites-requirements"></a>

Avant d'activer les MTL d'origine sur une CloudFront distribution, assurez-vous d'avoir :
+ Un certificat client stocké dans AWS Certificate Manager dans la région USA Est (Virginie du Nord) (us-east-1)
+ Serveurs d'origine configurés pour exiger une authentification TLS mutuelle et valider les certificats clients
+ Serveurs d'origine présentant des certificats provenant d'autorités de certification approuvées par le public
+ Autorisations pour modifier les CloudFront distributions
+ Origin mTLS n'est disponible que sur les forfaits Business, Premium ou Pay as you go.

**Note**  
Les modèles MTL d'origine peuvent être configurés pour des origines personnalisées (y compris des origines hébergées à l'extérieur AWS) et des AWS origines compatibles avec les protocoles TLS mutuels, tels que Application Load Balancer et API Gateway.

**Important**  
Les CloudFront fonctionnalités suivantes ne sont pas prises en charge avec les MTL d'origine :  
**Trafic gRPC : le protocole gRPC** n'est pas pris en charge pour les origines dont les mTLS d'origine sont activés
**WebSocket connexions :** le WebSocket protocole n'est pas pris en charge pour les origines dont le protocole MTL d'origine est activé
**Origines VPC :** les MTL d'origine ne peuvent pas être utilisées avec les origines VPC
**Déclencheurs de demande d'origine et de réponse d'origine avec Lambda @Edge : les fonctions Lambda** @Edge dans les positions de demande d'origine et de réponse d'origine ne sont pas prises en charge par les MTL d'origine
**Embarqué POPs :** le mTLS d'origine n'est pas pris en charge pour l'intégration POPs

## Activer les MTL d'origine
<a name="origin-enable-mtls-per-origin"></a>

La configuration par origine vous permet de spécifier différents certificats clients pour différentes origines au sein d'une même distribution. Cette approche offre une flexibilité maximale lorsque vos origines ont des exigences d'authentification différentes.

### Pour les nouvelles distributions (console)
<a name="origin-enable-mtls-new-distributions"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez **Créer une distribution**

1. Sélectionnez un plan tarifaire : choisissez **Business** ou **Premium** ou **Payez au fur** et à mesure (Origin mTLS n'est pas disponible avec le plan gratuit)

1. Dans la section Paramètres d'origine, choisissez Type d'origine comme Autre

1. Dans la section **Paramètres d'origine**, choisissez **Personnaliser les paramètres d'origine**

1. Configurez votre première origine (nom de domaine, protocole, etc.)

1. Dans la configuration d'origine, recherchez les **MTL**

1. Activez le **protocole MTL**

1. Pour **le certificat client**, sélectionnez votre certificat dans AWS Certificate Manager

1. (Facultatif) Ajoutez des origines supplémentaires avec leurs propres configurations MTL d'origine

1. Complétez les paramètres de distribution restants et choisissez **Créer une distribution**

### Pour les distributions existantes (console)
<a name="origin-enable-mtls-existing-distributions"></a>

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans la liste de distribution, sélectionnez la distribution que vous souhaitez modifier. (Remarque : assurez-vous que votre distribution est basée sur un plan tarifaire **Pro, Premium ou Pay As You Go**. Dans le cas contraire, vous devez mettre à jour votre plan tarifaire avant d'activer Origin (MTL).

1. Choisissez l'onglet **Origins**

1. Sélectionnez l'origine que vous souhaitez configurer et choisissez **Modifier**

1. Dans les paramètres d'origine, recherchez les **MTL**

1. Activez le **protocole MTL**

1. Pour **le certificat client**, sélectionnez votre certificat dans AWS Certificate Manager. (Remarque : seuls les certificats clients dont la propriété EKU (Extended Key Usage) est définie sur « Authentification client TLS » seront répertoriés)

1. Choisissez **Enregistrer les modifications**

1. Répétez l'opération pour d'autres origines si nécessaire

## Utilisation de la AWS CLI
<a name="origin-enable-mtls-cli"></a>

Pour la configuration par origine, spécifiez les paramètres mTLS d'origine dans la configuration de chaque origine :

```
{
  "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"
        }
      }
    ]
  }
}
```

**Note**  
CloudFront ne fournira pas le certificat client si le serveur ne le demande pas, ce qui permet à la connexion de se poursuivre normalement.

## Étapes suivantes
<a name="origin-enable-mtls-next-steps"></a>

Après avoir activé les MTL d'origine sur votre CloudFront distribution, vous pouvez surveiller les événements d'authentification à l'aide des journaux CloudFront d'accès.

# Utilisation de CloudFront fonctions avec Origin Mutual TLS
<a name="origin-mtls-cloudfront-functions"></a>

CloudFront Functions fournit un calcul léger et sans serveur à la périphérie pour personnaliser la diffusion de contenu. Lorsque vous utilisez Origin Mutual TLS avec CloudFront Functions, il existe des comportements et des limites spécifiques à prendre en compte en ce qui concerne la sélection et la manipulation de l'origine.

## Opérations CloudFront des fonctions prises en charge
<a name="supported-cloudfront-functions-operations"></a>

CloudFront Les fonctions peuvent interagir avec les origines compatibles MTLS de la manière suivante :

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

La fonction updateRequestOrigin () prend en charge des modifications limitées lorsque vous travaillez avec des origines compatibles MTLS :
+ **Basculement entre les origines des MTL d'origine :** vous pouvez mettre à jour la demande pour qu'elle soit acheminée vers une autre origine utilisant des MTL d'origine, à condition que les deux origines utilisent le **même certificat client**. Cela vous permet d'implémenter une logique de routage personnalisée tout en maintenant l'authentification TLS mutuelle.
+ **Désactivation des MTLS d'origine :** vous pouvez passer d'une origine compatible MTLS à une origine non MTLS en configurant la fonction. `mTLSConfig: 'off'` Cela permet de désactiver de manière conditionnelle l'authentification TLS mutuelle en fonction des caractéristiques de la demande.

#### Exemple : Basculer entre les origines MTL d'origine avec le même certificat
<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;
}
```

#### Exemple : désactivation conditionnelle des MTL d'origine
<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;
}
```

## Opérations de CloudFront fonctions non prises en charge
<a name="unsupported-cloudfront-functions-operations"></a>

Les opérations CloudFront Functions suivantes ne prennent pas en charge les origines compatibles MTLS lors de leur disponibilité générale :

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

La `selectRequestOriginById()` fonction ne peut pas sélectionner une origine pour laquelle les mTLS d'origine sont activés. Toute tentative de sélection d'une origine compatible MTLS à l'aide de cette fonction entraînera une erreur de validation.

Si votre cas d'utilisation nécessite une sélection dynamique de l'origine avec des MTL d'origine, utilisez-le `updateRequestOrigin()` plutôt, en vous assurant que toutes les origines cibles utilisent le même certificat client.

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

La `createRequestOriginGroup()` fonction ne prend pas en charge la création de groupes d'origine incluant des origines compatibles MTLS. Les groupes d'origine avec des origines MTL d'origine ne peuvent pas être créés dynamiquement via CloudFront Functions.

Si vous avez besoin de fonctionnalités de basculement d'origine avec les MTL d'origine, configurez les groupes d'origine directement dans vos paramètres de CloudFront distribution plutôt que de les créer dynamiquement dans les fonctions.

# Diffusez du contenu privé avec des cookies signés URLs et signés
<a name="PrivateContent"></a>

De nombreuses entreprises qui distribuent du contenu via Internet veulent limiter l’accès aux documents, données professionnelles, flux multimédias ou contenus destinés à des utilisateurs sélectionnés, tels que ceux qui paient un droit. Pour diffuser en toute sécurité ce contenu privé en utilisant CloudFront, vous pouvez effectuer les opérations suivantes :
+ Exigez que vos utilisateurs accèdent à votre contenu privé en utilisant des cookies spéciaux CloudFront signés URLs ou signés. 
+ Exigez que vos utilisateurs accèdent à votre contenu en utilisant CloudFront URLs, et non URLs en accédant au contenu directement sur le serveur d'origine (par exemple, Amazon S3 ou un serveur HTTP privé). L'exiger CloudFront URLs n'est pas nécessaire, mais nous le recommandons pour empêcher les utilisateurs de contourner les restrictions que vous spécifiez dans les cookies signés URLs ou signés.

Pour de plus amples informations, veuillez consulter [Restriction de l’accès aux fichiers](private-content-overview.md).

## Comment diffuser du contenu privé
<a name="private-content-task-list"></a>

Pour configurer CloudFront afin de diffuser du contenu privé, effectuez les tâches suivantes :

1. (Facultatif mais recommandé) Demandez à vos utilisateurs d'accéder à votre contenu uniquement via CloudFront. La méthode que vos utilisez varie selon que vous recourez aux origines Amazon S3 ou aux origines personnalisées :
   + **Amazon S3** : voir [Restriction de l’accès à une origine Amazon S3](private-content-restricting-access-to-s3.md).
   + **Origine personnalisée** : voir [Restriction de l’accès à des fichiers d’origines personnalisées](private-content-overview.md#forward-custom-headers-restrict-access).

   Les origines personnalisées incluent Amazon EC2, les compartiments Amazon S3 configurés en tant que points de terminaison de site Web, Elastic Load Balancing et vos propres serveurs web HTTP.

1. Spécifiez les *groupes de clés* ou *les signataires approuvés* que vous souhaitez utiliser pour créer des cookies signés URLs ou signés. Nous vous recommandons d’utiliser des groupes de clés approuvés. Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).

1. Rédigez votre application pour répondre aux demandes des utilisateurs autorisés, soit avec des en-têtes signés, URLs soit avec `Set-Cookie` des en-têtes qui définissent des cookies signés. Suivez les étapes décrites dans l’une des rubriques suivantes : 
   + [Utiliser signé URLs](private-content-signed-urls.md)
   + [Utilisation de cookies signés](private-content-signed-cookies.md)

   En cas de doute sur la méthode à utiliser, consultez [Décidez d'utiliser des cookies signés URLs ou signés](private-content-choosing-signed-urls-cookies.md).

**Topics**
+ [Comment diffuser du contenu privé](#private-content-task-list)
+ [Restriction de l’accès aux fichiers](private-content-overview.md)
+ [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md)
+ [Décidez d'utiliser des cookies signés URLs ou signés](private-content-choosing-signed-urls-cookies.md)
+ [Utiliser signé URLs](private-content-signed-urls.md)
+ [Utilisation de cookies signés](private-content-signed-cookies.md)
+ [Utilisation d’une commande Linux et OpenSSL pour le chiffrement et l’encodage en base64](private-content-linux-openssl.md)
+ [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md)

# Restriction de l’accès aux fichiers
<a name="private-content-overview"></a>

Vous pouvez contrôler l’accès des utilisateurs à votre contenu privé de deux façons :
+ [Limitez l'accès aux fichiers dans les CloudFront caches](#private-content-overview-edge-caches).
+ Restreignez l’accès aux fichiers dans votre origine en effectuant l’une des actions suivantes :
  + [Configurez un contrôle d'accès à l'origine (OAC) pour votre compartiment Amazon S3](private-content-restricting-access-to-s3.md).
  + [Configurez des en-têtes personnalisés pour un serveur HTTP privé (origine personnalisée)](#forward-custom-headers-restrict-access).

## Restreindre l'accès aux fichiers dans les CloudFront caches
<a name="private-content-overview-edge-caches"></a>

Vous pouvez configurer CloudFront pour obliger les utilisateurs à accéder à vos fichiers à l'aide de *cookies *signés URLs* ou signés*. Vous développez ensuite votre application soit pour créer et distribuer des signatures URLs aux utilisateurs authentifiés, soit pour envoyer `Set-Cookie` des en-têtes qui définissent des cookies signés pour les utilisateurs authentifiés. (Pour permettre à quelques utilisateurs d'accéder à long terme à un petit nombre de fichiers, vous pouvez également créer des fichiers signés URLs manuellement.) 

Lorsque vous créez des cookies signés URLs ou signés pour contrôler l'accès à vos fichiers, vous pouvez définir les restrictions suivantes :
+ Une heure et une date de fin, au-delà desquelles l’URL n’est plus valide. 
+ (Facultatif) L’heure et la date auxquelles l’URL devient valide.
+ (Facultatif) L’adresse IP ou la plage d’adresses IP des ordinateurs qui peuvent être utilisés pour accéder à votre contenu. 

Une partie d’une URL signée ou d’un cookie signé est hachée et signée à l’aide de la clé privée d’une paire de clés publique/privée. Lorsqu'un utilisateur utilise une URL signée ou un cookie signé pour accéder à un fichier, CloudFront compare les parties signées et non signées de l'URL ou du cookie. S'ils ne correspondent pas, CloudFront ne diffuse pas le fichier.

Vous devez utiliser des clés privées RSA 2048 ou ECDSA 256 pour la signature ou les cookies. URLs 

## Restriction de l’accès aux fichiers dans les compartiments Amazon S3
<a name="private-content-overview-s3"></a>

Vous pouvez éventuellement sécuriser le contenu de votre compartiment Amazon S3 afin que les utilisateurs puissent y accéder via la CloudFront distribution spécifiée, mais ne puissent pas y accéder directement via Amazon S3URLs. Cela empêche quelqu'un de contourner CloudFront et d'utiliser l'URL Amazon S3 pour accéder au contenu auquel vous souhaitez restreindre l'accès. Cette étape n'est pas obligatoire pour utiliser SignedURLs, mais nous vous la recommandons.

Pour obliger les utilisateurs à accéder à votre contenu CloudFront URLs, vous devez effectuer les tâches suivantes :
+ Donnez à une autorisation de *contrôle CloudFront d'accès à l'origine* l'autorisation de lire les fichiers du compartiment S3.
+ Créez le contrôle d'accès à l'origine et associez-le à votre CloudFront distribution.
+ Supprimez l'autorisation pour toute autre personne d'utiliser Amazon S3 URLs pour lire les fichiers.

Pour plus d’informations, consultez [Restriction de l’accès à une origine Amazon S3](private-content-restricting-access-to-s3.md) ou [Restreindre l'accès à l'origine d'un point d'accès multirégional Amazon S3](private-content-restricting-access-to-s3-mrap.md).

## Restriction de l’accès à des fichiers d’origines personnalisées
<a name="forward-custom-headers-restrict-access"></a>

Si vous utilisez une origine personnalisée, vous pouvez éventuellement configurer des en-têtes personnalisés pour limiter l’accès. CloudFront Pour obtenir vos fichiers à partir d'une origine personnalisée, ceux-ci doivent être accessibles à l'CloudFront aide d'une requête HTTP (ou HTTPS) standard. Mais en utilisant des en-têtes personnalisés, vous pouvez restreindre davantage l'accès à votre contenu afin que les utilisateurs puissent y accéder uniquement par le biaisCloudFront, et non directement. Cette étape n'est pas obligatoire pour utiliser Signed URLs, mais nous vous la recommandons.

Pour obliger les utilisateurs à accéder au contenu via CloudFront, modifiez les paramètres suivants dans vos CloudFront distributions :

**Origin Custom Headers**  
Configurez CloudFront pour transférer les en-têtes personnalisés vers votre origine. Consultez [Configurer CloudFront pour ajouter des en-têtes personnalisés aux demandes d'origine](add-origin-custom-headers.md#add-origin-custom-headers-configure).

**Viewer Protocol Policy**  
Configurez votre distribution de manière à ce que les utilisateurs emploient HTTPS pour accéder à CloudFront. Consultez [Viewer Protocol Policy](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy). 

**Origin Protocol Policy**  
Configurez votre distribution CloudFront pour exiger l'utilisation du même protocole que les spectateurs pour transmettre les demandes à l'origine. Consultez [Protocole (origines personnalisées uniquement)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy). 

Après avoir apporté ces modifications, mettez à jour votre application sur votre origine personnalisée pour n'accepter que les demandes qui incluent les en-têtes personnalisés que vous avez configurés CloudFront pour envoyer.

La combinaison de la **Politique de protocole d’utilisateur** et de la **Politique de protocole d’origine** garantit que les en-têtes personnalisés sont chiffrés en transit. Cependant, nous vous recommandons de procéder régulièrement comme suit pour faire pivoter les en-têtes personnalisés qui sont CloudFront renvoyés vers votre origine :

1. Mettez à jour votre CloudFront distribution pour commencer à transférer un nouvel en-tête vers votre origine personnalisée.

1. Mettez à jour votre application pour accepter le nouvel en-tête comme confirmation de l'origine de la demande CloudFront.

1. Lorsque les demandes n'incluent plus l'en-tête que vous remplacez, mettez à jour votre application pour qu'elle n'accepte plus l'ancien en-tête comme confirmation de l'origine de la demande CloudFront.

# Spécifiez les signataires autorisés à créer des cookies signés URLs et signés
<a name="private-content-trusted-signers"></a>

**Topics**
+ [Choisissez entre des groupes de clés fiables (recommandé) et Comptes AWS](#choosing-key-groups-or-AWS-accounts)
+ [Création de paires de clés pour vos signataires](#private-content-creating-cloudfront-key-pairs)
+ [Reformatage de la clé privée (.NET et Java uniquement)](#private-content-reformatting-private-key)
+ [Ajout d’un signataire à une distribution](#private-content-adding-trusted-signers)
+ [Rotation de paires de clés](#private-content-rotating-key-pairs)

Pour créer des cookies signés URLs ou signés, vous avez besoin d'un *signataire*. Un signataire est soit un groupe de clés fiables dans lequel vous créez CloudFront, soit un AWS compte contenant une paire de CloudFront clés. Nous vous recommandons d'utiliser des groupes de clés fiables avec des cookies signés URLs et signés. Pour de plus amples informations, veuillez consulter [Choisissez entre des groupes de clés fiables (recommandé) et Comptes AWS](#choosing-key-groups-or-AWS-accounts).

Le signataire a deux finalités :
+ Dès que vous ajoutez le signataire à votre distribution, CloudFront les spectateurs doivent désormais utiliser des cookies signés URLs ou signés pour accéder à vos fichiers.
+ Lorsque vous créez des cookies signés URLs ou signés, vous utilisez la clé privée de la paire de clés du signataire pour signer une partie de l'URL ou du cookie. Lorsqu'un utilisateur demande un fichier restreint, CloudFront compare la signature contenue dans l'URL ou le cookie avec l'URL ou le cookie non signé, afin de vérifier qu'il n'a pas été falsifié. CloudFront vérifie également que l'URL ou le cookie est valide, ce qui signifie, par exemple, que la date et l'heure d'expiration ne sont pas dépassées.

Lorsque vous spécifiez un signataire, vous spécifiez également indirectement les fichiers qui nécessitent des cookies signés URLs ou signés en ajoutant le signataire à un comportement de cache. Si votre distribution n'a qu'un seul comportement de cache, les utilisateurs doivent utiliser des cookies signés URLs ou signés pour accéder à tous les fichiers de la distribution. Si vous créez plusieurs comportements de cache et que vous ajoutez des signataires à certains comportements de cache et pas à d'autres, vous pouvez demander aux utilisateurs d'utiliser des cookies signés URLs ou signés pour accéder à certains fichiers et pas à d'autres.

Pour spécifier les signataires (les clés privées) autorisés à créer des cookies signés URLs ou signés, et pour ajouter les signataires à votre CloudFront distribution, effectuez les tâches suivantes :

1. Décidez si vous souhaitez utiliser un groupe de clés approuvé ou un Compte AWS en tant que signataire. Nous vous recommandons d’utiliser un groupe de clés approuvé. Pour plus d’informations, consultez [Choisissez entre des groupes de clés fiables (recommandé) et Comptes AWS](#choosing-key-groups-or-AWS-accounts).

1. Pour le signataire que vous avez choisi à l’étape 1, créez une paire de clés privées/publiques. Pour de plus amples informations, veuillez consulter [Création de paires de clés pour vos signataires](#private-content-creating-cloudfront-key-pairs).

1. Si vous utilisez .NET ou Java pour créer des cookies signés URLs ou signés, reformatez la clé privée. Pour de plus amples informations, veuillez consulter [Reformatage de la clé privée (.NET et Java uniquement)](#private-content-reformatting-private-key).

1. Dans la distribution pour laquelle vous créez des cookies signés URLs ou signés, spécifiez le signataire. Pour de plus amples informations, veuillez consulter [Ajout d’un signataire à une distribution](#private-content-adding-trusted-signers).

## Choisissez entre des groupes de clés fiables (recommandé) et Comptes AWS
<a name="choosing-key-groups-or-AWS-accounts"></a>

Pour utiliser des cookies signés URLs ou signés, vous avez besoin d'un *signataire*. Un signataire est soit un groupe de clés fiables dans lequel vous créez CloudFront, soit un groupe Compte AWS contenant une paire de CloudFront clés. Nous vous recommandons d’utiliser des groupes de clés approuvés, pour les raisons suivantes :
+ Avec les groupes de CloudFront clés, il n'est pas nécessaire d'utiliser l'utilisateur root du AWS compte pour gérer les clés publiques des cookies CloudFront signés URLs et signés. [AWS les meilleures pratiques](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root) recommandent de ne pas utiliser l'utilisateur root lorsque ce n'est pas nécessaire.
+ Avec les groupes de CloudFront clés, vous pouvez gérer les clés publiques, les groupes de clés et les signataires de confiance à l'aide de l' CloudFront API. Vous pouvez utiliser l’API pour automatiser la création et la rotation des clés. Lorsque vous utilisez l'utilisateur AWS root, vous devez utiliser le AWS Management Console pour gérer les paires de CloudFront clés. Vous ne pouvez donc pas automatiser le processus.
+ Comme vous pouvez gérer des groupes de clés avec l' CloudFront API, vous pouvez également utiliser des politiques d'autorisation Gestion des identités et des accès AWS (IAM) pour limiter ce que les différents utilisateurs sont autorisés à faire. Par exemple, vous pouvez autoriser les utilisateurs à télécharger des clés publiques, mais pas à les supprimer. Vous pouvez également autoriser les utilisateurs à supprimer des clés publiques, mais uniquement lorsque certaines conditions sont remplies, telles que l’utilisation d’une authentification à plusieurs facteurs, l’envoi de la demande à partir d’un réseau particulier ou dans une plage de dates et d’heures spécifiques.
+ Avec les groupes de CloudFront clés, vous pouvez associer un plus grand nombre de clés publiques à votre CloudFront distribution, ce qui vous donne plus de flexibilité dans la manière dont vous utilisez et gérez les clés publiques. Par défaut, vous pouvez associer jusqu’à quatre groupes de clés avec une seule distribution, et vous pouvez avoir jusqu’à cinq clés publiques dans un groupe de clés.

  Lorsque vous utilisez l'utilisateur root du AWS compte pour gérer les paires de CloudFront clés, vous ne pouvez avoir que deux paires de CloudFront clés actives par AWS compte.

## Création de paires de clés pour vos signataires
<a name="private-content-creating-cloudfront-key-pairs"></a>

Chaque signataire que vous utilisez pour créer des cookies CloudFront signés URLs ou signés doit posséder une paire de clés publique-privée. Le signataire utilise sa clé privée pour signer l'URL ou les cookies, et CloudFront utilise la clé publique pour vérifier la signature.

La façon dont vous créez une paire de clés varie selon que vous utilisez un groupe de clés approuvé comme signataire (recommandé) ou une paire de CloudFront clés. Pour plus d’informations, consultez les sections suivantes. La paire de clés que vous créez doit satisfaire aux exigences suivantes :
+ Il doit s’agir d’une paire de clés SSH-2 RSA 2048 ou d’une paire de clés ECDSA 256.
+ Elle doit être au format PEM codé en base64.

Pour aider à sécuriser vos applications, nous vous recommandons d’effectuer une rotation périodique des paires de clés. Pour plus d’informations, consultez [Rotation de paires de clés](#private-content-rotating-key-pairs).

### Création d’une paire de clés pour un groupe de clés approuvé (recommandé)
<a name="create-key-pair-and-key-group"></a>

Pour créer une paire de clés pour un groupe de clés approuvé, effectuez les opérations suivantes :

1. Créez la paire de clés privées/publiques.

1. Téléchargez la clé publique sur CloudFront.

1. Ajoutez la clé publique à un groupe de CloudFront clés.

Pour plus d’informations, consultez les procédures suivantes.<a name="private-content-uploading-cloudfront-public-key-procedure"></a>

**Pour créer une paire de clés**
**Note**  
Les étapes suivantes utilisent OpenSSL comme exemple d’une méthode permettant de créer une paire de clés. Il existe de nombreuses autres façons de créer une paire de clés RSA ou ECDSA.

1. Exécutez une des commandes d’exemple suivantes :
   + L’exemple de commande suivant utilise OpenSSL pour générer une paire de clés RSA d’une longueur de 2048 bits et l’enregistrer dans le fichier nommé `private_key.pem`.

     ```
     openssl genrsa -out private_key.pem 2048
     ```
   + L’exemple de commande suivant utilise OpenSSL pour générer une paire de clés ECDSA avec la courbe `prime256v1` et l’enregistrer dans le fichier nommé `private_key.pem`.

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

1. Le fichier obtenu contient à la fois la clé publique et la clé privée. L’exemple de commande suivant extrait la clé publique du fichier nommé `private_key.pem`.

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

   Vous chargez la clé publique (dans le fichier `public_key.pem`) ultérieurement, dans le cadre de la procédure suivante.

**Pour télécharger la clé publique sur CloudFront**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le menu de navigation, choisissez **Clés publiques**.

1. Choisissez **Créer une clé publique**.

1. Dans la fenêtre **Créer une clé publique** procédez comme suit :

   1. Dans **Nom de la clé**, saisissez un nom pour identifier la clé publique.

   1. Dans **Valeur de clé**, collez la clé publique. Si vous avez suivi les étapes de la procédure précédente, la clé publique se trouve dans le fichier nommé `public_key.pem`. Pour copier et coller le contenu de la clé publique, vous pouvez :
      + Utilisez la commande **cat** sur la ligne de commande macOS ou Linux, comme ceci :

        ```
        cat public_key.pem
        ```

        Copiez la sortie de cette commande, puis collez-la dans le champ **Valeur de clé**.
      + Ouvrez le `public_key.pem` fichier à l'aide d'un éditeur de texte brut tel que le Bloc-notes (sous Windows) ou TextEdit (sous macOS). Copiez le contenu du fichier, puis collez-le dans le champ **Valeur de clé**.

   1. (Facultatif) Dans **Commentaire**, ajoutez un commentaire pour décrire la clé publique.

   Lorsque vous avez terminé, choisissez **Ajouter**.

1. Enregistrez l’ID de clé publique. Vous l'utiliserez ultérieurement lorsque vous créerez des cookies signés URLs ou signés, comme valeur du `Key-Pair-Id` champ.

**Pour ajouter la clé publique à un groupe de clés**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le menu de navigation, choisissez **Groupes de clés**.

1. Choisissez **Ajouter un groupe de clés**.

1. Sur la page **Créer un groupe de clés** procédez comme suit :

   1. Dans **Nom du groupe de clés**, saisissez un nom pour identifier le groupe de clés.

   1. (Facultatif) Dans **Commentaire**, saisissez un commentaire pour décrire le groupe de clés.

   1. Dans **Clés publiques**, sélectionnez la clé publique à ajouter au groupe de clés, puis choisissez **Ajouter**. Répétez cette étape pour chaque clé publique que vous souhaitez ajouter au groupe de clés.

1. Choisissez **Créer une paire de clés**.

1. Enregistrez le nom du groupe de clés. Vous l'utiliserez ultérieurement pour associer le groupe de clés à un comportement de cache dans une CloudFront distribution. (Dans l' CloudFront API, vous utilisez l'ID du groupe de clés pour associer le groupe de clés à un comportement de cache.)

### Création d'une paire de CloudFront clés (non recommandé, nécessite l'utilisateur Compte AWS root)
<a name="create-key-pair-aws-account"></a>

**Important**  
Nous vous recommandons de créer une clé publique pour un groupe de clés approuvé au lieu de suivre ces étapes. Pour connaître la méthode recommandée pour créer des clés publiques pour les cookies signés URLs et signés, consultez[Création d’une paire de clés pour un groupe de clés approuvé (recommandé)](#create-key-pair-and-key-group).

Vous pouvez créer une paire de CloudFront clés de différentes manières :
+ Créez une paire de clés dans le AWS Management Console et téléchargez la clé privée. Consultez la procédure suivante.
+ Créez une paire de clés RSA à l’aide d’une application tel qu’OpenSSL, puis chargez la clé publique sur AWS Management Console. Pour plus d’informations sur la création d’une paire de clés, consultez [Création d’une paire de clés pour un groupe de clés approuvé (recommandé)](#create-key-pair-and-key-group).<a name="private-content-creating-cloudfront-key-pairs-procedure"></a>

**Pour créer des paires de CloudFront clés dans AWS Management Console**

1. Connectez-vous à l' AWS Management Console aide des informations d'identification de l'utilisateur root du AWS compte.
**Important**  
Les utilisateurs d'IAM ne peuvent pas créer de paires de CloudFront clés. Pour créer des paires de clés, vous devez vous connecter à l’aide des informations d’identification de l’utilisateur racine.

1. Choisissez le nom de votre compte, puis **Mes informations d’identification de sécurité**.

1. Choisissez **CloudFront des paires de clés**.

1. Confirmez que vous n’avez pas plus d’une paire de clés active. Vous ne pouvez pas créer une paire de clés si vous en avez déjà deux actives.

1. Choisissez **Créer une nouvelle paire de clés**.
**Note**  
Vous pouvez également choisir de créer votre propre paire de clés et de télécharger la clé publique. CloudFront les paires de clés prennent en charge les clés de 1024, 2048 ou 4096 bits.

1. Dans la boîte de dialogue **Créer une paire de clés**, choisissez **Télécharger fichier de clés privées**, puis enregistrez le fichier sur votre ordinateur.
**Important**  
Enregistrez la clé privée de votre paire de CloudFront clés dans un emplacement sécurisé et définissez des autorisations sur le fichier afin que seuls les administrateurs souhaités puissent le lire. Si quelqu'un obtient votre clé privée, il peut générer des cookies signés URLs et signés valides et télécharger votre contenu. Vous ne pouvez pas récupérer la clé privée. Par conséquent, si vous la perdez ou la supprimez, vous devez créer une nouvelle paire de CloudFront clés.

1. Enregistrez l’ID de paire de clés de votre paire de clés. (Dans le AWS Management Console, cela s'appelle l'**ID de clé d'accès**.) Vous l'utiliserez lorsque vous créerez des cookies signés URLs ou signés.

## Reformatage de la clé privée (.NET et Java uniquement)
<a name="private-content-reformatting-private-key"></a>

Si vous utilisez .NET ou Java pour créer des cookies signés URLs ou signés, vous ne pouvez pas utiliser la clé privée de votre paire de clés au format PEM par défaut pour créer la signature. Dans ce cas, procédez comme suit :
+ **.NET framework** : convertit la clé privée au format XML utilisé par .NET framework. Plusieurs outils sont disponibles.
+ **Java** : convertit la clé privée au format DER. On peut utiliser la commande OpenSSL suivante pour le faire. Dans la commande suivante, `private_key.pem` est le nom du fichier qui contient la clé privée au format PEM et `private_key.der` le nom du fichier qui contient la clé privée au format DER après l’exécution de la commande.

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

  Pour vous assurer que l'encodeur fonctionne correctement, ajoutez le fichier JAR pour le chiffrement Java de Bouncy Castle APIs à votre projet, puis ajoutez le fournisseur Bouncy Castle.

## Ajout d’un signataire à une distribution
<a name="private-content-adding-trusted-signers"></a>

Un signataire est le groupe de clés approuvé (recommandé) ou la paire de CloudFront clés qui peut créer des cookies signés URLs et signés pour une distribution. Pour utiliser des cookies signés URLs ou signés avec une CloudFront distribution, vous devez spécifier un signataire.

Les signataires sont associés aux comportements de cache. Cela vous permet d'exiger des cookies signés URLs ou signés pour certains fichiers et pas pour d'autres de la même distribution. Une distribution nécessite des cookies URLs ou signés uniquement pour les fichiers associés aux comportements de cache correspondants.

De même, un signataire ne peut signer URLs ou utiliser des cookies que pour les fichiers associés aux comportements de cache correspondants. Par exemple, si vous avez un signataire pour un comportement de cache et un autre signataire pour un comportement de cache différent, aucun des signataires ne peut créer de signature URLs ou de cookies pour les fichiers associés à l'autre comportement de cache.

**Important**  
Avant d’ajouter un signataire à votre distribution, procédez comme suit :  
Définissez soigneusement les modèles de chemin d’accès dans les comportements de cache et la séquence des comportements de cache de façon à ne pas donner aux utilisateurs un accès non prévu à votre contenu ou à les empêcher d’accéder à un contenu que vous voulez disponible pour tout le monde.  
Par exemple, imaginons qu’une demande corresponde au modèle de chemin de deux comportements de cache. Le premier comportement de cache ne nécessite pas de cookies signés URLs ou signés, tandis que le second comportement de cache en nécessite. Les utilisateurs pourront accéder aux fichiers sans utiliser de cookies signés URLs ou signés, car il CloudFront traite le comportement du cache associé à la première correspondance.  
Pour plus d’informations sur les modèles de chemin d’accès, consultez [Modèle de chemin](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
Pour une distribution que vous utilisez déjà pour distribuer du contenu, assurez-vous d'être prêt à commencer à générer des cookies signés URLs et signés avant d'ajouter un signataire. Lorsque vous ajoutez un signataire, CloudFront rejette les demandes qui n'incluent pas d'URL signée ou de cookie signé valide.

Vous pouvez ajouter des signataires à votre distribution à l'aide de la CloudFront console ou de l' CloudFrontAPI.

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

Les étapes suivantes montrent comment ajouter un groupe de clés approuvé en tant que signataire. Vous pouvez également ajouter un Compte AWS en tant que signataire de confiance, mais cela n'est pas recommandé.<a name="private-content-adding-trusted-signers-console-procedure"></a>

**Pour ajouter un signataire à une distribution à l’aide de la console**

1. Enregistrez l’ID de groupe de clés du groupe de clés que vous souhaitez utiliser en tant que signataire approuvé. Pour de plus amples informations, veuillez consulter [Création d’une paire de clés pour un groupe de clés approuvé (recommandé)](#create-key-pair-and-key-group).

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez la distribution dont vous souhaitez protéger les fichiers avec des cookies signés URLs ou signés.
**Note**  
Pour ajouter un signataire à une nouvelle distribution, vous spécifiez les mêmes paramètres que ceux décrits à l’étape 6 lors de la création de la distribution.

1. Choisissez l’onglet **Comportements**.

1. Sélectionnez le comportement du cache dont le modèle de chemin correspond aux fichiers que vous souhaitez protéger avec des cookies signés URLs ou signés, puis choisissez **Modifier**.

1. Sur la page **Modifier le comportement** procédez comme suit :

   1. Pour **Restreindre l'accès des spectateurs (utiliser des cookies signés URLs ou signés)**, sélectionnez **Oui**.

   1. Dans **Groupes de clés approuvés ou Signataire approuvé**, choisissez **Groupes de clés approuvés**.

   1. Dans **Groupes de clés approuvés**, choisissez le groupe de clés à ajouter, puis **Ajouter**. Recommencez si vous souhaitez ajouter plusieurs groupes de clés.

1. Choisissez **Oui, Modifier** pour mettre à jour le comportement du cache.

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

Vous pouvez utiliser l' CloudFront API pour ajouter un groupe de clés fiables en tant que signataire. Vous pouvez ajouter un signataire à une distribution existante ou à une nouvelle distribution. Dans les deux cas, spécifiez les valeurs dans l’élément `TrustedKeyGroups`.

Vous pouvez également ajouter un Compte AWS en tant que signataire de confiance, mais cela n'est pas recommandé.

Consultez les rubriques suivantes dans le manuel *Amazon CloudFront API Reference* :
+ **Mettre à jour une distribution existante** — [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
+ **Créez une nouvelle distribution** — [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)

------

## Rotation de paires de clés
<a name="private-content-rotating-key-pairs"></a>

Nous vous recommandons de faire régulièrement pivoter (modifier) vos paires de clés pour les cookies signés URLs et signés. Pour faire pivoter les paires de clés que vous utilisez pour créer des cookies signés URLs ou signés sans les invalider URLs ou des cookies qui n'ont pas encore expiré, effectuez les tâches suivantes :

1. Créez une nouvelle paire de clés et ajoutez la clé publique à un groupe de clés. Pour plus d’informations, consultez [Création d’une paire de clés pour un groupe de clés approuvé (recommandé)](#create-key-pair-and-key-group).

1. Si vous avez créé un nouveau groupe de clés à l’étape précédente, [ajoutez le groupe de clés à la distribution en tant que signataire](#private-content-adding-trusted-signers).
**Important**  
Ne supprimez pas encore des clés publiques existantes du groupe de clés, ni les groupes de clés de la distribution. Ajoutez seulement les nouveaux.

1. Mettez à jour votre application pour créer des signatures à l’aide des clés privées à partir de la nouvelle paire de clés. Vérifiez que les cookies signés URLs ou signés avec les nouvelles clés privées fonctionnent.

1. Attendez que la date d'expiration soit passée URLs ou que les cookies aient été signés à l'aide de la clé privée précédente. Ensuite, supprimez l’ancienne clé publique du groupe de clés. Si vous avez créé un nouveau groupe de clés à l’étape 2, supprimez l’ancien groupe de clés de votre distribution.

# Décidez d'utiliser des cookies signés URLs ou signés
<a name="private-content-choosing-signed-urls-cookies"></a>

CloudFront les cookies signés URLs et signés fournissent les mêmes fonctionnalités de base : ils vous permettent de contrôler qui peut accéder à votre contenu. Si vous souhaitez diffuser du contenu privé CloudFront et que vous essayez de décider d'utiliser des cookies signés URLs ou signés, considérez ce qui suit.

Utilisez URLs Signed dans les cas suivants :
+ Vous voulez restreindre l’accès aux fichiers individuels : par exemple, un téléchargement d’installation de votre application.
+ Vos utilisateurs utilisent un client (par exemple, un client HTTP personnalisé) qui ne prend pas en charge les cookies.

Utilisez les cookies signés dans les cas suivants :
+ Vous voulez fournir l’accès à plusieurs fichiers restreints : par exemple, tous les fichiers d’une vidéo au format HLS ou tous les fichiers de la section des abonnés d’un site web.
+ Vous ne voulez pas modifier votre compte actuel URLs.

Si vous n'utilisez pas de cookies signés actuellement URLs, et si votre (non signé) URLs contient l'un des paramètres de chaîne de requête suivants, vous ne pouvez pas utiliser de cookies signés URLs ou signés :
+ `Expires`
+ `Policy`
+ `Signature`
+ `Key-Pair-Id`
+ `Hash-Algorithm`

CloudFront suppose que ceux URLs qui contiennent l'un de ces paramètres de chaîne de requête sont signés URLs et ne regarderont donc pas les cookies signés.

## Utiliser à la fois des cookies signés URLs et des cookies signés
<a name="private-content-using-signed-urls-and-cookies"></a>

Les cookies URLs signés ont priorité sur les cookies signés. Si vous utilisez à la fois des cookies signés URLs et signés pour contrôler l'accès aux mêmes fichiers et qu'un utilisateur utilise une URL signée pour demander un fichier, CloudFront détermine s'il convient de renvoyer le fichier au lecteur en se basant uniquement sur l'URL signée.

# Utiliser signé URLs
<a name="private-content-signed-urls"></a>

Une URL signée inclut des informations supplémentaires, par exemple une heure et date d’expiration, qui vous donnent un meilleur contrôle de l’accès à votre contenu. Ces informations supplémentaires apparaissent dans une déclaration de politique, basée sur une politique prédéfinie ou une politique personnalisée. Les différences entre les politiques prédéfinies et les politiques personnalisées sont expliquées dans les deux prochaines sections.

**Note**  
Vous pouvez en créer des signatures à URLs l'aide de politiques prédéfinies et en créer d'autres signées URLs à l'aide de politiques personnalisées pour la même distribution.

**Topics**
+ [Décidez d'utiliser des politiques prédéfinies ou personnalisées pour les documents signés URLs](#private-content-choosing-canned-custom-policy)
+ [Comment URLs fonctionnent les signatures](#private-content-how-signed-urls-work)
+ [Décidez de la durée de validité URLs des signatures](#private-content-overview-choosing-duration)
+ [Quand CloudFront vérifie la date et l'heure d'expiration dans une URL signée](#private-content-check-expiration)
+ [Exemple de code et outils tiers](#private-content-overview-sample-code)
+ [Création d’une URL signée à l’aide d’une politique prédéfinie](private-content-creating-signed-url-canned-policy.md)
+ [Création d’une URL signée utilisant une politique personnalisée](private-content-creating-signed-url-custom-policy.md)

## Décidez d'utiliser des politiques prédéfinies ou personnalisées pour les documents signés URLs
<a name="private-content-choosing-canned-custom-policy"></a>

Lorsque vous créez une URL signée, vous écrivez une instruction de politique au format JSON qui spécifie les restrictions sur l’URL signée : par exemple, la durée de validité de l’URL. Vous pouvez utiliser une politique prédéfinie ou une politique personnalisée. Comparaison des politiques prédéfinies et des politiques personnalisées :


****  

| Description | Politique prédéfinie | Politique personnalisée | 
| --- | --- | --- | 
| Vous pouvez réutiliser la déclaration de politique pour plusieurs fichiers. Pour ce faire, vous devez utiliser les caractères génériques de l’objet `Resource`. Pour plus d’informations, consultez [Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique personnalisée](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-statement-values).)  | Non | Oui | 
| Vous pouvez indiquer la date et l’heure auxquelles les utilisateurs peuvent commencer à accéder à votre contenu. | Non | Oui (facultatif) | 
| Vous pouvez indiquer la date et l’heure auxquelles les utilisateurs ne peuvent plus accéder à votre contenu. | Oui | Oui | 
| Vous pouvez spécifier l’adresse IP ou la plage d’adresses IP des utilisateurs qui peuvent accéder à votre contenu. | Non | Oui (facultatif) | 
| L’URL signée inclut une version encodée base 64 de la politique, ce qui se traduit par une URL plus longue. | Non | Oui | 

Pour plus d'informations sur la création de documents signés URLs à l'aide *d'une politique prédéfinie*, consultez[Création d’une URL signée à l’aide d’une politique prédéfinie](private-content-creating-signed-url-canned-policy.md).

Pour plus d'informations sur la création de documents signés URLs à l'aide d'une politique *personnalisée*, consultez[Création d’une URL signée utilisant une politique personnalisée](private-content-creating-signed-url-custom-policy.md).

## Comment URLs fonctionnent les signatures
<a name="private-content-how-signed-urls-work"></a>

Voici un aperçu de la façon dont vous configurez CloudFront Amazon S3 pour les fichiers signés URLs et de la manière dont il CloudFront répond lorsqu'un utilisateur utilise une URL signée pour demander un fichier. 

1. Dans votre CloudFront distribution, spécifiez un ou plusieurs groupes de clés fiables, qui contiennent les clés publiques CloudFront pouvant être utilisées pour vérifier la signature de l'URL. Vous utilisez les clés privées correspondantes pour signer le URLs.

   CloudFront prend en charge les signatures de clé signées URLs avec RSA 2048 et ECDSA 256.

   Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).

1. Développez votre application pour déterminer si un utilisateur doit avoir accès à votre contenu et pour créer des signatures URLs pour les fichiers ou les parties de votre application auxquels vous souhaitez restreindre l'accès. Pour plus d’informations, consultez les rubriques suivantes :
   + [Création d’une URL signée à l’aide d’une politique prédéfinie](private-content-creating-signed-url-canned-policy.md)
   + [Création d’une URL signée utilisant une politique personnalisée](private-content-creating-signed-url-custom-policy.md)

1. Un utilisateur demande un fichier dont vous souhaitez demander la signature URLs.

1. Votre application vérifie que l’utilisateur est autorisé à accéder au fichier : il est abonné, il a payé pour accéder au contenu ou il a satisfait à quelque autre condition pour accéder.

1. Votre application crée et renvoie une URL signée à l’utilisateur.

1. L’URL signée autorise l’utilisateur à télécharger ou diffuser le contenu.

   Cette étape est automatique ; l’utilisateur n’a généralement rien à faire de plus pour accéder au contenu. Pa exemple, si un utilisateur accède à votre contenu dans un navigateur web, votre application renvoie l’URL signée au navigateur. Le navigateur utilise immédiatement l'URL signée pour accéder au fichier dans le cache CloudFront périphérique sans aucune intervention de l'utilisateur.

1. CloudFront utilise la clé publique pour valider la signature et confirmer que l'URL n'a pas été falsifiée. Si la signature n’est pas valide, la demande est rejetée. 

   Si la signature est valide, CloudFront examine la déclaration de politique contenue dans l'URL (ou en crée une si vous utilisez une politique prédéfinie) pour confirmer que la demande est toujours valide. Par exemple, si vous avez spécifié une date et une heure de début et de fin pour l'URL, cela CloudFront confirme que l'utilisateur essaie d'accéder à votre contenu pendant la période pendant laquelle vous souhaitez autoriser l'accès. 

   Si la demande répond aux exigences de la déclaration de politique, CloudFront effectue les opérations standard : détermine si le fichier se trouve déjà dans le cache périphérique, transmet la demande à l'origine si nécessaire et renvoie le fichier à l'utilisateur.

**Note**  
Si une URL non signée contient des paramètres de chaîne de requête, assurez-vous de les inclure dans la partie de l’URL que vous signez. Si vous ajoutez une chaîne de requête à une URL signée après l’avoir signée, l’URL renvoie un code d’état HTTP 403.

## Décidez de la durée de validité URLs des signatures
<a name="private-content-overview-choosing-duration"></a>

Vous pouvez distribuer le contenu privé à l’aide d’une URL signée qui est valide pendant une brève durée, de quelques minutes au plus. Les URLs signatures valides pour une période aussi courte sont utiles pour distribuer du contenu on-the-fly à un utilisateur dans un but précis, comme la location de films ou le téléchargement de musique aux clients à la demande. Si vos signatures URLs ne sont valides que pour une courte période, vous souhaiterez probablement les générer automatiquement à l'aide d'une application que vous développez. Lorsque l'utilisateur commence à télécharger un fichier ou à lire un fichier multimédia, CloudFront compare le délai d'expiration indiqué dans l'URL avec l'heure actuelle pour déterminer si l'URL est toujours valide.

Vous pouvez aussi distribuer le contenu privé à l’aide d’une URL signée qui est valide pour une durée plus longue, quelques années peut-être. Les documents signés URLs dont la durée de validité est plus longue sont utiles pour distribuer du contenu privé à des utilisateurs connus, comme la distribution d'un plan d'affaires aux investisseurs ou la distribution de matériel de formation aux employés. Vous pouvez développer une application pour générer ces documents signés à long terme URLs pour vous.

## Quand CloudFront vérifie la date et l'heure d'expiration dans une URL signée
<a name="private-content-check-expiration"></a>

CloudFront vérifie la date et l'heure d'expiration d'une URL signée au moment de la requête HTTP. Si un client commence à télécharger un fichier volumineux immédiatement avant la date d’expiration, le téléchargement se termine même si la date d’expiration intervient pendant le téléchargement. Si la connexion TCP cesse et que le client essaie de redémarrer le téléchargement une fois la date d’expiration passée, le téléchargement échoue.

Si un client utilise Range GETs pour obtenir un fichier en petits morceaux, toute requête GET exécutée après l'expiration du délai d'expiration échouera. Pour plus d'informations sur RangeGETs, consultez[Comment CloudFront traite les demandes partielles pour un objet (plage GETs)](RangeGETs.md).

## Exemple de code et outils tiers
<a name="private-content-overview-sample-code"></a>

Pour un exemple de code qui crée la partie hachée et signée de signed URLs, consultez les rubriques suivantes :
+ [Créer une signature d’URL avec Perl](CreateURLPerl.md)
+ [Créer une signature d’URL avec PHP](CreateURL_PHP.md)
+ [Créer une signature d’URL avec C\$1 et .NET Framework](CreateSignatureInCSharp.md)
+ [Créer une signature d’URL avec Java](CFPrivateDistJavaDevelopment.md)

# Création d’une URL signée à l’aide d’une politique prédéfinie
<a name="private-content-creating-signed-url-canned-policy"></a>

Pour créer une URL signée à l’aide d’une politique prédéfinie, procédez comme suit.<a name="private-content-creating-signed-url-canned-policy-procedure"></a>

**Pour créer une URL signée à l’aide d’une politique prédéfinie**

1. Si vous utilisez .NET ou Java pour créer des fichiers signés URLs, et si vous n'avez pas reformaté la clé privée de votre paire de clés du format .pem par défaut à un format compatible avec .NET ou Java, faites-le maintenant. Pour de plus amples informations, veuillez consulter [Reformatage de la clé privée (.NET et Java uniquement)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concaténez les valeurs suivantes. Vous pouvez utiliser le format dans cet exemple d’URL signée. 

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Expires=1767290400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F&Hash-Algorithm=SHA256
   ```

   Supprimez tous les espaces vides (tabulations et sauts de ligne inclus). Il se peut que vous ayez à inclure des caractères d’échappement dans la chaîne du code d’application. Toutes les valeurs ont le type `String`.  
**1. *Base URL for the file***  
L'URL de base est l' CloudFront URL que vous utiliseriez pour accéder au fichier si vous n'utilisiez pas Signed URLs, y compris vos propres paramètres de chaîne de requête, le cas échéant. Dans l’exemple précédent, l’URL de base est `https://d111111abcdef8.cloudfront.net/image.jpg`. Pour plus d'informations sur le format de URLs pour les distributions, consultez[Personnalisez le format d'URL pour les fichiers dans CloudFront](LinkFormat.md).  
   + L' CloudFront URL suivante concerne un fichier image dans une distribution (en utilisant le nom de CloudFront domaine). Notez que `image.jpg` se trouve dans un répertoire `images`. Le chemin d’accès au fichier de l’URL doit correspondre à celui du fichier de votre serveur HTTP ou de votre compartiment Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + L' CloudFront URL suivante inclut une chaîne de requête :

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Les informations suivantes CloudFront URLs concernent les fichiers image d'une distribution. Les deux utilisent un nom de domaine alternatif. La seconde inclut une chaîne de requête :

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + L' CloudFront URL suivante concerne un fichier image d'une distribution qui utilise un autre nom de domaine et le protocole HTTPS :

     `https://www.example.com/images/image.jpg`  
** 2. `?`**  
Le `?` indique que les paramètres de requête suivent l’URL de base. Incluez le `?` même si vous ne spécifiez aucun paramètre de requête.  
Vous pouvez spécifier les paramètres de requête suivants dans n’importe quel ordre.  
**3. *Your query string parameters, if any*`&`**  
(Facultatif) Vous pouvez entrer vos propres paramètres de chaîne de requête. Pour ce faire, ajoutez une esperluette (`&`) entre chaque valeur, par exemple. `color=red&size=medium`. Vous pouvez spécifier les paramètres de chaîne de requête dans n’importe quel ordre dans l’URL.  
Les paramètres de votre chaîne de requête ne peuvent pas être nommés `Expires``Signature`,`Key-Pair-Id`, ou`Hash-Algorithm`.  
** 4. `Expires=`*date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC)***  
Date et heure auxquelles vous souhaitez que l’URL cesse d’autoriser l’accès au fichier.  
Spécifiez la date et l’heure d’expiration au format horaire Unix (en secondes) et en heure UTC. Par exemple, le 1er janvier 2026 à 10:00 UTC correspond à `1767290400` au format d’heure Unix, comme indiqué dans l’exemple au début de cette rubrique.   
Pour utiliser l’heure époque, indiquez un entier 64 bits correspondant à une date qui ne dépasse pas `9223372036854775807` (vendredi 11 avril 2262 à 23:47:16.854 UTC).  
  
Pour plus d’informations sur l’UTC, consultez [RFC 3339, Date et heure sur Internet : Horodatages](https://tools.ietf.org/html/rfc3339).  
** 5. `&Signature=`*hashed and signed version of the policy statement***  
Version hachée, signée et encodée en base 64 de la déclaration de politique JSON. Pour de plus amples informations, veuillez consulter [Création d’une signature pour une URL signée qui utilise une politique prédéfinie](#private-content-canned-policy-creating-signature).  
** 6. `&Key-Pair-Id=`*public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature***  
L'ID d'une clé CloudFront publique, par exemple,`K2JCJMDEHXQW5F`. L'ID de clé publique indique CloudFront la clé publique à utiliser pour valider l'URL signée. CloudFront compare les informations de la signature avec celles de la déclaration de politique pour vérifier que l'URL n'a pas été falsifiée.  
Cette clé publique doit appartenir à un groupe de clés qui est un signataire approuvé dans la distribution. Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).  
** 7. `&Hash-Algorithm=`*SHA1 or SHA256***  
(Facultatif) L'algorithme de hachage utilisé pour créer la signature. Les valeurs prises en charge sont `SHA1` et `SHA256`. Si vous ne spécifiez pas ce paramètre, la CloudFront valeur par défaut est. `SHA1`

## Création d’une signature pour une URL signée qui utilise une politique prédéfinie
<a name="private-content-canned-policy-creating-signature"></a>

Pour créer la signature pour une URL signée qui utilise une politique prédéfinie, suivez les procédures suivantes.

**Topics**
+ [Création d’une déclaration de politique pour une URL signée qui utilise une politique prédéfinie](#private-content-canned-policy-creating-policy-statement)
+ [Création d’une signature pour une URL signée qui utilise une politique prédéfinie](#private-content-canned-policy-signing-policy-statement)

### Création d’une déclaration de politique pour une URL signée qui utilise une politique prédéfinie
<a name="private-content-canned-policy-creating-policy-statement"></a>

Lorsque vous créez une URL signée avec une politique prédéfinie, le paramètre `Signature` est une version hachée et signée d’une déclaration de politique. Pour les signataires URLs qui utilisent une politique prédéfinie, vous n'incluez pas la déclaration de politique dans l'URL, comme c'est le cas pour les signataires URLs qui utilisent une politique personnalisée. Pour créer la déclaration de politique, effectuez la procédure suivante.<a name="private-content-canned-policy-creating-policy-statement-procedure"></a>

**Pour créer la déclaration de politique d’une URL signée qui utilise une politique prédéfinie**

1. Construisez la déclaration de politique à l’aide du format JSON suivant et de l’encodage de caractères UTF-8. Incluez la ponctuation et les autres valeurs littérales exactement comme spécifié. Pour plus d’informations sur les paramètres `Resource` et `DateLessThan`, consultez [Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique prédéfinie](#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. Supprimez tous les espaces vides (tabulations et sauts de ligne inclus) de la déclaration de politique. Il se peut que vous ayez à inclure des caractères d’échappement dans la chaîne du code d’application.

#### Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique prédéfinie
<a name="private-content-canned-policy-statement-values"></a>

Lorsque vous créez une déclaration de politique pour une politique prédéfinie, vous spécifiez les valeurs suivantes.

**Ressource**  
Vous ne pouvez spécifier qu’une seule valeur pour `Resource`.
L'URL de base, y compris vos chaînes de requête, le cas échéant, mais à l'exclusion des `Hash-Algorithm` paramètres CloudFront `Expires` `Signature``Key-Pair-Id`,,, et, par exemple :  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Notez ce qui suit :  
+ **Protocole** : la valeur doit commencer par `http://` ou `https://`.
+ **Paramètres de chaîne de requête** : si vous n’avez aucun paramètre de chaîne de requête, omettez le point d’interrogation.
+ **Noms de domaine alternatifs** : si vous spécifiez un nom de domaine alternatif (CNAME) dans l’URL, vous devez le spécifier lorsque vous référencez le fichier dans votre page ou application web. Ne spécifiez pas l’URL Amazon S3 pour l’objet.

**DateLessThan**  
Date et heure d’expiration de l’URL au format horaire Unix (en secondes) et en heure UTC. Par exemple, le 1er janvier 2026 à 10 h UTC est converti en 1767290400 au format horaire Unix.  
Cette valeur doit correspondre à la valeur du paramètre de la chaîne de requête `Expires` de l’URL signée. N’entourez pas la valeur de points d’interrogation.  
Pour plus d’informations, consultez [Quand CloudFront vérifie la date et l'heure d'expiration dans une URL signée](private-content-signed-urls.md#private-content-check-expiration).

#### Exemple d’une déclaration de politique pour une URL signée qui utilise une politique prédéfinie
<a name="private-content-canned-policy-creating-policy-statement-example"></a>

Lorsque vous utilisez l'exemple de déclaration de politique suivant dans une URL signée, un utilisateur peut accéder au fichier `https://d111111abcdef8.cloudfront.net/horizon.jpg` jusqu'au 1er janvier 2026 à 10 h UTC :

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Création d’une signature pour une URL signée qui utilise une politique prédéfinie
<a name="private-content-canned-policy-signing-policy-statement"></a>

Pour créer la valeur du paramètre `Signature` d’une URL signée, vous hachez et signez la déclaration de politique que vous avez créée dans [Création d’une déclaration de politique pour une URL signée qui utilise une politique prédéfinie](#private-content-canned-policy-creating-policy-statement).

Pour plus d’informations et d’exemples sur la façon de hacher, signer et encoder la déclaration de politique, consultez :
+ [Utilisation d’une commande Linux et OpenSSL pour le chiffrement et l’encodage en base64](private-content-linux-openssl.md)
+ [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md)

**Note**  
Les exemples liés utilisent SHA-1 par défaut. Pour utiliser SHA-256 à la place, remplacez `sha1` par `sha256` dans les commandes OpenSSL et incluez le paramètre de `Hash-Algorithm=SHA256` requête dans l'URL signée.<a name="private-content-canned-policy-creating-signature-download-procedure"></a>

**Option 1 : Créer une signature à l’aide d’une politique prédéfinie**

1. Utilisez la fonction de hachage SHA-1 ou SHA-256 et la clé privée RSA ou ECDSA générée pour hacher et signer la déclaration de politique que vous avez créée dans le cadre de la procédure. [Pour créer la déclaration de politique d’une URL signée qui utilise une politique prédéfinie](#private-content-canned-policy-creating-policy-statement-procedure) Utilisez la version de la déclaration de politique qui n’inclut plus d’espaces vides.

   Si vous utilisez SHA-256, vous devez l'inclure `&Hash-Algorithm=SHA256` dans l'URL signée.

   Pour la clé privée requise par la fonction de hachage, utilisez une clé privée dont la clé publique se trouve dans un groupe de clés approuvé actif pour la distribution.
**Note**  
La méthode que vous utilisez pour hacher et signer la déclaration de politique dépend du langage de programmation et de la plateforme. Pour un exemple de code, consultez [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md).

1. Supprimez les espaces vides (tabulations et sauts de ligne inclus) de la chaîne hachée et signée.

1. Encodez en base64 la chaîne à l’aide de l’encodage MIME base64. Pour plus d'informations, consultez [la Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) dans la *RFC 2045, MIME (extensions de messagerie Internet polyvalentes), première partie : Format des* corps de messages Internet.

1. Remplacez les caractères non valides d’une chaîne de requête d’URL par les caractères valides. Le tableau suivant répertorie les caractères valides et non valides.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html)

1. Ajoutez la valeur obtenue à votre URL signée après `&Signature=`, et retournez à [Pour créer une URL signée à l’aide d’une politique prédéfinie](#private-content-creating-signed-url-canned-policy-procedure) pour terminer la concaténation des parties de votre URL signée.

# Création d’une URL signée utilisant une politique personnalisée
<a name="private-content-creating-signed-url-custom-policy"></a>

Pour créer une URL signée utilisant une politique personnalisée, suivez la procédure suivante.<a name="private-content-creating-signed-url-custom-policy-procedure"></a>

**Pour créer une URL signée utilisant une politique personnalisée**

1. Si vous utilisez .NET ou Java pour créer des fichiers signés URLs, et si vous n'avez pas reformaté la clé privée de votre paire de clés du format .pem par défaut à un format compatible avec .NET ou Java, faites-le maintenant. Pour de plus amples informations, veuillez consulter [Reformatage de la clé privée (.NET et Java uniquement)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concaténez les valeurs suivantes. Vous pouvez utiliser le format dans cet exemple d’URL signée.

   

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIyMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F&Hash-Algorithm=SHA256
   ```

   Supprimez tous les espaces vides (tabulations et sauts de ligne inclus). Il se peut que vous ayez à inclure des caractères d’échappement dans la chaîne du code d’application. Toutes les valeurs ont le type `String`.  
**1. *Base URL for the file***  
L'URL de base est l' CloudFront URL que vous utiliseriez pour accéder au fichier si vous n'utilisiez pas Signed URLs, y compris vos propres paramètres de chaîne de requête, le cas échéant. Dans l’exemple précédent, l’URL de base est `https://d111111abcdef8.cloudfront.net/image.jpg`. Pour plus d'informations sur le format de URLs pour les distributions, consultez[Personnalisez le format d'URL pour les fichiers dans CloudFront](LinkFormat.md).  
Les exemples suivants affichent les valeurs que vous spécifiez pour les distributions.  
   + L' CloudFront URL suivante concerne un fichier image dans une distribution (en utilisant le nom de CloudFront domaine). Notez que `image.jpg` se trouve dans un répertoire `images`. Le chemin d’accès au fichier de l’URL doit correspondre à celui du fichier de votre serveur HTTP ou de votre compartiment Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + L' CloudFront URL suivante inclut une chaîne de requête :

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Les informations suivantes CloudFront URLs concernent les fichiers image d'une distribution. Les deux utilisent un nom de domaine alternatif ; le second inclut une chaîne de requête :

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + L' CloudFront URL suivante concerne un fichier image d'une distribution qui utilise un autre nom de domaine et le protocole HTTPS :

     `https://www.example.com/images/image.jpg`  
**2. `?`**  
Le `?` indique que les paramètres de chaîne de requête suivent l’URL de base. Incluez le `?` même si vous ne spécifiez aucun paramètre de requête.  
Vous pouvez spécifier les paramètres de requête suivants dans n’importe quel ordre.  
**3. *Your query string parameters, if any*`&`**  
(Facultatif) Vous pouvez entrer vos propres paramètres de chaîne de requête. Pour ce faire, ajoutez une esperluette (&) entre chaque valeur, par exemple. `color=red&size=medium`. Vous pouvez spécifier les paramètres de chaîne de requête dans n’importe quel ordre dans l’URL.  
Les paramètres de votre chaîne de requête ne peuvent pas être nommés `Policy``Signature`,`Key-Pair-Id`, ou`Hash-Algorithm`.
Si vous ajoutez vos propres paramètres, ajoutez un `&` après chacun d’eux, y compris le dernier.   
**4. `Policy=`*base64 encoded version of policy statement***  
Votre déclaration de politique au format JSON, avec suppression des espaces vide, puis encodage en base64. Pour de plus amples informations, veuillez consulter [Création d’une déclaration de politique pour une URL signée qui utilise une politique personnalisée](#private-content-custom-policy-statement).  
La déclaration de politique contrôle l’accès accordé par une URL signée à un utilisateur. Elle inclut l’URL du fichier, une date et une heure d’expiration, une date et une heure (facultatif) auxquelles l’URL devient valide et une adresse IP (facultatif) ou une plage d’adresses IP autorisées à accéder au fichier.  
**5. `&Signature=`*hashed and signed version of the policy statement***  
Version hachée, signée et encodée en base 64 de la déclaration de politique JSON. Pour de plus amples informations, veuillez consulter [Création d’une signature pour une URL signée qui utilise une politique personnalisée](#private-content-custom-policy-creating-signature).  
**6. `&Key-Pair-Id=`*public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature***  
L'ID d'une clé CloudFront publique, par exemple,`K2JCJMDEHXQW5F`. L'ID de clé publique indique CloudFront la clé publique à utiliser pour valider l'URL signée. CloudFrontcompare les informations de la signature avec celles de la déclaration de politique pour vérifier que l'URL n'a pas été falsifiée.  
Cette clé publique doit appartenir à un groupe de clés qui est un signataire approuvé dans la distribution. Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).  
**7. `&Hash-Algorithm=`*SHA1 or SHA256***  
(Facultatif) L'algorithme de hachage utilisé pour créer la signature. Les valeurs prises en charge sont `SHA1` et `SHA256`. Si vous ne spécifiez pas ce paramètre, la CloudFront valeur par défaut est. `SHA1`

## Création d’une déclaration de politique pour une URL signée qui utilise une politique personnalisée
<a name="private-content-custom-policy-statement"></a>

Effectuez la procédure suivante pour créer une déclaration de politique pour une URL signée qui utilise une politique personnalisée.

Pour obtenir des exemples de déclaration de politique qui contrôlent l’accès aux fichiers de différentes façons, consultez [Exemple d’une déclaration de politique pour une URL signée qui utilise une politique personnalisée](#private-content-custom-policy-statement-examples).<a name="private-content-custom-policy-creating-policy-procedure"></a>

**Pour créer la déclaration de politique d’une URL signée qui utilise une politique personnalisée**

1. Construisez la déclaration de politique à l’aide du format JSON suivant. Remplacez les symboles inférieur à (`<`) et supérieur à (`>`), ainsi que les descriptions qu'ils contiennent, par vos propres valeurs. Pour de plus amples informations, veuillez consulter [Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique personnalisée](#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>"
                   }
               }
           }
       ]
   }
   ```

   Notez ce qui suit :
   + Vous pouvez inclure une seule déclaration dans cette politique.
   + Utilisez l’encodage de caractères UTF-8.
   + Incluez la ponctuation et les noms de paramètre exactement comme spécifié. Les abréviations ne sont pas acceptées pour les noms de paramètre.
   + L’ordre des paramètres de la section `Condition` n’importe pas.
   + Pour plus d’informations sur les valeurs de `Resource`, `DateLessThan`, `DateGreaterThan` et `IpAddress`, consultez [Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique personnalisée](#private-content-custom-policy-statement-values).

1. Supprimez tous les espaces vides (tabulations et sauts de ligne inclus) de la déclaration de politique. Il se peut que vous ayez à inclure des caractères d’échappement dans la chaîne du code d’application.

1. Encodez en base64 la déclaration de politique à l’aide de l’encodage MIME base64. Pour plus d'informations, consultez [la Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) dans la *RFC 2045, MIME (extensions de messagerie Internet polyvalentes), première partie : Format des* corps de messages Internet.

1. Remplacez les caractères non valides d’une chaîne de requête d’URL par les caractères valides. Le tableau suivant répertorie les caractères valides et non valides.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Ajoutez la valeur obtenue à votre URL signée après `Policy=`.

1. Créez une signature pour l’URL signée en hachant, signant et encodant en base64 la déclaration de politique. Pour de plus amples informations, veuillez consulter [Création d’une signature pour une URL signée qui utilise une politique personnalisée](#private-content-custom-policy-creating-signature).

### Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique personnalisée
<a name="private-content-custom-policy-statement-values"></a>

Lorsque vous créez une déclaration de politique pour une politique personnalisée, vous spécifiez les valeurs suivantes.

**Ressource**  
L'URL, y compris les chaînes de requête, à l'exclusion des `Hash-Algorithm` paramètres CloudFront `Policy` `Signature``Key-Pair-Id`,, et. Par exemple :  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg\?size=large&license=yes`  
Vous ne pouvez spécifier qu’une seule valeur d'URL pour `Resource`.  
Vous pouvez omettre le paramètre `Resource` dans une politique, mais cela signifie que toute personne disposant de l'URL signée peut accéder à *tous* les fichiers de *toute* distribution associée à cette paire de clés que vous utilisez pour créer l'URL signée.
Notez ce qui suit :  
+ **Protocole** : la valeur doit commencer par `http://`, `https://` ou `*://`.
+ **Paramètres de chaîne de requête** : si l'URL contient des paramètres de chaîne de requête, n'utilisez pas de barre oblique inverse (`\`) pour échapper au point d'interrogation (`?`) qui commence la chaîne de requête. Par exemple :

  `https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`
+ **Caractères génériques** : vous pouvez utiliser des caractères génériques dans l'URL de la politique. Les caractères génériques suivants sont pris en charge :
  + astérisque (`*`), qui correspond à zéro, un ou plusieurs caractères
  + point d'interrogation (`?`), qui correspond à un et un seul caractère

  Lorsque l'URL de la politique CloudFront correspond à celle de la requête HTTP, l'URL de la politique est divisée en quatre sections (protocole, domaine, chemin et chaîne de requête) comme suit :

  `[protocol]://[domain]/[path]\?[query string]`

  Lorsque vous utilisez un caractère générique dans l'URL de la politique, la correspondance avec le caractère générique s'applique uniquement dans les limites de la section qui contient ce caractère générique. Par exemple, envisagez l'URL suivante dans une politique :

  `https://www.example.com/hello*world`

  Dans cet exemple, le caractère générique astérisque (`*`) ne s'applique que dans la section du chemin, il correspond donc au URLs `https://www.example.com/helloworld` et`https://www.example.com/hello-world`, mais pas à l'URL. `https://www.example.net/hello?world`

  Les exceptions suivantes s'appliquent aux limites des sections pour la mise en correspondance des caractères génériques :
  + La présence d'un astérisque à la fin de la section de chemin implique un astérisque dans la section de la chaîne de requête. Par exemple, `http://example.com/hello*` équivaut à `http://example.com/hello*\?*`.
  + La présence d'un astérisque à la fin de la section de domaine implique un astérisque dans les sections de chemin et de chaîne de requête. Par exemple, `http://example.com*` équivaut à `http://example.com*/*\?*`.
  + Une URL figurant dans la politique peut omettre la section de protocole et commencer par un astérisque dans la section de domaine. Dans ce cas, la section de protocole est implicitement définie sur un astérisque. Par exemple, l'URL `*example.com` d'une politique est équivalente à `*://*example.com/`.
  + Un astérisque à lui seul (`"Resource": "*"`) correspond à n'importe quelle URL.

  Par exemple, la valeur : `https://d111111abcdef8.cloudfront.net/*game_download.zip*` dans une politique correspond à toutes les valeurs suivantes 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`
+ **Autres noms de domaine** : si vous spécifiez un nom de domaine alternatif (CNAME) dans l’URL de la politique, la requête HTTP doit utiliser ce nom de domaine alternatif dans votre page ou application Web. Ne spécifiez pas l’URL Amazon S3 pour le fichier dans une politique.

**DateLessThan**  
Date et heure d’expiration de l’URL au format horaire Unix (en secondes) et en heure UTC. Dans la politique, n’entourez pas la valeur avec des points d’interrogation. Pour plus d’informations sur l’UTC, consultez [Date et heure sur Internet : Horodatages](https://tools.ietf.org/html/rfc3339).  
Par exemple, l'horodatage 31 janvier 2023 10 h 00 UTC est converti en 1675159200 au format horaire Unix.  
Il s'agit du seul paramètre obligatoire dans `Condition` cette section. CloudFront nécessite cette valeur pour empêcher les utilisateurs d'avoir un accès permanent à votre contenu privé.  
Pour de plus amples informations, consultez [Quand CloudFront vérifie la date et l'heure d'expiration dans une URL signée](private-content-signed-urls.md#private-content-check-expiration).

**DateGreaterThan (Facultatif)**  
(Facultatif) Date et heure de début de l’URL au format horaire Unix (en secondes) et en heure UTC. Les utilisateurs ne sont pas autorisés à accéder au fichier avant la date et l’heure spécifiées. N’entourez pas la valeur de points d’interrogation. 

**IpAddress (Facultatif)**  
Adresse IP du client formulant la requête HTTP. Notez ce qui suit :  
+ Pour autoriser une adresse IP à accéder au fichier, omettez le paramètre `IpAddress`.
+ Vous pouvez spécifier une adresse IP ou une plage d’adresses IP. Vous ne pouvez pas utiliser cette politique pour autoriser l’accès si l’adresse IP du client figure dans l’une des deux plages distinctes.
+ Pour autoriser l’accès depuis une seule adresse IP, vous spécifiez :

  `"`*IPv4 IP address*`/32"`
+ Vous devez spécifier les plages d'adresses IP au format IPv4 CIDR standard (par exemple,`192.0.2.0/24`). Pour plus d’informations, consultez [Routage inter-domaines sans classe (CIDR) : plan d'agrégation et d'affectation d'adresses Internet](https://tools.ietf.org/html/rfc4632).
**Important**  
Les adresses IP au IPv6 format 2001:0 db 8:85 a3 : :8a2e : 0370:7334 ne sont pas prises en charge. 

  Si vous utilisez une politique personnalisée qui inclut`IpAddress`, n'activez pas IPv6 la distribution. Si vous souhaitez restreindre l'accès à certains contenus par adresse IP et répondre aux IPv6 demandes d'assistance pour d'autres contenus, vous pouvez créer deux distributions. Pour plus d’informations, consultez [Activer IPv6 (demandes du spectateur)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).

## Exemple d’une déclaration de politique pour une URL signée qui utilise une politique personnalisée
<a name="private-content-custom-policy-statement-examples"></a>

Les exemples suivants de déclaration de politique montrent comment accéder à un fichier spécifique, à tous les objets d’un répertoire ou à tous les fichiers associés à un ID de paire de clés. Les exemples montrent aussi comment contrôler l’accès depuis une adresse IP individuelle ou une plage d’adresses IP, et comment empêcher les utilisateurs d’employer l’URL signée au-delà d’une date et heure spécifiées.

Si vous copiez et collez l’un de ces exemples, supprimez les espaces vides (y compris les tabulations et les sauts de ligne), remplacez les valeurs par vos propres valeurs et incluez un caractère de saut de ligne après l’accolade fermante (`}`).

Pour de plus amples informations, veuillez consulter [Valeurs que vous spécifiez dans la déclaration de politique d’une URL signée utilisant une politique personnalisée](#private-content-custom-policy-statement-values).

**Topics**
+ [Exemple de déclaration de politique : accès à un fichier à partir d’une plage d’adresses IP](#private-content-custom-policy-statement-example-one-object)
+ [Exemple de déclaration de politique : accès à tous les fichiers d’un répertoire à partir d’une plage d’adresses IP](#private-content-custom-policy-statement-example-all-objects)
+ [Exemple de déclaration de politique : accès à tous les fichiers associés à un ID de paire de clés à partir d’une adresse IP](#private-content-custom-policy-statement-example-one-ip)

### Exemple de déclaration de politique : accès à un fichier à partir d’une plage d’adresses IP
<a name="private-content-custom-policy-statement-example-one-object"></a>

L’exemple suivant de politique personnalisée dans une URL signée spécifie qu’un utilisateur peut accéder au fichier `https://d111111abcdef8.cloudfront.net/game_download.zip` à partir des adresses IP de la plage `192.0.2.0/24` jusqu’au 31 janvier 2023 10 h 00 UTC :

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

### Exemple de déclaration de politique : accès à tous les fichiers d’un répertoire à partir d’une plage d’adresses IP
<a name="private-content-custom-policy-statement-example-all-objects"></a>

L'exemple de politique personnalisée suivant vous permet de créer une signature URLs pour n'importe quel fichier du `training` répertoire, comme indiqué par le caractère générique astérisque (`*`) dans le `Resource` paramètre. Les utilisateurs peuvent accéder au fichier depuis une adresse IP de la plage `192.0.2.0/24` jusqu’au 31 janvier 2023 10 h 00 UTC :

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

Chaque URL signée avec laquelle vous utilisez cette politique inclut une URL qui identifie un fichier spécifique ; par exemple :

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Exemple de déclaration de politique : accès à tous les fichiers associés à un ID de paire de clés à partir d’une adresse IP
<a name="private-content-custom-policy-statement-example-one-ip"></a>

L'exemple de politique personnalisée suivant vous permet de créer une signature URLs pour n'importe quel fichier associé à n'importe quelle distribution, comme indiqué par le caractère générique astérisque (`*`) dans le `Resource` paramètre. L'URL signée doit utiliser le protocole `https://`, et non `http://`. L’utilisateur doit employer l’adresse IP `192.0.2.10/32`. (La valeur `192.0.2.10/32` en notation CIDR fait référence à une seule adresse IP, `192.0.2.10`.) Les fichiers ne sont disponibles qu’entre le 31 janvier 2023 10 h 00 UTC et le 2 février 2023 10 h 00 UTC :

```
{
    "Statement": [
       {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1675159200
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675332000
                }
            }
        }
    ]
}
```

Chaque URL signée avec laquelle vous utilisez cette politique possède une URL qui identifie un fichier spécifique dans une CloudFront distribution spécifique, par exemple :

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

L’URL signée inclut aussi un ID de paire de clés, qui doit être associé à un groupe de clés autorisé dans la distribution (d111111abcdef8.cloudfront.net) que vous spécifiez dans l’URL.

## Création d’une signature pour une URL signée qui utilise une politique personnalisée
<a name="private-content-custom-policy-creating-signature"></a>

La signature d’une URL signée utilisant une politique personnalisée est une version hachée, signée et encodée en base64 de la déclaration de politique. Pour créer une signature pour une politique personnalisée, procédez comme suit.

Pour plus d’informations et d’exemples sur la façon de hacher, signer et encoder la déclaration de politique, consultez :
+ [Utilisation d’une commande Linux et OpenSSL pour le chiffrement et l’encodage en base64](private-content-linux-openssl.md)
+ [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md)

**Note**  
Les exemples liés utilisent SHA-1 par défaut. Pour utiliser SHA-256 à la place, remplacez `sha1` par `sha256` dans les commandes OpenSSL et incluez le paramètre de `Hash-Algorithm=SHA256` requête dans l'URL signée.<a name="private-content-custom-policy-creating-signature-download-procedure"></a>

**Option 1 : Créer une signature à l’aide d’une politique personnalisée**

1. Utilisez la fonction de hachage SHA-1 ou SHA-256 et la clé privée RSA ou ECDSA générée pour hacher et signer la déclaration de politique JSON que vous avez créée dans la procédure. [Pour créer la déclaration de politique d’une URL signée qui utilise une politique personnalisée](#private-content-custom-policy-creating-policy-procedure) Utilisez la version de la déclaration de politique qui n’inclut plus d’espaces vides, mais qui n’a pas encore été encodée en base64.

   Si vous utilisez SHA-256, vous devez l'inclure `&Hash-Algorithm=SHA256` dans l'URL signée.

   Pour la clé privée requise par la fonction de hachage, utilisez une clé privée dont la clé publique se trouve dans un groupe de clés approuvé actif pour la distribution.
**Note**  
La méthode que vous utilisez pour hacher et signer la déclaration de politique dépend du langage de programmation et de la plateforme. Pour un exemple de code, consultez [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md).

1. Supprimez les espaces vides (tabulations et sauts de ligne inclus) de la chaîne hachée et signée.

1. Encodez en base64 la chaîne à l’aide de l’encodage MIME base64. Pour plus d'informations, consultez [la Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) dans la *RFC 2045, MIME (extensions de messagerie Internet polyvalentes), première partie : Format des* corps de messages Internet.

1. Remplacez les caractères non valides d’une chaîne de requête d’URL par les caractères valides. Le tableau suivant répertorie les caractères valides et non valides.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Ajoutez la valeur obtenue à votre URL signée après `&Signature=`, et retournez à [Pour créer une URL signée utilisant une politique personnalisée](#private-content-creating-signed-url-custom-policy-procedure) pour terminer la concaténation des parties de votre URL signée.

# Utilisation de cookies signés
<a name="private-content-signed-cookies"></a>

CloudFront les cookies signés vous permettent de contrôler qui peut accéder à votre contenu lorsque vous ne souhaitez pas modifier votre contenu actuel URLs ou lorsque vous souhaitez donner accès à plusieurs fichiers restreints, par exemple tous les fichiers de la zone réservée aux abonnés d'un site Web. Cette rubrique explique l’utilisation des cookies signés et décrit comment les définir à l’aide de politiques prédéfinies et personnalisées.

**Topics**
+ [Choix entre des politiques prédéfinies et personnalisées pour les cookies signés](#private-content-choosing-canned-custom-cookies)
+ [Fonctionnement des cookies signés](#private-content-how-signed-cookies-work)
+ [Prévention du mauvais usage des cookies signés](#private-content-signed-cookie-misuse)
+ [Quand CloudFront vérifie la date et l'heure d'expiration dans un cookie signé](#private-content-check-expiration-cookie)
+ [Exemple de code et outils tiers](#private-content-overview-sample-code-cookies)
+ [Définition de cookies signés à l’aide d’une politique prédéfinie](private-content-setting-signed-cookie-canned-policy.md)
+ [Définition de cookies signés utilisant une politique personnalisée](private-content-setting-signed-cookie-custom-policy.md)
+ [Création de cookies signés avec PHP](signed-cookies-PHP.md)

## Choix entre des politiques prédéfinies et personnalisées pour les cookies signés
<a name="private-content-choosing-canned-custom-cookies"></a>

Lorsque vous créez un cookie signé, vous écrivez une instruction de politique au format JSON qui spécifie les restrictions sur le cookie signé : par exemple, la durée de validité du cookie. Vous pouvez utiliser une politique prédéfinie ou une politique personnalisé e. Le tableau suivant compare les politiques prédéfinies et les politiques personnalisées :


****  

| Description | Politique prédéfinie | Politique personnalisée | 
| --- | --- | --- | 
| Vous pouvez réutiliser la déclaration de politique pour plusieurs fichiers. Pour ce faire, vous devez utiliser les caractères génériques de l’objet `Resource`. Pour plus d’informations, consultez [Valeurs que vous spécifiez dans la déclaration de politique d’une politique personnalisée pour les cookies signés](private-content-setting-signed-cookie-custom-policy.md#private-content-custom-policy-statement-cookies-values).)  | Non | Oui | 
| Vous pouvez indiquer la date et l’heure auxquelles les utilisateurs peuvent commencer à accéder à votre contenu | Non | Oui (facultatif) | 
| Vous pouvez indiquer la date et l’heure auxquelles les utilisateurs ne peuvent plus accéder à votre contenu | Oui | Oui | 
| Vous pouvez spécifier l’adresse IP ou la plage d’adresses IP des utilisateurs qui peuvent accéder à votre contenu | Non | Oui (facultatif) | 

Pour plus d’informations sur la création de cookies signés à l’aide d’une politique prédéfinie, consultez [Définition de cookies signés à l’aide d’une politique prédéfinie](private-content-setting-signed-cookie-canned-policy.md).

Pour plus d’informations sur la création de cookies signés à l’aide d’une politique personnalisée, consultez [Définition de cookies signés utilisant une politique personnalisée](private-content-setting-signed-cookie-custom-policy.md).

## Fonctionnement des cookies signés
<a name="private-content-how-signed-cookies-work"></a>

Voici un aperçu de la façon dont vous configurez CloudFront les cookies signés et de la manière dont vous CloudFront répondez lorsqu'un utilisateur soumet une demande contenant un cookie signé. 

1. Dans votre CloudFront distribution, spécifiez un ou plusieurs groupes de clés fiables, qui contiennent les clés publiques CloudFront pouvant être utilisées pour vérifier la signature de l'URL. Vous utilisez les clés privées correspondantes pour signer le URLs.

   Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).

1. Vous développez votre application pour déterminer si un utilisateur doit avoir accès à votre contenu et, si tel est le cas, pour envoyer trois en-têtes `Set-Cookie` à l’utilisateur. (Chaque `Set-Cookie` en-tête ne peut contenir qu'une seule paire nom-valeur, et un cookie CloudFront signé nécessite trois paires nom-valeur.) Vous devez envoyer les en-têtes `Set-Cookie` à l’utilisateur avant qu’il ne demande votre contenu privé. Si vous définissez une durée d’expiration brève sur le cookie, il se peut aussi que vous vouliez envoyer trois en-têtes `Set-Cookie` supplémentaires en réponse aux demandes suivantes, de telle sorte que l’utilisateur puisse continuer à y accéder.

   En règle générale, votre CloudFront distribution aura au moins deux comportements de cache, l'un qui ne nécessite pas d'authentification et l'autre qui en nécessite une. La page d’erreur de la partie sécurisé du site inclut une redirection ou un lien vers une page de connexion.

   Si vous configurez votre distribution pour mettre en cache des fichiers basés sur des cookies, CloudFront elle ne met pas en cache des fichiers séparés en fonction des attributs des cookies signés.

1. Un utilisateur se connecte à votre site web et paie le contenu ou satisfait à quelques autres exigences pour l’accès.

1. Votre application renvoie les en-têtes `Set-Cookie` dans la réponse, et l’utilisateur stocke les paires nom-valeur.

1. L’utilisateur demande un fichier.

   Le navigateur de cet utilisateur ou d’un autre obtient les paires nom-valeur de l’étape 4 et les ajoute à la demande dans un en-tête `Cookie`. Il s’agit du cookie signé.

1. CloudFront utilise la clé publique pour valider la signature du cookie signé et pour confirmer que le cookie n'a pas été falsifié. Si la signature n’est pas valide, la demande est rejetée.

   Si la signature contenue dans le cookie est valide, CloudFront consultez la déclaration de politique contenue dans le cookie (ou créez-en une si vous utilisez une politique prédéfinie) pour confirmer que la demande est toujours valide. Par exemple, si vous avez spécifié une date et une heure de début et de fin pour le cookie, cela CloudFront confirme que l'utilisateur essaie d'accéder à votre contenu pendant la période pendant laquelle vous souhaitez autoriser l'accès.

   Si la demande répond aux exigences de la déclaration de politique, CloudFront diffuse votre contenu comme elle le fait pour le contenu non restreint : elle détermine si le fichier se trouve déjà dans le cache périphérique, transmet la demande à l'origine si nécessaire et renvoie le fichier à l'utilisateur.

## Prévention du mauvais usage des cookies signés
<a name="private-content-signed-cookie-misuse"></a>

Si vous spécifiez le paramètre `Domain` dans un en-tête `Set-Cookie`, spécifiez la valeur la plus précise possible pour réduire les possibilités d’accès par une personne ayant le même nom de domaine racine. Par exemple, app.example.com est préférable à example.com, particulièrement quand vous ne contrôlez pas example.com. Vous empêchez ainsi qu’une personne accède à votre contenu depuis www.example.com.

Pour contribuer à empêcher ce type d’attaque, procédez comme suit :
+ Excluez les attributs de cookie `Expires` et `Max-Age`, de telle sorte que l’en-tête `Set-Cookie` crée un cookie de session. Les cookies de session sont automatiquement supprimés quand l’utilisateur clôt le navigateur, ce qui réduit la possibilité que quelqu’un n’obtienne un accès non autorisé à votre contenu.
+ Incluez l’attribut `Secure`, de telle sorte que le cookie soit chiffré quand un utilisateur l’inclut dans une demande.
+ Chaque fois que possible, utilisez une politique personnalisée et incluez l’adresse IP de l’utilisateur.
+ Dans l’attribut `CloudFront-Expires`, spécifiez la durée d’expiration raisonnable la plus courte selon la période pendant laquelle vous autorisez les utilisateurs à accéder à votre contenu.

## Quand CloudFront vérifie la date et l'heure d'expiration dans un cookie signé
<a name="private-content-check-expiration-cookie"></a>

Pour déterminer si un cookie signé est toujours valide, CloudFront vérifie la date et l'heure d'expiration du cookie au moment de la requête HTTP. Si un client commence à télécharger un fichier volumineux immédiatement avant la date d’expiration, le téléchargement se termine même si la date d’expiration intervient pendant le téléchargement. Si la connexion TCP cesse et que le client essaie de redémarrer le téléchargement une fois la date d’expiration passée, le téléchargement échoue.

Si un client utilise Range GETs pour obtenir un fichier en petits morceaux, toute requête GET exécutée après l'expiration du délai d'expiration échouera. Pour plus d'informations sur Range GETs, consultez[Comment CloudFront traite les demandes partielles pour un objet (plage GETs)](RangeGETs.md).

## Exemple de code et outils tiers
<a name="private-content-overview-sample-code-cookies"></a>

L'exemple de code pour le contenu privé montre uniquement comment créer la signature pour le contenu signé URLs. Cependant, le processus de création d’une signature d’un cookie signé étant très similaire, une grande partie de l’exemple de code continue à être pertinente. Pour plus d’informations, consultez les rubriques suivantes : 
+ [Créer une signature d’URL avec Perl](CreateURLPerl.md)
+ [Créer une signature d’URL avec PHP](CreateURL_PHP.md)
+ [Créer une signature d’URL avec C\$1 et .NET Framework](CreateSignatureInCSharp.md)
+ [Créer une signature d’URL avec Java](CFPrivateDistJavaDevelopment.md)

# Définition de cookies signés à l’aide d’une politique prédéfinie
<a name="private-content-setting-signed-cookie-canned-policy"></a>

Pour définir un cookie signé à l’aide d’une politique prédéfinie, procédez comme suit. Pour créer la signature, consultez [Création d’une signature pour un cookie signé qui utilise une politique prédéfinie](#private-content-canned-policy-signature-cookies).<a name="private-content-setting-signed-cookie-canned-policy-procedure"></a>

**Pour définir un cookie signé à l’aide d’une politique prédéfinie**

1. Si vous utilisez .NET ou Java pour créer des cookies signés et si vous n’avez pas reformaté la clé privée de votre paire de clés du format par défaut .pem en un format compatible avec .NET ou Java, procédez comme suit : Pour de plus amples informations, veuillez consulter [Reformatage de la clé privée (.NET et Java uniquement)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programmez votre application pour qu'elle envoie trois `Set-Cookie` en-têtes aux utilisateurs approuvés (ou quatre, si vous souhaitez spécifier un algorithme de hachage). Vous avez besoin de trois en-têtes `Set-Cookie` parce que chaque en-tête `Set-Cookie` ne peut contenir qu'une seule paire nom-valeur, et qu'un cookie signé CloudFront nécessite trois paires nom-valeur. Les paires nom-valeur sont : `CloudFront-Expires`, `CloudFront-Signature` et `CloudFront-Key-Pair-Id`. Vous pouvez éventuellement inclure une quatrième paire nom-valeur pour spécifier l'algorithme de hachage utilisé pour la signature. `CloudFront-Hash-Algorithm` Les valeurs doivent être présentes sur la visionneuse avant qu’un utilisateur ne puisse faire la requête d’un fichier dont vous voulez contrôler l’accès. 
**Note**  
En règle générale, nous recommandons d’exclure les attributs `Expires` et `Max-Age`. L’exclusion des attributs conduit le navigateur à supprimer le cookie quand l’utilisateur ferme le navigateur, ce qui réduit la possibilité qu’une personne obtienne un accès non autorisé à votre contenu. Pour plus d’informations, consultez [Prévention du mauvais usage des cookies signés](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Les noms des attributs de cookie sont sensibles à la casse**. 

   Les sauts de ligne ne sont inclus que pour rendre les attributs plus lisibles.

   ```
   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
   
   Set-Cookie: 
   CloudFront-Hash-Algorithm=SHA1 or SHA256; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Facultatif) `Domain` **  
Nom de domaine du fichier demandé. Si vous ne spécifiez pas un attribut `Domain`, la valeur par défaut est le nom de domaine de l’URL et ne s’applique qu’au nom de domaine spécifié, non aux sous-domaines. Si vous spécifiez un attribut `Domain`, il s’applique aussi aux sous-domaines. Un point devant le nom de domaine (par exemple, `Domain=.example.com`) est facultatif. De plus, si vous spécifiez un attribut `Domain`, le nom de domaine de l’URL et la valeur de l’attribut `Domain` doivent correspondre.  
Vous pouvez spécifier le nom de domaine CloudFront attribué à votre distribution, par exemple d111111abcdef8.cloudfront.net, mais vous ne pouvez pas spécifier\$1.cloudfront.net pour le nom de domaine.  
Si vous souhaitez utiliser un autre nom de domaine tel que exemple.com dans URLs, vous devez ajouter le nom de domaine alternatif à votre distribution, que vous spécifiiez ou non l'`Domain`attribut. Pour plus d’informations, consultez [Noms de domaine alternatifs (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).  
**(Facultatif) `Path` **  
Chemin d’accès du fichier demandé. Si vous ne spécifiez pas d’attribut `Path`, la valeur par défaut est le chemin d’accès de l’URL.  
**`Secure`**  
Nécessite que l’utilisateur chiffre les cookies avant d’envoyer une demande. Nous vous recommandons d'envoyer l'`Set-Cookie`en-tête via une connexion HTTPS pour vous assurer que les attributs du cookie sont protégés contre man-in-the-middle les attaques.  
**`HttpOnly`**  
Définit la manière dont le navigateur (lorsqu’il est pris en charge) interagit avec la valeur du cookie. Avec`HttpOnly`, les valeurs des cookies ne sont pas accessibles à JavaScript. Cette précaution permet d’atténuer les attaques par scripts inter-site (XSS). Pour plus d’informations, consultez [Utilisation de cookies HTTPS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies).  
**`CloudFront-Expires`**  
Spécifiez la date et l’heure d’expiration au format horaire Unix (en secondes) et en heure UTC. Par exemple, le 1er janvier 2026 à 10 h UTC est converti en 1767290400 au format horaire Unix.   
Pour utiliser l’heure époque, indiquez un entier 64 bits correspondant à une date qui ne dépasse pas `9223372036854775807` (vendredi 11 avril 2262 à 23:47:16.854 UTC).  
Pour plus d’informations sur l’UTC, consultez *RFC 3339, Date et heure sur Internet : Horodatages*, [https://tools.ietf.org/html/rfc3339](https://tools.ietf.org/html/rfc3339).  
**`CloudFront-Signature`**  
Version hachée, signée et encodée en base 64 d’une déclaration de politique JSON. Pour de plus amples informations, veuillez consulter [Création d’une signature pour un cookie signé qui utilise une politique prédéfinie](#private-content-canned-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
L'ID d'une clé CloudFront publique, par exemple,`K2JCJMDEHXQW5F`. L'ID de clé publique indique CloudFront la clé publique à utiliser pour valider l'URL signée. CloudFront compare les informations de la signature avec celles de la déclaration de politique pour vérifier que l'URL n'a pas été falsifiée.  
Cette clé publique doit appartenir à un groupe de clés qui est un signataire approuvé dans la distribution. Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).  
**`CloudFront-Hash-Algorithm`**  
(Facultatif) L'algorithme de hachage utilisé pour créer la signature. Les valeurs prises en charge sont `SHA1` et `SHA256`. Si vous n'incluez pas ce cookie, la CloudFront valeur par défaut est. `SHA1`

L'exemple suivant montre `Set-Cookie` les en-têtes d'un cookie signé lorsque vous utilisez le nom de domaine associé à votre distribution dans URLs vos fichiers :

```
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
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
```

L'exemple suivant montre `Set-Cookie` les en-têtes d'un cookie signé lorsque vous utilisez le nom de domaine alternatif exemple.org URLs pour vos fichiers :

```
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
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/images/*; Secure; HttpOnly
```

Si vous souhaitez utiliser un autre nom de domaine tel que exemple.com dans URLs, vous devez ajouter le nom de domaine alternatif à votre distribution, que vous spécifiiez ou non l'`Domain`attribut. Pour plus d’informations, consultez [Noms de domaine alternatifs (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).

## Création d’une signature pour un cookie signé qui utilise une politique prédéfinie
<a name="private-content-canned-policy-signature-cookies"></a>

Pour créer la signature pour un cookie signé qui utilise une politique prédéfinie, suivez les procédures suivantes.

**Topics**
+ [Création d’une déclaration de politique pour un cookie signé qui utilise une politique prédéfinie](#private-content-canned-policy-statement-cookies)
+ [Signature d’une déclaration de politique pour créer une signature pour un cookie signé qui utilise une politique prédéfinie](#private-content-canned-policy-cookies-signing-policy-statement)

### Création d’une déclaration de politique pour un cookie signé qui utilise une politique prédéfinie
<a name="private-content-canned-policy-statement-cookies"></a>

Lorsque vous définissez un cookie signé qui utilise une politique prédéfinie, l’attribut `CloudFront-Signature` est une version hachée et signée d’une déclaration de politique. Pour les cookies signés qui utilisent une politique prédéfinie, vous n’incluez pas la déclaration de politique dans l’en-tête `Set-Cookie`, comme vous le faites pour les cookies signés qui utilisent une politique personnalisée. Pour créer l’a déclaration de politique, procédez comme suit.<a name="private-content-canned-policy-statement-cookies-procedure"></a>

**Pour créer une déclaration de politique pour un cookie signé qui utilise une politique prédéfinie**

1. Construisez la déclaration de politique à l’aide du format JSON suivant et de l’encodage de caractères UTF-8. Incluez la ponctuation et les autres valeurs littérales exactement comme spécifié. Pour plus d’informations sur les paramètres `Resource` et `DateLessThan`, consultez [Valeurs que vous spécifiez dans la déclaration de politique d’une politique prédéfinie pour les cookies signés](#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. Supprimez tous les espaces vides (tabulations et sauts de ligne inclus) de la déclaration de politique. Il se peut que vous ayez à inclure des caractères d’échappement dans la chaîne du code d’application.

#### Valeurs que vous spécifiez dans la déclaration de politique d’une politique prédéfinie pour les cookies signés
<a name="private-content-canned-policy-statement-cookies-values"></a>

Lorsque vous créez une déclaration de politique pour une politique prédéfinie, vous spécifiez les valeurs suivantes :

**Ressource**  
L’URL de base incluant vos chaînes de requête, le cas échéant ; par exemple :  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Vous ne pouvez spécifier qu’une seule valeur pour `Resource`.  
Remarques :  
+ **Protocole** : la valeur doit commencer par `http://` ou `https://`.
+ **Paramètres de chaîne de requête** : si vous n’avez aucun paramètre de chaîne de requête, omettez le point d’interrogation.
+ **Noms de domaine alternatifs** : si vous spécifiez un nom de domaine alternatif (CNAME) dans l’URL, vous devez le spécifier lorsque vous référencez le fichier dans votre page ou application web. Ne spécifiez pas l’URL Amazon S3 pour le fichier.

**DateLessThan**  
Date et heure d’expiration de l’URL au format horaire Unix (en secondes) et en heure UTC. N’entourez pas la valeur de points d’interrogation.  
Par exemple, la date 16 mars 2015 10 h 00 UTC est convertie en 1426500000 au format horaire Unix.  
Cette valeur doit correspondre à la valeur de l’attribut `CloudFront-Expires` de l’en-tête `Set-Cookie`. N’entourez pas la valeur de points d’interrogation.  
Pour plus d’informations, consultez [Quand CloudFront vérifie la date et l'heure d'expiration dans un cookie signé](private-content-signed-cookies.md#private-content-check-expiration-cookie).

#### Exemple de déclaration de politique pour une politique prédéfinie
<a name="private-content-canned-policy-cookies-sample-policy-statement"></a>

Lorsque vous utilisez l’exemple de déclaration de politique suivant dans un cookie signé, un utilisateur peut accéder au fichier `https://d111111abcdef8.cloudfront.net/horizon.jpg` jusqu’au 16 mars 2015 10 h 00 UTC :

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1426500000
                }
            }
        }
    ]
}
```

### Signature d’une déclaration de politique pour créer une signature pour un cookie signé qui utilise une politique prédéfinie
<a name="private-content-canned-policy-cookies-signing-policy-statement"></a>

Pour créer la valeur de l’attribut `CloudFront-Signature` d’un en-tête `Set-Cookie`, vous hachez et signez la déclaration de politique que vous avez créée dans [Pour créer une déclaration de politique pour un cookie signé qui utilise une politique prédéfinie](#private-content-canned-policy-statement-cookies-procedure). 

Pour plus d’informations et d’exemples sur la façon de hacher, signer et encoder la déclaration de politique, consultez les rubriques suivantes :
+ [Utilisation d’une commande Linux et OpenSSL pour le chiffrement et l’encodage en base64](private-content-linux-openssl.md)
+ [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md)

**Note**  
Les exemples liés utilisent SHA-1 par défaut. Pour utiliser SHA-256 à la place, remplacez `sha1` par `sha256` dans les commandes OpenSSL et incluez le cookie avec une valeur de`CloudFront-Hash-Algorithm`. `SHA256`<a name="private-content-canned-policy-cookie-creating-signature-procedure"></a>

**Pour créer une signature pour un cookie signé qui utilise une politique prédéfinie**

1. Utilisez la fonction de hachage SHA-1 ou SHA-256 et RSA pour hacher et signer la déclaration de politique que vous avez créée au cours de la procédure. [Pour créer une déclaration de politique pour un cookie signé qui utilise une politique prédéfinie](#private-content-canned-policy-statement-cookies-procedure) Utilisez la version de la déclaration de politique qui n’inclut plus d’espaces vides.

   Si vous utilisez SHA-256, vous devez inclure le `CloudFront-Hash-Algorithm` cookie avec une valeur de. `SHA256`

   Pour la clé privée requise par la fonction de hachage, utilisez une clé privée dont la clé publique se trouve dans un groupe de clés approuvé actif pour la distribution.
**Note**  
La méthode que vous utilisez pour hacher et signer la déclaration de politique dépend du langage de programmation et de la plateforme. Pour un exemple de code, consultez [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md).

1. Supprimez les espaces vides (tabulations et sauts de ligne inclus) de la chaîne hachée et signée.

1. Encodez en base64 la chaîne à l’aide de l’encodage MIME base64. Pour plus d'informations, consultez [la Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) dans la *RFC 2045, MIME (extensions de messagerie Internet polyvalentes), première partie : Format des* corps de messages Internet.

1. Remplacez les caractères non valides d’une chaîne de requête d’URL par les caractères valides. Le tableau suivant répertorie les caractères valides et non valides.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html)

1. Incluez la valeur obtenue dans l’en-tête `Set-Cookie` de la paire nom-valeur `CloudFront-Signature`. Puis retournez à [Pour définir un cookie signé à l’aide d’une politique prédéfinie](#private-content-setting-signed-cookie-canned-policy-procedure) pour ajouter l’en-tête `Set-Cookie` de `CloudFront-Key-Pair-Id`.

# Définition de cookies signés utilisant une politique personnalisée
<a name="private-content-setting-signed-cookie-custom-policy"></a>

Pour définir un cookie signé qui utilise une politique personnalisée, effectuez la procédure suivante.<a name="private-content-setting-signed-cookie-custom-policy-procedure"></a>

**Pour définir un cookie signé utilisant une politique personnalisée**

1. Si vous utilisez .NET ou Java pour créer des fichiers signés URLs, et si vous n'avez pas reformaté la clé privée de votre paire de clés du format .pem par défaut à un format compatible avec .NET ou Java, faites-le maintenant. Pour de plus amples informations, veuillez consulter [Reformatage de la clé privée (.NET et Java uniquement)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programmez votre application pour qu'elle envoie trois `Set-Cookie` en-têtes aux utilisateurs approuvés (ou quatre, si vous souhaitez spécifier un algorithme de hachage). Vous avez besoin de trois `Set-Cookie` en-têtes car chaque `Set-Cookie` en-tête ne peut contenir qu'une seule paire nom-valeur, et un cookie CloudFront signé nécessite trois paires nom-valeur. Les paires nom-valeur sont : `CloudFront-Policy`, `CloudFront-Signature` et `CloudFront-Key-Pair-Id`. Vous pouvez éventuellement inclure une quatrième paire nom-valeur pour spécifier l'algorithme de hachage utilisé pour la signature. `CloudFront-Hash-Algorithm` Les valeurs doivent être présentes sur la visionneuse avant qu’un utilisateur ne puisse faire la requête d’un fichier dont vous voulez contrôler l’accès. 
**Note**  
En règle générale, nous recommandons d’exclure les attributs `Expires` et `Max-Age`. Cette exclusion conduit le navigateur à supprimer le cookie quand l’utilisateur ferme le navigateur, ce qui réduit la possibilité qu’une personne obtienne un accès non autorisé à votre contenu. Pour plus d’informations, consultez [Prévention du mauvais usage des cookies signés](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Les noms des attributs de cookie sont sensibles à la casse**. 

   Les sauts de ligne ne sont inclus que pour rendre les attributs plus lisibles.

   ```
   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
   
   Set-Cookie: 
   CloudFront-Hash-Algorithm=SHA1 or SHA256; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Facultatif) `Domain` **  
Nom de domaine du fichier demandé. Si vous ne spécifiez pas un attribut `Domain`, la valeur par défaut est le nom de domaine de l’URL et ne s’applique qu’au nom de domaine spécifié, non aux sous-domaines. Si vous spécifiez un attribut `Domain`, il s’applique aussi aux sous-domaines. Un point devant le nom de domaine (par exemple, `Domain=.example.com`) est facultatif. De plus, si vous spécifiez un attribut `Domain`, le nom de domaine de l’URL et la valeur de l’attribut `Domain` doivent correspondre.  
Vous pouvez spécifier le nom de domaine CloudFront attribué à votre distribution, par exemple d111111abcdef8.cloudfront.net, mais vous ne pouvez pas spécifier\$1.cloudfront.net pour le nom de domaine.  
Si vous souhaitez utiliser un autre nom de domaine tel que exemple.com dans URLs, vous devez ajouter le nom de domaine alternatif à votre distribution, que vous spécifiiez ou non l'`Domain`attribut. Pour plus d’informations, consultez [Noms de domaine alternatifs (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).  
**(Facultatif) `Path` **  
Chemin d’accès du fichier demandé. Si vous ne spécifiez pas d’attribut `Path`, la valeur par défaut est le chemin d’accès de l’URL.  
**`Secure`**  
Nécessite que l’utilisateur chiffre les cookies avant d’envoyer une demande. Nous vous recommandons d'envoyer l'`Set-Cookie`en-tête via une connexion HTTPS pour vous assurer que les attributs du cookie sont protégés contre man-in-the-middle les attaques.  
**`HttpOnly`**  
Requiert que l’utilisateur n’envoie le cookie que dans les requêtes HTTP ou HTTPS.  
**`CloudFront-Policy`**  
Votre déclaration de politique au format JSON, avec suppression des espaces vide, puis encodage en base64. Pour de plus amples informations, veuillez consulter [Création d’une signature pour un cookie signé qui utilise une politique personnalisée](#private-content-custom-policy-signature-cookies).  
La déclaration de politique contrôle l’accès accordé par un cookie signé à un utilisateur. Elle inclut les fichiers auxquels l’utilisateur peut accéder, une date et une heure d’expiration, une date et une heure (facultatif) auxquelles l’URL devient valide et une adresse IP (facultatif) ou une plage d’adresses IP autorisées à accéder au fichier.  
**`CloudFront-Signature`**  
Version hachée, signée et encodée en base 64 de la déclaration de politique JSON. Pour de plus amples informations, veuillez consulter [Création d’une signature pour un cookie signé qui utilise une politique personnalisée](#private-content-custom-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
L'ID d'une clé CloudFront publique, par exemple,`K2JCJMDEHXQW5F`. L'ID de clé publique indique CloudFront la clé publique à utiliser pour valider l'URL signée. CloudFrontcompare les informations de la signature avec celles de la déclaration de politique pour vérifier que l'URL n'a pas été falsifiée.  
Cette clé publique doit appartenir à un groupe de clés qui est un signataire approuvé dans la distribution. Pour de plus amples informations, veuillez consulter [Spécifiez les signataires autorisés à créer des cookies signés URLs et signés](private-content-trusted-signers.md).  
**`CloudFront-Hash-Algorithm`**  
(Facultatif) L'algorithme de hachage utilisé pour créer la signature. Les valeurs prises en charge sont `SHA1` et `SHA256`. Si vous n'incluez pas ce cookie, la CloudFront valeur par défaut est. `SHA1`

## Exemples d’en-têtes `Set-Cookie` pour les politiques personnalisées
<a name="example-set-cookie-headers-custom-policy"></a>

Consultez les exemples de paires d’en-têtes `Set-Cookie` suivants. 

Si vous souhaitez utiliser un autre nom de domaine tel que exemple.org dans URLs, vous devez ajouter le nom de domaine alternatif à votre distribution, que vous spécifiiez ou non l'`Domain`attribut. Pour plus d’informations, consultez [Noms de domaine alternatifs (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).

**Example Exemple 1**  
Vous pouvez utiliser `Set-Cookie` les en-têtes d'un cookie signé lorsque vous utilisez le nom de domaine associé à votre distribution dans URLs vos fichiers.  

```
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
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Exemple 2**  
Vous pouvez utiliser `Set-Cookie` les en-têtes d'un cookie signé lorsque vous utilisez un autre nom de domaine (exemple.org) URLs pour vos fichiers.  

```
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
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/; Secure; HttpOnly
```

**Example Exemple 3**  
Vous pouvez utiliser les paires d'`Set-Cookie`en-têtes pour une demande signée lorsque vous utilisez le nom de domaine associé à votre distribution dans vos fichiers. URLs   

```
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
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Exemple 4**  
Vous pouvez utiliser les paires `Set-Cookie` d'en-têtes pour une demande signée lorsque vous utilisez un autre nom de domaine (exemple.org) associé à votre distribution dans le fichier URLs pour vos fichiers.  

```
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
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/; Secure; HttpOnly
```

## Création d’une déclaration de politique pour un cookie signé qui utilise une politique personnalisée
<a name="private-content-custom-policy-statement-cookies"></a>

Pour créer une déclaration de politique pour une politique personnalisée, effectuez la procédure suivante. Pour obtenir des exemples de déclaration de politique qui contrôlent l’accès aux fichiers de différentes façons, consultez [Exemple d’une déclaration de politique pour un cookie signé qui utilise une politique personnalisée](#private-content-custom-policy-statement-signed-cookies-examples).<a name="private-content-custom-policy-statement-cookies-procedure"></a>

**Pour créer la déclaration de politique d’un cookie signé qui utilise une politique personnalisée**

1. Construisez la déclaration de politique à l’aide du format JSON suivant.

   ```
   {
       "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"
                   }
               }
           }
       ]
   }
   ```

   Remarques :
   + Vous pouvez inclure une seule instruction.
   + Utilisez l’encodage de caractères UTF-8.
   + Incluez la ponctuation et les noms de paramètre exactement comme spécifié. Les abréviations ne sont pas acceptées pour les noms de paramètre.
   + L’ordre des paramètres de la section `Condition` n’importe pas.
   + Pour plus d’informations sur les valeurs de `Resource`, `DateLessThan`, `DateGreaterThan` et `IpAddress`, consultez [Valeurs que vous spécifiez dans la déclaration de politique d’une politique personnalisée pour les cookies signés](#private-content-custom-policy-statement-cookies-values).

1. Supprimez tous les espaces vides (tabulations et sauts de ligne inclus) de la déclaration de politique. Il se peut que vous ayez à inclure des caractères d’échappement dans la chaîne du code d’application.

1. Encodez en base64 la déclaration de politique à l’aide de l’encodage MIME base64. Pour plus d'informations, consultez [la Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) dans la *RFC 2045, MIME (extensions de messagerie Internet polyvalentes), première partie : Format des* corps de messages Internet.

1. Remplacez les caractères non valides d’une chaîne de requête d’URL par les caractères valides. Le tableau suivant répertorie les caractères valides et non valides.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Incluez la valeur obtenue dans votre en-tête `Set-Cookie` après `CloudFront-Policy=`.

1. Créez une signature pour l’en-tête `Set-Cookie` de `CloudFront-Signature` en hachant, signant et encodant en base64 la déclaration de politique. Pour plus d’informations, consultez [Création d’une signature pour un cookie signé qui utilise une politique personnalisée](#private-content-custom-policy-signature-cookies).

### Valeurs que vous spécifiez dans la déclaration de politique d’une politique personnalisée pour les cookies signés
<a name="private-content-custom-policy-statement-cookies-values"></a>

Lorsque vous créez une déclaration de politique pour une politique personnalisée, vous spécifiez les valeurs suivantes.

**Ressource**  
L’URL de base incluant vos chaînes de requête, le cas échéant :  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Si vous omettez le paramètre `Resource`, les utilisateurs peuvent accéder à tous les fichiers associés à une distribution elle-même associée à la paire de clés que vous utilisez pour créer l’URL signée.
Vous ne pouvez spécifier qu’une seule valeur pour `Resource`.  
Remarques :  
+ **Protocole** : la valeur doit commencer par `http://` ou `https://`.
+ **Paramètres de chaîne de requête** : si vous n’avez aucun paramètre de chaîne de requête, omettez le point d’interrogation.
+ **Caractères génériques** : vous pouvez utiliser à tout moment dans la chaîne, le caractère générique qui correspond à zéro caractère ou plus (\$1) ou celui qui correspond exactement à un seul caractère (?). Par exemple, la valeur :

  `https://d111111abcdef8.cloudfront.net/*game_download.zip*`

  inclut (par exemple) les fichiers suivants :
  + `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`
+ **Noms de domaine alternatifs** : si vous spécifiez un nom de domaine alternatif (CNAME) dans l’URL, vous devez le spécifier lorsque vous référencez le fichier dans votre page ou application web. Ne spécifiez pas l’URL Amazon S3 pour le fichier.

**DateLessThan**  
Date et heure d’expiration de l’URL au format horaire Unix (en secondes) et en heure UTC. N’entourez pas la valeur de points d’interrogation.  
Par exemple, la date 16 mars 2015 10 h 00 UTC est convertie en 1426500000 au format horaire Unix.  
Pour de plus amples informations, veuillez consulter [Quand CloudFront vérifie la date et l'heure d'expiration dans un cookie signé](private-content-signed-cookies.md#private-content-check-expiration-cookie).

**DateGreaterThan (Facultatif)**  
(Facultatif) Date et heure de début de l’URL au format horaire Unix (en secondes) et en heure UTC. Les utilisateurs ne sont pas autorisés à accéder au fichier avant la date et l’heure spécifiées. N’entourez pas la valeur de points d’interrogation. 

**IpAddress (Facultatif)**  
Adresse IP du client formulant la demande GET. Remarques :  
+ Pour autoriser une adresse IP à accéder au fichier, omettez le paramètre `IpAddress`.
+ Vous pouvez spécifier une adresse IP ou une plage d’adresses IP. Par exemple, vous pouvez définir la politique pour autoriser l’accès si l’adresse IP du client figure dans l’une des deux plages distinctes.
+ Pour autoriser l’accès depuis une seule adresse IP, vous spécifiez :

  `"`*IPv4 IP address*`/32"`
+ Vous devez spécifier les plages d'adresses IP au format IPv4 CIDR standard (par exemple,`192.0.2.0/24`). Pour plus d’informations, consultez *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).
**Important**  
Les adresses IP au IPv6 format 2001:0 db 8:85 a3 : :8a2e : 0370:7334 ne sont pas prises en charge. 

  Si vous utilisez une politique personnalisée qui inclut`IpAddress`, n'activez pas IPv6 la distribution. Si vous souhaitez restreindre l'accès à certains contenus par adresse IP et répondre aux IPv6 demandes d'assistance pour d'autres contenus, vous pouvez créer deux distributions. Pour plus d’informations, consultez [Activer IPv6 (demandes du spectateur)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).

## Exemple d’une déclaration de politique pour un cookie signé qui utilise une politique personnalisée
<a name="private-content-custom-policy-statement-signed-cookies-examples"></a>

Les exemples suivants de déclaration de politique montrent comment accéder à un fichier spécifique, à tous les objets d’un répertoire ou à tous les fichiers associés à un ID de paire de clés. Les exemples montrent aussi comment contrôler l’accès depuis une adresse IP individuelle ou une plage d’adresses IP, et comment empêcher les utilisateurs d’employer le cookie signé au-delà d’une date et heure spécifiées.

Si vous copiez et collez l’un de ces exemples, supprimez les espaces vides (y compris les tabulations et les sauts de ligne), remplacez les valeurs par vos propres valeurs et incluez un caractère de saut de ligne après l’accolade fermante ( \$1 ).

Pour de plus amples informations, veuillez consulter [Valeurs que vous spécifiez dans la déclaration de politique d’une politique personnalisée pour les cookies signés](#private-content-custom-policy-statement-cookies-values).

**Topics**
+ [Exemple de déclaration de politique : accès à un fichier à partir d’une plage d’adresses IP](#private-content-custom-policy-statement-signed-cookies-example-one-object)
+ [Exemple de déclaration de politique : accès à tous les fichiers d’un répertoire à partir d’une plage d’adresses IP](#private-content-custom-policy-statement-signed-cookies-example-all-objects)
+ [Exemple de déclaration de politique : accès à tous les fichiers associés à un ID de paire de clés à partir d’une adresse IP](#private-content-custom-policy-statement-signed-cookies-example-one-ip)

### Exemple de déclaration de politique : accès à un fichier à partir d’une plage d’adresses IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-object"></a>

L’exemple suivant de politique personnalisée dans un cookie signé spécifie qu’un utilisateur peut accéder au fichier `https://d111111abcdef8.cloudfront.net/game_download.zip` à partir des adresses IP de la plage `192.0.2.0/24` jusqu’au 1er janvier 2023 10 h 00 UTC :

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Exemple de déclaration de politique : accès à tous les fichiers d’un répertoire à partir d’une plage d’adresses IP
<a name="private-content-custom-policy-statement-signed-cookies-example-all-objects"></a>

L’exemple suivant de politique personnalisée vous permet de créer des cookies signés pour n’importe quel fichier du répertoire `training`, comme indiqué par le caractère générique \$1 du paramètre `Resource`. Les utilisateurs peuvent accéder au fichier depuis une adresse IP de la plage `192.0.2.0/24` jusqu’au 1er janvier 2013 10 h 00 UTC :

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

Chaque cookie signé dans lequel vous utilisez cette politique inclut une URL de base qui identifie un fichier spécifique ; par exemple :

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Exemple de déclaration de politique : accès à tous les fichiers associés à un ID de paire de clés à partir d’une adresse IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-ip"></a>

L’exemple suivant de politique personnalisée vous permet de définir des cookies signés pour tout fichier associé à une distribution, comme indiqué par le caractère générique \$1 du paramètre `Resource`. L’utilisateur doit employer l’adresse IP `192.0.2.10/32`. (La valeur `192.0.2.10/32` en notation CIDR fait référence à une seule adresse IP, `192.0.2.10`.) Les fichiers ne sont disponibles qu’entre le 1er janvier 2013 10 h 00 UTC et le 2 janvier 2013 10 h 00 UTC :

```
{
    "Statement": [
        {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1767290400
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767376800
                }
            }
        }
    ]
}
```

Chaque cookie signé dans lequel vous utilisez cette politique inclut une URL de base qui identifie un fichier spécifique dans une CloudFront distribution spécifique, par exemple :

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

Le cookie signé inclut aussi un ID de paire de clés, qui doit être associé à un groupe de clés approuvé de la distribution (d111111abcdef8.cloudfront.net) que vous spécifiez dans l’URL de base.

## Création d’une signature pour un cookie signé qui utilise une politique personnalisée
<a name="private-content-custom-policy-signature-cookies"></a>

La signature d’un cookie signé utilisant une politique personnalisée est une version hachée, signée et encodée en base64 de la déclaration de politique. 

Pour plus d’informations et d’exemples sur la façon de hacher, signer et encoder la déclaration de politique, consultez :
+ [Utilisation d’une commande Linux et OpenSSL pour le chiffrement et l’encodage en base64](private-content-linux-openssl.md)
+ [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md)

**Note**  
Les exemples liés utilisent SHA-1 par défaut. Pour utiliser SHA-256 à la place, remplacez `sha1` par `sha256` dans les commandes OpenSSL et incluez le cookie avec une valeur de`CloudFront-Hash-Algorithm`. `SHA256`<a name="private-content-custom-policy-signature-cookies-procedure"></a>

**Pour créer une signature pour un cookie signé en utilisant une politique personnalisée**

1. Utilisez la fonction de hachage SHA-1 ou SHA-256 et RSA pour hacher et signer la déclaration de politique JSON que vous avez créée dans la procédure. [Pour créer la déclaration de politique d’une URL signée qui utilise une politique personnalisée](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-creating-policy-procedure) Utilisez la version de la déclaration de politique qui n’inclut plus d’espaces vides, mais qui n’a pas encore été encodée en base64.

   Si vous utilisez SHA-256, vous devez inclure le `CloudFront-Hash-Algorithm` cookie avec une valeur de. `SHA256`

   Pour la clé privée requise par la fonction de hachage, utilisez une clé privée dont la clé publique se trouve dans un groupe de clés approuvé actif pour la distribution.
**Note**  
La méthode que vous utilisez pour hacher et signer la déclaration de politique dépend du langage de programmation et de la plateforme. Pour un exemple de code, consultez [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md).

1. Supprimez les espaces vides (tabulations et sauts de ligne inclus) de la chaîne hachée et signée.

1. Encodez en base64 la chaîne à l’aide de l’encodage MIME base64. Pour plus d'informations, consultez [la Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) dans la *RFC 2045, MIME (extensions de messagerie Internet polyvalentes), première partie : Format des* corps de messages Internet.

1. Remplacez les caractères non valides d’une chaîne de requête d’URL par les caractères valides. Le tableau suivant répertorie les caractères valides et non valides.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Incluez la valeur obtenue dans l’en-tête `Set-Cookie` de la paire nom-valeur `CloudFront-Signature=`, et retournez à [Pour définir un cookie signé utilisant une politique personnalisée](#private-content-setting-signed-cookie-custom-policy-procedure) pour ajouter l’en-tête `Set-Cookie` de `CloudFront-Key-Pair-Id`.

# Création de cookies signés avec PHP
<a name="signed-cookies-PHP"></a>

L’exemple de code suivant est similaire à celui indiqué dans [Créer une signature d’URL avec PHP](CreateURL_PHP.md), puisqu’il génère un lien vers une vidéo. Cependant, au lieu de signer l’URL dans le code, cet exemple signe les cookies avec la fonction `create_signed_cookies()`. Le joueur côté client utilise les cookies pour authentifier chaque demande auprès de la distribution. CloudFront

Cette approche est utile pour diffuser du contenu en continu, comme le HTTP Live Streaming (HLS) ou le Dynamic Adaptive Streaming over HTTP (DASH), où le client doit envoyer plusieurs demandes pour récupérer le manifeste, les segments et les ressources associées à la lecture. En utilisant des cookies signés, le client peut authentifier chaque demande sans avoir à générer une nouvelle URL signée pour chaque segment. 

**Note**  
La création d’une signature d’URL n’est qu’une partie du processus d’offre d’un contenu privé avec des cookies signés. Pour de plus amples informations, veuillez consulter [Utilisation de cookies signés](private-content-signed-cookies.md).



**Topics**
+ [Création de la signature RSA SHA-1 ou SHA-256](#create-rsa-sha-1signature-cookies)
+ [Création des cookies signés](#create-the-signed-cookie)
+ [Code complet](#full-code-signed-cookies)

Les sections suivantes décomposent l’exemple de code en plusieurs parties. Vous trouverez l’[exemple de code](#full-code-signed-cookies) complet ci-dessous.

## Création de la signature RSA SHA-1 ou SHA-256
<a name="create-rsa-sha-1signature-cookies"></a>

Cet exemple de code effectue les opérations suivantes :

1. La fonction `rsa_sha1_sign` hache et signe la déclaration de politique à l'aide de SHA-1. Pour utiliser SHA-256 à la place, utilisez la fonction rsa\$1sha256\$1sign illustrée ci-dessous. Les arguments requis sont une déclaration de politique et la clé privée qui correspond à une clé publique qui se trouve dans un groupe de clés approuvé pour votre distribution.

1. Ensuite, la fonction `url_safe_base64_encode` crée une version à URL sécurisée de la signature.

   ```
   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);
   }
   ```

   La fonction suivante utilise SHA-256 au lieu de SHA-1 :

   ```
   function rsa_sha256_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_ALGO_SHA256);
       openssl_free_key($pkeyid);
       return $signature;
   }
   ```

   La `rsa_sha256_sign` fonction est la même que`rsa_sha1_sign`, sauf qu'elle passe `OPENSSL_ALGO_SHA256` à`openssl_sign`. Lorsque vous utilisez SHA-256, incluez le `CloudFront-Hash-Algorithm` cookie avec une valeur de. `SHA256`

## Création des cookies signés
<a name="create-the-signed-cookie"></a>

Le code suivant construit et crée les cookies signés, en utilisant les attributs de cookie suivants : `CloudFront-Expires``CloudFront-Signature`, `CloudFront-Key-Pair-Id` et`CloudFront-Hash-Algorithm`. Le code utilise une politique personnalisée.

```
function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null, $hash_algorithm = 'SHA1') {
    $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);
    if ($hash_algorithm === 'SHA256') {
        $signature = rsa_sha256_sign($policy, $private_key_filename);
    } else {
        $signature = rsa_sha1_sign($policy, $private_key_filename);
    }
    $encoded_signature = url_safe_base64_encode($signature);

    $cookies = array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );

    if ($hash_algorithm === 'SHA256') {
        $cookies['CloudFront-Hash-Algorithm'] = 'SHA256';
    }

    return $cookies;
}
```

Pour de plus amples informations, veuillez consulter [Définition de cookies signés utilisant une politique personnalisée](private-content-setting-signed-cookie-custom-policy.md).

## Code complet
<a name="full-code-signed-cookies"></a>

L'exemple de code suivant fournit une démonstration complète de la création de cookies CloudFront signés avec PHP. Vous pouvez télécharger l’exemple complet depuis le fichier [demo-php.zip](samples/demo-php.zip).

Dans l'exemple suivant, vous pouvez modifier l'`$policy Condition`élément pour autoriser à la fois les plages d' IPv6 adresses IPv4 et les plages d'adresses. Par exemple, consultez la section [Utilisation IPv6 des adresses dans les politiques IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) du *guide de l'utilisateur d'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 rsa_sha256_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_ALGO_SHA256);
    openssl_free_key($pkeyid);
    return $signature;
}

function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null, $hash_algorithm = 'SHA1') {
    $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);
    if ($hash_algorithm === 'SHA256') {
        $signature = rsa_sha256_sign($policy, $private_key_filename);
    } else {
        $signature = rsa_sha1_sign($policy, $private_key_filename);
    }
    $encoded_signature = url_safe_base64_encode($signature);

    $cookies = array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );

    if ($hash_algorithm === 'SHA256') {
        $cookies['CloudFront-Hash-Algorithm'] = 'SHA256';
    }

    return $cookies;
}



$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, 'SHA256');

// 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>
```

Au lieu d'utiliser des cookies signés, vous pouvez utiliser des cookies signés URLs. Pour de plus amples informations, veuillez consulter [Créer une signature d’URL avec PHP](CreateURL_PHP.md).

# Utilisation d’une commande Linux et OpenSSL pour le chiffrement et l’encodage en base64
<a name="private-content-linux-openssl"></a>

Vous pouvez utiliser la commande de ligne de commande Linux suivante et OpenSSL pour hacher et signer la déclaration de politique, encoder la signature en base64 et remplacer les caractères non valides des paramètres de la chaîne de requête de l’URL par des caractères valides.

Pour plus d’informations sur OpenSSL, rendez-vous sur [https://www.openssl.org](https://www.openssl.org).

SHA-1 (par défaut) :

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha1 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

SHA-256 :

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha256 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

Dans la commande précédente :
+ `cat` lit le fichier `policy`.
+ `tr -d "\n" | tr -d " \t\n\r"` supprime les espaces vides et le caractère de saut de ligne qui ont été ajoutés par `cat`.
+ OpenSSL hache le fichier à l'aide de SHA-1 (ou SHA-256) et le signe à l'aide du fichier de clé privée. `private_key.pem` La signature de clé privée peut être RSA 2048 ou ECDSA 256. Si vous utilisez SHA-256, incluez le paramètre de `Hash-Algorithm=SHA256` requête dans l'URL signée ou le `CloudFront-Hash-Algorithm=SHA256` cookie pour les cookies signés.
+ OpenSSL encode en base64 la déclaration de politique hachée et signée.
+ `tr`remplace les caractères non valides dans les paramètres de chaîne de requête d'URL par des caractères valides.

Pour d’autres exemples de code illustrant la création d’une signature, consultez [Exemples de code pour la création de la signature d’une URL signée](PrivateCFSignatureCodeAndExamples.md).

# Exemples de code pour la création de la signature d’une URL signée
<a name="PrivateCFSignatureCodeAndExamples"></a>

Cette section inclut des exemples d'applications téléchargeables qui montrent comment créer des signatures pour Signed URLs. Les exemples sont disponibles en Perl, PHP, C\$1 et Java. Vous pouvez utiliser n'importe lequel des exemples pour créer des signatures URLs. Le script Perl s’exécute sur les plateformes Linux et MacOS. L’exemple PHP fonctionne sur n’importe quel serveur qui exécute PHP. L’exemple C\$1 utilise le .NET Framework.

Les exemples de cette section utilisent SHA-1 pour hacher et signer la déclaration de politique. Vous pouvez également utiliser SHA-256. Pour utiliser SHA-256, mettez à jour l'algorithme de hachage dans la fonction de signature (par exemple, remplacez-le par `sha1` dans les appels `sha256` OpenSSL ou utilisez la constante SHA-256 équivalente dans la bibliothèque cryptographique de votre langue). Lorsque vous utilisez SHA-256, incluez le paramètre de `Hash-Algorithm=SHA256` requête dans l'URL signée.

Pour un exemple de code dans JavaScript (Node.js), consultez [Creating Amazon CloudFront URLs Signed in Node.js](https://aws.amazon.com/blogs/developer/creating-amazon-cloudfront-signed-urls-in-node-js/) sur le blog des AWS développeurs.

Pour un exemple de code en Python, consultez [Generate a signed URL for Amazon CloudFront](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#examples) dans le *AWS SDK for Python (Boto3) API [Reference et cet exemple de code dans le référentiel](https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst) Boto3*. GitHub 

**Topics**
+ [Créer une signature d’URL avec Perl](CreateURLPerl.md)
+ [Créer une signature d’URL avec PHP](CreateURL_PHP.md)
+ [Créer une signature d’URL avec C\$1 et .NET Framework](CreateSignatureInCSharp.md)
+ [Créer une signature d’URL avec Java](CFPrivateDistJavaDevelopment.md)

# Créer une signature d’URL avec Perl
<a name="CreateURLPerl"></a>

Cette section inclut un script Perl pour les Linux/Mac plateformes que vous pouvez utiliser pour créer la signature du contenu privé. Pour créer la signature, exécutez le script avec des arguments de ligne de commande qui spécifient l' CloudFront URL, le chemin d'accès à la clé privée du signataire, l'ID de la clé et la date d'expiration de l'URL. L'outil peut également décoder les signaturesURLs. 

**Remarques**  
La création d’une signature d’URL n’est qu’une partie du processus d’offre d’un contenu privé avec une URL signée. Pour plus d'informations sur le end-to-end processus, consultez[Utiliser signé URLs](private-content-signed-urls.md). 
Dans la commande de signature, notez que cela `sha1` peut être remplacé par `sha256` dans l'`openssl dgst`appel.

**Topics**
+ [Source du script Perl pour la création d’une URL signée](#CreateURLPerlScriptSource)

## Source du script Perl pour la création d’une URL signée
<a name="CreateURLPerlScriptSource"></a>

Le code source Perl suivant peut être utilisé pour créer une URL signée pour CloudFront. Les commentaires du code incluent les informations sur les fonctions et les commutateurs de ligne de commande de l’outil.

```
#!/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;
```

# Créer une signature d’URL avec PHP
<a name="CreateURL_PHP"></a>

Tout serveur Web qui exécute PHP peut utiliser cet exemple de code PHP pour créer des déclarations de politique et des signatures pour CloudFront des distributions privées. L'exemple complet crée une page Web fonctionnelle avec des liens URL signés qui diffusent un flux vidéo CloudFront en streaming. Vous pouvez télécharger l’exemple complet depuis le fichier [demo-php.zip](samples/demo-php.zip).

**Remarques**  
La création d’une signature d’URL n’est qu’une partie du processus d’offre d’un contenu privé avec une URL signée. Pour plus d’informations sur la totalité du processus, consultez [Utiliser signé URLs](private-content-signed-urls.md). 
Vous pouvez également créer une signature URLs en utilisant la `UrlSigner` classe dans le AWS SDK pour PHP. Pour plus d'informations, consultez la section [Classe UrlSigner](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CloudFront.UrlSigner.html) dans la *référence de AWS SDK pour PHP l'API*.
Lors de l'`openssl_sign`appel, notez que le passage `OPENSSL_ALGO_SHA256` en tant que quatrième argument passe à SHA-256. (Voir également le [Création de cookies signés avec PHP](signed-cookies-PHP.md) pour un exemple complet.)

**Topics**
+ [Création de la signature RSA SHA-1](#sample-rsa-sign)
+ [Création d’une politique prédéfinie](#sample-canned-policy)
+ [Créer une stratégie personnalisée](#sample-custom-policy)
+ [Exemple de code complet](#full-example)

Les sections suivantes décomposent l’exemple de code en plusieurs parties. Vous trouverez le [Exemple de code complet](#full-example) ci-dessous.

## Création de la signature RSA SHA-1
<a name="sample-rsa-sign"></a>

Cet exemple de code effectue les opérations suivantes :
+ La fonction `rsa_sha1_sign` hache et signe la déclaration de politique. Les arguments requis sont une déclaration de politique et la clé privée qui correspond à une clé publique qui se trouve dans un groupe de clés approuvé pour votre distribution. 
+ Ensuite, la fonction `url_safe_base64_encode` crée une version à URL sécurisée de la signature.

```
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);
}
```

L'extrait de code suivant utilise les fonctions `get_canned_policy_stream_name()` et permet de `get_custom_policy_stream_name()` créer une politique prédéfinie et personnalisée. CloudFront utilise les politiques pour créer l'URL de diffusion de la vidéo, notamment en spécifiant le délai d'expiration. 

Vous pouvez ensuite utiliser une politique prédéfinie ou personnalisée pour définir la gestion de l’accès à votre contenu. Pour savoir quelle option privilégier, consultez la section [Décidez d'utiliser des politiques prédéfinies ou personnalisées pour les documents signés URLs](private-content-signed-urls.md#private-content-choosing-canned-custom-policy).

## Création d’une politique prédéfinie
<a name="sample-canned-policy"></a>

L’exemple de code suivant construit une déclaration de politique *prédéfinie* pour la signature. 

**Note**  
La `$expires` variable est un date/time tampon qui doit être un entier et non une chaîne.

```
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;
}
```

Pour plus d’informations sur les politiques prédéfinies, consultez [Création d’une URL signée à l’aide d’une politique prédéfinie](private-content-creating-signed-url-canned-policy.md).

## Créer une stratégie personnalisée
<a name="sample-custom-policy"></a>

L’exemple de code suivant construit une déclaration de politique *personnalisée* pour la signature. 

```
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;
}
```

Pour plus d’informations sur les politiques personnalisées, consultez [Création d’une URL signée utilisant une politique personnalisée](private-content-creating-signed-url-custom-policy.md).

## Exemple de code complet
<a name="full-example"></a>

L'exemple de code suivant fournit une démonstration complète de la création de CloudFront signatures URLs avec PHP. Vous pouvez télécharger l’exemple complet depuis le fichier [demo-php.zip](samples/demo-php.zip).

Dans l'exemple suivant, vous pouvez modifier l'`$policy``Condition`élément pour autoriser à la fois les plages d' IPv6 adresses IPv4 et les plages d'adresses. Par exemple, consultez la section [Utilisation IPv6 des adresses dans les politiques IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) du *guide de l'utilisateur d'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>
```

Pour obtenir plus exemples sur la signature d’URL, consultez les rubriques suivantes :
+ [Créer une signature d’URL avec Perl](CreateURLPerl.md)
+ [Créer une signature d’URL avec C\$1 et .NET Framework](CreateSignatureInCSharp.md)
+ [Créer une signature d’URL avec Java](CFPrivateDistJavaDevelopment.md)

Au lieu d'utiliser des cookies signés URLs pour créer la signature, vous pouvez utiliser des cookies signés. Pour de plus amples informations, veuillez consulter [Création de cookies signés avec PHP](signed-cookies-PHP.md).

# Créer une signature d’URL avec C\$1 et .NET Framework
<a name="CreateSignatureInCSharp"></a>

Les exemples C\$1 présentés dans cette section mettent en œuvre un exemple d'application qui montre comment créer des signatures pour des distributions CloudFront privées à l'aide de déclarations de politique prédéfinies et personnalisées. Les exemples incluent des fonctions utilitaires basées sur le [AWS SDK pour .NET](https://aws.amazon.com/sdkfornet) pour .NET et qui peuvent être utiles dans les applications .NET.

Vous pouvez également créer des cookies signés URLs et signés en utilisant le SDK pour .NET. Dans la *Référence des API du kit SDK pour .NET *, consultez les rubriques suivantes :
+ **Signé URLs** — [AmazonCloudFrontUrlSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontUrlSigner.html) 
+ **Cookies signés** — [AmazonCloudFrontCookieSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontCookieSigner.html) 

Pour télécharger le code, consultez [Code de signature en C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip).

**Remarques**  
Les classes `AmazonCloudFrontUrlSigner` et `AmazonCloudFrontCookieSigner` ont été déplacées vers un package distinct. Pour plus d'informations sur leur utilisation, consultez [CookieSigner et](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html#net-dg-v4-CookieSigner-UrlSigner) consultez UrlSigner le *Guide du développeur AWS SDK pour .NET (V4)*. 
La création d’une signature d’URL n’est qu’une partie du processus d’offre d’un contenu privé avec une URL signée. Pour de plus amples informations, veuillez consulter [Utiliser signé URLs](private-content-signed-urls.md). Pour plus d’informations sur l’utilisation des cookies signés, consultez [Utilisation de cookies signés](private-content-signed-cookies.md).
Dans l'appel de signature RSA, notez que cela `SHA1` peut être remplacé par le paramètre de `SHA256` l'algorithme de hachage.

## Utilisation d’une clé RSA dans .NET Framework
<a name="rsa-key-sdk-net"></a>

Pour utiliser une clé RSA dans le .NET Framework, vous devez convertir le fichier .pem AWS fourni au format XML utilisé par le .NET Framework.

Après la conversion, le fichier de clé privée RSA est au format suivant :

**Example : clé privée RSA au format XML .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éthode de signature de politique prédéfinie en C\$1
<a name="canned-policy-signed-url-net"></a>

Le code C\$1 suivant crée une URL signée qui utilise une politique prédéfinie en effectuant les opérations suivantes :
+ Crée une déclaration de politique.
+ Hache la déclaration de politique en utilisant SHA1 et signe le résultat à l'aide de RSA et de la clé privée dont la clé publique correspondante se trouve dans un groupe de clés fiables.
+ Encode en base64 la déclaration de politique hachée et signée, et remplace les caractères spéciaux pour assurer la sécurité de la chaîne utilisée comme paramètre de demande d’URL.
+ Concatène les valeurs.

Pour l’implémentation complète, consultez l’exemple de la rubrique [Code de signature en C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**Note**  
Le `keyId` est renvoyé lorsque vous téléchargez une clé publique sur CloudFront. Pour plus d’informations, consultez ![\[6\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : méthode de signature de politique prédéfinie en 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éthode de signature de politique personnalisée en C\$1
<a name="custom-policy-signed-url-net"></a>

Le code C\$1 suivant crée une URL signée qui utilise une politique personnalisée en effectuant les opérations suivantes :

1. Crée une déclaration de politique.

1. Encode en base64 la déclaration de politique et remplace les caractères spéciaux pour assurer la sécurité de la chaîne utilisée comme paramètre de demande d’URL.

1. Hache la déclaration de politique en utilisant SHA1 et chiffre le résultat à l'aide de RSA et de la clé privée dont la clé publique correspondante se trouve dans un groupe de clés fiables.

1. Encode en base64 la déclaration de politique hachée et remplace les caractères spéciaux pour assurer la sécurité de la chaîne utilisée comme paramètre de demande d’URL.

1. Concatène les valeurs.

Pour l’implémentation complète, consultez l’exemple de la rubrique [Code de signature en C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**Note**  
Le `keyId` est renvoyé lorsque vous téléchargez une clé publique sur CloudFront. Pour plus d’informations, consultez ![\[6\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : méthode de signature de politique personnalisée en 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éthodes d’utilité pour la génération de signatures
<a name="utility-methods-signed-url"></a>

Les méthodes suivantes obtiennent la déclaration de politique d’un fichier et analyse les intervalles de temps pour la génération des signatures.

**Example : méthodes d’utilité pour la génération de signatures**  <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();   
}
```

Voir aussi
+ [Créer une signature d’URL avec Perl](CreateURLPerl.md)
+ [Créer une signature d’URL avec PHP](CreateURL_PHP.md)
+ [Créer une signature d’URL avec Java](CFPrivateDistJavaDevelopment.md)

# Créer une signature d’URL avec Java
<a name="CFPrivateDistJavaDevelopment"></a>

Outre l'exemple de code suivant, vous pouvez utiliser [la classe `CloudFrontUrlSigner` utilitaire de AWS SDK pour Java (version 1)](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/cloudfront/CloudFrontUrlSigner.html) pour créer des [CloudFront signatures URLs](private-content-signed-urls.md).

Pour plus d'exemples, consultez la section [Création de cookies URLs et de signatures à l'aide d'un AWS SDK](https://docs.aws.amazon.com/code-library/latest/ug/cloudfront_example_cloudfront_CloudFrontUtilities_section.html) dans la bibliothèque de codes d'*exemples de code AWS SDK*. 

**Remarques**  
La création d'une URL signée n'est qu'une partie du processus de [diffusion de contenu privé avec CloudFront](PrivateContent.md). Pour plus d’informations sur la totalité du processus, consultez [Utiliser signé URLs](private-content-signed-urls.md).
Dans l'`Signature.getInstance`appel, notez que cela `SHA1withRSA` peut être remplacé par`SHA256withRSA`.

**Example Méthodes de chiffrement de politiques et de signatures Java**  <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);

    }
}
```

**Example Exemple de signature de politiques prédéfinies avec SHA256 Java**  <a name="ExampleJavaPolicySHA256AndSignatureEncryptionMethods"></a>

```
package org.example;

import java.io.File;
import java.nio.file.Files;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.Base64;

public class Main {

    public static void main(String[] args) throws Exception {
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net/myfile.html";
        String keyPairId = "K1UA3WV15I7JSD";
        Instant expiration = Instant.now().plus(7, ChronoUnit.DAYS);
        PrivateKey privateKey = loadPrivateKey("/path/to/private_key.der");

        System.out.println(createSignedUrl(resourceUrl, keyPairId, privateKey, expiration, "SHA1"));
        System.out.println(createSignedUrl(resourceUrl, keyPairId, privateKey, expiration, "SHA256"));
    }

    static String createSignedUrl(String resourceUrl, String keyPairId,
                                  PrivateKey privateKey, Instant expiration,
                                  String hashAlgorithm) throws Exception {
        long epochSeconds = expiration.getEpochSecond();

        String policy = "{\"Statement\":[{\"Resource\":\"" + resourceUrl
                + "\",\"Condition\":{\"DateLessThan\":{\"AWS:EpochTime\":" + epochSeconds + "}}}]}";

        String jcaAlgorithm = hashAlgorithm.equals("SHA256") ? "SHA256withRSA" : "SHA1withRSA";

        Signature sig = Signature.getInstance(jcaAlgorithm);
        sig.initSign(privateKey);
        sig.update(policy.getBytes("UTF-8"));
        String signature = base64UrlEncode(sig.sign());

        String url = resourceUrl
                + (resourceUrl.contains("?") ? "&" : "?")
                + "Expires=" + epochSeconds
                + "&Signature=" + signature
                + "&Key-Pair-Id=" + keyPairId;

        if (hashAlgorithm.equals("SHA256")) {
            url += "&Hash-Algorithm=SHA256";
        }

        return url;
    }

    static String base64UrlEncode(byte[] bytes) {
        return Base64.getEncoder().encodeToString(bytes)
                .replace('+', '-')
                .replace('=', '_')
                .replace('/', '~');
    }

    static PrivateKey loadPrivateKey(String path) throws Exception {
        byte[] keyBytes = Files.readAllBytes(new File(path).toPath());
        return KeyFactory.getInstance("RSA")
                .generatePrivate(new PKCS8EncodedKeySpec(keyBytes));
    }
}
```

Voir aussi :
+ [Créer une signature d’URL avec Perl](CreateURLPerl.md)
+ [Créer une signature d’URL avec PHP](CreateURL_PHP.md)
+ [Créer une signature d’URL avec C\$1 et .NET Framework](CreateSignatureInCSharp.md)

# Restreindre l'accès à une AWS origine
<a name="private-content-restricting-access-to-origin"></a>

Vous pouvez configurer CloudFront certaines AWS origines d'une manière qui offre les avantages suivants :
+ Restreint l'accès à l' AWS origine afin qu'elle ne soit pas accessible au public.
+ Veille à ce que les spectateurs (utilisateurs) puissent accéder au contenu de l' AWS origine uniquement via la CloudFront distribution spécifiée. Cela empêche les spectateurs d'accéder au contenu directement depuis l'origine ou par le biais d'une CloudFront distribution involontaire.

Pour ce faire, configurez CloudFront pour envoyer des demandes authentifiées à votre AWS origine, et configurez l' AWS origine pour autoriser uniquement l'accès aux demandes authentifiées provenant de. CloudFront Pour plus d'informations, consultez les rubriques suivantes pour connaître les types d' AWS origines compatibles.

**Topics**
+ [Restreindre l'accès à une origine AWS Elemental MediaPackage v2](private-content-restricting-access-to-mediapackage.md)
+ [Restreindre l'accès à une AWS Elemental MediaStore origine](private-content-restricting-access-to-mediastore.md)
+ [Restreindre l'accès à l'origine de l'URL d'une AWS Lambda fonction](private-content-restricting-access-to-lambda.md)
+ [Restriction de l’accès à une origine Amazon S3](private-content-restricting-access-to-s3.md)
+ [Restriction de l’accès avec les origines de VPC](private-content-vpc-origins.md)
+ [Restreindre l'accès à l'origine d'un point d'accès multirégional Amazon S3](private-content-restricting-access-to-s3-mrap.md)

# Restreindre l'accès à une origine AWS Elemental MediaPackage v2
<a name="private-content-restricting-access-to-mediapackage"></a>

CloudFront fournit un *contrôle d'accès à l'origine* (OAC) pour restreindre l'accès à une origine MediaPackage v2.

**Note**  
CloudFront OAC ne prend en charge que la MediaPackage v2. MediaPackage la v1 n'est pas prise en charge.

**Topics**
+ [Création d’un nouvel OAC](#create-oac-overview-mediapackage)
+ [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-mediapackage)

## Création d’un nouvel OAC
<a name="create-oac-overview-mediapackage"></a>

Suivez les étapes décrites dans les rubriques suivantes pour configurer un nouvel OAC dans CloudFront.

**Topics**
+ [Conditions préalables](#oac-prerequisites-mediapackage)
+ [Accorder CloudFront l'autorisation d'accéder à l'origine de la MediaPackage version 2](#oac-permission-to-access-mediapackage)
+ [Création de l’OAC](#create-oac-mediapackage)

### Conditions préalables
<a name="oac-prerequisites-mediapackage"></a>

Avant de créer et de configurer OAC, vous devez disposer d'une CloudFront distribution d'origine MediaPackage v2. Pour de plus amples informations, veuillez consulter [Utiliser un MediaStore conteneur ou un MediaPackage canal](DownloadDistS3AndCustomOrigins.md#concept_AWS_Media).

### Accorder CloudFront l'autorisation d'accéder à l'origine de la MediaPackage version 2
<a name="oac-permission-to-access-mediapackage"></a>

Avant de créer un OAC ou de le configurer dans une CloudFront distribution, assurez-vous qu'il CloudFront est autorisé à accéder à l'origine MediaPackage v2. Procédez ainsi après avoir créé une CloudFront distribution, mais avant d'ajouter l'OAC à l'origine MediaPackage v2 dans la configuration de distribution.

Utilisez une politique IAM pour autoriser le principal de CloudFront service (`cloudfront.amazonaws.com`) à accéder à l'origine. L'`Condition`élément de la politique permet d'accéder CloudFront à l'origine MediaPackage v2 *uniquement* lorsque la demande est au nom de la CloudFront distribution qui contient l'origine MediaPackage v2. Il s'agit de la distribution avec l'origine MediaPackage v2 à laquelle vous souhaitez ajouter OAC.

**Example : politique IAM qui autorise l'accès en lecture seule pour une CloudFront distribution avec OAC activé**  
La politique suivante autorise la CloudFront distribution (`E1PDK09ESKHJWT`) à accéder à l'origine MediaPackage v2. L’origine est l’ARN spécifié pour l’élément `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"}
            }
        }
    ]
}
```

**Remarques**  
Si vous avez activé la fonctionnalité MQAR et le contrôle d’accès d’origine (OAC), ajoutez l’action `mediapackagev2:GetHeadObject` à la politique IAM. MQAR a besoin de cette autorisation pour envoyer `HEAD` des demandes à l'origine MediaPackage v2. Pour plus d’informations sur MQAR, consultez [Résilience tenant compte de la qualité média](media-quality-score.md).
Si vous créez une distribution qui n'est pas autorisée à accéder à votre origine MediaPackage v2, vous pouvez choisir **Copier la politique** depuis la CloudFront console, puis choisir **Mettre à jour les autorisations du point de terminaison**. Vous pouvez ensuite associer l’autorisation copiée au point de terminaison. Pour plus d’informations, consultez [Champs de la politique de points de terminaison](https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-policy.html) dans le *Guide de l’utilisateur AWS Elemental MediaPackage *. 

### Création de l’OAC
<a name="create-oac-mediapackage"></a>

Pour créer un OAC, vous pouvez utiliser le AWS Management Console CloudFormation, AWS CLI, ou l' CloudFront API.

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

**Pour créer un OAC**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le panneau de navigation de gauche, choisissez **Accès à l'origine**.

1. Choisissez **Créer un paramètre de contrôle**.

1. Sur la page **Créer un nouvel OAC**, procédez comme suit :

   1. Entrez un **Nom** et éventuellement une **Description** pour l’OAC.

   1. Dans **Comportement de signature**, nous vous recommandons de conserver le paramètre par défaut **Demandes de signature (recommandé)**. Pour de plus amples informations, veuillez consulter [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-mediapackage).

1. Pour le **type d'origine**, choisissez **MediaPackage V2**. 

1. Choisissez **Créer**.
**Astuce**  
Après avoir créé l’OAC, prenez note du **Nom**. Vous en aurez besoin au cours de la procédure suivante.

**Pour ajouter un OAC à une origine MediaPackage v2 dans une distribution**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez une distribution d'origine MediaPackage V2 à laquelle vous souhaitez ajouter l'OAC, puis choisissez l'onglet **Origins**.

1. Sélectionnez l'origine MediaPackage v2 à laquelle vous souhaitez ajouter l'OAC, puis choisissez **Modifier**.

1. Sélectionnez **HTTPS only** (HTTPS uniquement) pour le paramètre **Protocol** (Protocole) de votre origine.

1. Dans le menu déroulant **Contrôle d’accès d’origine**, choisissez le nom de l’OAC que vous souhaitez utiliser.

1. Sélectionnez **Enregistrer les modifications**.

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l'origine MediaPackage v2.

------
#### [ CloudFormation ]

Pour créer un OAC avec CloudFormation, utilisez le type de `AWS::CloudFront::OriginAccessControl` ressource. L'exemple suivant montre la syntaxe du CloudFormation modèle, au format YAML, pour créer un OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediapackagev2
      SigningBehavior: always
      SigningProtocol: sigv4
```

Pour plus d'informations, consultez la section [AWS::CloudFront::OriginAccessContrôle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) dans le *guide de AWS CloudFormation l'utilisateur*.

------
#### [ CLI ]

Pour créer un contrôle d'accès à l'origine avec le AWS Command Line Interface (AWS CLI), utilisez la **aws cloudfront create-origin-access-control** commande. Vous pouvez utiliser un fichier d’entrée pour fournir les paramètres d’entrée de la commande, plutôt que de spécifier chaque paramètre individuel comme entrée de ligne de commande.

**Pour créer un contrôle d'accès à l'origine (CLI avec un fichier d'entrée)**

1. Utilisez la commande suivante pour créer un fichier nommé `origin-access-control.yaml`. Ce fichier contient tous les paramètres d’entrée de la commande **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Ouvrez le fichier `origin-access-control.yaml` que vous venez de créer. Modifiez le fichier pour ajouter un nom à l'OAC, une description (facultative) et remplacez `SigningBehavior` par `always`. Ensuite, enregistrez le fichier.

   Pour plus d'informations sur paramètres OAC, consultez [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-mediapackage).

1. Utilisez la commande suivante pour créer le contrôle d'accès à l'origine à l'aide des paramètres d'entrée du fichier `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Notez la valeur de `Id` dans la sortie de la commande. Vous en avez besoin pour ajouter l'OAC à une origine MediaPackage v2 dans une CloudFront distribution.

**Pour attacher un OAC à une origine MediaPackage v2 dans une distribution existante (CLI avec fichier d'entrée)**

1. Utilisez la commande suivante pour enregistrer la configuration de distribution pour la CloudFront distribution à laquelle vous souhaitez ajouter l'OAC. La distribution doit avoir une origine MediaPackage v2.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Ouvrez le fichier nommé `dist-config.yaml` que vous venez de créer. Modifiez le fichier en apportant les modifications suivantes :
   + Dans l'objet `Origins`, ajoutez l'ID de l'OAC au champ nommé `OriginAccessControlId`.
   + Supprimez la valeur du champ nommé `OriginAccessIdentity`, le cas échéant.
   + Renommez le champ `ETag` en `IfMatch`, mais ne modifiez pas la valeur du champ.

   Enregistrez le fichier lorsque vous avez terminé.

1. Utilisez la commande suivante pour mettre à jour la distribution afin d’utiliser le contrôle d’accès à l’origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l'origine MediaPackage v2.

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

Pour créer un OAC avec l' CloudFront API, utilisez [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Pour plus d'informations sur les champs que vous spécifiez dans cet appel d'API, consultez la documentation de référence de l'API pour votre AWS SDK ou un autre client d'API.

Après avoir créé un OAC, vous pouvez l'associer à une origine MediaPackage v2 dans une distribution, à l'aide de l'un des appels d'API suivants :
+ Pour le rattacher à une distribution existante, utilisez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Pour l'associer à une nouvelle distribution, utilisez [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Pour ces deux appels d’API, indiquez l’OAC dans le champ `OriginAccessControlId`, à l’intérieur d’une origine. Pour plus d'informations sur les autres champs que vous spécifiez dans ces appels d'API, consultez [Référence de tous les paramètres de distribution](distribution-web-values-specify.md) la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

------

## Paramètres avancés pour le contrôle d’accès à l’origine
<a name="oac-advanced-settings-mediapackage"></a>

La fonctionnalité CloudFront OAC inclut des paramètres avancés destinés uniquement à des cas d'utilisation spécifiques. Utilisez les paramètres recommandés, sauf si vous avez des besoins spécifiques en matière de paramètres avancés.

L'OAC contient un paramètre nommé **Comportement de signature** (dans la console) ou `SigningBehavior` (dans l'API, la CLI et CloudFormation). Ce paramètre fournit les options suivantes :

**Toujours signer les demandes d'origine (paramètre recommandé)**  
Nous vous recommandons d’utiliser ce paramètre, nommé **Signer les demandes (recommandé)** dans la console ou `always` dans l’API, la CLI et CloudFormation. Avec ce paramètre, il signe CloudFront toujours toutes les demandes qu'il envoie à l'origine de la MediaPackage v2.

**Ne jamais signer les demandes d’origine**  
Ce paramètre est nommé **Ne pas signer les demandes** dans la console ou `never` dans l’API, la CLI et CloudFormation. Utilisez ce paramètre pour désactiver l’OAC pour toutes les origines dans l’ensemble des distributions qui utilisent cet OAC. Cela permet d’économiser du temps et des efforts par rapport à la suppression d’un OAC de toutes les origines et distributions qui l’utilisent, une par une. Avec ce paramètre, CloudFront ne signe aucune demande envoyée à l'origine de la MediaPackage v2.  
Pour utiliser ce paramètre, l'origine MediaPackage v2 doit être accessible au public. Si vous utilisez ce paramètre avec une origine MediaPackage v2 qui n'est pas accessible au public, CloudFront vous ne pouvez pas accéder à l'origine. L'origine MediaPackage v2 renvoie les erreurs CloudFront et les CloudFront transmet aux spectateurs. Pour plus d'informations, consultez l'exemple de politique MediaPackage v2 pour [les politiques et les autorisations MediaPackage dans](https://docs.aws.amazon.com/mediapackage/latest/userguide/policies-permissions.html) le *guide de AWS Elemental MediaPackage l'utilisateur*.

**Ne remplacez pas l’en-tête `Authorization` de l’utilisateur (client)**  
Ce paramètre est nommé **Ne pas remplacer l'en-tête d'autorisation** dans la console ou `no-override` dans l'API, la CLI et CloudFormation. Utilisez ce paramètre lorsque vous CloudFront souhaitez signer des demandes d'origine uniquement lorsque la demande d'affichage correspondante ne contient pas d'`Authorization`en-tête. Avec ce paramètre, CloudFront transmet l'`Authorization`en-tête de la demande du visualiseur lorsqu'il y en a un, mais signe la demande d'origine (en ajoutant son propre `Authorization` en-tête) lorsque la demande du visualiseur n'inclut pas d'`Authorization`en-tête.  
Pour transmettre l'`Authorization`en-tête de la demande du lecteur, vous *devez* l'`Authorization`ajouter à une [politique de cache](controlling-the-cache-key.md) pour tous les comportements de cache qui utilisent des origines MediaPackage v2 associées à ce contrôle d'accès à l'origine.

# Restreindre l'accès à une AWS Elemental MediaStore origine
<a name="private-content-restricting-access-to-mediastore"></a>

CloudFront fournit un *contrôle d'accès à l'origine* (OAC) pour restreindre l'accès à une AWS Elemental MediaStore origine.

**Topics**
+ [Création d’un nouveau contrôle d’accès d’origine](#create-oac-overview-mediastore)
+ [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-mediastore)

## Création d’un nouveau contrôle d’accès d’origine
<a name="create-oac-overview-mediastore"></a>

Suivez les étapes décrites dans les rubriques suivantes pour configurer un nouveau contrôle d'accès à l'origine dans CloudFront.

**Topics**
+ [Conditions préalables](#oac-prerequisites-mediastore)
+ [Accorder CloudFront l'autorisation d'accéder à l' MediaStore origine](#oac-permission-to-access-mediastore)
+ [Création du contrôle d’accès d’origine](#create-oac-mediastore)

### Conditions préalables
<a name="oac-prerequisites-mediastore"></a>

Avant de créer et de configurer le contrôle d'accès à l'origine, vous devez disposer d'une CloudFront distribution avec une MediaStore origine. 

### Accorder CloudFront l'autorisation d'accéder à l' MediaStore origine
<a name="oac-permission-to-access-mediastore"></a>

Avant de créer un contrôle d'accès à l'origine ou de le configurer dans une CloudFront distribution, assurez-vous que celui-ci CloudFront est autorisé à accéder à l' MediaStore origine. Procédez ainsi après avoir créé une CloudFront distribution, mais avant d'ajouter l'OAC à l' MediaStoreorigine dans la configuration de distribution. 

Utilisez une politique de MediaStore conteneur pour autoriser le principal CloudFront de service (`cloudfront.amazonaws.com`) à accéder à l'origine. Utilisez un `Condition` élément de la politique pour autoriser l'accès CloudFront au MediaStore conteneur uniquement lorsque la demande est présentée au nom de la CloudFront distribution qui contient l' MediaStore origine. Il s'agit de la distribution avec l' MediaStore origine à laquelle vous souhaitez ajouter OAC.

Voici des exemples de politiques de MediaStore conteneur qui permettent à une CloudFront distribution d'accéder à une MediaStore origine.

**Example MediaStore politique de conteneur qui autorise l'accès en lecture seule pour une CloudFront distribution avec OAC activé**    
****  

```
{
        "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 MediaStore politique de conteneur qui autorise l'accès en lecture et en écriture pour une CloudFront distribution avec OAC activé**    
****  

```
{
        "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"
                    }
                }
            }
        ]
}
```

**Note**  
Pour autoriser l'accès en écriture, vous devez configurer les **méthodes HTTP autorisées** à inclure `PUT` dans les paramètres de comportement de votre CloudFront distribution.

### Création du contrôle d’accès d’origine
<a name="create-oac-mediastore"></a>

Pour créer un OAC, vous pouvez utiliser le AWS Management Console CloudFormation, AWS CLI, ou l' CloudFrontAPI.

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

**Pour créer un contrôle d’accès à l’origine**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le panneau de navigation de gauche, choisissez **Accès à l'origine**.

1. Choisissez **Créer un paramètre de contrôle**.

1. Sur l'écran **Créer un paramètre de contrôle**, procédez comme suit :

   1. Dans le volet **Détails**, entrez un **Nom** et (éventuellement) une **Description** pour le contrôle d'accès à l'origine.

   1. Dans le volet **Paramètres**, nous vous recommandons de conserver le paramètre par défaut (**Signer les demandes (recommandé)**). Pour de plus amples informations, veuillez consulter [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-mediastore).

1.  MediaStore Choisissez dans le menu déroulant **Type d'origine**.

1. Choisissez **Créer**.

   Après avoir créé l'OAC, prenez note de **Nom**. Vous en aurez besoin au cours de la procédure suivante.

**Pour ajouter un contrôle d'accès à l'origine à une MediaStore origine dans une distribution**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez une distribution avec une MediaStore origine à laquelle vous souhaitez ajouter l'OAC, puis cliquez sur l'onglet **Origines**.

1. Sélectionnez l' MediaStore origine à laquelle vous souhaitez ajouter l'OAC, puis choisissez **Modifier**.

1. Sélectionnez **HTTPS only** (HTTPS uniquement) pour le paramètre **Protocol** (Protocole) de votre origine.

1. Dans le menu déroulant **Origin access control** (Contrôle d'accès d'origine), choisissez l'OAC que vous souhaitez utiliser.

1. Sélectionnez **Enregistrer les modifications**.

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l'origine du MediaStore compartiment.

------
#### [ CloudFormation ]

Pour créer un contrôle d'accès à l'origine (OAC) avec CloudFormation, utilisez le type de `AWS::CloudFront::OriginAccessControl` ressource. L'exemple suivant montre la syntaxe du CloudFormation modèle, au format YAML, pour créer un contrôle d'accès à l'origine.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediastore
      SigningBehavior: always
      SigningProtocol: sigv4
```

Pour plus d'informations, consultez la section [AWS::CloudFront::OriginAccessContrôle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) dans le *guide de AWS CloudFormation l'utilisateur*.

------
#### [ CLI ]

Pour créer un contrôle d'accès à l'origine avec le AWS Command Line Interface (AWS CLI), utilisez la **aws cloudfront create-origin-access-control** commande. Vous pouvez utiliser un fichier d’entrée pour fournir les paramètres d’entrée de la commande, plutôt que de spécifier chaque paramètre individuel comme entrée de ligne de commande.

**Pour créer un contrôle d'accès à l'origine (CLI avec un fichier d'entrée)**

1. Utilisez la commande suivante pour créer un fichier nommé `origin-access-control.yaml`. Ce fichier contient tous les paramètres d’entrée de la commande **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Ouvrez le fichier `origin-access-control.yaml` que vous venez de créer. Modifiez le fichier pour ajouter un nom à l'OAC, une description (facultative) et remplacez `SigningBehavior` par `always`. Ensuite, enregistrez le fichier.

   Pour plus d'informations sur paramètres OAC, consultez [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-mediastore).

1. Utilisez la commande suivante pour créer le contrôle d'accès à l'origine à l'aide des paramètres d'entrée du fichier `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Notez la valeur de `Id` dans la sortie de la commande. Vous en avez besoin pour ajouter l'OAC à une MediaStore origine dans une CloudFront distribution.

**Pour attacher un OAC à une MediaStore origine dans une distribution existante (CLI avec fichier d'entrée)**

1. Utilisez la commande suivante pour enregistrer la configuration de distribution pour la CloudFront distribution à laquelle vous souhaitez ajouter l'OAC. La distribution doit avoir une MediaStore origine.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Ouvrez le fichier nommé `dist-config.yaml` que vous venez de créer. Modifiez le fichier en apportant les modifications suivantes :
   + Dans l'objet `Origins`, ajoutez l'ID de l'OAC au champ nommé `OriginAccessControlId`.
   + Supprimez la valeur du champ nommé `OriginAccessIdentity`, le cas échéant.
   + Renommez le champ `ETag` en `IfMatch`, mais ne modifiez pas la valeur du champ.

   Enregistrez le fichier lorsque vous avez terminé.

1. Utilisez la commande suivante pour mettre à jour la distribution afin d’utiliser le contrôle d’accès à l’origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l' MediaStore origine.

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

Pour créer un contrôle d'accès à l'origine avec l' CloudFront API, utilisez [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Pour plus d'informations sur les champs que vous spécifiez dans cet appel d'API, consultez la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

Après avoir créé un contrôle d'accès à l'origine, vous pouvez l'associer à une MediaStore origine dans une distribution à l'aide de l'un des appels d'API suivants :
+ Pour le rattacher à une distribution existante, utilisez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Pour l'associer à une nouvelle distribution, utilisez [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Pour ces deux appels d'API, indiquez l'ID de contrôle d'accès à l'origine dans le champ `OriginAccessControlId`, à l'intérieur d'une origine. Pour plus d'informations sur les autres champs que vous spécifiez dans ces appels d'API, consultez [Référence de tous les paramètres de distribution](distribution-web-values-specify.md) la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

------

## Paramètres avancés pour le contrôle d’accès à l’origine
<a name="oac-advanced-settings-mediastore"></a>

La fonctionnalité de contrôle CloudFront d'accès à l'origine inclut des paramètres avancés destinés uniquement à des cas d'utilisation spécifiques. Utilisez les paramètres recommandés, sauf si vous avez des besoins spécifiques en matière de paramètres avancés.

Le contrôle d'accès à Origin contient un paramètre nommé **Comportement de signature** (dans la console) ou `SigningBehavior` (dans l'API, la CLI et CloudFormation). Ce paramètre fournit les options suivantes :

**Toujours signer les demandes d'origine (paramètre recommandé)**  
Nous vous recommandons d’utiliser ce paramètre, nommé **Signer les demandes (recommandé)** dans la console ou `always` dans l’API, la CLI et CloudFormation. Avec ce paramètre, il signe CloudFront toujours toutes les demandes qu'il envoie à l' MediaStore origine.

**Ne jamais signer les demandes d’origine**  
Ce paramètre est nommé **Ne pas signer les demandes** dans la console ou `never` dans l'API, la CLI et CloudFormation. Utilisez ce paramètre pour désactiver le contrôle d'accès à l'origine pour toutes les origines dans toutes les distributions qui utilisent ce contrôle d'accès à l'origine. Cela permet d’économiser du temps et des efforts par rapport à la suppression d’un contrôle d’accès à l’origine de toutes les origines et distributions qui l’utilisent, une par une. Avec ce paramètre, CloudFront ne signe aucune demande envoyée à l' MediaStoreorigine.  
Pour utiliser ce paramètre, l' MediaStore origine doit être accessible au public. Si vous utilisez ce paramètre avec une MediaStore origine qui n'est pas accessible au public, vous CloudFront ne pouvez pas accéder à l'origine. L' MediaStore origine renvoie les erreurs CloudFront et les CloudFront transmet aux spectateurs. Pour plus d'informations, consultez l'exemple de politique de MediaStore conteneur pour l'[accès public en lecture via HTTPS](https://docs.aws.amazon.com/mediastore/latest/ug/policies-examples-public-https.html).

**Ne remplacez pas l’en-tête `Authorization` de l’utilisateur (client)**  
Ce paramètre est nommé **Ne pas remplacer l'en-tête d'autorisation** dans la console ou `no-override` dans l'API, la CLI et CloudFormation. Utilisez ce paramètre lorsque vous CloudFront souhaitez signer des demandes d'origine uniquement lorsque la demande d'affichage correspondante ne contient pas d'`Authorization`en-tête. Avec ce paramètre, CloudFront transmet l'`Authorization`en-tête de la demande du visualiseur lorsqu'il y en a un, mais signe la demande d'origine (en ajoutant son propre `Authorization` en-tête) lorsque la demande du visualiseur n'inclut pas d'`Authorization`en-tête.  
Pour transmettre l'`Authorization`en-tête de la demande du lecteur, vous *devez* l'`Authorization`ajouter à une [politique de cache](controlling-the-cache-key.md) pour tous les comportements de cache qui utilisent des MediaStore origines associées à ce contrôle d'accès aux origines.

# Restreindre l'accès à l'origine de l'URL d'une AWS Lambda fonction
<a name="private-content-restricting-access-to-lambda"></a>

CloudFront fournit un *contrôle d'accès à l'origine* (OAC) pour restreindre l'accès à l'origine de l'URL d'une fonction Lambda.

**Topics**
+ [Création d’un nouvel OAC](#create-oac-overview-lambda)
+ [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-lambda)
+ [Exemple de code de modèle](#example-template-code-lambda-oac)

## Création d’un nouvel OAC
<a name="create-oac-overview-lambda"></a>

Suivez les étapes décrites dans les rubriques suivantes pour configurer un nouvel OAC dans CloudFront.

**Important**  
Si vous utilisez `POST` des méthodes `PUT` or avec l'URL de votre fonction Lambda, vos utilisateurs doivent calculer le corps SHA256 du corps et inclure la valeur de hachage de la charge utile du corps de la demande dans l'`x-amz-content-sha256`en-tête lorsqu'ils envoient la demande à. CloudFront Lambda ne prend pas en charge les données utiles non signées.

**Topics**
+ [Conditions préalables](#oac-prerequisites-lambda)
+ [CloudFront Autoriser l'accès à l'URL de la fonction Lambda](#oac-permission-to-access-lambda)
+ [Création de l’OAC](#create-oac-lambda)

### Conditions préalables
<a name="oac-prerequisites-lambda"></a>

Avant de créer et de configurer OAC, vous devez disposer d'une CloudFront distribution avec une URL de fonction Lambda comme origine. Pour utiliser l’OAC, vous devez spécifier la valeur `AWS_IAM` pour le paramètre `AuthType`. Pour de plus amples informations, veuillez consulter [Utilisation d’une URL de fonction Lambda](DownloadDistS3AndCustomOrigins.md#concept_lambda_function_url).

### CloudFront Autoriser l'accès à l'URL de la fonction Lambda
<a name="oac-permission-to-access-lambda"></a>

Avant de créer un OAC ou de le configurer dans une CloudFront distribution, assurez-vous qu'il CloudFront est autorisé à accéder à l'URL de la fonction Lambda. Procédez ainsi après avoir créé une CloudFront distribution, mais avant d'ajouter l'OAC à l'URL de la fonction Lambda dans la configuration de distribution.

**Note**  
Pour mettre à jour la politique IAM de l’URL de la fonction Lambda, vous devez utiliser l’ AWS Command Line Interface (AWS CLI). La modification de la politique IAM dans la console Lambda n’est pas prise en charge pour le moment.

La AWS CLI commande suivante accorde au CloudFront service principal (`cloudfront.amazonaws.com`) l'accès à l'URL de votre fonction Lambda. L'`Condition`élément de la politique permet d'accéder CloudFront à Lambda *uniquement* lorsque la demande provient de la CloudFront distribution qui contient l'URL de la fonction Lambda. Il s’agit de la distribution contenant l’URL de la fonction Lambda à laquelle vous souhaitez ajouter l’OAC.

**Example : AWS CLI commande pour mettre à jour une politique afin d'autoriser l'accès en lecture seule pour une CloudFront distribution avec OAC activé**  
Les AWS CLI commandes suivantes permettent à la CloudFront distribution (`E1PDK09ESKHJWT`) d'accéder à votre Lambda*`FUNCTION_URL_NAME`*.

```
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
```

**Note**  
Si vous créez une distribution et qu'elle n'est pas autorisée à accéder à l'URL de votre fonction Lambda, vous pouvez choisir la **commande Copy CLI** depuis la CloudFront console, puis entrer cette commande depuis votre terminal de ligne de commande. Pour plus d’informations, consultez [Attribution de l’accès à la fonction aux Services AWS](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) dans le *Guide du développeur AWS Lambda *. 

### Création de l’OAC
<a name="create-oac-lambda"></a>

Pour créer un OAC, vous pouvez utiliser le AWS Management Console CloudFormation, AWS CLI, ou l' CloudFront API.

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

**Pour créer un OAC**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le panneau de navigation de gauche, choisissez **Accès à l'origine**.

1. Choisissez **Créer un paramètre de contrôle**.

1. Sur la page **Créer un nouvel OAC**, procédez comme suit :

   1. Entrez un **Nom** et éventuellement une **Description** pour l’OAC.

   1. Dans **Comportement de signature**, nous vous recommandons de conserver le paramètre par défaut **Demandes de signature (recommandé)**. Pour de plus amples informations, veuillez consulter [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-lambda).

1. Pour **Type de l’origine**, choisissez **Lambda**. 

1. Choisissez **Créer**.
**Astuce**  
Après avoir créé l’OAC, prenez note du **Nom**. Vous en aurez besoin au cours de la procédure suivante.

**Pour ajouter un contrôle d’accès d’origine à une URL de fonction Lambda dans une distribution**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez une distribution qui comporte l’URL de fonction Lambda à laquelle vous souhaitez ajouter l’OAC, puis choisissez l’onglet **Origines**.

1. Sélectionnez l’URL de fonction Lambda à laquelle vous souhaitez ajouter l’OAC, puis choisissez **Modifier**.

1. Sélectionnez **HTTPS only** (HTTPS uniquement) pour le paramètre **Protocol** (Protocole) de votre origine.

1. Dans le menu déroulant **Contrôle d’accès d’origine**, choisissez le nom de l’OAC que vous souhaitez utiliser.

1. Sélectionnez **Enregistrer les modifications**.

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu’un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu’il envoie à l’URL de fonction Lambda.

------
#### [ CloudFormation ]

Pour créer un OAC avec CloudFormation, utilisez le type de `AWS::CloudFront::OriginAccessControl` ressource. L'exemple suivant montre la syntaxe du CloudFormation modèle, au format YAML, pour créer un OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: lambda
      SigningBehavior: always
      SigningProtocol: sigv4
```

Pour plus d'informations, consultez la section [AWS::CloudFront::OriginAccessContrôle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) dans le *guide de AWS CloudFormation l'utilisateur*.

------
#### [ CLI ]

Pour créer un contrôle d'accès à l'origine avec le AWS Command Line Interface (AWS CLI), utilisez la **aws cloudfront create-origin-access-control** commande. Vous pouvez utiliser un fichier d’entrée pour fournir les paramètres d’entrée de la commande, plutôt que de spécifier chaque paramètre individuel comme entrée de ligne de commande.

**Pour créer un contrôle d'accès à l'origine (CLI avec un fichier d'entrée)**

1. Utilisez la commande suivante pour créer un fichier nommé `origin-access-control.yaml`. Ce fichier contient tous les paramètres d’entrée de la commande **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Ouvrez le fichier `origin-access-control.yaml` que vous venez de créer. Modifiez le fichier pour ajouter un nom à l'OAC, une description (facultative) et remplacez `SigningBehavior` par `always`. Ensuite, enregistrez le fichier.

   Pour plus d'informations sur paramètres OAC, consultez [Paramètres avancés pour le contrôle d’accès à l’origine](#oac-advanced-settings-lambda).

1. Utilisez la commande suivante pour créer le contrôle d'accès à l'origine à l'aide des paramètres d'entrée du fichier `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Notez la valeur de `Id` dans la sortie de la commande. Vous en avez besoin pour ajouter l'OAC à l'URL d'une fonction Lambda dans CloudFront une distribution.

**Pour attacher un OAC à une URL de fonction Lambda dans une distribution existante (CLI avec un fichier d’entrée)**

1. Utilisez la commande suivante pour enregistrer la configuration de distribution pour la CloudFront distribution à laquelle vous souhaitez ajouter l'OAC. La distribution doit disposer d’une URL de fonction Lambda comme origine.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Ouvrez le fichier nommé `dist-config.yaml` que vous venez de créer. Modifiez le fichier en apportant les modifications suivantes :
   + Dans l'objet `Origins`, ajoutez l'ID de l'OAC au champ nommé `OriginAccessControlId`.
   + Supprimez la valeur du champ nommé `OriginAccessIdentity`, le cas échéant.
   + Renommez le champ `ETag` en `IfMatch`, mais ne modifiez pas la valeur du champ.

   Enregistrez le fichier lorsque vous avez terminé.

1. Utilisez la commande suivante pour mettre à jour la distribution afin d’utiliser le contrôle d’accès à l’origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu’un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu’il envoie à l’URL de fonction Lambda.

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

Pour créer un OAC avec l' CloudFront API, utilisez [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Pour plus d'informations sur les champs que vous spécifiez dans cet appel d'API, consultez la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

Après avoir créé un OAC, vous pouvez l’attacher à une URL de fonction Lambda dans une distribution à l'aide de l’un des appels d’API suivants :
+ Pour l'associer à une distribution existante, utilisez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Pour l'associer à une nouvelle distribution, utilisez [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Pour ces deux appels d’API, indiquez l’OAC dans le champ `OriginAccessControlId`, à l’intérieur d’une origine. Pour plus d'informations sur les autres champs que vous spécifiez dans ces appels d'API, consultez la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

------

## Paramètres avancés pour le contrôle d’accès à l’origine
<a name="oac-advanced-settings-lambda"></a>

La fonctionnalité CloudFront OAC inclut des paramètres avancés destinés uniquement à des cas d'utilisation spécifiques. Utilisez les paramètres recommandés, sauf si vous avez des besoins spécifiques en matière de paramètres avancés.

L'OAC contient un paramètre nommé **Comportement de signature** (dans la console) ou `SigningBehavior` (dans l'API, la CLI et CloudFormation). Ce paramètre fournit les options suivantes :

**Toujours signer les demandes d'origine (paramètre recommandé)**  
Nous vous recommandons d’utiliser ce paramètre, nommé **Signer les demandes (recommandé)** dans la console ou `always` dans l’API, la CLI et CloudFormation. Avec ce paramètre, il signe CloudFront toujours toutes les demandes envoyées à l'URL de la fonction Lambda.

**Ne jamais signer les demandes d’origine**  
Ce paramètre est nommé **Ne pas signer les demandes** dans la console ou `never` dans l’API, la CLI et CloudFormation. Utilisez ce paramètre pour désactiver l’OAC pour toutes les origines dans l’ensemble des distributions qui utilisent cet OAC. Cela permet d’économiser du temps et des efforts par rapport à la suppression d’un OAC de toutes les origines et distributions qui l’utilisent, une par une. Avec ce paramètre, CloudFront ne signe aucune demande envoyée à l'URL de la fonction Lambda.  
Pour utiliser ce paramètre, l’URL de fonction Lambda doit être accessible au public. Si vous utilisez ce paramètre avec une URL de fonction Lambda qui n'est pas accessible au public, CloudFront vous ne pouvez pas accéder à l'origine. L'URL de la fonction Lambda renvoie des erreurs CloudFront et les CloudFront transmet aux utilisateurs. Pour plus d'informations, consultez [la section Modèle de sécurité et d'authentification pour la URLs fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) dans *AWS Lambda le guide de l'*utilisateur.

**Ne remplacez pas l’en-tête `Authorization` de l’utilisateur (client)**  
Ce paramètre est nommé **Ne pas remplacer l'en-tête d'autorisation** dans la console ou `no-override` dans l'API, la CLI et CloudFormation. Utilisez ce paramètre lorsque vous CloudFront souhaitez signer des demandes d'origine uniquement lorsque la demande d'affichage correspondante ne contient pas d'`Authorization`en-tête. Avec ce paramètre, CloudFront transmet l'`Authorization`en-tête de la demande du visualiseur lorsqu'il y en a un, mais signe la demande d'origine (en ajoutant son propre `Authorization` en-tête) lorsque la demande du visualiseur n'inclut pas d'`Authorization`en-tête.  
+ Si vous utilisez ce paramètre, vous devez spécifier la signature Signature Version 4 pour l'URL de la fonction Lambda au lieu du nom ou du CloudFront CNAME de votre distribution. Lorsque l' CloudFront `Authorization`en-tête de la demande du visualiseur est transféré à l'URL de la fonction Lambda, Lambda valide la signature par rapport à l'hôte du domaine URL Lambda. Si la signature n’est pas basée sur le domaine de l’URL Lambda, l’hôte figurant dans la signature ne correspondra pas à celui utilisé par l’origine de l’URL Lambda. Ainsi, la demande échouera, entraînant une erreur de validation de signature.
+ Pour transmettre l'`Authorization`en-tête de la demande du lecteur, vous *devez* l'`Authorization`ajouter à une [politique de cache](controlling-the-cache-key.md) pour tous les comportements de cache qui utilisent la fonction Lambda URLs associée à ce contrôle d'accès à l'origine.

## Exemple de code de modèle
<a name="example-template-code-lambda-oac"></a>

Si votre CloudFront origine est une URL de fonction Lambda associée à un OAC, vous pouvez utiliser le script Python suivant pour télécharger des fichiers vers la fonction Lambda avec la méthode. `POST` 

Ce code suppose que vous avez configuré l’OAC avec le comportement de signature par défaut défini sur **Toujours signer les demandes d’origine** et que vous n’avez pas sélectionné le paramètre **Ne pas remplacer l’en-tête d’autorisation**.

Cette configuration permet à l’OAC de gérer correctement l’autorisation SigV4 avec Lambda à l'aide du nom d’hôte Lambda. Les données utiles sont signées à l’aide de SigV4 à partir de l’identité IAM autorisée pour l’URL de la fonction Lambda, laquelle est désignée comme type `IAM_AUTH`. 

Le modèle montre comment gérer les valeurs de hachage des données utiles signées dans l’en-tête x-amz-content-sha256 pour les demandes `POST` provenant du côté client. Plus précisément, ce modèle est conçu pour gérer les données utiles des données de formulaire. Le modèle permet le téléchargement sécurisé de fichiers vers l'URL CloudFront d'une fonction Lambda et AWS utilise des mécanismes d'authentification pour garantir que seules les demandes autorisées peuvent accéder à la fonction Lambda.

**Le code inclut les fonctionnalités suivantes :**  
Satisfait à l’exigence d’inclure le hachage des données utiles dans l’en-tête x-amz-content-sha256
Utilise l'authentification SigV4 pour un accès sécurisé Service AWS 
Prend en charge les envois de fichiers à l’aide de données de formulaire en plusieurs parties
Inclut la gestion des erreurs pour les exceptions de demande

```
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)
```

# Restriction de l’accès à une origine Amazon S3
<a name="private-content-restricting-access-to-s3"></a>

CloudFront propose deux méthodes pour envoyer des demandes authentifiées à une origine Amazon S3 : le *contrôle d'accès à l'origine* (OAC) et l'*identité d'accès à l'origine* (OAI). L’OAC vous permet de sécuriser vos origines, telles qu’Amazon S3. 

Nous vous *recommandons* d’utiliser l’OAC à la place, car il prend en charge les fonctionnalités suivantes :
+ Tous les compartiments Amazon S3 en tout Régions AWS, y compris les régions optionnelles lancées après décembre 2022
+ [Chiffrement côté serveur avec AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS) Amazon S3
+ Demandes dynamiques (`PUT` et `DELETE`) vers Amazon S3

L’OAI ne prend pas en charge ces fonctionnalités ou nécessite des solutions de contournement supplémentaires dans ces scénarios. Si vous utilisez déjà OAI et que vous souhaitez effectuer une migration, consultez [Migration de l'identité d'accès à l'origine (OAI) vers le contrôle d'accès à l'origine (OAC)](#migrate-from-oai-to-oac).

**Remarques**  
Lorsque vous utilisez l' CloudFront OAC avec les origines des compartiments Amazon S3, vous devez définir **Amazon S3 Object Ownership** pour que le **propriétaire du compartiment soit appliqué**, ce qui est le cas par défaut pour les nouveaux compartiments Amazon S3. Si nécessaire ACLs, utilisez le paramètre **préféré du propriétaire du compartiment** pour garder le contrôle sur les objets chargés via CloudFront.
Si votre origine est un compartiment Amazon S3 configuré comme point de [terminaison de site Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html), vous devez le configurer en CloudFront tant qu'origine personnalisée. Cela signifie que vous ne pouvez pas utiliser OAC (ou OAI). L’OAC ne prend pas en charge la redirection d’origine à l’aide de Lambda@Edge.
Si vous utilisez un point d'accès multirégional Amazon S3 comme point CloudFront d'origine, consultez[Restreindre l'accès à l'origine d'un point d'accès multirégional Amazon S3](private-content-restricting-access-to-s3-mrap.md). Les points d'accès multirégionaux S3 nécessitent une configuration OAC différente.

Les rubriques suivantes décrivent comment utiliser l'origine Amazon S3. 

**Rubriques**
+ [Création d’un nouveau contrôle d’accès d’origine](#create-oac-overview-s3)
+ [Suppression d’une distribution avec un OAC associé à un compartiment S3](#delete-oac-distribution-s3)
+ [Migration de l'identité d'accès à l'origine (OAI) vers le contrôle d'accès à l'origine (OAC)](#migrate-from-oai-to-oac)
+ [Paramètres avancés pour le contrôle d'accès à l'origine](#oac-advanced-settings-s3)

## Création d’un nouveau contrôle d’accès d’origine
<a name="create-oac-overview-s3"></a>

Suivez les étapes décrites dans les rubriques suivantes pour configurer un nouveau contrôle d'accès à l'origine dans CloudFront.

**Topics**
+ [Conditions préalables](#oac-prerequisites-s3)
+ [Accorder l' CloudFront autorisation d'accéder au compartiment S3](#oac-permission-to-access-s3)
+ [Création du contrôle d’accès d’origine](#create-oac-s3)

### Conditions préalables
<a name="oac-prerequisites-s3"></a>

Avant de créer et de configurer le contrôle d'accès à l'origine (OAC), vous devez disposer d'une CloudFront distribution avec une origine de compartiment Amazon S3. Cette origine doit être un compartiment S3 normal, et non un compartiment configuré en tant que [point de terminaison](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html). Pour plus d'informations sur la configuration d'une CloudFront distribution avec une origine de compartiment S3, consultez[Commencez avec une distribution CloudFront standard](GettingStarted.SimpleDistribution.md).

**Important**  
Lorsque vous utilisez OAC pour sécuriser votre origine Amazon S3, la communication entre Amazon S3 CloudFront et Amazon S3 se fait *toujours* via HTTPS, mais uniquement lorsque vous choisissez de *toujours signer les demandes*. Vous devez choisir **Signer les demandes (recommandé)** dans la console ou les spécifier `always` dans l' CloudFront API AWS CLI, ou CloudFormation.   
Si vous choisissez plutôt l'option **Ne pas signer les demandes** ou **Ne pas remplacer l'en-tête d'autorisation**, utilisez le CloudFront protocole de connexion que vous avez spécifié dans les politiques suivantes :  
[Politique du protocole Viewer](using-https-viewers-to-cloudfront.md) 
[Stratégie de protocole de l’origine](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) (origines personnalisées uniquement)
Par exemple, si vous choisissez **Ne pas remplacer l'en-tête d'autorisation** et que vous souhaitez utiliser le protocole HTTPS entre CloudFront et votre origine Amazon S3, utilisez **Redirect HTTP vers HTTPS ou HTTPS** **uniquement** pour la [politique de protocole de visualisation](using-https-viewers-to-cloudfront.md).

### Accorder l' CloudFront autorisation d'accéder au compartiment S3
<a name="oac-permission-to-access-s3"></a>

Avant de créer un contrôle d'accès à l'origine (OAC) ou de le configurer dans une CloudFront distribution, assurez-vous que celui-ci CloudFront est autorisé à accéder à l'origine du compartiment S3. Procédez ainsi après avoir créé une CloudFront distribution, mais avant d'ajouter l'OAC à l'origine S3 dans la configuration de distribution.

Utilisez une [politique de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) S3 pour autoriser le principal de CloudFront service (`cloudfront.amazonaws.com`) à accéder au compartiment. Utilisez un `Condition` élément de la politique CloudFront pour autoriser l'accès au compartiment uniquement lorsque la demande provient de la CloudFront distribution contenant l'origine S3. Il s’agit de la distribution contenant l’origine S3 à laquelle vous souhaitez ajouter l’OAC.

Pour plus d'informations sur l'ajout ou la modification d'une stratégie de compartiment, consultez [Ajout d'une stratégie de compartiment à l'aide de la console Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)dans le *Guide de l’utilisateur Amazon S3*.

Voici des exemples de politiques de compartiment S3 qui autorisent une CloudFront distribution avec OAC à accéder à une origine S3.

**Example Politique de compartiment S3 qui autorise l'accès en lecture seule pour une CloudFront distribution avec OAC activé**    
****  

```
{
  "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 Politique de compartiment S3 qui autorise l'accès en lecture et en écriture pour une CloudFront distribution avec OAC activé**    
****  

```
{
  "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>

Si les objets de l'origine du compartiment S3 sont chiffrés à l'aide du [chiffrement côté serveur avec AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), vous devez vous assurer que la CloudFront distribution est autorisée à utiliser la clé. AWS KMS Pour autoriser la CloudFront distribution à utiliser la clé KMS, ajoutez une déclaration à la [politique de clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). Pour plus d’informations sur la modification d’une stratégie de clé, consultez [Modification d’une stratégie de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) dans le *Guide du développeur AWS Key Management Service *.

**Example Déclaration de stratégie de clé KMS**  
L'exemple suivant montre une déclaration de AWS KMS politique qui permet à la CloudFront distribution avec OAC d'accéder à une clé KMS pour 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>"
            }
        }
}
```

### Création du contrôle d’accès d’origine
<a name="create-oac-s3"></a>

Pour créer un contrôle d'accès à l'origine (OAC), vous pouvez utiliser le AWS Management Console CloudFormation, AWS CLI, ou l' CloudFront API.

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

**Pour créer un contrôle d’accès à l’origine**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le panneau de navigation de gauche, choisissez **Accès à l'origine**.

1. Choisissez **Créer un paramètre de contrôle**.

1. Sur l'écran **Créer un paramètre de contrôle**, procédez comme suit :

   1. Dans le volet **Détails**, entrez un **Nom** et (éventuellement) une **Description** pour le contrôle d'accès à l'origine.

   1. Dans le volet **Paramètres**, nous vous recommandons de conserver le paramètre par défaut (**Signer les demandes (recommandé)**). Pour de plus amples informations, veuillez consulter [Paramètres avancés pour le contrôle d'accès à l'origine](#oac-advanced-settings-s3).

1. Choisissez S3 dans la liste déroulante **Origin type** (Type de l'origine).

1. Choisissez **Créer**.

   Après avoir créé l'OAC, prenez note de **Nom**. Vous en aurez besoin au cours de la procédure suivante.

**Pour ajouter un contrôle d'accès à une origine S3 dans une distribution**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez une distribution avec une origine S3 à laquelle vous souhaitez ajouter l'OAC, puis choisissez l'onglet **Origines**.

1. Sélectionnez l'origine S3 que vous souhaitez ajouter à l'origine, puis choisissez **Modifier**.

1. Pour **Accès d’origine**, sélectionnez **Paramètres de contrôle d’accès d’origine (recommandé)**.

1. Dans le menu déroulant **Origin access control** (Contrôle d'accès d'origine), choisissez l'OAC que vous souhaitez utiliser.

1. Sélectionnez **Enregistrer les modifications**.

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l'origine du compartiment S3.

------
#### [ CloudFormation ]

Pour créer un contrôle d'accès à l'origine (OAC) avec CloudFormation, utilisez le type de `AWS::CloudFront::OriginAccessControl` ressource. L'exemple suivant montre la syntaxe du CloudFormation modèle, au format YAML, pour créer un contrôle d'accès à l'origine.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4
```

Pour plus d'informations, consultez la section [AWS::CloudFront::OriginAccessContrôle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) dans le *guide de AWS CloudFormation l'utilisateur*.

------
#### [ CLI ]

Pour créer un contrôle d'accès à l'origine avec le AWS Command Line Interface (AWS CLI), utilisez la **aws cloudfront create-origin-access-control** commande. Vous pouvez utiliser un fichier d’entrée pour fournir les paramètres d’entrée de la commande, plutôt que de spécifier chaque paramètre individuel comme entrée de ligne de commande.

**Pour créer un contrôle d'accès à l'origine (CLI avec un fichier d'entrée)**

1. Utilisez la commande suivante pour créer un fichier nommé `origin-access-control.yaml`. Ce fichier contient tous les paramètres d’entrée de la commande **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Ouvrez le fichier `origin-access-control.yaml` que vous venez de créer. Modifiez le fichier pour ajouter un nom à l'OAC, une description (facultative) et remplacez `SigningBehavior` par `always`. Ensuite, enregistrez le fichier.

   Pour plus d'informations sur paramètres OAC, consultez [Paramètres avancés pour le contrôle d'accès à l'origine](#oac-advanced-settings-s3).

1. Utilisez la commande suivante pour créer le contrôle d'accès à l'origine à l'aide des paramètres d'entrée du fichier `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Notez la valeur de `Id` dans la sortie de la commande. Vous en avez besoin pour ajouter l'OAC à l'origine d'un compartiment S3 dans une CloudFront distribution.

**Pour attacher un OAC à l'origine d'un compartiment S3 dans une distribution existante (CLI avec un fichier d'entrée)**

1. Utilisez la commande suivante pour enregistrer la configuration de distribution pour la CloudFront distribution à laquelle vous souhaitez ajouter l'OAC. La distribution doit avoir une origine de compartiment S3.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Ouvrez le fichier nommé `dist-config.yaml` que vous venez de créer. Modifiez le fichier en apportant les modifications suivantes :
   + Dans l'objet `Origins`, ajoutez l'ID de l'OAC au champ nommé `OriginAccessControlId`.
   + Supprimez la valeur du champ nommé `OriginAccessIdentity`, le cas échéant.
   + Renommez le champ `ETag` en `IfMatch`, mais ne modifiez pas la valeur du champ.

   Enregistrez le fichier lorsque vous avez terminé.

1. Utilisez la commande suivante pour mettre à jour la distribution afin d’utiliser le contrôle d’accès à l’origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l'origine du compartiment S3.

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

Pour créer un contrôle d'accès à l'origine avec l' CloudFront API, utilisez [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Pour plus d'informations sur les champs que vous spécifiez dans cet appel d'API, consultez la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

Après avoir créé un contrôle d'accès à l'origine, vous pouvez l'attacher à l'origine d'un compartiment S3 dans une distribution, à l'aide de l'un des appels d'API suivants :
+ Pour le rattacher à une distribution existante, utilisez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Pour l'associer à une nouvelle distribution, utilisez [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Pour ces deux appels d'API, indiquez l'ID de contrôle d'accès à l'origine dans le champ `OriginAccessControlId`, à l'intérieur d'une origine. Pour plus d'informations sur les autres champs que vous spécifiez dans ces appels d'API, consultez [Référence de tous les paramètres de distribution](distribution-web-values-specify.md) la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

------

## Suppression d’une distribution avec un OAC associé à un compartiment S3
<a name="delete-oac-distribution-s3"></a>

Si vous devez supprimer une distribution avec un OAC associé à un compartiment S3, vous devez supprimer la distribution avant de supprimer l’origine du compartiment S3. Vous pouvez également inclure la région dans le nom de domaine d’origine. Si cela n’est pas possible, vous pouvez supprimer l’OAC de la distribution en passant au mode public avant de le supprimer. Pour de plus amples informations, veuillez consulter [Supprimer une distribution](HowToDeleteDistribution.md).

## Migration de l'identité d'accès à l'origine (OAI) vers le contrôle d'accès à l'origine (OAC)
<a name="migrate-from-oai-to-oac"></a>

Pour migrer d’une ancienne identité d’accès d’origine (OAI) vers un contrôle d’accès d’origine (OAC), commencez par mettre à jour l’origine du compartiment S3 afin de permettre à l’OAI et à la distribution avec OAC d’accéder au contenu du compartiment. Cela garantit qu'il CloudFront ne perdra jamais l'accès au bucket pendant la transition. Pour permettre à l’OAI et à la distribution avec OAC d’accéder à un compartiment S3, mettez à jour la [Stratégie de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) de façon à inclure deux déclarations, une pour chaque type de principal.

L’exemple de stratégie de compartiment S3 suivant permet à la fois à une OAI et à une distribution avec OAC d’accéder à une origine S3.

**Example Politique de compartiment S3 qui autorise l'accès en lecture seule à un OAI et à une CloudFront distribution avec OAC activé**    
****  

```
{
    "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>/*"
        }
    ]
}
```

Après avoir mis à jour la stratégie de compartiment de l'origine S3 pour autoriser l'accès à la fois à l'OAI et à l'OAC, vous pouvez mettre à jour la configuration de distribution pour utiliser l'OAC au lieu de l'OAI. Pour de plus amples informations, veuillez consulter [Création d’un nouveau contrôle d’accès d’origine](#create-oac-overview-s3).

Une fois la distribution entièrement déployée, vous pouvez supprimer l'instruction de la politique de compartiment qui autorise l'accès à l'OAI. Pour de plus amples informations, veuillez consulter [Accorder l' CloudFront autorisation d'accéder au compartiment S3](#oac-permission-to-access-s3).

## Paramètres avancés pour le contrôle d'accès à l'origine
<a name="oac-advanced-settings-s3"></a>

La fonctionnalité de contrôle CloudFront d'accès à l'origine inclut des paramètres avancés destinés uniquement à des cas d'utilisation spécifiques. Utilisez les paramètres recommandés, sauf si vous avez des besoins spécifiques en matière de paramètres avancés.

Le contrôle d'accès à Origin contient un paramètre nommé **Comportement de signature** (dans la console) ou `SigningBehavior` (dans l'API, la CLI et CloudFormation). Ce paramètre fournit les options suivantes :

**Toujours signer les demandes d'origine (paramètre recommandé)**  
Nous vous recommandons d’utiliser ce paramètre, nommé **Signer les demandes (recommandé)** dans la console ou `always` dans l’API, la CLI et CloudFormation. Avec ce paramètre, il signe CloudFront toujours toutes les demandes qu'il envoie à l'origine du compartiment S3.

**Ne jamais signer les demandes d’origine**  
Ce paramètre est nommé **Ne pas signer les demandes** dans la console ou `never` dans l'API, la CLI et CloudFormation. Utilisez ce paramètre pour désactiver le contrôle d'accès à l'origine pour toutes les origines dans toutes les distributions qui utilisent ce contrôle d'accès à l'origine. Cela permet d’économiser du temps et des efforts par rapport à la suppression d’un contrôle d’accès à l’origine de toutes les origines et distributions qui l’utilisent, une par une. Avec ce paramètre, il CloudFront ne signe aucune demande envoyée à l'origine du compartiment S3.  
Pour utiliser ce paramètre, l'origine du compartiment S3 doit être accessible au public. Si vous utilisez ce paramètre avec une origine de compartiment S3 qui n'est pas accessible au public, vous CloudFront ne pouvez pas accéder à l'origine. L'origine du compartiment S3 renvoie les erreurs aux utilisateurs CloudFront et les CloudFront transmet aux utilisateurs.

**Ne remplacez pas l’en-tête `Authorization` de l’utilisateur (client)**  
Ce paramètre est nommé **Ne pas remplacer l'en-tête d'autorisation** dans la console ou `no-override` dans l'API, la CLI et CloudFormation. Utilisez ce paramètre lorsque vous CloudFront souhaitez signer des demandes d'origine uniquement lorsque la demande d'affichage correspondante ne contient pas d'`Authorization`en-tête. Avec ce paramètre, CloudFront transmet l'`Authorization`en-tête de la demande du visualiseur lorsqu'il y en a un, mais signe la demande d'origine (en ajoutant son propre `Authorization` en-tête) lorsque la demande du visualiseur n'inclut pas d'`Authorization`en-tête.  
Pour parcourir l'en-tête `Authorization` de la demande de l'utilisateur, vous *devez* ajouter l'en-tête `Authorization` à une [stratégie de mise en cache](controlling-the-cache-key.md) pour tous les comportements de cache qui utilisent les origines du compartiment S3 associées à ce contrôle d'accès à l'origine.

## Utilisation d’une identité d’accès d’origine (héritée, non recommandée)
<a name="private-content-restricting-access-to-s3-oai"></a>

### Présentation de l'identité d'accès à l'origine
<a name="private-content-restricting-access-to-s3-overview"></a>

CloudFront *L'identité d'accès à l'origine* (OAI) fournit des fonctionnalités similaires à celles du *contrôle d'accès à l'origine* (OAC), mais elle ne fonctionne pas dans tous les scénarios. Plus précisément, l'OAI ne prend pas en charge :
+ Tous les compartiments Amazon S3 Régions AWS, y compris les régions optionnelles
+ [Chiffrement côté serveur avec AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS) Amazon S3
+ Demandes dynamiques (`PUT`, `POST` ou `DELETE`) vers Amazon S3
+ Nouveau Régions AWS produit lancé après janvier 2023

**Astuce**  
Nous vous recommandons d’utiliser l’OAC à la place. Pour configurer l’OAC, consultez [Création d’un nouveau contrôle d’accès d’origine](#create-oac-overview-s3). Pour plus d'informations sur la migration d'OAI vers OAC, consultez [Migration de l'identité d'accès à l'origine (OAI) vers le contrôle d'accès à l'origine (OAC)](#migrate-from-oai-to-oac).

### Attribution à l’identité d’accès d’origine de l’autorisation de lire les fichiers du compartiment Amazon S3
<a name="private-content-granting-permissions-to-oai"></a>

Lorsque vous créez un OAI ou que vous en ajoutez un à une distribution à l'aide de la CloudFront console, vous pouvez automatiquement mettre à jour la politique de compartiment Amazon S3 pour autoriser l'OAI à accéder à votre compartiment. Vous pouvez également choisir de créer ou de mettre à jour manuellement la politique de compartiment. Quelle que soit la méthode que vous utilisez, vous devez toujours vérifier les autorisations pour vous assurer que :
+ Votre CloudFront OAI peut accéder aux fichiers du bucket pour le compte des utilisateurs qui les demandent. CloudFront
+ Les utilisateurs ne peuvent pas utiliser Amazon S3 URLs pour accéder à vos fichiers en dehors de CloudFront.

**Important**  
Si vous configurez CloudFront pour accepter et transférer toutes les méthodes HTTP compatibles, CloudFront assurez-vous d'accorder à votre CloudFront OAI les autorisations souhaitées. Par exemple, si vous configurez CloudFront pour accepter et transférer les demandes qui utilisent cette `DELETE` méthode, configurez votre politique de compartiment pour traiter les `DELETE` demandes de manière appropriée afin que les utilisateurs puissent supprimer uniquement les fichiers que vous souhaitez qu'ils souhaitent.

#### Utilisation des stratégies de compartiment Amazon S3
<a name="private-content-updating-s3-bucket-policies"></a>

Vous pouvez accorder à un CloudFront OAI l'accès aux fichiers d'un compartiment Amazon S3 en créant ou en mettant à jour la politique de compartiment de la manière suivante :
+ Utilisation de l’onglet **Autorisations** du compartiment Amazon S3 dans la [console Amazon S3](https://console.aws.amazon.com/s3/home).
+ Utilisation [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html)dans l'API Amazon S3.
+ En utilisant la [console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home). Lorsque vous ajoutez un OAI à vos paramètres d'origine dans la CloudFront console, vous pouvez choisir **Oui, mettre à jour la politique de compartiment** pour indiquer de mettre CloudFront à jour la politique de compartiment en votre nom.

Si vous mettez à jour manuellement la politique de compartiment, assurez-vous que vous :
+ Spécifiez l’identité d’accès à l’origine correcte comme `Principal` dans la politique.
+ Accordez à l’identité d’accès à l’origine les autorisations dont elle a besoin pour accéder aux objets pour le compte des utilisateurs.

Pour plus d’informations, consultez les sections suivantes.

##### Spécification d’une OAI comme `Principal` dans une politique de compartiment
<a name="private-content-updating-s3-bucket-policies-principal"></a>

Pour spécifier une OAI comme `Principal` dans une politique de compartiment Amazon S3, utilisez l’Amazon Resource Name (ARN) qui inclut son ID. Par exemple :

```
"Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
}
```

Trouvez l'ID OAI dans la CloudFront console sous **Security**, **Origin access**, **Identities (legacy).** Vous pouvez également l'utiliser [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)dans l' CloudFrontAPI.

##### Octroi d’autorisations à une OAI
<a name="private-content-updating-s3-bucket-policies-permissions"></a>

Pour donner à l’identité d’accès à l’origine les autorisations pour accéder aux objets de votre compartiment Amazon S3, utilisez des actions dans la politique qui se rapportent à des opérations d’API Amazon S3 spécifiques. Par exemple, l'action `s3:GetObject` permet à l'identité d'accès à l'origine de lire des objets dans le compartiment. Pour plus d’informations, consultez les exemples de la section suivante ou la section [Actions Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) du *Guide de l’utilisateur Amazon Simple Storage Service*.

##### Exemples de politique de compartiment Amazon S3
<a name="private-content-updating-s3-bucket-policies-examples"></a>

Les exemples suivants présentent les politiques de compartiment Amazon S3 qui permettent à CloudFront OAI d'accéder à un compartiment S3.

Trouvez l'ID OAI dans la CloudFront console sous **Security**, **Origin access**, **Identities (legacy).** Vous pouvez également l'utiliser [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)dans l' CloudFrontAPI.

**Example Politique de compartiment Amazon S3 qui donne à l’identité d’accès à l’origine un accès en lecture**  
L’exemple suivant permet à l’identité d’accès à l’origine de lire des objets dans le compartiment spécifié (`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 Politique de compartiment Amazon S3 qui donne à l’identité d’accès à l’origine un accès en lecture et en écriture**  
L’exemple suivant permet à l’identité d’accès à l’origine de lire et d’écrire des objets dans le compartiment spécifié (`s3:GetObject` et `s3:PutObject`). Cela permet aux utilisateurs de télécharger des fichiers dans votre compartiment Amazon S3 via 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>/*"
        }
    ]
}
```

#### Utiliser un objet Amazon S3 ACLs (non recommandé)
<a name="private-content-updating-s3-acls"></a>

**Important**  
Il est recommandé [d’utiliser les politiques du compartiment Amazon S3](#private-content-updating-s3-bucket-policies) pour attribuer à une OAI l’accès à un compartiment S3. Vous pouvez utiliser les listes de contrôle d'accès (ACLs) comme décrit dans cette section, mais nous ne le recommandons pas.  
Amazon S3 recommande de définir [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) comme **étant appliqué par le propriétaire du compartiment**, ce qui signifie que ces paramètres ACLs sont désactivés pour le compartiment et les objets qu'il contient. Lorsque vous appliquez ce paramètre à Object Ownership (Propriété de l’objet), vous devez utiliser des politiques du compartiment pour donner l’accès à l’OAI (consultez la section précédente).  
La section suivante concerne uniquement les anciens cas d'utilisation qui nécessitent ACLs.

Vous pouvez accorder à un CloudFront OAI l'accès aux fichiers d'un compartiment Amazon S3 en créant ou en mettant à jour l'ACL du fichier de la manière suivante :
+ Utilisation de l’onglet **Autorisations** de l’objet Amazon S3 dans la [console Amazon S3](https://console.aws.amazon.com/s3/home).
+ Utilisation [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html)dans l'API Amazon S3.

Lorsque vous accordez l’accès à une identité d’accès à l’origine à l’aide d’une liste ACL, vous devez spécifier l’identité d’accès à l’origine à l’aide de son ID d’utilisateur canonique Amazon S3. Dans la CloudFront console, vous pouvez trouver cet identifiant sous **Sécurité**, **Accès à l'origine**, **Identités (ancienne)**. Si vous utilisez l' CloudFront API, utilisez la valeur de l'`S3CanonicalUserId`élément renvoyé lorsque vous avez créé l'OAI, ou appelez [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)l' CloudFrontAPI.

### Utilisation d’une identité d’accès d’origine dans les régions Amazon S3 prenant uniquement en charge l’authentification Signature version 4
<a name="private-content-origin-access-identity-signature-version-4"></a>

Les régions Amazon S3 plus récentes requièrent que vous utilisiez Signature version 4 pour les demandes authentifiées. (Pour connaître les versions de signatures prises en charge dans chaque région Amazon S3, consultez la section [Points de terminaison et quotas Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) de la *Références générales AWS*.) Si vous utilisez une identité d’accès à l’origine et que votre compartiment se trouve dans l’une des régions qui nécessitent Signature version 4, notez les points suivants :
+ Les demandes `DELETE`, `GET`, `HEAD`, `OPTIONS` et`PATCH` sont prises en charge sans qualifications.
+ Les demandes `POST` ne sont pas prises en charge.

# Restriction de l’accès avec les origines de VPC
<a name="private-content-vpc-origins"></a>

Vous pouvez l'utiliser CloudFront pour diffuser du contenu à partir d'applications hébergées dans les sous-réseaux privés de votre cloud privé virtuel (VPC). Vous pouvez utiliser des Application Load Balancers (ALB), des Network Load Balancers (NLB) et des instances EC2 dans des sous-réseaux privés en tant qu’origines VPC.

Voici certaines raisons pour lesquelles vous pourriez choisir d’utiliser des origines VPC :
+ **Sécurité** : VPC Origins est conçu pour améliorer le niveau de sécurité de votre application en plaçant vos équilibreurs de charge et vos instances EC2 dans des sous-réseaux privés, constituant CloudFront ainsi un point d'entrée unique. Les demandes des utilisateurs CloudFront proviennent du VPC via une connexion privée et sécurisée, ce qui renforce la sécurité de vos applications.
+ **Gestion** — Les origines des VPC réduisent la charge opérationnelle requise pour sécuriser la connectivité entre les origines CloudFront et les origines. Vous pouvez déplacer vos origines vers des sous-réseaux privés sans accès public, et vous n'avez pas à implémenter de listes de contrôle d'accès (ACLs) ou d'autres mécanismes pour restreindre l'accès à vos origines. Ainsi, vous n'avez pas à investir dans un travail de développement indifférencié pour sécuriser vos applications Web. CloudFront 
+ **Évolutivité et performances** : les origines du VPC vous aident à sécuriser vos applications Web, vous libérant ainsi du temps pour vous concentrer sur le développement de vos applications professionnelles critiques tout en améliorant la sécurité et en maintenant des performances élevées et une évolutivité mondiale grâce à. CloudFront Les origines du VPC rationalisent la gestion de la sécurité et réduisent la complexité opérationnelle afin que vous puissiez l'utiliser CloudFront comme point d'entrée unique pour vos applications.

**Astuce**  
CloudFront prend en charge le partage des origines des VPC entre eux Comptes AWS, qu'ils appartiennent ou non à votre organisation. Vous pouvez partager les origines des VPC depuis la CloudFront console ou utiliser AWS Resource Access Manager ()AWS RAM. Pour de plus amples informations, veuillez consulter [Utilisation de ressources partagées dans CloudFront](sharing-resources.md).

## Conditions préalables
<a name="vpc-origin-prerequisites"></a>

Avant de créer une origine VPC pour votre CloudFront distribution, vous devez effectuer les opérations suivantes :

### VPC Configuration
<a name="vpc-configuration"></a>

**Créez un cloud privé virtuel (VPC) sur Amazon VPC** dans l'un des clouds pris en charge pour Régions AWS les origines de VPC. Pour en savoir plus sur la création d’un VPC, consultez [Créer un VPC et d’autres ressources VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-and-other-resources) dans le *Guide de l’utilisateur Amazon VPC*. Pour obtenir une liste des régions prises en charge, consultez [Pris en charge Régions AWS pour les origines de VPC](#vpc-origins-supported-regions).

Votre VPC doit inclure les éléments suivants :
+ **Passerelle Internet** : vous devez ajouter une passerelle Internet au VPC qui contient vos ressources d’origine VPC. La passerelle Internet est nécessaire pour indiquer que le VPC peut recevoir du trafic provenant d’Internet. La passerelle Internet n’est pas utilisée pour acheminer le trafic vers les origines du sous-réseau, et il n’est pas nécessaire de mettre à jour les politiques de routage.
+ **Sous-réseau privé avec au moins une IPv4 adresse disponible** : CloudFront route vers votre sous-réseau à l'aide d'une interface ELASTIC (ENI) gérée par des services qui est CloudFront créée après avoir défini votre ressource d'origine VPC avec. CloudFront Vous devez disposer d'au moins une IPv4 adresse disponible dans votre sous-réseau privé pour que le processus de création d'ENI puisse réussir. L' IPv4 adresse peut être privée, sans frais supplémentaires. IPv6Les sous-réseaux -only ne sont pas pris en charge.

### Ressources d'origine
<a name="origin-resources"></a>

Dans le sous-réseau privé, déployez un Application Load Balancer, un Network Load Balancer ou une instance EC2 qui servira d’origine. La ressource que vous lancez doit être entièrement déployée et présenter l’état Actif avant de pouvoir être utilisée comme origine VPC.

**Restrictions d'origine :**
+ Les équilibreurs de charge Gateway ne peuvent pas être ajoutés en tant qu'origines
+ Les équilibreurs de charge réseau à double pile ne peuvent pas être ajoutés en tant qu'origines
+ Les équilibreurs de charge réseau dotés d'écouteurs TLS ne peuvent pas être ajoutés en tant qu'origines
+ Pour être utilisé comme origine VPC, un Network Load Balancer doit être associé à un groupe de sécurité

### Configuration du groupe de sécurité
<a name="security-group-configuration"></a>

Un groupe de sécurité doit être attaché à vos ressources d'origine VPC (Application Load Balancer, Network Load Balancer ou instance EC2). Lorsque vous créez une origine VPC, un groupe de sécurité géré par des services est CloudFront automatiquement créé avec le modèle de dénomination. `CloudFront-VPCOrigins-Service-SG` Ce groupe de sécurité est entièrement géré par AWS et ne doit pas être modifié.

Pour autoriser le trafic en provenance de votre VPC CloudFront à atteindre l'origine, mettez à jour le groupe de sécurité attaché à votre ressource d'origine (instance ALB, NLB ou EC2) afin d'autoriser le trafic entrant en utilisant l'une des méthodes suivantes :
+ **Option 1 :** Autoriser le trafic depuis la liste des préfixes CloudFront gérés. Pour de plus amples informations, veuillez consulter [Utiliser la liste de préfixes CloudFront gérée](LocationsOfEdgeServers.md#managed-prefix-list). Cela peut également être fait avant la création de l'origine du VPC.
+ **Option 2 :** autoriser le trafic provenant du groupe de sécurité CloudFront géré par le service ()`CloudFront-VPCOrigins-Service-SG`. Cela ne peut être fait qu'une fois l'origine du VPC créée et le groupe de sécurité géré par le service créé. Cette configuration est encore plus restrictive car elle restreint le trafic uniquement à vos CloudFront distributions.

**Important**  
Ne créez pas votre propre groupe de sécurité dont le nom commence par`CloudFront-VPCOrigins-Service-SG`. Il s'agit d'un modèle de dénomination AWS réservé aux groupes de sécurité gérés par des services. Pour plus d’informations, consultez [Création d’un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html).

### Restrictions relatives au protocole et aux fonctionnalités
<a name="protocol-feature-restrictions"></a>

Les origines VPC ne prennent pas en charge les éléments suivants :
+ WebSockets
+ Trafic gRPC
+ Déclencheurs de demande d'origine et de réponse d'origine avec Lambda @Edge

## Création d’une origine VPC (nouvelle distribution)
<a name="new-vpc-origin"></a>

La procédure suivante explique comment créer une origine VPC pour votre nouvelle CloudFront distribution dans la CloudFront console. Vous pouvez également utiliser les opérations d'[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)API [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html)et avec le AWS CLI ou un AWS SDK.

**Pour créer une origine VPC pour une nouvelle distribution CloudFront**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez les **Origines du VPC**, puis **Créer une origine du VPC**.

1. Renseignez les champs obligatoires. Pour **ARN d’origine**, sélectionnez l’ARN de votre Application Load Balancer, un Network Load Balancer ou une instance EC2. Si l’ARN n’apparaît pas, copiez l’ARN de votre ressource et collez-le ici.

1. Choisissez **Créer une origine du VPC**.

1. **Attendez que l’état de l’origine VPC passe à Déployé**. Ce processus peut prendre jusqu’à 15 minutes.

1. Choisissez **Distributions**, puis **Créer une distribution**.

1. Pour **Domaine de l’origine**, sélectionnez la ressource de l’origine VPC dans la liste déroulante.

   Si votre origine VPC est une instance EC2, copiez et collez le **Nom DNS IP privé** de l’instance dans le champ **Domaine de l’origine**.

1. Terminez la création de votre distribution. Pour de plus amples informations, veuillez consulter [Création d'une CloudFront distribution dans la console](distribution-web-creating-console.md#create-console-distribution).

## Création d’une origine VPC (distribution existante)
<a name="existing-vpc-origin"></a>

La procédure suivante explique comment créer une origine VPC pour votre CloudFront distribution existante dans la CloudFront console, afin de garantir la disponibilité continue de vos applications. Vous pouvez également utiliser les opérations d'[UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html)API [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html)et avec le AWS CLI ou un AWS SDK.

Vous pouvez éventuellement choisir d’ajouter l’origine VPC à votre distribution existante sans créer de distribution intermédiaire.

**Pour créer une origine VPC pour votre distribution existante CloudFront**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez les **Origines du VPC**, puis **Créer une origine du VPC**.

1. Renseignez les champs obligatoires. Pour **ARN d’origine**, sélectionnez l’ARN de votre Application Load Balancer, un Network Load Balancer ou une instance EC2. Si l’ARN n’apparaît pas, copiez l’ARN de votre ressource et collez-le ici.

1. Choisissez **Créer une origine du VPC**.

1. **Attendez que l’état de l’origine VPC passe à Déployé**. Ce processus peut prendre jusqu’à 15 minutes.

1. Dans le volet de navigation, sélectionnez **Distributions**.

1. Choisissez l’ID de votre distribution.

1. Dans l’onglet **Questions d’ordre général**, sous **Déploiement continu**, choisissez **Créer une distribution intermédiaire**. Pour de plus amples informations, veuillez consulter [Utilisez le déploiement CloudFront continu pour tester en toute sécurité les modifications de configuration du CDN](continuous-deployment.md).

1. Suivez les étapes de l’assistant indiquées dans **Créer une distribution intermédiaire** pour créer une distribution intermédiaire. Effectuez les étapes suivantes :
   + Pour **Origines**, choisissez **Créer une origine**.
   + Pour **Domaine de l’origine**, sélectionnez la ressource de votre origine VPC dans le menu déroulant.

     Si votre origine VPC est une instance EC2, copiez et collez le **Nom DNS IP privé** de l’instance dans le champ **Domaine de l’origine**.
   + Choisissez **Create origin (Créer une origine)**.

1. Dans votre distribution intermédiaire, testez l’origine VPC.

1. Faites passer la configuration de distribution intermédiaire à votre distribution principale. Pour de plus amples informations, veuillez consulter [Promouvoir la configuration d’une distribution intermédiaire](working-with-staging-distribution-continuous-deployment-policy.md#promote-staging-distribution-configuration).

1. Supprimez l’accès public à votre origine VPC en rendant le sous-réseau privé. Une fois cela fait, l'origine du VPC ne sera plus détectable sur Internet, mais CloudFront vous aurez toujours un accès privé à celui-ci. Pour plus d’informations, consultez [Associer ou dissocier un sous-réseau à une table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AssociateSubnet) dans le *Guide de l’utilisateur Amazon VPC*.

## Mise à jour d’une origine VPC
<a name="update-vpc-origin"></a>

La procédure suivante explique comment mettre à jour une origine VPC pour votre CloudFront distribution dans la CloudFront console. Vous pouvez également utiliser les opérations d'[UpdateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateVpcOrigin.html)API [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)et avec le AWS CLI ou un AWS SDK.

**Pour mettre à jour une origine VPC existante pour votre distribution CloudFront**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, sélectionnez **Distributions**.

1. Choisissez l’ID de votre distribution.

1. Choisissez l’onglet **Comportements**.

1. Assurez-vous que l’origine VPC n’est pas l’origine par défaut de votre comportement de cache. 

1. Choisissez l’onglet **Origines**.

1. Sélectionnez l’origine VPC que vous souhaitez mettre à jour et choisissez **Supprimer**. Cette opération dissocie l’origine VPC de votre distribution. Répétez les étapes 2 à 7 pour dissocier l’origine VPC de toute autre distribution.

1. Choisissez **Origines du VPC**.

1. Sélectionnez l’origine VPC et choisissez **Modifier**.

1. Effectuez vos mises à jour et choisissez **Mettre à jour l’origine du VPC**.

1. **Attendez que l’état de l’origine VPC passe à Déployé**. Ce processus peut prendre jusqu’à 15 minutes.

1. Dans le volet de navigation, sélectionnez **Distributions**.

1. Choisissez l’ID de votre distribution.

1. Choisissez l’onglet **Origines**.

1. Choisissez **Create origin (Créer une origine)**.

1. Pour **Domaine de l’origine**, sélectionnez la ressource de votre origine VPC dans le menu déroulant.

   Si votre origine VPC est une instance EC2, copiez et collez le **Nom DNS IP privé** de l’instance dans le champ **Domaine de l’origine**.

1. Choisissez **Create origin (Créer une origine)**. Cette opération associe à nouveau l’origine VPC à votre distribution. Répétez les étapes 12 à 17 pour associer l’origine VPC mise à jour à toute autre distribution.

## Pris en charge Régions AWS pour les origines de VPC
<a name="vpc-origins-supported-regions"></a>

Les origines VPC sont actuellement prises en charge dans la publicité suivante. Régions AWS Les exceptions de zone de disponibilité (AZ) sont notées.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)

# Restreindre l'accès à l'origine d'un point d'accès multirégional Amazon S3
<a name="private-content-restricting-access-to-s3-mrap"></a>

Vous pouvez utiliser le contrôle d'accès à l'origine (OAC) pour restreindre l'accès à un point d'accès multirégional Amazon S3. Les points d'accès multirégionaux S3 fournissent un point de terminaison global qui achemine les demandes vers le compartiment S3 le plus proche en fonction de la latence du réseau.

Pour plus d'informations sur l'utilisation d'OAC avec une origine de compartiment Amazon S3 standard, consultez[Restriction de l’accès à une origine Amazon S3](private-content-restricting-access-to-s3.md).

## Conditions préalables
<a name="oac-prerequisites-s3-mrap"></a>

Avant de créer et de configurer l'OAC, vous devez disposer d'une CloudFront distribution avec une origine de point d'accès multirégional Amazon S3. Le nom de domaine d'origine doit utiliser le format de nom d'hôte du point d'accès multirégional S3 :

`multi-region-access-point-alias.accesspoint.s3-global.amazonaws.com`

Pour plus d'informations sur la création d'un point d'accès multirégional S3, consultez la section [Création de points d'accès multirégionaux](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingMultiRegionAccessPoints.html) dans le guide de l'*utilisateur d'Amazon Simple Storage Service*.

## Accorder CloudFront l'autorisation d'accéder au point d'accès multirégional S3
<a name="oac-permission-to-access-s3-mrap"></a>

Mettez à jour la politique de point d'accès multirégional pour autoriser le principal de CloudFront service (`cloudfront.amazonaws.com`) à accéder au point d'accès multirégional. Utilisez un `Condition` élément de la politique pour autoriser l'accès CloudFront au point d'accès multirégional uniquement lorsque la demande est présentée au nom de la CloudFront distribution qui contient l'origine.

Pour plus d'informations sur l'ajout ou la modification d'une politique de point d'accès multirégional, consultez les [exemples de politique de points d'accès multirégionaux](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointPermissions.html) dans le guide de l'*utilisateur d'Amazon Simple Storage Service*.

**Example Politique de point d'accès multirégional pour CloudFront l'OAC**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccess",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3::111122223333:accesspoint/Multi-Region-Access-Point-Alias.mrap/object/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
                }
            }
        }
    ]
}
```

## Accorder CloudFront l'autorisation d'accéder aux compartiments S3 sous-jacents
<a name="oac-permission-to-access-s3-mrap-buckets"></a>

Outre la politique de point d'accès multirégional, vous devez également accorder CloudFront l'autorisation d'accéder à chacun des compartiments S3 sous-jacents associés au point d'accès multirégional. Vous pouvez effectuer cette opération de deux manières :

### Option 1 : Accorder l'accès uniquement à CloudFront
<a name="oac-s3-mrap-bucket-option1"></a>

Ajoutez une politique de compartiment à chaque compartiment S3 qui autorise le principal du CloudFront service à accéder au compartiment. Utilisez cette option lorsque vous devez également autoriser l'accès direct au bucket depuis d'autres sources.

**Example Politique de compartiment S3 pour un compartiment sous-jacent**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccessViaMRAP",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
                }
            }
        }
    ]
}
```

### Option 2 : déléguer l'accès complet au bucket au point d'accès multirégional
<a name="oac-s3-mrap-bucket-option2"></a>

Accordez au point d'accès multirégional un accès complet à chaque compartiment sous-jacent. Avec cette approche, tous les accès au bucket sont contrôlés par la politique des points d'accès multirégionaux, qui simplifie la gestion des accès. Nous recommandons cette option pour les cas d'utilisation qui ne nécessitent pas un accès direct au bucket.

**Example Politique de compartiment S3 qui délègue l'accès au point d'accès multirégional**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DelegateAccessToMRAP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1",
                "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointArn": "arn:aws:s3::111122223333:accesspoint/Multi-Region-Access-Point-Alias.mrap"
                }
            }
        }
    ]
}
```

Pour plus d'informations, consultez l'[exemple de politique de point d'accès multirégional](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointPermissions.html#MultiRegionAccessPointPolicyExamples) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*.

**Important**  
Vous devez ajouter cette politique de compartiment à chaque compartiment S3 associé au point d'accès multirégional. Si la politique n'est pas respectée dans un compartiment, les CloudFront demandes acheminées vers ce compartiment seront refusées.

### SSE-KMS
<a name="oac-s3-mrap-sse-kms"></a>

Si les objets des compartiments S3 sous-jacents sont chiffrés à l'aide du chiffrement côté serveur avec AWS KMS (SSE-KMS), vous devez vous assurer que la CloudFront distribution est autorisée à utiliser la clé. AWS KMS Étant donné que les points d'accès multirégionaux S3 peuvent acheminer les demandes vers des compartiments situés dans plusieurs régions, vous devez ajouter une déclaration à la politique de clé KMS dans chaque région où un compartiment sous-jacent utilise SSE-KMS. Pour plus d’informations sur la modification d’une stratégie de clé, consultez [Modification d’une stratégie de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) dans le *Guide du développeur AWS Key Management Service *.

**Example Déclaration de stratégie de clé KMS**  
L'exemple suivant montre une déclaration de politique de clé KMS qui permet à la CloudFront distribution via OAC d'accéder à une clé KMS pour 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"
        }
    }
}
```

**Important**  
Vous devez ajouter cette déclaration de politique clé à la clé KMS dans chaque région où un compartiment S3 sous-jacent utilise le chiffrement SSE-KMS.

## Création du contrôle d’accès d’origine
<a name="create-oac-s3-mrap"></a>

Pour créer un contrôle d'accès à l'origine (OAC), vous pouvez utiliser le AWS Management Console CloudFormation, AWS CLI, ou l' CloudFront API.

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

**Pour créer un contrôle d’accès à l’origine**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le panneau de navigation de gauche, choisissez **Accès à l'origine**.

1. Choisissez **Créer un paramètre de contrôle**.

1. Sur l'écran **Créer un paramètre de contrôle**, procédez comme suit :

   1. Dans le volet **Détails**, entrez un **Nom** et (éventuellement) une **Description** pour le contrôle d'accès à l'origine.

   1. Dans le volet **Paramètres**, nous vous recommandons de conserver le paramètre par défaut (**Signer les demandes (recommandé)**). Pour de plus amples informations, veuillez consulter [Paramètres avancés pour le contrôle d'accès à l'origine](private-content-restricting-access-to-s3.md#oac-advanced-settings-s3).

1. Choisissez le **point d'accès multirégional S3** dans la liste déroulante du **type d'origine**.

1. Choisissez **Créer**.

   Après avoir créé l'OAC, prenez note de **Nom**. Vous en aurez besoin au cours de la procédure suivante.

**Pour ajouter un contrôle d'accès d'origine à l'origine d'un point d'accès multirégional S3 dans une distribution**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez une distribution avec une origine de point d'accès multirégional S3 à laquelle vous souhaitez ajouter l'OAC, puis choisissez l'onglet **Origins**.

1. **Sélectionnez l'origine du point d'accès multirégional S3 à laquelle vous souhaitez ajouter l'OAC, puis choisissez Modifier.**

1. Pour **Accès d’origine**, sélectionnez **Paramètres de contrôle d’accès d’origine (recommandé)**.

1. Dans le menu déroulant **Origin access control** (Contrôle d'accès d'origine), choisissez l'OAC que vous souhaitez utiliser.

1. Sélectionnez **Enregistrer les modifications**.

La distribution commence à se déployer sur tous les emplacements CloudFront périphériques. Lorsqu'un emplacement périphérique reçoit la nouvelle configuration, il signe toutes les demandes qu'il envoie à l'origine du point d'accès multirégional S3.

------
#### [ CLI ]

Utilisez la commande **create-origin-access-control** :

```
aws cloudfront create-origin-access-control \
    --origin-access-control-config '{
        "Name": "my-s3-mrap-oac",
        "Description": "OAC for S3 Multi-Region Access Point",
        "SigningProtocol": "sigv4a",
        "SigningBehavior": "always",
        "OriginAccessControlOriginType": "s3mrap"
    }'
```

------
#### [ CloudFormation ]

Spécifiez les valeurs suivantes dans `OriginAccessControlConfig` :
+ `SigningProtocol`: `sigv4a`
+ `SigningBehavior`: `always``never`, ou `no-override`
+ `OriginAccessControlOriginType`: `s3mrap`

**Example CloudFormation modèle**  

```
Type: AWS::CloudFront::OriginAccessControl
Properties:
  OriginAccessControlConfig:
    Description: An optional description for the origin access control
    Name: my-s3-mrap-oac
    OriginAccessControlOriginType: s3mrap
    SigningBehavior: always
    SigningProtocol: sigv4a
```

------

## Comportement de signature
<a name="oac-signing-behavior-s3-mrap"></a>

Les options de comportement de signature pour les origines de points d'accès multirégionaux S3 sont les mêmes que pour les origines de compartiments Amazon S3 classiques. Pour plus d'informations, consultez [Paramètres avancés pour le contrôle d'accès à l'origine](private-content-restricting-access-to-s3.md#oac-advanced-settings-s3) la section *Restreindre l'accès à une origine Amazon S3*.

# Restriction de l’accès aux Application Load Balancers
<a name="restrict-access-to-load-balancer"></a>

Vous pouvez utiliser des équilibreurs de charge d'application internes et accessibles sur Internet avec Amazon. CloudFront Vous pouvez utiliser des équilibreurs de charge d'application internes dans des sous-réseaux privés CloudFront en utilisant des origines VPC. CloudFront Les origines VPC vous permettent de diffuser du contenu provenant d'applications hébergées dans des sous-réseaux VPC privés sans les exposer à l'Internet public. Pour de plus amples informations, veuillez consulter [Restriction de l’accès avec les origines de VPC](private-content-vpc-origins.md).

Si vous utilisez un Application Load Balancer connecté à Internet CloudFront avec, vous pouvez utiliser les mesures de sécurité suivantes pour empêcher les utilisateurs d'accéder directement à un Application Load Balancer et autoriser l'accès uniquement via. CloudFront

1. Configurez CloudFront pour ajouter un en-tête HTTP personnalisé aux demandes qu'il envoie à l'Application Load Balancer.

1. Configurez l'Application Load Balancer pour transférer uniquement les demandes contenant l'en-tête HTTP personnalisé.

1. Exigez l’utilisation de HTTPS pour renforcer la sécurité de cette solution.

CloudFront peut également contribuer à réduire la latence et même à absorber certaines attaques par déni de service (DDoS) distribué.

Si votre cas d'utilisation nécessite un double accès aux applications Web à la fois CloudFront depuis Application Load Balancer directement sur Internet, envisagez de diviser votre application APIs Web comme suit :
+ APIs cela doit passer CloudFront. Dans ce cas, envisagez d’utiliser un Application Load Balancer privé distinct comme origine.
+ APIs qui nécessitent un accès via Application Load Balancer. Dans ce cas, vous contournez CloudFront.

Dans le cas d'une application Web ou d'un autre contenu diffusé par un Application Load Balancer connecté à Internet CloudFront , Elastic Load Balancing peut également mettre en cache des objets et les diffuser directement aux utilisateurs (spectateurs), réduisant ainsi la charge sur votre Application Load Balancer. Un équilibreur de charge accessible sur Internet possède un nom DNS publiquement résolu et achemine les demandes des clients vers les cibles via Internet.

Pour plus d’informations, consultez les rubriques suivantes. Une fois ces étapes effectuées, les utilisateurs ne peuvent accéder à votre Application Load Balancer que via. CloudFront

**Topics**
+ [Configurer CloudFront pour ajouter un en-tête HTTP personnalisé aux demandes](#restrict-alb-add-custom-header)
+ [Configuration d’un Application Load Balancer pour transférer uniquement les demandes contenant un en-tête spécifique](#restrict-alb-route-based-on-header)
+ [(Facultatif) Améliorer la sécurité de cette solution](#restrict-alb-improve-security)
+ [(Facultatif) Limitez l'accès à l'origine en utilisant la liste de AWS préfixes -managed pour CloudFront](#limit-access-to-origin-using-aws-managed-prefixes)

## Configurer CloudFront pour ajouter un en-tête HTTP personnalisé aux demandes
<a name="restrict-alb-add-custom-header"></a>

Vous pouvez configurer CloudFront pour ajouter un en-tête HTTP personnalisé aux requêtes qu'il envoie à votre origine (dans ce cas, un Application Load Balancer).

**Important**  
Ce cas d'utilisation repose sur le fait de garder secrets le nom et la valeur de l'en-tête personnalisé. Si le nom et la valeur d'en-tête ne sont pas secrets, d'autres clients HTTP peuvent potentiellement les inclure dans les demandes qu'ils envoient directement à l'Application Load Balancer. Cela peut faire en sorte que l'Application Load Balancer se comporte comme si les demandes provenaient d'une CloudFront autre source. Pour éviter cela, gardez le nom et la valeur de l'en-tête personnalisé secrets.

Vous pouvez configurer CloudFront pour ajouter un en-tête HTTP personnalisé aux demandes d'origine à l'aide de la CloudFront console ou de l' CloudFront API. CloudFormation

**Pour ajouter un en-tête HTTP personnalisé (CloudFront console)**  
Dans la CloudFront console, utilisez le paramètre **Origin Custom Headers** dans les **paramètres d'Origin**. Entrez le **Nom de l’en-tête** et sa **Valeur**.  
En production, utilisez des noms et des valeurs d’en-têtes générés aléatoirement. Traitez les noms et les valeurs d’en-tête en tant qu’informations d’identification sécurisées, comme les noms d’utilisateur et les mots de passe.
Vous pouvez modifier le paramètre **Origin Custom Headers** lorsque vous créez ou modifiez l'origine d'une CloudFront distribution existante, et lorsque vous créez une nouvelle distribution. Pour plus d’informations, consultez [Mettre à jour une distribution](HowToUpdateDistribution.md) et [Créer une distribution](distribution-web-creating-console.md).

**Pour ajouter un en-tête HTTP personnalisé (CloudFormation)**  
Dans un CloudFormation modèle, utilisez la `OriginCustomHeaders` propriété, comme indiqué dans l'exemple suivant.  
Le nom et la valeur de l'en-tête dans cet exemple n’existent qu'à des fins de démonstration. En production, utilisez des valeurs générées aléatoirement. Traitez le nom et la valeur de l'en-tête en tant qu’informations d'identification sécurisées, comme un nom d'utilisateur et un mot de passe.

```
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'
```
Pour plus d'informations, consultez l'[origine](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) et les [OriginCustomHeader](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origincustomheader.html)propriétés dans le *guide de AWS CloudFormation l'utilisateur*.

**Pour ajouter un en-tête HTTP personnalisé (CloudFront API)**  
Dans l' CloudFront API, utilisez l'`CustomHeaders`objet qu'il contient`Origin`. Pour plus d'informations, consultez [CreateDistribution[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)la *référence des CloudFront API Amazon* et la documentation de votre SDK ou de tout autre client d'API.

Il existe certains noms d'en-tête que vous ne pouvez pas spécifier en tant qu'en-têtes personnalisés d'origine. Pour de plus amples informations, veuillez consulter [En-têtes personnalisés qui ne CloudFront peuvent pas être ajoutés aux demandes d'origine](add-origin-custom-headers.md#add-origin-custom-headers-denylist).

## Configuration d’un Application Load Balancer pour transférer uniquement les demandes contenant un en-tête spécifique
<a name="restrict-alb-route-based-on-header"></a>

Après avoir configuré CloudFront pour ajouter un en-tête HTTP personnalisé aux demandes qu'il envoie à votre Application Load Balancer (voir [la section précédente](#restrict-alb-add-custom-header)), vous pouvez configurer l'équilibreur de charge pour ne transférer que les demandes contenant cet en-tête personnalisé. Pour ce faire, ajoutez une nouvelle règle et modifiez la règle par défaut dans l’écouteur de votre équilibreur de charge.

**Conditions préalables**  
Pour utiliser les procédures suivantes, vous avez besoin d'un Application Load Balancer avec au moins un écouteur. Si vous n'en avez pas encore créé, reportez-vous à la section [Créer un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) dans le *guide de l'utilisateur pour les Application Load Balancers*.

Les procédures suivantes modifient un écouteur HTTPS. Vous pouvez utiliser le même processus pour modifier un écouteur HTTP.

**Pour mettre à jour les règles dans un écouteur d'Application Load Balancer**

1. Ajoutez une nouvelle règle. Suivez les instructions indiquées dans [Ajouter une règle](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule), avec les modifications suivantes :
   + Ajoutez la règle à l'équilibreur de charge qui est à l'origine de votre CloudFront distribution.
   + Pour **Ajouter une condition**, choisissez **En-tête HTTP**. Spécifiez le nom et la valeur de l'en-tête HTTP que vous avez ajoutés en tant qu'en-tête personnalisé d'origine CloudFront.
   + Pour **Ajouter une action**, choisissez **Transférer vers**. Choisissez le groupe cible dans lequel vous souhaitez transférer les demandes.

1. Modifiez la règle par défaut dans l’écouteur de votre équilibreur de charge. Suivez les instructions indiquées dans [Modifier une règle](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule), avec les modifications suivantes :
   + Modifiez la règle par défaut de l'équilibreur de charge qui est à l'origine de votre CloudFront distribution.
   + Supprimez l’action par défaut, puis pour **Ajouter une action**, choisissez **Renvoyer une réponse fixe**. 
   + Pour le **Code de réponse**, saisissez **403**.
   + Pour **Corps de réponse**, saisissez **Access denied**.

Après avoir terminé ces étapes, votre écouteur d’équilibreur de charge dispose de deux règles. Une règle transmet les demandes contenant l'en-tête HTTP (demandes provenant de CloudFront). L'autre règle envoie une réponse fixe à toutes les autres demandes (demandes qui ne proviennent pas de CloudFront).

Vous pouvez vérifier que la solution fonctionne en envoyant une demande à votre CloudFront distribution et une autre à votre Application Load Balancer. La demande de CloudFront renvoi de votre application Web ou de votre contenu, et celle envoyée directement à votre Application Load Balancer, renvoient une `403` réponse avec le message en texte brut. `Access denied`

## (Facultatif) Améliorer la sécurité de cette solution
<a name="restrict-alb-improve-security"></a>

Pour améliorer la sécurité de cette solution, vous pouvez configurer votre CloudFront distribution pour qu'elle utilise toujours le protocole HTTPS lorsque vous envoyez des demandes à votre Application Load Balancer. N'oubliez pas que cette solution ne fonctionne que si vous gardez le nom et la valeur de l'en-tête personnalisé secrètes. L'utilisation de HTTPS peut aider à empêcher un compte-écoute de découvrir le nom et la valeur de l'en-tête. Nous vous recommandons également de faire changer périodiquement le nom et la valeur de l'en-tête.

**Utiliser HTTPS pour les demandes d'origine**  
 CloudFront Pour configurer l'utilisation du protocole HTTPS pour les demandes d'origine, définissez le paramètre **Origin Protocol Policy** sur **HTTPS uniquement**. Ce paramètre est disponible dans la CloudFront console et dans l' CloudFront API. CloudFormation Pour de plus amples informations, veuillez consulter [Protocole (origines personnalisées uniquement)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy).

Ce qui suit s'applique également lorsque vous configurez CloudFront l'utilisation du protocole HTTPS pour les demandes d'origine :
+ Vous devez configurer CloudFront pour transmettre l'`Host`en-tête à l'origine avec la politique de demande d'origine. Vous pouvez utiliser la [politique de AllViewer gestion des demandes d'origine](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer).
+ Assurez-vous que votre Application Load Balancer dispose d’un écouteur HTTPS (comme indiqué dans [la section précédente](#restrict-alb-route-based-on-header)). Pour plus d'informations, consultez la section [Création d'un écouteur HTTPS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) dans le *guide de l’utilisateur pour les Application Load Balancers*. L'utilisation d'un écouteur HTTPS nécessite que vous disposiez d'un SSL/TLS certificat correspondant au nom de domaine acheminé vers votre Application Load Balancer.
+ Les certificats SSL/TLS pour ne CloudFront peuvent être demandés (ou importés) que `us-east-1` Région AWS dans AWS Certificate Manager (ACM). Comme il CloudFront s'agit d'un service mondial, il distribue automatiquement le certificat de la `us-east-1` région à toutes les régions associées à votre CloudFront distribution.
  + Par exemple, si vous avez un Application Load Balancer (ALB) dans la `ap-southeast-2` région, vous devez configurer les SSL/TLS certificats à la fois dans la `ap-southeast-2` région (pour utiliser le protocole HTTPS entre CloudFront et l'origine de l'ALB) et dans la `us-east-1` région (pour utiliser le protocole HTTPS entre les utilisateurs et). CloudFront Les deux certificats doivent correspondre au nom de domaine qui est acheminé vers votre Application Load Balancer. Pour de plus amples informations, veuillez consulter [Région AWS pour AWS Certificate Manager](cnames-and-https-requirements.md#https-requirements-aws-region).
+ Si les utilisateurs finaux (également appelés *spectateurs* ou *clients*) de votre application Web peuvent utiliser le protocole HTTPS, vous pouvez également le configurer de manière CloudFront à préférer (voire à exiger) des connexions HTTPS de la part des utilisateurs finaux. Pour ce faire, utilisez le paramètre **Stratégie de protocole d'utilisateur**. Vous pouvez le définir pour rediriger les utilisateurs finaux de HTTP vers HTTPS ou pour rejeter les demandes utilisant HTTP. Ce paramètre est disponible dans la CloudFront console et dans l' CloudFront API. CloudFormation Pour de plus amples informations, veuillez consulter [Viewer Protocol Policy](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy).

**Changer le nom et la valeur de l'en-tête**  
En plus d'utiliser HTTPS, nous vous recommandons également de changer périodiquement le nom et la valeur de l'en-tête. Les étapes de haut niveau pour ce faire sont les suivantes :

1. Configurez CloudFront pour ajouter un en-tête HTTP personnalisé supplémentaire aux demandes qu'il envoie à l'Application Load Balancer.

1. Mettez à jour la règle de l’écouteur de l'Application Load Balancer pour transférer les demandes contenant cet en-tête HTTP personnalisé supplémentaire.

1. Configurez CloudFront pour arrêter d'ajouter l'en-tête HTTP personnalisé d'origine aux demandes qu'il envoie à l'Application Load Balancer.

1. Mettez à jour la règle de l'écouteur de l'Application Load Balancer pour arrêter le transfert des demandes contenant l'en-tête HTTP personnalisé d'origine.

Pour plus d'informations sur la réalisation de ces étapes, consultez les sections précédentes.

## (Facultatif) Limitez l'accès à l'origine en utilisant la liste de AWS préfixes -managed pour CloudFront
<a name="limit-access-to-origin-using-aws-managed-prefixes"></a>

Pour restreindre davantage l'accès à votre Application Load Balancer, vous pouvez configurer le groupe de sécurité associé à l'Application Load Balancer afin qu'il n'accepte que le trafic CloudFront provenant de pays où le service utilise AWS une liste de préfixes gérée. Cela empêche le trafic qui ne CloudFront provient pas d'atteindre votre Application Load Balancer au niveau de la couche réseau (couche 3) ou de la couche transport (couche 4).

Pour plus d'informations, consultez le billet de CloudFront blog « [Limiter l'accès à vos origines à l'aide de la liste de préfixes AWS-managed » pour Amazon](https://aws.amazon.com//blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/).

# Restriction de la distribution géographique de votre contenu
<a name="georestrictions"></a>

Vous pouvez utiliser *des restrictions géographiques*, parfois appelées *blocage géographique*, pour empêcher les utilisateurs de zones géographiques spécifiques d'accéder au contenu que vous distribuez via une CloudFront distribution Amazon. Pour utiliser les restrictions géographiques, vous avez deux options :
+ Utilisez la fonction de restrictions CloudFront géographiques. Choisissez cette option pour limiter l’accès à tous les fichiers associés à une distribution et pour limiter l’accès au niveau du pays.
+ Utiliser un service de géolocalisation tiers. Utilisez cette option pour limiter l’accès à un sous-ensemble des fichiers associés à une distribution ou pour le limiter à un niveau de détail plus fin que le niveau pays.

**Topics**
+ [Utiliser les restrictions CloudFront géographiques](#georestrictions-cloudfront)
+ [Utilisation d’un service de géolocalisation tiers](#georestrictions-geolocation-service)

## Utiliser les restrictions CloudFront géographiques
<a name="georestrictions-cloudfront"></a>

Lorsqu'un utilisateur demande votre contenu, il diffuse CloudFront généralement le contenu demandé, quel que soit l'endroit où se trouve l'utilisateur. Si vous devez empêcher les utilisateurs de certains pays d'accéder à votre contenu, vous pouvez utiliser la fonctionnalité de restrictions CloudFront géographiques pour effectuer l'une des opérations suivantes :
+ Accorder à vos utilisateurs l’autorisation d’accéder à votre contenu seulement s’ils résident dans un des pays figurant dans la liste des pays autorisés.
+ Empêcher vos utilisateurs d’accéder à votre contenu s’ils résident dans un des pays interdits de la liste d’exclusion.

Par exemple, si une demande provient d'un pays dans lequel vous n'êtes pas autorisé à diffuser votre contenu, vous pouvez utiliser des restrictions CloudFront géographiques pour bloquer la demande.

**Note**  
CloudFront détermine l'emplacement de vos utilisateurs à l'aide d'une base de données tierce. La précision de la correspondance entre les adresses IP et les pays varie selon la région. Selon des tests récents, la précision globale est de 99,8 %. S'il n'est pas CloudFront possible de déterminer l'emplacement d'un utilisateur, CloudFront diffuse le contenu demandé par l'utilisateur.

Les restrictions géographiques fonctionnent comme suit :

1. Imaginons que vous n’ayez le droit de distribuer votre contenu qu’au Liechtenstein. Vous mettez à jour votre CloudFront distribution pour ajouter une liste d'autorisation contenant uniquement le Liechtenstein. (Vous pouvez, à la place, ajouter une liste d’exclusion contenant tous les pays, à l’exception du Liechtenstein.)

1. Un utilisateur à Monaco demande votre contenu, et le DNS achemine la demande vers un emplacement CloudFront périphérique à Milan, en Italie.

1. L’emplacement périphérique de Milan recherche votre distribution et détermine que l’utilisateur de Monaco n’a pas l’autorisation de télécharger votre contenu.

1. CloudFront renvoie un code d'état HTTP `403 (Forbidden)` à l'utilisateur.

Vous pouvez éventuellement configurer CloudFront pour renvoyer un message d'erreur personnalisé à l'utilisateur, et vous pouvez spécifier la durée pendant laquelle vous souhaitez CloudFront mettre en cache la réponse d'erreur pour le fichier demandé. La valeur par défaut est de 10 secondes. Pour de plus amples informations, veuillez consulter [Création d’une page d’erreur personnalisée pour des codes d’état HTTP spécifiques](creating-custom-error-pages.md).

Les restrictions géographiques s’appliquent à la totalité d’une distribution. Si vous devez appliquer une restriction à une partie de votre contenu et une restriction différente (ou aucune restriction) à une autre partie de votre contenu, vous devez créer des CloudFront distributions distinctes ou [utiliser un service de géolocalisation tiers](#georestrictions-geolocation-service).

Si vous activez [les journaux CloudFront standard](AccessLogs.md) (journaux d'accès), vous pouvez identifier les demandes CloudFront rejetées en recherchant les entrées de journal contenant la valeur de `sc-status` (le code d'état HTTP)`403`. Cependant, en utilisant uniquement les journaux standard, vous ne pouvez pas distinguer une demande CloudFront rejetée en fonction de l'emplacement de l'utilisateur d'une demande CloudFront rejetée parce que l'utilisateur n'était pas autorisé à accéder au fichier pour une autre raison. Si vous disposez d'un service de géolocalisation tiers tel que Digital Element or MaxMind, vous pouvez identifier l'emplacement des demandes en fonction de l'adresse IP figurant dans la colonne `c-ip` (IP du client) des journaux d'accès. Pour plus d'informations sur les journaux CloudFront standard, consultez[Journaux d'accès (journaux standard)](AccessLogs.md).

La procédure suivante explique comment utiliser la CloudFront console pour ajouter des restrictions géographiques à une distribution existante. Pour plus d’informations sur l’utilisation de la console pour créer une distribution, consultez [Créer une distribution](distribution-web-creating-console.md).<a name="restrictions-geo-procedure"></a>

**Pour ajouter des restrictions géographiques à votre distribution CloudFront Web (console)**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le panneau de navigation, choisissez **Distributions**, puis choisissez la distribution que vous souhaitez mettre à jour.

1. Choisissez l'onglet **Sécurité**, puis sélectionnez **Restrictions géographiques**.

1. Choisissez **Modifier**.

1. Sélectionnez **Allow list (Liste verte)** pour créer une liste des pays autorisés, ou **Liste rouge** pour créer une liste des pays interdits.

1. Ajoutez les pays souhaités à la liste, puis choisissez **Save changes (Enregistrer les modifications)**.

## Utilisation d’un service de géolocalisation tiers
<a name="georestrictions-geolocation-service"></a>

Grâce à la fonctionnalité de restrictions CloudFront géographiques, vous contrôlez la distribution de votre contenu au niveau du pays pour tous les fichiers que vous distribuez dans le cadre d'une distribution Web donnée. Si vous avez un cas d'utilisation pour des restrictions géographiques où les restrictions ne suivent pas les frontières nationales, ou si vous souhaitez restreindre l'accès à certains des fichiers que vous diffusez par une distribution donnée, vous pouvez combiner l'utilisation CloudFront d'un service de géolocalisation tiers. Vous pouvez ainsi contrôler l’accès à votre contenu en fonction non seulement du pays, mais aussi de la ville ou du code postal, voire de la latitude et de la longitude.

Lorsque vous utilisez un service de géolocalisation tiers, nous vous recommandons d'utiliser CloudFront SignedURLs, qui vous permet de spécifier une date et une heure d'expiration après lesquelles l'URL n'est plus valide. En outre, nous vous recommandons d'utiliser un compartiment Amazon S3 comme origine, car vous pouvez ensuite utiliser un [contrôle CloudFront d'accès à l'origine](private-content-restricting-access-to-s3.md) pour empêcher les utilisateurs d'accéder à votre contenu directement depuis l'origine. Pour plus d'informations sur le contrôle d'accès signé URLs et d'origine, consultez[Diffusez du contenu privé avec des cookies signés URLs et signés](PrivateContent.md).

Les étapes ci-après expliquent comment contrôler l’accès à vos fichiers à l’aide d’un service de géolocalisation tiers.

**Utiliser un service de géolocalisation tiers pour restreindre l'accès aux fichiers d'une distribution CloudFront**

1. Obtenez un compte avec un service de géolocalisation.

1. Chargez votre contenu sur un compartiment Amazon S3.

1. Configurez Amazon CloudFront et Amazon S3 pour diffuser du contenu privé. Pour de plus amples informations, veuillez consulter [Diffusez du contenu privé avec des cookies signés URLs et signés](PrivateContent.md).

1. Ecrivez votre application web pour exécuter ce qui suit :
   + Envoyez l’adresse IP de chaque demande utilisateur au service de géolocalisation.
   + Évaluez la valeur renvoyée par le service de géolocalisation pour déterminer si l'utilisateur se trouve dans un endroit où vous CloudFront souhaitez diffuser votre contenu.
   + Si vous souhaitez distribuer votre contenu à l'adresse de l'utilisateur, générez une URL signée pour votre CloudFront contenu. Si vous ne souhaitez pas distribuer de contenu à cet emplacement, renvoyez le code d'état HTTP `403 (Forbidden)` à l'utilisateur. Vous pouvez également configurer CloudFront pour renvoyer un message d'erreur personnalisé. Pour de plus amples informations, veuillez consulter [Création d’une page d’erreur personnalisée pour des codes d’état HTTP spécifiques](creating-custom-error-pages.md).

   Pour plus d’informations, consultez la documentation du service de géolocalisation que vous utilisez.

Vous pouvez utiliser une variable de serveur web pour obtenir les adresses IP des utilisateurs qui visitent votre site web. Notez les avertissements suivants :
+ Si votre serveur web n’est pas connecté à Internet via un équilibreur de charge, vous pouvez utiliser une variable de serveur web pour obtenir l’adresse IP distante. Toutefois, cette adresse IP n’est pas toujours l’adresse IP de l’utilisateur. Il peut également s’agir de l’adresse IP d’un serveur proxy, selon la façon dont l’utilisateur est connecté à Internet.
+ Si votre serveur web est connecté à Internet via un équilibreur de charge, une variable de serveur web peut contenir l’adresse IP de l’équilibreur de charge, et non celle de l’utilisateur. Dans cette configuration, nous vous recommandons d’utiliser la dernière adresse IP de l’en-tête HTTP `X-Forwarded-For`. Cet en-tête contient généralement plusieurs adresses IP, la plupart concernant des proxys ou des équilibreurs de charge. La dernière adresse IP de la liste est celle qui est très vraisemblablement associée à l’emplacement géographique de l’utilisateur.

Si votre serveur web n’est pas connecté à un équilibreur de charge, nous vous recommandons d’utiliser les variables de serveur web à la place de l’en-tête `X-Forwarded-For` pour éviter l’usurpation d’adresse IP.

# Utilisation du chiffrement au niveau du champ pour faciliter la protection des données sensibles
<a name="field-level-encryption"></a>

Amazon CloudFront vous permet de sécuriser les end-to-end connexions aux serveurs d'origine en utilisant le protocole HTTPS. Le chiffrement au niveau du champ ajoute une couche de sécurité, qui vous permet de protéger des données spécifiques tout au long du traitement du système, pour que seules certaines applications puissent les voir.

Grâce au chiffrement au niveau du champ, vous pouvez permettre à vos utilisateurs de charger de manière sécurisée des informations sensibles envoyées à vos serveurs web. Les informations sensibles fournies par vos utilisateurs sont chiffrées à la périphérie, à proximité de l’utilisateur, et restent chiffrées tout le long de votre pile d’applications. Ce chiffrement garantit que seules les applications qui ont besoin des données (et qui disposent des informations d’identification pour les déchiffrer) sont en mesure de le faire.

Pour utiliser le chiffrement au niveau des champs, lorsque vous configurez votre CloudFront distribution, spécifiez l'ensemble de champs que vous souhaitez chiffrer dans les requêtes POST, ainsi que la clé publique à utiliser pour les chiffrer. Vous pouvez chiffrer jusqu’à 10 champs de données dans une requête. (Vous ne pouvez pas chiffrer toutes les données dans une requête avec chiffrement au niveau du champ ; vous devez spécifier des champs individuels à chiffrer).

Lorsque la requête HTTPS avec chiffrement au niveau du champ est réacheminée vers l’origine, et que la requête est acheminée dans votre application ou sous-système d’origine, les données sensibles sont toujours chiffrées, ce qui réduit le risque de violation ou de perte accidentelle des données sensibles. Les composants devant accéder aux données sensibles pour des raisons professionnelles, comme un système de traitement de paiement qui aurait besoin d’accéder à un numéro de crédit, peuvent utiliser la clé privée adéquate pour déchiffrer les données et y accéder.

**Note**  
Pour utiliser le chiffrement au niveau du champ, votre origine doit prendre en charge l’encodage segmenté.

![\[Chiffrement au niveau du champ dans CloudFront\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/fleoverview.png)


CloudFront le chiffrement au niveau du champ utilise le chiffrement asymétrique, également appelé chiffrement à clé publique. Vous fournissez une clé publique à CloudFront, et toutes les données sensibles que vous spécifiez sont cryptées automatiquement. La clé que vous fournissez CloudFront ne peut pas être utilisée pour déchiffrer les valeurs chiffrées ; seule votre clé privée peut le faire.

![\[Chiffrer uniquement des données sensibles\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/encryptedfields.png)


**Topics**
+ [Présentation du chiffrement au niveau du champ](#field-level-encryption-overview)
+ [Configuration du chiffrement au niveau du champ](#field-level-encryption-setting-up)
+ [Déchiffrage de champs de données à votre origine](#field-level-encryption-decrypt)

## Présentation du chiffrement au niveau du champ
<a name="field-level-encryption-overview"></a>

Les étapes suivantes présentent la configuration de chiffrement au niveau du champ. Pour connaître les étapes spécifiques, consultez [Configuration du chiffrement au niveau du champ](#field-level-encryption-setting-up).

1. **Obtenez une paire de clés publique/clé privée.** Vous devez obtenir et ajouter la clé publique avant de commencer à configurer le chiffrement au niveau du champ dans CloudFront

1. **Créez un profil de chiffrement au niveau du champs.** Les profils de chiffrement au niveau des champs, que vous créez dans CloudFront, définissent les champs que vous souhaitez chiffrer.

1. **Créez une configuration de chiffrement au niveau du champ.** Une configuration spécifie les profils à utiliser selon le type de contenu de la requête ou un argument de requête pour chiffrer des champs de données spécifiques. Vous pouvez également choisir les options de comportement de transfert de demande que vous souhaitées pour différents scénarios. Par exemple, vous pouvez définir le comportement lorsque le nom de profil spécifié par l'argument de requête dans une URL de demande n'existe pas dans CloudFront.

1. **Lien vers un comportement de cache.** Associez la configuration à un comportement de cache pour une distribution, pour spécifier quand CloudFront doit chiffrer des données.

## Configuration du chiffrement au niveau du champ
<a name="field-level-encryption-setting-up"></a>

Suivez ces étapes pour commencer à utiliser le chiffrement au niveau du champ. Pour en savoir plus sur les quotas (auparavant appelés limites) liés au chiffrement au niveau du champ, consultez [Quotas](cloudfront-limits.md).
+ [Étape 1 : créer une paire de clés RSA](#field-level-encryption-setting-up-step1)
+ [Étape 2 : Ajoutez votre clé publique à CloudFront](#field-level-encryption-setting-up-step2)
+ [Étape 3 : créer un profil de chiffrement au niveau du champ](#field-level-encryption-setting-up-step3)
+ [Étape 4 : créer une configuration](#field-level-encryption-setting-up-step4)
+ [Étape 5 : ajouter une configuration à un comportement de cache](#field-level-encryption-setting-up-step5)

### Étape 1 : créer une paire de clés RSA
<a name="field-level-encryption-setting-up-step1"></a>

Pour commencer, vous devez créer une paire de clés RSA qui inclut une clé publique et une clé privée. La clé publique permet CloudFront de chiffrer les données, et la clé privée permet aux composants de votre origine de déchiffrer les champs qui ont été chiffrés. Vous pouvez utiliser OpenSSL ou un autre outil pour créer une paire de clés. La taille de la clé doit être de 2 048 bits.

Par exemple, si vous utilisez OpenSSL, vous pouvez exécuter la commande suivante pour générer une paire de clés avec une longueur de 2048 bits et l’enregistrer dans le fichier `private_key.pem`:

```
openssl genrsa -out private_key.pem 2048
```

Le fichier obtenu contient à la fois la clé publique et la clé privée. Pour extraire la clé publique de ce fichier, exécutez la commande suivante :

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

Le fichier de clé publique (`public_key.pem`) contient la valeur de clé codée que vous collez à l’étape suivante.

### Étape 2 : Ajoutez votre clé publique à CloudFront
<a name="field-level-encryption-setting-up-step2"></a>

Après avoir obtenu votre paire de clés RSA, ajoutez votre clé publique à CloudFront.<a name="field-level-encryption-setting-up-step2-procedure"></a>

**Pour ajouter votre clé publique à CloudFront (console)**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans le volet de navigation, sélectionnez **Clé publique**.

1. Choisissez **Ajouter une clé publique**.

1. Dans **Nom de clé**, tapez un nom unique pour la clé. Le nom ne peut pas contenir d’espaces et ne peut contenir que des caractères alphanumériques, des traits de soulignement (\$1) et des tirets (-). Le nombre maximum de caractères est 128.

1. Pour **Key value (Valeur de clé)**, collez la valeur de clé encodée pour votre clé publique, y compris les lignes `-----BEGIN PUBLIC KEY-----` et `-----END PUBLIC KEY-----`.

1. Pour **Commentaire**, ajoutez un commentaire facultatif. Par exemple, vous pouvez inclure la date d’expiration pour la clé publique.

1. Choisissez **Ajouter**.

Vous pouvez ajouter d'autres clés à utiliser CloudFront en répétant les étapes de la procédure.

### Étape 3 : créer un profil de chiffrement au niveau du champ
<a name="field-level-encryption-setting-up-step3"></a>

Après avoir ajouté au moins une clé publique CloudFront, créez un profil CloudFront indiquant les champs à chiffrer.<a name="field-level-encryption-setting-up-step3-procedure"></a>

**Créer un profil de chiffrement au niveau du champ (console)**

1. Dans le volet de navigation, sélectionnez **Chiffrement au niveau du champ**.

1. Choisissez **Créer un profil**.

1. Remplissez les champs suivants :  
**Profile name (Nom du profil)**  
Saisissez un nom unique pour le profil. Le nom ne peut pas contenir d’espaces et ne peut contenir que des caractères alphanumériques, des traits de soulignement (\$1) et des tirets (-). Le nombre maximum de caractères est 128.  
**Nom de clé publique**  
Dans la liste déroulante, choisissez le nom d'une clé publique que vous avez ajoutée CloudFront à l'étape 2. CloudFront utilise la clé pour chiffrer les champs que vous spécifiez dans ce profil.  
**Nom du fournisseur**  
Saisissez une phrase facilitant l’identification de la clé, comme le fournisseur de la paire de clés. Ces informations, tout comme la clé privée, sont nécessaires lors du déchiffrement des champs de données par les applications. Le nom du fournisseur ne peut pas contenir d’espaces et ne peut contenir que des caractères alphanumériques, des deux-points (:), des traits de soulignement (\$1) et des tirets (-). Le nombre maximum de caractères est 128.  
**Modèle de nom de champ**  
Saisissez les noms des champs de données, ou des modèles identifiant des noms de champs de données dans la requête, que vous voulez que CloudFront chiffre. Sélectionnez l’option \$1 pour ajouter tous les champs que vous souhaitez chiffrer avec cette clé.  
Pour le modèle de nom de champ, vous pouvez taper le nom complet du champ de données DateOfBirth, par exemple, ou simplement la première partie du nom avec un caractère générique (\$1), comme CreditCard \$1. Le modèle de champ de nom ne peut contenir que des caractères alphanumériques, des crochets ([ et ]), des points (.), des traits de soulignement (\$1) et des tirets (-) et en option, le métacaractère (\$1).  
N’utilisez pas de caractères qui se chevauchent pour différents modèles de nom de champ. Par exemple, si vous avez un modèle de nom de champ ABC\$1, vous ne pouvez pas ajouter un autre modèle de nom de champ AB\$1. De plus, les noms de champ sont sensibles à la casse et le nombre maximum de caractères ne doit pas dépasser 128.  
**Commentaire**  
(Facultatif) Saisissez un commentaire sur ce profil. Le nombre maximum de caractères à utiliser est de 128.

1. Une fois les champs remplis, choisissez **Créer un profil**.

1. Pour ajouter d’autres profils, Sélectionnez **Ajouter un profil**.

### Étape 4 : créer une configuration
<a name="field-level-encryption-setting-up-step4"></a>

Après avoir créé un ou plusieurs profils de chiffrement au niveau des champs, créez une configuration qui spécifie le type de contenu de la demande qui inclut les données à chiffrer, le profil à utiliser pour le chiffrement et les autres options qui spécifient la manière dont vous CloudFront souhaitez gérer le chiffrement.

Par exemple, lorsque vous ne CloudFront pouvez pas chiffrer les données, vous pouvez spécifier si vous CloudFront devez bloquer ou transférer une demande à votre origine dans les scénarios suivants :
+ **Lorsque le type de contenu d'une demande ne figure pas dans une configuration** : si vous n'avez pas ajouté de type de contenu à une configuration, vous pouvez spécifier si vous CloudFront devez transmettre la demande contenant ce type de contenu à l'origine sans chiffrer les champs de données, ou bloquer la demande et renvoyer une erreur.
**Note**  
Si vous ajoutez un type de contenu à une configuration mais que vous n'avez pas spécifié de profil à utiliser avec ce type de contenu, CloudFront transférez toujours les demandes contenant ce type de contenu à l'origine.
+ **Lorsque le nom de profil fourni dans un argument de requête est inconnu** : lorsque vous spécifiez à l'argument de `fle-profile` requête un nom de profil qui n'existe pas pour votre distribution, vous pouvez spécifier si vous CloudFront devez envoyer la demande à l'origine sans chiffrer les champs de données ou bloquer la demande et renvoyer une erreur.

Dans une configuration, vous pouvez également spécifier si fournir un profil en tant qu’argument de requête dans une URL substitue un profil que vous avez mappé vers le type de contenu de cette requête. Par défaut, CloudFront utilise le profil que vous avez mappé à un type de contenu, si vous en spécifiez un. Cela vous permet d’avoir un profil utilisé par défaut, mais de décider, pour certaines requêtes, d’appliquer un autre profil.

Donc, par exemple, vous pouvez spécifier (dans votre configuration) **SampleProfile** comme profil d’argument de requête à utiliser. Vous pouvez ensuite utiliser l'URL à la `https://d1234.cloudfront.net?fle-profile=SampleProfile` place de`https://d1234.cloudfront.net`, **SampleProfile** pour CloudFront utiliser cette demande, au lieu du profil que vous avez configuré pour le type de contenu de la demande.

Vous pouvez créer jusqu’à 10 configurations pour un seul compte, puis associer l’une des configurations au comportement de cache d’une distribution pour le compte.<a name="field-level-encryption-setting-up-step4-procedure"></a>

**Créer une configuration de chiffrement au niveau du champ (console)**

1. Sur la page **Chiffrement au niveau du champ**, sélectionnez **Créer la configuration**.

   Remarque : Si vous n’avez pas créé de profil, vous ne verrez pas l’option permettant de créer une configuration.

1. Renseignez les champs suivants pour spécifier le profil à utiliser. (Certains champs ne peuvent être modifiés).  
**Type de contenu (non modifiable)**  
Le type de contenu est défini comme `application/x-www-form-urlencoded` et ne peut être modifié.  
**ID de profil par défaut (facultatif)**  
Dans la liste déroulante, sélectionnez le profil que vous souhaitez mapper au type de contenu dans le champ **Type de contenu**.  
**Format de contenu (non modifiable)**  
Le format du contenu est défini comme `URLencoded` et ne peut être modifié.

1. Si vous souhaitez modifier le comportement CloudFront par défaut des options suivantes, cochez la case appropriée.  
**Réacheminer une requête vers l’origine lorsque le type de contenu de a requête n’est pas configuré**  
Sélectionnez la case à cocher pour permettre à la requête d’atteindre votre origine *si vous n’avez pas spécifié de profil à utiliser pour le type de contenu de la requête*.  
**Substituer le profil d’un type de contenu avec un argument de requête fourni**  
Sélectionnez la case à cocher pour autoriser un profil fourni dans un argument de requête à *substituer le profil que vous avez spécifié pour un type de contenu*.

1. Si vous sélectionnez la case à cocher pour autoriser un argument de requête à remplacer le profil par défaut, vous devez renseigner les champs supplémentaires suivants pour la configuration. Vous pouvez créer jusqu’à cinq de ces mappages d’argument de requête à utiliser avec les requêtes.  
**Argument de requête**  
Tapez la valeur que vous souhaitez inclure dans URLs l'argument de `fle-profile` requête. Cette valeur indique à CloudFront d'utiliser l'ID de profil (que vous indiquez dans le champ suivant) associée à cet argument de requête de chiffrement au niveau du champ pour cette requête.  
Le nombre maximum de caractères à utiliser est de 128. La valeur ne doit pas contenir d’espaces et ne comporter que des caractères alphanumériques ou les caractères suivants : tiret (-), point (.), trait de soulignement (\$1), astérisque (\$1), signe plus (\$1), pourcentage (%).  
**ID de profil**  
Dans la liste déroulante, sélectionnez le profil à associer à la valeur que vous avez saisie pour **Argument de requête**.  
**Réacheminer une requête vers l’origine lorsque le profil spécifié dans un argument de requête n’existe pas**  
Sélectionnez la case à cocher pour permettre à la demande d'être acheminée vers votre origine *si le profil spécifié dans un argument de requête n'est pas défini dans CloudFront*.

### Étape 5 : ajouter une configuration à un comportement de cache
<a name="field-level-encryption-setting-up-step5"></a>

Pour utiliser le chiffrement au niveau du champ, associez une configuration à un comportement de cache pour une distribution en ajoutant l’ID de configuration en tant que valeur pour votre distribution.

**Important**  
Pour associer une configuration de chiffrement au niveau du champ à un comportement de cache, la distribution doit être configurée pour toujours utiliser HTTPS et accepter des demandes HTTP `POST` et `PUT` des utilisateurs. Ainsi, les conditions suivantes doivent être vraies :  
La **Viewer Protocol Policy (Politique de protocole d’utilisateur)** du comportement de cache doit être définie sur **Redirect HTTP vers HTTPS (Rediriger HTTP vers HTTPS)** ou **HTTPS Only (HTTPS uniquement)**. (Dans CloudFormation ou dans l' CloudFront API, `ViewerProtocolPolicy` doit être défini sur `redirect-to-https` ou`https-only`.)
Les **Allowed HTTP Methods (Méthodes HTTP autorisées)** du comportement du cache doivent être définies sur **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. (Dans CloudFormation ou dans l' CloudFront API, `AllowedMethods` il doit être défini sur `GET``HEAD`,`OPTIONS`,`PUT`,`POST`,`PATCH`,`DELETE`. Ils peuvent être spécifiés dans n'importe quel ordre.)
La **Stratégie de protocole d’origine** du paramètre d’origine doit être définie sur **Identique à l’utilisateur** ou **HTTPS uniquement**. (Dans CloudFormation ou dans l' CloudFront API, `OriginProtocolPolicy` doit être défini sur `match-viewer` ou`https-only`.)

Pour de plus amples informations, veuillez consulter [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).

## Déchiffrage de champs de données à votre origine
<a name="field-level-encryption-decrypt"></a>

CloudFront chiffre les champs de données en utilisant le [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html). Les données restent chiffrées dans l’ensemble de votre pile d’applications et ne sont accessibles qu’aux applications possédant les informations d’identification pour les déchiffrer.

Après le chiffrement, le texte chiffré est encodé en base64. Lorsque vos applications déchiffrent le texte à l’origine, elles doivent d’abord décoder le texte chiffré, puis utiliser le kit SDK de chiffrement AWS pour déchiffrer les données.

L’exemple de code suivant illustre la façon dont les applications peuvent déchiffrer des données à votre origine. Remarques : 
+ Pour simplifier l’exemple, cet exemple charge des clés publiques et privées (au format DER) à partir de fichiers du répertoire de travail. En pratique, vous devez stocker la clé privée à un emplacement sécurisé hors ligne, par exemple un module de sécurité matérielle hors ligne, et distribuer la clé publique à votre équipe de développement.
+ CloudFront utilise des informations spécifiques lors du chiffrement des données, et le même ensemble de paramètres doit être utilisé à l'origine pour les déchiffrer. Les paramètres CloudFront utilisés lors de l'initialisation MasterKey sont les suivants :
  + PROVIDER\$1NAME : Vous avez indiqué cette valeur lors de la création d’un profil de chiffrement au niveau du profil. Utilisez la même valeur ici.
  + KEY\$1NAME : vous avez créé un nom pour votre clé publique lorsque vous l'avez téléchargée CloudFront, puis vous l'avez spécifié dans le profil. Utilisez la même valeur ici.
  + ALGORITHME : CloudFront utilisé `RSA/ECB/OAEPWithSHA-256AndMGF1Padding` comme algorithme de chiffrement, vous devez donc utiliser le même algorithme pour déchiffrer les données.
+ Si vous exécutez l’exemple de programme suivant avec le texte chiffré en tant qu’entrée, les données déchiffrées constituent une sortie de votre console. Pour plus d'informations, consultez l'[exemple de code Java](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html) dans le SDK de AWS chiffrement.

### Exemple de code
<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));
    }
}
```