

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.

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