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

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 à partir du nom d'hôte :

• Point de terminaison régional (HomeRegionet 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 AvecIamAuth, 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 dans le guide du AWS Lambda développeur.

• Politique de cache — Si votre fonction Web Lambda utilise l'Authorizationen-tête du visualiseur, vous devez ajouter l'en-tête à la politique de cache. Cette exigence s'applique à tous les comportements de cache qui utilisent l'origine. Pour les HEAD demandes GET et, CloudFront supprime l'Authorizationen-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).

• Politique de demande d'origine : utilisez une politique de demande d'origine qui exclut l'Hosten-tête du téléspectateur. Les points de terminaison Lambda Web Function s'attendent à ce que l'Hosten-tête contienne le nom de domaine d'origine, et non le nom de domaine de la distribution. CloudFront Si l'Hosten-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, utilisezAllViewerExceptHostHeader, notAllViewer. Pour plus d’informations, consultez AllViewerExceptHostHeader.

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.

Exemple 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 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'adressehttps://console.aws.amazon.com/cloudfront/v4/home.

2. Dans le panneau de navigation de gauche, choisissez Accès à l'origine.

3. Choisissez Créer un paramètre de contrôle.

4. 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.

   2. 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.

   3. 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.

   4. 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.

5. 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'adressehttps://console.aws.amazon.com/cloudfront/v4/home.

2. Choisissez une distribution avec une origine de fonction Web Lambda à laquelle vous souhaitez ajouter l'OAC, puis cliquez sur l'onglet Origins.

3. Sélectionnez l'origine de la fonction Web Lambda à laquelle vous souhaitez ajouter l'OAC, puis choisissez Modifier.

4. Pour Accès d’origine, sélectionnez Paramètres de contrôle d’accès d’origine (recommandé).

5. Dans le menu déroulant Origin access control (Contrôle d'accès d'origine), choisissez l'OAC que vous souhaitez utiliser.

6. 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

Exemple 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 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'Authorizationen-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'Authorizationen-tête du spectateur à l'origine sans modification. Avec ce comportement, votre fonction Web Lambda peut recevoir l'Authorizationen-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'Authorizationen-tête du visualiseur, vous devez l'ajouter à une politique de cache pour chaque comportement de cache utilisant l'origine.

Les autres comportements de signature (alwaysnever, etno-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 PUTPOST, 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.