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.
# Accorder à d'autres AWS entités l'accès à vos fonctions Lambda
Pour autoriser d'autres Comptes AWS organisations et services à accéder à vos ressources Lambda, plusieurs options s'offrent à vous :
+ Vous pouvez utiliser des [politiques basées sur l’identité](access-control-identity-based.md) pour accorder à d’autres utilisateurs l’accès à vos ressources Lambda. Les stratégies basées sur l’identité peuvent s’appliquer directement aux utilisateurs, ou aux groupes et aux rôles associés à un utilisateur.
+ Vous pouvez utiliser des [politiques basées sur les ressources](access-control-resource-based.md) pour accorder à d'autres comptes et Services AWS autorisations l'accès à vos ressources Lambda. Lorsqu’un utilisateur essaie d’accéder à une ressource Lambda, Lambda prend en compte à la fois les stratégies basées sur l’identité appartenant à l’utilisateur et la stratégie basée sur une ressource appartenant aux ressources. Lorsqu'un AWS service tel qu'Amazon Simple Storage Service (Amazon S3) appelle votre fonction Lambda, Lambda ne prend en compte que la politique basée sur les ressources.
+ Vous pouvez utiliser un modèle de [contrôle d’accès par attributs (ABAC)](attribute-based-access-control.md) pour contrôler l’accès à vos fonctions Lambda. Avec ABAC, vous pouvez attacher des balises à une fonction Lambda, les transmettre dans certaines requêtes d’API ou les attacher au principal IAM qui effectue la requête. Spécifiez les mêmes balises dans l’élément condition d’une politique IAM pour contrôler l’accès aux fonctions.
Pour vous aider à optimiser vos autorisations d’accès avec le moindre privilège, Lambda fournit des conditions supplémentaires que vous pouvez inclure dans vos politiques. Pour de plus amples informations, veuillez consulter [Optimisation des sections relatives aux stratégies de Ressources et Conditions](lambda-api-permissions-ref.md).
# Politiques IAM basées sur l’identité pour Lambda
Vous pouvez utiliser des politiques basées sur l'identité dans Gestion des identités et des accès AWS (IAM) pour autoriser les utilisateurs de votre compte à accéder à Lambda. Les politiques basées sur l’identité peuvent s’appliquer aux utilisateurs, aux groupes d’utilisateurs ou aux rôles. Vous pouvez également accorder aux utilisateurs d’un autre compte l’autorisation d’endosser un rôle de votre compte et d’accéder à vos ressources Lambda.
Lambda fournit des politiques AWS gérées qui accordent l'accès aux actions de l'API Lambda et, dans certains cas, à d'autres AWS services utilisés pour développer et gérer les ressources Lambda. Lambda met à jour ces stratégies gérées si nécessaire pour s’assurer que vos utilisateurs ont accès aux nouvelles fonctionnalités quand elles sont disponibles.
+ [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Accorde un accès complet aux actions Lambda et aux autres AWS services utilisés pour développer et gérer les ressources Lambda.
+ [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Accorde un accès en lecture seule aux ressources Lambda.
+ [AWSLambdaRôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) : accorde des autorisations pour appeler des fonctions Lambda.
AWS les politiques gérées autorisent les actions d'API sans restreindre les fonctions ou les couches Lambda qu'un utilisateur peut modifier. Pour bénéficier d’un contrôle plus précis, vous pouvez créer vos propres stratégies qui limitent la portée des autorisations d’un utilisateur.
**Topics**
+ [Octroi aux utilisateurs de l’accès à une fonction Lambda](permissions-user-function.md)
+ [Octroi aux utilisateurs de l’accès à une couche Lambda](permissions-user-layer.md)
# Octroi aux utilisateurs de l’accès à une fonction Lambda
Utilisez des [politiques basées sur l’identité](access-control-identity-based.md) pour autoriser des utilisateurs, des groupes d’utilisateurs ou des groupes à effectuer des opérations sur des fonctions Lambda.
**Note**
Pour une fonction définie comme une image de conteneur, l’autorisation des utilisateurs à accéder à l’image doit être configurée dans Amazon Elastic Container Registry (Amazon ECR). Pour voir un exemple, consultez la rubrique [Politiques de référentiel Amazon ECR](images-create.md#configuration-images-permissions).
Voici un exemple de stratégie d’autorisations avec une portée limitée. Elle permet à un utilisateur de créer et gérer des fonctions Lambda nommées avec un préfixe distinct (`intern-`) et configurées avec un rôle d’exécution désigné.
**Example Stratégie de développement des fonctions**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "DevelopFunctions",
"Effect": "Allow",
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
},
{
"Sid": "DevelopEventSourceMappings",
"Effect": "Allow",
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
},
{
"Sid": "PassExecutionRole",
"Effect": "Allow",
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
},
{
"Sid": "ViewLogs",
"Effect": "Allow",
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
}
]
}
```
Les autorisations de la stratégie sont organisées en déclarations reposant sur les [ressources et conditions](lambda-api-permissions-ref.md) qu’elles prennent en charge.
+ `ReadOnlyPermissions` – La console Lambda utilise ces autorisations lorsque vous parcourez et affichez les fonctions. Les conditions ou modèles de ressources ne sont pas pris en charge.
```
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
```
+ `DevelopFunctions` – Utilisez toute action Lambda qui s’exécute sur des fonctions ayant le préfixe `intern-`, à l’exception de `AddPermission` et de `PutFunctionConcurrency`. `AddPermission` modifie la [politique basée sur les ressources](access-control-resource-based.md) de la fonction, ce qui peut avoir des conséquences en matière de sécurité. `PutFunctionConcurrency` réserve la capacité de mise à l’échelle pour une fonction, et peut retirer de la capacité à d’autres fonctions.
```
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
```
+ `DevelopEventSourceMappings` – Gérez les mappages de source d’événement sur les fonctions qui sont préfixées avec `intern-`. Ces actions s’exécutent sur des mappages de source d’événement, mais vous pouvez les restreindre par fonction à l’aide d’une *condition*.
```
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"StringLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
```
+ `PassExecutionRole` – Affichez et transmettez uniquement un rôle nommé `intern-lambda-execution-role`, qui doit être créé et géré par un utilisateur avec des autorisations IAM. `PassRole` est utilisé lorsque vous attribuez un rôle d’exécution à une fonction.
```
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
```
+ `ViewLogs`— Utilisez CloudWatch les journaux pour afficher les journaux des fonctions préfixées par`intern-`.
```
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
```
Cette stratégie permet à un utilisateur de démarrer avec Lambda, sans nuire aux ressources des autres utilisateurs. Il ne permet pas à un utilisateur de configurer une fonction pour qu'elle soit déclenchée par d'autres services ou d'appeler d'autres AWS services, ce qui nécessite des autorisations IAM plus étendues. Cela n'inclut pas non plus l'autorisation d'accéder à des services qui ne sont pas compatibles avec les politiques à portée limitée, tels que CloudWatch X-Ray. Pour ces services, utilisez les stratégies en lecture seule afin d’accorder à l’utilisateur l’accès aux métriques et aux données de suivi.
Lorsque vous configurez des déclencheurs pour votre fonction, vous devez y accéder pour utiliser le AWS service qui appelle votre fonction. Par exemple, pour configurer un déclencheur Amazon S3, vous vous devez être autorisé à utiliser les actions Amazon S3 qui gèrent les notifications de compartiment. La plupart de ces autorisations sont incluses dans la politique [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)gérée.
# Octroi aux utilisateurs de l’accès à une couche Lambda
Utilisez des [politiques basées sur l’identité](access-control-identity-based.md) pour autoriser des utilisateurs, des groupes d’utilisateurs ou des groupes à effectuer des opérations sur des couches Lambda. La stratégie suivante accorde à un utilisateur l’autorisation de créer des couches et de les utiliser avec des fonctions. Les modèles de ressources permettent à l'utilisateur de travailler dans n' Région AWS importe quelle version de couche, à condition que le nom de la couche commence par`test-`.
**Example stratégie de développement des couches**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PublishLayers",
"Effect": "Allow",
"Action": [
"lambda:PublishLayerVersion"
],
"Resource": "arn:aws:lambda:*:*:layer:test-*"
},
{
"Sid": "ManageLayerVersions",
"Effect": "Allow",
"Action": [
"lambda:GetLayerVersion",
"lambda:DeleteLayerVersion"
],
"Resource": "arn:aws:lambda:*:*:layer:test-*:*"
}
]
}
```
Vous pouvez également appliquer l’utilisation des couches durant la création et la configuration de la fonction avec la condition `lambda:Layer`. Par exemple, vous pouvez empêcher les utilisateurs d’utiliser les couches publiées par d’autres comptes. La stratégie ci-dessous ajoute une condition aux actions `CreateFunction` et `UpdateFunctionConfiguration` afin d’exiger que toutes les couches spécifiées proviennent du compte `123456789012`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConfigureFunctions",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringLike": {
"lambda:Layer": [
"arn:aws:lambda:*:123456789012:layer:*:*"
]
}
}
}
]
}
```
------
Pour que la condition s’applique, vérifiez qu’aucune autre déclaration n’accorde d’autorisation utilisateur à ces actions.
# Voir les politiques IAM basées sur les ressources dans Lambda
Lambda prend en charge les stratégies d’autorisations basées sur une ressource pour les fonctions et les couches Lambda. Vous pouvez utiliser des politiques basées sur les ressources pour accorder l’accès à d’autres [comptes](permissions-function-cross-account.md), [organisations](permissions-function-organization.md) ou [services AWS](permissions-function-services.md). Les stratégies basées sur les ressources s’appliquent à une seule fonction, version ou version de couche ou à un seul alias.
------
#### [ Console ]
**Pour afficher la stratégie basée sur les ressources d’une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez **Configuration** (Configuration), puis **Permissions** (Autorisations).
1. Faites défiler la page vers le bas, jusqu’à **Resource-based policy** (Stratégie basée sur les ressources), puis choisissez **View policy document** (Afficher le document de stratégie). La politique basée sur les ressources indique les autorisations appliquées lorsqu'un autre compte ou AWS service tente d'accéder à la fonction. L’exemple suivant montre une déclaration qui autorise Amazon S3 à invoquer une fonction nommée `my-function` pour un compartiment nommé `amzn-s3-demo-bucket` dans le compte `123456789012`.
**Example politique basée sur les ressources**
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "lambda-allow-s3-my-function",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "123456789012"
},
"ArnLike": {
"AWS:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
}
]
}
```
------
#### [ AWS CLI ]
Pour afficher une stratégie basée sur les ressources d’une fonction, utilisez la commande `get-policy`.
```
aws lambda get-policy \
--function-name my-function \
--output text
```
Vous devriez voir la sortie suivante:
****
```
{"Version":"2012-10-17", "Id":"default","Statement":[{"Sid":"sns","Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function","Condition":{"ArnLike":{"AWS:SourceArn":"arn:aws:sns:us-east-2:123456789012:lambda*"}}}]}
```
Pour les versions et les alias, ajoutez le numéro de version ou l’alias au nom de la fonction.
```
aws lambda get-policy --function-name my-function:PROD
```
Pour supprimer les autorisations de votre fonction, utilisez `remove-permission`.
```
aws lambda remove-permission \
--function-name example \
--statement-id sns
```
Utilisez la commande `get-layer-version-policy` pour afficher les autorisations sur une couche.
```
aws lambda get-layer-version-policy \
--layer-name my-layer \
--version-number 3 \
--output text
```
Vous devriez voir la sortie suivante:
```
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-west-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
Utilisez `remove-layer-version-permission` pour supprimer des déclarations de la stratégie.
```
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org
```
------
## Actions d’API prises en charge
Les actions de l’API Lambda suivantes prennent en charge les politiques basées sur les ressources :
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
+ [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionEventInvokeConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionEventInvokeConfig.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)
+ [InvokeFunctionUrl](urls-auth.md)(autorisation uniquement)
+ [ListAliases](https://docs.aws.amazon.com/lambda/latest/api/API_ListAliases.html)
+ [ListFunctionEventInvokeConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionEventInvokeConfigs.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)
+ [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
# Accorder l'accès à la fonction Lambda à Services AWS
Lorsque vous [utilisez un AWS service pour appeler votre fonction](lambda-services.md), vous accordez l'autorisation dans une déclaration relative à une politique basée sur les ressources. Vous pouvez appliquer la déclaration à l’ensemble de la fonction, ou limiter la déclaration à une seule version ou un seul alias.
**Note**
Lorsque vous ajoutez un déclencheur à la fonction à l’aide de la console Lambda, celle-ci met à jour la stratégie basée sur une ressource de la fonction afin d’autoriser le service à l’invoquer. Pour accorder des autorisations à d’autres comptes ou services non disponibles dans la console Lambda, vous pouvez utiliser l’ AWS CLI.
Ajoutez une déclaration avec la commande [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html). La déclaration de stratégie basée sur les ressources la plus simple autorise un service à invoquer une fonction. La commande ci-après accorde à Amazon Simple Notification Service l’autorisation d’invoquer une fonction nommée `my-function`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns \
--principal sns.amazonaws.com \
--output text
```
Vous devriez voir la sortie suivante :
```
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
```
Amazon SNS peut ainsi appeler l’action d’[invocation](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) de l’API pour la fonction, mais ne restreint pas la rubrique Amazon SNS qui déclenche l’invocation. Afin de vous assurer que votre fonction est invoquée uniquement par une ressource spécifique, spécifiez l’ARN (Amazon Resource Name) de la ressource avec l’option `source-arn`. La commande ci-après autorise uniquement Amazon SNS à invoquer la fonction pour des abonnements à une rubrique nommée `my-topic`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns-my-topic \
--principal sns.amazonaws.com \
--source-arn arn:aws:sns:us-east-2:123456789012:my-topic
```
Certains services peuvent invoquer des fonctions dans d’autres comptes. Cela ne pose pas de problème si vous spécifiez un ARN source qui contient votre ID de compte. Pour Amazon S3, cependant, la source est un compartiment dont l’ARN ne contient pas d’ID de compte. Il est possible que vous puissiez supprimer le compartiment et qu’un autre compte crée un compartiment du même nom. Utilisez l’option `source-account` avec votre ID de compte pour vous assurer que seules les ressources de votre compte peuvent invoquer la fonction.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id s3-account \
--principal s3.amazonaws.com \
--source-arn arn:aws:s3:::amzn-s3-demo-bucket \
--source-account 123456789012
```
# Octroi de l’accès à la fonction à une organisation
Pour accorder des autorisations à une organisation dans [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), spécifiez l’ID de l’organisation comme `principal-org-id`. La commande [ass-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) suivante accorde un accès d’invocation à tous les utilisateurs de l’organisation `o-a1b2c3d4e5f`.
```
aws lambda add-permission \
--function-name example \
--statement-id PrincipalOrgIDExample \
--action lambda:InvokeFunction \
--principal * \
--principal-org-id o-a1b2c3d4e5f
```
**Note**
Dans cette commande, `Principal` est `*`. Cela signifie que tous les utilisateurs de l’organisation `o-a1b2c3d4e5f` obtiennent des autorisations d’invocation de fonction. Si vous spécifiez un rôle Compte AWS ou comme étant le`Principal`, seul ce principal obtient les autorisations d'invocation des fonctions, mais uniquement s'il fait également partie de l'`o-a1b2c3d4e5f`organisation.
Cette commande crée une politique basée sur les ressources qui ressemble à ce qui suit :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalOrgIDExample",
"Effect": "Allow",
"Principal": "*",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:example",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-a1b2c3d4e5f"
}
}
}
]
}
```
------
Pour plus d'informations, consultez [aws : PrincipalOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) dans le *guide de l'utilisateur d'IAM*.
# Octroi de l’accès à la fonction Lambda à d’autres comptes
Pour partager une fonction avec une autre Compte AWS, ajoutez une déclaration d'autorisations entre comptes à la politique basée sur les [ressources](access-control-resource-based.md) de la fonction. Exécutez la commande [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) et spécifiez l’ID du compte en tant que `principal`. L’exemple suivant accorde au compte `111122223333` l’autorisation d’invoquer la fonction `my-function` avec l’alias `prod`.
```
aws lambda add-permission \
--function-name my-function:prod \
--statement-id xaccount \
--action lambda:InvokeFunction \
--principal 111122223333 \
--output text
```
Vous devriez voir la sortie suivante:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-1:123456789012:function:my-function"}
```
La stratégie basée sur les ressources accorde à l’autre compte l’autorisation d’accéder à la fonction, mais n’autorise pas les utilisateurs de ce compte à dépasser leurs autorisations. Les utilisateurs de l’autre compte doivent disposer des [autorisations utilisateur](access-control-identity-based.md) correspondantes pour utiliser l’API Lambda.
Afin de limiter l’accès à un utilisateur ou à un rôle dans un autre compte, spécifiez l’ARN complet de l’identité en tant que principal. Par exemple, `arn:aws:iam::123456789012:user/developer`.
L’[alias](configuration-aliases.md) limite la version pouvant être invoquée par l’autre compte. L’autre compte doit alors inclure l’alias dans l’ARN de la fonction.
```
aws lambda invoke \
--function-name arn:aws:lambda:us-east-2:123456789012:function:my-function:prod out
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"ExecutedVersion": "1"
}
```
Le propriétaire de la fonction peut alors mettre à jour l’alias afin qu’il pointe vers une nouvelle version sans que l’appelant ait besoin de modifier la façon dont il invoque votre fonction. Cela permet de s’assurer que l’autre compte n’a pas besoin de changer son code pour utiliser la nouvelle version et qu’il est uniquement autorisé à invoquer la version de la fonction associée à l’alias.
Vous pouvez accorder l’accès entre comptes pour n’importe quelle action d’API qui s’exécute sur une fonction existante. Par exemple, vous pouvez accorder l’accès à `lambda:ListAliases` afin qu’un compte puisse obtenir une liste des alias ou à `lambda:GetFunction` pour qu’il puisse télécharger le code de votre fonction. Ajoutez chaque autorisation séparément ou utilisez `lambda:*` pour accorder l’accès à toutes les actions pour la fonction spécifiée.
Pour accorder à d’autres comptes l’autorisation pour plusieurs fonctions ou pour des actions qui ne s’exécutent pas sur une fonction, nous vous conseillons d’utiliser des [rôles IAM](access-control-identity-based.md).
# Octroi de l’accès de la couche Lambda à d’autres comptes
Pour partager une couche avec une autre Compte AWS, ajoutez une déclaration d'autorisations entre comptes à la politique basée sur les [ressources](access-control-resource-based.md) de la couche. Exécutez la [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html)commande et spécifiez l'ID du compte sous la forme`principal`. Dans chaque instruction, vous pouvez accorder une autorisation à un compte unique, à tous les comptes ou à une organisation dans [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
L’exemple suivant autorise le compte 111122223333 à accéder à la version 2 de la couche `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Vous devez voir des résultats similaires à ce qui suit :
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Les autorisations ne s’appliquent qu’à une seule version de couche. Répétez le processus chaque fois que vous créez une nouvelle version de la couche.
Pour accorder l’autorisation à tous les comptes d’une organisation [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), utilisez l’option `organization-id`. L’exemple suivant accorde à tous les comptes d’une organisation `o-t194hfs8cz` l’autorisation d’utiliser la version 3 de `my-layer`.
```
aws lambda add-layer-version-permission \
--layer-name my-layer \
--version-number 3 \
--statement-id engineering-org \
--principal '*' \
--action lambda:GetLayerVersion \
--organization-id o-t194hfs8cz \
--output text
```
Vous devriez voir la sortie suivante :
```
{"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
Pour octroyer l’autorisation à plusieurs comptes ou organisations, vous devez ajouter plusieurs instructions.
# Utilisation du contrôle d’accès basé sur les attributs dans Lambda
Avec le [Contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html), vous pouvez utiliser des balises pour contrôler l’accès à vos fonctions Lambda. Vous pouvez associer des balises à certaines ressources Lambda, à certaines demandes d'API ou au principal Gestion des identités et des accès AWS (IAM) émetteur de la demande. Pour plus d'informations sur la manière dont l'accès basé sur les attributs est AWS accordé, consultez la section [Contrôle de l'accès aux AWS ressources à l'aide de balises](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) dans le guide de l'utilisateur *IAM*.
Vous pouvez utiliser ABAC pour[Accorder le moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) sans spécifier ni un nom ni un modèle ARN Amazon Resource Name (ARN) dans la stratégie IAM. Au lieu de cela, vous pouvez spécifier une balise dans le champ [élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une stratégie IAM pour le contrôle de l’accès. La mise à l’échelle est plus facile avec ABAC, car vous n’avez pas à mettre à jour vos politiques IAM lorsque vous créez de nouvelles ressources. Ajoutez plutôt des balises aux nouvelles ressources pour contrôler l’accès.
Dans Lambda, les balises sont utilisées sur les ressources suivantes :
+ Fonctions : pour plus d’informations sur les fonctions de balisage, voir [Utilisation de balises sur les fonctions Lambda](configuration-tags.md).
+ Configurations de signature de code : pour plus d’informations sur le balisage des configurations de signature de code, voir [Utilisation des balises dans les configurations de signature de code](tags-csc.md).
+ Mappage des sources d’événements : pour plus d’informations sur le balisage du mappage des sources d’événements, voir [Utilisation des balises dans les mappages des sources d’événements](tags-esm.md).
Les balises ne sont pas prises en charge pour les couches.
Vous pouvez utiliser les clés de condition suivantes pour écrire des règles de politique IAM basées sur les balises :
+ [aws : ResourceTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) : contrôlez l'accès en fonction des balises associées à une ressource Lambda.
+ [aws : RequestTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) : exige la présence de balises dans une demande, par exemple lors de la création d'une nouvelle fonction.
+ [aws : PrincipalTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html)
+ [aws : TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) : Contrôle si des clés de balise spécifiques peuvent être utilisées dans une requête.
Vous ne pouvez définir des conditions que pour les actions qui les prennent en charge. Pour obtenir une liste des conditions prises en charge par chaque action Lambda, consultez la rubrique [Actions, ressources et clés de condition pour AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) dans la Référence de l’autorisation de service. Pour la prise en charge d'**aws : ResourceTag /tag-key**, reportez-vous à « Types de ressources définis par ». AWS Lambda Pour **aws : RequestTag /tag-key** et **aws : TagKeys** support, reportez-vous à « Actions définies par ». AWS Lambda
**Topics**
+ [Sécurisation de vos fonctions par balise](attribute-based-access-control-example.md)
# Sécurisation de vos fonctions par balise
Les étapes suivantes illustrent une façon de configurer des autorisations pour les fonctions à l’aide d’ABAC. Dans cet exemple de scénario, vous allez créer quatre stratégies d’autorisations IAM. Vous allez ensuite associer ces stratégies à un nouveau rôle IAM. Enfin, vous allez créer un utilisateur IAM et lui donner l’autorisation d’assumer le nouveau rôle.
**Topics**
+ [Conditions préalables](#abac-prerequisites)
+ [Étape 1 : Exiger des balises pour les nouvelles fonctions](#require-tag-on-create)
+ [Étape 2 : Autoriser les actions en fonction des balises attachées à une fonction Lambda et à un principal IAM](#restrict-actions-function-tags)
+ [Étape 3 : Accorder des permissions de liste](#abac-list-permissions)
+ [Étape 4 : accorder des autorisations IAM](#abac-iam-permissions)
+ [Étape 5 : Création du rôle IAM](#abac-create-role)
+ [Étape 6 : Création d’un utilisateur IAM](#abac-create-user)
+ [Étape 7 : Tester les autorisations](#abac-test)
+ [Étape 8 : Nettoyer vos ressources](#abac-clean-up)
## Conditions préalables
Assurez-vous que vous disposez d’un [rôle d’exécution Lambda](lambda-intro-execution-role.md). Vous utiliserez ce rôle lorsque vous accorderez des autorisations IAM et lorsque vous créerez une fonction Lambda.
## Étape 1 : Exiger des balises pour les nouvelles fonctions
Lorsque vous utilisez ABAC avec Lambda, il est recommandé d’exiger que toutes les fonctions comportent des balises. Cela permet de garantir que vos politiques d’autorisation ABAC fonctionnent comme prévu.
[Créez une stratégie IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) similaire à l’exemple suivant : Cette politique utilise les clés de TagKeys condition [aws : RequestTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag), [aws : ResourceTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) et [aws :](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) pour exiger que les nouvelles fonctions et le principal IAM qui les crée possèdent tous deux la balise. `project` Le `ForAllValues` modificateur garantit que `project` est la seule balise autorisée. Si vous n’incluez pas`ForAllValues`, les utilisateurs peuvent ajouter d’autres balises à la fonction tant qu’ils transmettent également `project`.
**Example — Exiger des balises sur les nouvelles fonctions**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:TagResource"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/project": "${aws:PrincipalTag/project}",
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": "project"
}
}
}
}
```
## Étape 2 : Autoriser les actions en fonction des balises attachées à une fonction Lambda et à un principal IAM
Créez une deuxième politique IAM à l'aide de la clé de condition [aws : ResourceTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) pour exiger que la balise du principal corresponde à la balise attachée à la fonction. L’exemple de stratégie suivant autorise les mandataires avec la balise `project` pour appeler des fonctions avec la balise `project`. Si une fonction possède d’autres balises, l’action est refusée.
**Example — Exiger des balises correspondantes sur la fonction et le principal IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:GetFunction"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
}
}
}
]
}
```
## Étape 3 : Accorder des permissions de liste
Créez une stratégie qui permet au principal de répertorier les fonctions Lambda et les rôles IAM. Cela permet au principal de voir toutes les fonctions Lambda et les rôles IAM sur la console et lors de l’appel des actions d’API.
**Example — Accordez des autorisations de liste Lambda et IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllResourcesLambdaNoTags",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:ListFunctions",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
## Étape 4 : accorder des autorisations IAM
Créez une politique qui autorise **iam : PassRole**. Cette autorisation est requise lorsque vous attribuez un rôle d’exécution à une fonction. Dans l’exemple de stratégie suivant, remplacez l’exemple d’ARN par l’ARN de votre rôle d’exécution Lambda.
**Note**
N’utilisez pas la clé de condition `ResourceTag` dans une politique avec l’action `iam:PassRole`. Vous ne pouvez pas utiliser la balise sur un rôle IAM pour contrôler l’accès aux personnes qui peuvent transmettre ce rôle. Pour plus d'informations sur les autorisations requises pour transmettre un rôle à un service, consultez la section [Octroi à un utilisateur des autorisations pour transmettre un rôle à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html).
**Example — Accordez l’autorisation de transmettre le rôle d’exécution**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/lambda-ex"
}
]
}
```
## Étape 5 : Création du rôle IAM
C’est une bonne pratique d’[utilisation des rôles pour déléguer des autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate-using-roles). [Créer un rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html#roles-creatingrole-user-console) appelé `abac-project-role` :
+ Sur **Étape 1 : Sélection d’une entité de confiance** : Choisissez :**AWS compte**, puis **Ce compte**.
+ Sur **Étape 2 : Ajouter des autorisations** : Joignez les quatre stratégies IAM que vous avez créées au cours des étapes précédentes.
+ Sur **Étape 3 : Nommer, vérifier et créer** : Choisissez :**Ajouter une balise**. Pour **Key** (Clé), saisissez `project`. Ne saisissez pas **Valeur**.
## Étape 6 : Création d’un utilisateur IAM
[Création d’un utilisateur IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)appelé`abac-test-user`. Sur la page **Définir des autorisations**, choisissez **Attacher directement les stratégies existantes**, puis choisissez **Créer une stratégie**. Entrez la définition de politique suivante. Remplacez *111122223333* par votre [ID de compte AWS](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingYourAccountIdentifiers). Cette stratégie permet à `abac-test-user` d’assumer `abac-project-role`.
**Example — Autoriser l’utilisateur IAM à assumer le rôle ABAC**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/abac-project-role"
}
}
```
------
## Étape 7 : Tester les autorisations
1. Connectez-vous à la AWS console en tant que`abac-test-user`. Pour plus d’informations, [connectez-vous en tant qu’utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html#user-sign-in-page).
1. Basculez vers le rôle `abac-project-role`. Pour plus d’informations, consultez [Changement de rôles (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html).
1. [Création d’une fonction Lambda](configuration-tags.md#using-tags-with-the-console).
+ Sous **Autorisations** Choisissez **Modifier le rôle d’exécution par défaut**, puis dans le champ **Rôle d’exécution**, choisissez **Utiliser un rôle existant**. Choisissez le même rôle d’exécution que celui que vous avez utilisé dans[Étape 4 : accorder des autorisations IAM](#abac-iam-permissions).
+ Sous **Paramètres avancés**, choisissez **Activer les balises**, puis **Ajouter un nouveau tag**. Pour **Key** (Clé), saisissez `project`. Ne saisissez pas **Valeur**.
1. [Test de la fonction](testing-functions.md).
1. Créez une deuxième fonction Lambda et ajoutez une balise différente, telle que`environment`. Cette opération devrait échouer car la stratégie ABAC que vous avez créée dans [Étape 1 : Exiger des balises pour les nouvelles fonctions](#require-tag-on-create) autorise uniquement le principal à créer des fonctions avec la balise `project`.
1. Créez une troisième fonction sans balises. Cette opération devrait échouer car la stratégie ABAC que vous avez créée dans[Étape 1 : Exiger des balises pour les nouvelles fonctions](#require-tag-on-create)ne permet pas au mandant de créer des fonctions sans balises.
Cette stratégie d’autorisation vous permet de contrôler l’accès sans créer de nouvelles politiques pour chaque nouvel utilisateur. Pour accorder l’accès à de nouveaux utilisateurs, il suffit de leur donner l’autorisation d’assumer le rôle qui correspond au projet qui leur a été attribué.
## Étape 8 : Nettoyer vos ressources
**Suppression du rôle IAM**
1. Ouvrez la [page Roles](https://console.aws.amazon.com/iam/home#/roles) (Rôles) de la console IAM.
1. Sélectionnez le rôle que vous avez créé à l’[étape 5](#abac-create-role).
1. Sélectionnez **Delete (Supprimer)**.
1. Pour confirmer la suppression, saisissez le nom du rôle dans la zone de saisie de texte.
1. Sélectionnez **Delete (Supprimer)**.
**Pour supprimer l’utilisateur IAM**
1. Ouvrez la [page Utilisateurs](https://console.aws.amazon.com/iam/home#/users) de la console IAM.
1. Sélectionnez l’utilisateur IAM que vous avez créé à l’[étape 6](#abac-create-user).
1. Sélectionnez **Delete (Supprimer)**.
1. Pour confirmer la suppression, saisissez le nom de l’utilisateur dans la zone de saisie de texte.
1. Choisissez **Delete user** (Supprimer l’utilisateur).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
# Optimisation des sections relatives aux stratégies de Ressources et Conditions
Vous pouvez restreindre la portée des autorisations d’un utilisateur en spécifiant des ressources et des conditions dans une stratégie IAM Gestion des identités et des accès AWS . Chaque action d’une politique prend en charge une combinaison de types de ressources et de conditions qui varie en fonction du comportement de l’action.
Chaque déclaration de stratégie IAM accorde une autorisation pour une action effectuée sur une ressource. Lorsque l’action n’agit pas sur une ressource nommée, ou lorsque vous accordez l’autorisation d’effectuer l’action sur toutes les ressources, la valeur de la ressource de la stratégie est un caractère générique (`*`). Pour la plupart des actions, vous pouvez limiter les ressources qu’un utilisateur peut modifier en spécifiant l’Amazon Resource Name (ARN) d’une ressource ou un modèle ARN qui correspond à plusieurs ressources.
Par type de ressource, la conception générale pour restreindre la portée d’une action est la suivante :
+ Fonctions : les actions sur une fonction peuvent être limitées à une fonction spécifique selon l’ARN de la fonction, de la version ou de l’alias.
+ Mappage des sources d’événements : les actions peuvent être limitées à des ressources de mappage des sources d’événements spécifiques selon l’ARN. Le mappage des sources d’événements est toujours associé à une fonction. Vous pouvez également utiliser la condition `lambda:FunctionArn` pour restreindre les actions par fonction associée.
+ Couches : les actions liées à l’utilisation et aux autorisations relatives aux couches agissent sur les versions de couche.
+ Configuration de signature de code : les actions peuvent être limitées à des ressources de configuration de signature de code spécifiques selon l’ARN.
+ Balises : utilisez les conditions de balise standard. Pour de plus amples informations, veuillez consulter [Utilisation du contrôle d’accès basé sur les attributs dans Lambda](attribute-based-access-control.md).
Pour limiter les autorisations par ressource, spécifiez la ressource par son ARN.
**Format ARN de ressource Lambda**
+ Fonction – `arn:aws:lambda:us-west-2:123456789012:function:my-function`
+ Version de la fonction – `arn:aws:lambda:us-west-2:123456789012:function:my-function:1`
+ Alias de la fonction – `arn:aws:lambda:us-west-2:123456789012:function:my-function:TEST`
+ Mappage de source d’événement – `arn:aws:lambda:us-west-2:123456789012:event-source-mapping:fa123456-14a1-4fd2-9fec-83de64ad683de6d47`
+ Couche – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer`
+ Version de la couche – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer:1`
+ Configuration de signature de code – `arn:aws:lambda:us-west-2:123456789012:code-signing-config:my-csc`
Par exemple, la politique suivante permet Compte AWS `123456789012` à un utilisateur d'appeler une fonction nommée `my-function` dans la AWS région USA Ouest (Oregon).
**Example appeler une stratégie de fonction**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Invoke",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:my-function"
}
]
}
```
Il s’agit d’un cas particulier, où l’identificateur de l’action (`lambda:InvokeFunction`) diffère de l’opération d’API ([Appeler](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)). Pour les autres actions, l’identificateur de l’action est le nom de l’opération avec le préfixe `lambda:`.
**Topics**
+ [Comprendre la section Condition relative aux stratégies](#authorization-conditions)
+ [Fonctions de référencement dans la section Ressources relative aux stratégies](#function-resources)
+ [Actions IAM et comportements de fonctions pris en charge](#permissions-resources)
## Comprendre la section Condition relative aux stratégies
Les conditions sont facultatives dans la stratégie, et appliquent une logique supplémentaire pour déterminer si une action est autorisée. Outre les [conditions courantes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) prises en charge par toutes les actions, Lambda définit les types de condition que vous pouvez utiliser pour restreindre les valeurs des paramètres supplémentaires sur certaines actions.
Par exemple, la condition `lambda:Principal` permet de restreindre le service ou le compte auquel un utilisateur peut accorder l’accès d’invocation selon la [stratégie basée sur les ressources](access-control-resource-based.md) d’une fonction. La stratégie suivante permet à un utilisateur d’accorder une autorisation à des rubriques Amazon Simple Notification Service (Amazon SNS) d’appeler une fonction nommée `test`.
**Example gestion des autorisations d’une stratégie de fonction**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ManageFunctionPolicy",
"Effect": "Allow",
"Action": [
"lambda:AddPermission",
"lambda:RemovePermission"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:test:*",
"Condition": {
"StringEquals": {
"lambda:Principal": "sns.amazonaws.com"
}
}
}
]
}
```
La condition nécessite que le principal soit Amazon SNS et pas un autre service ou compte. Le modèle de ressource exige que le nom de la fonction soit `test` et inclue un numéro de version ou un alias. Par exemple, `test:v1`.
Pour plus d'informations sur les ressources et les conditions de Lambda et d'autres AWS services, consultez la section [Actions, ressources et clés de condition pour les AWS services](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html) dans la référence *d'autorisation de service*.
## Fonctions de référencement dans la section Ressources relative aux stratégies
Vous référencez une fonction Lambda dans une déclaration de stratégie à l’aide d’un nom Amazon Resource Name (ARN). Le format de l’ARN d’une fonction dépend du fait que vous référenciez la fonction entière, la [version](configuration-versions.md) d’une fonction ou un [alias](configuration-aliases.md).
Lors des appels d'API Lambda, les utilisateurs peuvent spécifier une version ou un alias en transmettant un ARN de version ou un ARN d'alias dans le [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)`FunctionName`paramètre, ou en définissant une valeur dans le [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)`Qualifier`paramètre. Lambda prend des décisions d’autorisation en comparant l’élément de ressource dans la stratégie IAM au `FunctionName` et au `Qualifier` transmis dans les appels d’API. En cas d’incompatibilité, Lambda refuse la demande.
Que vous autorisiez ou refusiez une action sur votre fonction, vous devez utiliser les types ARN de fonction appropriés dans votre déclaration de stratégie pour obtenir les résultats attendus. Par exemple, si votre stratégie fait référence à l’ARN non qualifié, Lambda accepte les demandes faisant référence à l’ARN non qualifié, mais refuse les demandes faisant référence à un ARN qualifié.
**Note**
Vous ne pouvez pas utiliser un caractère générique (\$1) pour établir une correspondance avec l’ID du compte. Pour plus d’informations sur la syntaxe acceptée, consultez[Référence de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)dans le*IAM User Guide*.
**Example permettant l’invocation d’un ARN non qualifié**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction"
}
]
}
```
Si votre stratégie fait référence à un ARN qualifié spécifique, Lambda accepte les demandes faisant référence à cet ARN, mais refuse les demandes faisant référence à l’ARN non qualifié ou à un ARN qualifié différent, par exemple,`myFunction:2`.
**Example permettant l’invocation d’un ARN qualifié spécifique**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:1"
}
]
}
```
Si votre stratégie fait référence à un ARN qualifié à l’aide de `:*`, Lambda accepte tout ARN qualifié mais refuse les demandes faisant référence à l’ARN non qualifié.
**Example permettant l’invocation de n’importe quel ARN qualifié**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
}
]
}
```
Si votre stratégie fait référence à un ARN utilisant `*`, Lambda accepte tout ARN qualifié ou non qualifié.
**Example permettant l’invocation de tout ARN qualifié ou non qualifié**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction*"
}
]
}
```
## Actions IAM et comportements de fonctions pris en charge
Les actions définissent ce qui peut être autorisé par le biais des politiques IAM. Pour obtenir une liste des actions prises en charge par Lambda, consultez la rubrique [Actions, ressources et clés de condition pour AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) dans la Référence de l’autorisation de service. Dans la plupart des cas, lorsqu’une action IAM autorise une action d’API Lambda, le nom de l’action IAM est identique à celui de l’action d’API Lambda, à l’exception des actions suivantes :
| Action d’API | Action IAM |
| --- | --- |
| [Invoke](https://docs.aws.amazon.com//lambda/latest/api/API_Invoke.html) | lambda:InvokeFunction |
| [GetLayerVersion](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersion.html) [GetLayerVersionByArn](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersionByArn.html) | lambda:GetLayerVersion |
Outre les ressources et les conditions définies dans la [référence d’autorisation de service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html), Lambda prend en charge les ressources et conditions suivantes pour certaines actions. Nombre d’entre elles sont liées aux fonctions de référencement dans la section des ressources relative aux politiques. Les actions sur une fonction peuvent être limitées à une fonction spécifique selon l’ARN de la fonction, de la version ou de l’alias, tel que décrit dans le tableau suivant.
| Action | Ressource | Condition |
| --- | --- | --- |
| [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) [Invoquer](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) (**Autorisation :** `lambda:InvokeFunction`) | Version de la fonction Alias de la fonction | N/A |
| [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) | N/A | `lambda:CodeSigningConfigArn` |
| [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html) [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html) [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html) | Alias de la fonction | N/A |