

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.

# Utilisation du contrôle d’accès basé sur les attributs dans Lambda
<a name="attribute-based-access-control"></a>

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
<a name="attribute-based-access-control-example"></a>

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
<a name="abac-prerequisites"></a>

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
<a name="require-tag-on-create"></a>

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
<a name="restrict-actions-function-tags"></a>

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
<a name="abac-list-permissions"></a>

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
<a name="abac-iam-permissions"></a>

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
<a name="abac-create-role"></a>

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
<a name="abac-create-user"></a>

[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
<a name="abac-test"></a>

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
<a name="abac-clean-up"></a>

**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).