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.
# Restreindre l'accès à un AWS Lambda Origine de la fonction Web
Vous pouvez utiliser le contrôle d'accès à l'origine (OAC) pour restreindre l'accès à l'origine d'une fonction AWS Lambda Web. Une fonction Web Lambda fournit son propre point de terminaison HTTPS régional ou mondial, que vous utilisez comme domaine d'origine pour votre CloudFront distribution. Pour plus d'informations sur les fonctions Web Lambda, consultez la section [Fonctions AWS Lambda Web](https://docs.aws.amazon.com/lambda/latest/dg/web-functions.html) du manuel du *AWS Lambda développeur*.
**Note**
L'OAC avec Lambda Web Functions n'est pas pris en charge pour les points de terminaison globaux qui incluent des régions optionnelles. Si le point de terminaison achemine une demande vers une région optionnelle, il CloudFront ne peut pas signer la demande pour cette région. L'origine renvoie alors une erreur HTTP 403 (Interdit). Toutes les régions associées au point de terminaison global doivent être des régions activées par défaut.
Pour plus d'informations sur l'utilisation d'OAC avec l'origine de l'URL d'une fonction Lambda, consultez. [Restreindre l'accès à un AWS Lambda origine de l'URL de la fonction](private-content-restricting-access-to-lambda.md)
## Conditions préalables
Avant de créer et de configurer OAC, vous devez disposer d'une CloudFront distribution dont l'origine est une fonction Web Lambda. Le nom de domaine d'origine est le nom d'hôte du point de terminaison de la fonction Web Lambda. CloudFront identifie le [type de point de terminaison](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-endpoints.html#web-functions-endpoint-types) à partir du nom d'hôte :
+ Point de terminaison régional (`HomeRegion`et types de `PerRegion` points de terminaison) : le nom d'hôte se termine par `.lambda-web.{{AWS-Region}}.on.aws`
+ Point de terminaison global (type de `MultiRegion` point de terminaison) : le nom d'hôte se termine par `.lambda-web.global.on.aws`
Votre configuration doit également répondre aux exigences suivantes :
+ Type d'**authentification du point de terminaison : le type** d'authentification du point de terminaison doit être. `IamAuth` Avec`IamAuth`, le point de terminaison utilise Gestion des identités et des accès AWS (IAM) pour authentifier et autoriser les demandes. Pour les demandes provenant de CloudFront, l'autorisation est basée sur la politique basée sur les ressources de la fonction Web Lambda. CloudFront signe les demandes au nom du spectateur, et le point de terminaison valide la signature. Pour plus d'informations, consultez la section sur [CloudFront l'intégration](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-endpoint-access-control.html#web-functions-endpoint-access-control-cloudfront) dans le *guide du AWS Lambda développeur*.
+ **Politique de cache** — Si votre fonction Web Lambda utilise l'`Authorization`en-tête du visualiseur, vous devez ajouter l'en-tête à la politique de [cache](controlling-the-cache-key.md). Cette exigence s'applique à tous les comportements de cache qui utilisent l'origine. Pour les `HEAD` demandes `GET` et, CloudFront supprime l'`Authorization`en-tête avant de transférer la demande, sauf si l'en-tête figure dans la politique de cache. Pour plus d’informations, consultez [En-têtes et CloudFront comportement des requêtes HTTP (origines personnalisées et Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
+ **Politique de demande d'origine** : utilisez une politique de demande d'origine qui exclut l'`Host`en-tête du téléspectateur. Les points de terminaison Lambda Web Function s'attendent à ce que l'`Host`en-tête contienne le nom de domaine d'origine, et non le nom de domaine de la distribution. CloudFront Si l'`Host`en-tête contient le nom de domaine de la distribution, le point de terminaison renvoie une erreur HTTP 404 (introuvable). Si vous utilisez une politique de demande d'origine gérée, utilisez`AllViewerExceptHostHeader`, not`AllViewer`. Pour plus d’informations, consultez [AllViewerExceptHostHeader](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer-except-host-header).
**Note**
Les déclencheurs de demande d'origine et de réponse d'origine Lambda @Edge ne sont pas pris en charge dans les comportements de cache qui utilisent une origine de fonction Web Lambda avec OAC. Cela s'applique aux points de terminaison régionaux et mondiaux, ainsi qu'aux origines accessibles directement ou via un groupe d'origine. CloudFront rejette une configuration de distribution qui contient les deux.
## Accorder CloudFront l'autorisation d'accéder à la fonction Web Lambda
Attachez une politique basée sur les ressources à la fonction Web Lambda qui permet au principal du CloudFront service (`cloudfront.amazonaws.com`) d'appeler le point de terminaison. L'action IAM pour appeler un point de terminaison est. `lambda:InvokeWebFunctionEndpoint` La politique est attachée à la fonction Web Lambda, mais chaque instruction peut l'étendre `Resource` à un ARN de point de terminaison spécifique. Utilisez un `Condition` élément pour autoriser l'accès CloudFront au point de terminaison uniquement lorsque la demande provient de la CloudFront distribution qui contient l'origine.
**Example Resource-based politique de l' CloudFront OAC**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontOACAccess",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "lambda:InvokeWebFunctionEndpoint",
"Resource": "arn:aws:lambda:us-east-1:{{111122223333}}:web-function/{{my-function}}/endpoint/{{prod}}",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:cloudfront::{{111122223333}}:distribution/{{EDFDVBD6EXAMPLE}}"
}
}
}
]
}
```
Pour associer la politique basée sur les ressources, utilisez la **put-resource-policy** commande avec la fonction ARN (et non un *ARN* de point de terminaison) :
```
aws lambda-web put-resource-policy \
--resource-arn "arn:aws:lambda:us-east-1:{{111122223333}}:web-function/{{my-function}}" \
--policy file://policy.json \
--region us-east-1
```
Vous pouvez revoir ou supprimer la politique à l'aide des **delete-resource-policy** commandes **get-resource-policy** et.
**Note**
Pour les points de terminaison qui s'étendent sur plusieurs régions, Lambda réplique les modifications de politique dans toutes les régions qui desservent le point de terminaison. Une politique nouvelle ou mise à jour peut prendre peu de temps pour entrer en vigueur dans chaque région. Pour plus d'informations, consultez [la section Réplication et cohérence éventuelle](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-permissions.html#web-functions-permissions-resource-policy-replication) dans le *Guide du AWS Lambda développeur*.
## Création du contrôle d’accès d’origine
Pour créer un contrôle d'accès à l'origine (OAC), vous pouvez utiliser le Console de gestion AWS 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 Console de gestion AWS 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. Choisissez **Lambda** dans le menu déroulant **Type d'origine**. Ce type d'origine est utilisé à la fois pour les URL des fonctions Lambda et pour les fonctions Web Lambda.
1. Si votre origine est un point de terminaison global (le nom d'hôte se termine par`.lambda-web.global.on.aws`), sélectionnez l'option **Utiliser le protocole de signature SIGv4a**. Pour un point de terminaison régional (le nom d'hôte se termine par`.lambda-web.{{AWS-Region}}.on.aws`), laissez cette option désactivée.
1. Pour **Comportement de signature**, choisissez **Toujours signer, préserver l'autorisation du spectateur**. Cette option apparaît sous **Signer les demandes (recommandé)**, qui est sélectionnée par défaut. Les origines des fonctions Web Lambda ne prennent en charge que ce comportement de signature. Pour plus d’informations, consultez [Comportement de signature](#oac-signing-behavior-lambda-web).
1. Cliquez sur **Créer**.
**Pour ajouter un contrôle d'accès à l'origine à une origine de fonction Web 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 avec une origine de fonction Web Lambda à laquelle vous souhaitez ajouter l'OAC, puis cliquez sur l'onglet Origins.**
1. **Sélectionnez l'origine de la fonction Web Lambda à 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. Cliquez sur **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 de la fonction Web Lambda.
------
#### [ CLI ]
Utilisez la commande **create-origin-access-control**. Pour un point de terminaison régional (le nom d'hôte se termine par`.lambda-web.{{AWS-Region}}.on.aws`), utilisez le protocole de `sigv4` signature :
```
aws cloudfront create-origin-access-control \
--origin-access-control-config '{
"Name": "my-lambda-web-oac",
"Description": "OAC for Lambda Web Function origin",
"SigningProtocol": "sigv4",
"SigningBehavior": "always-amz-auth",
"OriginAccessControlOriginType": "lambda"
}'
```
Pour un point de terminaison global (le nom d'hôte se termine par`.lambda-web.global.on.aws`), utilisez le protocole de `sigv4a` signature :
```
aws cloudfront create-origin-access-control \
--origin-access-control-config '{
"Name": "my-lambda-web-global-oac",
"Description": "OAC for global Lambda Web Function origin",
"SigningProtocol": "sigv4a",
"SigningBehavior": "always-amz-auth",
"OriginAccessControlOriginType": "lambda"
}'
```
------
#### [ CloudFormation ]
Spécifiez les valeurs suivantes dans `OriginAccessControlConfig` :
+ `SigningProtocol`: `sigv4` (paramètre régional) ou `sigv4a` (paramètre global)
+ `SigningBehavior`: `always-amz-auth`
+ `OriginAccessControlOriginType`: `lambda`
**Example CloudFormation modèle**
```
Type: AWS::CloudFront::OriginAccessControl
Properties:
OriginAccessControlConfig:
Description: An optional description for the origin access control
Name: my-lambda-web-oac
OriginAccessControlOriginType: lambda
SigningBehavior: always-amz-auth
SigningProtocol: sigv4a
```
Pour plus d'informations, voir [AWS::CloudFront: : OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) dans le *guide de AWS CloudFormation l'utilisateur*.
------
L'OAC ne prend effet pour chaque demande qu'une fois le déploiement de la distribution terminé. Pour un point de terminaison qui couvre plusieurs régions, la politique basée sur les ressources que vous avez attachée précédemment doit également terminer sa réplication dans chaque région qui dessert le point de terminaison. Tant que les deux ne sont pas terminées, certaines demandes peuvent recevoir une réponse HTTP 403 transitoire de la part de l'origine. Ces erreurs sont résolues automatiquement une fois le déploiement de la distribution terminé et la réplication de la politique terminée.
## Comportement de signature
Les origines des fonctions Web Lambda ne prennent en charge que le comportement de `always-amz-auth` signature (**toujours signer, préserver l'autorisation du lecteur** dans la console). CloudFront signe toujours toutes les demandes qu'il envoie à la fonction Web Lambda, mais il ne remplace pas l'`Authorization`en-tête de la demande du visualiseur. Il CloudFront ajoute plutôt sa signature dans un CloudFront en-tête dédié et transmet l'`Authorization`en-tête du spectateur à l'origine sans modification. Avec ce comportement, votre fonction Web Lambda peut recevoir l'`Authorization`en-tête original du lecteur (par exemple, pour effectuer sa propre authentification ou autorisation). CloudFront signe toujours chaque demande qu'il envoie à l'origine. Pour transférer l'`Authorization`en-tête du visualiseur, vous devez l'ajouter à une [politique de cache](controlling-the-cache-key.md) pour chaque comportement de cache utilisant l'origine.
Les autres comportements de signature (`always``never`, et`no-override`) ne sont pas pris en charge pour les origines des fonctions Web Lambda. Le comportement de `always-amz-auth` signature n'est pris en charge pour aucun autre type d'origine, y compris les origines d'URL de la fonction Lambda.
For `PUT``POST`, et `PATCH` requests, CloudFront signe la demande d'origine avec une charge utile non signée ()`UNSIGNED-PAYLOAD`. Le corps de la demande n'est pas couvert par la CloudFront signature. La signature couvre toujours la méthode de demande, le chemin, la chaîne de requête et les en-têtes qui identifient votre distribution. Le point de terminaison peut donc vérifier que chaque demande provient CloudFront de votre distribution avant d'appeler votre fonction Web Lambda. Le corps de la demande est protégé en transit par la connexion HTTPS entre CloudFront et le point de terminaison. Il n'est pas nécessaire d'inclure un `x-amz-content-sha256` en-tête dans les demandes adressées à CloudFront. Si un utilisateur en envoie une, il CloudFront ne l'utilise pas lors de la signature de la demande d'origine.