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.
# Définition des autorisations de fonction Lambda avec un rôle d’exécution
Le rôle d'exécution d'une fonction Lambda est un rôle Gestion des identités et des accès AWS (IAM) qui accorde à la fonction l'autorisation d'accès Services AWS et de ressources. Par exemple, vous pouvez créer un rôle d'exécution autorisé à envoyer des journaux à Amazon CloudWatch et à y télécharger des données de suivi AWS X-Ray. Cette page fournit des informations sur la façon de créer, d’afficher et de gérer le rôle d’exécution d’une fonction Lambda.
Lambda assume automatiquement votre rôle d’exécution lorsque vous appelez votre fonction. Vous devez éviter d’appeler `sts:AssumeRole` manuellement afin d’assumer le rôle d’exécution dans votre code de fonction. Si votre cas d’utilisation nécessite que le rôle soit assumé par lui-même, vous devez inclure le rôle lui-même en tant que principal approuvé dans la politique d’approbation de votre rôle. Pour en savoir plus sur la procédure de modification d’une politique d’approbation des rôles, consultez [Modification d’une politique d’approbation de rôle (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-managingrole_edit-trust-policy)dans le Guide de l’utilisateur IAM.
Pour que Lambda assume correctement votre rôle d’exécution, [la politique de confiance](#permissions-executionrole-api) du rôle doit spécifier le principal de service Lambda (`lambda.amazonaws.com`) comme un service de confiance.
**Topics**
+ [
## Création d’un rôle d’exécution dans la console IAM
](#permissions-executionrole-console)
+ [
## Création et gestion des rôles à l'aide du AWS CLI
](#permissions-executionrole-api)
+ [
## Accorder un accès assorti d’un privilège minimum à votre rôle d’exécution Lambda
](#permissions-executionrole-least-privilege)
+ [
# Affichage et mise à jour des autorisations dans le rôle d’exécution
](permissions-executionrole-update.md)
+ [
# Utilisation de politiques AWS gérées dans le rôle d'exécution
](permissions-managed-policies.md)
+ [
# Utilisation de l’ARN de la fonction source pour contrôler le comportement d’accès aux fonctions
](permissions-source-function-arn.md)
## Création d’un rôle d’exécution dans la console IAM
Par défaut, Lambda crée un rôle d’exécution avec des autorisations minimales lorsque vous [créez une fonction dans la console Lambda](getting-started.md#getting-started-create-function). Plus précisément, ce rôle d'exécution inclut la [politique `AWSLambdaBasicExecutionRole` gérée](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html), qui donne à votre fonction les autorisations de base pour consigner des événements sur Amazon CloudWatch Logs. Vous pouvez sélectionner **Créer un rôle par défaut** dans la section **Autorisations**.
Vous pouvez choisir un rôle existant en sélectionnant **Utiliser un autre rôle** dans la section **Autorisations**. Si votre fonction Lambda a besoin d'autorisations supplémentaires pour effectuer des tâches telles que la mise à jour des entrées dans une base de données Amazon DynamoDB en réponse à des événements, vous pouvez créer un rôle d'exécution personnalisé avec les autorisations nécessaires. Pour ce faire, sélectionnez **Utiliser un autre rôle** dans la section **Autorisations**, qui ouvre un tiroir dans lequel vous pouvez personnaliser vos autorisations.
**Pour configurer un rôle d'exécution depuis la console**
1. Entrez un **nom de rôle** dans la section Détails du rôle.
1. Dans la section **Stratégie**, sélectionnez **Utiliser la politique existante**.
1. Sélectionnez les politiques AWS gérées que vous souhaitez associer à votre rôle. Par exemple, si votre fonction doit accéder à DynamoDB, sélectionnez la politique gérée par **DBExecutionDynamo AWSLambda Role**.
1. Choisissez **Créer un rôle**.
Lorsque vous [créez une fonction dans la console Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function), vous pouvez également associer à la fonction n'importe quel rôle d'exécution que vous avez créé précédemment. Si vous souhaitez associer un nouveau rôle d'exécution à une fonction existante, suivez les étapes décrites dans [Mettre à jour le rôle d'exécution d'une fonction](permissions-executionrole-update.md).
## Création et gestion des rôles à l'aide du AWS CLI
Pour créer un rôle d'exécution avec le AWS Command Line Interface (AWS CLI), utilisez la **create-role** commande. Lorsque vous utilisez cette commande, vous pouvez préciser la politique d’approbation en ligne. La politique d’approbation d’un rôle accorde aux principaux spécifiés l’autorisation d’assumer le rôle. Dans l’exemple suivant, vous accordez au service Lambda l’autorisation principale d’assumer votre rôle. Notez que les exigences relatives à l’échappement des guillemets dans la chaîne JSON peuvent varier en fonction de votre shell.
```
aws iam create-role \
--role-name lambda-ex \
--assume-role-policy-document '{"Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
```
Vous pouvez également définir la politique d’approbation pour le rôle à l’aide d’un fichier JSON séparé. Dans l’exemple suivant, le fichier `trust-policy.json` se trouve dans le répertoire actuel.
**Example trust-policy.json**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
```
aws iam create-role \
--role-name lambda-ex \
--assume-role-policy-document file://trust-policy.json
```
Pour ajouter des autorisations au rôle, utilisez la commande **attach-policy-to-role**. La commande suivante ajoute la politique gérée `AWSLambdaBasicExecutionRole` au rôle d’exécution `lambda-ex`.
```
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Après avoir créé votre rôle d’exécution, attachez-le à votre fonction. Lorsque vous [créez une fonction dans la console Lambda](getting-started.md#getting-started-create-function), vous pouvez attacher n’importe quel rôle d’exécution précédemment créé à la fonction. Si vous souhaitez attacher un nouveau rôle d’exécution à une fonction existante, suivez les étapes décrites dans [Mise à jour du rôle d’exécution d’une fonction](permissions-executionrole-update.md#update-execution-role).
## Accorder un accès assorti d’un privilège minimum à votre rôle d’exécution Lambda
Lorsque vous créez pour la première fois un rôle IAM pour votre fonction Lambda pendant la phase de développement, il peut arriver que vous accordiez des autorisations au-delà de ce que est nécessaire. Avant de publier votre fonction dans l’environnement de production, une bonne pratique consiste à ajuster la stratégie de manière à inclure uniquement les autorisations requises. Pour en savoir plus, consultez [Appliquer les autorisations de moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) dans le *Guide de l’utilisateur IAM*.
Utilisez IAM Access Analyzer pour identifier les autorisations requises pour la stratégie de rôle d’exécution IAM. IAM Access Analyzer examine vos AWS CloudTrail journaux pendant la période que vous spécifiez et génère un modèle de politique avec uniquement les autorisations utilisées par la fonction pendant cette période. Vous pouvez utiliser le modèle pour créer une stratégie gérée avec des autorisations affinées, puis l’attacher au rôle IAM. Ainsi, vous n'accordez que les autorisations dont le rôle a besoin pour interagir avec les AWS ressources correspondant à votre cas d'utilisation spécifique.
Pour en savoir plus, consultez [Générer des stratégies basées sur l’activité d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html) dans le *Guide de l’utilisateur IAM*.
# Affichage et mise à jour des autorisations dans le rôle d’exécution
Cette rubrique explique comment afficher et mettre à jour le [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction.
**Topics**
+ [
## Affichage du rôle d’exécution d’une fonction
](#view-execution-role)
+ [
## Mise à jour du rôle d’exécution d’une fonction
](#update-execution-role)
## Affichage du rôle d’exécution d’une fonction
Pour afficher le rôle d’exécution d’une fonction, utilisez la console Lambda.
**Pour afficher le rôle d’exécution d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez **Configuration (Configuration)**, puis **Permissions (Autorisations)**.
1. Sous **Rôle d’exécution**, vous pouvez afficher le rôle actuellement utilisé comme rôle d’exécution de la fonction. Par souci de commodité, vous pouvez consulter toutes les ressources et actions auxquelles la fonction peut accéder dans la section **Synthèse des ressources**. Vous pouvez également choisir un service dans la liste déroulante pour afficher toutes les autorisations associées à ce service.
## Mise à jour du rôle d’exécution d’une fonction
À tout moment, vous pouvez ajouter ou supprimer des autorisations à partir du rôle d’exécution d’une fonction ou configurer votre fonction afin d’utiliser un autre rôle. Si votre fonction a besoin d’accéder à d’autres services ou ressources, vous devez ajouter les autorisations nécessaires au rôle d’exécution.
Lorsque vous ajoutez des autorisations à votre fonction, modifiez légèrement son code ou sa configuration. Cela force l’arrêt et le remplacement des instances en cours d’exécution de votre fonction, qui ont des informations d’identification obsolètes.
Pour mettre à jour le rôle d’exécution d’une fonction, vous pouvez utiliser la console Lambda.
**Pour mettre à jour le rôle d’exécution d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez **Configuration (Configuration)**, puis **Permissions (Autorisations)**.
1. Sous **Rôle d’exécution**, choisissez **Modifier**.
1. Si vous souhaitez mettre à jour votre fonction pour utiliser un autre rôle en tant que rôle d’exécution, choisissez le nouveau rôle dans le menu déroulant sous **Rôle existant**.
**Note**
Si vous souhaitez mettre à jour les autorisations au sein d'un rôle d'exécution existant, vous ne pouvez le faire que dans la console Gestion des identités et des accès AWS (IAM).
Si vous souhaitez créer un nouveau rôle à utiliser comme rôle d'exécution, choisissez **Créer un nouveau rôle à partir de modèles de AWS politique** sous **Rôle d'exécution**. Saisissez ensuite le nom de votre nouveau rôle sous **Nom du rôle** et spécifiez les politiques que vous souhaitez attacher au nouveau rôle sous **Modèles de stratégies**.
1. Choisissez **Save** (Enregistrer).
# Utilisation de politiques AWS gérées dans le rôle d'exécution
Les politiques AWS gérées suivantes fournissent les autorisations requises pour utiliser les fonctionnalités Lambda.
| Modification | Description | Date |
| --- | --- | --- |
| **[ AWSLambdaMSKExecutionRôle](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)** — Lambda a ajouté l'autorisation [Kafka : DescribeCluster V2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#v2-clusters-clusterarnget) à cette politique. | `AWSLambdaMSKExecutionRole`accorde les autorisations nécessaires pour lire et accéder aux enregistrements d'un cluster Amazon Managed Streaming for Apache Kafka (Amazon MSK), gérer les interfaces réseau élastiques (ENIs) et écrire dans les journaux. CloudWatch | 17 juin 2022 |
| **[ AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole)**— Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSLambdaBasicExecutionRole` accorde des autorisations pour charger les journaux sur CloudWatch. | 14 février 2022 |
| **[ AWSLambdaDynamo DBExecution Role](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole)** — Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSLambdaDynamoDBExecutionRole`accorde l'autorisation de lire les enregistrements d'un flux Amazon DynamoDB et d'écrire dans Logs. CloudWatch | 14 février 2022 |
| **[ AWSLambdaKinesisExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole)**— Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSLambdaKinesisExecutionRole`accorde l'autorisation de lire les événements d'un flux de données Amazon Kinesis et d'écrire dans Logs. CloudWatch | 14 février 2022 |
| **[ AWSLambdaMSKExecutionRôle](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)** — Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSLambdaMSKExecutionRole`accorde les autorisations nécessaires pour lire et accéder aux enregistrements d'un cluster Amazon Managed Streaming for Apache Kafka (Amazon MSK), gérer les interfaces réseau élastiques (ENIs) et écrire dans les journaux. CloudWatch | 14 février 2022 |
| **[ AWSLambdaSQSQueueExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole)**— Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSLambdaSQSQueueExecutionRole`accorde l'autorisation de lire un message depuis une file d'attente Amazon Simple Queue Service (Amazon SQS) et d'écrire dans Logs. CloudWatch | 14 février 2022 |
| **[ AWSLambdaVPCAccessExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole)**— Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSLambdaVPCAccessExecutionRole`accorde des autorisations pour gérer ENIs au sein d'un Amazon VPC et écrire dans Logs. CloudWatch | 14 février 2022 |
| **[ AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)**— Lambda a commencé à suivre les modifications apportées à cette politique. | `AWSXRayDaemonWriteAccess`accorde des autorisations pour charger des données de suivi vers X-Ray. | 14 février 2022 |
| **[ CloudWatchLambdaInsightsExecutionRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy)**— Lambda a commencé à suivre les modifications apportées à cette politique. | `CloudWatchLambdaInsightsExecutionRolePolicy`accorde l'autorisation d'écrire des métriques d'exécution dans CloudWatch Lambda Insights. | 14 février 2022 |
| **[AmazonS3 — ObjectLambdaExecutionRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonS3ObjectLambdaExecutionRolePolicy)** Lambda a commencé à suivre les modifications apportées à cette politique. | `AmazonS3ObjectLambdaExecutionRolePolicy`accorde les autorisations nécessaires pour interagir avec l'objet Lambda d'Amazon Simple Storage Service (Amazon S3) et pour écrire dans Logs. CloudWatch | 14 février 2022 |
Pour certaines fonctionnalités, la console Lambda tente d’ajouter les autorisations manquantes au rôle d’exécution dans une stratégie gérée par le client. Ces stratégies peuvent être excessivement nombreuses. Afin d’éviter la création de stratégies supplémentaires, ajoutez les stratégies gérées AWS pertinentes au rôle d’exécution avant d’activer les fonctions.
Lorsque vous utilisez un [mappage de source d’événement](invocation-eventsourcemapping.md) pour appeler votre fonction, Lambda utilise le rôle d’exécution pour lire les données d’événement. Par exemple, un mappage de source d’événement pour Kinesis lit les événements d’un flux de données et les envoie à votre fonction par lots.
Lorsqu’un service endosse un rôle dans votre compte, vous pouvez inclure les clés de contexte de condition globale `aws:SourceAccount` et `aws:SourceArn` dans votre politique d’approbation des rôles afin de limiter l’accès au rôle aux seules demandes générées par les ressources attendues. Pour plus d’informations, consultez [Prévention du problème de l’adjoint confus entre services pour AWS Security Token Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention).
Outre les politiques AWS gérées, la console Lambda fournit des modèles permettant de créer une politique personnalisée avec des autorisations pour des cas d'utilisation supplémentaires. Lorsque vous créez une fonction dans la console Lambda, vous pouvez choisir de créer un nouveau rôle d’exécution doté des autorisations d’un ou plusieurs modèles. Ces modèles s’appliquent également automatiquement lorsque vous créez une fonction à partir d’un plan ou lorsque vous configurez les options qui nécessitent l’accès à d’autres services. Des exemples de modèles sont disponibles dans le [GitHubréférentiel](https://github.com/awsdocs/aws-lambda-developer-guide/tree/master/iam-policies) de ce guide.
# Utilisation de l’ARN de la fonction source pour contrôler le comportement d’accès aux fonctions
Il est courant que votre code de fonction Lambda envoie des requêtes API à d’autres Services AWS. Pour effectuer ces requêtes, Lambda génère un ensemble éphémère d’informations d’identification en assumant le rôle d’exécution de votre fonction. Ces informations d’identification sont disponibles en tant que variables d’environnement lors de l’appel de votre fonction. Lorsque vous travaillez avec AWS SDKs, vous n'avez pas besoin de fournir les informations d'identification du SDK directement dans le code. Par défaut, la chaîne de fournisseurs d’informations d’identification vérifie séquentiellement chaque endroit où vous pouvez définir des informations d’identification et sélectionne le premier disponible, généralement les variables d’environnement (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` et `AWS_SESSION_TOKEN`).
Lambda injecte l'ARN de la fonction source dans le contexte des informations d'identification si la demande est une demande d' AWS API provenant de votre environnement d'exécution. Lambda injecte également l’ARN de la fonction source pour les demandes d’API AWS suivantes que Lambda effectue en votre nom en dehors de votre environnement d’exécution :
| Service | Action | Raison |
| --- | --- | --- |
| CloudWatch Journaux | CreateLogGroup, CreateLogStream, PutLogEvents | Pour stocker les journaux dans un groupe de CloudWatch journaux |
| X-Ray | PutTraceSegments | Pour envoyer des données de traçage à X-Ray |
| Amazon EFS | ClientMount | Pour connecter votre fonction à un système de fichiers Amazon Elastic File System (Amazon EFS) |
Les autres appels d' AWS API que Lambda effectue en dehors de votre environnement d'exécution en votre nom en utilisant le même rôle d'exécution ne contiennent pas l'ARN de la fonction source. Voici des exemples de tels appels d’API en dehors de l’environnement d’exécution :
+ Appelle to AWS Key Management Service (AWS KMS) pour chiffrer et déchiffrer automatiquement vos variables d'environnement.
+ Appels à Amazon Elastic Compute Cloud (Amazon EC2) pour créer des interfaces réseau élastiques ENIs () pour une fonction compatible VPC.
+ Appels Services AWS, tels qu'Amazon Simple Queue Service (Amazon SQS), pour lire à partir d'une source d'événements configurée en tant que mappage de sources [d'](invocation-eventsourcemapping.md)événements.
Avec l’ARN de la fonction source dans le contexte des informations d’identification, vous pouvez vérifier si un appel à votre ressource provient du code d’une fonction Lambda spécifique. Pour vérifier cela, utilisez le clé de condition `lambda:SourceFunctionArn` dans une politique IAM basée sur l’identité ou [politique de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
**Note**
Vous ne pouvez pas utiliser l’élément `lambda:SourceFunctionArn` dans les politiques basées sur les ressources.
Avec cette clé de condition dans vos politiques basées sur l'identité SCPs, vous pouvez également implémenter des contrôles de sécurité pour les actions d'API que votre code de fonction effectue sur d'autres. Services AWS Cela comporte quelques applications de sécurité clés, telles que l’identification de la source d’une fuite d’informations d’identification.
**Note**
La clé de condition `lambda:SourceFunctionArn` est différente des clés de condition `lambda:FunctionArn` et `aws:SourceArn`. Le clé de condition `lambda:FunctionArn` s’applique uniquement aux [Mappages de sources d’événement](invocation-eventsourcemapping.md) et aide à définir les fonctions que votre source d’événement peut invoquer. La clé de `aws:SourceArn` condition s'applique uniquement aux politiques dans lesquelles votre fonction Lambda est la ressource cible et permet de définir quelles autres Services AWS ressources peuvent invoquer cette fonction. La clé de `lambda:SourceFunctionArn` condition peut s'appliquer à n'importe quelle politique basée sur l'identité ou à tout SCP afin de définir les fonctions Lambda spécifiques autorisées à effectuer des appels d' AWS API spécifiques vers d'autres ressources.
Pour utiliser `lambda:SourceFunctionArn` dans votre stratégie, incluez-la en tant que condition dans l’un des [Opérateurs de condition ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_ARN). La valeur de la clé doit être un ARN valide.
Par exemple, supposons que votre code de fonction Lambda émette un appel `s3:PutObject` qui cible un compartiment Amazon S3 spécifique. Vous pouvez vouloir n’autoriser qu’une fonction Lambda spécifique à avoir un accès `s3:PutObject` à ce compartiment. Dans ce cas, le rôle d’exécution de votre fonction doit être associé à une stratégie qui ressemble à ceci :
**Example stratégie accordant à une fonction Lambda spécifique l’accès à une ressource Amazon S3**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleSourceFunctionArn",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Condition": {
"ArnEquals": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
Cette politique permet uniquement un accès `s3:PutObject` si la source est la fonction Lambda avec ARN `arn:aws:lambda:us-east-1:123456789012:function:source_lambda`. Cette politique n’autorise pas un accès `s3:PutObject` à une autre identité d’appel. C’est le cas même si une fonction ou une entité différente émet un appel `s3:PutObject` avec le même rôle d’exécution.
**Note**
La clé de condition `lambda:SourceFunctionARN` ne prend pas en charge les versions des fonctions Lambda ni les alias de fonction. Si vous utilisez l’ARN pour une version ou un alias de fonction en particulier, votre fonction n’est pas autorisée à effectuer l’action que vous spécifiez. Veillez à utiliser l’ARN non qualifié pour votre fonction sans suffixe de version ou d’alias.
Vous pouvez également l'utiliser `lambda:SourceFunctionArn` dans SCPs. Supposons, par exemple, que vous souhaitiez limiter l’accès à votre compartiment à un code de fonction Lambda unique ou à des appels issus d’un cloud privé virtuel (VPC) Amazon. Le SCP suivant illustre ce processus.
**Example politique refusant l’accès à Amazon S3 dans des conditions spécifiques**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": [
"vpc-12345678"
]
}
}
},
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"ArnNotEqualsIfExists": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
Cette stratégie refuse toutes les actions S3 sauf si elles proviennent d’une fonction Lambda spécifique avec ARN `arn:aws:lambda:*:123456789012:function:source_lambda`, ou à moins qu’ils ne proviennent du VPC spécifié. L’opérateur `StringNotEqualsIfExists` indique à IAM de traiter cette condition uniquement si la clé `aws:SourceVpc` est présente dans la demande. De la même façon, IAM considère l’opérateur `ArnNotEqualsIfExists` uniquement si le `lambda:SourceFunctionArn` existe.