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.
Vous pouvez utiliser AWS Identity and Access Management (IAM) pour gérer les autorisations dans AWS Lambda. Il existe deux catégories principales d’autorisations que vous devez prendre en compte lorsque vous travaillez avec des fonctions Lambda :
-
Autorisations dont vos fonctions Lambda ont besoin pour effectuer des actions d'API et accéder à d'autres ressources AWS
-
Autorisations dont AWS les autres utilisateurs et entités ont besoin pour accéder à vos fonctions Lambda
Les fonctions Lambda ont souvent besoin d'accéder à d'autres AWS ressources et d'effectuer diverses opérations d'API sur ces ressources. Par exemple, vous pouvez disposer d’une fonction Lambda qui répond à un événement en mettant à jour les entrées d’une base de données Amazon DynamoDB. Dans ce cas, votre fonction a besoin d’autorisations pour accéder à la base de données, ainsi que d’autorisations pour mettre ou mettre à jour des éléments dans cette base de données.
Vous définissez les autorisations dont votre fonction Lambda a besoin dans un rôle IAM spécial appelé rôle d’exécution. Dans ce rôle, vous pouvez associer une politique qui définit toutes les autorisations dont votre fonction a besoin pour accéder à d'autres AWS ressources et lire des sources d'événements. Chaque fonction Lambda doit avoir un rôle d’exécution. Au minimum, votre rôle d'exécution doit avoir accès à Amazon CloudWatch car les fonctions Lambda se connectent par défaut à CloudWatch Logs. Vous pouvez associer la politique gérée par AWSLambdaBasicExecutionRole à votre rôle d’exécution pour répondre à cette exigence.
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é 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 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) 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.
Dans AWS, il est recommandé d'accorder uniquement les autorisations requises pour effectuer une tâche (autorisations du moindre privilège). Pour implémenter cela dans Lambda, nous vous recommandons de commencer par une politique gérée par AWS. Vous pouvez utiliser ces stratégies gérées telles quelles ou comme point de départ pour créer des stratégies plus restrictives.
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.
Pour de plus amples informations sur IAM, consultez le Guide de l’utilisateur IAM.
