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. # Autorisations relatives à la fonction Web Lambda Les fonctions Web Lambda utilisent Gestion des identités et des accès AWS (IAM) pour contrôler ce que le code de votre application peut faire (le rôle d'exécution) et qui peut accéder à votre fonction Web (politiques basées sur les ressources). Cette page explique comment configurer chaque type. + **Rôle d'exécution : rôle** IAM assumé par votre code de fonction Web pour accéder à AWS des services tels qu'Amazon CloudWatch Logs, DynamoDB ou Amazon S3. + **Resource-based politiques** : politique attachée à votre fonction Web. Il définit quels principaux ou AWS services IAM peuvent effectuer des actions de fonction Web, telles que l'appel d'un point de terminaison dont le type d'authentification est`IamAuth`, ce qui signifie que Lambda authentifie les demandes auprès d'IAM. Pour plus d’informations, consultez [Type d’authentification](web-functions-endpoints.md#web-functions-endpoint-auth). Le principal IAM d'un autre compte a également besoin d'une autorisation basée sur l'identité. Le schéma suivant montre les identités qui nécessitent des autorisations et ce que chacune d'elles utilise. Le déployeur appelle les actions et les `iam:PassRole` besoins de gestion Lambda sur le rôle d'exécution. Le téléchargeur de code doit `s3:PutObject` se trouver sur le compartiment Amazon S3 versionné, et Lambda lit la version de l'objet de code. Lambda peut chiffrer le code de votre fonction Web et vos variables d'environnement à l'aide d'une clé optionnelle gérée par le client. AWS KMS Votre code s'exécute avec le rôle d'exécution, qui donne accès à Amazon CloudWatch Logs et à vos dépendances. L'appelant a besoin `lambda:InvokeWebFunctionEndpoint` d'un point de `IamAuth` terminaison ou d'informations d'identification d'application pour un `ApplicationManaged` point de terminaison. ![Le déployeur, le téléchargeur de code et l'appelant du point de terminaison ont chacun besoin d'autorisations différentes pour accéder au plan de contrôle des fonctions Web, au compartiment de code Amazon S3 et à l'environnement d'exécution.](https://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/web-functions-permissions-actors.png) ## Rôle d'exécution Le rôle d'exécution est un rôle IAM que Lambda assume lorsqu'il exécute le code de votre fonction Web. Votre application utilise les autorisations de ce rôle pour interagir avec d'autres AWS services. Au minimum, votre fonction Web doit être autorisée à écrire des CloudWatch journaux sur Amazon Logs afin que vous puissiez surveiller votre application. Si votre application lit depuis DynamoDB, écrit sur Amazon S3 ou appelle AWS d'autres services, vous ajoutez ces autorisations au rôle d'exécution. ### Création d'un rôle d'exécution Pour créer un rôle d'exécution pour votre fonction Web, créez un rôle IAM avec une politique de confiance qui permet au principal du service Lambda de l'assumer, et associez une politique d'autorisation qui accorde l'accès dont votre application a besoin. **Pour créer un rôle d'exécution (AWS CLI)** 1. Créez un fichier nommé `trust-policy.json` avec la politique de confiance suivante. Cette politique permet au directeur du service Lambda d'assumer le rôle en votre nom. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Créez le rôle. ``` aws iam create-role \ --role-name {{my-web-function-role}} \ --assume-role-policy-document file://trust-policy.json ``` 1. Attachez la politique de gestion des rôles d'exécution de AWS Lambda base. Cette politique accorde des autorisations pour créer des groupes de journaux, des flux de journaux et écrire des événements de journal sur Amazon CloudWatch Logs. ``` aws iam attach-role-policy \ --role-name {{my-web-function-role}} \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole ``` Si vous préférez créer une politique d'autorisations personnalisée au lieu d'utiliser la politique gérée, les autorisations minimales dont votre fonction Web a besoin pour se connecter sont les suivantes : ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:{{us-east-1}}:{{111122223333}}:log-group:/aws/lambda/web/{{my-web-app}}:*", "arn:aws:logs:*:{{111122223333}}:log-group:/aws/lambda/web/{{my-web-app}}.local:*" ] } ] } ``` La politique couvre deux groupes de journaux. Lambda écrit les journaux régionaux dans le `.local` groupe de journaux, puis les centralise dans le groupe de journaux sans le suffixe dans la région d'origine. L'ARN du groupe de journaux centralisé utilise la région d'origine. L'`.local`ARN utilise un caractère générique de région car Lambda écrit dans ce groupe dans chaque région où un point de terminaison dessert du trafic. Cela permet à un rôle d'exécution de prendre en charge des points de terminaison dotés de différents ensembles de régions. Si le rôle ne peut pas écrire dans le groupe de `.local` journaux d'une région, Lambda ne fournit pas les journaux de cette région. Si vous utilisez un groupe de journaux personnalisé, remplacez les deux ARN par le nom de votre groupe de journaux et le nom de votre groupe de journaux suivis `.local` de. Pour plus d’informations, consultez [Groupes de journaux](web-functions-logging.md#web-functions-logging-log-groups). ### Ajouter des autorisations pour d'autres services Si votre application accède à d'autres AWS services, ajoutez les autorisations correspondantes au rôle d'exécution. L'exemple suivant ajoute un accès en lecture à une table DynamoDB et un accès en écriture à un compartiment Amazon S3. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:{{us-east-1}}:{{111122223333}}:log-group:/aws/lambda/web/{{my-web-app}}:*", "arn:aws:logs:*:{{111122223333}}:log-group:/aws/lambda/web/{{my-web-app}}.local:*" ] }, { "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:Query" ], "Resource": "arn:aws:dynamodb:{{us-east-1}}:{{111122223333}}:table/{{my-table}}" }, { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::{{my-output-bucket}}/*" } ] } ``` L'identité IAM qui crée une fonction Web ou une révision utilise ses propres autorisations, et non le rôle d'exécution. Cette identité nécessite `lambda:CreateWebFunction` ou`lambda:CreateWebFunctionRevision`, `iam:PassRole` sur le rôle d'exécution, un accès en lecture au package de déploiement dans Amazon S3. Pour les autorisations Amazon S3, consultez[Autorisations de l'appelant](web-functions-code-s3.md#web-functions-code-s3-caller-permissions). Si vous utilisez une clé gérée par le client pour chiffrer le code de votre fonction Web et les variables d'environnement, cette identité nécessite également AWS KMS des autorisations. Pour plus d’informations, consultez [Chiffrement au repos pour les fonctions Web](web-functions-encryption.md). ## Resource-based politiques Une politique basée sur les ressources est un document de politique JSON que vous attachez à votre fonction Web. Il peut accorder n'importe quelle action de fonction Web `lambda:CreateWebFunction` à l'exception des principaux ou AWS des services IAM. Par exemple, il peut accorder une autorisation `lambda:InvokeWebFunctionEndpoint` pour un `IamAuth` point de terminaison. Il peut également accorder des actions de gestion telles que `lambda:GetWebFunction``lambda:CreateWebFunctionRevision`, et`lambda:UpdateWebFunctionEndpoint`. La pièce jointe à la politique et ses déclarations utilisent différents ARN de ressources : + **ARN de la fonction Web** : utilisez cet ARN avec `PutResourcePolicy` `GetResourcePolicy``DeleteResourcePolicy`, et, et dans l'`Resource`élément d'une instruction qui autorise une action sur la fonction Web elle-même, tel que `lambda:GetWebFunction``lambda:CreateWebFunctionRevision`, ou`lambda:CreateWebFunctionEndpoint`. Par exemple : `arn:aws:lambda:us-east-1:111122223333:web-function/my-function`. Pour une action sur un point de terminaison existant, par exemple`lambda:UpdateWebFunctionEndpoint`, utilisez l'ARN du point de terminaison. Pour une action sur une révision existante, par exemple`lambda:DeleteWebFunctionRevision`, utilisez l'ARN de révision. Pour couvrir tous les points de terminaison de la fonction Web, utilisez`arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/*`. + **ARN du point de terminaison** — Utilisez cet ARN dans l'`Resource`élément d'une déclaration de politique qui accorde`lambda:InvokeWebFunctionEndpoint`. Par exemple : `arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod`. Pour un principal IAM du même compte, la politique basée sur l'identité du principal ou la politique basée sur les ressources de la fonction Web peuvent accorder l'autorisation. Pour un directeur IAM d'un autre compte, les deux politiques doivent accorder une autorisation. Cela s'applique à la fois aux actions d'appel et aux actions de gestion. Pour autoriser ou refuser des actions basées sur les balises d'une fonction Web, utilisez le contrôle d'accès basé sur les attributs (ABAC). Pour connaître les clés de condition prises en charge, consultez[Fonctions Web de balisage](web-functions-configuration-tags.md). **Note** Les fonctions Web ne sont pas `AddPermission` compatibles avec`RemovePermission`, ou`GetPolicy`. Gérez la politique avec `PutResourcePolicy``GetResourcePolicy`, et`DeleteResourcePolicy`. Utilisez des politiques basées sur les ressources lorsque : + Vous souhaitez accorder l'accès Invoke à un principal dans le cadre d'une autre procédure Compte AWS (invocation entre comptes). + Vous souhaitez accorder l'accès Invoke à un AWS service tel que CloudFront. + Vous souhaitez laisser un directeur d'un autre administrateur Compte AWS gérer la fonction Web, par exemple pour créer des révisions ou mettre à jour des points de terminaison. + Pour l'invocation d'un même compte, vous ne pouvez pas modifier la politique IAM de l'appelant (par exemple, lorsque l'appelant est géré par une autre équipe). ### Les politiques publiques ne sont pas autorisées Vous ne pouvez pas associer une politique basée sur les ressources publiques à une fonction Web. Si une politique est publique, la demande échoue avec un`ValidationException`. Dans cette section, *public* décrit une politique qui accorde l'accès à un ensemble non spécifié de principes. Il ne décrit pas l'accessibilité du réseau ou le type d'authentification du point de terminaison. **Qu'est-ce qui rend une politique publique** Une politique est publique à moins qu'elle ne limite les personnes autorisées à appeler la ressource à un ensemble bien défini de principes. Lambda part du principe que la politique est publique, puis évalue si elle est considérée comme non publique. Une politique est publique si elle autorise un principal que n'importe quel AWS client peut assumer. Le cas le plus courant est celui d'un joker principal non restreint, comme dans l'exemple suivant. Lambda rejette cette politique avec un. `ValidationException` Ne l'utilisez pas. ``` { "Effect": "Allow", "Principal": "*", "Action": "lambda:InvokeWebFunctionEndpoint", "Resource": "arn:aws:lambda:{{us-west-2}}:{{123456789012}}:web-function/{{my-web-function}}/endpoint/{{prod}}" } ``` Les restrictions suivantes ne rendent pas une politique non publique : + Conditions relatives à l'adresse IP. Il ne suffit pas `aws:SourceIp` de se limiter à une plage CIDR. + Principaux fédérés. Un `Principal` bloc qui nomme un fournisseur d'identité fédéré ne limite pas l'accès à un ensemble d'identités bien défini. + Clés de condition qui décrivent la ressource. Les clés telles que le type d'authentification du point de terminaison décrivent comment la ressource est configurée, et non qui appelle, de sorte qu'elles ne peuvent pas restreindre le principal. Il existe deux manières de rendre une politique non publique. #### Spécifiez les principes dans le bloc Principal Énumérez un ou plusieurs principes entièrement spécifiés dans le `Principal` bloc. Les valeurs ne doivent pas contenir de caractères génériques ni de variables de politique. Le nombre de directeurs n'a pas d'importance. ``` { "Effect": "Allow", "Principal": { "AWS": [ "{{123456789012}}", "{{111122223333}}" ] }, "Action": "lambda:InvokeWebFunctionEndpoint", "Resource": "arn:aws:lambda:{{us-west-2}}:{{123456789012}}:web-function/{{my-web-function}}/endpoint/{{prod}}" } ``` Un principal IAM d'un autre compte a également besoin d'une autorisation basée sur l'identité pour appeler le point de terminaison. #### Utiliser une clé de condition fiable Limitez l'une des clés de condition suivantes à une valeur fixe. Ces clés identifient l'appelant authentifié et ne peuvent pas être définies par le demandeur. + `aws:PrincipalAccount` + `aws:PrincipalArn` + `aws:PrincipalOrgID` + `aws:PrincipalOrgPaths` + `aws:SourceAccount` + `aws:SourceArn` + `aws:SourceOrgID` + `aws:SourceOrgPaths` + `aws:SourceVpc` + `aws:SourceVpcArn` + `aws:SourceVpce` + `aws:VpceAccount` + `aws:VpceOrgID` + `aws:VpceOrgPaths` + `aws:Ec2InstanceSourceVpc` + `aws:UserId` + `aws:PrincipalServiceName` + `aws:PrincipalServiceNamesList` + `aws:PrincipalIsAWSService` + `lambda:SourceFunctionArn` Le fait de nommer une clé fiable ne suffit pas à lui seul. Vous devez également restreindre la valeur : + Les valeurs de chaîne ne doivent pas contenir de caractères génériques ni de variables de politique. + Les valeurs ARN ne doivent pas contenir de caractères génériques ou de variables de politique dans les cinq premiers champs de l'ARN : `arn` partition, service, région et ID de compte. Les caractères génériques sont autorisés dans la partie ressource. + `aws:PrincipalIsAWSService` doit être défini sur `true`. La politique suivante accorde aux responsables de votre organisation l'autorisation basée sur les ressources requise pour appeler le point de terminaison et n'est pas considérée comme publique. Le principal IAM d'un autre compte a également besoin d'une autorisation basée sur l'identité. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowOrgAccess", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "lambda:InvokeWebFunctionEndpoint", "Resource": "arn:aws:lambda:{{us-west-2}}:{{123456789012}}:web-function/{{my-web-function}}/endpoint/{{prod}}", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "{{o-a1b2c3d4e5}}" } } } ] } ``` ### Cross-account accès La politique basée sur les ressources suivante accorde à un rôle IAM spécifique dans un autre compte l'autorisation d'invoquer un point de terminaison de votre fonction Web. Le rôle a également besoin d'une autorisation basée sur l'identité pour appeler le point de terminaison. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCrossAccountInvoke", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{{444455556666}}:role/{{caller-role}}" }, "Action": "lambda:InvokeWebFunctionEndpoint", "Resource": "arn:aws:lambda:{{us-east-1}}:{{111122223333}}:web-function/{{my-function}}/endpoint/{{prod}}" } ] } ``` Pour que l'invocation entre comptes réussisse, toutes les conditions suivantes doivent être remplies : + La politique basée sur l'identité de l'appelant accorde une `lambda:InvokeWebFunctionEndpoint` autorisation sur l'ARN du point de terminaison. + La politique basée sur les ressources de la fonction Web accorde l'autorisation à l'appelant (comme indiqué ci-dessus). + Le point de terminaison utilise `IamAuth` l'authentification afin que Lambda évalue les informations d'identification de l'appelant. ### Accorder l'accès à un AWS web La politique basée sur les ressources suivante accorde au principal du CloudFront service l'autorisation d'appeler votre fonction Web. Utilisez cette politique lorsque vous configurez une CloudFront distribution avec le point de terminaison de votre fonction Web comme origine. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudFrontInvoke", "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": { "ArnLike": { "aws:SourceArn": "arn:aws:cloudfront::{{111122223333}}:distribution/{{EDFDVBD6EXAMPLE}}" } } } ] } ``` La `aws:SourceArn` condition restreint l'accès à une CloudFront distribution spécifique. Sans cette condition, toute CloudFront distribution dans n'importe quel compte pourrait invoquer votre fonction Web. ### Réplication et cohérence éventuelle Lorsque vous attachez ou mettez à jour une politique basée sur les ressources à une fonction Web qui possède **MultiRegion**ou des points de **PerRegion**terminaison, Lambda réplique la politique sur toutes les répliques sur lesquelles les points de terminaison opèrent. Régions AWS Cette réplication est finalement cohérente. Pendant la fenêtre de réplication, Lambda peut évaluer les demandes dans les régions de réplication par rapport à la version précédente de la politique. Autrement dit : + Il est possible qu'une autorisation nouvellement ajoutée ne prenne pas effet immédiatement dans toutes les régions. + Lambda peut toujours respecter une autorisation récemment supprimée dans certaines régions jusqu'à ce que la réplication soit terminée. Il n'existe aucun signal d'achèvement visible par le client pour la réplication des politiques. Testez le comportement d'autorisation ou de refus attendu dans chaque région du point de terminaison avant de vous fier à la nouvelle politique. Pour le confinement d'urgence, mettez à jour le routage du trafic ou configurez le point de terminaison de manière `throttleConfig.rateLimit` `0` à ce qu'il bloque tout le trafic pendant que le changement de politique se propage. Pour plus d’informations, consultez [étranglement](web-functions-scaling.md#web-functions-scaling-throttling). Pour les **HomeRegion**terminaux, la politique s'applique uniquement dans la région d'origine et ne nécessite pas de réplication entre régions. Un changement peut tout de même prendre un peu de temps pour prendre effet. ## Autorisations pour configurer le réseau L'identité qui configure le réseau doit être autorisée à créer ou à mettre à jour les ressources Lambda pertinentes. Il a également besoin d'une autorisation pour transmettre les rôles et le connecteur requis. En fonction de l'opération, les autorisations incluent : + `lambda:CreateNetworkConnector` + `lambda:UpdateNetworkConnector` + `lambda:GetNetworkConnector` + `lambda:CreateWebFunction` + `lambda:CreateWebFunctionRevision` + `lambda:UpdateWebFunctionEndpoint` + `lambda:PassNetworkConnector` + `iam:PassRole` L'appelant doit être connecté `lambda:PassNetworkConnector` au connecteur référencé chaque fois qu'un `create-web-function-revision` appel `create-web-function` ou est défini. `egressNetworkConnectorArn` Élargissez cette autorisation aux ressources de connecteur approuvées. `iam:PassRole`Portez sur les rôles d'exécution approuvés, que vous transmettez lorsque vous créez une fonction Web ou une révision, et sur les rôles d'opérateur approuvés, que vous transmettez lorsque vous créez ou mettez à jour un connecteur réseau. Pour la politique d'autorisations relatives au rôle d'opérateur, voir[Autorisations relatives au rôle d'opérateur](web-functions-networking.md#web-functions-networking-vpc-operator-role).