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.
# Identity and Access Management pour AWS Lambda
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs IAM contrôlent les personnes qui s’*authentifient* (sont connectées) et sont *autorisées* (disposent d’autorisations) à utiliser des ressources . IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment AWS Lambda fonctionne avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md)
+ [AWS politiques gérées pour AWS Lambda](security-iam-awsmanpol.md)
+ [Résolution des problèmes AWS Lambda d'identité et d'accès](security_iam_troubleshoot.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes AWS Lambda d'identité et d'accès](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment AWS Lambda fonctionne avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md))
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération AWS CLI ou AWS API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Comment AWS Lambda fonctionne avec IAM
Avant d’utiliser IAM pour gérer l’accès à Lambda, découvrez les fonctions IAM que vous pouvez utiliser avec Lambda.
| Fonctionnalité IAM | Support Lambda |
| --- | --- |
| [Politiques basées sur l’identité](#security_iam_service-with-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies) | Oui |
| [Actions de politique](#security_iam_service-with-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#security_iam_service-with-iam-id-based-policies-resources) | Oui |
| [Clés de condition de politique (spécifiques au service)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Oui |
| [ACLs](#security_iam_service-with-iam-acls) | Non |
| [ABAC (identifications dans les politiques)](#security_iam_service-with-iam-tags) | Partielle |
| [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Transfert des sessions d’accès (FAS)](#security_iam_service-with-iam-principal-permissions) | Non |
| [Rôles de service](#security_iam_service-with-iam-roles-service) | Oui |
| [Rôles liés à un service](#security_iam_service-with-iam-roles-service-linked) | Partielle |
*Pour obtenir une vue d'ensemble de la façon dont Lambda et les autres AWS services fonctionnent avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM dans le guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
## Politiques basées sur l’identité pour Lambda
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de politiques basées sur l’identité pour Lambda
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## Politiques basées sur les ressources dans Lambda
**Prend en charge les politiques basées sur les ressources** : oui
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
Vous pouvez attacher une politique basée sur les ressources à une fonction ou une couche Lambda. Cette politique désigne les principaux autorisés à effectuer des actions sur la fonction ou la couche.
Pour savoir comment attacher une politique basée sur les ressources à une fonction ou une couche, consultez [Voir les politiques IAM basées sur les ressources dans Lambda](access-control-resource-based.md).
## Actions de politique pour Lambda
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Pour afficher la liste des actions Lambda, consultez [Actions définies par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) dans la *Référence de l’autorisation de service*.
Les actions de politique dans Lambda utilisent le préfixe suivant avant l’action :
```
lambda
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## Ressources de politique pour Lambda
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
Pour consulter la liste des types de ressources Lambda et leurs caractéristiques ARNs, consultez la section [Types de ressources définis par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) dans la référence *d'autorisation de service*. Pour savoir grâce à quelles actions vous pouvez spécifier l’ARN de chaque ressource, consultez [Actions définies par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## Clés de condition de politique pour Lambda
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour afficher la liste des clés de condition Lambda, consultez [Clés de condition pour AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) dans la *Référence de l’autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la section [Actions définies par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## ACLs à Lambda
**Supports ACLs :** Non
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## ABAC avec Lambda
**Prend en charge ABAC (identifications dans les politiques) :** partiellement
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs nommés balise. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur le balisage des ressources Lambda, consultez [Utilisation du contrôle d’accès basé sur les attributs dans Lambda](attribute-based-access-control.md).
## Utilisation des informations d’identification temporaires avec Lambda
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Transmission des sessions d’accès pour Lambda
**Prend en charge les sessions d’accès direct (FAS)** : oui
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour Lambda
**Prend en charge les rôles de service :** oui
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
Dans Lambda, un rôle de service est appelé [rôle d’exécution](lambda-intro-execution-role.md).
**Avertissement**
La modification des autorisations d’un rôle d’exécution peut altérer la fonction Lambda.
## Rôles liés à un service pour Lambda
**Prend en charge les rôles liés à un service :** partiellement
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Lambda n’a pas de rôles liés au service, contrairement à Lambda@Edge. *Pour plus d'informations, consultez la section [Rôles liés aux services pour Lambda @Edge dans](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) le manuel Amazon Developer Guide. CloudFront *
Pour plus d’informations sur la création ou la gestion des rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Recherchez un service dans le tableau qui inclut un `Yes` dans la colonne **Rôle lié à un service**. Choisissez le lien **Oui** pour consulter la documentation du rôle lié à ce service.
# Exemples de politiques basées sur l'identité pour AWS Lambda
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources Lambda. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
Pour plus de détails sur les actions et les types de ressources définis par Lambda, y compris le format de ARNs pour chacun des types de ressources, voir [Actions, ressources et clés de condition AWS Lambda dans la référence](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) *d'autorisation de service*.
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console Lambda](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
## Bonnes pratiques en matière de politiques
Les stratégies basées sur l’identité déterminent si une personne peut créer, consulter ou supprimer des ressources Lambda dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console Lambda
Pour accéder à la AWS Lambda console, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher des informations détaillées sur les ressources Lambda de votre. Compte AWS Si vous créez une politique basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette politique.
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.
Pour obtenir un exemple de stratégie qui accorde un accès minimal pour le développement de fonctions, veuillez consulter [Octroi aux utilisateurs de l’accès à une fonction Lambda](permissions-user-function.md). Outre Lambda APIs, la console Lambda utilise d'autres services pour afficher la configuration des déclencheurs et vous permettre d'ajouter de nouveaux déclencheurs. Si vos utilisateurs utilisent Lambda avec d’autres services, ils ont également besoin d’accéder à ces services. Pour plus d’informations sur la configuration d’autres services avec Lambda, consultez [Invoquer Lambda avec des événements provenant d'autres services AWS](lambda-services.md).
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS politiques gérées pour AWS Lambda
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
**Topics**
+ [AWS politique gérée : AWSLambda\$1FullAccess](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [AWS politique gérée : AWSLambda\$1ReadOnlyAccess](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [AWS politique gérée : AWSLambda BasicExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [AWS politique gérée : AWSLambda BasicDurableExecutionRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [AWS stratégie gérée : AWSLambda Dynamo Role DBExecution](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [AWS politique gérée : AWSLambda ENIManagement Accès](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [AWS politique gérée : AWSLambdaInvocation-DynamoDB](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [AWS politique gérée : AWSLambda KinesisExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [AWS politique gérée : AWSLambda MSKExecution rôle](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [AWS politique gérée : AWSLambda rôle](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [AWS politique gérée : AWSLambda SQSQueue ExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [AWS politique gérée : AWSLambda VPCAccess ExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [AWS politique gérée : AWSLambda Géré EC2 ResourceOperator](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [AWS politique gérée : AWSLambda ServiceRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [Mises à jour Lambda des politiques gérées AWS](#lambda-security-iam-awsmanpol-updates)
## AWS politique gérée : AWSLambda\$1FullAccess
Cette stratégie accorde un accès complet aux actions Lambda. Il accorde également des autorisations à d'autres AWS services utilisés pour développer et gérer les ressources Lambda.
Vous pouvez attacher la stratégie `AWSLambda_FullAccess` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `lambda` : donne aux principaux un accès complet à Lambda.
+ `cloudformation`— Permet aux directeurs de décrire les AWS CloudFormation piles et de répertorier les ressources qu'elles contiennent.
+ `cloudwatch`— Permet aux principaux de répertorier les CloudWatch métriques Amazon et d'obtenir des données métriques.
+ `ec2`— Permet aux principaux de décrire les groupes de sécurité, les sous-réseaux et. VPCs
+ `iam` : permet aux principaux d’obtenir les stratégies, les versions des stratégies, les rôles, les stratégies de rôle, les stratégies de rôles associées et la liste des rôles. Cette stratégie permet également aux principaux de transmettre des rôles à Lambda. L’autorisation `PassRole` est utilisée lorsque vous attribuez un rôle d’exécution à une fonction. L'`CreateServiceLinkedRole`autorisation est utilisée lors de la création d'un rôle lié à un service.
+ `kms`— Permet aux principaux de répertorier les alias et de décrire la clé pour le chiffrement des volumes.
+ `logs` : permet aux principaux de décrire les flux de journaux, d’obtenir les événements du journal, de filtrer les événements du journal et de démarrer et arrêter dsessions Live Tail.
+ `states`— Permet aux directeurs de décrire et de répertorier les machines AWS Step Functions d'état.
+ `tag` : permet aux principaux d’obtenir des ressources en fonction de leurs balises.
+ `xray`— Permet aux principaux d'obtenir des résumés de AWS X-Ray traces et de récupérer une liste de traces spécifiée par ID.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda\$1ReadOnlyAccess
Cette politique accorde un accès en lecture seule aux ressources Lambda et aux autres AWS services utilisés pour développer et gérer les ressources Lambda.
Vous pouvez attacher la stratégie `AWSLambda_ReadOnlyAccess` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `lambda` : permet aux principaux d’obtenir et de répertorier toutes les ressources.
+ `cloudformation`— Permet aux directeurs de décrire et de répertorier les AWS CloudFormation piles et de répertorier les ressources qu'elles contiennent.
+ `cloudwatch`— Permet aux principaux de répertorier les CloudWatch métriques Amazon et d'obtenir des données métriques.
+ `ec2`— Permet aux principaux de décrire les groupes de sécurité, les sous-réseaux et. VPCs
+ `iam` : permet aux principaux d’obtenir les stratégies, les versions des stratégies, les rôles, les stratégies de rôle, les stratégies de rôles associées et la liste des rôles.
+ `kms` : permet aux principaux de répertorier les alias.
+ `logs` : permet aux principaux de décrire les flux de journaux, d’obtenir les événements du journal, de filtrer les événements du journal et de démarrer et arrêter dsessions Live Tail.
+ `states`— Permet aux directeurs de décrire et de répertorier les machines AWS Step Functions d'état.
+ `tag` : permet aux principaux d’obtenir des ressources en fonction de leurs balises.
+ `xray`— Permet aux principaux d'obtenir des résumés de AWS X-Ray traces et de récupérer une liste de traces spécifiée par ID.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda BasicExecutionRole
Cette politique accorde des autorisations pour télécharger des CloudWatch journaux dans Logs.
Vous pouvez attacher la stratégie `AWSLambdaBasicExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda BasicDurableExecutionRolePolicy
Cette politique fournit des autorisations d'écriture aux CloudWatch journaux et read/write des autorisations d'exécution durable APIs utilisées par les fonctions durables Lambda. Cette politique fournit les autorisations essentielles requises pour les fonctions durables Lambda, qui utilisent l'exécution durable pour maintenir la progression et maintenir l'état d'un appel de fonction APIs à l'autre.
Vous pouvez attacher la stratégie `AWSLambdaBasicDurableExecutionRolePolicy` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `logs`— Permet aux principaux de créer des groupes de journaux et des flux de journaux, et d'écrire les événements des journaux dans les CloudWatch journaux.
+ `lambda`— Permet aux principaux de vérifier l'état d'exécution durable et de récupérer l'état d'exécution durable pour les fonctions durables Lambda.
Pour plus de détails sur cette politique, y compris la dernière version du document sur la politique JSON, consultez [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) dans le *Guide de référence de la politique gérée par AWS *.
## AWS stratégie gérée : AWSLambda Dynamo Role DBExecution
Cette politique accorde des autorisations pour lire les enregistrements d'un flux Amazon DynamoDB et pour écrire dans Logs. CloudWatch
Vous pouvez attacher la stratégie `AWSLambdaDynamoDBExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaDynamo DBExecution Role](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) dans le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda ENIManagement Accès
Cette stratégie accorde les autorisations nécessaires pour créer, décrire et supprimer des interfaces réseau Elastic utilisées par une fonction Lambda compatible VPC.
Vous pouvez attacher la stratégie `AWSLambdaENIManagementAccess` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) dans le *guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambdaInvocation-DynamoDB
Cette stratégie accorde un accès en lecture à Amazon DynamoDB Streams.
Vous pouvez attacher la stratégie `AWSLambdaInvocation-DynamoDB` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda KinesisExecutionRole
Cette politique accorde l'autorisation de lire les événements d'un flux de données Amazon Kinesis et d'écrire dans Logs. CloudWatch
Vous pouvez attacher la stratégie `AWSLambdaKinesisExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda MSKExecution rôle
Cette politique autorise la lecture et l'accès aux enregistrements d'un cluster Amazon Managed Streaming for Apache Kafka, la gestion des interfaces réseau élastiques et l'écriture dans les CloudWatch journaux.
Vous pouvez attacher la stratégie `AWSLambdaMSKExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, voir [AWSLambdaMSKExecutionRôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) dans le *guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda rôle
Cette stratégie accorde des autorisations pour invoquer les fonctions Lambda.
Vous pouvez attacher la stratégie `AWSLambdaRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, voir [AWSLambdaRôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) dans le *guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda SQSQueue ExecutionRole
Cette politique accorde des autorisations pour lire et supprimer des messages d'une file d'attente Amazon Simple Queue Service, et accorde des autorisations d'écriture aux CloudWatch journaux.
Vous pouvez attacher la stratégie `AWSLambdaSQSQueueExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda VPCAccess ExecutionRole
Cette politique accorde des autorisations pour gérer des interfaces réseau élastiques au sein d'un Amazon Virtual Private Cloud et pour écrire dans CloudWatch Logs.
Vous pouvez attacher la stratégie `AWSLambdaVPCAccessExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda Géré EC2 ResourceOperator
Cette politique permet la gestion automatisée des instances Amazon Elastic Compute Cloud pour les fournisseurs de capacité Lambda. Il accorde des autorisations au service Lambda Scaler pour effectuer des opérations sur le cycle de vie des instances en votre nom.
Vous pouvez attacher la stratégie `AWSLambdaManagedEC2ResourceOperator` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `ec2:RunInstances`— Permet à Lambda de lancer de nouvelles instances Amazon EC2 à condition que ec2 ManagedResourceOperator : soit égal à scaler.lambda.amazonaws.com et limite l'utilisation des AMI aux images appartenant à Amazon uniquement.
+ `ec2:DescribeInstances`et `ec2:DescribeInstanceStatus` — Permet à Lambda de surveiller l'état de l'instance et de récupérer les informations relatives à l'instance.
+ `ec2:CreateTags`— Permet à Lambda de baliser les ressources Amazon EC2 à des fins de gestion et d'identification.
+ `ec2:DescribeAvailabilityZones`— Permet à Lambda de visualiser les zones disponibles pour les décisions de placement des instances.
+ `ec2:DescribeCapacityReservations`— Permet à Lambda de vérifier les réservations de capacité pour un placement optimal des instances.
+ `ec2:DescribeInstanceTypes`et `ec2:DescribeInstanceTypeOfferings` — Permet à Lambda de passer en revue les types d'instances disponibles et leurs offres.
+ `ec2:DescribeSubnets`— Permet à Lambda d'examiner les configurations de sous-réseau pour la planification du réseau.
+ `ec2:DescribeSecurityGroups`— Permet à Lambda de récupérer les informations du groupe de sécurité pour la configuration de l'interface réseau.
+ `ec2:CreateNetworkInterface`— Permet à Lambda de créer des interfaces réseau et de gérer les associations de sous-réseaux et de groupes de sécurité.
+ `ec2:AttachNetworkInterface`[— Permet à Lambda d'associer des interfaces réseau aux instances Amazon EC2 avec la condition `ec2:ManagedResourceOperator` égale à scaler.lambda.amazonaws.com.](http://scaler.lambda.amazonaws.com/)
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, voir [AWSLambdaManaged EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : AWSLambda ServiceRolePolicy
Cette politique est attachée au rôle lié au service nommé pour permettre à Lambda AWSService RoleForLambda de mettre fin aux instances gérées dans le cadre des fournisseurs de capacité Lambda.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `ec2:TerminateInstances`— Permet à Lambda de mettre fin aux instances EC2 à la condition que ec2 : soit égal à scaler.lambda.amazonaws.com. ManagedResourceOperator
+ `ec2:DescribeInstanceStatus`et `ec2:DescribeInstances` — Permet à Lambda de décrire les instances EC2.
Pour plus d'informations sur cette politique, consultez la section [Utilisation de rôles liés à un service pour Lambda](using-service-linked-roles.md).
## Mises à jour Lambda des politiques gérées AWS
| Modifier | Description | Date |
| --- | --- | --- |
| [AWSLambdaGéré EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) — Nouvelle politique | Lambda a ajouté une nouvelle politique gérée pour permettre la gestion automatisée des instances Amazon EC2 pour les fournisseurs de capacité Lambda, permettant ainsi au service de scaler d'effectuer des opérations sur le cycle de vie des instances. | 30 novembre 2025 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) : nouvelle politique | Lambda a ajouté une nouvelle politique gérée pour le rôle lié au service afin de permettre à Lambda de mettre fin aux instances gérées dans le cadre des fournisseurs de capacité Lambda. | 30 novembre 2025 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Modification | Lambda a mis à jour la `AWSLambda_FullAccess` politique pour autoriser les actions `kms:DescribeKey` et`iam:CreateServiceLinkedRole`. | 30 novembre 2025 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)— Nouvelle politique gérée | Lambda a publié une nouvelle politique gérée `AWSLambdaBasicDurableExecutionRolePolicy` qui fournit des autorisations d'écriture aux CloudWatch journaux et des read/write autorisations d'exécution durable APIs utilisées par les fonctions durables Lambda. | 1er décembre 2025 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)et [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Modifier | Lambda a mis à jour les politiques `AWSLambda_ReadOnlyAccess` et `AWSLambda_FullAccess` pour autoriser les actions `logs:StartLiveTail` et `logs:StopLiveTail`. | 17 mars 2025 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)— Modification | Lambda a mis à jour la politique `AWSLambdaVPCAccessExecutionRole` pour autoriser l’action `ec2:DescribeSubnets`. | 5 janvier 2024 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Modification | Lambda a mis à jour la `AWSLambda_ReadOnlyAccess` politique pour autoriser les principaux à répertorier les piles. CloudFormation | 27 juillet 2023 |
| AWS Lambda a commencé à suivre les modifications | AWS Lambda a commencé à suivre les modifications apportées AWS à ses politiques gérées. | 27 juillet 2023 |
# Résolution des problèmes AWS Lambda d'identité et d'accès
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Lambda et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Lambda](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite permettre à des personnes extérieures à moi d'accéder Compte AWS à mes ressources Lambda](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans Lambda
Si vous recevez une erreur qui indique que vous n’êtes pas autorisé à effectuer une action, vos politiques doivent être mises à jour afin de vous permettre d’effectuer l’action.
L’exemple d’erreur suivant se produit quand l’utilisateur IAM `mateojackson` tente d’utiliser la console pour afficher des informations détaillées sur une ressource `my-example-widget` fictive, mais ne dispose pas des autorisations `lambda:GetWidget` fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
Dans ce cas, la politique qui s’applique à l’utilisateur `mateojackson` doit être mise à jour pour autoriser l’accès à la ressource `my-example-widget` à l’aide de l’action `lambda:GetWidget`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez une erreur selon laquelle vous n’êtes pas autorisé à exécuter l’action `iam:PassRole`, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Lambda.
Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L’exemple d’erreur suivant se produit quand un utilisateur IAM nommé `marymajor` tente d’utiliser la console pour exécuter une action dans Lambda. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite permettre à des personnes extérieures à moi d'accéder Compte AWS à mes ressources Lambda
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Lambda prend en charge ces fonctions, consultez [Comment AWS Lambda fonctionne avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.