

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.

# IAM identités
<a name="id"></a>

Une identité IAM peut être associée à une ou plusieurs politiques, qui déterminent les actions qu'une identité est autorisée à effectuer, sur quelles AWS ressources et dans quelles conditions. Les identités IAM incluent les utilisateurs IAM, les groupes IAM et les rôles IAM. Une identité IAM est un type d’entité qui représente un utilisateur humain ou une charge de travail programmatique qui peut être authentifié et autorisé à effectuer des actions dans Comptes AWS. Les entités IAM comprennent les utilisateurs IAM et les rôles IAM. Pour les définitions des termes couramment utilisés, consultez [Conditions](introduction_identity-management.md#intro-structure-terms).

Vous pouvez fédérer des identités existantes à partir d’un fournisseur d’identité externe. Ces identités assumeront des rôles IAM pour accéder aux AWS ressources. Pour de plus amples informations, veuillez consulter [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md).

Vous pouvez également l'utiliser AWS IAM Identity Center pour créer et gérer les identités et l'accès aux AWS ressources. Les ensembles d’autorisations IAM Identity Center créent automatiquement les rôles IAM nécessaires pour fournir l’accès aux ressources. Pour plus d’informations, consultez [En quoi consiste IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html).

 Utilisateur racine d'un compte AWS Il s'agit d'un Compte AWS principe créé lors de votre Compte AWS création. L'utilisateur root a accès à tous les AWS services et ressources du compte. Pour de plus amples informations, veuillez consulter [Utilisateur racine IAM](#id_root). 

**Note**  
Suivez les [Pratiques exemplaires en matière de sécurité dans IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices-use-cases.html) lorsque vous travaillez avec des identités IAM. 
Suivez les [meilleures pratiques applicables à l’utilisateur racine de votre Compte AWS](root-user-best-practices.md) lorsque vous travaillez avec l’utilisateur racine.
Si vous ne parvenez pas à vous connecter, consultez [Se connecter à l’ AWS Management Console](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html). 

## Utilisateur racine IAM
<a name="id_root"></a>

Lorsque vous créez un Compte AWS, vous commencez par une identité de connexion unique qui donne un accès complet à toutes Services AWS les ressources du compte. Cette identité est appelée *utilisateur Compte AWS root*. Pour plus d’informations, consultez [Utilisateur racine du compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).

## Utilisateurs IAM
<a name="id_iam-users"></a>

Un *utilisateur IAM* est une identité au sein de vous Compte AWS qui possède des autorisations spécifiques pour une seule personne ou une seule application. Pour plus d’informations, consultez [Utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html). 

## Groupes d'utilisateurs IAM
<a name="id_iam-groups"></a>

Un *groupes d’utilisateurs IAM* est une identité qui spécifie un ensemble d’utilisateurs IAM. Pour plus d’informations, consultez la section [Groupes d’utilisateurs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html).

## Rôles IAM
<a name="id_iam-roles"></a>

Un *rôle IAM* est une identité au sein de vous Compte AWS dotée d'autorisations spécifiques. S’il est comparable à un utilisateur IAM, il n’est toutefois pas associé à une personne déterminée. Pour en savoir plus, consultez [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html).

# Utilisateur racine d'un compte AWS
<a name="id_root-user"></a>

Lorsque vous créez un compte Amazon Web Services (AWS) pour la première fois, vous utilisez une identité de connexion unique qui donne un accès complet à tous les AWS services et ressources du compte. Cette identité est appelée *utilisateur root* du AWS compte. L'adresse e-mail et le mot de passe que vous avez utilisés pour créer le vôtre Compte AWS sont les informations d'identification que vous utilisez pour vous connecter en tant qu'utilisateur root.
+ Utilisez l’utilisateur racine pour effectuer les tâches qui nécessitent des autorisations de niveau racine. Pour obtenir la liste complète des tâches qui nécessitent que vous vous connectiez en tant qu'utilisateur root, veuillez consulter [Tâches nécessitant les informations d'identification de l'utilisateur root](#root-user-tasks). 
+ Suivez les [Meilleures pratiques d’utilisateur racine pour votre Compte AWS](root-user-best-practices.md).
+ Si vous ne parvenez pas à vous connecter, consultez [Se connecter à l’ AWS Management Console](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html).

**Important**  
Nous vous recommandons vivement de ne pas utiliser l'utilisateur root pour vos tâches quotidiennes et de suivre les [bonnes pratiques de l'utilisateur root pour votre Compte AWS](root-user-best-practices.md). Protégez vos informations d’identification d’utilisateur racine et utilisez-les pour effectuer les tâches que seul l’utilisateur racine peut effectuer. Pour obtenir la liste complète des tâches qui nécessitent que vous vous connectiez en tant qu'utilisateur root, veuillez consulter [Tâches nécessitant les informations d'identification de l'utilisateur root](#root-user-tasks). 

Bien que l’authentification multifactorielle (MFA) soit appliquée par défaut pour les utilisateurs racine, elle nécessite une action de la part du client pour être ajoutée lors de la création initiale du compte ou à la demande lors de la connexion. Pour de plus amples informations sur l’utilisation de l’authentification multifactorielle (MFA) pour protéger l’utilisateur racine, veuillez consulter [Authentification multifactorielle pour Utilisateur racine d'un compte AWS](enable-mfa-for-root.md).

## Gestion centralisée de l’accès root pour les comptes membres
<a name="id_root-user-access-management"></a>

Pour vous aider à gérer les informations d’identification à grande échelle, vous pouvez sécuriser de manière centralisée l’accès aux informations d’identification des utilisateurs racine pour les comptes membres dans AWS Organizations. Lorsque vous l'activez AWS Organizations, vous regroupez tous vos AWS comptes au sein d'une organisation pour une gestion centralisée. La centralisation de l’accès racine vous permet de supprimer les informations d’identification de l’utilisateur racine et d’effectuer les tâches privilégiées suivantes sur les comptes membres.

**Suppression des informations d’identification de l’utilisateur racine des comptes membres**  
Après avoir [centralisé l’accès racine pour les comptes membres](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html), vous pouvez choisir de supprimer les informations d’identification de l’utilisateur racine des comptes membres de votre Organizations. Vous pouvez supprimer le mot de passe d’utilisateur racine, les clés d’accès, les certificats de signature, ainsi que désactiver l’authentification multifactorielle (MFA). Les nouveaux comptes que vous créez dans Organizations ne disposent par défaut d’aucunes informations d’identification d’utilisateur racine. Les comptes membres ne peuvent pas se connecter à leur utilisateur racine ni récupérer le mot de passe de leur utilisateur racine si la récupération de compte n’est pas activée.

**Effectuez les tâches privilégiées nécessitant les informations d’identification de l’utilisateur racine**  
Certaines tâches ne peuvent être effectuées que lorsque vous vous connectez en tant qu’utilisateur racine d’un compte. Certaines d’entre elles [Tâches nécessitant les informations d'identification de l'utilisateur root](#root-user-tasks) peuvent être effectuées par le compte de gestion ou par l’administrateur délégué d’IAM. Pour en savoir plus sur les actions privilégiées sur les comptes membres, consultez [Exécuter une tâche privilégiée](id_root-user-privileged-task.md).

**Activer la restauration du compte de l’utilisateur racine**  
Si vous devez récupérer les informations d’identification de l’utilisateur racine pour un compte membre, le compte de gestion des Organizations ou l’administrateur délégué peut exécuter la tâche privilégiée **Autoriser la récupération du mot de passe**. La personne ayant accès à la boîte de réception de l’utilisateur racine pour le compte membre peut [réinitialiser le mot de passe de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html) pour récupérer les informations d’identification de l’utilisateur racine. Nous vous recommandons de supprimer les informations d’identification de l’utilisateur racine une fois que vous avez terminé la tâche nécessitant l’accès à l’utilisateur racine.

# Centralisation de l’accès racine pour les comptes membres
<a name="id_root-enable-root-access"></a>

Les informations d'identification de l'utilisateur root sont les informations d'identification initiales attribuées à chaque Compte AWS utilisateur ayant un accès complet à tous les AWS services et ressources du compte. Lorsque vous l'activez AWS Organizations, vous regroupez tous vos AWS comptes au sein d'une organisation pour une gestion centralisée. Chaque compte membre dispose de son propre utilisateur racine avec des autorisations par défaut lui permettant d’effectuer toute action dans le compte membre. Nous vous recommandons de sécuriser de manière centralisée les informations d'identification de l'utilisateur root lors de l'utilisation Comptes AWS gérée AWS Organizations afin d'empêcher la récupération des informations d'identification de l'utilisateur root et l'accès à grande échelle.

Après avoir centralisé l’accès racine, vous pouvez choisir de supprimer les informations d’identification de l’utilisateur racine des comptes membres de votre organisation. Vous pouvez supprimer le mot de passe d’utilisateur racine, les clés d’accès, les certificats de signature, ainsi que désactiver l’authentification multifactorielle (MFA). Les nouveaux comptes que vous créez dans AWS Organizations ne disposent par défaut d’aucune information d’identification d’utilisateur racine. Les comptes membres ne peuvent pas se connecter à leur utilisateur racine ni récupérer le mot de passe de leur utilisateur racine.

**Note**  
Certaines tâches [Tâches nécessitant les informations d'identification de l'utilisateur root](id_root-user.md#root-user-tasks) peuvent être effectuées par le compte de gestion ou l’administrateur délégué pour IAM, mais d’autres ne peuvent être effectuées que lorsque vous vous connectez en tant qu’utilisateur racine d’un compte.  
Si vous devez récupérer les informations d’identification de l’utilisateur racine pour un compte membre pour exécuter l’une de ces tâches, suivez les étapes décrites dans [Exécuter une tâche privilégiée](id_root-user-privileged-task.md) et sélectionnez **Autoriser la récupération du mot de passe**. La personne ayant accès à la boîte de réception de l’utilisateur racine pour le compte membre peut alors suivre les étapes pour [réinitialiser le mot de passe de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html) et se connecter à l’utilisateur racine du compte membre.  
 Nous vous recommandons de supprimer les informations d’identification de l’utilisateur racine une fois que vous avez terminé la tâche nécessitant l’accès à l’utilisateur racine.

## Conditions préalables
<a name="enable-root-access-management_prerequisite"></a>

Avant de centraliser l’accès racine, vous devez configurer un compte avec les paramètres suivants :
+ Vous devez détenir les autorisations IAM suivants :
  + `iam:GetAccessKeyLastUsed`
  + `iam:GetAccountSummary`
  + `iam:GetLoginProfile`
  + `iam:GetUser`
  + `iam:ListAccessKeys`
  + `iam:ListMFADevices`
  + `iam:ListSigningCertificates`
  + `sts:AssumeRoot`
**Note**  
Pour vérifier l'état des informations d'identification de l'utilisateur root d'un compte membre, vous pouvez utiliser la politique [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials) AWS gérée pour limiter les autorisations lorsque vous effectuez une tâche privilégiée sur un compte AWS Organizations membre, ou utiliser n'importe quelle politique ayant accès à`iam:GetAccountSummary`.  
Pour générer le rapport sur les informations d’identification de l’utilisateur racine, les autres politiques ont uniquement besoin de l’action `iam:GetAccountSummary` pour produire le même résultat. Vous pouvez également répertorier ou obtenir les informations d’identification de chaque utilisateur racine, notamment :  
Si un mot de passe utilisateur racine est présent
Si une clé d’accès utilisateur racine est présente et quand elle a été utilisée pour la dernière fois
Si l’utilisateur racine possède des certificats de signature associés
Dispositifs MFA associés à l’utilisateur racine
Liste du statut consolidé des informations d’identification de l’utilisateur racine
+ Vous devez gérer votre Comptes AWS entrée [AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_introduction.html).
+ Pour activer cette fonctionnalité de votre organisation, vous devez disposer de l’autorisation suivante :
  + `iam:EnableOrganizationsRootCredentialsManagement`
  + `iam:EnableOrganizationsRootSessions`
  + `iam:ListOrganizationsFeatures`
  + `organizations:EnableAwsServiceAccess`
  + `organizations:ListAccountsForParent`
  + `organizations:RegisterDelegatedAdministrator` 
+ Pour garantir un fonctionnement optimal de la console, nous vous recommandons d’activer les autorisations supplémentaires suivantes :
  + `organizations:DescribeAccount`
  + `organizations:DescribeOrganization`
  + `organizations:ListAWSServiceAccessForOrganization`
  + `organizations:ListDelegatedAdministrators`
  + `organizations:ListOrganizationalUnitsForParent`
  + `organizations:ListParents`
  + `organizations:ListTagsForResource`

## Activation de l’accès racine centralisé (console)
<a name="enable-root-access-console"></a>

**Pour activer cette fonctionnalité pour les comptes membres dans le AWS Management Console**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation de la console, choisissez **Gestion de l’accès racine**, puis sélectionnez **Activer**.
**Note**  
Si vous constatez que la **gestion de l'accès root est désactivée**, activez l'accès sécurisé pour Gestion des identités et des accès AWS l'entrée AWS Organizations. Pour plus d’informations, consultez [AWS IAM et AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-iam.html) dans le *Guide de l’utilisateur AWS Organizations *.

1. Dans la section Fonctionnalités à activer, choisissez les fonctionnalités à activer.
   + Sélectionnez **Gestion des informations d’identification racine** pour permettre au compte de gestion et à l’administrateur délégué d’IAM de supprimer les informations d’identification de l’utilisateur racine pour les comptes membres. Vous devez activer les actions racines privilégiées dans les comptes membres pour leur permettre de récupérer leurs informations d’identification d’utilisateur racine après leur suppression.
   + Sélectionnez **Actions racine privilégiées dans les comptes membres** pour permettre au compte de gestion et à l’administrateur délégué d’IAM d’effectuer certaines tâches nécessitant des informations d’identification de l’utilisateur racine.

1. (Facultatif) Saisissez l’ID de compte de l’**administrateur délégué** autorisé à gérer l’accès des utilisateurs racine et à effectuer des actions privilégiées sur les comptes membres. Nous recommandons un compte destiné à des fins de sécurité ou de gestion.

1. Sélectionnez **Activer**.

## Activation de l’accès racine centralisé (AWS CLI)
<a name="enable-root-access-cli"></a>

**Pour activer l'accès root centralisé depuis le AWS Command Line Interface (AWS CLI)**

1. Si vous n'avez pas encore activé l'accès sécurisé pour Gestion des identités et des accès AWS in AWS Organizations, utilisez la commande suivante : [aws organizations enable-aws-service-access](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/organizations/enable-aws-service-access.html).

1. Utilisez la commande suivante pour autoriser le compte de gestion et l'administrateur délégué à supprimer les informations d'identification de l'utilisateur root pour les comptes membres : [aws iam enable-organizations-root-credentials -management](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-organizations-root-credentials-management.html).

1. Utilisez la commande suivante pour autoriser le compte de gestion et l'administrateur délégué à effectuer certaines tâches nécessitant des informations d'identification de l'utilisateur root : [aws iam enable-organizations-root-sessions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-organizations-root-sessions.html).

1. (Facultatif) Utilisez la commande suivante pour enregistrer un administrateur délégué : [aws organizations register-delegated-administrator](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/organizations/register-delegated-administrator.html).

   L’exemple suivant affecte le compte 111111111111 en tant qu’administrateur délégué pour le service IAM.

   ```
   aws organizations register-delegated-administrator 
   --service-principal iam.amazonaws.com
   --account-id 111111111111
   ```

## Activation de l'accès root centralisé (AWS API)
<a name="enable-root-access-api"></a>

**Pour activer l'accès root centralisé depuis l' AWS API**

1. Si vous n'avez pas encore activé l'accès sécurisé pour Gestion des identités et des accès AWS in AWS Organizations, utilisez la commande suivante : [Activer AWSService l'accès](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html).

1. Utilisez la commande suivante pour autoriser le compte de gestion et l'administrateur délégué à supprimer les informations d'identification de l'utilisateur root pour les comptes membres : [EnableOrganizationsRootCredentialsManagement](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOrganizationsRootCredentialsManagement.html).

1. Utilisez la commande suivante pour autoriser le compte de gestion et l'administrateur délégué à effectuer certaines tâches nécessitant des informations d'identification de l'utilisateur root : [EnableOrganizationsRootSessions](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOrganizationsRootSessions.html).

1. (Facultatif) Utilisez la commande suivante pour enregistrer un administrateur délégué : [RegisterDelegatedAdministrator](https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html)

## Étapes suivantes
<a name="enable-root-access_next-steps"></a>

Une fois que vous avez sécurisé de manière centralisée les informations d’identification privilégiées pour les comptes membres de votre organisation, consultez [Exécuter une tâche privilégiée](id_root-user-privileged-task.md) pour effectuer des actions privilégiées sur un compte membre.

# Réaliser une tâche privilégiée sur un compte AWS Organizations membre
<a name="id_root-user-privileged-task"></a>

Le compte AWS Organizations de gestion ou un compte d'administrateur délégué pour IAM peut effectuer certaines tâches privilégiées sur les comptes membres qui nécessiteraient autrement les informations d'identification de l'utilisateur root. Avec un accès root centralisé, ces tâches sont effectuées par le biais de sessions privilégiées de courte durée. Ces sessions fournissent des informations d'identification temporaires limitées à des actions privilégiées spécifiques, sans nécessiter la connexion de l'utilisateur root sur le compte du membre.

Une fois que vous avez lancé une session privilégiée, vous pouvez supprimer une politique de compartiment Amazon S3 mal configurée, supprimer une politique de file d’attente Amazon SQS mal configurée, supprimer les informations d’identification de l’utilisateur racine pour un compte membre et réactiver les informations d’identification de l’utilisateur racine pour un compte membre.

**Note**  
Pour utiliser l'accès root centralisé, vous devez vous connecter via un compte de gestion ou un compte d'administrateur délégué en tant qu'utilisateur ou rôle IAM avec l'`sts:AssumeRoot`autorisation explicitement accordée. Vous ne pouvez pas utiliser les informations d'identification de l'utilisateur root pour appeler`sts:AssumeRoot`.

## Conditions préalables
<a name="root-user-privileged-task_prerequisite"></a>

Avant de pouvoir lancer une session privilégiée, vous devez disposer des paramètres suivants :
+ Vous avez activé l’accès racine centralisé dans votre organisation. Pour savoir comment activer cette fonctionnalité, consultez [Centralisation de l’accès racine pour les comptes membres](id_root-enable-root-access.md).
+ Votre compte de gestion ou votre compte d’administrateur délégué dispose des autorisations suivantes : `sts:AssumeRoot`

## Effectuer une action privilégiée sur un compte membre (console)
<a name="root-user-privileged-task_action-console"></a>

**Pour lancer une session d'action privilégiée sur un compte membre dans le AWS Management Console**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation de la console, choisissez **Gestion de l’accès racine**.

1. Sélectionnez un nom dans la liste des comptes membres, puis choisissez **Effectuer une action privilégiée**.

1. Choisissez l’action privilégiée que vous souhaitez effectuer dans le compte membre.
   + Sélectionnez **Supprimer la politique de compartiment Amazon S3** pour supprimer une politique de compartiment mal configurée qui empêche tous les principaux d’accéder au compartiment Amazon S3.

     1. Choisissez **Naviguer dans S3** pour sélectionner un nom parmi les compartiments appartenant au compte membre, puis sélectionnez **Choisir**.

     1. Choisissez **Supprimer la politique de compartiment**.

     1. Utilisez la console Amazon S3 pour corriger la politique de compartiment après avoir supprimé la politique mal configurée. Pour plus d’informations, consultez [Ajout d’une politique de compartiment à l’aide de la console Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)dans le *Guide de l’utilisateur Amazon S3*.
   + Sélectionnez **Supprimer la politique Amazon SQS** pour supprimer une politique Amazon Simple Queue Service qui refuse à tous les principaux l’accès à une file d’attente Amazon SQS.

     1. Saisissez le nom de la file d’attente dans le champ **Nom de la file d’attente SQS**, puis sélectionnez **Supprimer la politique SQS**.

     1. Utilisez la console Amazon SQS pour corriger la politique de la file d’attente après avoir supprimé la politique mal configurée. Pour plus d’informations, consultez [Configuration de stratégie d’accès dans Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-add-permissions.html) dans le *Guide du développeur Amazon SQS*.
   + Sélectionnez **Supprimer les informations d’identification racine** pour supprimer l’accès racine d’un compte membre. La suppression des informations d’identification de l’utilisateur racine supprime le mot de passe de l’utilisateur racine, les clés d’accès, les certificats de signature et désactive l’authentification multifactorielle (MFA) pour le compte membre.

     1. Choisissez **Supprimer les informations d’identification racine**.
   + Sélectionnez **Autoriser la récupération du mot de passe** pour récupérer les informations d’identification de l’utilisateur racine pour un compte membre.

     Cette option est disponible uniquement lorsque le compte membre ne possède pas d’informations d’identification d’utilisateur racine.

     1. Choisissez **Autoriser la récupération du mot de passe**.

     1. Après avoir effectué cette action privilégiée, la personne ayant accès à la boîte de réception de l’utilisateur racine pour le compte membre peut [réinitialiser le mot de passe de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html) et se connecter à l’utilisateur racine du compte membre.

## Effectuer une action privilégiée sur un compte membre (AWS CLI)
<a name="root-user-privileged-task_action-cli"></a>

**Pour lancer une session d'action privilégiée sur un compte membre depuis le AWS Command Line Interface**

1. Utilisez la commande suivante pour utiliser une session utilisateur racine : [aws sts assume-root](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-root.html).
**Note**  
Le point de terminaison global n’est pas pris en charge pour `sts:AssumeRoot`. Vous devez envoyer cette demande à un point de AWS STS terminaison régional. Pour de plus amples informations, veuillez consulter [Gérez AWS STS dans un Région AWS](id_credentials_temp_enable-regions.md).

   Lorsque vous lancez une session utilisateur racine privilégiée pour un compte membre, vous devez définir `task-policy-arn` permettant d’étendre la session à l’action privilégiée à effectuer au cours de la session. Vous pouvez utiliser l’une des politiques gérées AWS suivantes pour définir les actions de session privilégiées.
   + [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials)
   + [IAMCreateRootUserPassword](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMCreateRootUserPassword)
   + [IAMDeleteRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMDeleteRootUserCredentials)
   + [S3 UnlockBucketPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-S3UnlockBucketPolicy)
   + [SQSUnlockQueuePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SQSUnlockQueuePolicy)

   Pour limiter les actions qu'un compte de gestion ou un administrateur délégué peut effectuer au cours d'une session utilisateur root privilégiée, vous pouvez utiliser la clé de AWS STS condition [sts : TaskPolicyArn](reference_policies_iam-condition-keys.md#ck_taskpolicyarn).

    Dans l'exemple suivant, l'administrateur délégué suppose que root supprime les informations d'identification de l'utilisateur root pour l'ID du compte membre*111122223333*. 

   ```
   aws sts assume-root \
     --target-principal 111122223333 \
     --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials \
     --duration-seconds 900
   ```

1. Utilisez `SessionToken`, `AccessKeyId` et `SecretAccessKey` depuis la réponse pour effectuer des actions privilégiées dans le compte membre. Vous pouvez omettre le nom d’utilisateur et le mot de passe dans la requête afin d’utiliser par défaut le compte membre.
   + **Vérifiez l’état des informations d’identification de l’utilisateur racine**. Utilisez les commandes suivantes pour vérifier l’état des informations d’identification de l’utilisateur racine pour un compte membre.
     + [get-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-user.html)
     + [get-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-login-profile.html)
     + [list-access-keys](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-access-keys.html)
     + [list-signing-certificates](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-signing-certificates.html)
     + [list-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-mfa-devices.html)
     + [get-access-key-last-utilisé](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-access-key-last-used.html)
   + **Supprimez les informations d’identification de l’utilisateur racine**. Utilisez les commandes suivantes pour supprimer l’accès racine. Vous pouvez supprimer le mot de passe d’utilisateur racine, les clés d’accès, les certificats de signature, ainsi que désactiver l’authentification multifactorielle (MFA) pour supprimer tout accès et toute récupération de l’utilisateur racine.
     + [delete-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-login-profile.html)
     + [delete-access-key](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-access-key.html)
     + [delete-signing-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-signing-certificate.html)
     + [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html)
   + **Supprimez le compartiment Amazon S3**. Utilisez les commandes suivantes pour lire, modifier et supprimer une politique de compartiment mal configurée qui empêche tous les principaux d’accéder au compartiment Amazon S3.
     + [list-buckets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/list-buckets.html)
     + [get-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-bucket-policy.html)
     + [put-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-policy.html)
     + [delete-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/delete-bucket-policy.html)
   + **Supprimez la politique Amazon SQS.** Utilisez les commandes suivantes pour afficher et supprimer une politique Amazon Simple Queue Service qui refuse à tous les principaux l’accès à une file d’attente Amazon SQS.
     + [list-queues](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/list-queues.html)
     + [get-queue-url](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-url.html)
     + [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html)
     + [set-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/set-queue-attributes.html)
   + **Autorisez la récupération du mot de passe**. Utilisez les commandes suivantes pour afficher le nom d’utilisateur et récupérer les informations d’identification de l’utilisateur racine pour un compte membre.
     + [get-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-login-profile.html)
     + [create-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-login-profile.html)

## Effectuer une action privilégiée sur un compte membre (AWS API)
<a name="root-user-privileged-task_action-api"></a>

**Pour lancer une session pour une action privilégiée dans un compte membre depuis l' AWS API**

1. Utilisez la commande suivante pour assumer une session utilisateur root : [AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html).
**Note**  
Le point de terminaison global n'est pas pris en charge pour AssumeRoot. Vous devez envoyer cette demande à un point de AWS STS terminaison régional. Pour de plus amples informations, veuillez consulter [Gérez AWS STS dans un Région AWS](id_credentials_temp_enable-regions.md).

   Lorsque vous lancez une session utilisateur racine privilégiée pour un compte membre, vous devez définir `TaskPolicyArn` permettant d’étendre la session à l’action privilégiée à effectuer au cours de la session. Vous pouvez utiliser l'une des politiques AWS gérées suivantes pour définir les actions de session privilégiées.
   + [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials)
   + [IAMCreateRootUserPassword](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMCreateRootUserPassword)
   + [IAMDeleteRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMDeleteRootUserCredentials)
   + [S3 UnlockBucketPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-S3UnlockBucketPolicy)
   + [SQSUnlockQueuePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SQSUnlockQueuePolicy)

   Pour limiter les actions qu'un compte de gestion ou un administrateur délégué peut effectuer au cours d'une session utilisateur root privilégiée, vous pouvez utiliser la clé de AWS STS condition [sts : TaskPolicyArn](reference_policies_iam-condition-keys.md#ck_taskpolicyarn).

   Dans l'exemple suivant, l'administrateur délégué suppose que root lit, modifie et supprime une politique basée sur les ressources mal configurée pour un compartiment Amazon S3 pour l'ID de compte membre. *111122223333*

   ```
   https://sts.us-east-2.amazonaws.com/
     ?Version=2011-06-15
     &Action=AssumeRoot
     &TargetPrincipal=111122223333
     &PolicyArns.arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy 
     &DurationSeconds 900
   ```

1. Utilisez `SessionToken`, `AccessKeyId` et `SecretAccessKey` depuis la réponse pour effectuer des actions privilégiées dans le compte membre. Vous pouvez omettre le nom d’utilisateur et le mot de passe dans la requête afin d’utiliser par défaut le compte membre.
   + **Vérifiez l’état des informations d’identification de l’utilisateur racine**. Utilisez les commandes suivantes pour vérifier l’état des informations d’identification de l’utilisateur racine pour un compte membre.
     + [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)
     + [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)
     + [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)
     + [ListSigningCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSigningCertificates.html)
     + [ListMFADevices](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADevices.html)
     + [GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)
   + **Supprimez les informations d’identification de l’utilisateur racine**. Utilisez les commandes suivantes pour supprimer l’accès racine. Vous pouvez supprimer le mot de passe d’utilisateur racine, les clés d’accès, les certificats de signature, ainsi que désactiver l’authentification multifactorielle (MFA) pour supprimer tout accès et toute récupération de l’utilisateur racine.
     + [DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html)
     + [DeleteAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)
     + [DeleteSigningCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSigningCertificate.html)
     + [DeactivateMfaDevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)
   + **Supprimez le compartiment Amazon S3**. Utilisez les commandes suivantes pour lire, modifier et supprimer une politique de compartiment mal configurée qui empêche tous les principaux d’accéder au compartiment Amazon S3.
     + [ListBuckets](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListBuckets.html)
     + [GetBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketPolicy.html)
     + [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html)
     + [DeleteBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html)
   + **Supprimez la politique Amazon SQS.** Utilisez les commandes suivantes pour afficher et supprimer une politique Amazon Simple Queue Service qui refuse à tous les principaux l’accès à une file d’attente Amazon SQS.
     + [ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)
     + [GetQueueUrl](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueUrl.html)
     + [GetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html)
     + [SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)
   + **Autorisez la récupération du mot de passe**. Utilisez les commandes suivantes pour afficher le nom d’utilisateur et récupérer les informations d’identification de l’utilisateur racine pour un compte membre.
     + [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)
     + [CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)

# Authentification multifactorielle pour Utilisateur racine d'un compte AWS
<a name="enable-mfa-for-root"></a>

**Important**  
AWS vous recommande d'utiliser une clé d'accès ou une clé de sécurité pour les MFA, dans la AWS mesure du possible, car ils sont plus résistants aux attaques telles que le phishing. Pour de plus amples informations, veuillez consulter [Clés d’accès et clés de sécurité](#passkeys-security-keys-for-root).

L’authentification multifactorielle (MFA) est un mécanisme simple et efficace pour renforcer votre sécurité. Le premier facteur, votre mot de passe, est un secret que vous mémorisez, également appelé facteur de connaissance. Les autres facteurs peuvent être des facteurs liés à la possession (quelque chose que vous possédez, comme une clé de sécurité) ou des facteurs inhérents (quelque chose que vous êtes, comme un scan biométrique). Pour une sécurité accrue, nous vous recommandons vivement de configurer l'authentification multifactorielle (MFA) afin de protéger AWS vos ressources.

**Note**  
Tous les Compte AWS types (comptes autonomes, de gestion et comptes membres) nécessitent que l'authentification MFA soit configurée pour leur utilisateur root. Les utilisateurs doivent enregistrer le MFA dans les 35 jours suivant leur première tentative de connexion pour accéder au si le AWS Management Console MFA n'est pas déjà activé.

Vous pouvez activer le MFA pour les utilisateurs Utilisateur racine d'un compte AWS et IAM. Lorsque vous activez la MFA pour l’utilisateur racine, cela n’affecte que les informations d’identification de l’utilisateur racine. Pour en savoir plus sur l’activation de la MFA pour les utilisateurs IAM, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md).

**Note**  
Comptes AWS L'utilisation gérée AWS Organizations peut avoir la possibilité de [gérer de manière centralisée l'accès root aux](id_root-user.md#id_root-user-access-management) comptes des membres afin d'empêcher la récupération des informations d'identification et l'accès à grande échelle. Si cette option est activée, vous pouvez supprimer les informations d’identification de l’utilisateur racine des comptes membres, y compris les mots de passe et l’authentification multifactorielle (MFA), empêchant ainsi efficacement la connexion en tant qu’utilisateur racine, la récupération du mot de passe ou la configuration de la MFA. Si vous préférez conserver les méthodes de connexion par mot de passe, sécurisez votre compte en enregistrant l’authentification multifactorielle (MFA) afin de renforcer la protection de votre compte.

Avant d’activer la MFA pour votre utilisateur racine, vérifiez et [mettez à jour les paramètres de votre compte et les informations de contact](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html) pour vous assurer que vous avez accès à l’adresse e-mail et au numéro de téléphone. Si votre dispositif MFA est perdu, volé ou ne fonctionne pas, vous pouvez toujours vous connecter en tant qu'utilisateur racine en vérifiant votre identité à l'aide de cet e-mail et de ce numéro de téléphone. Pour en savoir plus sur la connexion à l'aide d'autres facteurs d'authentification, consultez [Restauration d’une identité protégée par MFA dans IAM](id_credentials_mfa_lost-or-broken.md). Pour désactiver cette fonction, contactez [AWS Support](https://console.aws.amazon.com/support/home#/). 

AWS prend en charge les types de MFA suivants pour votre utilisateur root :
+ [Clés d’accès et clés de sécurité](#passkeys-security-keys-for-root)
+ [Applications d’authentification virtuelle](#virtual-auth-apps-for-root)
+ [Jetons TOTP matériels](#hardware-totp-token-for-root)

## Clés d’accès et clés de sécurité
<a name="passkeys-security-keys-for-root"></a>

Gestion des identités et des accès AWS prend en charge les clés d'accès et les clés de sécurité pour la MFA. Basées sur les normes FIDO, les clés d'accès utilisent la cryptographie à clé publique pour fournir une authentification solide, résistante au hameçonnage et plus sécurisée que les mots de passe. AWS prend en charge deux types de clés d'accès : les clés d'accès liées à l'appareil (clés de sécurité) et les clés d'accès synchronisées.
+ **Clés de sécurité** : il s'agit de périphériques physiques YubiKey, tels que a, utilisés comme deuxième facteur d'authentification. Une clé de sécurité unique peut prendre en charge plusieurs comptes utilisateur racine et utilisateurs IAM. 
+ **Clés d’accès synchronisées** : elles utilisent des gestionnaires d’informations d’identification provenant de fournisseurs tels que Google, Apple, Microsoft et de services tiers tels que 1Password, Dashlane et Bitwarden comme deuxième facteur.

Vous pouvez utiliser des authentificateurs biométriques intégrés, tels que Touch ID sur Apple MacBooks, pour déverrouiller votre gestionnaire d'identifiants et vous y connecter. AWS Les clés d’accès sont créées avec le fournisseur de votre choix à l’aide de votre empreinte digitale, de votre visage ou du code PIN de votre appareil. Vous pouvez utiliser une clé d’accès d’authentification entre appareils (CDA) provenant d’un appareil, comme un appareil mobile ou une clé de sécurité matérielle, pour vous connecter sur un autre appareil, tel qu’un ordinateur portable. Pour plus d’informations, consultez [Authentification entre appareils](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda) (CDA).

Vous pouvez synchroniser les clés d'accès sur tous vos appareils pour faciliter les connexions et améliorer la convivialité AWS et la récupérabilité. Pour plus d’informations sur l’activation des clés d’accès et des clés de sécurité, consultez [Activation d’une clé d’accès ou d’une clé de sécurité pour l’utilisateur racine (console)](enable-fido-mfa-for-root.md).

La FIDO Alliance tient à jour une liste de tous les [produits certifiés FIDO](https://fidoalliance.org/certification/fido-certified-products/) qui sont compatibles avec les spécifications FIDO.

## Applications d’authentification virtuelle
<a name="virtual-auth-apps-for-root"></a>

Une application d’authentification virtuelle s’exécute sur un téléphone ou un autre dispositif et émule un dispositif physique. Les applications d'authentification virtuelle mettent en œuvre l'algorithme TOTP ([mot de passe unique à durée limitée](https://datatracker.ietf.org/doc/html/rfc6238)) et prennent en charge plusieurs jetons sur un seul dispositif. L’utilisateur doit saisir un code valide à partir du dispositif lorsqu’il y est invité lors de la connexion. Chaque jeton attribué à un utilisateur doit être unique. Un utilisateur ne peut pas saisir un code provenant du jeton d’un autre utilisateur pour s’authentifier.

Nous vous recommandons d'utiliser un dispositif MFA virtuel pendant l'attente de l'approbation d'achat du matériel ou pendant que vous attendez de recevoir votre matériel. Pour obtenir une liste des applications que vous pouvez utiliser comme dispositifs MFA virtuels, consultez [Authentification multifactorielle (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1). Pour obtenir des instructions sur la configuration d'un périphérique MFA virtuel avec AWS, voir. [Activation d’un dispositif MFA virtuel pour l’utilisateur racine (console)](enable-virt-mfa-for-root.md)

## Jetons TOTP matériels
<a name="hardware-totp-token-for-root"></a>

Un dispositif matériel qui génère un code numérique à six chiffres basé sur l’[algorithme TOTP (mot de passe unique à durée limitée)](https://datatracker.ietf.org/doc/html/rfc6238). L'utilisateur doit saisir un code valide à partir du dispositif sur une deuxième page web lors de la connexion. Chaque dispositif MFA attribué à un utilisateur doit être unique. Un utilisateur ne peut pas saisir un code à partir du périphérique d'un autre utilisateur pour s'authentifier. Pour plus d’informations sur les dispositifs MFA matériels pris en charge, consultez [Authentification multifactorielle (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1). Pour plus d'informations sur la configuration d'un jeton TOTP matériel avec AWS, consultez [Activation d'un jeton TOTP matériel pour l'utilisateur root de l' (console)](enable-hw-mfa-for-root.md).

Si vous souhaitez utiliser un dispositif MFA physique, nous vous recommandons d’utiliser les clés de sécurité FIDO comme alternative aux périphériques TOTP matériels. Les clés de sécurité FIDO offrent les avantages de ne pas nécessiter de batterie, de résister au hameçonnage et de prendre en charge plusieurs utilisateurs racine et utilisateurs IAM sur un seul appareil pour une sécurité renforcée.

**Topics**
+ [Clés d’accès et clés de sécurité](#passkeys-security-keys-for-root)
+ [Applications d’authentification virtuelle](#virtual-auth-apps-for-root)
+ [Jetons TOTP matériels](#hardware-totp-token-for-root)
+ [Activation d’une clé d’accès ou d’une clé de sécurité pour l’utilisateur racine (console)](enable-fido-mfa-for-root.md)
+ [Activation d’un dispositif MFA virtuel pour l’utilisateur racine (console)](enable-virt-mfa-for-root.md)
+ [Activation d'un jeton TOTP matériel pour l'utilisateur root de l' (console)](enable-hw-mfa-for-root.md)

# Activation d’une clé d’accès ou d’une clé de sécurité pour l’utilisateur racine (console)
<a name="enable-fido-mfa-for-root"></a>

Vous pouvez configurer et activer une clé d'accès pour votre utilisateur root AWS Management Console uniquement, et non depuis l' AWS API AWS CLI or. <a name="enable_fido_root"></a>

**Pour activer une clé d’accès ou une clé de sécurité pour l’utilisateur racine (console)**

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.

1. À droite de la barre de navigation, choisissez le nom de votre compte, et cliquez sur **Security credentials** (Informations d'identification de sécurité).  
![\[Informations d'identification de sécurité dans le menu de navigation\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. Sur la page **Mes informations d’identification de sécurité** de votre utilisateur racine, sous **Authentification multifactorielle (MFA)**, choisissez **Attribuer un dispositif MFA**.

1. Sur la page **Nom du dispositif MFA**, saisissez un **Nom du dispositif**, choisissez **Clé d’accès ou Clé de sécurité**, puis choisissez **Suivant**.

1. Dans **Configurer le dispositif**, configurez votre clé d’accès. Créez une clé d’accès avec des données biométriques telles que votre visage ou votre empreinte digitale, avec le code PIN d’un appareil, ou en insérant la clé de sécurité FIDO dans le port USB de votre ordinateur et en la touchant.

1. Suivez les instructions de votre navigateur pour choisir un fournisseur de clé d’accès ou l’endroit où vous souhaitez stocker votre clé d’accès afin de l’utiliser sur tous vos dispositifs. 

1. Sélectionnez **Continuer**.

Vous avez maintenant enregistré votre clé d'accès pour l'utiliser avec AWS. La prochaine fois que vous utiliserez vos informations d’identification d’utilisateur racine pour vous connecter, vous devrez vous authentifier à l’aide de votre clé d’accès pour terminer le processus de connexion.

Pour obtenir de l’aide afin de résoudre les problèmes liés à votre clé de sécurité FIDO, consultez [Résolution des problèmes liés aux clés d’accès et aux clés de sécurité FIDO](troubleshoot_mfa-fido.md).

# Activation d’un dispositif MFA virtuel pour l’utilisateur racine (console)
<a name="enable-virt-mfa-for-root"></a>

Vous pouvez utiliser le AWS Management Console pour configurer et activer un périphérique MFA virtuel pour votre utilisateur root. Pour activer les appareils MFA pour le Compte AWS, vous devez être connecté à l' AWS aide de vos informations d'identification d'utilisateur root. 

**Pour configurer et activer un dispositif MFA virtuel à utiliser avec votre utilisateur racine (console)**

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.

1. À droite de la barre de navigation, choisissez le nom de votre compte, et cliquez sur **Security credentials** (Informations d'identification de sécurité).  
![\[Informations d'identification de sécurité dans le menu de navigation\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. Dans la section **Multi-Factor Authentication (MFA)** (Authentification multifactorielle (MFA)), sélectionnez **Assign MFA device** (Attribuer un dispositif MFA).

1. Dans l'assistant, saisissez un nom dans le champ **Nom du dispositif**, sélectionnez **Application Authenticator**, puis cliquez sur **Suivant**.

   IAM génère et affiche les informations de configuration du dispositif MFA virtuel, notamment un graphique de code QR. Le graphique est une représentation de la clé de configuration secrète que l'on peut saisir manuellement sur des dispositifs qui ne prennent pas en charge les codes QR.

1. Ouvrez l'application MFA virtuelle sur l'appareil. 

   Si l'application MFA virtuelle prend en charge plusieurs comptes ou plusieurs dispositifs MFA virtuels, choisissez l'option permettant de créer un compte ou un dispositif MFA virtuel.

1. La manière la plus simple de configurer l'application consiste à utiliser l'application pour analyser le code QR. Si vous ne pouvez pas analyser le code, vous pouvez saisir les informations de configuration manuellement. Le code QR et la clé de configuration secrète générés par IAM sont liés à votre compte Compte AWS et ne peuvent pas être utilisés avec un autre compte. En revanche, ils peuvent être réutilisés pour configurer un nouveau dispositif MFA pour votre compte si vous perdez l'accès au dispositif MFA d'origine.
   + Pour utiliser le code QR pour configurer le dispositif MFA virtuel, dans l'assistant, choisissez **Show QR code (Afficher le code QR)**. Ensuite, suivez les instructions de l'application pour scanner le code. Par exemple, vous pouvez avoir besoin de choisir l'icône de caméra ou une commande similaire à **Scan account barcode (Analyser le code-barres du compte)**, puis d'utiliser la caméra du périphérique pour analyser le code QR.
   + Dans l'assistant **Set up device** (Configurer le dispositif), sélectionnez **Show secret key** (Afficher la clé secrète), puis saisissez la clé secrète dans votre application MFA.
**Important**  
Faites une sauvegarde sécurisée du code QR ou de la clé de configuration secrète ou assurez-vous d'activer plusieurs dispositifs MFA pour votre compte. Vous pouvez enregistrer jusqu'à **huit** appareils MFA de n'importe quelle combinaison des [types de MFA actuellement pris en charge auprès de vos Utilisateur racine d'un compte AWS utilisateurs et de ceux](https://aws.amazon.com/iam/features/mfa/) d'IAM. Un dispositif MFA virtuel peut devenir indisponible, par exemple, si vous perdez le smartphone hébergeant le dispositif MFA virtuel. Si cela se produit et que vous ne parvenez pas à vous connecter à votre compte sans autre dispositif MFA associé à l'utilisateur ou même d'après [Récupération d'un dispositif MFA d'utilisateur racine](id_credentials_mfa_lost-or-broken.md#root-mfa-lost-or-broken), vous ne pourrez pas vous connecter à votre compte et vous devrez [contacter le service client](https://support.aws.amazon.com/#/contacts/aws-mfa-support) pour supprimer la protection MFA du compte. 

   Le périphérique commence à générer des numéros à six chiffres.

1. Dans l'assistant, dans la zone **MFA Code 1** (Code MFA 1), saisissez le mot de passe unique qui s'affiche actuellement sur le dispositif MFA virtuel. Attendez jusqu'à 30 secondes pour que le dispositif génère un nouveau mot de passe unique. Saisissez ensuite le second mot de passe unique dans la zone **MFA Code 2 (Code MFA 2)**. Choisissez **Add MFA** (Ajouter un dispositif MFA). 
**Important**  
Envoyez votre demande immédiatement après avoir généré le code. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, le dispositif MFA s'associe avec succès à l'utilisateur mais est désynchronisé. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez [resynchroniser le dispositif](id_credentials_mfa_sync.md).

L'appareil est prêt à être utilisé avec AWS. Pour plus d'informations sur l'utilisation de l'authentification MFA avec l'interface AWS Management Console, veuillez consulter [Connexion compatible avec la MFA](console_sign-in-mfa.md).

# Activation d'un jeton TOTP matériel pour l'utilisateur root de l' (console)
<a name="enable-hw-mfa-for-root"></a>

Vous pouvez configurer et activer un dispositif MFA physique pour votre utilisateur root AWS Management Console uniquement, et non à partir de l'API AWS CLI or AWS .

**Note**  
Il se peut que vous remarquiez des textes différents, tels que **se connecter à l'aide de MFA** et **dépanner votre dispositif d'authentification**. Toutefois, les mêmes fonctions sont fournies. Dans les deux cas, si vous ne pouvez pas vérifier l’adresse e-mail et le numéro de téléphone de votre compte en utilisant d’autres facteurs d’authentification, contactez [AWS Support](https://aws.amazon.com/forms/aws-mfa-support) pour supprimer votre configuration de MFA.<a name="enable_physical_root"></a>

**Pour activer un jeton TOTP matériel pour votre propre utilisateur racine (console)**

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.

1. À droite de la barre de navigation, choisissez le nom de votre compte, et cliquez sur **Security credentials** (Informations d'identification de sécurité).  
![\[Informations d'identification de sécurité dans le menu de navigation\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. Développez la section **Multi-factor authentication (MFA) (authentification multifactorielle (MFA))**.

1. Choisissez **Assign MFA device** (Attribuer un dispositif MFA).

1. Dans l'assistant, tapez le **nom du dispositif**, choisissez **Hardware TOTP token** (Jeton TOTP matériel), puis **Next** (Suivant).

1. Dans la zone **Numéro de série**, saisissez le numéro de série qui se trouve à l'arrière du dispositif MFA.

1. Dans la zone **MFA code 1**, saisissez le code à six chiffres qui s'affichent sur le dispositif MFA. Vous devrez peut-être appuyer sur le bouton situé à l'avant du périphérique pour afficher le numéro.  
![\[Tableau de bord IAM, dispositif MFA\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/MFADevice.png)

1. Attendez 30 secondes que le périphérique actualise le code, puis saisissez la nouvelle série de six chiffres dans la zone **MFA code 2**. Vous devrez peut-être appuyer à nouveau sur le bouton situé à l'avant du périphérique pour afficher le second numéro.

1. Choisissez **Add MFA** (Ajouter un dispositif MFA). Le dispositif MFA est à présent associé au Compte AWS.
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes d'authentification. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, l'dispositif MFA s'associe avec succès à l'utilisateur mais se désynchronise. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez [resynchroniser le dispositif](id_credentials_mfa_sync.md).

   La prochaine fois que vous utiliserez les informations d'identification d'utilisateur racine, vous devrez saisir un code du dispositif MFA.

# Changez le mot de passe du Utilisateur racine d'un compte AWS
<a name="root-user-password"></a>

Vous pouvez modifier l'adresse e-mail et le mot de passe à partir de la page [Informations d'identification](https://console.aws.amazon.com/iam/home?#security_credential) ou de la page **Compte**. Vous pouvez également choisir **Mot de passe oublié ?** sur la page de AWS connexion pour réinitialiser votre mot de passe.

Pour modifier le mot de passe de l'utilisateur root, vous devez vous connecter en tant qu'utilisateur Utilisateur racine d'un compte AWS et non en tant qu'utilisateur IAM. Pour savoir comment réinitialiser un mot de passe d'utilisateur racine *oublié*, veuillez consulter [Réinitialisation d’un mot de passe d’utilisateur racine perdu ou oublié](reset-root-password.md). 

Pour protéger votre mot de passe, il est important de respecter les bonnes pratiques suivantes :
+ Modifiez régulièrement votre mot de passe. 
+ Gardez votre mot de passe confidentiel, car toute personne qui le connaît peut accéder à votre compte.
+ Utilisez un mot de passe différent AWS de celui que vous utilisez sur d'autres sites. 
+ Evitez les mots de passe trop faciles à deviner, notamment : `secret`, `password`, `amazon` ou `123456`. Évitez également les mots du dictionnaire, votre nom, votre adresse électronique ou d'autres informations personnelles que quelqu'un pourrait facilement obtenir.

**Important**  
Comptes AWS géré à l'aide d'un [accès root centralisé AWS Organizations](id_root-user.md#id_root-user-access-management) peut être activé pour les comptes des membres. Ces comptes membres ne disposent pas d’informations d’identification de l’utilisateur racine, ne peuvent pas se connecter en tant qu’utilisateur racine et ne peuvent pas récupérer le mot de passe de l’utilisateur racine. Contactez votre administrateur si vous devez effectuer une tâche qui nécessite les informations d’identification de l’utilisateur racine.

------
#### [ AWS Management Console ]

**Pour changer le mot de passe de l'utilisateur racine**
**Autorisations minimales**  
Pour effectuer les étapes suivantes, vous devez au moins disposer des autorisations IAM suivantes :  
Vous devez vous connecter en tant qu'utilisateur Compte AWS root, ce qui ne nécessite aucune autorisation Gestion des identités et des accès AWS (IAM) supplémentaire. Vous ne pouvez pas effectuer ces étapes en tant qu'utilisateur ou rôle IAM.

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.

1. Dans le coin supérieur droit de la console, choisissez votre nom ou votre numéro de compte, puis sélectionnez **Informations d’identification de sécurité**.

1. Sur la page **Compte**, en regard de **Paramètres du compte**, choisissez **Modifier**. Pour des raisons de sécurité, vous êtes invité à vous réauthentifier.
**Note**  
Si l'option **Modifier** ne s'affiche pas, il est probable que vous ne soyez pas connecté en tant qu'utilisateur root de votre compte. Vous ne pouvez pas modifier les paramètres du compte lorsque vous êtes connecté en tant qu'utilisateur ou rôle IAM.

1. Sur la page **Mettre à jour les paramètres du compte**, sous **Mot de passe**, sélectionnez **Modifier**.

1. Sur la page **Mettre à jour votre mot de passe**, remplissez les champs **Mot de passe actuel**, **Nouveau mot de passe** et **Confirmer le nouveau mot de passe**.
**Important**  
Assurez-vous de choisir un mot de passe fort. Bien que vous puissiez définir une politique de mot de passe de compte pour les utilisateurs IAM, celle-ci ne s'applique pas à votre utilisateur root.

   AWS nécessite que votre mot de passe remplisse les conditions suivantes :
   + Avoir un minimum de 8 caractères et un maximum de 128 caractères
   + Inclure au minimum trois des types de caractères suivants : majuscules, minuscules, chiffres, et les symboles \$1 @ \$1 \$1 % ^ & \$1 () <> [] \$1\$1 \$1 \$1 \$1 - =
   + Il ne doit pas être identique à votre Compte AWS nom ou à votre adresse e-mail.

1. Sélectionnez **Enregistrer les modifications**.

------
#### [ AWS CLI or AWS SDK ]

Cette tâche n'est pas prise en charge dans AWS CLI ou par une opération d'API provenant de l'un des AWS SDKs. Vous ne pouvez effectuer cette tâche qu'à l'aide du AWS Management Console.

------

# Réinitialisation d’un mot de passe d’utilisateur racine perdu ou oublié
<a name="reset-root-password"></a>

Lorsque vous avez créé votre Compte AWS, vous avez fourni une adresse e-mail et un mot de passe. Voici vos Utilisateur racine d'un compte AWS informations d'identification. Si vous oubliez votre mot de passe utilisateur racine, vous pouvez le réinitialiser à partir de la AWS Management Console.

Comptes AWS géré à l'aide d'un [accès root centralisé AWS Organizations](id_root-user.md#id_root-user-access-management) peut être activé pour les comptes des membres. Ces comptes membres ne disposent pas d’informations d’identification de l’utilisateur racine, ne peuvent pas se connecter en tant qu’utilisateur racine et ne peuvent pas récupérer le mot de passe de l’utilisateur racine. Contactez votre administrateur si vous devez effectuer une tâche qui nécessite les informations d’identification de l’utilisateur racine.

**Important**  
**Vous rencontrez des difficultés pour vous connecter à AWS ?** Assurez-vous que vous êtes sur la bonne [page de connexion AWS](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html) pour votre type d'utilisateur. Si vous êtes le Utilisateur racine d'un compte AWS (propriétaire du compte), vous pouvez vous connecter à AWS l'aide des informations d'identification que vous avez définies lors de la création du Compte AWS. Si vous êtes un utilisateur IAM, votre administrateur de compte peut vous fournir les informations d'identification que vous pouvez utiliser pour vous connecter à AWS. Si vous avez besoin d'assistance, n'utilisez pas le lien de commentaires sur cette page, car le formulaire est reçu par l'équipe de AWS documentation, non Support. Sur la page [Contactez-nous](https://aws.amazon.com/contact-us/), sélectionnez **Impossible de vous connecter à votre AWS compte**, puis choisissez l'une des options d'assistance disponibles.

**Pour réinitialiser votre mot de passe utilisateur racine**

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.
**Note**  
 Si vous vous êtes connecté à [AWS Management Console](https://console.aws.amazon.com/) avec des informations d'identification d'*utilisateur IAM*, vous devez vous déconnecter pour pouvoir réinitialiser le mot de passe utilisateur racine. Si la page de connexion utilisateur IAM spécifique au compte s'affiche, choisissez **Identifiez-vous à l'aide de vos informations de connexion au compte racine** située près du bas de la page. Si nécessaire, fournissez l'adresse e-mail de votre compte et choisissez **Next (Suivant)** pour accéder à la page **Root user sign in (Connexion de l'utilisateur racine)**.

1. Choisissez **Forgot your password? (Mot de passe oublié ?)**.
**Note**  
Si vous êtes un utilisateur IAM, cette option n'est pas disponible. L'option **Mot de passe oublié ?** n'est disponible que pour le compte utilisateur root. Les utilisateurs IAM doivent demander à leur administrateur de réinitialiser un mot de passe oublié. Pour plus d'informations, voir [J'ai oublié le mot de passe utilisateur IAM associé à mon AWS compte](https://docs.aws.amazon.com/signin/latest/userguide/troubleshooting-sign-in-issues.html#troubleshoot-forgot-iam-password). Si vous vous connectez via le portail AWS d'accès, consultez [Réinitialisation de votre mot de passe utilisateur IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/resetpassword-accessportal.html).

1. Indiquez l'adresse e-mail associée au compte. Indiquez ensuite le texte CAPTCHA et choisissez **Continue (Continuer)**.

1. Vérifiez que l'e-mail qui vous est associé ne contient Compte AWS pas de message provenant d'Amazon Web Services. L'e-mail peut provenir d'une adresse se terminant par dans `@verify.signin.aws`. Suivez les instructions de l'e-mail. Si vous ne voyez pas l'e-mail dans votre compte, vérifiez le dossier des courriers indésirables. Si vous n'avez plus accès à l'e-mail, consultez la section [Je n'ai pas accès à l'e-mail associé à mon AWS compte](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-troubleshooting.html#credentials-not-working-console) dans le *guide de Connexion à AWS l'utilisateur*.

# Création de clés d’accès pour l’utilisateur racine
<a name="id_root-user_manage_add-key"></a>

**Avertissement**  
Nous vous recommandons vivement de ne **pas** créer de paires de clés d'accès pour votre utilisateur root. Étant donné [que seules quelques tâches nécessitent l'utilisateur root](id_root-user.md#root-user-tasks) et que vous les effectuez généralement rarement, nous vous recommandons de vous connecter au AWS Management Console pour effectuer les tâches de l'utilisateur root. Avant de créer des clés d'accès, passez en revue les [alternatives aux clés d'accès à long terme](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys).

Bien que cela ne soit pas recommandé, vous pouvez créer des clés d'accès pour votre utilisateur root afin de pouvoir exécuter des commandes dans le AWS Command Line Interface (AWS CLI) ou utiliser des opérations d'API à partir de l' AWS SDKs un des identifiants utilisateur root. Lorsque vous créez des clés d'accès, vous créez l'ID de clé d'accès et la clé d'accès secrète sous forme d'ensemble. Lors de la création de la clé AWS d'accès, vous avez la possibilité de visualiser et de télécharger la partie clé d'accès secrète de la clé d'accès. Si vous ne la téléchargez pas ou si vous la perdez, vous pouvez supprimez la clé d'accès, puis en créer une nouvelle. Vous pouvez créer des clés d'accès utilisateur root à l'aide de la console ou de AWS l'API. AWS CLI

Une clé d'accès nouvellement créée a le statut *active*, ce qui signifie que vous pouvez l'utiliser pour les appels de CLI et d'API. Vous pouvez attribuer jusqu'à deux clés d'accès à l'utilisateur root.

Les clés d'accès qui ne sont pas utilisées doivent être désactivées. Lorsqu'une clé d'accès est inactive, vous ne pouvez pas l'utiliser pour les appels d'API. Les clés inactives comptent toujours dans votre limite. Vous pouvez créer ou supprimer une clé d'accès à tout moment. Toutefois, la suppression d'une clé d'accès est définitive et vous ne pourrez plus la récupérer.

------
#### [ AWS Management Console ]

**Pour créer une clé d'accès pour Utilisateur racine d'un compte AWS**
**Autorisations minimales**  
Pour effectuer les étapes suivantes, vous devez au moins disposer des autorisations IAM suivantes :  
Vous devez vous connecter en tant qu'utilisateur Compte AWS root, ce qui ne nécessite aucune autorisation Gestion des identités et des accès AWS (IAM) supplémentaire. Vous ne pouvez pas effectuer ces étapes en tant qu'utilisateur ou rôle IAM.

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.

1. Dans le coin supérieur droit de la console, choisissez votre nom ou votre numéro de compte, puis sélectionnez **Informations d'identification de sécurité**. 

1. Dans la section **Clés d’accès**, choisissez **Créer une clé d’accès**. Si cette option n'est pas disponible, cela signifie que vous avez déjà atteint le nombre maximum de clés d'accès. Vous devez supprimer l'une des clés d'accès existantes avant de pouvoir créer une clé. Pour plus d'informations, veuillez consulter [Quotas d'objets IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities). 

1. Sur la page **Alternatives aux clés d'accès d'utilisateur root**, passez en revue les recommandations de sécurité. Pour continuer, cochez la case, puis choisissez **Créer une clé d’accès**. 

1. Sur la page **Récupérer la clé d'accès**, votre **ID de clé d'accès** est affiché. 

1. Sous **Clé d'accès secrète**, choisissez **Afficher** puis copiez l'ID de la clé d'accès et la clé secrète dans la fenêtre de votre navigateur et collez-les dans un endroit sûr. Vous pouvez également choisir l'option **Télécharger un fichier .csv** qui téléchargera un fichier nommé `rootkey.csv` contenant l'ID de la clé d'accès et la clé secrète. Enregistrez le fichier à un endroit sûr.

1. Sélectionnez **Exécuté**. Lorsque vous n'avez plus besoin d'utiliser la clé d'accès, [nous vous recommandons de la supprimer](id_root-user_manage_delete-key.md), ou au moins d'envisager de la désactiver afin que personne ne puisse en abuser.

------
#### [ AWS CLI & SDKs ]

**Pour créer une clé d'accès pour l'utilisateur root**
**Note**  
Pour exécuter la commande ou l'opération d'API suivante en tant qu'utilisateur root, vous devez déjà disposer d'une paire de clés d'accès active. Si vous n'avez aucune clé d'accès, créez la première clé d'accès à l'aide de l' AWS Management Console. Vous pouvez ensuite utiliser les informations d'identification de cette première clé d'accès avec le AWS CLI pour créer la deuxième clé d'accès ou pour supprimer une clé d'accès.
+ AWS CLI: [vison create-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)  
**Example**  

  ```
  $ aws iam create-access-key
  {
      "AccessKey": {
          "UserName": "MyUserName",
          "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
          "Status": "Active",
          "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
          "CreateDate": "2021-04-08T19:30:16+00:00"
      }
  }
  ```
+ AWS API : [CreateAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html)dans la *référence d'API IAM*. 

------

# Suppression d’une clé d’accès de l’utilisateur racine
<a name="id_root-user_manage_delete-key"></a>

Vous pouvez utiliser l' AWS Management Console API AWS CLI ou l' AWS API pour supprimer les clés d'accès de l'utilisateur root.

------
#### [ AWS Management Console ]

**Pour supprimer une clé d'accès de l'utilisateur root**
**Autorisations minimales**  
Pour effectuer les étapes suivantes, vous devez au moins disposer des autorisations IAM suivantes :  
Vous devez vous connecter en tant qu'utilisateur Compte AWS root, ce qui ne nécessite aucune autorisation Gestion des identités et des accès AWS (IAM) supplémentaire. Vous ne pouvez pas effectuer ces étapes en tant qu'utilisateur ou rôle IAM.

1. Ouvrez la [console de gestion AWS](https://console.aws.amazon.com/) et connectez-vous à l’aide de vos informations d’identification d’utilisateur racine.

   Pour obtenir des instructions, voir [Se connecter en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html) dans le *guide de Connexion à AWS l'utilisateur*.

1. Dans le coin supérieur droit de la console, choisissez votre nom ou votre numéro de compte, puis sélectionnez **Informations d'identification de sécurité**. 

1. Dans la section **Clés d'accès**, sélectionnez la clé d'accès que vous souhaitez supprimer, puis sous **Actions**, choisissez **Supprimer**.
**Note**  
Vous pouvez également **Désactiver** une clé d'accès au lieu de la supprimer définitivement. Vous pourrez ainsi la réutiliser ultérieurement sans avoir à modifier l'ID de clé ou la clé secrète. Lorsque la clé est inactive, toute tentative de l'utiliser dans les demandes adressées à l' AWS API échoue et l'accès est refusé en cas d'erreur.

1. Dans la boîte de dialogue **Supprimer <access key ID>**, choisissez **Désactiver**, saisissez l'ID de la clé d'accès pour confirmer que vous souhaitez la supprimer, puis choisissez **Supprimer**. 

------
#### [ AWS CLI & SDKs ]

**Pour supprimer une clé d'accès de l'utilisateur root**
**Autorisations minimales**  
Pour effectuer les étapes suivantes, vous devez au moins disposer des autorisations IAM suivantes :  
Vous devez vous connecter en tant qu'utilisateur Compte AWS root, ce qui ne nécessite aucune autorisation Gestion des identités et des accès AWS (IAM) supplémentaire. Vous ne pouvez pas effectuer ces étapes en tant qu'utilisateur ou rôle IAM.
+ AWS CLI: [cime delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)  
**Example**  

  ```
  $ aws iam delete-access-key \
      --access-key-id AKIAIOSFODNN7EXAMPLE
  ```

  Cette commande ne produit aucune sortie lorsqu’elle réussit.
+ AWS API : [DeleteAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## Tâches nécessitant les informations d'identification de l'utilisateur root
<a name="root-user-tasks"></a>

Nous vous recommandons de [configurer un utilisateur administratif AWS IAM Identity Center pour effectuer les](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) tâches quotidiennes et accéder aux AWS ressources. Toutefois, vous ne pouvez effectuer les tâches énumérées ci-dessous que si vous vous connectez en tant qu'utilisateur root d'un compte.

Pour simplifier la gestion des informations d'identification des utilisateurs root privilégiés sur les comptes des membres AWS Organizations, vous pouvez activer l'accès root centralisé pour vous aider à sécuriser de manière centralisée un accès hautement privilégié à votre Comptes AWS. [Gestion centralisée de l’accès root pour les comptes membres](#id_root-user-access-management)vous permet de supprimer de manière centralisée et d'empêcher la restauration à long terme des informations d'identification des utilisateurs root, améliorant ainsi la sécurité des comptes au sein de votre entreprise. Après avoir activé cette fonctionnalité, vous pouvez effectuer les tâches privilégiées suivantes sur les comptes membres.
+ Supprimez les informations d’identification de l’utilisateur racine du compte membre pour empêcher la restauration du compte de l’utilisateur racine. Vous pouvez également autoriser la récupération du mot de passe pour récupérer les informations d’identification de l’utilisateur racine pour un compte membre.
+ Supprimez une politique de compartiment mal configurée qui empêche tous les principaux d’accéder à un compartiment Amazon S3.
+ Supprimez une politique Amazon Simple Queue Service qui refuse à tous les principaux l’accès à une file d’attente Amazon SQS.

**Tâches de gestion de compte**
+ [Modifiez vos paramètres Compte AWS .](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html) Les appareils autonomes Comptes AWS qui n'en font pas partie AWS Organizations nécessitent des informations d'identification root pour mettre à jour l'adresse e-mail, le mot de passe de l'utilisateur root et les clés d'accès de l'utilisateur root. Les autres paramètres du compte, tels que le nom du compte, les coordonnées, les contacts alternatifs, la devise de paiement préférée Régions AWS, ne nécessitent pas d'informations d'identification d'utilisateur root.
**Note**  
AWS Organizations, avec toutes les fonctionnalités activées, peut être utilisé pour gérer les paramètres des comptes membres de manière centralisée à partir du compte de gestion et des comptes d’administration délégués. Les utilisateurs IAM autorisés ou les rôles IAM dans le compte de gestion et dans les comptes d'administrateur délégué peuvent fermer les comptes des membres et mettre à jour les adresses e-mail racine, les noms des comptes, les informations de contact, les contacts secondaires et les comptes Régions AWS des membres. 
+ [Fermez votre Compte AWS.](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html) Les appareils autonomes Comptes AWS qui n'en font pas partie AWS Organizations nécessitent des informations d'identification root pour fermer le compte. Avec AWS Organizations, vous pouvez fermer les comptes des membres de manière centralisée depuis le compte de gestion et les comptes d'administration délégués.
+ [Restaurer les autorisations de l'utilisateur IAM.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) Si un utilisateur IAM révoque accidentellement ses propres autorisations, vous pouvez vous connecter en tant qu'utilisateur root pour modifier les politiques et restaurer ces autorisations.

**Tâches de facturation**
+ [Activer l'accès IAM à la console de gestion de la facturation et des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html#ControllingAccessWebsite-Activate).
+ Certaines tâches de facturation sont limitées à l’utilisateur racine. Consultez le guide de [gestion Compte AWS d'un](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html) AWS Billing utilisateur intégré pour plus d'informations.
+ Afficher certaines factures fiscales. Un utilisateur IAM disposant de l'ViewBillingautorisation [aws-portal :](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html#user-permissions) peut consulter et télécharger les factures de TVA depuis AWS l'Europe, mais pas depuis AWS Inc. ou Amazon Internet Services Private Limited (AISPL).

**AWS GovCloud (US) Tâches**
+ [Inscrivez-vous à AWS GovCloud (US)](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/getting-started-sign-up.html).
+ Demandez les clés d'accès de l'utilisateur root au AWS GovCloud (US) compte auprès de AWS Support.

**Tâches Amazon EC2**
+ [Inscrit en tant que vendeur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-general.html) sur le Marketplace des instances réservées.

**AWS KMS Tâche**
+ Si une AWS Key Management Service clé devient ingérable, un administrateur peut la récupérer en contactant Support ; toutefois, il Support répond au numéro de téléphone principal de votre utilisateur root pour obtenir l'autorisation en confirmant le ticket OTP.

**Tâche Amazon Mechanical Turk**
+  [Associez votre compte Compte AWS à votre compte MTurk demandeur.](https://docs.aws.amazon.com/AWSMechTurk/latest/AWSMechanicalTurkGettingStartedGuide/SetUp.html#accountlinking)

**Tâches Amazon Simple Storage Service**
+ [Configurer un compartiment Amazon S3 pour activer MFA (authentification multifactorielle)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html).
+ [Modifier ou supprimer une politique de compartiment Amazon S3 qui refuse tous les principaux](https://aws.amazon.com/premiumsupport/knowledge-center/change-vpc-endpoint-s3-bucket-policy/).

  Vous pouvez utiliser des actions privilégiées pour déverrouiller un compartiment Amazon S3 dont la politique de compartiment est mal configurée. Pour en savoir plus, consultez [Réaliser une tâche privilégiée sur un compte AWS Organizations membre](id_root-user-privileged-task.md).

**Tâche Amazon Simple Queue Service**
+ [Modifier ou supprimer une politique de ressources Amazon SQS qui refuse tous les principaux](https://aws.amazon.com/premiumsupport/knowledge-center/sqs-queue-access-issues-deny-policy).

  Vous pouvez utiliser des actions privilégiées pour déverrouiller une file d’attente Amazon SQS dont la politique basée sur les ressources est mal configurée. Pour en savoir plus, consultez [Réaliser une tâche privilégiée sur un compte AWS Organizations membre](id_root-user-privileged-task.md).

## Ressources supplémentaires
<a name="id_root-user-resources"></a>

Pour plus d'informations sur l'utilisateur AWS root, consultez les ressources suivantes :
+ Pour obtenir de l’aide sur les problèmes liés aux utilisateurs racine, consultez [Résolution de problèmes relatifs à l’utilisateur racine](troubleshooting_root-user.md).
+ Pour gérer de manière centralisée les adresses e-mail des utilisateurs root dans AWS Organizations, consultez [la section Mise à jour de l'adresse e-mail de l'utilisateur root pour un compte membre](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html) dans le *guide de AWS Organizations l'utilisateur*.

Les articles suivants fournissent des informations supplémentaires sur l'utilisation de l'utilisateur root.
+ [Quelles sont les meilleures pratiques pour sécuriser mes ressources Compte AWS et les siennes ?](https://repost.aws/knowledge-center/security-best-practices)
+ [Comment créer une règle d' EventBridge événement pour m'avertir que mon utilisateur root a été utilisé ?](https://repost.aws/knowledge-center/root-user-account-eventbridge-rule) 
+ [Surveiller et notifier l' Utilisateur racine d'un compte AWS activité](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 
+ [Surveiller l'activité de l'utilisateur root IAM](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-iam-root-user-activity.html) 

# Utilisateurs IAM
<a name="id_users"></a>

**Important**  
 [Les meilleures pratiques](best-practices.md) IAM recommandent de demander aux utilisateurs humains d'utiliser la fédération avec un fournisseur d'identité pour accéder à l'aide d'informations d'identification temporaires plutôt que d' AWS utiliser des utilisateurs IAM dotés d'informations d'identification à long terme. Nous vous recommandons de n’utiliser les utilisateurs IAM que pour les [cas d’utilisation spécifiques](gs-identities-iam-users.md) non pris en charge par les utilisateurs fédérés.

Un *utilisateur IAM* est une entité que vous créez dans votre Compte AWS. L’utilisateur IAM représente l’utilisateur humain ou la charge de travail qui utilise l’utilisateur IAM pour interagir avec les ressources AWS . Un utilisateur IAM se compose d’un nom et d’informations d’identification.

Un utilisateur IAM doté d'autorisations d'administrateur n'est pas un Utilisateur racine d'un compte AWS. Pour de plus amples informations sur l'utilisateur racine, veuillez consulter [Utilisateur racine d'un compte AWS](id_root-user.md).

## Comment AWS identifier un utilisateur IAM
<a name="id_users_create_aws-identifiers"></a>

Lorsque vous créez un utilisateur IAM, IAM implémente les éléments suivants pour l'identifier :
+ Un « nom convivial » pour l'utilisateur IAM. Il s'agit du nom que vous avez spécifié lors de la création de l'utilisateur IAM, par exemple `Richard` ou `Anaya`. Ce sont les noms que vous voyez dans AWS Management Console. Étant donné que les noms d'utilisateur IAM apparaissent dans Amazon Resource Names (ARNs), nous vous déconseillons d'inclure des informations d'identification personnelle dans le nom IAM. Reportez-vous à [Exigences relatives aux noms IAM](reference_iam-quotas.md#reference_iam-quotas-names) pour connaître les exigences et les restrictions relatives aux noms IAM.
+ Un Amazon Resource Name (ARN) pour l'utilisateur IAM. Vous utilisez l'ARN lorsque vous devez identifier de manière unique l'utilisateur IAM dans l'ensemble du AWS site. Par exemple, vous pouvez utiliser un ARN pour spécifier l'utilisateur IAM en tant que `Principal` dans la politique IAM d'un compartiment Amazon S3. L'ARN d'un utilisateur IAM peut se présenter comme suit : 

  `arn:aws:iam::account-ID-without-hyphens:user/Richard`
+ Un identifiant unique pour l'utilisateur IAM. Cet ID est renvoyé uniquement lorsque vous utilisez l'API, Tools for Windows PowerShell ou AWS CLI pour créer l'utilisateur IAM ; il ne figure pas dans la console.

Pour plus d'informations sur ces identifiants, consultez [Identifiants IAM](reference_identifiers.md).

## Utilisateurs IAM et informations d'identification
<a name="id_users_creds"></a>

Vous pouvez y accéder de différentes manières AWS en fonction des informations d'identification de l'utilisateur IAM :
+ [**Mot de passe de la console**](id_credentials_passwords.md) : un mot de passe que l'utilisateur IAM peut entrer pour se connecter à des sessions interactives telles que l' AWS Management Console. La désactivation du mot de passe (accès à la console) pour un utilisateur IAM l'empêche de se connecter à l' AWS Management Console aide de ses informations d'identification. Cela ne modifie pas ses autorisations ni ne l'empêche d'accéder à la console à l'aide d'un rôle endossé. Les utilisateurs IAM dont l'accès à la console est activé peuvent également utiliser ces mêmes informations d'identification pour s'authentifier AWS CLI et accéder au SDK à l'aide de la commande. `aws login` AWS CLI Ces utilisateurs devront disposer d'[SignInLocalDevelopmentAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SignInLocalDevelopmentAccess.html)autorisations. [Pour plus de détails, reportez-vous à la section Authentification et identifiants d'accès AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html) dans le *guide de AWS Command Line Interface l'utilisateur*. 
+ [**Clés d'accès**](id_credentials_access-keys.md) : utilisées pour passer des appels programmatiques à AWS. Toutefois, il existe des alternatives plus sécurisées à envisager avant de créer des clés d'accès pour les utilisateurs IAM. Pour plus d'informations, consultez [Considérations et alternatives relatives aux clés d'accès à long terme](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys) dans *Références générales AWS*. Si l'utilisateur IAM dispose de clés d'accès actives, celles-ci continuent de fonctionner et autorisent l'accès via les AWS CLI Outils pour Windows PowerShell, AWS l'API ou l'Application AWS Console Mobile.
+ [**Clés SSH à utiliser avec CodeCommit**](id_credentials_ssh-keys.md) : une clé publique SSH au format OpenSSH qui peut être utilisée pour s'authentifier auprès d' CodeCommit.
+ [**Certificats de serveur**](id_credentials_server-certs.md) : SSL/TLS certificats que vous pouvez utiliser pour vous authentifier auprès de certains AWS services. Nous vous recommandons d'utiliser AWS Certificate Manager (ACM) pour provisionner, gérer et déployer vos certificats de serveur. Utilisez IAM uniquement lorsque vous devez prendre en charge des connexions HTTPS dans une région non prise en charge par ACM. Pour savoir quelles régions prennent en charge ACM, consultez [Points de terminaison et quotas AWS Certificate Manager](https://docs.aws.amazon.com/general/latest/gr/acm.html) dans *Références générales AWS*.

Vous pouvez choisir les informations d'identification qui conviennent à votre utilisateur IAM. Lorsque vous utilisez la AWS Management Console pour créer un utilisateur IAM, vous devez au moins choisir d'inclure un mot de passe ou des clés d'accès à la console. Par défaut, un tout nouvel utilisateur IAM créé à l'aide de l' AWS API AWS CLI or ne possède aucune information d'identification. Vous devez créer le type d'informations d'identification pour un utilisateur IAM en fonction de votre cas d'utilisation. 

Vous disposez des options suivantes pour administrer les mots de passe, les clés d'accès et les dispositifs d'authentification multifactorielle (MFA) :
+ **[Gérer les mots de passe pour vos utilisateurs IAM](id_credentials_passwords.md).** Créez et modifiez les mots de passe permettant d'accéder à AWS Management Console. Définissez une politique de mot de passe afin d'appliquer une complexité minimale pour les mots de passe. Autorisez les utilisateurs IAM à modifier leurs propres mots de passe. 
+ **[Gérer les clés d'accès pour vos utilisateurs IAM](id_credentials_access-keys.md).** Créez et mettez à jour les clés d'accès afin de permettre l'accès par programmation aux ressources de votre compte. 
+ **[Activez l'authentification multifactorielle (MFA) pour l'utilisateur IAM.](id_credentials_mfa.md)** Selon les [bonnes pratiques](best-practices.md), nous vous recommandons d'exiger une authentification multifactorielle pour tous les utilisateurs IAM de votre compte. Avec MFA, les utilisateurs IAM doivent fournir deux formes d’identification : tout d’abord, ils fournissent les informations d’identification faisant partie de leur identité utilisateur (un mot de passe ou une clé d’accès). En outre, ils fournissent un code numérique temporaire généré sur un matériel ou par une application sur un smartphone ou une tablette.
+ **[Recherche de mots de passe et clés d'accès inutilisés](id_credentials_finding-unused.md).** Toute personne disposant d'un mot de passe ou de clés d'accès pour votre compte ou d'un utilisateur IAM de votre compte a accès à vos AWS ressources. En matière de sécurité, les [pratiques exemplaires](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html) consistent à supprimer les mots de passe et les clés d’accès dont les utilisateurs IAM n’ont plus besoin.
+ **[Téléchargez un rapport d'informations d'identification pour votre compte](id_credentials_getting-report.md).** Vous pouvez générer et télécharger un rapport sur les informations d'identification qui répertorie tous les utilisateurs IAM de votre compte et le statut de leurs diverses informations d'identification, notamment leurs mots de passe, clés d'accès et dispositifs MFA. Pour les mots de passe et les clés d'accès, le rapport d'informations d'identification indique leur dernière date d'utilisation.

## Rôles et autorisations IAM
<a name="id_users_perms"></a>

Par défaut, un nouvel utilisateur IAM ne dispose d'aucune [autorisation](access.md) pour faire quoi que ce soit. Ils ne sont pas autorisés à effectuer des AWS opérations ou à accéder à des AWS ressources. Lorsque vous configurez des utilisateurs IAM individuels, il est également possible de leur affecter des autorisations individuellement. Vous pouvez attribuer des autorisations administratives à quelques utilisateurs, qui pourront ensuite administrer vos AWS ressources et même créer et gérer d'autres utilisateurs IAM. Dans la plupart des cas, toutefois, vous souhaitez limiter les autorisations d'un utilisateur aux seules tâches (AWS actions ou opérations) et aux ressources nécessaires à la tâche. 

Prenons l'exemple d'un utilisateur nommé Diego. Lorsque vous créez l'utilisateur IAM`Diego`, vous lui créez un mot de passe et vous lui associez des autorisations qui lui permettent de lancer une EC2 instance Amazon spécifique et de lire (`GET`) les informations d'une table d'une base de données Amazon RDS. Pour les procédures relatives à la création des utilisateurs IAM et à l’octroi d’informations d’identification initiales, consultez [Créez un utilisateur IAM dans votre Compte AWS](id_users_create.md). Pour les procédures relatives à la modification des autorisations pour les utilisateurs existants, consultez [Modification des autorisations pour un utilisateur IAM](id_users_change-permissions.md). Pour les procédures relatives à la modification des clés d'accès et du mot de passe de l'utilisateur, consultez [Mots de passe utilisateur dans AWS](id_credentials_passwords.md) et [Gestion des clés d’accès pour les utilisateurs IAM](id_credentials_access-keys.md).

Vous pouvez également ajouter une limite des autorisations à vos utilisateurs IAM. Une limite d'autorisations est une fonctionnalité avancée qui vous permet d'utiliser des politiques AWS gérées pour limiter le maximum d'autorisations qu'une politique basée sur l'identité peut accorder à un utilisateur ou à un rôle IAM. Pour plus d'informations sur les types de politiques et les utilisations, veuillez consulter [Politiques et autorisations dans Gestion des identités et des accès AWS](access_policies.md).

## Utilisateurs et comptes IAM
<a name="id_users_accounts"></a>

Chaque utilisateur IAM est associé à un seul et même Compte AWS. Comme les utilisateurs IAM sont définis au sein de votre Compte AWS entreprise, ils n'ont pas besoin de disposer d'un mode de paiement enregistré auprès AWS de. Toute AWS activité effectuée par les utilisateurs IAM sur votre compte est facturée sur votre compte.

Le nombre et la taille des ressources IAM d'un AWS compte sont limités. Pour de plus amples informations, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md).

## Utilisateurs IAM en tant que comptes de service
<a name="id_users_service_accounts"></a>

Un utilisateur IAM est une ressource dans IAM à laquelle des informations d'identification et ses autorisations sont associées. Un utilisateur IAM peut représenter une personne ou une application qui utilise ses informations d'identification pour exécuter des demandes AWS . En général, ceci est appelé un *compte de service*. Si vous choisissez d'utiliser les informations d'identification à long terme d'un utilisateur IAM dans votre application, **n'incorporez pas directement les clés d'accès dans le code de votre application.** Le AWS SDKs et le vous AWS Command Line Interface permettent de placer les clés d'accès dans des emplacements connus afin de ne pas avoir à les conserver dans le code. Pour de plus amples informations, consultez [Gestion correcte des clés d'accès utilisateur IAM](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#iam-user-access-keys) (français non garanti) dans *Références générales AWS*. En tant que bonne pratique, vous pouvez également [utiliser des informations d'identification de sécurité temporaires (rôles IAM) au lieu des clés d'accès à long terme](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#use-roles).

# Comment les utilisateurs d'IAM se connectent à AWS
<a name="id_users_sign-in"></a>

Pour vous connecter en AWS Management Console tant qu'utilisateur IAM, vous devez fournir votre identifiant de compte ou votre alias de compte en plus de votre nom d'utilisateur et de votre mot de passe. Lorsque votre administrateur a créé votre utilisateur IAM dans la console, il a dû vous envoyer vos informations d'identification de connexion, notamment votre nom d'utilisateur et l'URL de la page de connexion à votre compte, qui inclut votre ID de compte ou votre alias de compte. 

```
https://My_AWS_Account_ID.signin.aws.amazon.com/console/
```

**Conseil**  
Pour créer un marque-page pour la page de connexion à votre compte dans votre navigateur web, vous devez saisir manuellement l'URL de connexion de votre compte lors de la création du marque-page. N'utilisez pas la fonction « Marquer cette page » de votre navigateur web, en raison des redirections qui risquent de masquer l'URL de connexion. 

Vous pouvez également vous connecter au point de terminaison général suivant et saisir manuellement votre ID de compte ou votre alias de compte :

```
[https://console.aws.amazon.com/](https://console.aws.amazon.com/)
```

Pour plus de commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser le nom d'utilisateur IAM et les informations de compte. La prochaine fois que l'utilisateur accède à une page du AWS Management Console, la console utilise le cookie pour le rediriger vers la page de connexion au compte.

Vous n'avez accès qu'aux AWS ressources spécifiées par votre administrateur dans la politique associée à votre identité d'utilisateur IAM. Pour travailler dans la console, vous devez disposer des autorisations nécessaires pour effectuer les actions effectuées par la console, telles que la liste et la création de AWS ressources. Pour plus d’informations, consultez [Gestion de l'accès aux AWS ressources](access.md) et [Exemples de politiques basées sur l'identité IAM](access_policies_examples.md).

**Note**  
Si votre organisation dispose déjà d'un système d'identité, vous souhaiterez peut-être créer une option d'authentification unique (SSO). Le SSO permet aux utilisateurs d'accéder AWS Management Console à votre compte sans qu'ils aient besoin d'une identité d'utilisateur IAM. L'authentification unique élimine également la nécessité pour les utilisateurs de se connecter au site de votre organisation et de s'y connecter AWS séparément. Pour de plus amples informations, veuillez consulter [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md). 

**Enregistrement des informations de connexion dans CloudTrail**  
Si vous activez CloudTrail l'enregistrement des événements de connexion dans vos journaux, vous devez savoir comment CloudTrail choisit où enregistrer les événements.
+ Si les utilisateurs se connectent directement à une console, ils sont redirigés vers un point de terminaison de connexion international ou régional, si la console de service sélectionnée prend en charge les régions. Par exemple, la page d'accueil de la console principale prend en charge les régions, donc si vous vous connectez à l'URL suivante :

  ```
  https://alias.signin.aws.amazon.com/console
  ```

  vous êtes redirigé vers un point de connexion régional tel que`https://us-east-2.signin.aws.amazon.com`, ce qui entraîne une entrée de CloudTrail journal régional dans le journal régional de l'utilisateur :

  En revanche, la console Amazon S3 ne prend pas en charge les régions, donc si vous vous connectez à l'URL suivante

  ```
  https://alias.signin.aws.amazon.com/console/s3
  ```

  AWS vous redirige vers le point de connexion global à l'adresse`https://signin.aws.amazon.com`, ce qui entraîne une entrée de CloudTrail journal globale.
+ Vous pouvez demander manuellement un point de terminaison de connexion régional spécifique en vous connectant à la page d'accueil régionale de la console principale à l'aide d'une syntaxe d'URL similaire à ce qui suit :

  ```
  https://alias.signin.aws.amazon.com/console?region=ap-southeast-1
  ```

  AWS vous redirige vers le point de connexion `ap-southeast-1` régional et entraîne un événement de CloudTrail journal régional.

Pour plus d'informations sur IAM CloudTrail et IAM, consultez la section [Journalisation des événements IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html) avec. CloudTrail

Si les utilisateurs ont besoin d'un accès par programmation pour utiliser votre compte, vous pouvez créer une paire de clés d'accès (un ID de clé d'accès et une clé d'accès secrète) pour chaque utilisateur. Toutefois, il existe des alternatives plus sécurisées à envisager avant de créer des clés d'accès pour les utilisateurs. Pour plus d'informations, consultez [Considérations et alternatives relatives aux clés d'accès à long terme](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys) dans *Références générales AWS*.

## Ressources supplémentaires
<a name="id_users_sign-in-additional-resources"></a>

Les ressources suivantes peuvent vous aider à en savoir plus sur la AWS connexion.
+ Le [Guide de l’utilisateur de la connexion AWS](https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html) vous aide à comprendre les différentes façons dont vous pouvez vous connecter à Amazon Web Services (AWS), en fonction de votre type d’utilisateur.
+ Vous pouvez vous connecter à un maximum de cinq identités différentes simultanément dans un seul navigateur Web dans l’ AWS Management Console. Pour plus de détails, consultez la section [Connexion à plusieurs comptes](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html) dans le *Guide de démarrage AWS Management Console *.

# Connexion compatible avec la MFA
<a name="console_sign-in-mfa"></a>

Les utilisateurs pour lesquels l'[authentification multifactorielle (MFA)](id_credentials_mfa.md) est configurée doivent utiliser leurs dispositifs MFA pour se connecter à l' AWS Management Console. Une fois que l'utilisateur a saisi ses informations de connexion, AWS vérifie dans son compte si le MFA est requis pour cet utilisateur. 

**Important**  
Si vous utilisez des informations d'identification par clé d'accès et clé secrète pour AWS Management Console un accès direct AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)via l'appel d'API, la MFA ne sera PAS requise. Pour de plus amples informations, veuillez consulter [Utilisation des clés d’accès et des informations d’identification de clé secrète pour l’accès à la console](securing_access-keys.md#console-access-security-keys).

Les rubriques suivantes fournissent des informations sur la façon dont les utilisateurs effectuent leur connexion lorsque l'authentification MFA est requise. 

**Topics**
+ [Plusieurs dispositifs MFA activés](#console_sign-in-multiple-mfa)
+ [Clé de sécurité FIDO](#console_sign-in-mfa-fido)
+ [Dispositif MFA virtuel](#console_sign-in-mfa-virtual)
+ [Jeton TOTP matériel](#console_sign-in-mfa-hardware)

## Plusieurs dispositifs MFA activés
<a name="console_sign-in-multiple-mfa"></a>

Si un utilisateur se connecte en AWS Management Console tant qu'utilisateur Compte AWS root ou utilisateur IAM avec plusieurs appareils MFA activés pour ce compte, il n'a besoin d'utiliser qu'un seul appareil MFA pour se connecter. Une fois que l'utilisateur s'est authentifié à l'aide du mot de passe de l'utilisateur, il sélectionne le type de dispositif MFA qu'il souhaite utiliser pour terminer l'authentification. L'utilisateur est ensuite invité à s'authentifier avec le type de dispositif qu'il a sélectionné. 

## Clé de sécurité FIDO
<a name="console_sign-in-mfa-fido"></a>

Si l'authentification MFA est requise pour l'utilisateur, une deuxième page de connexion s'affiche. L'utilisateur a besoin d'utiliser la clé de sécurité FIDO.

**Note**  
Les utilisateurs de Google Chrome ne doivent choisir aucune des options disponibles dans la fenêtre contextuelle qui demande **Verify your identity with amazon.com** (Vérifiez votre identité auprès d'amazon.com). Il vous suffit d'appuyer sur la clé de sécurité.

Contrairement aux autres dispositifs MFA, les clés de sécurité FIDO ne se désynchronisent pas. Les administrateurs peuvent désactiver une clé de sécurité FIDO si elle est perdue ou endommagée. Pour de plus amples informations, veuillez consulter [Désactivation des dispositifs MFA (console)](id_credentials_mfa_disable.md#deactive-mfa-console).

Pour plus d'informations sur les navigateurs compatibles WebAuthn et les appareils compatibles FIDO compatibles, AWS consultez. [Configurations prises en charge pour l’utilisation des clés d’accès et des clés de sécurité](id_credentials_mfa_fido_supported_configurations.md)

## Dispositif MFA virtuel
<a name="console_sign-in-mfa-virtual"></a>

Si l'authentification MFA est requise pour l'utilisateur, une deuxième page de connexion s'affiche. Dans le champ **Code MFA**, l'utilisateur doit entrer le code numérique fourni par l'application MFA.

Si le code MFA est correct, l'utilisateur peut accéder à l’interface AWS Management Console. Si le code est incorrect, l'utilisateur peut refaire une tentative avec un autre code. 

Un dispositif MFA virtuel peut être désynchronisé. Si un utilisateur ne parvient pas à se connecter AWS Management Console après plusieurs tentatives, il est invité à synchroniser le périphérique MFA virtuel. L'utilisateur peut suivre les instructions affichées à l'écran pour synchroniser le dispositif MFA virtuel. Pour plus d'informations sur la façon dont vous pouvez synchroniser un appareil pour le compte d'un utilisateur de votre Compte AWS, consultez[Resynchronisation des dispositifs MFA virtuels et matériels](id_credentials_mfa_sync.md). 

## Jeton TOTP matériel
<a name="console_sign-in-mfa-hardware"></a>

Si l'authentification MFA est requise pour l'utilisateur, une deuxième page de connexion s'affiche. Dans le champ **Code MFA**, l'utilisateur doit entrer le code numérique fourni par un jeton TOTP matériel. 

Si le code MFA est correct, l'utilisateur peut accéder à l’interface AWS Management Console. Si le code est incorrect, l'utilisateur peut refaire une tentative avec un autre code. 

Un jeton TOTP matériel peut être désynchronisé. Si un utilisateur ne parvient pas à se connecter AWS Management Console après plusieurs tentatives, il est invité à synchroniser le dispositif à jetons MFA. L'utilisateur peut suivre les instructions affichées à l'écran pour synchroniser le dispositif de jeton MFA. Pour plus d'informations sur la façon dont vous pouvez synchroniser un appareil pour le compte d'un utilisateur de votre Compte AWS, consultez[Resynchronisation des dispositifs MFA virtuels et matériels](id_credentials_mfa_sync.md). 

# Créez un utilisateur IAM dans votre Compte AWS
<a name="id_users_create"></a>

**Important**  
 [Les meilleures pratiques](best-practices.md) IAM recommandent d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à l'aide d'informations d'identification temporaires plutôt que d' AWS utiliser des utilisateurs IAM dotés d'informations d'identification à long terme. Nous vous recommandons de n’utiliser les utilisateurs IAM que pour les [cas d’utilisation spécifiques](gs-identities-iam-users.md) non pris en charge par les utilisateurs fédérés.

Le processus de création d’un utilisateur IAM et sa capacité à exécuter des tâches se compose des étapes suivantes :

1. Créez l'[utilisateur dans AWS Management Console les AWS CLI](getting-started-workloads.md) outils pour Windows PowerShell ou à l'aide d'une opération d' AWS API. Si vous créez l'utilisateur dans le AWS Management Console, les étapes 1 à 4 sont gérées automatiquement, en fonction de vos choix. Si vous créez les utilisateurs IAM par programme, vous devez exécuter chacune de ces étapes individuellement.

1. Créez les informations d'identification pour l'utilisateur, en fonction du type d'accès dont il a besoin :
   + **Activer l'accès à la console — *facultatif*** : si l'utilisateur doit accéder au AWS Management Console, [créez un mot de passe pour l'utilisateur](id_credentials_passwords_admin-change-user.md). La désactivation de l'accès à la console pour un utilisateur l'empêche de se connecter à l' AWS Management Console à l'aide de son nom d'utilisateur et de son mot de passe. Cela ne modifie pas ses autorisations ni ne l'empêche d'accéder à la console à l'aide d'un rôle endossé.
**Astuce**  
Créez uniquement les informations d'identification dont a besoin l'utilisateur. Par exemple, pour un utilisateur qui a uniquement besoin d'un accès via le AWS Management Console, ne créez pas de clés d'accès.

1. Donner à l’utilisateur les autorisations nécessaires pour effectuer les tâches requises. Nous vous recommandons de placer vos utilisateurs IAM dans des groupes et de gérer leurs autorisations par le biais de politiques attachées à ces groupes. Toutefois, vous pouvez également accorder des autorisations en attachant des politiques d’autorisations directement à l’utilisateur. Si vous utilisez la console pour ajouter l’utilisateur, vous pouvez copier les autorisations d’un utilisateur existant vers le nouvel utilisateur.

   Vous pouvez également ajouter une [limite des autorisations](access_policies_boundaries.md) pour limiter les autorisations de l’utilisateur en spécifiant une politique qui définit les autorisations maximales que l’utilisateur peut avoir. Les limites des autorisations n’accordent aucune autorisation.

   Pour obtenir des instructions sur la création d’une politique d’autorisation personnalisée à utiliser pour accorder des autorisations ou définir une limite des autorisations, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](access_policies_create.md).

1. (Facultatif) Ajoutez des métadonnées à l'utilisateur en associant des balises. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Fournissez à l'utilisateur les informations nécessaires à la connexion. Cela inclut le mot de passe et l'URL de la console de la page de connexion au compte sur laquelle l'utilisateur saisit ces informations d'identification. Pour plus d’informations, veuillez consulter [Comment les utilisateurs d'IAM se connectent à AWS](id_users_sign-in.md).

1. (Facultatif) Configurez l'[authentification multifacteur (MFA)](id_credentials_mfa.md) pour l'utilisateur. La MFA demande à l'utilisateur de fournir un one-time-use code chaque fois qu'il se connecte au. AWS Management Console

1. (Facultatif) Accordez aux utilisateurs IAM les autorisations requises pour gérer leurs propres informations d’identification. (Par défaut, les utilisateurs IAM ne sont pas autorisés à gérer leurs propres informations d’identification.) Pour de plus amples informations, veuillez consulter [Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe](id_credentials_passwords_enable-user-change.md).
**Note**  
Si vous utilisez la console pour créer l’utilisateur et que vous sélectionnez l’**Utilisateur doit créer un nouveau mot de passe à la prochaine connexion (recommandé)**, l’utilisateur dispose des autorisations requises.

Pour plus d'informations sur les autorisations requises pour créer un utilisateur, consultez [Autorisations requises pour accéder aux autres ressources IAM](access_permissions-required.md).

Pour de plus amples informations sur la création d’utilisateurs IAM pour des cas d’utilisation particuliers, consultez les rubriques suivantes :
+ [Création d’un utilisateur IAM pour l’accès d’urgence](getting-started-emergency-iam-user.md)
+ [Création d’un utilisateur IAM pour les charges de travail qui ne peuvent pas utiliser de rôles IAM](getting-started-workloads.md)

# Affichage des utilisateurs IAM
<a name="id_users_list"></a>

Vous pouvez répertorier les utilisateurs IAM de votre groupe IAM Compte AWS ou d'un groupe IAM spécifique, et répertorier tous les groupes IAM auxquels appartient un utilisateur. Pour plus d'informations sur les autorisations requises pour répertorier des utilisateurs, consultez [Autorisations requises pour accéder aux autres ressources IAM](access_permissions-required.md). 

## Pour répertorier tous les utilisateurs IAM de votre compte
<a name="id_users_manage_list-users"></a>

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**. 

La console affiche les utilisateurs IAM de votre Compte AWS.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)`

------
#### [ API ]

Appelez l’opération suivante :
+ `[ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` 

------

## Pour répertorier les utilisateurs dans un groupe IAM
<a name="id_users_manage_list-users-group"></a>

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs).

1. Choisissez le nom du groupe d’utilisateurs. 

Les utilisateurs IAM membres du groupe sont répertoriés dans l’onglet **Utilisateurs**.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)`

------
#### [ API ]

Appelez l’opération suivante :
+ `[GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)` 

------

## Pour répertorier tous les groupes IAM auxquels appartient un utilisateur
<a name="id_users_manage_list-groups-users"></a>

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste des **Users** (Utilisateurs), choisissez le nom d'utilisateur IAM. 

1. Sélectionnez l’onglet **Groupes** pour afficher la liste des groupes qui incluent l’utilisateur actuel.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)`

------
#### [ API ]

Appelez l’opération suivante :
+ `[ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)` 

------

## Étapes suivantes
<a name="id_users_list-next-steps"></a>

Une fois que vous avez une liste de vos utilisateurs IAM, vous pouvez renommer, supprimer ou désactiver un utilisateur IAM en suivant les procédures suivantes.
+ [Renommer un utilisateur IAM](id_users_rename.md)
+ [Suppression ou désactivation d’un utilisateur IAM](id_users_remove.md)

# Renommer un utilisateur IAM
<a name="id_users_rename"></a>

**Note**  
En tant que [bonne pratique](best-practices.md), nous vous recommandons de demander aux utilisateurs humains d'utiliser la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires. Si vous suivez les bonnes pratiques, vous ne gérez pas les utilisateurs et les groupes IAM. Au lieu de cela, vos utilisateurs et vos groupes sont gérés en dehors de l'extérieur AWS et peuvent accéder aux AWS ressources en tant qu'*identité fédérée*. Une identité fédérée est un utilisateur de l'annuaire des utilisateurs de votre entreprise, un fournisseur d'identité Web, le AWS Directory Service, le répertoire Identity Center ou tout utilisateur qui accède AWS aux services à l'aide des informations d'identification fournies par le biais d'une source d'identité. Les identités fédérées utilisent les groupes définis par leur fournisseur d'identité. Si vous en utilisez AWS IAM Identity Center, consultez la section [Gérer les identités dans IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) dans le *Guide de l'AWS IAM Identity Center utilisateur* pour plus d'informations sur la création d'utilisateurs et de groupes dans IAM Identity Center.

Amazon Web Services fournit plusieurs outils permettant de gérer les utilisateurs IAM dans votre Compte AWS. Vous pouvez répertorier les utilisateurs IAM de votre compte ou d’un groupe d’utilisateurs, ou dresser la liste de tous les groupes IAM auxquels appartient un utilisateur. Vous pouvez renommer ou modifier le chemin d'accès d'un utilisateur IAM. Si vous passez à l'utilisation d'identités fédérées au lieu d'utilisateurs IAM, vous pouvez supprimer un utilisateur IAM de votre compte AWS ou désactiver l'utilisateur.

Pour plus d'informations sur l'ajout, la modification ou la suppression de politiques gérées pour un utilisateur IAM, consultez [Modification des autorisations pour un utilisateur IAM](id_users_change-permissions.md). Pour plus d'informations sur la gestion des politiques en ligne pour les utilisateurs IAM, consultez [Ajout et suppression d'autorisations basées sur l'identité IAM](access_policies_manage-attach-detach.md), [Modification de politiques IAM](access_policies_manage-edit.md) et [Suppression de politiques IAM](access_policies_manage-delete.md). En guise de bonne pratique, utilisez des politiques gérées plutôt que des politiques en ligne. Les *politiques gérées par AWS * octroient des autorisations pour de nombreux cas d'utilisation courants. 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 peuvent être utilisées par tous les AWS clients. En conséquence, 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 spécifiques à vos cas d'utilisation. Pour de plus amples informations, veuillez consulter [AWS politiques gérées](access_policies_managed-vs-inline.md#aws-managed-policies). Pour plus d'informations sur les politiques AWS gérées conçues pour des fonctions professionnelles spécifiques, consultez[AWS politiques gérées pour les fonctions professionnelles](access_policies_job-functions.md).

Pour en savoir plus sur la validation des politiques IAM, consultez [Validation de politique IAM](access_policies_policy-validator.md).

**Astuce**  
[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) peut analyser les services et les actions que vos rôles IAM utilisent, puis générer une politique précise que vous pouvez utiliser. Après avoir testé chaque stratégie générée, vous pouvez la déployer dans votre environnement de production. Cela garantit que vous n'accordez que les autorisations requises à vos charges de travail. Pour plus d'informations sur la génération de politiques, consultez [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).

Pour de plus amples informations sur la gestion des mots de passe utilisateur IAM, consultez [Gérer les mots de passe des utilisateurs IAM](id_credentials_passwords_admin-change-user.md).

## Renommer un utilisateur IAM
<a name="id_users_renaming"></a>

Pour modifier le nom ou le chemin d'un utilisateur AWS CLI, vous devez utiliser l' AWS API Outils pour Windows PowerShell. La console ne comporte aucune option permettant de renommer un utilisateur. Pour plus d'informations sur les autorisations requises pour renommer un utilisateur, consultez [Autorisations requises pour accéder aux autres ressources IAM](access_permissions-required.md). 

Lorsque vous modifiez le nom ou le chemin d'accès d'un utilisateur, voici ce qui suit se produit : 
+ Toutes les politiques attachées à l'utilisateur restent dans l'utilisateur sous le nouveau nom.
+ L’utilisateur reste dans les mêmes groupes IAM sous le nouveau nom.
+ L'ID unique de l'utilisateur demeure le même. Pour plus d'informations sur le caractère unique IDs, consultez[Identifiants uniques](reference_identifiers.md#identifiers-unique-ids).
+ Toutes les ressources ou politiques de rôle qui font référence à l'utilisateur *en tant que principal* (l'utilisateur se voit accorder l'accès) sont mises à jour automatiquement pour utiliser le nouveau nom ou chemin. Par exemple, toutes les politiques basées sur des files d'attente dans Amazon SQS ou les politiques basées sur des ressources dans Amazon S3 sont mises à jour automatiquement pour utiliser le nouveau nom ou chemin. 

IAM ne met pas automatiquement à jour les politiques qui font référence à l'utilisateur *en tant que ressource* de manière à utiliser le nouveau nom ou chemin ; vous devez le faire manuellement. Par exemple, imaginons qu'une politique est attachée à l'utilisateur `Richard` et qu'elle lui permet de gérer ses informations d'identification de sécurité. Si un administrateur renomme `Richard` en `Rich`, administrateur doit également mettre à jour cette politique pour changer la ressource de :

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Richard
```

à :

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Rich
```

C'est également vrai si un administrateur modifie le chemin : il doit également mettre à jour la politique pour refléter le nouveau chemin de l'utilisateur. 

### Pour renommer un utilisateur
<a name="id_users_manage_list-users-rename"></a>
+ AWS CLI : [aws iam update-user](https://docs.aws.amazon.com/cli/latest/reference/iam/update-user.html)
+ AWS API : [UpdateUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateUser.html) 

# Suppression ou désactivation d’un utilisateur IAM
<a name="id_users_remove"></a>

[Les meilleures pratiques](best-practices.md#remove-credentials) recommandent de supprimer les utilisateurs IAM non utilisés de votre Compte AWS. Si vous souhaitez conserver les informations d’identification de l’utilisateur IAM pour une utilisation ultérieure, au lieu de les supprimer du compte, vous pouvez désactiver l’accès de l’utilisateur. Pour de plus amples informations, veuillez consulter [Désactivation d'un utilisateur IAM](#id_users_deactivating).

**Avertissement**  
Une fois qu’un utilisateur IAM et ses clés d’accès sont supprimés, ils ne peuvent pas être restaurés ou récupérés.

## Prérequis : affichage de l’accès de l’utilisateur IAM
<a name="users-manage_prerequisites"></a>

Avant de supprimer un utilisateur, passez en revue ses activités récentes au niveau du service. Ceci permet d’éviter de supprimer l’accès à partir d’un principal (personne ou application) qui l’utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md).

## Suppression d’un utilisateur IAM (console)
<a name="id_users_deleting_console"></a>

Lorsque vous utilisez le AWS Management Console pour supprimer un utilisateur IAM, IAM supprime automatiquement les informations associées suivantes : 
+ Identificateur de l’utilisateur IAM
+ Toute appartenance à un groupe, ce qui signifie que l’utilisateur IAM est supprimé de tous les groupes dont il était membre
+ Tous les mots de passe associés à utilisateur IAM 
+ Toutes les politiques en ligne intégrées à l’utilisateur IAM (politiques qui étaient appliquées à l’utilisateur IAM à l’aide des autorisations de groupe d’utilisateurs ne sont pas affectées) 
**Note**  
IAM supprime toutes les politiques gérées attachées à l’utilisateur IAM lorsque vous supprimez l’utilisateur, mais ne supprime pas les politiques gérées. 
+ Tous les dispositifs MFA associés

### Pour supprimer un utilisateur IAM (console)
<a name="id_users_remove-section-1"></a>

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation de gauche, sélectionnez **Utilisateurs**, puis cochez la case en regard du nom d’utilisateur IAM que vous souhaitez supprimer, pas le nom ou la ligne elle-même. 

1. En haut de la page, sélectionnez **Delete** (Supprimer).
**Note**  
Si certains utilisateurs disposent de clés d’accès actives, vous devez désactiver ces clés avant de supprimer les utilisateurs. Pour de plus amples informations, veuillez consulter [Pour désactiver une clé d’accès pour un utilisateur IAM](access-keys-admin-managed.md#admin-deactivate-access-key).

1. Dans la boîte de dialogue de confirmation, saisissez le nom d'utilisateur dans le champ de saisie de texte pour confirmer la suppression de l'utilisateur. Sélectionnez **Delete (Supprimer)**. 

La console affiche une notification d’état indiquant que l’utilisateur IAM a été supprimé.

------

## Suppression d'un utilisateur IAM (AWS CLI)
<a name="id_users_deleting_cli"></a>

Contrairement au AWS Management Console, lorsque vous supprimez un utilisateur IAM avec le AWS CLI, vous devez supprimer manuellement les éléments attachés à cet utilisateur IAM. La procédure suivante illustre ce processus. 

**Pour supprimer un utilisateur IAM de votre Compte AWS ()AWS CLI**

1. Supprimez le mot de passe de l'utilisateur, s'il en a un.

   `[aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html)`

1. Supprimez les clés d'accès de l'utilisateur, si l'utilisateur en possède une.

   `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)` (pour répertorier les clés d'accès de l'utilisateur) et `[aws iam delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)`

1. Supprimez le certificat de signature de l'utilisateur. Notez que la suppression d'une information d'identification de sécurité est définitive et que vous ne pourrez plus récupérer celle-ci.

   `[aws iam list-signing-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-signing-certificates.html)` (pour répertorier les certificats de signature de l'utilisateur) et `[aws iam delete-signing-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-signing-certificate.html)`

1. Supprimez la clé publique SSH de l'utilisateur, s'il en a une.

   `[aws iam list-ssh-public-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-ssh-public-keys.html)` (pour répertorier les clés publiques SSH de l'utilisateur) et `[aws iam delete-ssh-public-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-ssh-public-key.html)`

1. Supprimez les informations d'identification Git.

   `[aws iam list-service-specific-credentials](https://docs.aws.amazon.com/cli/latest/reference/iam/list-service-specific-credentials.html)` (pour répertorier les informations d'identification git de l'utilisateur) et `[aws iam delete-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-specific-credential.html)`

1. Désactivez l'authentification multifacteur (MFA) de l'utilisateur, s'il en a une.

   `[aws iam list-mfa-devices](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-devices.html)` (pour répertorier les dispositifs MFA de l'utilisateur), `[aws iam deactivate-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)` (pour désactiver le dispositif), et `[aws iam delete-virtual-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html)` (pour supprimer définitivement un dispositif MFA virtuel) 

1. Supprimez les politiques en ligne de l'utilisateur. 

   `[aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)` (pour répertorier les politiques en ligne pour l'utilisateur) et [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html) (pour supprimer la politique) 

1. Détachez toutes les politiques gérées attachées à l'utilisateur. 

   `[aws iam list-attached-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-user-policies.html)` (pour répertorier les politiques gérées attachées à l'utilisateur) et [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html) (pour détacher la politique) 

1. Supprimez l’utilisateur à partir de tous les groupes IAM. 

   `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)` (pour répertorier les groupes IAM auxquels l’utilisateur appartient) et `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)` 

1. Supprimez l’utilisateur.

   `[aws iam delete-user](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user.html)` 

## Désactivation d'un utilisateur IAM
<a name="id_users_deactivating"></a>

Vous pouvez désactiver un utilisateur IAM pendant qu'il est temporairement absent de votre entreprise. Vous pouvez laisser ses informations d'identification utilisateur IAM en place tout en bloquant son accès à AWS .

Pour désactiver un utilisateur, créez et attachez une politique pour lui refuser l'accès à AWS. Vous pourrez rétablir l'accès de l'utilisateur ultérieurement.

Voici deux exemples de politiques de refus que vous pouvez attacher à un utilisateur pour lui refuser l'accès.

La politique suivante n'inclut pas de limite de temps. Vous devez supprimer la politique pour rétablir l'accès de l'utilisateur.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [ 
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*"
      } 
   ]
}
```

------

La politique suivante inclut une condition qui commence la politique le 24 décembre 2024 à 23 h 59 (UTC) et la termine le 28 février 2025 à 23 h 59 (UTC).

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "DateGreaterThan": {"aws:CurrentTime": "2024-12-24T23:59:59Z"},
          "DateLessThan": {"aws:CurrentTime": "2025-02-28T23:59:59Z"}
          }
       }
   ]
}
```

------

# Contrôlez l'accès des utilisateurs IAM au AWS Management Console
<a name="console_controlling-access"></a>

Les utilisateurs IAM autorisés qui se connectent à vous Compte AWS via le AWS Management Console peuvent accéder à vos AWS ressources. La liste suivante indique les manières dont vous pouvez accorder aux utilisateurs IAM l'accès à vos Compte AWS ressources via le AWS Management Console. Il montre également comment les utilisateurs d'IAM peuvent accéder aux autres fonctionnalités du AWS compte via le AWS site Web.

**Note**  
L'utilisation d'IAM n'induit aucuns frais.

**Le AWS Management Console**  
Vous créez un mot de passe pour chaque utilisateur IAM devant accéder à l' AWS Management Console. Les utilisateurs accèdent à la console via votre page de Compte AWS connexion compatible IAM. Pour plus d'informations sur l'accès à la page de connexion, consultez [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l'utilisateur Connexion à AWS *. Pour plus d'informations sur la création de mots de passe, consultez [Mots de passe utilisateur dans AWS](id_credentials_passwords.md).  
Vous pouvez empêcher un utilisateur IAM d'accéder au AWS Management Console en supprimant son mot de passe. Cela les empêche de se connecter à l' AWS Management Console aide de leurs identifiants de connexion. Cela ne modifie pas ses autorisations ni ne l'empêche d'accéder à la console à l'aide d'un rôle endossé. Si l'utilisateur dispose de clés d'accès actives, elles continuent de fonctionner et autorisent l' AWS CLI accès via les Outils pour Windows PowerShell, l' AWS API ou l'Application AWS Console Mobile.

**Vos AWS ressources, telles que les instances Amazon EC2, les compartiments Amazon S3, etc.**  
Même si vos utilisateurs IAM ont des mots de passe, ils doivent également disposer d'une autorisation leur permettant d'accéder à vos ressources AWS . Lorsque vous créez un utilisateur IAM, celui-ci ne dispose par défaut d'aucune autorisation. Pour accorder à vos utilisateurs IAM les autorisations dont ils ont besoin, vous leur attachez des politiques. Si plusieurs utilisateurs IAM effectuent les mêmes tâches avec les mêmes ressources, vous pouvez les affecter à un groupe. Affectez ensuite les autorisations à ce groupe. Pour plus d'informations sur la création d'utilisateurs et de groupes IAM, veuillez consulter la rubrique [IAM identités](id.md). Pour plus d'informations sur l'utilisation de stratégies pour l'octroi d'autorisations, consultez [Gestion de l'accès aux AWS ressources](access.md).

**AWS Forums de discussion**  
Tout le monde peut lire les messages publiés sur les [Forums de discussion AWS](https://forums.aws.amazon.com/). Les utilisateurs qui souhaitent publier des questions ou des commentaires AWS sur le forum de discussion peuvent le faire en utilisant leur nom d'utilisateur. La première fois qu'un utilisateur publie AWS sur le forum de discussion, il est invité à saisir un surnom et une adresse e-mail. Seul cet utilisateur peut utiliser ce surnom dans les forums de AWS discussion. 

**Vos informations Compte AWS de facturation et d'utilisation**  
Vous pouvez autoriser les utilisateurs à accéder à vos informations Compte AWS de facturation et d'utilisation. Pour de plus amples informations, veuillez consulter [Contrôle de l'accès à vos informations de facturation](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html) dans le *Guide de l'utilisateur AWS Billing *. 

**Informations Compte AWS de votre profil**  
Les utilisateurs ne peuvent pas accéder aux informations Compte AWS de votre profil.

**Vos informations Compte AWS de sécurité**  
Les utilisateurs ne peuvent pas accéder à vos informations Compte AWS de sécurité.

**Note**  
Les politiques IAM contrôlent l'accès, quelle que soit l'interface. Par exemple, vous pouvez fournir à un utilisateur un mot de passe pour accéder au AWS Management Console. Les politiques de cet utilisateur (ou de tout groupe auquel appartient l'utilisateur) contrôleraient ce que l'utilisateur peut faire dans le AWS Management Console. Vous pouvez également fournir à l'utilisateur des clés d' AWS accès pour effectuer des appels d'API à AWS. Les politiques contrôleraient les actions que l'utilisateur pourrait appeler via une bibliothèque ou un client qui utilise ces clés d'accès pour l'authentification.

# Modification des autorisations pour un utilisateur IAM
<a name="id_users_change-permissions"></a>

Vous pouvez modifier les autorisations d'un utilisateur IAM de votre site en Compte AWS modifiant son appartenance à un groupe, en copiant les autorisations d'un utilisateur existant, en attachant des politiques directement à un utilisateur ou en définissant une limite d'[autorisation](access_policies_boundaries.md). Une limite d'autorisations contrôle les autorisations maximum dont un utilisateur peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

Pour plus d'informations sur les autorisations requises pour modifier les autorisations d'un utilisateur, consultez [Autorisations requises pour accéder aux autres ressources IAM](access_permissions-required.md).

**Topics**
+ [Afficher l'accès des utilisateurs](#users-modify_prerequisites)
+ [Générer une politique basée sur l'activité d'accès d'un utilisateur](#users_change_permissions-gen-policy)
+ [Ajout d'autorisations à un utilisateur (console)](#users_change_permissions-add-console)
+ [Modification des autorisations pour un utilisateur (console)](#users_change_permissions-change-console)
+ [Pour supprimer une politique d’autorisations d’un utilisateur (console)](#users_change_permissions-remove-policy-console)
+ [Pour supprimer la limite des autorisations d’un utilisateur (console)](#users_change_permissions-remove-boundary-console)
+ [Ajouter et supprimer les autorisations (AWS CLI ou AWS API) d'un utilisateur](#users_change_permissions-add-programmatic)

## Afficher l'accès des utilisateurs
<a name="users-modify_prerequisites"></a>

Avant de modifier les autorisations d'un utilisateur, vous devez passer en revue ses activités récentes au niveau service. Ceci est important, car vous ne souhaitez pas supprimer l'accès à partir d'un principal (personne ou application) qui l'utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md).

## Générer une politique basée sur l'activité d'accès d'un utilisateur
<a name="users_change_permissions-gen-policy"></a>

Vous pouvez parfois octroyer plus d'autorisations à une entité IAM (utilisateur ou rôle) qu'elle n'en a besoin. Pour affiner les autorisations que vous octroyez, vous pouvez générer une politique IAM basée sur l'activité d'accès d'une entité. IAM Access Analyzer examine vos AWS CloudTrail journaux et génère un modèle de politique contenant les autorisations qui ont été utilisées par l'entité dans la plage de dates que vous avez spécifiée. Vous pouvez utiliser le modèle pour créer une politique gérée avec des autorisations affinées, puis l'attacher à l'entité IAM. Ainsi, vous accordez uniquement les autorisations dont l'utilisateur ou 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ération d’une politique de l’analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).

## Ajout d'autorisations à un utilisateur (console)
<a name="users_change_permissions-add-console"></a>

IAM propose trois méthodes pour ajouter des politiques d'autorisations à un utilisateur :
+ **Ajouter l’utilisateur IAM à un groupe IAM** : faites de l’utilisateur un membre d’un groupe. Les politiques du groupe sont attachées à l'utilisateur.
+ **Copier les autorisations d’un utilisateur IAM existant** : copiez toutes les appartenances à un groupe, toutes les politiques gérées attachées, les politiques en ligne et toutes les limites des autorisations existantes d’un utilisateur source.
+ **Attacher directement des politiques à l’utilisateur IAM** : attachez directement une politique gérée à l’utilisateur. Pour faciliter la gestion des autorisations, affectez vos politiques à un groupe, puis faites de ces utilisateurs IAM des membres des groupes appropriés.

**Important**  
Si l’utilisateur dispose d’une limite des autorisations, alors vous ne pouvez pas ajouter à l’utilisateur plus d’autorisations que le permet la limite.

### Pour ajouter des autorisations en ajoutant l’utilisateur IAM à un groupe
<a name="users_change_permissions-add-group-console"></a>

L’ajout d’un utilisateur IAM à un groupe IAM met immédiatement à jour les autorisations de l’utilisateur avec les autorisations définies pour le groupe.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste des **Users** (Utilisateurs), choisissez le nom d'utilisateur IAM. 

1. Sélectionnez l’onglet **Groupes** pour afficher la liste des groupes qui incluent l’utilisateur actuel.

1. Choisissez **Ajouter l’utilisateur aux groupes**. 

1. Activez la case à cocher pour chaque groupe que l’utilisateur doit rejoindre. La liste affiche le nom de chaque groupe et les politiques que l'utilisateur reçoit s'il devient membre de ce groupe.

1. (Facultatif) Vous pouvez choisir **Créer un groupe** pour définir un nouveau groupe. Cela est utile si vous souhaitez ajouter l’utilisateur à un groupe auquel sont associées des politiques différentes de celles des groupes existants :

   1. Dans le nouvel onglet, pour **Nom du groupe d'utilisateurs**, saisissez le nom de votre nouveau groupe.
**Note**  
Le nombre et la taille des ressources IAM d'un AWS compte sont limités. Pour de plus amples informations, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md). Les noms de groupe peuvent combiner jusqu'à 128 lettres, chiffres et caractères suivants : plus (\$1), égal (=), virgule (,), point (.), arobase (@) et tiret (-). Les noms doivent être uniques au sein d'un compte. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux groupes nommés *TESTGROUP* et *testgroup*.

   1. Cochez une ou plusieurs cases pour les politiques gérées que vous souhaitez attacher au groupe. Vous pouvez également créer une politique gérée en choisissant **Créer une politique**. Le cas échéant, revenez dans la fenêtre ou l'onglet du navigateur une fois la nouvelle politique créée. Choisissez **Refresh (Actualiser)**, puis choisissez la nouvelle politique à attacher à votre groupe. Pour de plus amples informations, veuillez consulter [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](access_policies_create.md).

   1. Choisissez **Créer un groupe d'utilisateurs**.

   1. Revenez à l'onglet initial, actualisez votre liste de groupes. Puis cochez la case correspondant à votre nouveau groupe.

1. Choisissez **Ajouter l’utilisateur au(x) groupe(s)**.

La console affiche un message d’état vous informant que l’utilisateur a été ajouté aux groupes que vous avez spécifié.

------

### Pour ajouter des autorisations en copiant celles d’un autre utilisateur IAM
<a name="users_change_permissions-add-copy-console"></a>

Si vous choisissez d’ajouter des autorisations à un utilisateur IAM en copiant des autorisations, IAM copie toutes les appartenances à des groupes, les politiques gérées attachées, les politiques en ligne et toutes les limites des autorisations existantes de l’utilisateur spécifié et les applique immédiatement à l’utilisateur actuellement sélectionné.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste des **Users** (Utilisateurs), choisissez le nom d'utilisateur IAM. 

1. Sous l’onglet **Autorisations**, choisissez **Ajouter des autorisations**.

1. Sur la page **Ajouter des autorisations**, choisissez **Copier des autorisations**. La liste affiche les utilisateurs IAM disponibles ainsi que leur appartenance à un groupe et les politiques attachées. 

1. Sélectionnez le bouton radio en regard de l'utilisateur dont vous voulez copier les autorisations. 

1. Choisissez **Suivant** pour afficher la liste des modifications apportées à l'utilisateur. Choisissez ensuite **Add permissions (Ajouter des autorisations)**.

La console affiche un message d’état vous informant que les autorisations ont été copiées depuis l’utilisateur IAM que vous avez spécifié.

------

### Pour ajouter des autorisations en attachant les politiques directement à l’utilisateur IAM
<a name="users_change_permissions-add-directly-console"></a>

Vous pouvez attacher une politique gérée directement à un utilisateur IAM. Les autorisations mises à jour sont appliquées immédiatement.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste des **Users** (Utilisateurs), choisissez le nom d'utilisateur IAM. 

1. Sous l’onglet **Autorisations**, choisissez **Ajouter des autorisations**.

1. Sur la page **Ajouter des autorisations**, choisissez **Attacher directement les politiques**. La liste des **Politiques d’autorisations** affiche les politiques disponibles ainsi que leurs types de politiques et les entités associées. 

1. Sélectionnez le bouton en regard du **Nom de la politique** que vous souhaitez attacher. 

1. Choisissez **Suivant** pour afficher la liste des modifications apportées à l'utilisateur. Choisissez ensuite **Add permissions (Ajouter des autorisations)**.

La console affiche un message d’état vous informant que la politique a été ajoutée à l’utilisateur IAM que vous avez spécifié.

------

### Pour définir la limite des autorisations pour un utilisateur IAM
<a name="users_change_permissions-set-boundary-console"></a>

Une limite d'autorisations est une fonctionnalité avancée de gestion des AWS autorisations utilisée pour définir le maximum d'autorisations qu'un utilisateur IAM peut avoir. La définition d’une limite des autorisations restreint immédiatement les autorisations de l’utilisateur IAM à cette limite, quelles que soient les autres autorisations accordées.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste **Utilisteurs**, choisissez le nom de l’utilisateur IAM dont vous souhaitez modifier la limite des autorisations. 

1. Sélectionnez l’onglet **Autorisations**. Si nécessaire, ouvrez la section **Limite d'autorisations**, puis choisissez **Définir une limite d'autorisations**.

1. Sur la page **Définir la limite des autorisations**, sous **Politiques d’autorisations**, sélectionnez la politique que vous souhaitez utiliser pour la limite des autorisations.

1. Choisissez **Set boundary (Définir une limite)**.

La console affiche un message d’état vous informant que la limite des autorisations a été ajoutée.

------

## Modification des autorisations pour un utilisateur (console)
<a name="users_change_permissions-change-console"></a>

IAM vous permet de modifier les autorisations associées à un utilisateur de la manière suivante :
+ **Edit a permissions policy** (Modifier une politique d'autorisations) : modifiez la politique en ligne d'un utilisateur, la politique en ligne du groupe de l'utilisateur ou une politique gérée attachée directement à l'utilisateur ou à partir d'un groupe. Si l'utilisateur dispose d'une limite d'autorisations, alors vous ne pouvez pas fournir plus d'autorisations que le permet la politique utilisée comme limite d'autorisations de l'utilisateur.
+ **Changing the permissions boundary** (Modification de la limite d'autorisations) : modifiez la politique utilisée comme limite d'autorisations pour l'utilisateur. Cette action peut développer ou limiter les autorisations maximum dont dispose un utilisateur. 

### Modification d'une politique d'autorisations attachée à un utilisateur
<a name="users_change_permissions-edit-policy-console"></a>

La modification d’autorisations met immédiatement à jour l’accès de l’utilisateur.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste **Utilisteurs**, choisissez le nom de l’utilisateur IAM dont vous souhaitez modifier la limite des autorisations. 

1. Sélectionnez l’onglet **Autorisations**. Si nécessaire, ouvrez la section **Limite des autorisations**.

1. Choisissez le nom de la politique que vous souhaitez modifier pour en afficher les détails. Choisissez l’onglet **Entités attachées** pour afficher d’autres entités (utilisateurs, groupes et rôles IAM) qui pourraient être affectées par la modification de la politique. 

1. Choisissez l'onglet **Autorisations** et examinez les autorisations accordées par la politique. Pour modifier les autorisations, choisissez **Modifier**. 

1. Modifiez la politique et résolvez les recommandations sur la [validation des politiques](access_policies_policy-validator.md). Pour de plus amples informations, veuillez consulter [Modification de politiques IAM](access_policies_manage-edit.md).

1. Choisissez **Suivant**, examinez le récapitulatif de la politique, puis choisissez **Enregistrer les modifications**.

La console affiche un message d’état vous informant que la politique a été mise à jour.

------

### Pour changer la limite des autorisations pour un utilisateur
<a name="users_change_permissions-change-boundary-console"></a>

La modification d’une limite des autorisations met immédiatement à jour l’accès de l’utilisateur.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste **Utilisteurs**, choisissez le nom de l’utilisateur IAM dont vous souhaitez modifier la limite des autorisations. 

1. Sélectionnez l’onglet **Autorisations**. Si nécessaire, ouvrez la section **Permissions boundary (Limite d'autorisations)**, puis choisissez **Change boundary (Modifier une limite)**.

1. Sélectionnez la politique que vous souhaitez utiliser pour la limite d'autorisations.

1. Choisissez **Set boundary (Définir une limite)**.

La console affiche un message d’état vous informant que la limite des autorisations a été modifiée.

------

## Pour supprimer une politique d’autorisations d’un utilisateur (console)
<a name="users_change_permissions-remove-policy-console"></a>

La suppression d’autorisations met immédiatement à jour l’accès de l’utilisateur.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom de l’utilisateur dont vous souhaitez supprimer les politiques d’autorisations. 

1. Sélectionnez l’onglet **Autorisations**. 

1. Si vous souhaitez supprimer les autorisations en supprimant une politique existante, affichez la colonne **Attachée via** pour comprendre comment l’utilisateur obtient cette politique avant de choisir **Supprimer** pour supprimer celle-ci :
   + Si la politique s'applique en raison de l'appartenance à un groupe, choisissez **Supprimer** pour supprimer l'utilisateur du groupe. N'oubliez pas que vous pouvez avoir plusieurs politiques attachées à un seul groupe. Si vous supprimez un utilisateur d'un groupe, il perd l'accès à *toutes* les politiques qu'il reçoit par le biais de cette appartenance au groupe.
   + Si la politique est une politique gérée attachée directement à l'utilisateur, choisissez **Supprimer** pour détacher la politique de l'utilisateur. Cela n'affecte pas la politique elle-même ni aucune autre entité à laquelle la politique pourrait être attachée.
   + S’il s’agit d’une politique en ligne intégrée, sélectionnez **Supprimer** pour supprimer la politique d’IAM. Les politiques en ligne attachées directement à un utilisateur existent uniquement sur cet utilisateur.

Si la politique a été accordée à l’utilisateur par le biais d’une adhésion à un groupe, la console affiche un message d’état vous informant que l’utilisateur IAM a été supprimé du groupe IAM. Si la politique est directement attachée ou intégrée, le message d’état vous informe que la politique a été supprimée.

------

## Pour supprimer la limite des autorisations d’un utilisateur (console)
<a name="users_change_permissions-remove-boundary-console"></a>

La suppression de la limite des autorisations met immédiatement à jour l’accès de l’utilisateur.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste **Utilisteurs**, choisissez le nom de l’utilisateur IAM dont vous souhaitez supprimer la limite des autorisations. 

1. Sélectionnez l’onglet **Autorisations**. Si nécessaire, ouvrez la section **Limite des autorisations**.

1.  Choisissez **Change boundary (Modifier une limite)**. Pour confirmer que vous souhaitez supprimer la limite des autorisations, sélectionnez **Supprimer la limite** dans la boîte de dialogue de confirmation.

La console affiche un message d’état vous informant que la limite des autorisations a été supprimée.

------

## Ajouter et supprimer les autorisations (AWS CLI ou AWS API) d'un utilisateur
<a name="users_change_permissions-add-programmatic"></a>

Pour ajouter ou supprimer des autorisations par programme, vous devez ajouter ou supprimer l'appartenance au groupe, attacher ou détacher les politiques gérées, ou ajouter ou supprimer les politiques en ligne. Pour plus d’informations, consultez les rubriques suivantes :
+ [Modification des utilisateurs dans les groupes IAM](id_groups_manage_add-remove-users.md)
+ [Ajout et suppression d'autorisations basées sur l'identité IAM](access_policies_manage-attach-detach.md)

# Mots de passe utilisateur dans AWS
<a name="id_credentials_passwords"></a>

Vous pouvez gérer les mots de passe des utilisateurs IAM de votre compte. Les utilisateurs IAM ont besoin de mots de passe pour accéder au AWS Management Console. Les utilisateurs n'ont pas besoin de mots de passe pour accéder aux AWS ressources par programmation à l' AWS CLI aide des outils pour Windows PowerShell ou. AWS SDKs APIs Pour ces environnements, vous avez la possibilité d'attribuer des [clés d'accès](id_credentials_access-keys.md) aux utilisateurs IAM. Cependant, il existe d'autres alternatives plus sécurisées aux clés d'accès que nous vous recommandons d'envisager d'abord. Pour de plus amples informations, veuillez consulter [AWS informations d'identification de sécurité](security-creds.md).

**Note**  
Si l’un de vos utilisateurs IAM perd ou oublie son mot de passe, vous *ne pouvez pas* le récupérer auprès d’IAM. En fonction de vos paramètres, l’utilisateur ou l’administrateur doit générer un nouveau mot de passe.

**Topics**
+ [Définition d’une politique de mot de passe du compte pour les utilisateurs IAM](id_credentials_passwords_account-policy.md)
+ [Gérer les mots de passe des utilisateurs IAM](id_credentials_passwords_admin-change-user.md)
+ [Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe](id_credentials_passwords_enable-user-change.md)
+ [Modification par l'utilisateur IAM de son propre mot de passe](id_credentials_passwords_user-change-own.md)

# Définition d’une politique de mot de passe du compte pour les utilisateurs IAM
<a name="id_credentials_passwords_account-policy"></a>

Vous pouvez définir une politique de mot de passe personnalisée Compte AWS pour définir les exigences de complexité et les périodes de rotation obligatoires pour les mots de passe de vos utilisateurs IAM. Si vous ne définissez pas de politique de mot de passe personnalisée, les mots de passe des utilisateurs IAM doivent respecter la politique de AWS mot de passe par défaut. Pour de plus amples informations, veuillez consulter [Options de politique de mot de passe personnalisé](#password-policy-details).

**Topics**
+ [Règles relatives à la définition d'une politique de mot de passe](#password-policy-rules)
+ [Autorisations requises pour définir une politique de mot de passe](#default-policy-permissions-required)
+ [Politique de mot de passe par défaut](#default-policy-details)
+ [Options de politique de mot de passe personnalisé](#password-policy-details)
+ [Pour définir une politique de mot de passe (console)](#IAMPasswordPolicy)
+ [Pour modifier une politique de mot de passe (console)](#id_credentials_passwords_account-policy-section-1)
+ [Pour supprimer une politique de mot de passe personnalisée (console)](#id_credentials_passwords_account-policy-section-2)
+ [Définition d'une politique de mot de passe (AWS CLI)](#PasswordPolicy_CLI)
+ [Définition d'une politique de mot de passe (AWS API)](#PasswordPolicy_API)

## Règles relatives à la définition d'une politique de mot de passe
<a name="password-policy-rules"></a>

La politique de mot de passe IAM ne s'applique pas au Utilisateur racine d'un compte AWS mot de passe ou aux clés d'accès utilisateur IAM. Si un mot de passe expire, l'utilisateur IAM ne peut pas se connecter AWS Management Console mais peut continuer à utiliser ses clés d'accès.

Lorsque vous créez ou modifiez une politique de mot de passe, la plupart de ses paramètres sont appliqués la fois suivante où vos utilisateurs modifient leurs mots de passe. Toutefois, certains des paramètres sont appliqués immédiatement. Par exemple : 
+ Lorsque les exigences de longueur minimale et de type de caractères sont modifiés, les nouveaux paramètres sont appliqués à la prochaine modification des mots de passe. Les utilisateurs ne sont pas contraints à modifier leurs mots de passe, même si ceux-ci ne respectent pas la politique de mot de passe modifiée.
+ Lorsque vous définissez une période d'expiration de mot de passe, celle-ci est appliquée immédiatement. Par exemple, supposons que vous définissez une période d'expiration de mot de passe de 90 jours. Dans ce cas, le mot de passe expire pour tous les utilisateurs IAM dont le mot de passe existant date de plus de 90 jours. Ces utilisateurs sont tenus de modifier leur mot de passe la première fois qu'ils se connectent.

Vous ne pouvez pas créer de « politique de verrouillage » pour empêcher l'accès d'un utilisateur à un compte après un nombre défini de tentatives de connexion ayant échoué. Pour renforcer votre sécurité, nous vous recommandons de combiner des politiques de mot de passe d'un niveau de sécurité élevé à la Multi-Factor Authentication (MFA). Pour plus d'informations sur l'authentification MFA, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md).

## Autorisations requises pour définir une politique de mot de passe
<a name="default-policy-permissions-required"></a>

Vous devez configurer les autorisations pour permettre à une entité IAM (utilisateur ou rôle) d'afficher ou de modifier sa politique de mot de passe de compte. Vous pouvez inclure les actions de politique de mot de passe suivantes dans une politique IAM : 
+ `iam:GetAccountPasswordPolicy` : permet à l'entité d'afficher la politique de mot de passe pour son compte
+ `iam:DeleteAccountPasswordPolicy` : permet à l'entité de supprimer la politique de mot de passe personnalisée pour son compte et de revenir à la politique de mot de passe par défaut
+ `iam:UpdateAccountPasswordPolicy` : permet à l'entité de créer ou de modifier la politique de mot de passe personnalisée pour son compte

La politique suivante permet un accès complet pour afficher et modifier la politique de mot de passe du compte. Pour apprendre à créer une politique IAM à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "FullAccessPasswordPolicy",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:DeleteAccountPasswordPolicy",
                "iam:UpdateAccountPasswordPolicy"
            ],
            "Resource": "*"
        }
    ]
}
```

------

Pour plus d'informations sur les autorisations requises par les utilisateurs IAM pour modifier leur propre mot de passe, veuillez consulter [Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe](id_credentials_passwords_enable-user-change.md).

## Politique de mot de passe par défaut
<a name="default-policy-details"></a>

Si un administrateur ne définit pas de politique de mot de passe personnalisée, les mots de passe des utilisateurs IAM doivent respecter la politique de AWS mot de passe par défaut.

La politique de mot de passe par défaut exige les conditions suivantes :
+ Longueur minimale du mot de passe de 8 caractères et longueur maximale de 128 caractères
+ Au minimum trois des types de caractères suivants : majuscules, minuscules, chiffres et les caractères non alphanumériques (`! @ # $ % ^ & * ( ) _ + - = [ ] { } | '`)
+ Ne pas être identique à votre Compte AWS nom ou à votre adresse e-mail
+ Mot de passe sans expiration

## Options de politique de mot de passe personnalisé
<a name="password-policy-details"></a>

Lorsque vous configurez une politique de mot de passe personnalisée pour votre compte, vous pouvez spécifier les conditions suivantes :
+ **Password minimum length** (Longueur minimale du mot de passe) : vous pouvez spécifier une longueur minimale de 6 caractères et une longueur maximale de 128 caractères.
+ **Niveau de sécurité du mot de passe** : vous pouvez cocher l’une des cases suivantes pour définir le niveau de sécurité de vos mots de passe utilisateur IAM :
  + Exiger au moins une lettre majuscule de l'alphabet latin (A–Z)
  + Exiger au moins une lettre minuscule de l'alphabet latin (a–z)
  + Nécessite au moins un chiffre
  + Exiger au moins un caractère non alphanumérique `! @ # $ % ^ & * ( ) _ + - = [ ] { } | '` 
+ **Turn on password expiration** (Activer l'expiration du mot de passe) : vous pouvez sélectionner et spécifier une durée minimale de 1 jour et une durée maximale de 1 095 jours pendant laquelle les mots de passe utilisateur IAM sont valides après leur définition. Par exemple, si vous spécifiez un délai d'expiration de 90 jours, cela a un impact immédiat sur tous vos utilisateurs. Pour les utilisateurs dont le mot de passe date de plus de 90 jours, ils doivent définir un nouveau mot de passe lorsqu'ils se connectent à la console après la modification. Les utilisateurs dont le mot de passe est vieux de 75 à 89 jours reçoivent un AWS Management Console avertissement concernant l'expiration de leur mot de passe. Les utilisateurs IAM peuvent modifier leur mot de passe à tout moment s'ils en ont l'autorisation. Lorsqu'ils définissent un nouveau mot de passe, la date d’expiration est réinitialisée. Un utilisateur IAM ne peut avoir qu'un mot de passe valide à la fois.
+ L'**expiration du mot de passe nécessite une réinitialisation par l'administrateur** : sélectionnez cette option pour empêcher les utilisateurs IAM de l'utiliser AWS Management Console pour mettre à jour leur propre mot de passe après son expiration. Avant de sélectionner cette option, vérifiez que votre Compte AWS a plusieurs utilisateurs disposant des autorisations d'administrateur nécessaires pour réinitialiser les mots de passe utilisateur IAM. Les administrateurs disposant de l'autorisation `iam:UpdateLoginProfile` peuvent réinitialiser les mots de passe des utilisateurs IAM. Les utilisateurs IAM disposant de l'autorisation `iam:ChangePassword` et de clés d'accès actives peuvent réinitialiser leur propre mot de passe de console utilisateur IAM de manière programmatique. Si vous décochez cette case, les utilisateurs IAM dont les mots de passe ont expiré doivent tout de même définir un nouveau mot de passe avant de pouvoir accéder à l’ AWS Management Console.
+ **Allow users to change their own password** (Autoriser les utilisateurs à modifier leur propre mot de passe) : vous pouvez permettre à tous les utilisateurs IAM de votre compte d'utiliser la console IAM pour modifier leur mot de passe. Cela permet aux utilisateurs d'accéder à l'action `iam:ChangePassword` uniquement pour leur propre utilisateur et à l'action `iam:GetAccountPasswordPolicy`. Cette option n'associe aucune politique d'autorisations à chaque utilisateur. IAM applique plutôt les autorisations au niveau du compte pour tous les utilisateurs. Vous pouvez également n'autoriser que certains utilisateurs à gérer leurs propres mots de passe. Pour ce faire, décochez cette case. Pour plus d'informations sur l'utilisation de politiques visant à limiter les utilisateurs pouvant gérer les mots de passe, consultez la section [Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe](id_credentials_passwords_enable-user-change.md).
+ **Prevent password reuse** (Empêcher la réutilisation d'un mot de passe) : vous pouvez empêcher les utilisateurs IAM de réutiliser un certain nombre de mots de passe précédents. Vous pouvez spécifier le nombre de mots de passe précédents qui ne peuvent pas être réutilisés, entre 1 et 24 mots de passe. 

## Pour définir une politique de mot de passe (console)
<a name="IAMPasswordPolicy"></a>

Vous pouvez utiliser le AWS Management Console pour créer, modifier ou supprimer une politique de mot de passe personnalisée. Les modifications apportées à la politique de mot de passe s’appliquent aux nouveaux utilisateurs IAM créés après cette modification de politique et aux utilisateurs IAM existants lorsqu’ils modifient leur mot de passe.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **Paramètres du compte**.

1. Dans la section **Password policy** (Politique de mot de passe), sélectionnez **Edit** (Modifier). 

1. Choisissez **Custom** (Personnalisé) pour utiliser une politique de mot de passe personnalisée.

1. Sélectionnez les options que vous souhaitez appliquer à votre politique de mot de passe, puis sélectionnez **Enregistrer les modifications**. 

1. Confirmez que vous souhaitez définir la politique de mot de passe personnalisée en sélectionnant **Définir personnalisé**.

La console affiche un message d’état vous informant que les exigences en matière de mot de passe pour les utilisateurs IAM ont été mises à jour.

------

## Pour modifier une politique de mot de passe (console)
<a name="id_credentials_passwords_account-policy-section-1"></a>

Vous pouvez utiliser le AWS Management Console pour créer, modifier ou supprimer une politique de mot de passe personnalisée. Les modifications apportées à la politique de mot de passe s’appliquent aux nouveaux utilisateurs IAM créés après cette modification de politique et aux utilisateurs IAM existants lorsqu’ils modifient leur mot de passe.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **Paramètres du compte**.

1. Dans la section **Password policy** (Politique de mot de passe), sélectionnez **Edit** (Modifier). 

1. Sélectionnez les options que vous souhaitez appliquer à votre politique de mot de passe, puis sélectionnez **Enregistrer les modifications**. 

1. Confirmez que vous souhaitez définir la politique de mot de passe personnalisée en sélectionnant **Définir personnalisé**.

La console affiche un message d’état vous informant que les exigences en matière de mot de passe pour les utilisateurs IAM ont été mises à jour.

------

## Pour supprimer une politique de mot de passe personnalisée (console)
<a name="id_credentials_passwords_account-policy-section-2"></a>

Vous pouvez utiliser le AWS Management Console pour créer, modifier ou supprimer une politique de mot de passe personnalisée. Les modifications apportées à la politique de mot de passe s’appliquent aux nouveaux utilisateurs IAM créés après cette modification de politique et aux utilisateurs IAM existants lorsqu’ils modifient leur mot de passe.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **Paramètres du compte**.

1. Dans la section **Password policy** (Politique de mot de passe), sélectionnez **Edit** (Modifier). 

1. Choisissez **IAM default** (IAM par défaut) pour supprimer la politique de mot de passe personnalisée, puis **Save changes** (Enregistrer les modifications).

1. Confirmez que vous souhaitez définir la politique de mot de passe IAM par défaut en sélectionnant **Définir personnalisé**.

La console affiche un message d’état vous informant que la politique de mot de passe est définie sur le réglage par défaut d’IAM.

------

## Définition d'une politique de mot de passe (AWS CLI)
<a name="PasswordPolicy_CLI"></a>

Vous pouvez utiliser le AWS Command Line Interface pour définir une politique de mot de passe.

**Pour gérer la politique de mot de passe de compte personnalisée depuis le AWS CLI**  
Exécutez les commandes suivantes :
+ Pour créer ou modifier la politique de mot de passe personnalisée : [https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)
+ Pour afficher la politique de mot de passe : [https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html) 
+ Pour supprimer la politique de mot de passe personnalisée : [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html) 

## Définition d'une politique de mot de passe (AWS API)
<a name="PasswordPolicy_API"></a>

Vous pouvez utiliser les opérations de AWS l'API pour définir une politique de mot de passe.

**Pour gérer la politique de mot de passe de compte personnalisée à partir de l' AWS API**  
Appelez les opérations suivantes :
+ Pour créer ou modifier la politique de mot de passe personnalisée : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)
+ Pour afficher la politique de mot de passe : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) 
+ Pour supprimer la politique de mot de passe personnalisée : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html) 

# Gérer les mots de passe des utilisateurs IAM
<a name="id_credentials_passwords_admin-change-user"></a>

Les utilisateurs IAM qui utilisent les ressources AWS Management Console pour travailler avec AWS des ressources doivent disposer d'un mot de passe pour se connecter. Vous pouvez créer, modifier ou supprimer un mot de passe pour un utilisateur IAM dans votre compte AWS . 

Après avoir attribué un mot de passe à un utilisateur, celui-ci peut se connecter à l' AWS Management Console aide de l'URL de connexion de votre compte, qui ressemble à ceci : 

```
https://12-digit-AWS-account-ID or alias.signin.aws.amazon.com/console
```

Pour plus d'informations sur la manière dont les utilisateurs IAM se connectent au AWS Management Console, consultez la section [Comment se connecter AWS dans](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) le *guide de l'Connexion à AWS utilisateur*. 

Même si vos utilisateurs ont leurs propres mots de passe, ils toujours besoin de votre autorisation pour accéder à vos ressources AWS . Par défaut, un utilisateur ne dispose d'aucune autorisation. Pour accorder à vos utilisateurs les autorisations dont ils ont besoin, vous leur attribuez des politiques ou aux groupes dont ils font partie. Pour plus d'informations sur la création d'utilisateurs et de groupes, consultez [IAM identités](id.md). Pour plus d'informations sur l'utilisation de stratégies pour l'octroi d'autorisations, consultez [Modification des autorisations pour un utilisateur IAM](id_users_change-permissions.md). 

Vous pouvez accorder aux utilisateurs l'autorisation de modifier leurs propres mots de passe. Pour de plus amples informations, veuillez consulter [Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe](id_credentials_passwords_enable-user-change.md). Pour plus d'informations sur la façon dont les utilisateurs accèdent à la page de connexion à votre compte, consultez [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l'utilisateur Connexion à AWS *. 

**Topics**
+ [Création, modification ou suppression d'un mot de passe utilisateur IAM (console)](#id_credentials_passwords_admin-change-user_console)

## Création, modification ou suppression d'un mot de passe utilisateur IAM (console)
<a name="id_credentials_passwords_admin-change-user_console"></a>

Vous pouvez utiliser le AWS Management Console pour gérer les mots de passe de vos utilisateurs IAM.

Les besoins de vos utilisateurs en matière d’accès peuvent changer au fil du temps. Vous devrez peut-être autoriser un utilisateur à accéder à la CLI à accéder à la console, modifier le mot de passe d'un utilisateur parce qu'il reçoit un e-mail contenant ses informations d'identification, ou supprimer un utilisateur lorsqu'il quitte votre organisation ou n'a plus besoin d'y AWS accéder. 

### Pour créer le mot de passe d’un utilisateur IAM (console)
<a name="id_credentials_passwords_admin-change-user-section-1"></a>

Utilisez cette procédure pour donner accès à une console utilisateur en générant un mot de passe associé au nom d’utilisateur.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom de l'utilisateur dont vous souhaitez créer le mot de passe. 

1. Cliquez sur l'onglet **Informations d'identification de sécurité**, puis sous **Connexion à la console**, sélectionnez **Activer l'accès à la console**.

1. Dans la boîte de dialogue **Activer l’accès à la console**, sélectionnez **Réinitialiser le mot de passe**, puis choisissez si vous préférez qu’IAM génère un mot de passe ou si vous voulez en générer un personnalisé : 
   + Pour qu'IAM génère un mot de passe, sélectionnez **Autogenerated password** (Mot de passe généré automatiquement).
   + Pour créer un mot de passe personnalisé, choisissez **Custom password (Mot de passe personnalisé)**, puis tapez le mot de passe. 
**Note**  
Le mot de passe que vous créez doit respecter la [politique de mot de passe](id_credentials_passwords_account-policy.md) du compte.

1. Pour obliger l’utilisateur à générer un nouveau mot de passe au moment de la connexion, sélectionnez **L’utilisateur doit générer un nouveau mot de passe à la prochaine connexion**. 

1. Pour demander à l’utilisateur d’utiliser le nouveau mot de passe immédiatement, sélectionnez **Révoquer les sessions de console actives**. Cela associe une politique en ligne à l’utilisateur IAM qui lui refuse l’accès aux ressources si ses informations d’identification sont antérieures à la date spécifiée par la politique.

1. Choisissez **Réinitialiser le mot de passe**.

1. La boîte de dialogue **Mot de passe de la console** vous informe que vous avez activé le nouveau mot de passe de l’utilisateur. Pour afficher le mot de passe afin de le partager avec l’utilisateur, choisissez **Afficher** dans la boîte de dialogue **Mot de passe de la console**. Sélectionnez **Télécharger le fichier .csv** pour télécharger un fichier contenant les informations d’identification de l’utilisateur.
**Important**  
Pour des raisons de sécurité, vous ne pouvez pas accéder au mot de passe après avoir effectué cette étape, mais vous pouvez créer un nouveau mot de passe à tout moment.

La console affiche un message d’état vous informant que l’accès à la console a été activé.

------

### Pour changer le mot de passe d'un utilisateur IAM (console)
<a name="id_credentials_passwords_admin-change-user-section-2"></a>

Utilisez cette procédure pour mettre à jour un mot de passe associé au nom d’utilisateur.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom de l'utilisateur dont vous souhaitez changer le mot de passe. 

1. Cliquez sur l'onglet **Informations d'identification de sécurité**, puis sous **Connexion à la console**, sélectionnez **Gérer l'accès à la console**.

1. Dans la boîte de dialogue **Gérer l’accès à la console**, sélectionnez **Réinitialiser le mot de passe**, puis choisissez si vous préférez qu’IAM génère un mot de passe ou si vous voulez générer un personnalisé : 
   + Pour qu'IAM génère un mot de passe, sélectionnez **Autogenerated password** (Mot de passe généré automatiquement).
   + Pour créer un mot de passe personnalisé, choisissez **Custom password (Mot de passe personnalisé)**, puis tapez le mot de passe. 
**Note**  
Le mot de passe que vous créez doit respecter la [politique de mot de passe](id_credentials_passwords_account-policy.md) du compte.

1. Pour obliger l’utilisateur à générer un nouveau mot de passe au moment de la connexion, sélectionnez **L’utilisateur doit générer un nouveau mot de passe à la prochaine connexion**. 

1. Pour demander à l’utilisateur d’utiliser le nouveau mot de passe immédiatement, sélectionnez **Révoquer les sessions de console actives**. Cela associe une politique en ligne à l’utilisateur IAM qui lui refuse l’accès aux ressources si ses informations d’identification sont antérieures à la date spécifiée par la politique.

1. Choisissez **Réinitialiser le mot de passe**.

1. La boîte de dialogue **Mot de passe de la console** vous informe que vous avez activé le nouveau mot de passe de l’utilisateur. Pour afficher le mot de passe afin de le partager avec l’utilisateur, choisissez **Afficher** dans la boîte de dialogue **Mot de passe de la console**. Sélectionnez **Télécharger le fichier .csv** pour télécharger un fichier contenant les informations d’identification de l’utilisateur.
**Important**  
Pour des raisons de sécurité, vous ne pouvez pas accéder au mot de passe après avoir effectué cette étape, mais vous pouvez créer un nouveau mot de passe à tout moment.

La console affiche un message d’état vous informant que l’accès à la console a été mis à jour.

------

### Supprimer (désactiver) le mot de passe d'un utilisateur IAM (console)
<a name="id_credentials_passwords_admin-change-user-section-3"></a>

Utilisez cette procédure pour supprimer un mot de passe associé au nom d’utilisateur, privant ainsi l’utilisateur de l’accès à la console.

**Important**  
Vous pouvez empêcher un utilisateur IAM d'accéder au AWS Management Console en supprimant son mot de passe. Cela les empêche de se connecter à l' AWS Management Console aide de leurs identifiants de connexion. Cela ne modifie pas ses autorisations ni ne l'empêche d'accéder à la console à l'aide d'un rôle endossé. Si l'utilisateur dispose de clés d'accès actives, elles continuent de fonctionner et autorisent l' AWS CLI accès via les Outils pour Windows PowerShell, l' AWS API ou l'Application AWS Console Mobile.

------
#### [ Console ]

1. Suivez la procédure de connexion correspondant à votre type d'utilisateur, comme décrit dans la rubrique [Connexion à AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l'utilisateur Connexion àAWS *.

1. Sur la **page d’accueil de la console IAM**, dans le volet de navigation de gauche, saisissez votre requête dans la zone de texte **Rechercher sur IAM**.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom de l'utilisateur dont vous souhaitez supprimer le mot de passe. 

1. Cliquez sur l'onglet **Informations d'identification de sécurité**, puis sous **Connexion à la console**, sélectionnez **Gérer l'accès à la console**.

1. Pour demander à l’utilisateur de cesser immédiatement d’utiliser la console, sélectionnez **Révoquer les sessions de console actives**. Cela associe une politique en ligne à l’utilisateur IAM qui lui refuse l’accès aux ressources si ses informations d’identification sont antérieures à la date spécifiée par la politique.

1. Choisissez **Désactiver l’accès**

La console affiche un message d’état vous informant que l’accès à la console a été désactivé.

------

### Création, modification ou suppression d'un mot de passe utilisateur IAM (AWS CLI)
<a name="Using_ManagingPasswordsCLIAPI"></a>

Vous pouvez utiliser l' AWS CLI API pour gérer les mots de passe de vos utilisateurs IAM.

**Pour créer un mot de passe (AWS CLI)**

1. (Facultatif) Pour déterminer si un utilisateur possède un mot de passe, exécutez cette commande : [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html)

1. Pour créer un mot de passe, exécutez cette commande : [aws iam create-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-login-profile.html)

**Pour modifier le mot de passe d'un utilisateur (AWS CLI)**

1. (Facultatif) Pour déterminer si un utilisateur possède un mot de passe, exécutez cette commande : [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html)

1. Pour modifier un mot de passe, exécutez cette commande : [aws iam update-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/update-login-profile.html)

**Pour supprimer (désactiver) le mot de passe d'un utilisateur (AWS CLI)**

1. (Facultatif) Pour déterminer si un utilisateur possède un mot de passe, exécutez cette commande : [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html)

1. (Facultatif) Pour déterminer quand un mot de passe a été utilisé pour la dernière fois, exécutez cette commande : [aws iam get-user](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user.html)

1. Pour supprimer un mot de passe, exécutez cette commande : [aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html)

**Important**  
Lorsque vous supprimez le mot de passe d'un utilisateur, ce dernier ne peut plus se connecter à l’interface AWS Management Console. Si l'utilisateur dispose de clés d'accès actives, elles continuent de fonctionner et autorisent l'accès via les appels de fonction AWS CLI PowerShell, Outils pour Windows ou AWS API. Lorsque vous utilisez les AWS CLI outils pour Windows PowerShell ou l' AWS API pour supprimer un utilisateur de votre compte Compte AWS, vous devez d'abord supprimer le mot de passe à l'aide de cette opération. Pour de plus amples informations, veuillez consulter [Suppression d'un utilisateur IAM (AWS CLI)](id_users_remove.md#id_users_deleting_cli). 

**Pour révoquer les sessions de console actives d’un utilisateur avant une heure spécifiée (AWS CLI)**

1. [Pour intégrer une politique en ligne qui révoque les sessions de console actives d'un utilisateur IAM avant une heure spécifiée, utilisez la politique en ligne suivante et exécutez cette commande : aws iam put-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-user-policy.html)

   Cette politique en ligne récuse toutes les autorisations et inclut la clé de condition `aws:TokenIssueTime`. Il révoque les sessions de console actives de l’utilisateur avant l’heure spécifiée dans l’élément `Condition` de la politique en ligne. Remplacez la valeur de la clé de condition `aws:TokenIssueTime` par votre propre valeur.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. [(Facultatif) Pour répertorier les noms des politiques intégrées à l'utilisateur IAM, exécutez cette commande : aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)

1. [(Facultatif) Pour afficher la politique intégrée nommée intégrée à l'utilisateur IAM, exécutez cette commande : aws iam get-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user-policy.html)

### Création, modification ou suppression d'un mot de passe utilisateur IAM (AWS API)
<a name="Using_ManagingPasswordsAPI"></a>

Vous pouvez utiliser l' AWS API pour gérer les mots de passe de vos utilisateurs IAM.

**Pour créer un mot de passe (AWS API)**

1. (Facultatif) Pour déterminer si un utilisateur possède un mot de passe, appelez cette opération : [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)

1. Pour créer un mot de passe, appelez cette opération : [CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)

**Pour modifier le mot de passe d'un utilisateur (AWS API)**

1. (Facultatif) Pour déterminer si un utilisateur possède un mot de passe, appelez cette opération : [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)

1. Pour modifier un mot de passe, procédez comme suit : [UpdateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html)

**Pour supprimer (désactiver) le mot de passe d'un utilisateur (AWS API)**

1. (Facultatif) Pour déterminer si un utilisateur possède un mot de passe, exécutez cette commande : [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)

1. (Facultatif) Pour déterminer quand un mot de passe a été utilisé pour la dernière fois, exécutez cette commande : [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)

1. Pour supprimer un mot de passe, exécutez cette commande : [DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html)

**Important**  
Lorsque vous supprimez le mot de passe d'un utilisateur, ce dernier ne peut plus se connecter à l’interface AWS Management Console. Si l'utilisateur dispose de clés d'accès actives, elles continuent de fonctionner et autorisent l'accès via les appels de fonction AWS CLI PowerShell, Outils pour Windows ou AWS API. Lorsque vous utilisez les AWS CLI outils pour Windows PowerShell ou l' AWS API pour supprimer un utilisateur de votre compte Compte AWS, vous devez d'abord supprimer le mot de passe à l'aide de cette opération. Pour de plus amples informations, veuillez consulter [Suppression d'un utilisateur IAM (AWS CLI)](id_users_remove.md#id_users_deleting_cli). 

**Pour révoquer les sessions de console actives d'un utilisateur avant une heure spécifiée (AWS API)**

1. Pour intégrer une politique en ligne qui révoque les sessions de console actives d'un utilisateur IAM avant une heure spécifiée, utilisez la stratégie en ligne suivante et exécutez cette commande : [PutUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html)

   Cette politique en ligne récuse toutes les autorisations et inclut la clé de condition `aws:TokenIssueTime`. Il révoque les sessions de console actives de l’utilisateur avant l’heure spécifiée dans l’élément `Condition` de la politique en ligne. Remplacez la valeur de la clé de condition `aws:TokenIssueTime` par votre propre valeur.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (Facultatif) Pour répertorier les noms des politiques intégrées à l'utilisateur IAM, exécutez cette commande : [ListUserPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserPolicies.html)

1. (Facultatif) Pour afficher la politique intégrée nommée intégrée à l'utilisateur IAM, exécutez cette commande : [GetUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUserPolicy.html)

# Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe
<a name="id_credentials_passwords_enable-user-change"></a>

**Note**  
Les utilisateurs dotés d'identités fédérées utiliseront le processus défini par leur fournisseur d'identité pour modifier leurs mots de passe. Il est [recommandé d'](best-practices.md)obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires.

Vous pouvez accorder aux utilisateurs IAM l'autorisation de modifier leurs propres mots de passe lors de la connexion à la AWS Management Console. Vous pouvez effectuer cette opération de deux manières :
+ [Autorisez tous les utilisateurs IAM du compte à modifier leurs propres mots de passe](#proc_letalluserschangepassword). 
+ [Autorisez uniquement les utilisateurs IAM sélectionnés à modifier leurs propres mots de passe](#proc_letselectuserschangepassword). Dans ce scénario, vous désactivez l'option permettant à tous les utilisateurs de modifier leurs propres mots de passe et vous utilisez une politique IAM pour accorder des autorisations uniquement à certains utilisateurs. Cette approche permet à ces utilisateurs de modifier leurs propres mots de passe et éventuellement d'autres informations d'identification telles que leurs propres clés d'accès. 

**Important**  
Nous vous recommandons de [définir une politique de mot de passe](id_credentials_passwords_account-policy.md) personnalisée qui oblige les utilisateurs IAM à créer des mots de passe d'un niveau de sécurité élevé.

## Pour autoriser tous les utilisateurs IAM à modifier leurs propres mots de passe
<a name="proc_letalluserschangepassword"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, cliquez sur **Paramètres du compte**.

1. Dans la section **Password policy** (Politique de mot de passe), sélectionnez **Edit** (Modifier).

1. Choisissez **Custom** (Personnalisé) pour utiliser une politique de mot de passe personnalisée.

1. Sélectionnez **Allow users to change their own password** (Autoriser les utilisateurs à modifier leur propre mot de passe), puis cliquez sur **Save changes** (Enregistrer les modifications). Cela permet à tous les utilisateurs du compte d'accéder à l'action `iam:ChangePassword` uniquement pour leur propre utilisateur et à l'action `iam:GetAccountPasswordPolicy`.

1. Fournissez aux utilisateurs les instructions suivantes pour modifier leurs mots de passe : [Modification par l'utilisateur IAM de son propre mot de passe](id_credentials_passwords_user-change-own.md). 

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam update-account-password-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)`

------
#### [ API ]

Pour créer un alias pour votre URL de la page de connexion de l' AWS Management Console , appelez l'opération suivante :
+ `[UpdateAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)` 

------

## Pour autoriser des utilisateurs IAM sélectionnés à modifier leurs propres mots de passe
<a name="proc_letselectuserschangepassword"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, cliquez sur **Paramètres du compte**. 

1. Dans la section **Paramètres du compte**, vérifiez que l'option **Autoriser les utilisateurs à modifier leur propre mot de passe** n'est pas sélectionnée. Si cette case à cocher est activée, tous les utilisateurs peuvent modifier leurs propres mots de passe. (Reportez-vous à la procédure précédente.) 

1. Créez les utilisateurs qui devraient être autorisés à modifier leurs propres mots de passe, s'il n'existe pas encore. Pour en savoir plus, consultez [Créez un utilisateur IAM dans votre Compte AWS](id_users_create.md). 

1. (Facultatif) Créez un groupe IAM pour les utilisateurs qui doivent être autorisés à modifier leurs mots de passe, puis ajoutez les utilisateurs de l'étape précédente au groupe. Pour en savoir plus, consultez [Groupes d'utilisateurs IAM](id_groups.md). 

1. Affectez la politique suivante au groupe. Pour de plus amples informations, veuillez consulter [Gestion des politiques IAM](access_policies_manage.md).

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "iam:GetAccountPasswordPolicy",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "iam:ChangePassword",
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       }
     ]
   }
   ```

------

   Cette politique donne accès à l'[ChangePassword](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html)action, qui permet aux utilisateurs de modifier uniquement leurs propres mots de passe depuis la console AWS CLI, les outils pour Windows PowerShell ou l'API. Elle donne également accès à l'[GetAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html)action, qui permet à l'utilisateur de consulter la politique de mot de passe actuelle ; cette autorisation est requise pour que l'utilisateur puisse consulter la politique de mot de passe du compte sur la page **Modifier le mot de passe**. L'utilisateur doit être autorisé à lire la politique de mot de passe actuelle pour s'assurer que le mot de passe satisfait les exigences de politique.

1. Fournissez aux utilisateurs les instructions suivantes pour modifier leurs mots de passe : [Modification par l'utilisateur IAM de son propre mot de passe](id_credentials_passwords_user-change-own.md). 

------

### Pour plus d’informations
<a name="HowToPwdIAMUser-moreinfo"></a>

Pour plus d'informations sur la gestion des informations d'identification, consultez les rubriques suivantes :
+ [Octroi aux utilisateurs IAM de l’autorisation de modification de leurs propres mots de passe](#id_credentials_passwords_enable-user-change) 
+ [Mots de passe utilisateur dans AWS](id_credentials_passwords.md)
+ [Définition d’une politique de mot de passe du compte pour les utilisateurs IAM](id_credentials_passwords_account-policy.md)
+ [Gestion des politiques IAM](access_policies_manage.md)
+ [Modification par l'utilisateur IAM de son propre mot de passe](id_credentials_passwords_user-change-own.md)

# Modification par l'utilisateur IAM de son propre mot de passe
<a name="id_credentials_passwords_user-change-own"></a>

Si vous avez été autorisé à modifier votre propre mot de passe utilisateur IAM, vous pouvez utiliser une page spéciale AWS Management Console à cet effet. Vous pouvez également utiliser l' AWS API AWS CLI or.

**Topics**
+ [Autorisations nécessaires](#change-own-passwords-permissions-required)
+ [Comment les utilisateurs IAM modifient leur mot de passe (console)](#ManagingUserPwdSelf-Console)
+ [Comment les utilisateurs IAM modifient leur propre mot de passe (AWS CLI ou AWS API)](#ManagingUserPwdSelf-CLIAPI)

## Autorisations nécessaires
<a name="change-own-passwords-permissions-required"></a>

Pour modifier le mot de passe pour votre propre utilisateur IAM, vous devez disposer des autorisations de la politique suivante : [AWS : autorise les utilisateurs IAM à modifier leur propre mot de passe pour la console sur la page Informations d’identification de sécurité](reference_policies_examples_aws_my-sec-creds-self-manage-password-only.md).

## Comment les utilisateurs IAM modifient leur mot de passe (console)
<a name="ManagingUserPwdSelf-Console"></a>

La procédure suivante décrit comment les utilisateurs IAM peuvent utiliser le AWS Management Console pour modifier leur propre mot de passe.

**Pour modifier votre propre mot de passe utilisateur IAM (console)**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Lien vers les identifiants de sécurité de la console de gestion\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans l'onglet **Informations d'identification AWS IAM**, sélectionnez **Mettre à jour le mot de passe**.

1. Dans le champ **Current password** (Mot de passe actuel), saisissez le mot de passe que vous utilisez actuellement. Entrez un nouveau mot de passe dans le champ **New password** (Nouveau mot de passe), puis confirmez-le dans le champ **Confirm new password** (Confirmer le nouveau mot de passe). Ensuite, choisissez l'option **Mettre à jour le mot de passe**.
**Note**  
Le nouveau mot de passe doit répondre aux exigences de la politique de mot de passe du compte. Pour de plus amples informations, veuillez consulter [Définition d’une politique de mot de passe du compte pour les utilisateurs IAM](id_credentials_passwords_account-policy.md). 

## Comment les utilisateurs IAM modifient leur propre mot de passe (AWS CLI ou AWS API)
<a name="ManagingUserPwdSelf-CLIAPI"></a>

La procédure suivante décrit comment les utilisateurs IAM peuvent utiliser l' AWS API AWS CLI or pour modifier leur propre mot de passe.

**Pour modifier votre mot de passe IAM, utilisez ce qui suit  :**
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html](https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html)
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html)

# Gestion des clés d’accès pour les utilisateurs IAM
<a name="id_credentials_access-keys"></a>

**Important**  
Les [bonnes pratiques](best-practices.md) consistent à utiliser des informations d'identification de sécurité temporaires (comme des rôles IAM) plutôt que de créer des informations d'identification à long terme comme des clés d'accès. Avant de créer des clés d'accès, passez en revue les [alternatives aux clés d'accès à long terme](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys).

Les clés d'accès sont les informations d'identification à long terme d'un utilisateur IAM ou du Utilisateur racine d'un compte AWS. Vous pouvez utiliser les clés d'accès pour signer des demandes programmatiques adressées à l' AWS API AWS CLI or (directement ou à l'aide du AWS SDK). Pour de plus amples informations, veuillez consulter [Accès programmatique avec identifiants AWS de sécurité](security-creds-programmatic-access.md).

Les clés d'accès se composent de deux parties : un ID de clé d'accès (par exemple, `AKIAIOSFODNN7EXAMPLE`) et une clé d'accès secrète (par exemple, `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`). Vous devez utiliser à la fois l'ID de la clé d'accès et la clé d'accès secrète pour authentifier vos demandes.



Lorsque vous créez une paire de clé d'accès, enregistrez l'ID de clé d'accès et la clé d'accès secrète dans un emplacement sécurisé. La clé d’accès secrète ne peut être récupérée qu’au moment de sa création. Si vous perdez votre clé d'accès secrète, vous devez supprimer la clé d'accès et en créer une nouvelle. Pour plus d’informations, consultez [Mise à jour des clés d’accès](id-credentials-access-keys-update.md).

Vous pouvez avoir un maximum de deux clés d'accès par utilisateur.

**Important**  
Les utilisateurs IAM dotés de clés d’accès constituent un risque pour la sécurité des comptes. Gérez vos clés d’accès en toute sécurité. Ne communiquez pas vos clés d’accès à des tiers non autorisés, même pour vous aider à trouver les [identifiants de votre compte](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html). Ce faisant, vous pouvez donner à quelqu'un un accès permanent à votre compte.  
Lorsque vous utilisez des clés d’accès, soyez conscient de ce qui suit :  
**N’utilisez PAS** les informations d’identification racine de votre compte pour créer des clés d’accès.
**N’incluez PAS** de clés d’accès ou d’informations d’identification dans vos fichiers d’application. 
**N’incluez PAS** de fichiers contenant des clés d’accès ou des informations d’identification dans votre zone de projet.
Les clés d'accès ou les informations d'identification stockées dans le fichier AWS d'informations d'identification partagé sont stockées en texte brut.

## Recommandations de surveillance
<a name="monitor-access-keys"></a>

Après avoir créé les clés d’accès :
+  AWS CloudTrail À utiliser pour surveiller l'utilisation des clés d'accès et détecter toute tentative d'accès non autorisée. Pour de plus amples informations, veuillez consulter [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md).
+ Configurez des CloudWatch alarmes pour avertir les administrateurs en cas de tentative de refus d'accès afin de détecter les activités malveillantes. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ Vérifiez, mettez à jour et supprimez régulièrement les clés d’accès selon les besoins.

Les rubriques suivantes détaillent les tâches de gestion associées aux clés d'accès.

**Topics**
+ [Recommandations de surveillance](#monitor-access-keys)
+ [Contrôler l’utilisation des clés d’accès en associant une politique en ligne à un utilisateur IAM](access-keys_inline-policy.md)
+ [Autorisations requises pour gérer les clés d'accès](access-keys_required-permissions.md)
+ [Gestion par les utilisateurs IAM de leurs propres clés d’accès](access-key-self-managed.md)
+ [Gestion des clés d’accès d’un utilisateur IAM par un administrateur IAM](access-keys-admin-managed.md)
+ [Mise à jour des clés d’accès](id-credentials-access-keys-update.md)
+ [Sécurisation des clés d’accès](securing_access-keys.md)

# Contrôler l’utilisation des clés d’accès en associant une politique en ligne à un utilisateur IAM
<a name="access-keys_inline-policy"></a>

Nous recommandons, à titre de bonne pratique, que les [charges de travail utilisent des informations d’identification temporaires avec des rôles IAM](best-practices.md#bp-workloads-use-roles) pour accéder à AWS. Les utilisateurs IAM disposant de clés d’accès doivent se voir attribuer un accès de moindre privilège et bénéficier d’une [authentification multifactorielle (MFA)](id_credentials_mfa.md). Pour plus d’informations sur l’endossement des rôles IAM, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md).

Toutefois, si vous créez un test de validation d’un service d’automatisation ou un autre cas d’utilisation à court terme, et que vous choisissez d’exécuter des charges de travail à l’aide d’un utilisateur IAM disposant de clés d’accès, nous vous recommandons d’[utiliser des conditions de politique pour restreindre davantage l’accès](best-practices.md#use-policy-conditions) aux informations d’identification de cet utilisateur IAM.

Dans cette situation, vous pouvez soit créer une politique à durée limitée qui fait expirer les informations d’identification après le délai spécifié, soit, si vous exécutez une charge de travail à partir d’un réseau sécurisé, utiliser une politique de restriction IP.

Pour ces deux cas d’utilisation, vous pouvez utiliser une politique en ligne associée à l’utilisateur IAM qui dispose des clés d’accès.

**Pour configurer une politique limitée dans le temps pour un utilisateur IAM**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation, choisissez **Utilisateurs**, puis sélectionnez l’utilisateur pour le cas d’utilisation à court terme. Si vous n’avez pas encore créé l’utilisateur, vous pouvez [le créer](getting-started-workloads.md) maintenant.

1. Sur la page **Détails** de l’utilisateur, choisissez l’onglet **Autorisations**.

1. Sélectionnez **Ajouter des autorisations**, puis **Créer la politique en ligne**.

1. Dans la section **Éditeur de politiques**, sélectionnez **JSON** pour afficher l’éditeur JSON.

1. Dans l’éditeur JSON, saisissez la politique suivante en remplaçant la valeur de l’horodatage `aws:CurrentTime` par la date et l’heure d’expiration souhaitées :

------
#### [ JSON ]

****  

   ```
   {
   "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
         "DateGreaterThan": {
         "aws:CurrentTime": "2025-03-01T00:12:00Z"
           }
         }
       }
     ]
   }
   ```

------

   Cette politique utilise l’effet `Deny` pour restreindre toutes les actions sur toutes les ressources après la date spécifiée. La condition `DateGreaterThan` compare l’heure actuelle avec l’horodatage que vous avez défini.

1. Sélectionnez **Suivant** pour accéder à la page **Vérifier et créer**. Dans **Détails de la politique**, sous **Nom de la politique**, saisissez un nom pour la politique, puis sélectionnez **Créer une politique**.

Une fois la politique créée, elle s’affiche dans l’onglet **Autorisations** de l’utilisateur. Lorsque l'heure actuelle est supérieure ou égale à l'heure spécifiée dans la politique, l'utilisateur n'aura plus accès aux AWS ressources. Veillez à informer les développeurs de charge de travail de la date d’expiration que vous avez spécifiée pour ces clés d’accès. 

**Pour configurer une politique de restriction IP pour un utilisateur IAM**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation, sélectionnez **Utilisateurs**, puis sélectionnez l’utilisateur qui exécutera la charge de travail à partir du réseau sécurisé. Si vous n’avez pas encore créé l’utilisateur, vous pouvez [le créer](getting-started-workloads.md) maintenant.

1. Sur la page **Détails** de l’utilisateur, choisissez l’onglet **Autorisations**.

1. Sélectionnez **Ajouter des autorisations**, puis **Créer la politique en ligne**.

1. Dans la section **Éditeur de politiques**, sélectionnez **JSON** pour afficher l’éditeur JSON.

1. Copiez la politique IAM suivante dans l'éditeur JSON et modifiez le public, les IPv6 adresses IPv4 ou les plages selon vos besoins. Vous pouvez utiliser [https://checkip.amazonaws.com/](https://checkip.amazonaws.com/)pour déterminer votre adresse IP publique actuelle. Vous pouvez spécifier des adresses IP individuelles ou des plages d’adresses IP à l’aide de la notation oblique. Pour de plus amples informations, veuillez consulter [aws:SourceIp](reference_policies_condition-keys.md#condition-keys-sourceip). 
**Note**  
Les adresses IP ne doivent pas être masquées par un VPN ou un serveur proxy.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Sid":"IpRestrictionIAMPolicyForIAMUser",
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
           "NotIpAddress": {
             "aws:SourceIp": [
               "203.0.113.0/24",
               "2001:DB8:1234:5678::/64",
               "203.0.114.1"
             ]
           },
           "BoolIfExists": {
             "aws:ViaAWSService": "false"
           }
         }
       }
     ]
   }
   ```

------

   Cet exemple de politique refuse l'utilisation des clés d'accès d'un utilisateur IAM lorsque cette politique est appliquée, sauf si la demande provient des réseaux (spécifiés en notation CIDR) « 203.0.113.0/24 », « 2001 : : 1234:5678 DB8 : :/64 » ou de l'adresse IP spécifique « 203.0.114.1 » 

1. Sélectionnez **Suivant** pour accéder à la page **Vérifier et créer**. Dans **Détails de la politique**, sous **Nom de la politique**, saisissez un nom pour la politique, puis sélectionnez **Créer une politique**.

Une fois la politique créée, elle s’affiche dans l’onglet **Autorisations** de l’utilisateur. 

Vous pouvez également appliquer cette politique en tant que politique de contrôle des services (SCP) à plusieurs AWS comptes. Nous vous recommandons d'utiliser une condition supplémentaire, `aws:PrincipalArn` afin que cette déclaration de politique ne s'applique qu'aux utilisateurs IAM des AWS comptes soumis à ce SCP. AWS Organizations La politique suivante inclut cette mise à jour :

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "IpRestrictionServiceControlPolicyForIAMUsers",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "2001:DB8:1234:5678::/64",
            "203.0.114.1"
          ]
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        },
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:user/*"
        }
      }
    }
  ]
}
```

------

# Autorisations requises pour gérer les clés d'accès
<a name="access-keys_required-permissions"></a>

**Note**  
`iam:TagUser` est une autorisation facultative permettant d'ajouter et de modifier des descriptions pour la clé d'accès. Pour de plus amples informations, consultez [Balisage des utilisateurs IAM](id_tags_users.md).

Pour créer des clés d'accès pour votre propre utilisateur IAM, vous devez disposer des autorisations de la politique suivante :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CreateOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

Pour mettre à jour des clés d'accès pour votre propre utilisateur IAM, vous devez disposer des autorisations de la politique suivante :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ManageOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:GetAccessKeyLastUsed",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

# Gestion par les utilisateurs IAM de leurs propres clés d’accès
<a name="access-key-self-managed"></a>

Les administrateurs IAM peuvent accorder aux utilisateurs IAM l’autorisation de gérer eux-mêmes leurs clés d’accès en attachant la politique décrite dans [Autorisations requises pour gérer les clés d'accès](access-keys_required-permissions.md).

Avec ces autorisations, l’utilisateur IAM peut utiliser les procédures suivantes pour créer, activer, désactiver et supprimer les clés d’accès associées à son nom d’utilisateur.

**Topics**
+ [Création d’une clé d’accès pour vous-même (console)](#Using_CreateAccessKey)
+ [Désactivation de votre clé d’accès (console)](#deactivate-access-key-seccreds)
+ [Activation de votre clé d’accès (console)](#activate-access-key-seccreds)
+ [Suppression de votre clé d’accès (console)](#delete-access-key-seccreds)

## Création d’une clé d’accès pour vous-même (console)
<a name="Using_CreateAccessKey"></a>

Si les autorisations appropriées vous ont été accordées, vous pouvez les utiliser AWS Management Console pour créer des clés d'accès pour vous-même.

**Pour créer vos propres clés d’accès (console)**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Lien vers les identifiants de sécurité de la console de gestion\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans la section **Clés d’accès**, choisissez **Créer une clé d’accès**. Si vous avez déjà deux clés d'accès, ce bouton est désactivé et vous devez supprimer une clé d'accès avant de pouvoir en créer une nouvelle.

1. Sur la page des **bonnes pratiques et alternatives en matière de clés d'accès**, choisissez votre cas d'utilisation pour découvrir les options supplémentaires qui peuvent vous aider à éviter de créer une clé d'accès à long terme. Si vous déterminez que votre cas d'utilisation nécessite toujours une clé d'accès, choisissez **Other** (Autre), puis **Next** (Suivant).

1. (Facultatif) Définissez une valeur de balise de description pour la clé d'accès. Cela permet d'ajouter une paire clé-valeur de balise à votre utilisateur IAM. Cela peut vous aider à identifier et à mettre à jour les clés d'accès par la suite. La clé de balise est définie sur l'identifiant de la clé d'accès. La valeur de balise est définie selon la description de la clé d'accès que vous spécifiez. Lorsque vous avez terminé, sélectionnez **Create access key** (Créer la clé d'accès).

1. Sur la page **Retrieve access keys** (Récupérer les clés d'accès), choisissez **Show** (Afficher) (pour révéler la valeur de la clé d'accès secrète de votre utilisateur) ou **Download .csv file** (Télécharger le fichier .csv). C'est le seul moment où vous pouvez enregistrer votre clé d'accès secrète. Après avoir enregistré votre clé d'accès secrète dans un emplacement sécurisé, sélectionnez **Done** (Terminé).

## Désactivation de votre clé d’accès (console)
<a name="deactivate-access-key-seccreds"></a>

Si les autorisations appropriées vous ont été accordées, vous pouvez les utiliser AWS Management Console pour désactiver votre clé d'accès.

**Pour désactiver une clé d'accès**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Lien vers les identifiants de sécurité de la console de gestion\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans la section **Access keys** (Clés d'accès), recherchez la clé que vous souhaitez désactiver, puis choisissez **Actions**, puis **Deactivate** (Désactiver). À l'invite de confirmation, cliquez sur **Deactivate** (Désactiver). Une clé d'accès désactivée compte toujours dans votre limite de deux clés d'accès.

## Activation de votre clé d’accès (console)
<a name="activate-access-key-seccreds"></a>

Si vous avez obtenu les autorisations appropriées, vous pouvez utiliser le AWS Management Console pour activer votre clé d'accès.

**Pour activer une clé d'accès**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Lien vers les identifiants de sécurité de la console de gestion\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans la section **Access keys** (Clés d'accès), recherchez la clé que vous souhaitez activer, puis choisissez **Actions**, puis **Activate** (Activer).

## Suppression de votre clé d’accès (console)
<a name="delete-access-key-seccreds"></a>

Si les autorisations appropriées vous ont été accordées, vous pouvez les utiliser AWS Management Console pour supprimer votre clé d'accès.

**Pour supprimer une clé d'accès dont vous n'avez plus besoin**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Lien vers les identifiants de sécurité de la console de gestion\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans la section **Access keys** (Clés d'accès), recherchez la clé que vous souhaitez suprimer, puis choisissez **Actions**, puis **Delete** (Supprimer). Suivez les instructions de la boîte de dialogue pour tout d'abord **désactiver**, puis confirmer la suppression. Nous vous recommandons de vérifier que la clé d'accès n'est plus utilisée avant de la supprimer définitivement.

# Gestion des clés d’accès d’un utilisateur IAM par un administrateur IAM
<a name="access-keys-admin-managed"></a>

Les administrateurs IAM peuvent créer, activer, désactiver et supprimer les clés d’accès associées à des utilisateurs IAM individuels. Ils peuvent également répertorier les utilisateurs IAM du compte qui possèdent des clés d’accès et localiser quel utilisateur IAM possède une clé d’accès spécifique.

**Topics**
+ [Pour créer une clé d’accès pour un utilisateur IAM](#admin-create-access-key)
+ [Pour désactiver une clé d’accès pour un utilisateur IAM](#admin-deactivate-access-key)
+ [Pour activer une clé d’accès pour un utilisateur IAM](#admin-activate-access-key)
+ [Pour supprimer une clé d’accès d’un utilisateur IAM](#admin-delete-access-key)
+ [Pour lister les clés d’accès d’un utilisateur IAM](#admin-list-access-key)
+ [Pour lister les clés d’accès d’un utilisateur IAM](#admin-list-access-key)
+ [Pour afficher toutes les clés d'accès IDs des utilisateurs de votre compte](#admin-list-all-access-keys)
+ [Pour rechercher un utilisateur à l’aide d’un ID de clé d’accès](#admin-find-user-access-keys)
+ [Pour recherche l’utilisation la plus récente d’un ID de clé d’accès](#admin-find-most-recent-use-access-keys)

## Pour créer une clé d’accès pour un utilisateur IAM
<a name="admin-create-access-key"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Dans l’onglet **Informations** d’identification, dans la section **Clés d’accès**, sélectionnez **Créer une clé d’accès**.

   Si le bouton est désactivé, vous devez supprimer l'une des clés existantes avant de pouvoir en créer une nouvelle.

1. Sur la page **Bonnes pratiques et alternatives en matière de clés d'accès**, passez en revue les bonnes pratiques et alternatives. Choisissez votre cas d'utilisation pour découvrir les options supplémentaires qui peuvent vous aider à éviter de créer une clé d'accès à long terme.

1. Si vous déterminez que votre cas d'utilisation nécessite toujours une clé d'accès, choisissez **Other** (Autre), puis **Next** (Suivant).

1. **(Facultatif)** Sur la page **Définir une balise de description**, vous pouvez ajouter une balise de description à la clé d’accès pour faciliter le suivi de votre clé d’accès. Sélectionnez **Créer une clé d’accès**.

1. Sur la page **Retrieve access key page** (Récupérer les clés d'accès), choisissez **Show** (Afficher) pour révéler la valeur de la clé d'accès secrète de votre utilisateur.

1. Pour enregistrer l'ID de clé d'accès et la clé d'accès secrète dans un fichier `.csv`, dans un emplacement sécurisé sur votre ordinateur, sélectionnez le bouton **Download .csv file** (Télécharger un fichier .csv).
**Important**  
Ce sera votre seule occasion de consulter ou télécharger la clé d’accès nouvellement créée et vous ne pourrez pas la récupérer. Assurez-vous de conserver votre clé d’accès en sécurité.

Lorsque vous créez une clé d'accès pour votre utilisateur, cette paire de clés est activée par défaut et votre utilisateur peut immédiatement l'utiliser.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html) 

------

## Pour désactiver une clé d’accès pour un utilisateur IAM
<a name="admin-deactivate-access-key"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Dans l’onglet **Informations d’identification de sécurité**, dans la section **Clés d’accès**, choisissez le menu déroulant **Actions**, puis sélectionnez **Désactiver**.

1. Dans la boîte de dialogue **Désactiver**, confirmez que vous souhaitez désactiver la clé d’accès en sélectionnant **Désactiver**

Une fois qu’une clé d’accès est désactivée, elle ne peut plus être utilisée par les appels d’API. Vous pouvez la réactiver si nécessaire.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## Pour activer une clé d’accès pour un utilisateur IAM
<a name="admin-activate-access-key"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Dans l’onglet **Informations d’identification de sécurité**, dans la section **Clés d’accès**, choisissez le menu déroulant **Actions**, puis sélectionnez **Activer**.

Une fois qu’une clé d’accès est activée, elle peut être utilisée par les appels d’API. Vous pouvez la désactiver à nouveau si nécessaire.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## Pour supprimer une clé d’accès d’un utilisateur IAM
<a name="admin-delete-access-key"></a>

Une fois qu’une clé d’accès a été désactivée, supprimez-la si elle n’est plus nécessaire.

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Dans l’onglet **Informations d’identification de sécurité**, dans la section **Clés d’accès**, choisissez le menu déroulant **Actions** pour la clé d’accès inactive, puis sélectionnez **Supprimer**.

1. Dans la boîte de dialogue **Supprimer**, confirmez que vous souhaitez supprimer la clé d’accès en saisissant son ID dans le champ de saisie de texte, puis en sélectionnant **Supprimer**.

Une fois que la clé d’accès est supprimée, elle ne peut pas être récupérée.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## Pour lister les clés d’accès d’un utilisateur IAM
<a name="admin-list-access-key"></a>

Vous pouvez consulter la liste des clés d'accès IDs associées à un utilisateur IAM. 

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Dans l’onglet **Informations d’identification de sécurité**, la section **Clés d’accès** répertorie les clés d’accès de l’utilisateur.

Chaque utilisateur IAM peut avoir deux clés d’accès.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## Pour lister les clés d’accès d’un utilisateur IAM
<a name="admin-list-access-key"></a>

Vous pouvez consulter la liste des clés d'accès IDs associées à un utilisateur IAM. 

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Dans l'onglet **Informations d'identification de sécurité**, la section **Clés** d'accès répertorie la clé IDs d'accès de l'utilisateur, y compris le statut de chaque clé affichée.
**Note**  
Seul l'ID de clé d'accès de l'utilisateur est visible. La clé d'accès secrète peut être récupérée uniquement au moment de la création de la clé.

Chaque utilisateur IAM peut avoir deux clés d’accès.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## Pour afficher toutes les clés d'accès IDs des utilisateurs de votre compte
<a name="admin-list-all-access-keys"></a>

Vous pouvez consulter la liste des clés d'accès IDs pour les utilisateurs de votre Compte AWS. 

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

1. Au besoin, ajoutez la colonne **ID de clé d'accès** à la table des utilisateurs en procédant comme suit :

   1. Au-dessus de la table à l’extrême droite, choisissez l’icône des **Préférences** (![\[Preferences icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. Dans la boîte de dialogue **Préférences**, sous **Sélectionner les colonnes visibles**, activez l’**ID de clé d’accès**.

   1. Choisissez **Confirmer** pour revenir à la liste des utilisateurs. La liste est mise à jour pour inclure l’ID de clé d’accès.

1. La colonne **ID de clé d’accès** indique l’état de chaque clé d’accès, suivi de son ID ; par exemple, **`Active - AKIAIOSFODNN7EXAMPLE`** ou **`Inactive - AKIAI44QH8DHBEXAMPLE`**. 

   Vous pouvez utiliser ces informations pour afficher et copier les clés d'accès IDs des utilisateurs possédant une ou deux clés d'accès. La colonne affiche **`-`** pour les utilisateurs ne disposant pas d’une clé d’accès.
**Note**  
La clé d'accès secrète peut être récupérée uniquement au moment de la création de la clé.

Chaque utilisateur IAM peut avoir deux clés d’accès.

------

## Pour rechercher un utilisateur à l’aide d’un ID de clé d’accès
<a name="admin-find-user-access-keys"></a>

Vous pouvez utiliser un ID de clé d’accès pour rechercher un utilisateur dans votre Compte AWS. 

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation, dans la zone de recherche, saisissez l’**ID de clé d’accès**, par exemple AKIAI44QH8DHBEXAMPLE. 

1. L’utilisateur IAM auquel l’ID de clé d’accès est associé apparaît dans le volet de navigation. Choisissez le nom d’utilisateur pour accéder à la page des détails de l’utilisateur.

------

## Pour recherche l’utilisation la plus récente d’un ID de clé d’accès
<a name="admin-find-most-recent-use-access-keys"></a>

L’utilisation la plus récente d’une clé d’accès est affichée dans la liste des utilisateurs sur la page des utilisateurs IAM, sur la page détaillée de l’utilisateur, et fait partie du rapport d’informations d’identification. 

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans la liste des utilisateurs, consultez la colonne **Dernière utilisation de clé d’accès**.

   Si la colonne n’est pas affichée, cliquez sur l’icône **Préférences** (![\[Preferences icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-settings-icon.console.png)) et sous **Sélectionner les colonnes visibles**, activez **Dernière utilisation de clé d’accès** pour afficher la colonne.

1. (facultatif) Dans le volet de navigation, sous **Rapports d’accès**, sélectionnez **Rapport d’informations d’identification** pour télécharger un rapport qui inclut les informations relatives aux dernières utilisations de clé d’accès pour tous les utilisateurs IAM de votre compte.

1. (facultatif) Sélectionnez l’utilisateur IAM pour afficher les détails de l’utilisateur. La section **Résumé** inclut la clé d'accès IDs, leur statut et la date de leur dernière utilisation.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) 

------

# Mise à jour des clés d’accès
<a name="id-credentials-access-keys-update"></a>

Comme [bonne pratique](best-practices.md#update-access-keys) en matière de sécurité, nous vous recommandons de mettre à jour les clés d'accès de l'utilisateur IAM en cas de besoin, par exemple lorsqu'un employé quitte votre entreprise. Les utilisateurs IAM peuvent mettre à jour leurs propres clés d'accès s'ils ont obtenu les autorisations nécessaires.

Pour plus d'informations concernant l'octroi aux utilisateurs IAM d'autorisations de mise à jour de leurs propres clés d'accès, veuillez consulter [AWS : autorise les utilisateurs IAM à gérer leurs propres mot de passe, clés d’accès et clés publiques SSH sur la page Informations d’identification de sécurité](reference_policies_examples_aws_my-sec-creds-self-manage-pass-accesskeys-ssh.md). Vous pouvez également appliquer une politique de mots de passe à votre compte pour exiger que tous vos utilisateurs IAM mettent périodiquement à jour leurs mots de passe et la fréquence à laquelle ils doivent le faire. Pour de plus amples informations, veuillez consulter [Définition d’une politique de mot de passe du compte pour les utilisateurs IAM](id_credentials_passwords_account-policy.md). 

**Note**  
Si vous perdez votre clé d'accès secrète, vous devez supprimer la clé d'accès et en créer une nouvelle. La clé d’accès secrète ne peut être récupérée qu’au moment de sa création. Utilisez cette procédure pour désactiver puis remplacer les clés d’accès perdues par de nouvelles informations d’identification.

**Topics**
+ [Mise à jour des clés d'accès pour un utilisateur IAM (console)](#rotating_access_keys_console)
+ [Mise à jour des clés d'accès (AWS CLI)](#rotating_access_keys_cli)
+ [Mise à jour des clés d'accès (AWS API)](#rotating_access_keys_api)

## Mise à jour des clés d'accès pour un utilisateur IAM (console)
<a name="rotating_access_keys_console"></a>

Vous pouvez mettre à jour les clés d'accès à partir de l' AWS Management Console.

**Pour mettre à jour les clés d'accès pour un utilisateur IAM sans interrompre vos applications (console)**

1. Pendant que la première clé d'accès est encore active, créez une seconde clé d'accès.

   1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

   1. Dans le panneau de navigation, choisissez **utilisateurs**.

   1. Choisissez le nom utilisateur concerné, puis sélectionnez l'onglet **Informations d'identification de sécurité**.

   1. Dans la section **Clés d'accès**, choisissez **Créer une clé d'accès**. Sur la page des **bonnes pratiques et alternatives en matière de clés d'accès**, choisissez **Other** (Autre), puis **Next** (Suivant).

   1. (Facultatif) Définissez une valeur de balise de description pour la clé d'accès afin d'ajouter une paire clé-valeur de balise à cet utilisateur IAM. Cela peut vous aider à identifier et à mettre à jour les clés d'accès par la suite. La clé de balise est définie sur l'identifiant de la clé d'accès. La valeur de balise est définie selon la description de la clé d'accès que vous spécifiez. Lorsque vous avez terminé, sélectionnez **Create access key** (Créer la clé d'accès).

   1. Sur la page **Retrieve access keys** (Récupérer les clés d'accès), choisissez **Show** (Afficher) (pour révéler la valeur de la clé d'accès secrète de votre utilisateur) ou **Download .csv file** (Télécharger le fichier .csv). C'est le seul moment où vous pouvez enregistrer votre clé d'accès secrète. Après avoir enregistré votre clé d'accès secrète dans un emplacement sécurisé, sélectionnez **Done** (Terminé).

      Lorsque vous créez une clé d'accès pour votre utilisateur, cette paire de clés est activée par défaut et votre utilisateur peut immédiatement l'utiliser. À ce stade, l'utilisateur dispose de deux clés d'accès actives.

1. Mettez à jour toutes les applications et tous les outils pour utiliser la nouvelle clé d'accès.

1. <a name="id_credentials_access-keys-key-still-in-use"></a>Déterminez si la première clé d'accès est toujours utilisée en consultant les informations **Dernière utilisation** de la clé d'accès la plus ancienne. Une des approches possibles consiste à attendre plusieurs jours, puis à vérifier si l'ancienne clé d'accès a été utilisée avant de poursuivre.

1. Même si la valeur des informations **Dernière utilisation** indique que l'ancienne clé n'a jamais été utilisée, nous vous recommandons de ne pas supprimer immédiatement la première clé d'accès. À la place, sélectionnez **Actions**, puis **Deactivate** (Désactiver) pour désactiver la première clé d'accès.

1. Utilisez uniquement la nouvelle clé d'accès pour confirmer que vos applications fonctionnent. Toutes les applications et tous les outils qui utilisent encore la clé d'accès d'origine cesseront de fonctionner à ce stade car ils n'ont plus accès aux AWS ressources. Si vous rencontrez l'une de ces applications ou l'un de ces outils, vous pouvez réactiver la première clé d'accès. Revenez ensuite à [Step 3](#id_credentials_access-keys-key-still-in-use) et mettez à jour cette application afin d'utiliser la nouvelle clé.

1. Après avoir attendu un certain temps pour vous assurer que toutes les applications et tous les outils ont été mis à jour, vus pouvez supprimer la première clé d'accès:

   1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

   1. Dans le panneau de navigation, choisissez **utilisateurs**.

   1. Choisissez le nom utilisateur concerné, puis sélectionnez l'onglet **Informations d'identification de sécurité**.

   1. Dans la section **Access keys** (Clés d'accès) correspondant à la clé d'accès que vous souhaitez supprimer, choisissez **Actions**, puis **Delete** (Supprimer). Suivez les instructions de la boîte de dialogue pour tout d'abord **désactiver**, puis confirmer la suppression.

**Pour déterminer quelles clés d'accès doivent être mises à jour ou supprimées (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Au besoin, ajoutez la colonne **Access key age (Âge de la clé d'accès)** à la table des utilisateurs en procédant comme suit :

   1. Au-dessus de la table à l'extrême droite, choisissez l'icône des paramètres (![\[Settings icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. Dans **Manage columns (Gérer les colonnes)**, sélectionnez **Access key age (Âge de la clé d'accès)**.

   1. Choisissez **Fermer** pour revenir à la liste des utilisateurs.

1. La colonne **Access key age (Âge de la clé d'accès)** affiche le nombre de jours écoulés depuis la création de la clé d'accès active la plus ancienne. Vous pouvez utiliser ces informations pour trouver les utilisateurs dont les clés d'accès doivent être mises à jour ou supprimées. La colonne affiche **Aucun** pour les utilisateurs sans clé d'accès.

## Mise à jour des clés d'accès (AWS CLI)
<a name="rotating_access_keys_cli"></a>

Vous pouvez mettre à jour les clés d'accès à partir de l' AWS Command Line Interface.

**Pour mettre à jour les clés d'accès sans interrompre vos applications (AWS CLI)**

1. Pendant que la première clé d'accès est encore active, créez une seconde clé d'accès qui est active par défaut. Exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

     À ce stade, l'utilisateur dispose de deux clés d'accès actives.

1. <a name="step-update-apps"></a>Mettez à jour toutes les applications et tous les outils pour utiliser la nouvelle clé d'accès.

1. <a name="step-determine-use"></a>Déterminez si la première clé d'accès est toujours utilisée à l'aide de cette commande :
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

   Une des approches possibles consiste à attendre plusieurs jours, puis à vérifier si l'ancienne clé d'accès a été utilisée avant de poursuivre.

1. Même si l'étape [Step 3](#step-determine-use) n'indique aucune utilisation de l'ancienne clé, nous vous recommandons de ne pas supprimer immédiatement la première clé d'accès. Définissez plutôt l'état de la première clé d'accès sur `Inactive` à l'aide de cette commande :
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

1. Utilisez uniquement la nouvelle clé d'accès pour confirmer que vos applications fonctionnent. Toutes les applications et tous les outils qui utilisent encore la clé d'accès d'origine cesseront de fonctionner à ce stade car ils n'ont plus accès aux AWS ressources. Si vous rencontrez l'une de ces applications ou l'un de ces outils, vous pouvez définir à nouveau son état sur `Active` pour réactiver la première clé d'accès. Revenez ensuite à l'étape [Step 2](#step-update-apps) et mettez à jour cette application afin d'utiliser la nouvelle clé.

1. Après avoir attendu un certain temps pour vous assurer que toutes les applications et tous les outils ont été mis à jour, vus pouvez supprimer la première clé d'accès à l'aide de cette commande :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

## Mise à jour des clés d'accès (AWS API)
<a name="rotating_access_keys_api"></a>

Vous pouvez mettre à jour les clés d'accès à l'aide de l' AWS API.

**Pour mettre à jour les clés d'accès sans interrompre vos applications (AWS API)**

1. Pendant que la première clé d'accès est encore active, créez une seconde clé d'accès qui est active par défaut. Appelez l’opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html)

     À ce stade, l'utilisateur dispose de deux clés d'accès actives.

1. <a name="step-update-apps-2"></a>Mettez à jour toutes les applications et tous les outils pour utiliser la nouvelle clé d'accès.

1. <a name="step-determine-use-2"></a>Déterminez si la première clé d'accès est toujours utilisée en appelant cette opération :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)

   Une des approches possibles consiste à attendre plusieurs jours, puis à vérifier si l'ancienne clé d'accès a été utilisée avant de poursuivre.

1. Même si l'étape [Step 3](#step-determine-use-2) n'indique aucune utilisation de l'ancienne clé, nous vous recommandons de ne pas supprimer immédiatement la première clé d'accès. Définissez plutôt l'état de la première clé d'accès sur `Inactive` en appelant cette opération :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html)

1. Utilisez uniquement la nouvelle clé d'accès pour confirmer que vos applications fonctionnent. Toutes les applications et tous les outils qui utilisent encore la clé d'accès d'origine cesseront de fonctionner à ce stade car ils n'ont plus accès aux AWS ressources. Si vous rencontrez l'une de ces applications ou l'un de ces outils, vous pouvez définir à nouveau son état sur `Active` pour réactiver la première clé d'accès. Revenez ensuite à l'étape [Step 2](#step-update-apps-2) et mettez à jour cette application afin d'utiliser la nouvelle clé.

1. Après avoir attendu un certain temps pour vous assurer que toutes les applications et tous les outils ont été mis à jour, vus pouvez supprimer la première clé d'accès en appelant cette opération :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)

# Sécurisation des clés d’accès
<a name="securing_access-keys"></a>

Toute personne disposant de vos clés d'accès a le même niveau d'accès à vos AWS ressources que vous. Par conséquent, AWS elle met tout en œuvre pour protéger vos clés d'accès et, conformément à notre [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/), vous devriez faire de même. 

Développez les sections suivantes pour obtenir des conseils qui vous aideront à protéger vos clés d'accès. 

**Note**  
Votre organisation peut avoir des exigences de sécurité et des stratégies différentes de celles décrites dans cette rubrique. Les suggestions fournies ici doivent être considérées comme des directives générales. 

## Supprimer (ou ne pas générer) les clés Utilisateur racine d'un compte AWS d'accès
<a name="root-password"></a>

**Le meilleur moyen de protéger votre compte est de n'avoir aucune clé d'accès pour votre Utilisateur racine d'un compte AWS.** À moins d'avoir impérativement besoin des clés d'accès de l'utilisateur root (ce qui est rare), il est préférable de ne pas les générer. Créez plutôt un utilisateur administratif pour les tâches administratives quotidiennes. AWS IAM Identity Center Pour plus d'informations sur la création d'un utilisateur administratif dans IAM Identity Center, voir [Getting started](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html) dans le guide de l'utilisateur d'*IAM Identity* Center.

Si vous disposez déjà de clés d'accès d'utilisateur root pour votre compte, nous vous recommandons ce qui suit : recherchez dans vos applications les endroits où vous utilisez actuellement des clés d'accès (le cas échéant) et remplacez les clés d'accès de l'utilisateur root par celles de l'utilisateur IAM. Ensuite, désactivez et supprimez les clés d'accès de l'utilisateur root. Pour plus d'informations sur les modalités de mise à jour des clés d'accès, veuillez consulter [Mise à jour des clés d’accès](id-credentials-access-keys-update.md).



## Utiliser les informations d'identification de sécurité temporaires (rôles IAM) au lieu des clés d'accès à long terme
<a name="use-roles"></a>

Dans de nombreux cas, vous n'avez pas besoin d'une clé d'accès à long terme qui n'expire jamais (comme dans le cas d'un utilisateur IAM). Au lieu de cela, vous pouvez créer des rôles IAM et générer des informations d'identification de sécurité temporaires. Les informations d'identification de sécurité temporaires consistent en un ID de clé d'accès et une clé d'accès secrète, mais elles comprennent également un jeton de sécurité qui indique la date d'expiration des informations d'identification. 

Les clés d'accès à long terme, telles que celles associées aux utilisateurs IAM et à l'utilisateur root, demeurent valides jusqu'à ce que vous les révoquiez manuellement. Toutefois, les informations d'identification de sécurité temporaires obtenues via les rôles IAM et d'autres fonctionnalités de l'IAM AWS Security Token Service expirent après un court laps de temps. Utilisez les informations d'identification de sécurité temporaires pour vous aider à réduire les risques en cas de compromission accidentelle des informations d'identification.

Utilisez un rôle IAM et les informations d'identification de sécurité temporaires dans les cas suivants :
+ **Vous avez une application ou AWS CLI des scripts exécutés sur une instance Amazon EC2.** N'utilisez pas les clés d'accès directement dans votre application. Ne transmettez pas les clés d'accès à l'application, ne les intégrez pas à l'application et ne laissez pas l'application les lire depuis n'importe quelle source. Définissez plutôt un rôle IAM qui dispose des autorisations adéquates pour votre application et lancez l'instance Amazon Elastic Compute Cloud (Amazon EC2) avec des [rôles pour EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html). Cela permet d'associer un rôle IAM à l'instance Amazon EC2. Cette pratique permet également à l'application d'obtenir des informations d'identification de sécurité temporaires qu'elle peut à son tour utiliser pour effectuer des appels à AWS. Le AWS SDKs et le AWS Command Line Interface (AWS CLI) peuvent obtenir automatiquement des informations d'identification temporaires à partir du rôle. 
+ **Vous devez accorder l'accès entre comptes.** Utilisez un rôle IAM pour établir une relation d'approbation entre les comptes, puis accordez aux utilisateurs d'un compte des autorisations limitées pour accéder au compte approuvé. Pour de plus amples informations, veuillez consulter [Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md).
+ **Vous disposez d'une application mobile.** N'intégrez pas les clés d'accès à l'application, même dans un espace de stockage chiffré. Au lieu de cela, utilisez [Amazon Cognito](https://aws.amazon.com/cognito/) pour gérer les identités de l'utilisateur dans votre application. Ce service vous permet d'authentifier les utilisateurs à l'aide de Login with Amazon, Facebook, Google ou tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC). Vous pouvez ensuite utiliser le fournisseur d'informations d'identification d'Amazon Cognito pour gérer les informations d'identification que votre application utilise pour effectuer des requêtes à AWS.
+ **Vous souhaitez vous fédérer dans le protocole SAML AWS 2.0 et votre organisation le prend en charge.** Si vous travaillez pour une organisation disposant d'un fournisseur d'identité prenant en charge SAML 2.0, configurez le fournisseur pour qu'il utilise SAML. Vous pouvez utiliser le protocole SAML pour échanger des informations d'authentification avec un ensemble d'informations d'identification de sécurité temporaires AWS et en récupérer un. Pour de plus amples informations, veuillez consulter [Fédération SAML 2.0](id_roles_providers_saml.md).
+ **Vous souhaitez vous fédérer dans un magasin d'identités sur site AWS et votre organisation dispose d'un magasin d'identités.** Si les utilisateurs peuvent s'authentifier au sein de votre organisation, vous pouvez créer une application qui peut leur délivrer des informations d'identification de sécurité temporaires pour accéder aux AWS ressources. Pour de plus amples informations, veuillez consulter [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).
+ **Utilisez les conditions des politiques IAM pour n’autoriser l’accès qu’à partir des réseaux attendus.** Vous pouvez limiter où et comment vos clés d'accès sont utilisées en mettant en œuvre des [politiques IAM avec des conditions](reference_policies_elements_condition_operators.md) qui spécifient et n'autorisent que les réseaux attendus, tels que vos adresses IP publiques ou vos clouds privés virtuels (VPCs). De cette façon, vous savez que les clés d’accès ne peuvent être utilisées qu’à partir de réseaux attendus et acceptables. 

**Note**  
Utilisez-vous une instance Amazon EC2 avec une application qui nécessite un accès programmatique aux ressources ? AWS Dans ce cas, utilisez les [rôles IAM pour EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).

## Gérer correctement les clés d'accès d'un utilisateur IAM
<a name="iam-user-access-keys"></a>

Si vous devez créer des clés d'accès pour un accès programmatique AWS, créez-les pour les utilisateurs IAM, en leur accordant uniquement les autorisations dont ils ont besoin.

Respectez les précautions suivantes pour protéger les clés d'accès des utilisateurs IAM :
+ **N'intégrez pas de clés d'accès directement dans le code.** Les outils de [ligne de AWS commande [AWS SDKs](https://aws.amazon.com/tools/#sdk)et les outils](https://aws.amazon.com/tools/#cli) de ligne de commande vous permettent de placer les clés d'accès à des emplacements connus afin de ne pas avoir à les conserver dans le code. 

  Placez les clés d'accès à l'un des emplacements suivants :
  + **Le fichier AWS d'informations d'identification.** Les AWS SDKs et utilisent AWS CLI automatiquement les informations d'identification que vous stockez dans le fichier AWS d'informations d'identification. 

    Pour plus d'informations sur l'utilisation du fichier AWS d'informations d'identification, consultez la documentation de votre SDK. Les exemples incluent [Définir les AWS informations d'identification et la région](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html) dans le *guide du AWS SDK pour Java développeur* et les [fichiers de configuration et d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) dans le *guide de l'AWS Command Line Interface utilisateur*.

    Pour stocker les informations d'identification des AWS SDK pour .NET et AWS Tools for Windows PowerShell, nous vous recommandons d'utiliser le SDK Store. Pour plus d'informations, veuillez consulter la rubrique [Using the SDK Store](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html) dans le *Guide du développeur AWS SDK pour .NET *.
  + **Variables d'environnement.** Sur un système à locataires multiples, choisissez des variables d'environnement utilisateur, et non pas des variables d'environnement système. 

    Pour plus d'informations sur l'utilisation des variables d'environnement pour stocker les informations d'identification, veuillez consulter la rubrique [Environment Variables](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html) dans le *Guide de l'utilisateur AWS Command Line Interface *. 
+ **Utilisez des clés d'accès différentes pour chaque application.** Procédez ainsi afin de pouvoir isoler les autorisations et révoquer les clés d'accès pour des applications individuelles si elles sont compromises. Le fait d'avoir des clés d'accès distinctes pour différentes applications génère également des entrées distinctes dans les fichiers journaux [AWS CloudTrail](https://aws.amazon.com/cloudtrail/). Cette configuration vous permet d'identifier plus facilement quelle application a effectué des actions spécifiques. 
+ **Mettez à jour les clés d'accès en cas de besoin.** Si la clé d'accès risque d'être compromise, mettez-la à jour et supprimez la clé d'accès précédente. Pour plus d’informations, consultez [Mise à jour des clés d’accès](id-credentials-access-keys-update.md). 
+ **Supprimez les clés d'accès inutilisées.** Si un utilisateur quitte votre organisation, supprimez l'utilisateur IAM correspondant afin qu'il ne puisse plus accéder à vos ressources. Pour savoir quand une clé d'accès a été utilisée pour la dernière fois, utilisez l'[https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)API (AWS CLI command : [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)).
+ **Utilisez des informations d'identification temporaires et configurez l'authentification multifactorielle pour vos opérations d'API les plus sensibles.** Avec les politiques IAM, vous pouvez spécifier quelles opérations d'API un utilisateur est autorisé à appeler. Dans certains cas, vous souhaiterez peut-être bénéficier d'une sécurité supplémentaire en exigeant que les utilisateurs soient authentifiés par le biais de la AWS MFA avant de les autoriser à effectuer des actions particulièrement sensibles. Par exemple, vous disposez peut-être d'une politique qui autorise l'utilisateur à exécuter les actions Amazon EC2 `RunInstances`, `DescribeInstances` et `StopInstances`. Mais vous souhaiterez peut-être restreindre une action destructrice telle que `TerminateInstances` et vous assurer que les utilisateurs ne peuvent effectuer cette action que s'ils s'authentifient auprès d'un périphérique AWS MFA. Pour de plus amples informations, veuillez consulter [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md).

## Accédez à l'application mobile à l'aide des touches AWS d'accès
<a name="access-keys-mobile-app"></a>

Vous pouvez accéder à un ensemble limité de AWS services et de fonctionnalités à l'aide de l'application AWS mobile. L'application mobile vous aide à prendre en charge la réponse aux incidents pendant vos déplacements. Pour de plus amples informations et pour télécharger l'application, veuillez consulter [Console AWS pour les applications mobiles](https://aws.amazon.com/console/mobile/).

Vous pouvez vous connecter à l'application mobile à l'aide du mot de passe de votre console ou de vos clés d'accès. En guise de bonne pratique, n'utilisez pas les clés d'accès de l'utilisateur root. Nous vous recommandons vivement, en plus d'utiliser un mot de passe ou un verrou biométrique sur votre appareil mobile, de créer un utilisateur IAM spécifiquement chargé de gérer les AWS ressources à l'aide de l'application mobile. Si vous perdez votre appareil mobile, vous pouvez supprimer l'accès de l'utilisateur IAM.

**Pour vous connecter à l'aide des clés d'accès (application mobile)**

1. Ouvrez l'application sur votre appareil mobile.

1. Si c'est la première fois que vous ajoutez une identité à l'appareil, choisissez **Ajouter une identité**, puis cliquez sur **Clés d'accès**.

   Si vous vous êtes déjà connecté à l'aide d'une autre identité, choisissez l'icône de menu et choisissez **Changer d'identité**. Choisissez ensuite **Se connecter en tant qu'identité différente**, puis **Clés d'accès**.

1. Sur la page **Clés d'accès**, saisissez vos informations :
   + **ID de clé d'accès** : saisissez votre ID de clé d'accès.
   + **Clé d'accès secrète** : saisissez votre clé d'accès secrète.
   + **Nom de l'identité** : saisissez le nom de l'identité qui apparaîtra dans l'application mobile. Elle ne doit pas nécessairement correspondre à votre nom d'utilisateur IAM.
   + **Code PIN d'identité** : créez un numéro d'identification personnel (PIN) que vous utiliserez pour les prochaines connexions.
**Note**  
Si vous activez la biométrie pour l'application AWS mobile, vous serez invité à utiliser votre empreinte digitale ou votre reconnaissance faciale pour la vérification au lieu du code PIN. Si la biométrie échoue, vous pouvez être invité à entrer le code PIN à la place.

1. Choisissez **Vérifier et ajouter des clés**.

   Vous pouvez désormais accéder à un ensemble sélectionné de vos ressources à l'aide de l'application mobile.

## Informations connexes
<a name="more-resources"></a>

Les rubriques suivantes fournissent des conseils pour configurer AWS SDKs et utiliser AWS CLI les clés d'accès :
+ [Définissez AWS les informations d'identification et la région](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html) dans le *guide du AWS SDK pour Java développeur*
+ [Using the SDK Store](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html) dans le *Guide du développeur AWS SDK pour .NET *
+ [Providing Credentials to the SDK](https://docs.aws.amazon.com/aws-sdk-php/v2/guide/credentials.html) dans le *Guide du développeur AWS SDK pour PHP *
+ [Configuration](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#configuration) dans la documentation de Boto 3 (AWS SDK pour Python)
+ [Using AWS Credentials](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html) dans le *Guide de l'utilisateur AWS Tools for Windows PowerShell * 
+ [Configuration and credential files](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) dans le *Guide de l'utilisateur AWS Command Line Interface * 
+ [Granting access using an IAM role](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) dans le *Guide du développeur AWS SDK pour .NET *
+ [Configure IAM roles for Amazon EC2](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) dans le *AWS SDK for Java 2.x*

## Utilisation des clés d’accès et des informations d’identification de clé secrète pour l’accès à la console
<a name="console-access-security-keys"></a>

Il est possible d’utiliser des informations d’identification de clé d’accès et de clé secrète pour un accès à l’ AWS Management Console direct, et pas seulement l’ AWS CLI. Cela peut être réalisé à l'aide de l'appel d' AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API. En créant une URL de console à l’aide des informations d’identification temporaires et du jeton fournis par `GetFederationToken`, les principaux IAM peuvent accéder à la console. Pour de plus amples informations, veuillez consulter [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).

Il convient de préciser que lorsque vous vous connectez directement à la console à l’aide des informations d’identification IAM ou utilisateur racine avec la MFA activée, cette dernière sera requise. Toutefois, si la méthode décrite ci-dessus (en utilisant des informations d’identification temporaires avec `GetFederationToken`) est utilisée, la MFA ne sera PAS requise.



## Audit des clés d'accès
<a name="Using_access-keys-audit"></a>

Vous pouvez vérifier les clés AWS d'accès contenues dans votre code pour déterminer si elles proviennent d'un compte que vous possédez. Vous pouvez transmettre un identifiant de clé d'accès à l'aide de la [https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html) AWS CLI commande ou de l'opération [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html) AWS API.

Les opérations AWS CLI et AWS API renvoient l'ID du Compte AWS auquel appartient la clé d'accès. Les clés d'accès IDs commençant par `AKIA` sont des informations d'identification à long terme pour un utilisateur IAM ou un Utilisateur racine d'un compte AWS. Les clés d'accès IDs commençant par `ASIA` sont des informations d'identification temporaires créées à l'aide d' AWS STS opérations. Si le compte de la réponse vous appartient, vous pouvez vous connecter en tant qu'utilisateur racine et vérifier vos clés d'accès d'utilisateur racine. Ensuite, vous pouvez extraire un [rapport d'informations d'identification](id_credentials_getting-report.md) pour savoir quel utilisateur IAM possède les clés. Pour savoir qui a demandé les informations d'identification temporaires pour une clé d'`ASIA`accès, consultez les AWS STS événements dans vos CloudTrail journaux.

Pour des raisons de sécurité, vous pouvez [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Vous pouvez utiliser la clé de condition `sts:SourceIdentity` dans la politique d'approbation de rôle pour exiger des utilisateurs qu'ils spécifient une identité lorsqu'ils endossent un rôle. Par exemple, vous pouvez exiger que les utilisateurs IAM spécifient leur propre nom d'utilisateur comme identité de source. Cela peut vous aider à déterminer quel utilisateur a effectué une action spécifique dans AWS. Pour de plus amples informations, veuillez consulter [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity).

Cette opération n'indique pas l'état de la clé d'accès. La clé peut être active, inactive ou supprimée. Les clés actives peuvent ne pas avoir les autorisations nécessaires pour effectuer une opération. La fourniture d'une clé d'accès supprimée peut renvoyer une erreur indiquant que la clé n'existe pas.

# AWS Authentification multifactorielle dans IAM
<a name="id_credentials_mfa"></a>

Pour une sécurité accrue, nous vous recommandons de configurer l'authentification multifactorielle (MFA) afin de protéger AWS vos ressources. Vous pouvez activer le Utilisateur racine d'un compte AWS MFA pour tous Comptes AWS, y compris les comptes autonomes, les comptes de gestion et les comptes membres, ainsi que pour vos utilisateurs IAM. Nous vous recommandons d'utiliser des MFA résistants au hameçonnage, tels que des clés d'accès et des clés de sécurité, dans la mesure du possible. Ces authentificateurs basés sur Fido utilisent la cryptographie à clé publique et résistent au phishing et aux attaques par replay man-in-the-middle, offrant ainsi un niveau de sécurité supérieur à celui des options basées sur le TOTP.

La MFA est appliquée à tous les types de comptes pour leur utilisateur racine. Pour de plus amples informations, veuillez consulter [Sécurisez les identifiants de l'utilisateur root de votre AWS Organizations compte](root-user-best-practices.md#ru-bp-organizations). 

Lorsque vous activez l'authentification MFA pour l'utilisateur root, cela affecte uniquement les informations d'identification de l'utilisateur root. Les utilisateurs IAM du compte sont des identités distinctes avec leurs propres informations d'identification, et chaque identité dispose de sa propre configuration MFA. Pour de plus amples informations sur l’utilisation de l’authentification multifactorielle (MFA) pour protéger l’utilisateur racine, veuillez consulter [Authentification multifactorielle pour Utilisateur racine d'un compte AWS](enable-mfa-for-root.md).

Vos utilisateurs Utilisateur racine d'un compte AWS et ceux d'IAM peuvent enregistrer jusqu'à huit appareils MFA de tout type. L’enregistrement de plusieurs dispositifs MFA peut apporter de la flexibilité et vous aider à réduire le risque d’interruption d’accès en cas de perte ou de panne d’un dispositif. Vous n’avez besoin que d’un seul dispositif MFA pour vous connecter à l’ AWS Management Console ou créer une session via l’ AWS CLI.

**Note**  
Nous vous recommandons de demander à vos utilisateurs humains d'utiliser des informations d'identification temporaires lors de l'accès AWS. Avez-vous envisagé d'en utiliser AWS IAM Identity Center ? Vous pouvez utiliser IAM Identity Center pour gérer de manière centralisée l'accès à plusieurs comptes Comptes AWS et fournir aux utilisateurs un accès par authentification unique protégé par le MFA à tous les comptes qui leur sont attribués à partir d'un seul endroit. Avec IAM Identity Center, vous pouvez créer et gérer les identités des utilisateurs dans IAM Identity Center ou vous connecter facilement à votre fournisseur d'identité compatible SAML 2.0 existant. 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 *.

La MFA ajoute une sécurité supplémentaire qui oblige les utilisateurs à fournir une authentification unique à partir d'un mécanisme AWS MFA compatible en plus de leurs informations de connexion lorsqu'ils accèdent à des sites Web ou à des services. AWS 

## Types MFA
<a name="id_credentials_mfa-types"></a>

AWS prend en charge les types de MFA suivants :

**Contents**
+ [Clés d’accès et clés de sécurité](#passkeys-security-keys-for-iam-users)
+ [Applications d’authentification virtuelle](#virtual-auth-apps-for-iam-users)
+ [Jetons TOTP matériels](#hardware-totp-token-for-iam-users)

### Clés d’accès et clés de sécurité
<a name="passkeys-security-keys-for-iam-users"></a>

Gestion des identités et des accès AWS prend en charge les clés d'accès et les clés de sécurité pour la MFA. Basées sur les normes FIDO, les clés d'accès utilisent la cryptographie à clé publique pour fournir une authentification solide, résistante au hameçonnage et plus sécurisée que les mots de passe. AWS prend en charge deux types de clés d'accès : les clés d'accès liées à l'appareil (clés de sécurité) et les clés d'accès synchronisées.
+ **Clés de sécurité** : il s'agit de périphériques physiques YubiKey, tels que a, utilisés comme deuxième facteur d'authentification. Une clé de sécurité unique peut prendre en charge plusieurs comptes utilisateur racine et utilisateurs IAM.
+ **Clés d’accès synchronisées** : elles utilisent des gestionnaires d’informations d’identification provenant de fournisseurs tels que Google, Apple, Microsoft et de services tiers tels que 1Password, Dashlane et Bitwarden comme deuxième facteur.

Vous pouvez utiliser des authentificateurs biométriques intégrés, tels que Touch ID sur Apple MacBooks, pour déverrouiller votre gestionnaire d'identifiants et vous y connecter. AWS Les clés d’accès sont créées avec le fournisseur de votre choix à l’aide de votre empreinte digitale, de votre visage ou du code PIN de votre appareil. Vous pouvez utiliser une clé d’accès d’authentification entre appareils (CDA) provenant d’un appareil, comme un appareil mobile ou une clé de sécurité matérielle, pour vous connecter sur un autre appareil, tel qu’un ordinateur portable. Pour plus d’informations, consultez [Authentification entre appareils](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda) (CDA).

Vous pouvez synchroniser les clés d'accès sur tous vos appareils pour faciliter les connexions et améliorer la convivialité AWS et la récupérabilité. Pour plus d’informations sur l’activation des clés d’accès et des clés de sécurité, consultez [Activation d’une clé d’accès ou d’une clé de sécurité pour l’utilisateur racine (console)](enable-fido-mfa-for-root.md).

La FIDO Alliance tient à jour une liste de tous les [produits certifiés FIDO](https://fidoalliance.org/certification/fido-certified-products/) qui sont compatibles avec les spécifications FIDO.

### Applications d’authentification virtuelle
<a name="virtual-auth-apps-for-iam-users"></a>

Une application d’authentification virtuelle s’exécute sur un téléphone ou un autre dispositif et émule un dispositif physique. Les applications d'authentification virtuelle mettent en œuvre l'algorithme TOTP ([mot de passe unique à durée limitée](https://datatracker.ietf.org/doc/html/rfc6238)) et prennent en charge plusieurs jetons sur un seul dispositif. L’utilisateur doit saisir un code valide à partir du dispositif lorsqu’il y est invité lors de la connexion. Chaque jeton attribué à un utilisateur doit être unique. Un utilisateur ne peut pas saisir un code provenant du jeton d’un autre utilisateur pour s’authentifier.

Nous vous recommandons d'utiliser un MFA résistant au hameçonnage, [comme des clés d'accès ou des clés de sécurité](#passkeys-security-keys-for-iam-users), pour une protection optimale. Si vous n'êtes pas encore en mesure d'utiliser des clés d'accès ou des clés de sécurité, nous vous recommandons d'utiliser un dispositif MFA virtuel comme mesure provisoire en attendant l'approbation de l'achat du matériel ou en attendant l'arrivée de votre matériel. Pour obtenir une liste des applications que vous pouvez utiliser comme dispositifs MFA virtuels, consultez [Authentification multifactorielle (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1).

Pour plus d’informations sur la configuration d’un dispositif MFA virtuel pour un utilisateur IAM, consultez [Attribuez un périphérique MFA virtuel dans le AWS Management Console](id_credentials_mfa_enable_virtual.md).

**Note**  
Les appareils MFA virtuels non assignés sont supprimés lorsque vous ajoutez de nouveaux appareils MFA virtuels via ou pendant AWS Management Console le processus de connexion. Compte AWS Les dispositifs MFA virtuels non attribués sont des dispositifs présents dans votre compte, mais qui ne sont pas utilisés par l’utilisateur racine du compte ou les utilisateurs IAM pour le processus de connexion. Ils sont supprimés afin que de nouveaux dispositifs MFA virtuels puissent être ajoutés à votre compte. Cela vous permet également de réutiliser les noms des appareils.  
Pour afficher les appareils MFA virtuels non assignés dans votre compte, vous pouvez utiliser [list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI la commande [ou](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) l'appel d'API.
Pour désactiver un appareil MFA virtuel, vous pouvez utiliser [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI la commande [ou](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) l'appel d'API. Le dispositif ne sera plus attribué.
[Pour associer un appareil MFA virtuel non attribué à votre utilisateur root ou à Compte AWS vos utilisateurs IAM, vous aurez besoin du code d'authentification généré par l'appareil ainsi que de la commande ou de [enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html)AWS CLI l'appel d'API.](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html)

### Jetons TOTP matériels
<a name="hardware-totp-token-for-iam-users"></a>

Un dispositif matériel qui génère un code numérique à six chiffres basé sur l’[algorithme TOTP (mot de passe unique à durée limitée)](https://datatracker.ietf.org/doc/html/rfc6238). L'utilisateur doit saisir un code valide à partir du dispositif sur une deuxième page web lors de la connexion.

Ces jetons sont utilisés exclusivement avec Comptes AWS. Vous ne pouvez utiliser que des jetons dont les graines uniques sont partagées en toute sécurité avec AWS. Les graines de jetons sont des clés secrètes générées au moment de la production des jetons. Les jetons achetés auprès d’autres sources ne fonctionneront pas avec IAM. Pour garantir la compatibilité, vous devez acheter votre dispositif MFA matériel via l’un des liens suivants : [jeton OTP](https://www.amazon.com/SafeNet-IDProve-Time-based-6-Digit-Services/dp/B002CRN5X8) ou [carte d’affichage OTP](https://www.amazon.com/SafeNet-IDProve-Card-Amazon-Services/dp/B00J4NGUO4).
+ Chaque dispositif MFA attribué à un utilisateur doit être unique. Un utilisateur ne peut pas saisir un code à partir du périphérique d'un autre utilisateur pour s'authentifier. Pour plus d’informations sur les dispositifs MFA matériels pris en charge, consultez [Authentification multifactorielle (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1).
+ Si vous souhaitez utiliser un dispositif MFA physique, nous vous recommandons d’utiliser des clés de sécurité comme alternative aux dispositifs TOTP matériels. Les clés de sécurité ne nécessitent aucune pile, résistent au hameçonnage et prennent en charge plusieurs utilisateurs sur un seul dispositif.

Vous pouvez activer un mot de passe ou une clé de sécurité AWS Management Console uniquement à partir de l' AWS API AWS CLI or, et non de l'API. Avant d’activer une clé de sécurité, vous devez avoir un accès physique au dispositif.

Pour plus d’informations sur la configuration d’un jeton TOTP matériel pour un utilisateur IAM, consultez [Attribuez un jeton TOTP matériel dans le AWS Management Console](id_credentials_mfa_enable_physical.md).

**Note**  
**MFA basée sur les SMS :** AWS fin de la prise en charge de l'activation de l'authentification multifactorielle par SMS (MFA). Nous recommandons aux clients dont les utilisateurs IAM utilisent un dispositif MFA basé sur les SMS de passer à l’une des méthodes alternatives suivantes : [clé d’accès ou clé de sécurité](id_credentials_mfa_enable_fido.md), [dispositif MFA (logiciel) virtuel](id_credentials_mfa_enable_virtual.md) ou [dispositif MFA matériel](id_credentials_mfa_enable_physical.md). Vous pouvez identifier les utilisateurs dans votre compte avec un dispositif MFA SMS affecté. Dans la console IAM, sélectionnez **Users** (Utilisateurs) dans le panneau de navigation, puis recherchez les utilisateurs avec **SMS** mentionné dans la colonne **MFA** de la table.

## Recommandations MFA
<a name="id_credentials_mfa-recommendations"></a>

Pour sécuriser vos AWS identités, suivez ces recommandations relatives à l'authentification MFA. 
+ Nous vous recommandons d'utiliser un MFA résistant au hameçonnage, comme des clés d'accès [et des clés de sécurité, comme](#passkeys-security-keys-for-iam-users) dispositif MFA. Ces authentificateurs basés sur Fido offrent la meilleure protection contre les attaques telles que le phishing.
+ Nous vous recommandons d'activer plusieurs appareils MFA pour les utilisateurs Utilisateur racine d'un compte AWS et IAM de votre. Comptes AWS Cela vous permet de relever la barre de sécurité de votre compte Comptes AWS et de simplifier la gestion de l'accès aux utilisateurs hautement privilégiés, tels que le Utilisateur racine d'un compte AWS.
+ Vous pouvez enregistrer jusqu'à **huit** appareils MFA de n'importe quelle combinaison des [types de MFA actuellement pris en charge auprès de vos Utilisateur racine d'un compte AWS utilisateurs et de ceux](https://aws.amazon.com/iam/features/mfa/) d'IAM. Avec plusieurs appareils MFA, vous n'avez besoin que d'un seul appareil MFA pour vous connecter AWS Management Console ou créer une session via cet utilisateur. AWS CLI Un utilisateur IAM doit s'authentifier avec un dispositif MFA existant pour activer ou désactiver un dispositif MFA supplémentaire.
+ En cas de perte, de vol ou d'inaccessibilité d'un appareil MFA, vous pouvez utiliser l'un des appareils MFA restants pour y accéder Compte AWS sans effectuer la procédure de récupération. Compte AWS En cas de perte ou de vol d'un dispositif MFA, celui-ci doit être dissocié du principal IAM auquel il est associé.
+ L'utilisation de plusieurs appareils MFAs permet à vos employés travaillant sur des sites géographiquement dispersés ou travaillant à distance d'utiliser le MFA basé sur le matériel pour y accéder AWS sans avoir à coordonner l'échange physique d'un seul appareil entre les employés.
+ L'utilisation de dispositifs MFA supplémentaires pour les principaux IAM vous permet d'en utiliser un ou plusieurs MFAs pour un usage quotidien, tout en conservant les dispositifs MFA physiques dans un emplacement physique sécurisé tel qu'un coffre-fort ou un coffre-fort pour la sauvegarde et la redondance.

**Remarques**  
Vous ne pouvez pas transmettre les informations MFA relatives à une clé de sécurité ou à une clé d'accès aux opérations d' AWS STS API pour demander des informations d'identification temporaires. Vous pouvez obtenir des informations d'identification à utiliser avec AWS CLI et AWS SDKs lors de l'utilisation d'une clé de sécurité ou d'un mot de passe en exécutant la `aws login` commande.
Vous ne pouvez pas utiliser de AWS CLI commandes ou AWS d'opérations d'API pour activer les [clés de sécurité FIDO](id_credentials_mfa_enable_fido.md).
Vous ne pouvez pas utiliser le même nom pour plusieurs utilisateurs racine ou dispositif MFA IAM.

## Ressources supplémentaires
<a name="id_credentials_mfa-resources"></a>

Les ressources suivantes peuvent vous aider à en savoir plus au sujet de la MFA.
+ Pour plus d'informations sur l'utilisation de la MFA pour accéder AWS, consultez. [Connexion compatible avec la MFA](console_sign-in-mfa.md)
+  Vous pouvez tirer parti d'IAM Identity Center pour permettre un accès MFA sécurisé à AWS votre portail d'accès, aux applications intégrées IAM Identity Center et au. AWS CLI Pour plus d’informations, consultez [Activation de la MFA dans IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-getting-started.html).

# Attribuez un mot de passe ou une clé de sécurité dans AWS Management Console
<a name="id_credentials_mfa_enable_fido"></a>

Les clés d'accès sont un type de [dispositif d'authentification multifactorielle (MFA)](id_credentials_mfa.md) que vous pouvez utiliser pour protéger vos ressources. AWS AWS prend en charge les clés d'accès synchronisées et les clés d'accès liées à l'appareil, également appelées clés de sécurité. 

Les clés d’accès synchronisées permettent aux utilisateurs d’IAM d’accéder à leurs informations d’identification de connexion FIDO sur bon nombre de leurs appareils, même les plus récents, sans avoir à réinscrire chaque appareil sur chaque compte. Les clés d’accès synchronisées incluent des gestionnaires d’identifiants internes tels que Google, Apple et Microsoft et des gestionnaires d’identifiants tiers tels que 1Password, Dashlane et Bitwarden comme deuxième facteur. Vous pouvez également utiliser la biométrie intégrée à l’appareil (par exemple, TouchID, FaceID) pour déverrouiller le gestionnaire d’informations d’identification de votre choix afin qu’il utilise des clés d’accès. 

D’autre part, les clés d’accès liées à l’appareil sont liées à une clé de sécurité FIDO que vous branchez sur un port USB de votre ordinateur, puis que vous touchez lorsque vous y êtes invité pour terminer le processus de connexion en toute sécurité. Si vous utilisez déjà une clé de sécurité FIDO avec d'autres services et que sa [configuration est AWS prise en charge](id_credentials_mfa_fido_supported_configurations.md) (par exemple, la série YubiKey 5 de Yubico), vous pouvez également l'utiliser avec. AWS Sinon, vous devez acheter une clé de sécurité FIDO si vous souhaitez l'utiliser WebAuthn pour l'entrée AWS MFA. De plus, les clés de sécurité FIDO peuvent prendre en charge plusieurs utilisateurs IAM ou utilisateurs racine sur le même appareil, ce qui améliore leur utilité pour la sécurité des comptes. Pour connaître les spécifications et les informations d'achat de ces deux types d'appareils, consultez [authentification multifacteur](https://aws.amazon.com/iam/details/mfa/).

Vous pouvez enregistrer jusqu'à **huit** appareils MFA de n'importe quelle combinaison des [types de MFA actuellement pris en charge auprès de vos Utilisateur racine d'un compte AWS utilisateurs et de ceux](https://aws.amazon.com/iam/features/mfa/) d'IAM. Avec plusieurs appareils MFA, vous n'avez besoin que d'un seul appareil MFA pour vous connecter AWS Management Console ou créer une session via cet utilisateur. AWS CLI Nous vous recommandons d'enregistrer plusieurs appareils MFA. Par exemple, vous pouvez enregistrer un authentificateur intégré ainsi qu'une clé de sécurité que vous conservez dans un endroit physiquement sûr. Si vous ne pouvez pas à utiliser votre authentificateur intégré, vous pouvez utiliser votre clé de sécurité enregistrée. Pour les applications d'authentification, nous recommandons également d'activer la fonctionnalité de sauvegarde ou de synchronisation dans le cloud dans ces applications afin d'éviter de perdre l'accès à votre compte si vous perdez ou cassez votre appareil avec les applications d'authentification.

**Note**  
Nous vous recommandons de demander à vos utilisateurs humains d'utiliser des informations d'identification temporaires lors de l'accès à AWS. Vos utilisateurs peuvent se fédérer AWS auprès d'un fournisseur d'identité où ils s'authentifient à l'aide de leurs identifiants d'entreprise et de leurs configurations MFA. Pour gérer l'accès aux applications professionnelles AWS et à celles-ci, nous vous recommandons d'utiliser IAM Identity Center. Pour plus d’informations, consultez le [Guide de l’utilisateur IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). 

**Topics**
+ [Autorisations nécessaires](#enable-fido-mfa-for-iam-user-permissions-required)
+ [Activation d’une clé d’accès ou d’une clé de sécurité pour votre propre utilisateur IAM (console)](#enable-fido-mfa-for-own-iam-user)
+ [Activation d’une clé d’accès ou d’une clé de sécurité pour un autre utilisateur IAM (console)](#enable-fido-mfa-for-iam-user)
+ [Remplacement d’une clé d’accès ou d’une clé de sécurité](#replace-fido-mfa)
+ [Configurations prises en charge pour l’utilisation des clés d’accès et des clés de sécurité](id_credentials_mfa_fido_supported_configurations.md)

## Autorisations nécessaires
<a name="enable-fido-mfa-for-iam-user-permissions-required"></a>

Pour gérer une clé d’accès FIDO pour votre propre utilisateur IAM tout en protégeant les actions sensibles liées à MFA, vous devez disposer des autorisations de la politique suivante :

**Note**  
Les valeurs ARN sont des valeurs statiques et n'indiquent pas le protocole qui a été utilisé pour enregistrer l'authentificateur. Nous avons déconseillé U2F, donc toutes les nouvelles implémentations l'utilisent. WebAuthn

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## Activation d’une clé d’accès ou d’une clé de sécurité pour votre propre utilisateur IAM (console)
<a name="enable-fido-mfa-for-own-iam-user"></a>

Vous pouvez activer une clé d'accès ou une clé de sécurité pour votre propre utilisateur IAM AWS Management Console uniquement, et non depuis l'API AWS CLI or AWS . Avant d’activer une clé de sécurité, vous devez avoir un accès physique au dispositif.

**Pour activer une clé d’accès ou une clé de sécurité pour votre propre utilisateur IAM (console)**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Management Console Lien vers les identifiants de sécurité\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Sur la page de l’utilisateur IAM sélectionné, choisissez l’onglet **Informations d’identification de sécurité**.

1. Dans la section **Multi-Factor Authentication (MFA)** (Authentification multifactorielle (MFA)), sélectionnez **Assign MFA device** (Attribuer un dispositif MFA).

1. Sur la page **Nom du dispositif MFA**, saisissez un **Nom du dispositif**, choisissez **Clé d’accès ou Clé de sécurité**, puis choisissez **Suivant**.

1. Dans **Configurer le dispositif**, configurez votre clé d’accès. Créez une clé d’accès avec des données biométriques telles que votre visage ou votre empreinte digitale, avec le code PIN d’un appareil, ou en insérant la clé de sécurité FIDO dans le port USB de votre ordinateur et en la touchant.

1. Suivez les instructions de votre navigateur, puis choisissez **Continuer**.

Vous avez maintenant enregistré votre clé d'accès ou votre clé de sécurité pour une utilisation avec AWS. Pour plus d'informations sur l'utilisation de la MFA avec le AWS Management Console, consultez. [Connexion compatible avec la MFA](console_sign-in-mfa.md) 

## Activation d’une clé d’accès ou d’une clé de sécurité pour un autre utilisateur IAM (console)
<a name="enable-fido-mfa-for-iam-user"></a>

Vous pouvez activer une clé d'accès ou une sécurité pour un autre utilisateur IAM AWS Management Console uniquement, et non depuis l'API AWS CLI or AWS .

**Pour activer une clé d’accès ou une clé de sécurité pour un autre utilisateur IAM (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Sous **Utilisateurs**, choisissez le nom de l’utilisateur pour lequel vous souhaitez activer l’authentification MFA.

1. Sur la page de l’utilisateur IAM sélectionné, choisissez l’onglet **Informations d’identification de sécurité**. 

1. Dans la section **Multi-Factor Authentication (MFA)** (Authentification multifactorielle (MFA)), sélectionnez **Assign MFA device** (Attribuer un dispositif MFA).

1. Sur la page **Nom du dispositif MFA**, saisissez un **Nom du dispositif**, choisissez **Clé d’accès ou Clé de sécurité**, puis choisissez **Suivant**.

1. Dans **Configurer le dispositif**, configurez votre clé d’accès. Créez une clé d’accès avec des données biométriques telles que votre visage ou votre empreinte digitale, avec le code PIN d’un appareil, ou en insérant la clé de sécurité FIDO dans le port USB de votre ordinateur et en la touchant.

1. Suivez les instructions de votre navigateur, puis choisissez **Continuer**.

Vous avez maintenant enregistré une clé d’accès ou une clé de sécurité utilisable avec AWS pour un autre utilisateur IAM. Pour plus d'informations sur l'utilisation de la MFA avec le AWS Management Console, consultez. [Connexion compatible avec la MFA](console_sign-in-mfa.md)

## Remplacement d’une clé d’accès ou d’une clé de sécurité
<a name="replace-fido-mfa"></a>

Vous pouvez attribuer à un utilisateur jusqu'à huit dispositifs MFA de n'importe quelle combinaison des [types MFA actuellement](https://aws.amazon.com/iam/features/mfa/) pris en charge, en même temps que vos Utilisateur racine d'un compte AWS utilisateurs et ceux d'IAM. Si l'utilisateur perd un authentificateur FIDO ou a besoin de le remplacer pour une raison quelconque, vous devez tout d'abord désactiver l'ancien authentificateur FIDO. Vous pouvez alors ajouter un nouveau dispositif MFA pour l'utilisateur.
+ Pour désactiver le dispositif actuellement associé à un autre utilisateur IAM, veuillez consulter la rubrique [Désactivation d’un dispositif MFA](id_credentials_mfa_disable.md).
+ Pour ajouter une nouvelle clé de sécurité FIDO pour un utilisateur IAM, veuillez consulter [Activation d’une clé d’accès ou d’une clé de sécurité pour votre propre utilisateur IAM (console)](#enable-fido-mfa-for-own-iam-user).

Si vous n’avez pas accès à une nouvelle clé d’accès ou une nouvelle clé de sécurité, vous pouvez activer un nouveau dispositif MFA virtuel ou jeton TOTP matériel. Pour plus d'informations, consultez l'un des liens suivants :
+ [Attribuez un périphérique MFA virtuel dans le AWS Management Console](id_credentials_mfa_enable_virtual.md) 
+ [Attribuez un jeton TOTP matériel dans le AWS Management Console](id_credentials_mfa_enable_physical.md) 

# Configurations prises en charge pour l’utilisation des clés d’accès et des clés de sécurité
<a name="id_credentials_mfa_fido_supported_configurations"></a>

Vous pouvez utiliser des clés d'accès FIDO2 liées à l'appareil, également appelées clés de sécurité, comme méthode d'authentification multifactorielle (MFA) avec IAM en utilisant les configurations actuellement prises en charge. Il s'agit notamment FIDO2 des appareils compatibles avec IAM et des navigateurs compatibles FIDO2. Avant d'enregistrer votre FIDO2 appareil, vérifiez que vous utilisez la dernière version du navigateur et du système d'exploitation (OS). Les fonctionnalités peuvent se comporter différemment selon les navigateurs, les authentificateurs et les clients du système d’exploitation. Si l’enregistrement de votre dispositif échoue sur un navigateur, vous pouvez essayer de vous enregistrer avec un autre navigateur. 

FIDO2 est une norme d'authentification ouverte et une extension de FIDO U2F, offrant le même haut niveau de sécurité basé sur la cryptographie à clé publique. FIDO2 comprend la spécification d'authentification Web (WebAuthn API) du W3C et le protocole FIDO Alliance (CTAP), un Client-to-Authenticator protocole de couche application. CTAP permet la communication entre le client ou la plateforme, comme un navigateur ou un système d'exploitation, avec un authentificateur externe. Lorsque vous activez un authentificateur certifié FIDO AWS, la clé de sécurité crée une nouvelle paire de clés à utiliser uniquement. AWS Tout d'abord, saisissez vos informations d'identification. Lorsque vous y êtes invité, insérez la clé de sécurité, qui répond au défi d’authentification émis par AWS. Pour en savoir plus sur la FIDO2 norme, consultez le [FIDO2projet](https://en.wikipedia.org/wiki/FIDO2_Project).

## FIDO2 appareils pris en charge par AWS
<a name="id_credentials_mfa_fido_supported_devices"></a>

IAM prend en charge les dispositifs de FIDO2 sécurité qui se connectent à vos appareils via USB ou NFC. Bluetooth IAM prend également en charge les authentificateurs de plateforme comme TouchID ou FaceID. IAM ne prend pas en charge l’enregistrement de clés d’accès locales pour Windows Hello. Pour créer et utiliser des clés d’accès, les utilisateurs de Windows doivent utiliser l’[authentification entre appareils](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda), qui consiste à utiliser une clé d’accès provenant d’un appareil, comme un appareil mobile, ou une clé de sécurité matérielle pour se connecter sur un autre appareil, tel qu’un ordinateur portable.

**Note**  
AWS nécessite l'accès au port USB physique de votre ordinateur pour vérifier votre FIDO2 appareil. Les clés de sécurité ne fonctionnent pas avec une machine virtuelle, une connexion à distance ou le mode de navigation privée d’un navigateur.

L'Alliance FIDO tient à jour une liste de tous les [FIDO2produits](https://fidoalliance.org/certification/fido-certified-products/) compatibles avec les spécifications FIDO.

## Navigateurs compatibles FIDO2
<a name="id_credentials_mfa_fido_browsers"></a>

La disponibilité des dispositifs de FIDO2 sécurité exécutés dans un navigateur Web dépend de la combinaison du navigateur et du système d'exploitation. Les navigateurs suivants prennent actuellement en charge l’utilisation de clés de sécurité :


****  

| Navigateur Web | macOS 10.15\$1 | Windows 10 | Linux | iOS 14.5\$1 | Android 7\$1 | 
| --- | --- | --- | --- | --- | --- | 
| Chrome | Oui | Oui | Oui | Oui | Non | 
| Safari | Oui | Non | Non | Oui | Non | 
| Edge | Oui | Oui | Non | Oui | Non | 
| Firefox | Oui | Oui | Non | Oui | Non | 

**Note**  
La plupart des versions de Firefox actuellement compatibles FIDO2 ne l'activent pas par défaut. Pour obtenir des instructions sur l'activation du FIDO2 support dans Firefox, consultez[Résolution des problèmes liés aux clés d’accès et aux clés de sécurité FIDO](troubleshoot_mfa-fido.md).  
Firefox sur macOS peut ne pas prendre pleinement en charge les flux de travail d’authentification entre appareils pour les clés d’accès. Il se peut que vous soyez invité à toucher une clé de sécurité au lieu de procéder à une authentification entre appareils. Nous vous recommandons d’utiliser un autre navigateur, tel que Chrome ou Safari, pour vous connecter à l’aide de clés d’accès sur macOS.

Pour plus d'informations sur la prise en charge par navigateur pour un appareil FIDO2 certifié tel que YubiKey, voir [Support du système d'exploitation et du navigateur Web pour FIDO2 U2F](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F).

### Plug-ins de navigateur
<a name="id_credentials_mfa_fido_plugins"></a>

AWS ne prend en charge que les navigateurs compatibles nativement. FIDO2 AWS ne prend pas en charge l'utilisation de plugins pour ajouter FIDO2 le support du navigateur. Certains plugins de navigateur sont incompatibles avec la FIDO2 norme et peuvent entraîner des résultats inattendus avec les clés FIDO2 de sécurité. 

Pour plus d'informations sur la désactivation des plug-ins et pour obtenir d'autres conseils de dépannage, consultez [Je ne peux pas activer ma clé de sécurité FIDO](troubleshoot_mfa-fido.md#troubleshoot_mfa-fido-cant-enable). 

## Certifications des appareils
<a name="id_credentials_mfa_fido_certifications"></a>

Nous ne saisissons et n’attribuons les certifications liées au dispositif, telles que la validation FIPS et le niveau de certification FIDO, que lors de l’enregistrement d’une clé de sécurité. La certification de votre appareil est extraite du [FIDO Alliance Metadata Service (MDS)](https://fidoalliance.org/metadata/). Si le statut ou le niveau de certification de votre clé de sécurité change, celui-ci n’apparaîtra pas automatiquement dans les balises du dispositif. Pour mettre à jour les informations de certification d'un appareil, enregistrez à nouveau l'appareil pour récupérer les informations de certification mises à jour. 

AWS fournit les types de certification suivants sous forme de clés de condition lors de l'enregistrement de l'appareil, obtenus à partir de FIDO MDS : niveaux de certification FIPS-140-2, FIPS-140-3 et FIDO. Vous avez la possibilité de spécifier l'enregistrement d'authentificateurs spécifiques dans leurs politiques IAM, en fonction du type et du niveau de certification que vous préférez. Pour plus d'informations, consultez les politiques ci-dessous.

### Exemples de politiques pour la certification des appareils
<a name="id_credentials_mfa_fido_certifications_policies"></a>

Les cas d'utilisation suivants présentent des exemples de politiques qui vous permettent d'enregistrer des appareils MFA avec des certifications FIPS.

**Topics**
+ [Cas d'utilisation 1 : autoriser uniquement l'enregistrement des appareils certifiés FIPS-140-2 L2](#id_credentials_mfa_fido_certifications_policies_use_case_1)
+ [Cas d'utilisation 2 : autoriser l'enregistrement des appareils certifiés FIPS-140-2 L2 et FIDO L1](#id_credentials_mfa_fido_certifications_policies_use_case_2)
+ [Cas d'utilisation 3 : autoriser l'enregistrement des appareils certifiés FIPS-140-2 L2 ou FIPS-140-3 L2](#id_credentials_mfa_fido_certifications_policies_use_case_3)
+ [Cas d'utilisation n°4 : autoriser l'enregistrement des appareils certifiés FIPS-140-2 L2 et prenant en charge d'autres types de MFA, tels que les authentificateurs virtuels et le TOTP matériel](#id_credentials_mfa_fido_certifications_policies_use_case_4)

#### Cas d'utilisation 1 : autoriser uniquement l'enregistrement des appareils certifiés FIPS-140-2 L2
<a name="id_credentials_mfa_fido_certifications_policies_use_case_1"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### Cas d'utilisation 2 : autoriser l'enregistrement des appareils certifiés FIPS-140-2 L2 et FIDO L1
<a name="id_credentials_mfa_fido_certifications_policies_use_case_2"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2",
                    "iam:FIDO-certification": "L1"
                }
            }
        }
    ]
}
```

------

#### Cas d'utilisation 3 : autoriser l'enregistrement des appareils certifiés FIPS-140-2 L2 ou FIPS-140-3 L2
<a name="id_credentials_mfa_fido_certifications_policies_use_case_3"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-3-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### Cas d'utilisation n°4 : autoriser l'enregistrement des appareils certifiés FIPS-140-2 L2 et prenant en charge d'autres types de MFA, tels que les authentificateurs virtuels et le TOTP matériel
<a name="id_credentials_mfa_fido_certifications_policies_use_case_4"></a>

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Create"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Activate",
          "iam:FIDO-FIPS-140-2-certification": "L2"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "Null": {
          "iam:RegisterSecurityKey": "true"
        }
      }
    }
  ]
}
```

------

## AWS CLI et AWS API
<a name="id_credentials_mfa_fido_cliapi"></a>

AWS prend en charge l'utilisation de clés d'accès et de clés de sécurité uniquement dans le AWS Management Console. L’utilisation des clés d’accès et des clés de sécurité pour l’authentification multifactorielle (MFA) n’est prise en charge ni dans l’[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/), ni dans l’[API AWS](https://aws.amazon.com/tools/), ni pour l’accès aux [opérations d’API protégées par l’authentification multifactorielle (MFA)](id_credentials_mfa_configure-api-require.md).

## Ressources supplémentaires
<a name="id_credentials_mfa_fido_additional_resources"></a>
+ Pour plus d'informations sur l'utilisation des clés d'accès et des clés de sécurité dans AWS, consultez[Attribuez un mot de passe ou une clé de sécurité dans AWS Management Console](id_credentials_mfa_enable_fido.md).
+ Pour obtenir de l'aide sur la résolution des problèmes liés aux clés d'accès et aux clés de sécurité AWS, consultez[Résolution des problèmes liés aux clés d’accès et aux clés de sécurité FIDO](troubleshoot_mfa-fido.md).
+ Pour des informations générales sur le secteur sur le FIDO2 support, voir [FIDO2 Projet](https://en.wikipedia.org/wiki/FIDO2_Project). 

# Attribuez un périphérique MFA virtuel dans le AWS Management Console
<a name="id_credentials_mfa_enable_virtual"></a>

**Important**  
AWS vous recommande d'utiliser une clé d'accès ou une clé de sécurité pour le MFA, dans la mesure du AWS possible. Pour de plus amples informations, veuillez consulter [Attribuez un mot de passe ou une clé de sécurité dans AWS Management Console](id_credentials_mfa_enable_fido.md).

Vous pouvez utiliser un téléphone ou un autre appareil comme appareil d'authentification multifacteur (MFA) virtuel. Pour ce faire, installez une application mobile conforme à [RFC 6238, un algorithme TOTP (mot de passe unique basé sur le temps) basé sur des normes](https://datatracker.ietf.org/doc/html/rfc6238). Ces applications génèrent un code d'authentification à six chiffres. Étant donné que les authentificateurs peuvent fonctionner sur des appareils mobiles non sécurisés et que les codes peuvent être partagés avec des parties non autorisées, le MFA basé sur le TOTP n'offre pas le même niveau de sécurité que les options résistantes au hameçonnage telles que les clés de sécurité et les clés d'accès. [FIDO2](https://en.wikipedia.org/wiki/FIDO_Alliance#FIDO2) Nous vous recommandons d'utiliser des clés d'accès ou des clés de sécurité pour le MFA afin de vous protéger au mieux contre les attaques telles que le phishing.

Si vous n'êtes pas encore en mesure d'utiliser des clés d'accès ou des clés de sécurité, nous vous recommandons d'utiliser un dispositif MFA virtuel à titre de mesure provisoire en attendant l'approbation de tout achat de matériel ou l'arrivée de votre matériel.

La plupart des applications MFA virtuelles prennent en charge la création de plusieurs appareils virtuels, ce qui vous permet d'utiliser la même application pour plusieurs Comptes AWS ou plusieurs utilisateurs. Vous pouvez enregistrer jusqu'à **huit** appareils MFA de n'importe quelle combinaison de [types MFA](https://aws.amazon.com/iam/features/mfa/) auprès de vos Utilisateur racine d'un compte AWS utilisateurs et de ceux d'IAM. Vous n'avez besoin que d'un seul appareil MFA pour vous connecter AWS Management Console ou créer une session via le. AWS CLI Nous vous recommandons d'enregistrer plusieurs appareils MFA. Pour les applications d’authentification, nous recommandons également d’activer la fonctionnalité de sauvegarde ou de synchronisation dans le cloud afin d’éviter de perdre l’accès à votre compte en cas de perte ou de casse de votre dispositif.

AWS nécessite une application MFA virtuelle qui produit un OTP à six chiffres. Pour obtenir la liste des applications MFA virtuelles que vous pouvez utiliser, consultez [authentification multifacteur](https://aws.amazon.com/iam/features/mfa/?audit=2019q1). 

**Topics**
+ [Autorisations nécessaires](#mfa_enable_virtual_permissions-required)
+ [Activation d'un dispositif MFA virtuel pour un utilisateur IAM (Console)](#enable-virt-mfa-for-iam-user)
+ [Remplacer un périphérique MFA virtuel](#replace-virt-mfa)

## Autorisations nécessaires
<a name="mfa_enable_virtual_permissions-required"></a>

Pour gérer des dispositifs MFA virtuels pour votre utilisateur IAM, vous devez disposer des autorisations de la politique suivante : [AWS : autorise les utilisateurs IAM authentifiés par MFA à gérer leur dispositif MFA sur la page Informations d’identification de sécurité](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md).

## Activation d'un dispositif MFA virtuel pour un utilisateur IAM (Console)
<a name="enable-virt-mfa-for-iam-user"></a>

Vous pouvez utiliser IAM AWS Management Console pour activer et gérer un appareil MFA virtuel pour un utilisateur IAM de votre compte. Vous pouvez attacher des balises à vos ressources IAM, y compris les appareils MFA virtuels, pour les identifier, les organiser et contrôler l'accès. Vous pouvez étiqueter les appareils MFA virtuels uniquement lorsque vous utilisez l'API AWS CLI or AWS . Pour activer et gérer un appareil MFA à l'aide de l' AWS API AWS CLI or, consultez. [Attribuez des appareils MFA dans l'API or AWS CLI AWS](id_credentials_mfa_enable_cliapi.md) Pour plus d'informations sur le balisage des ressources IAM, consultez [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 

**Note**  
Pour configurer l'authentification MFA, vous devez avoir accès physique au matériel sur lequel le dispositif MFA virtuel de l'utilisateur est hébergé. Par exemple, vous pouvez configurer le MFA pour un utilisateur qui utilisera un dispositif MFA virtuel s'exécutant sur un smartphone. Dans ce cas, vous devez avoir le smartphone à proximité afin de finaliser l'assistant. De ce fait, vous pouvez préférer laisser les utilisateurs configurer et gérer leurs propres dispositifs MFA virtuels. Dans ce cas, vous devez accorder aux utilisateurs l'autorisation d'exécuter les actions IAM nécessaires. Pour en savoir plus sur la politique IAM qui accorde ces autorisations et pour accéder à un exemple, veuillez consulter la rubrique [Didacticiel IAM : permettre aux utilisateurs de gérer leurs informations d'identification et leurs paramètres MFA](tutorial_users-self-manage-mfa-and-creds.md) et la politique d'exemple [AWS : autorise les utilisateurs IAM authentifiés par MFA à gérer leur dispositif MFA sur la page Informations d’identification de sécurité](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md). 

**Pour activer un dispositif MFA virtuel pour un utilisateur IAM (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Dans la liste des **Users** (Utilisateurs), choisissez le nom d'utilisateur IAM.

1. Choisissez l'onglet **Informations d'identification de sécurité**. Dans la section **Multi-Factor Authentication (MFA)** (Authentification multifactorielle (MFA)), sélectionnez **Assign MFA device** (Attribuer un dispositif MFA).

1. Dans l'assistant, saisissez un nom dans le champ **Nom du dispositif**, sélectionnez **Application Authenticator**, puis cliquez sur **Suivant**.

   IAM génère et affiche les informations de configuration du dispositif MFA virtuel, notamment un graphique de code QR. Le graphique est une représentation de la clé de configuration secrète que l'on peut saisir manuellement sur des périphériques qui ne prennent pas en charge les codes QR.

1. Ouvrez votre application MFA virtuelle. Pour obtenir une liste des applications que vous pouvez utiliser pour héberger des dispositifs MFA virtuels, consultez [authentification multifacteur](https://aws.amazon.com/iam/details/mfa/). 

   Si l'application MFA virtuelle prend en charge plusieurs comptes ou plusieurs dispositifs MFA virtuels, choisissez l'option permettant de créer un compte ou un dispositif MFA virtuel.

1. Déterminez si l'application MFA prend en charge les codes QR, puis effectuez l'une des actions suivantes :
   + Dans l'assistant, choisissez **Show QR code (Afficher le code QR)**, puis utiliser l'application pour analyser le code QR. Il peut s’agir d’une icône de caméra ou d’une option **Scanner le code** qui utilise la caméra de l’appareil pour analyser le code.
   + Dans l'assistant, sélectionnez **Show secret key** (Afficher la clé secrète), puis saisissez la clé secrète dans votre application MFA.

   Une fois que vous avez terminé, le dispositif MFA virtuel commence à générer des mots de passe uniques. 

1. Sur la page **Configurer l'appareil**, accédez à la zone **Code MFA 1** et saisissez le mot de passe à usage unique affiché sur le dispositif MFA virtuel. Attendez jusqu'à 30 secondes pour que le dispositif génère un nouveau mot de passe unique. Saisissez ensuite le second mot de passe unique dans la zone **MFA Code 2 (Code MFA 2)**. Choisissez **Add MFA** (Ajouter un dispositif MFA). 
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, le dispositif MFA s'associe avec succès à l'utilisateur mais est désynchronisé. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez [resynchroniser le dispositif](id_credentials_mfa_sync.md).

Le périphérique MFA virtuel est désormais prêt à être utilisé avec. AWS Pour plus d'informations sur l'utilisation de la MFA avec le AWS Management Console, consultez. [Connexion compatible avec la MFA](console_sign-in-mfa.md)

**Note**  
Les appareils MFA virtuels non assignés dans Compte AWS votre compte sont supprimés lorsque vous ajoutez de nouveaux appareils MFA virtuels, soit par le biais AWS Management Console du processus de connexion, soit pendant celui-ci. Les dispositifs MFA virtuels non attribués sont des dispositifs présents dans votre compte, mais qui ne sont pas utilisés par l’utilisateur racine du compte ou les utilisateurs IAM pour le processus de connexion. Ils sont supprimés afin que de nouveaux dispositifs MFA virtuels puissent être ajoutés à votre compte. Cela vous permet également de réutiliser les noms des appareils.  
Pour afficher les appareils MFA virtuels non assignés dans votre compte, vous pouvez utiliser [list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI la commande [ou](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) l'appel d'API.
Pour désactiver un appareil MFA virtuel, vous pouvez utiliser [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI la commande [ou](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) l'appel d'API. Le dispositif ne sera plus attribué.
[Pour associer un appareil MFA virtuel non attribué à votre utilisateur root ou à Compte AWS vos utilisateurs IAM, vous aurez besoin du code d'authentification généré par l'appareil ainsi que de la commande ou de [enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html)AWS CLI l'appel d'API.](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html)

## Remplacer un périphérique MFA virtuel
<a name="replace-virt-mfa"></a>

Vos utilisateurs Utilisateur racine d'un compte AWS et ceux d'IAM peuvent enregistrer jusqu'à **huit** appareils MFA de n'importe quelle combinaison de types de MFA. Si l’utilisateur perd un dispositif ou a besoin de le remplacer pour une raison quelconque, vous devez désactiver l’ancien dispositif. Vous pouvez alors ajouter le nouveau périphérique pour l'utilisateur.
+ Pour désactiver le dispositif actuellement associé à un autre utilisateur IAM, consultez [Désactivation d’un dispositif MFA](id_credentials_mfa_disable.md).
+ Pour ajouter un dispositif MFA virtuel de remplacement pour un autre utilisateur IAM, suivez les étapes de la procédure [Activation d'un dispositif MFA virtuel pour un utilisateur IAM (Console)](#enable-virt-mfa-for-iam-user) ci-dessus.
+ Pour ajouter un périphérique MFA virtuel de remplacement pour le Utilisateur racine d'un compte AWS, suivez les étapes de la procédure. [Activation d’un dispositif MFA virtuel pour l’utilisateur racine (console)](enable-virt-mfa-for-root.md)

# Attribuez un jeton TOTP matériel dans le AWS Management Console
<a name="id_credentials_mfa_enable_physical"></a>

**Important**  
AWS vous recommande d'utiliser une clé d'accès ou une clé de sécurité pour le MFA, dans la mesure du AWS possible. Pour de plus amples informations, veuillez consulter [Attribuez un mot de passe ou une clé de sécurité dans AWS Management Console](id_credentials_mfa_enable_fido.md).

Un jeton TOTP matériel génère un code numérique à six chiffres basé sur un algorithme TOTP (mot de passe unique à durée limitée). L'utilisateur doit saisir un code valide à partir du périphérique lorsqu'il y est invité lors de la connexion. Chaque dispositif MFA attribué à un utilisateur doit être unique ; un utilisateur ne peut pas saisir un code à partir du périphérique d'un autre utilisateur pour s'authentifier. Les dispositifs MFA ne peuvent pas être partagés entre plusieurs comptes ou plusieurs utilisateurs.

Les jetons TOTP matériels et les [clés de sécurité FIDO](id_credentials_mfa_enable_fido.md) sont des dispositifs physiques que vous achetez. Les appareils MFA matériels génèrent des codes TOTP pour l'authentification lorsque vous vous connectez à. AWS Ils utilisent des batteries, qui peuvent avoir besoin d'être remplacées et resynchronisées au fil du temps. AWS Les clés de sécurité FIDO, qui utilisent la cryptographie à clé publique, ne nécessitent pas de piles et offrent un processus d’authentification sans faille. Nous vous recommandons d’utiliser les clés de sécurité FIDO pour leur résistance au hameçonnage, ce qui constitue une alternative plus sûre aux appareils TOTP. De plus, les clés de sécurité FIDO peuvent prendre en charge plusieurs utilisateurs IAM ou utilisateurs racine sur le même appareil, ce qui améliore leur utilité pour la sécurité des comptes. Pour connaître les spécifications et les informations d'achat de ces deux types d'appareils, consultez [authentification multifacteur](https://aws.amazon.com/iam/details/mfa/).



Vous pouvez activer un jeton TOTP matériel pour un utilisateur IAM à partir de la AWS Management Console ligne de commande ou de l'API IAM. Pour activer un dispositif MFA pour votre Utilisateur racine d'un compte AWS, consultez. [Activation d'un jeton TOTP matériel pour l'utilisateur root de l' (console)](enable-hw-mfa-for-root.md)

Vous pouvez enregistrer jusqu'à **huit** appareils MFA de n'importe quelle combinaison des [types de MFA actuellement pris en charge auprès de vos Utilisateur racine d'un compte AWS utilisateurs et de ceux](https://aws.amazon.com/iam/features/mfa/) d'IAM. Avec plusieurs appareils MFA, vous n'avez besoin que d'un seul appareil MFA pour vous connecter AWS Management Console ou créer une session via cet utilisateur. AWS CLI 

**Important**  
Nous vous recommandons d'activer plusieurs dispositifs MFA pour permettre à vos utilisateurs d'accéder en permanence à votre compte en cas de perte ou d'inaccessibilité d'un dispositif MFA.

**Note**  
Si vous souhaitez activer le dispositif dans la ligne de commande, utilisez [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html) . Pour activer le dispositif MFA avec l'API IAM, utilisez l'opération [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html). 

**Topics**
+ [Autorisations nécessaires](#enable-hw-mfa-for-iam-user-permissions-required)
+ [Activation d'un jeton TOTP matériel pour votre propre utilisateur IAM (console)](#enable-hw-mfa-for-own-iam-user)
+ [Activation d'un jeton TOTP matériel pour un autre utilisateur IAM (console)](#enable-hw-mfa-for-iam-user)
+ [Remplacer un périphérique MFA physique](#replace-phys-mfa)

## Autorisations nécessaires
<a name="enable-hw-mfa-for-iam-user-permissions-required"></a>

Pour gérer un jeton TOTP matériel pour votre propre utilisateur IAM tout en protégeant les actions sensibles liées à MFA, vous devez disposer des autorisations de la politique suivante :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## Activation d'un jeton TOTP matériel pour votre propre utilisateur IAM (console)
<a name="enable-hw-mfa-for-own-iam-user"></a>

 Vous pouvez activer votre propre jeton TOTP matériel à partir de la AWS Management Console.

**Note**  
Avant d'activer un jeton TOTP matériel, vous devez y avoir accès physiquement.

**Pour activer un jeton TOTP matériel pour votre propre utilisateur IAM (console)**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Management Console Lien vers les identifiants de sécurité\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans l'onglet **Informations d'identification AWS IAM**, sous la section **Authentification multifactorielle (MFA)**, sélectionnez **Attribuer le dispositif MFA**.

1. Dans l'assistant, tapez le **nom du dispositif**, choisissez **Hardware TOTP token** (Jeton TOTP matériel), puis **Next** (Suivant).

1. Saisissez le numéro de série du périphérique. Le numéro de série se situe généralement l'arrière du périphérique.

1. Dans la zone **MFA code 1**, saisissez le code à six chiffres qui s'affichent sur le dispositif MFA. Vous devrez peut-être appuyer sur le bouton situé à l'avant du périphérique pour afficher le numéro.  
![\[Tableau de bord IAM, dispositif MFA\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/MFADevice.png)

1. Attendez 30 secondes que le périphérique actualise le code, puis saisissez la nouvelle série de six chiffres dans la zone **MFA code 2**. Vous devrez peut-être appuyer à nouveau sur le bouton situé à l'avant du périphérique pour afficher le second numéro.

1. Choisissez **Add MFA** (Ajouter un dispositif MFA).
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes d'authentification. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, l'dispositif MFA s'associe avec succès à l'utilisateur mais se désynchronise. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez [resynchroniser le dispositif](id_credentials_mfa_sync.md).

L'appareil est prêt à être utilisé avec AWS. Pour plus d'informations sur l'utilisation de l'authentification MFA avec l'interface AWS Management Console, veuillez consulter [Connexion compatible avec la MFA](console_sign-in-mfa.md).

## Activation d'un jeton TOTP matériel pour un autre utilisateur IAM (console)
<a name="enable-hw-mfa-for-iam-user"></a>

 Vous pouvez activer un jeton TOTP matériel pour un autre utilisateur IAM à partir de la AWS Management Console.

**Pour activer un jeton TOTP matériel pour un autre utilisateur IAM (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Choisissez le nom de l'utilisateur pour lequel vous souhaitez activer l'authentification MFA.

1. Choisissez l'onglet **Informations d'identification de sécurité**. Dans la section **Multi-Factor Authentication (MFA)** (Authentification multifactorielle (MFA)), sélectionnez **Assign MFA device** (Attribuer un dispositif MFA).

1. Dans l'assistant, tapez le **nom du dispositif**, choisissez **Hardware TOTP token** (Jeton TOTP matériel), puis **Next** (Suivant).

1. Saisissez le numéro de série du périphérique. Le numéro de série se situe généralement l'arrière du périphérique.

1. Dans la zone **MFA code 1**, saisissez le code à six chiffres qui s'affichent sur le dispositif MFA. Vous devrez peut-être appuyer sur le bouton situé à l'avant du périphérique pour afficher le numéro.  
![\[Tableau de bord IAM, dispositif MFA\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/MFADevice.png)

1. Attendez 30 secondes que le périphérique actualise le code, puis saisissez la nouvelle série de six chiffres dans la zone **MFA code 2**. Vous devrez peut-être appuyer à nouveau sur le bouton situé à l'avant du périphérique pour afficher le second numéro.

1. Choisissez **Add MFA** (Ajouter un dispositif MFA).
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes d'authentification. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, l'dispositif MFA s'associe avec succès à l'utilisateur mais se désynchronise. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez [resynchroniser le dispositif](id_credentials_mfa_sync.md).

L'appareil est prêt à être utilisé avec AWS. Pour plus d'informations sur l'utilisation de l'authentification MFA avec l'interface AWS Management Console, veuillez consulter [Connexion compatible avec la MFA](console_sign-in-mfa.md).

## Remplacer un périphérique MFA physique
<a name="replace-phys-mfa"></a>

Vous pouvez attribuer à un utilisateur jusqu'à huit dispositifs MFA de n'importe quelle combinaison des [types MFA actuellement](https://aws.amazon.com/iam/features/mfa/) pris en charge, en même temps que vos Utilisateur racine d'un compte AWS utilisateurs et ceux d'IAM. Si l'utilisateur perd un périphérique ou a besoin de le remplacer pour une raison quelconque, vous devez désactiver l'ancien périphérique. Vous pouvez alors ajouter le nouveau périphérique pour l'utilisateur.
+ Pour désactiver le périphérique actuellement associé à un utilisateur, consultez la page [Désactivation d’un dispositif MFA](id_credentials_mfa_disable.md).
+ Pour ajouter un jeton TOTP matériel de remplacement pour un utilisateur IAM, suivez les étapes de la procédure [Activation d'un jeton TOTP matériel pour un autre utilisateur IAM (console)](#enable-hw-mfa-for-iam-user) plus haut dans cette rubrique.
+ Pour ajouter un jeton TOTP matériel de remplacement pour le Utilisateur racine d'un compte AWS, suivez les étapes décrites dans la procédure décrite [Activation d'un jeton TOTP matériel pour l'utilisateur root de l' (console)](enable-hw-mfa-for-root.md) plus haut dans cette rubrique.

# Attribuez des appareils MFA dans l'API or AWS CLI AWS
<a name="id_credentials_mfa_enable_cliapi"></a>

Vous pouvez utiliser des AWS CLI commandes ou des opérations d' AWS API pour activer un dispositif MFA virtuel pour un utilisateur IAM. Vous ne pouvez pas activer un périphérique MFA Utilisateur racine d'un compte AWS avec l' AWS API AWS CLI, Tools for Windows PowerShell ou tout autre outil de ligne de commande. Toutefois, vous pouvez utiliser le AWS Management Console pour activer un périphérique MFA pour l'utilisateur root. 

Lorsque vous activez un dispositif MFA à partir du AWS Management Console, la console exécute plusieurs étapes pour vous. Si vous créez plutôt un appareil virtuel à l' AWS CLI aide des outils pour Windows PowerShell ou de AWS l'API, vous devez effectuer les étapes manuellement et dans le bon ordre. Par exemple, pour créer un dispositif MFA virtuel, vous devez créer l'objet IAM et extraire le code sous forme de chaîne ou de graphique de code QR. Ensuite, vous devez synchroniser le périphérique et l'associer à un utilisateur IAM. Consultez la section **Exemples** de [New- IAMVirtual MFADevice](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=New-IAMVirtualMFADevice.html&tocid=New-IAMVirtualMFADevice) pour plus de détails. Dans le cas d'un périphérique physique, vous ignorez l'étape de création et passez directement à la synchronisation du périphérique et l'association à un utilisateur. 

Vous pouvez attacher des balises à vos ressources IAM, y compris les appareils MFA virtuels, pour les identifier, les organiser et contrôler l'accès. Vous pouvez étiqueter les appareils MFA virtuels uniquement lorsque vous utilisez l'API AWS CLI or AWS .

Un utilisateur IAM utilisant le kit SDK ou l'interface de ligne de commande peut activer un dispositif MFA supplémentaire en appelant [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) ou désactiver un dispositif MFA existant en appelant [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html). Pour y parvenir, il doit d'abord appeler [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) et soumettre des codes MFA avec un dispositif MFA existant. Cet appel renvoie des informations d'identification de sécurité temporaires qui peuvent ensuite être utilisées pour signer des opérations d'API nécessitant une authentification MFA. Pour un exemple de demande et de réponse, consultez [`GetSessionToken` : informations d'identification temporaires pour les utilisateurs qui se trouvent dans des environnements non fiables](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken). 

**Pour créer l'entité de périphérique virtuel dans IAM pour représenter un dispositif MFA virtuel**  
Ces commandes fournissent un ARN pour le périphérique qui est utilisé à la place du numéro de série dans un grand nombre des commandes suivantes.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html) 

**Pour activer un périphérique MFA à utiliser avec AWS**  
Ces commandes synchronisent l'appareil avec un utilisateur AWS et l'associent à celui-ci. S'il s'agit d'un périphérique virtuel, utilisez son ARN en tant que numéro de série.

**Important**  
Envoyez votre demande immédiatement après avoir généré les codes d'authentification. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, l'dispositif MFA s'associe avec succès à l'utilisateur mais se désynchronise. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez resynchroniser l'appareil à l'aide des commandes décrites ci-dessous.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 

**Pour désactiver un périphérique**  
Utilisez ces commandes pour dissocier le périphérique de l'utilisateur et le désactiver. S'il s'agit d'un périphérique virtuel, utilisez son ARN en tant que numéro de série. Vous devez également supprimer l'entité de périphérique virtuel séparément. 
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

**Pour afficher la liste des entités de dispositifs MFA virtuels**  
Utilisez ces commandes pour afficher la liste des entités de dispositifs MFA virtuels.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) 

**Pour baliser un appareil MFA virtuel**  
Utilisez ces commandes pour baliser un appareil MFA virtuel.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html) 

**Pour répertorier les balises d'un appareil MFA virtuel**  
Utilisez ces commandes pour répertorier les balises attachées à un appareil MFA virtuel.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html) 

**Pour supprimer la balise d'un appareil MFA virtuel**  
Utilisez ces commandes pour supprimer les balises attachées à un appareil MFA virtuel.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html) 

**Pour resynchroniser un dispositif MFA**  
Utilisez ces commandes si le périphérique génère des codes qui ne sont pas acceptés par AWS. S'il s'agit d'un périphérique virtuel, utilisez son ARN en tant que numéro de série.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) 

**Pour supprimer une entité de dispositif MFA virtuel dans IAM**  
Après avoir dissocié le périphérique de l'utilisateur, vous pouvez supprimer l'entité de périphérique.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html) 
+ AWS API : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html) 

**Pour récupérer un dispositif MFA virtuel qui est perdu ou ne fonctionne pas**  
Parfois, l'appareil d'un utilisateur qui héberge l'application MFA virtuelle est perdu, remplacé ou ne fonctionne pas. Dans ce cas, l'utilisateur ne peut pas le récupérer par lui-même. L'utilisateur doit contacter un administrateur pour désactiver le dispositif. Pour de plus amples informations, veuillez consulter [Restauration d’une identité protégée par MFA dans IAM](id_credentials_mfa_lost-or-broken.md).

# Vérification du statut MFA
<a name="id_credentials_mfa_checking-status"></a>

Utilisez la console IAM pour vérifier si un périphérique MFA valide est activé pour un utilisateur Utilisateur racine d'un compte AWS ou un utilisateur IAM.

**Pour vérifier le statut de l'authentification MFA d'un utilisateur racine**

1. Connectez-vous à l' AWS Management Console aide de vos informations d'identification d'utilisateur root, puis ouvrez la console IAM à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) l'adresse. 

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).

1. Sous **Multi-Factor Authentication (MFA)**, vérifiez si la MFA est activée ou désactivée. Si la MFA n'a pas été activée, un symbole d'alerte (![\[Alert icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-alert-icon.console.png)) est affiché. 

Si vous souhaitez activer l'authentification MFA pour le compte, consultez l'une des sections suivantes :
+ [Activation d’un dispositif MFA virtuel pour l’utilisateur racine (console)](enable-virt-mfa-for-root.md)
+ [Activation d’une clé d’accès ou d’une clé de sécurité pour l’utilisateur racine (console)](enable-fido-mfa-for-root.md)
+ [Activation d'un jeton TOTP matériel pour l'utilisateur root de l' (console)](enable-hw-mfa-for-root.md)

**Pour vérifier le statut de l'authentification MFA d'utilisateurs IAM**

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Au besoin, ajoutez la colonne **MFA** à la table des utilisateurs en procédant comme suit :

   1. Au-dessus de la table à l'extrême droite, choisissez l'icône des paramètres (![\[Settings icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. Dans **Manage Columns (Gérer les colonnes)**, sélectionnez **MFA**.

   1. (Facultatif) Décochez la case des en-têtes de colonne que vous ne souhaitez pas voir apparaître dans le tableau des utilisateurs.

   1. Choisissez **Fermer** pour revenir à la liste des utilisateurs.

1. La colonne **MFA** vous fournit des informations sur le dispositif MFA qui est activé. Si aucun dispositif MFA n'est actif pour l'utilisateur, la console affiche **None** (Aucun). Si l'utilisateur dispose d'un dispositif MFA activé, la colonne **MFA** affiche le type de dispositif activé avec la valeur de **Virtuel**, **Clé de sécurité**, **Matériel** ou **SMS**.
**Note**  
AWS fin du support pour l'activation de l'authentification multifactorielle par SMS (MFA). Nous recommandons aux clients dont les utilisateurs IAM utilisent un dispositif MFA basé sur les SMS de passer à l'une des méthodes alternatives suivantes : [dispositif MFA virtuel (logiciel)](id_credentials_mfa_enable_virtual.md), [clé de sécurité FIDO](id_credentials_mfa_enable_fido.md) ou [dispositif MFA matériel](id_credentials_mfa_enable_physical.md). Vous pouvez identifier les utilisateurs dans votre compte avec un dispositif MFA SMS affecté. Pour ce faire, accédez à la console IAM, choisissez **Utilisateurs** dans le panneau de navigation, puis recherchez les utilisateurs avec **SMS** mentionné dans la colonne **MFA** de la table.

1. Pour afficher des informations supplémentaires sur le dispositif MFA pour un utilisateur, choisissez le nom de l'utilisateur dont vous souhaitez vérifier l'état MFA. Choisissez ensuite l'onglet **Informations d'identification de sécurité**. 

1. Si aucun dispositif MFA n'est actif pour l'utilisateur, la console affiche **Aucun dispositif MFA. Attribuez un dispositif MFA pour améliorer la sécurité de votre AWS environnement** dans la section Authentification à **facteurs multiples (MFA**). Si les dispositifs MFA de l'utilisateur sont activés, la section **Authentification multifactorielle (MFA)** affiche des informations détaillées sur les dispositifs :
   + Nom du dispositif
   + Type du dispositif
   + L'identifiant du périphérique, tel que le numéro de série d'un périphérique physique ou l'ARN AWS d'un périphérique virtuel
   + Quand le dispositif a été créé

Pour supprimer ou resynchroniser un dispositif, cliquez sur le bouton radio à côté du dispositif, puis choisissez **Remove** (Supprimer) ou **Resync** (Resynchroniser).

Pour plus d'informations sur l'activation de l'authentification MFA, consultez la documentation suivante : 
+ [Attribuez un périphérique MFA virtuel dans le AWS Management Console](id_credentials_mfa_enable_virtual.md)
+ [Attribuez un mot de passe ou une clé de sécurité dans AWS Management Console](id_credentials_mfa_enable_fido.md)
+ [Attribuez un jeton TOTP matériel dans le AWS Management Console](id_credentials_mfa_enable_physical.md)

# Resynchronisation des dispositifs MFA virtuels et matériels
<a name="id_credentials_mfa_sync"></a>

Vous pouvez l'utiliser AWS pour resynchroniser vos appareils d'authentification multifactorielle (MFA) virtuels et matériels. Si votre dispositif n'est pas synchronisé lorsque vous essayez de l'utiliser, la tentative de connexion échoue et IAM vous invite à resynchroniser le dispositif.

**Note**  
Les clés de sécurité FIDO ne se désynchronisent pas. Si une clé de sécurité FIDO est perdue ou endommagée, vous pouvez la désactiver. Pour plus d'informations sur la désactivation de tout type de dispositif MFA, consultez [Pour désactiver un dispositif MFA pour un autre utilisateur IAM (console)](id_credentials_mfa_disable.md#deactivate-mfa-for-user).

En tant qu' AWS administrateur, vous pouvez resynchroniser les appareils MFA virtuels et matériels de vos utilisateurs IAM s'ils ne sont pas synchronisés.

Si votre appareil Utilisateur racine d'un compte AWS MFA ne fonctionne pas, vous pouvez le resynchroniser à l'aide de la console IAM avec ou sans terminer le processus de connexion. Si vous ne parvenez pas à resynchroniser votre appareil, vous devrez peut-être le désassocier et le réassocier. Pour en savoir plus à ce sujet, veuillez consulter les rubriques [Désactivation d’un dispositif MFA](id_credentials_mfa_disable.md) et [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md).

**Topics**
+ [Autorisations nécessaires](#id_credentials_mfa_sync_console-permissions-required)
+ [Resynchronisation des dispositifs MFA matériels et virtuels (console IAM)](#id_credentials_mfa_sync_console)
+ [Resynchronisation de dispositifs MFA virtuels et matériels (AWS CLI)](#id_credentials_mfa_sync_cli)
+ [Resynchronisation des périphériques MFA virtuels et matériels (API)AWS](#id_credentials_mfa_sync_api)

## Autorisations nécessaires
<a name="id_credentials_mfa_sync_console-permissions-required"></a>

Pour resynchroniser des dispositifs MFA virtuels ou matériels pour votre propre utilisateur IAM, vous devez disposer des autorisations de la politique suivante. Cette politique ne vous permet pas de créer ou de désactiver un dispositif.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowListActions",
            "Effect": "Allow",
            "Action": [
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowUserToViewAndManageTheirOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "BlockAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## Resynchronisation des dispositifs MFA matériels et virtuels (console IAM)
<a name="id_credentials_mfa_sync_console"></a>

Vous pouvez utiliser la console IAM pour resynchroniser les dispositifs virtuels du matériel MFA.

**Pour resynchroniser un dispositif MFA matériel ou virtuel pour votre propre utilisateur IAM (console)**

1. Utilisez votre AWS identifiant ou alias de compte, votre nom d'utilisateur IAM et votre mot de passe pour vous connecter à la console [IAM](https://console.aws.amazon.com/iam).
**Note**  
Pour votre commodité, la page de AWS connexion utilise un cookie de navigateur pour mémoriser votre nom d'utilisateur IAM et les informations de votre compte. Si vous vous êtes déjà connecté en tant qu'utilisateur différent, sélectionnez **Sign in to a different account** (Se connecter à un compte différent) en bas de la page pour revenir à la page de connexion principale. À partir de là, vous pouvez saisir votre identifiant de AWS compte ou votre alias de compte pour être redirigé vers la page de connexion utilisateur IAM de votre compte.

   Pour obtenir votre Compte AWS identifiant, contactez votre administrateur.

1. Dans la barre de navigation, en haut à droite, choisissez votre nom d'utilisateur, puis **Security credentials** (Informations d'identification de sécurité).   
![\[AWS Lien vers les identifiants de sécurité de la console de gestion\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. Dans l'onglet **Informations d'identification AWS IAM**, sous la section **Authentification multifactorielle (MFA)**, cliquez sur le bouton radio situé en regard du dispositif MFA et sélectionnez **Resynchroniser**.

1. Entrez les deux prochains codes générés séquentiellement à partir du périphérique dans les champs **MFA code 1** et **MFA code 2**. Puis choisissez **Resync** (Resynchroniser).
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, cette dernière semble fonctionner mais l'appareil reste désynchronisé. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période.

**Pour resynchroniser un dispositif MFA matériel ou virtuel pour un autre utilisateur IAM (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Utilisateurs**, puis sélectionnez le nom de l'utilisateur dont le dispositif MFA doit être resynchronisé.

1. Choisissez l’onglet **Informations d’identification de sécurité.** Dans la section **Authentification multifactorielle (MFA)**, cliquez sur le bouton radio situé en regard du dispositif MFA et sélectionnez **Resynchroniser**.

1. Entrez les deux prochains codes générés séquentiellement à partir du périphérique dans les champs **MFA code 1** et **MFA code 2**. Puis choisissez **Resync** (Resynchroniser).
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, cette dernière semble fonctionner mais l'appareil reste désynchronisé. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période.

**Pour resynchroniser votre dispositif MFA d'utilisateur racine avant la connexion (console)**

1. Sur la page **Amazon Web Services Sign In With Authentication Device** (connexion à Amazon Web Services à l'aide de MFA), choisissez **Having problems with your authentication device? (des problèmes avec votre dispositif d'authentification ?) Click here** (Cliquez ici).
**Note**  
Il se peut que vous remarquiez des textes différents, tels que **se connecter à l'aide de MFA** et **dépanner votre dispositif d'authentification**. Toutefois, les mêmes fonctions sont fournies.

1. Dans la section **Re-Sync With Our Servers (Resynchroniser avec nos serveurs)**, entrez les deux prochains codes générés séquentiellement à partir du périphérique dans les champs **MFA code 1** et **MFA code 2**. Ensuite, choisissez **Re-sync authentication device (Resynchroniser l'appareil d'authentification)**.

1. Si besoin, saisissez à nouveau votre mot de passe et choisissez **Sign in (Connexion)**. Ensuite, procédez à la connexion à l'aide de votre dispositif MFA.

**Pour resynchroniser votre dispositif MFA d'utilisateur racine après la connexion (console)**

1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iam/) en tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe.
**Note**  
En tant qu'utilisateur root, vous ne pouvez pas vous connecter à la page **Se connecter en tant qu'utilisateur IAM**. Si la page **Se connecter en tant qu'utilisateur IAM** s'affiche, choisissez **Se connecter à l'aide de l'adresse e-mail de l'utilisateur root** en bas de la page. Pour obtenir de l'aide pour vous connecter en tant qu'utilisateur root, consultez [la section Connexion en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html) dans le *Guide de Connexion à AWS l'utilisateur*.

1. À droite de la barre de navigation, sélectionnez le nom de votre compte, puis **Security Credentials** (Informations d'identification de sécurité). Au besoin, choisissez **Continue to Security credentials** (Passer aux informations d'identification de sécurité).  
![\[Informations d'identification de sécurité dans le menu de navigation\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. Sur la page, développez la section **Multi-factor authentication (MFA) (authentification multi-facteur (MFA))**.

1. Cliquez sur le bouton radio en regard du dispositif et choisissez **Resync** (Resynchroniser).

1. Dans la boîte de dialogue **Resync MFA device** (Resynchroniser le dispositif MFA), entrez les deux prochains codes générés séquentiellement à partir du dispositif dans les champs **MFA code 1** et **MFA code 2**. Puis choisissez **Resync** (Resynchroniser).
**Important**  
Envoyez votre demande immédiatement après avoir généré les codes. Si vous générez les codes, puis attendez trop longtemps avant d'envoyer la demande, le dispositif MFA s'associe avec succès à l'utilisateur mais est désynchronisé. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période.

## Resynchronisation de dispositifs MFA virtuels et matériels (AWS CLI)
<a name="id_credentials_mfa_sync_cli"></a>

Vous pouvez resynchroniser les dispositifs MFA virtuels et matériels à partir de l’interface AWS CLI.

**Pour resynchroniser un dispositif MFA virtuel ou matériel pour un utilisateur IAM (AWS CLI)**  
À l'invite de commande, lancez la resync-mfa-device commande [aws iam](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) :
+ Dispositif MFA virtuel : spécifiez l'Amazon Resource Name (ARN) du périphérique en tant que numéro de série.

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number arn:aws:iam::123456789012:mfa/RichardsMFA --authentication-code1 123456 --authentication-code2 987654
  ```
+ Dispositif MFA matériel : spécifiez le numéro de série du périphérique matériel en tant que numéro de série. Le format est spécifique au fournisseur. Par exemple, vous pouvez acheter un jeton gemalto auprès d'Amazon. Son numéro de série est généralement composé de quatre lettres suivies de quatre chiffres.

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number ABCD12345678 --authentication-code1 123456 --authentication-code2 987654
  ```

**Important**  
Envoyez votre demande immédiatement après avoir généré les codes. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la demande, cette dernière échoue car les codes expirent après une courte période.

## Resynchronisation des périphériques MFA virtuels et matériels (API)AWS
<a name="id_credentials_mfa_sync_api"></a>

IAM dispose d'un appel d'API qui effectue la synchronisation. Dans ce cas, nous vous recommandons d'accorder à vos utilisateurs de dispositifs MFA virtuels et matériels l'autorisation d'accès à cet appel d'API. Créez ensuite un outil basé sur cet appel d'API afin que vos utilisateurs puissent resynchroniser leurs périphériques chaque fois que cela est nécessaire.

**Pour resynchroniser un périphérique MFA virtuel ou matériel pour un utilisateur IAM (API)AWS**
+ Envoyez la demande de [resynchronisation. MFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html)

# Désactivation d’un dispositif MFA
<a name="id_credentials_mfa_disable"></a>

Si vous rencontrez des difficultés pour vous connecter avec un dispositif d'authentification multifactorielle (MFA) en tant qu'utilisateur IAM, contactez votre administrateur pour obtenir de l'aide.

En tant qu'administrateur, vous pouvez désactiver le dispositif pour un autre utilisateur IAM. Cela permet à l'utilisateur de se connecter sans utiliser MFA. Vous pouvez faire ceci comme solution provisoire en attendant que le dispositif MFA soit remplacé ou si le périphérique est indisponible temporairement. Par contre, nous vous recommandons d'activer un nouveau périphérique pour l'utilisateur dès que possible. Pour savoir comment activer un nouveau dispositif MFA, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md).

**Note**  
Si vous utilisez l'API ou si vous AWS CLI souhaitez supprimer un utilisateur Compte AWS, vous devez désactiver ou supprimer le dispositif MFA de l'utilisateur. Vous effectuez cette modification dans le cadre du processus de suppression de l'utilisateur. Pour en savoir plus sur la suppression d’utilisateurs, consultez [Suppression ou désactivation d’un utilisateur IAM](id_users_remove.md).

**Topics**
+ [Désactivation des dispositifs MFA (console)](#deactive-mfa-console)
+ [Désactivation des dispositifs MFA (AWS CLI)](#deactivate-mfa-cli)
+ [Désactivation des appareils AWS MFA (API)](#deactivate-mfa-api)

## Désactivation des dispositifs MFA (console)
<a name="deactive-mfa-console"></a><a name="deactivate-mfa-for-user"></a>

**Pour désactiver un dispositif MFA pour un autre utilisateur IAM (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Pour désactiver le dispositif MFA pour un utilisateur, choisissez le nom de l'utilisateur dont vous souhaitez supprimer le MFA.

1. Choisissez l’onglet **Informations d’identification de sécurité.**

1. Sous **Authentification multifactorielle (MFA)**, cliquez sur le bouton radio situé en regard du dispositif MFA, puis sélectionnez **Supprimer** et encore **Supprimer**.

   L'appareil est retiré de AWS. Il ne peut pas être utilisé pour se connecter ou authentifier des demandes tant qu'il n'est pas réactivé et associé à un AWS utilisateur ou. Utilisateur racine d'un compte AWS<a name="deactivate-mfa-for-root"></a>

**Pour désactiver le dispositif MFA de Utilisateur racine d'un compte AWS votre (console)**

1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iam/) en tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe.
**Note**  
En tant qu'utilisateur root, vous ne pouvez pas vous connecter à la page **Se connecter en tant qu'utilisateur IAM**. Si la page **Se connecter en tant qu'utilisateur IAM** s'affiche, choisissez **Se connecter à l'aide de l'adresse e-mail de l'utilisateur root** en bas de la page. Pour obtenir de l'aide pour vous connecter en tant qu'utilisateur root, consultez [la section Connexion en AWS Management Console tant qu'utilisateur root](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html) dans le *Guide de Connexion à AWS l'utilisateur*.

1. À droite de la barre de navigation, sélectionnez le nom de votre compte, puis **Security Credentials** (Informations d'identification de sécurité). Au besoin, choisissez **Continue to Security credentials** (Passer aux informations d'identification de sécurité).  
![\[Informations d'identification de sécurité dans le menu de navigation\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. Dans la section **Multi-factor authentication (MFA)** (Authentification multifactorielle (MFA)), cliquez sur le bouton radio en regard du dispositif MFA que vous souhaitez désactiver, puis choisissez **Remove** (Supprimer).

1. Cliquez sur **Supprimer**.

   Le dispositif MFA est désactivé pour l' Compte AWS. Vérifiez que l'e-mail qui vous est associé contient Compte AWS un message de confirmation provenant d'Amazon Web Services. L'e-mail vous informe que votre authentification multi-facteur (MFA) Amazon Web Services a été désactivée. Le message viendra de `@amazon.com` ou `@aws.amazon.com`.

**Note**  
Les appareils MFA virtuels non assignés dans Compte AWS votre compte sont supprimés lorsque vous ajoutez de nouveaux appareils MFA virtuels, soit par le biais AWS Management Console du processus de connexion, soit pendant celui-ci. Les dispositifs MFA virtuels non attribués sont des dispositifs présents dans votre compte, mais qui ne sont pas utilisés par l’utilisateur racine du compte ou les utilisateurs IAM pour le processus de connexion. Ils sont supprimés afin que de nouveaux dispositifs MFA virtuels puissent être ajoutés à votre compte. Cela vous permet également de réutiliser les noms des appareils.

## Désactivation des dispositifs MFA (AWS CLI)
<a name="deactivate-mfa-cli"></a>

**Pour désactiver un dispositif MFA pour un utilisateur IAM (AWS CLI)**
+ Exécutez cette commande : [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)

## Désactivation des appareils AWS MFA (API)
<a name="deactivate-mfa-api"></a>

**Pour désactiver un appareil MFA pour un utilisateur IAM (API)AWS**
+ Appelez cette opération : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

# Restauration d’une identité protégée par MFA dans IAM
<a name="id_credentials_mfa_lost-or-broken"></a>

Si votre [périphérique MFA virtuel](id_credentials_mfa_enable_virtual.md) ou votre [jeton TOTP matériel](id_credentials_mfa_enable_physical.md) semble fonctionner correctement, mais que vous ne pouvez pas l'utiliser pour accéder à vos AWS ressources, il est possible qu'il ne soit pas synchronisé avec. AWS Pour plus d'informations sur la synchronisation d'un dispositif MFA virtuel ou d'un dispositif MFA matériel, consultez [Resynchronisation des dispositifs MFA virtuels et matériels](id_credentials_mfa_sync.md). Les [clés de sécurité FIDO](id_credentials_mfa_enable_fido.md) ne se désynchronisent pas.

Si le [dispositif MFA](id_credentials_mfa.md) d'un Utilisateur racine d'un compte AWS est perdu, endommagé ou ne fonctionne pas, vous pouvez récupérer l'accès à votre compte. Les utilisateurs IAM doivent contacter un administrateur pour désactiver le périphérique.

**Important**  
Nous vous recommandons d’activer plusieurs dispositifs MFA. L’enregistrement de plusieurs dispositifs MFA permet de garantir la continuité de l’accès en cas de perte ou de casse d’un dispositif. Vos utilisateurs Utilisateur racine d'un compte AWS et ceux d'IAM peuvent enregistrer jusqu'à huit appareils MFA de tout type.

## Prérequis – Utilisation d’un autre appareil MFA
<a name="mfa-lost-or-broken-prerequisites"></a>

Si le [dispositif d’authentification multifactorielle (MFA)](id_credentials_mfa.md) est perdu, endommagé ou défaillant, vous pouvez vous connecter à l’aide d’un autre dispositif MFA enregistré au même utilisateur racine ou utilisateur IAM.

**Pour vous connecter à l’aide d’un autre appareil MFA**

1. Connectez-vous à l’[AWS Management Console](url-comsole-domain;iam) à l’aide de votre ID d’ Compte AWS ou de votre alias de compte et de votre mot de passe.

1. Sur la page **Vérification supplémentaire nécessaire** ou la page **Authentification multifactorielle**, choisissez **Essayer une autre méthode MFA**.

1. Authentifiez-vous avec le type de dispositif MFA que vous avez sélectionné.

1. L’étape suivante varie selon que vous vous êtes connecté avec succès avec un autre dispositif MFA.
   + Si vous vous êtes connecté avec succès, vous pouvez [Resynchronisation des dispositifs MFA virtuels et matériels](id_credentials_mfa_sync.md), ce qui peut résoudre le problème. Si votre dispositif MFA est perdu ou endommagé, vous pouvez le désactiver. Pour plus d'informations sur la désactivation de tout type de dispositif MFA, consultez [Désactivation d’un dispositif MFA](id_credentials_mfa_disable.md).
   + Si vous ne parvenez pas à vous connecter avec la MFA, suivez les étapes indiquées dans [Récupération d'un dispositif MFA d'utilisateur racine](#root-mfa-lost-or-broken) ou [Récupération d'un dispositif MFA d'utilisateur IAM](#iam-user-mfa-lost-or-broken) pour récupérer votre identité protégée par la MFA.



## Récupération d'un dispositif MFA d'utilisateur racine
<a name="root-mfa-lost-or-broken"></a>

Si vous ne pouvez pas vous connecter par MFA, vous pouvez utiliser d’autres méthodes d’authentification pour vous connecter en vérifiant votre identité à l’aide de l’e-mail et du numéro de téléphone de contact principal enregistrés avec votre compte.

Assurez-vous de pouvoir accéder à l’e-mail et au numéro de téléphone du contact principal associés à votre compte avant d’utiliser d’autres facteurs d’authentification pour vous connecter en tant qu’utilisateur racine. Si vous devez mettre à jour le numéro de téléphone du contact principal, connectez-vous en tant qu’utilisateur IAM avec un accès *Administrateur* au lieu de l’utilisateur racine. Pour obtenir des instructions supplémentaires sur la mise à jour des informations de contact du compte, consultez la section [Modification de vos informations de contact](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) dans le *Guide de l'utilisateur AWS Billing *. Si vous n'avez pas accès à une adresse e-mail et à un numéro de téléphone de contact principal, vous devez contacter [AWS Support](https://support.aws.amazon.com/#/contacts/aws-mfa-support).

**Important**  
Nous vous recommandons de garder à jour l'adresse e-mail et le numéro de téléphone de contact associés à votre utilisateur root pour une restauration réussie du compte. Pour plus d'informations, consultez [Mettre à jour le contact principal pour votre Compte AWS](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) dans le *guide de référence d'Gestion de compte AWS *.

**Pour vous connecter en utilisant d'autres facteurs d'authentification en tant que Utilisateur racine d'un compte AWS**

1.  Connectez-vous en [AWS Management Console](https://console.aws.amazon.com/)tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe.

1. **Sur la page **Vérification supplémentaire nécessaire**, choisissez une méthode MFA pour vous authentifier, puis choisissez Suivant**. 
**Note**  
Vous pouvez voir un texte de remplacement, tel que **Connectez-vous à l'aide de MFA**, **Dépanner votre dispositif d'authentification**, ou **Dépanner le MFA**, mais les fonctionnalités sont les mêmes. Si vous ne pouvez pas utiliser d’autres facteurs d’authentification pour vérifier l’adresse e-mail et le numéro de téléphone du contact principal de votre compte, contactez [AWS Support](https://support.aws.amazon.com/#/contacts/aws-mfa-support) pour désactiver votre dispositif MFA.

1. Selon le type de MFA que vous utilisez, vous verrez une page différente, mais l'option **Dépanner MFA** fonctionne de la même manière. Sur la page **Vérification supplémentaire nécessaire** ou **Authentification multifacteur**, choisissez **Dépanner MFA**.

1. Si besoin, saisissez à nouveau votre mot de passe et choisissez **Sign in (Connexion)**.

1. Sur la page **Dépanner votre dispositif d'authentification**, dans la section **Connectez-vous à l'aide d'autres facteurs d'authentification**, choisissez **Connectez-vous à l'aide d'autres facteurs**.

1. Sur la page **Connectez-vous à l'aide d'autres facteurs d'authentification**, authentifiez votre compte en vérifiant l'adresse e-mail, puis choisissez **Envoyer un e-mail de vérification**. 

1. Vérifiez que l'e-mail associé à votre compte contient un message provenant Compte AWS d'Amazon Web Services (recover-mfa-no-reply@verify .signin.aws). Suivez les instructions de l'e-mail.

   Si vous ne voyez pas d'e-mail dans votre boîte de réception, vérifiez le dossier des courriers indésirables, ou revenez à votre navigateur et choisissez **Resend the email (Renvoyer l'e-mail)**.

1. Une fois que vous avez confirmé votre adresse e-mail, vous pouvez continuer à authentifier votre compte. Pour confirmer votre numéro de téléphone de contact principal, choisissez **Call me now** (Appelez-moi maintenant).

1. Répondez à l'appel de AWS et, lorsque vous y êtes invité, entrez le numéro à 6 chiffres du AWS site Web sur le clavier de votre téléphone. 

   Si vous ne recevez aucun appel de AWS, choisissez **Se connecter** pour vous reconnecter à la console et recommencer. Ou consultez la rubrique [Appareil d'authentification multifactorielle (MFA) perdu ou inutilisable](https://support.aws.amazon.com/#/contacts/aws-mfa-support) pour obtenir l'aide du support.

1. Une fois que vous avez confirmé votre numéro de téléphone, vous pouvez vous connecter à votre compte en choisissant **Sign in to the console (Se connecter à la console)**.

1. L'étape suivante varie selon le type de MFA que vous utilisez :
   + Si vous utilisez un dispositif MFA virtuel, supprimez le compte de votre périphérique. Ensuite, accédez à la page [Informations d'identification de sécuritéAWS](https://console.aws.amazon.com/iam/home?#security_credential) et supprimez l'ancienne entité de dispositif virtuel MFA avant d'en créer une nouvelle.
   + Pour une clé de sécurité FIDO, accédez à la page [Informations d'identification de sécuritéAWS](https://console.aws.amazon.com/iam/home?#security_credential) et désactivez l'ancienne clé FIDO avant d'en activer une nouvelle.
   + Si vous utilisez un jeton TOTP matériel, contactez le fournisseur tiers pour qu’il dépanne ou remplace le dispositif. Vous pouvez continuer à vous connecter à l'aide d'autres facteurs d'authentification jusqu'à ce que vous receviez votre nouveau périphérique. Une fois que vous avez le nouveau dispositif MFA matériel, rendez-vous sur la page [Informations d’identification de sécuritéAWS](https://console.aws.amazon.com/iam/home?#security_credential) et supprimez l’ancienne entité de dispositif matériel MFA avant d’en recréer une.
**Note**  
Vous n'êtes pas obligé de remplacer un dispositif MFA perdu ou volé par le même type de périphérique. Par exemple, si vous cassez votre clé de sécurité FIDO et en commandez une nouvelle, vous pouvez utiliser un dispositif MFA virtuel ou un jeton TOTP matériel jusqu’à réception de la nouvelle clé FIDO.

**Important**  
Si votre dispositif MFA est manquant ou volé, modifiez votre mot de passe d’utilisateur racine après vous être connecté et avoir mis en place votre dispositif MFA de remplacement. Un attaquant pourrait avoir volé le dispositif d’authentification et pourrait également détenir votre mot de passe actuel. Pour de plus amples informations, veuillez consulter [Changez le mot de passe du Utilisateur racine d'un compte AWS](root-user-password.md).

## Récupération d'un dispositif MFA d'utilisateur IAM
<a name="iam-user-mfa-lost-or-broken"></a>

Si vous êtes un utilisateur IAM et que vous ne pouvez pas vous connecter par MFA, vous ne pouvez pas récupérer un dispositif MFA par vous-même. Vous devez contacter un administrateur pour désactiver le périphérique. Ensuite, vous pouvez activer un nouveau périphérique.

**Pour obtenir de l'aide pour un dispositif MFA en tant qu'utilisateur IAM**

1. Contactez l' AWS administrateur ou toute autre personne qui vous a fourni le nom d'utilisateur et le mot de passe de l'utilisateur IAM. L'administrateur doit désactiver le dispositif MFA, comme décrit dans [Désactivation d’un dispositif MFA](id_credentials_mfa_disable.md), afin que vous puissiez vous connecter.

1. L'étape suivante varie selon le type de MFA que vous utilisez :
   + Si vous utilisez un dispositif MFA virtuel, supprimez le compte de votre périphérique. Activez ensuite le périphérique virtuel comme décrit dans [Attribuez un périphérique MFA virtuel dans le AWS Management Console](id_credentials_mfa_enable_virtual.md).
   + Si vous utilisez une clé de sécurité FIDO, contactez le fournisseur tiers pour qu’il remplace le dispositif. Lorsque vous recevez la nouvelle clé de sécurité FIDO, activez-la comme décrit dans [Attribuez un mot de passe ou une clé de sécurité dans AWS Management Console](id_credentials_mfa_enable_fido.md).
   + Si vous utilisez un jeton TOTP matériel, contactez le fournisseur tiers pour qu’il dépanne ou remplace le dispositif. Une fois que vous avez le nouveau dispositif MFA, activez-le comme décrit dans [Attribuez un jeton TOTP matériel dans le AWS Management Console](id_credentials_mfa_enable_physical.md).
**Note**  
Vous n'êtes pas obligé de remplacer un dispositif MFA perdu ou volé par le même type de périphérique. Vous pouvez avoir jusqu'à huit dispositifs MFA, quelle que soit leur combinaison. Par exemple, si vous cassez votre clé de sécurité FIDO et en commandez une nouvelle, vous pouvez utiliser un dispositif MFA virtuel ou un jeton TOTP matériel jusqu’à réception de la nouvelle clé FIDO.

1. Si votre dispositif MFA est perdu ou volé, modifiez votre mot de passe , au cas où un pirate informatique aurait volé le dispositif d'authentification et détiendrait également votre mot de passe actuel. Pour de plus amples informations, veuillez consulter [Gérer les mots de passe des utilisateurs IAM](id_credentials_passwords_admin-change-user.md).

# Accès sécurisé aux API avec MFA
<a name="id_credentials_mfa_configure-api-require"></a>

Avec les politiques IAM, vous pouvez spécifier quelles opérations d'API un utilisateur est autorisé à appeler. Vous pouvez renforcer la sécurité en exigeant des utilisateurs qu’ils s’authentifient à l’aide d’une authentification multifactorielle (MFA) avant de les autoriser à effectuer des actions particulièrement sensibles.

Par exemple, vous disposez peut-être d'une politique qui autorise l'utilisateur à exécuter les actions Amazon EC2 `RunInstances`, `DescribeInstances` et `StopInstances`. Mais vous souhaiterez peut-être restreindre une action destructrice telle que `TerminateInstances` et vous assurer que les utilisateurs ne peuvent effectuer cette action que s'ils s'authentifient auprès d'un périphérique AWS MFA.

**Topics**
+ [Présentation de](#MFAProtectedAPI-overview)
+ [Scénario : protection MFA pour la délégation entre comptes](#MFAProtectedAPI-cross-account-delegation)
+ [Scénario : protection MFA pour l'accès aux opérations d'API du compte actuel](#MFAProtectedAPI-user-mfa)
+ [Scénario : protection MFA des ressources disposant de politiques basées sur les ressources](#MFAProtectedAPI-resource-policies)

## Présentation de
<a name="MFAProtectedAPI-overview"></a>

L'ajout d'une protection MFA aux opérations d'API nécessite les tâches suivantes :

1. L'administrateur configure un dispositif AWS MFA pour chaque utilisateur qui doit effectuer des demandes d'API nécessitant une authentification MFA. Pour de plus amples informations, veuillez consulter [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md). 

1. L'administrateur crée des politiques pour les utilisateurs qui incluent un `Condition` élément qui vérifie si l'utilisateur s'est authentifié avec un dispositif AWS MFA.

1. L'utilisateur appelle l'une des opérations d' AWS STS API prenant en charge les paramètres MFA : [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou. [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) Dans le cadre de l'appel, l'utilisateur inclut l'identifiant du périphérique associé à l'utilisateur. L'utilisateur inclut également le mot de passe TOTP (Time-based One-Time Password) que le périphérique génère. Dans tous les cas, l'utilisateur récupère les informations d'identification de sécurité temporaires qu'il peut ensuite utiliser pour effectuer des demandes supplémentaires à AWS.
**Note**  
La protection MFA des opérations d'API d'un service est uniquement disponible si le service prend en charge les informations d'identification de sécurité temporaires. Pour connaître la liste de ces services, veuillez consulter [Utilisation d'informations d'identification de sécurité temporaires pour accéder à AWS](https://docs.aws.amazon.com/STS/latest/UsingSTS/UsingTokens.html).

Si l'autorisation échoue, AWS renvoie un message d'erreur de refus d'accès (comme c'est le cas pour tout accès non autorisé). Lorsque des politiques d'API protégées par MFA sont en place, AWS refuse l'accès aux opérations d'API spécifiées dans les politiques si l'utilisateur tente d'appeler une opération d'API sans authentification MFA valide. L'opération est également refusée si l'horodatage de la demande pour l'opération d'API se situe en dehors de la plage autorisée spécifiée dans la politique. L'utilisateur doit être à nouveau authentifié avec l'authentification MFA en demandant de nouvelles informations d'identification de sécurité temporaires avec un code MFA et un numéro de série de périphérique.

### Politiques IAM avec des conditions MFA
<a name="MFAProtectedAPI-policies"></a>

Les politiques avec des conditions MFA peuvent être attachées à ce qui suit :
+ Un utilisateur ou un groupe IAM
+ Une ressource telle qu'un compartiment Amazon S3, une file d'attente Amazon SQS ou une rubrique Amazon SNS
+ La politique d'approbation d'un rôle IAM qui peut être endossée par un utilisateur

Vous pouvez utiliser une condition MFA d'une politique pour vérifier les propriétés suivantes :
+ Existence : pour vérifier simplement que l'utilisateur s'est authentifié par MFA, vérifiez que la clé `aws:MultiFactorAuthPresent` est `True` dans une condition `Bool`. La clé est uniquement présente lorsque l'utilisateur s'authentifie avec des informations d'identification à court terme. Les informations d'identification à long terme, telles que les clés d'accès, n'incluent pas cette clé.
+ Durée : si vous voulez octroyer l'accès uniquement dans un délai spécifié après l'authentification MFA, utilisez un type de condition numérique pour comparer l'âge de la clé `aws:MultiFactorAuthAge` à une valeur (par exemple 3 600 secondes). Notez que la clé `aws:MultiFactorAuthAge` n'est pas présente si l'authentification MFA n'a pas été utilisée.

L'exemple suivant présente la politique d'approbation d'un rôle IAM incluant une condition MFA pour tester l'existence de l'authentification MFA. Avec cette politique, les utilisateurs Compte AWS spécifiés dans l'`Principal`élément (à `ACCOUNT-B-ID` remplacer par un Compte AWS identifiant valide) peuvent assumer le rôle auquel cette politique est attachée. Toutefois, ces utilisateurs peuvent endosser le rôle uniquement s'ils se sont authentifiés à l'aide de l'authentification MFA.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}
```

------

Pour plus d'informations sur les types de conditions pour l'authentification MFA, consultez [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md), [Opérateurs de condition numériques](reference_policies_elements_condition_operators.md#Conditions_Numeric) et [Opérateur de condition pour vérifier l'existence de clés de condition](reference_policies_elements_condition_operators.md#Conditions_Null) 

### Choisir entre GetSessionToken et AssumeRole
<a name="scenarios"></a>

AWS STS fournit deux opérations d'API qui permettent aux utilisateurs de transmettre des informations MFA : `GetSessionToken` et. `AssumeRole` L'opération d'API que l'utilisateur appelle pour obtenir des informations d'identification de sécurité temporaires dépend du scénario applicable parmi les suivants : 

**Utilisez `GetSessionToken` pour les scénarios suivants :**
+ Appelez les opérations d'API qui accèdent aux ressources de la même manière Compte AWS que l'utilisateur IAM qui fait la demande. Notez que les informations d'identification temporaires issues d'une `GetSessionToken` demande ne peuvent accéder aux opérations IAM et AWS STS API *que* si vous incluez des informations MFA dans la demande d'informations d'identification. Du fait que les informations d'identification temporaires renvoyées par `GetSessionToken` incluent des informations d'authentification MFA, vous pouvez vérifier l'authentification MFA dans les opérations d'API individuelles effectuées par les informations d'identification. 
+ Accédez aux ressources protégées par des politiques basées sur les ressources qui incluent une condition MFA.

Le but principal de l'opération `GetSessionToken` est d'authentifier l'utilisateur à l'aide de l'authentification MFA. Vous ne pouvez pas utiliser de stratégies pour contrôler les opérations d’authentification.

**Utilisez `AssumeRole` pour les scénarios suivants :**
+ Appeler des opérations d'API qui accèdent à des ressources dans le même Compte AWS ou dans un compte différent. Les appels d'API peuvent inclure n'importe quel IAM ou AWS STS API. Notez que pour protéger l'accès vous devez appliquer l'authentification MFA au moment où l'utilisateur endosse le rôle. Les informations d'identification temporaires renvoyées par `AssumeRole` n'incluent pas d'informations d'authentification MFA dans ce contexte ; vous ne pouvez donc pas vérifier les opérations d'API individuelles pour l'authentification MFA. C'est pourquoi vous devez utiliser `GetSessionToken` pour restreindre l'accès aux ressources protégées par des politiques basées sur les ressources.

**Note**  
AWS CloudTrail les journaux contiendront des informations MFA lorsque l'utilisateur IAM se connectera avec MFA. Si l'utilisateur IAM assume un rôle IAM, il CloudTrail se connectera également aux `sessionContext` attributs des actions effectuées `mfaAuthenticated: true` à l'aide du rôle assumé. Cependant, la CloudTrail journalisation est distincte de ce dont IAM a besoin lorsque des appels d'API sont effectués avec les informations d'identification du rôle assumé. Pour en savoir plus, consultez [Élément CloudTrail userIdentity](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).

Vous trouverez des détails sur l'implémentation de ces scénarios ultérieurement dans ce document.

### Points importants sur l'accès aux API protégé par MFA
<a name="MFAProtectedAPI-important-points"></a>

Il est important de comprendre les aspects suivants relatifs à la protection MFA pour les opérations d'API :
+ La protection MFA est uniquement disponible avec les informations d'identification de sécurité temporaires que vous devez obtenir avec `AssumeRole` ou `GetSessionToken`. 
+ Vous ne pouvez pas utiliser l'accès à l'API protégé par MFA avec des informations d'identification. Utilisateur racine d'un compte AWS 
+ Vous ne pouvez pas utiliser l'accès aux API protégé par MFA avec les clés de sécurité U2F.
+ Les utilisateurs fédérés ne peuvent pas se voir attribuer de périphérique MFA pour une utilisation AWS avec les services, ils ne peuvent donc pas AWS accéder aux ressources contrôlées par le MFA. (Voir le point suivant.) 
+ Les autres opérations d' AWS STS API qui renvoient des informations d'identification temporaires ne prennent pas en charge le MFA. Pour `AssumeRoleWithWebIdentity` et`AssumeRoleWithSAML`, l'utilisateur est authentifié par un fournisseur externe et AWS ne peut pas déterminer si ce fournisseur a besoin du MFA. Pour `GetFederationToken`, l'authentification MFA n'est pas nécessairement associée à un utilisateur spécifique. 
+ De même, les informations d'identification à long terme (clés d'accès utilisateur IAM et clés d'accès de l’utilisateur racine) ne peuvent pas être utilisées avec l'accès aux API protégé par MFA, car elles n'expirent pas.
+ `AssumeRole` et `GetSessionToken` peuvent également être appelées sans informations MFA. Dans ce cas, le principal récupère les informations d'identification de sécurité temporaires, mais les informations de session de ces informations d'identification temporaires n'indiquent pas que l'utilisateur s'est authentifié avec l'authentification MFA.
+ Pour établir la protection MFA pour les opérations d'API, ajoutez des conditions d'authentification MFA aux politiques. Une politique doit inclure la clé de condition `aws:MultiFactorAuthPresent` pour imposer l'utilisation de l'authentification MFA. Pour la délégation entre comptes, la politique d'approbation du rôle doit inclure la clé de condition.
+ Lorsque vous autorisez une autre personne Compte AWS à accéder aux ressources de votre compte, la sécurité de vos ressources dépend de la configuration du compte approuvé (l'autre compte, pas le vôtre). Cela est vrai même lorsque vous imposez une authentification multi-facteur. Toutes les identités du compte approuvé ayant l'autorisation de créer des dispositifs MFA virtuels peut créer une demande de MFA pour satisfaire cette partie de la politique d'approbation de votre rôle. Avant d'autoriser les membres d'un autre compte à accéder à vos AWS ressources qui nécessitent une authentification à plusieurs facteurs, vous devez vous assurer que le propriétaire du compte de confiance suit les meilleures pratiques en matière de sécurité. Par exemple, le compte approuvé doit restreindre l'accès aux opérations d'API sensibles, telles que les opérations d'API de gestion de dispositif MFA, à des identités approuvées spécifiques.
+ Si une politique inclut une condition MFA, une demande est refusée si les utilisateurs n'ont pas été authentifiés par MFA ou s'ils fournissent un identifiant de dispositif MFA ou un TOTP non valide.

## Scénario : protection MFA pour la délégation entre comptes
<a name="MFAProtectedAPI-cross-account-delegation"></a>

Dans ce scénario, vous souhaitez déléguer l'accès aux utilisateurs IAM d'un autre compte, mais uniquement si les utilisateurs sont authentifiés à l'aide d'un appareil MFA AWS . Pour plus d’informations sur la délégation entre comptes, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts). 

Imaginons que vous disposiez d'un compte A (le compte d'approbation qui est titulaire de la ressource auxquelles les utilisateurs ont accès), avec l'utilisateur IAM Anaya qui dispose de l'autorisation administrateur. Elle souhaite accorder l'accès à l'utilisateur Richard au compte B (le compte approuvé), mais veut s'assurer que Richard s'est authentifié avec MFA avant d'endosser le rôle. 

1. Dans le compte de confiance A, Anaya crée un rôle IAM nommé `CrossAccountRole` et définit le principal de la politique de confiance du rôle sur l'ID du compte B. La politique de confiance autorise l'action. AWS STS `AssumeRole` Anaya ajoute également une condition MFA à la politique d'approbation, comme dans l'exemple suivant. 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Allow",
       "Principal": {"AWS": "ACCOUNT-B-ID"},
       "Action": "sts:AssumeRole",
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }
   }
   ```

------

1. Anaya ajoute une politique d'autorisations au rôle qui spécifie ce que le rôle est autorisé à faire. La politique d'autorisations d'un rôle avec protection MFA est identique à toutes les politiques d'autorisation de rôle. L'exemple suivant montre la politique qu'Anaya ajoute au rôle : elle permet à un utilisateur endossant le rôle d'exécuter toutes les actions Amazon DynamoDB sur la table `Books` dans le compte A. Cette politique permet également l'action `dynamodb:ListTables`, qui est nécessaire pour effectuer des actions dans la console. 
**Note**  
La politique d'autorisations n'inclut pas de condition MFA. Il est important de comprendre que l'authentification MFA sert uniquement à déterminer si un utilisateur peut endosser le rôle. Une fois que l'utilisateur endosse le rôle, aucune autre vérification MFA n'est effectuée. 

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "TableActions",
               "Effect": "Allow",
               "Action": "dynamodb:*",
               "Resource": "arn:aws:dynamodb:*:111122223333:table/Books"
           },
           {
               "Sid": "ListTables",
               "Effect": "Allow",
               "Action": "dynamodb:ListTables",
               "Resource": "*"
           }
       ]
   }
   ```

------

1. Dans le compte sécurisé B, l'administrateur s'assure que l'utilisateur IAM Richard est configuré avec un appareil AWS MFA et qu'il connaît l'identifiant de l'appareil. L'ID du périphérique est le numéro de série s'il s'agit d'un dispositif MFA matériel, ou l'ARN du périphérique s'il s'agit d'un dispositif MFA virtuel.

1. Dans le compte B, l'administrateur attache la politique suivante à l'utilisateur Richard (ou à un groupe dont il est membre) qui l'autorise à appeler l'action `AssumeRole`. La ressource est définie sur l'ARN du rôle qu'Anaya a créé à l'étape 1. Notez que cette politique n'inclut aucune condition MFA.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sts:AssumeRole"
               ],
               "Resource": [
                   "arn:aws:iam::111122223333:role/CrossAccountRole"
               ]
           }
       ]
   }
   ```

------

1. Dans le compte B, Richard (ou une application qu'il exécute) appelle `AssumeRole`. L'appel d'API inclut l'ARN du rôle à endosser (`arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole`), l'ID du dispositif MFA et le TOTP actuel que Richard obtient de ce périphérique. 

   Lorsque Richard appelle`AssumeRole`, il AWS détermine s'il possède des informations d'identification valides, y compris l'exigence du MFA. Le cas échéant, Richard réussit à endosser le rôle et peut exécuter n'importe quelle action DynamoDB sur la table nommée `Books` dans le compte A tout en utilisant les informations d'identification temporaires du rôle. 

   Pour obtenir un exemple d'un programme qui appelle `AssumeRole`, consultez [Appels AssumeRole avec authentification MFA](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-assumerole).

## Scénario : protection MFA pour l'accès aux opérations d'API du compte actuel
<a name="MFAProtectedAPI-user-mfa"></a>

Dans ce scénario, vous devez vous assurer qu'un utilisateur Compte AWS peut accéder aux opérations d'API sensibles uniquement lorsqu'il est authentifié à l'aide d'un dispositif AWS MFA.

Imaginons que vous ayez un compte A contenant un groupe de développeurs ayant besoin d'utiliser des instances EC2. Les développeurs standard peuvent utiliser les instances, mais ils n'ont pas l'autorisation d'utiliser les actions `ec2:StopInstances` ou `ec2:TerminateInstances`. Vous souhaitez limiter ces actions « destructives » réalisées avec des actions à quelques utilisateurs approuvés uniquement, vous ajoutez donc la protection MFA à la politique qui autorise ces actions Amazon EC2 sensibles. 

Dans ce scénario, l'un des utilisateurs approuvé s'appelle Sofía. L'utilisatrice Anaya est administratrice du compte A. 

1. Anaya s'assure que Sofía est configurée avec un appareil AWS MFA et que Sofía connaît l'identifiant de l'appareil. L'ID du périphérique est le numéro de série s'il s'agit d'un dispositif MFA matériel, ou l'ARN du périphérique s'il s'agit d'un dispositif MFA virtuel. 

1. Anaya crée un groupe appelé `EC2-Admins` et ajoute l'utilisatrice Sofía au groupe.

1. Anaya attache la politique suivante au groupe `EC2-Admins`. Cette politique autorise également les utilisateurs à appeler les actions `StopInstances` et `TerminateInstances` Amazon EC2 uniquement si l'utilisateur s'est authentifié à l'aide de l'authentification MFA. 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Action": [
         "ec2:StopInstances",
         "ec2:TerminateInstances"
       ],
       "Resource": ["*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------

1. 
**Note**  
Pour que cette politique prenne effet, les utilisateurs doivent d'abord se déconnecter et se connecter à nouveau.

   Si l'utilisatrice Sofía a besoin d'arrêter ou de résilier une instance Amazon EC2, elle (ou une application qu'elle exécute) appelle `GetSessionToken`. Cette opération d'API transmet l'ID du dispositif MFA et le TOTP actuel que Sofía obtient de son périphérique.

1. L'utilisatrice Sofía (ou une application qu'elle utilise) utilise les informations d'identification temporaires fournies par `GetSessionToken` pour appeler l'action `StopInstances` ou `TerminateInstances` Amazon EC2. 

   Pour obtenir un exemple d'un programme qui appelle `GetSessionToken`, consultez [Appels GetSessionToken avec authentification MFA](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken) ci-après dans ce document.

## Scénario : protection MFA des ressources disposant de politiques basées sur les ressources
<a name="MFAProtectedAPI-resource-policies"></a>

Dans ce scénario, vous êtes le propriétaire d'un compartiment S3, d'une file d'attente SQS ou d'une rubrique SNS. Vous devez vous assurer que tous les Compte AWS utilisateurs accédant à la ressource sont authentifiés par un dispositif MFA AWS . 

Ce scénario illustre un processus permettant de fournir une protection MFA entre comptes sans nécessiter que les utilisateurs endossent d'abord un rôle. Dans ce cas, l'utilisateur peut accéder à la ressource s'il répond à trois conditions : l'utilisateur doit être authentifié par l'authentification MFA, être en mesure d'obtenir des informations d'identification temporaires de `GetSessionToken` et disposer d'un compte approuvé par la politique de la ressource. 

Imaginons que vous vous trouvez dans le compte A et que vous créez un compartiment S3. Vous souhaitez accorder l'accès à ce compartiment à des utilisateurs appartenant à plusieurs entités différentes Comptes AWS, mais uniquement s'ils sont authentifiés à l'aide de la MFA.

Dans ce scénario, l'utilisatrice Anaya est une administratrice du compte A. L'utilisateur Nikhil est un utilisateur IAM du compte C.

1. Dans le compte A, Anaya crée un compartiment appelé `Account-A-bucket`.

1. Anaya ajoute la politique de compartiment au compartiment. La politique autorise n'importe quel utilisateur du compte A, du compte B ou du compte C à exécuter les actions `PutObject` et `DeleteObject` Amazon S3 dans le compartiment. La politique inclut une condition MFA. 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Principal": {"AWS": [
         "ACCOUNT-A-ID",
         "ACCOUNT-B-ID",
         "ACCOUNT-C-ID"
       ]},
       "Action": [
         "s3:PutObject",
         "s3:DeleteObject"
       ],
       "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------
**Note**  
Amazon S3 fournit une fonction de suppression MFA (MFA Delete) pour l'accès au compte *racine* (uniquement). Vous pouvez activer la fonction de suppression MFA d'Amazon S3 lorsque vous définissez l'état de la gestion des versions du compartiment. La fonction de suppression MFA d'Amazon S3 ne peut pas être appliquée à un utilisateur IAM et elle est gérée indépendamment de l'accès à l'API protégé par MFA. Un utilisateur IAM disposant des autorisations nécessaires pour supprimer un compartiment ne peut pas le faire si la fonction de suppression MFA Amazon S3 est activée. Pour plus d'informations sur la fonction Supprimer MFA d'Amazon S3, consultez la section [Supprimer MFA](https://docs.aws.amazon.com/AmazonS3/latest/dev/MultiFactorAuthenticationDelete.html).

1. Dans le compte C, un administrateur vérifie que l'utilisateur Nikhil est configuré avec un dispositif MFA AWS et qu'il connaît l'ID du dispositif. L'ID du périphérique est le numéro de série s'il s'agit d'un dispositif MFA matériel, ou l'ARN du périphérique s'il s'agit d'un dispositif MFA virtuel. 

1. Dans le compte C, Nikhil (ou une application qu'il exécute) appelle `GetSessionToken`. L'appel inclut l'ID ou l'ARN du dispositif MFA et le TOTP actuel que Nikhil obtient de ce périphérique. 

1. Nikhil (ou une application qu'il utilise) utilise les informations d'identification temporaires renvoyées par `GetSessionToken` pour appeler l'action `PutObject` Amazon S3 afin de télécharger un fichier dans `Account-A-bucket`. 

   Pour obtenir un exemple d'un programme qui appelle `GetSessionToken`, consultez [Appels GetSessionToken avec authentification MFA](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken) ci-après dans ce document.
**Note**  
Les informations d'identification temporaires renvoyées par `AssumeRole` ne fonctionnent pas dans ce cas. Bien que l'utilisateur puisse fournir les informations MFA lui permettant d'endosser un rôle, les informations d'identification temporaires renvoyées par `AssumeRole` n'incluent par les informations MFA. Ces informations sont requises pour satisfaire la condition MFA de la politique. 

# Exemple de code : demande d'informations d'identification avec l'authentification multifacteur
<a name="id_credentials_mfa_sample-code"></a>

Les exemples suivants montrent comment appeler les opérations `GetSessionToken` et `AssumeRole` et transmettre les paramètres d'authentification MFA. Aucune autorisation n'est requise pour appeler `GetSessionToken`, toutefois, vous devez disposer d'une politique vous permettant d'appeler `AssumeRole`. Les informations d'identification renvoyées sont ensuite utilisées afin de répertorier tous les compartiments S3 dans le compte.

## Appels GetSessionToken avec authentification MFA
<a name="MFAProtectedAPI-example-getsessiontoken"></a>

L'exemple suivant explique comment appeler `GetSessionToken` et transmettre les informations d'authentification MFA. Les informations d'identification de sécurité temporaires renvoyées par l'opération `GetSessionToken` sont ensuite utilisées pour répertorier tous les compartiments S3 dans le compte.

La politique associée à l'utilisateur exécutant ce code (ou à un groupe dont fait partie l'utilisateur) fournit les autorisations pour les informations d'identification temporaires renvoyées. Dans cet exemple de code, la politique doit autoriser l'utilisateur à demander l'opération `ListBuckets` Amazon S3. 

Les exemples de code suivants illustrent comment utiliser `GetSessionToken`.

------
#### [ CLI ]

**AWS CLI**  
**Pour obtenir un ensemble d’informations d’identification à court terme d’une identité IAM**  
La commande `get-session-token` suivante extrait un ensemble d’informations d’identification à court terme pour l’identité IAM qui effectue l’appel. Les informations d’identification obtenues peuvent être utilisées pour les requêtes où l’authentification multifactorielle (MFA) est requise par la politique. Les informations d’identification expirent 15 minutes après leur création.  

```
aws sts get-session-token \
    --duration-seconds 900 \
    --serial-number "YourMFADeviceSerialNumber" \
    --token-code 123456
```
Sortie :  

```
{
    "Credentials": {
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
        "SessionToken": "AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2020-05-19T18:06:10+00:00"
    }
}
```
Pour plus d’informations, consultez [Demande d’informations d’identification temporaires de sécurité](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken) dans le *Guide de l’utilisateur AWS IAM*.  
+  Pour plus de détails sur l'API, voir [GetSessionToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-session-token.html)la section *Référence des AWS CLI commandes*. 

------
#### [ PowerShell ]

**Outils pour PowerShell V4**  
**Exemple 1 : renvoie une instance `Amazon.RuntimeAWSCredentials` contenant des informations d’identification temporaires valables pendant une période définie. Les informations d’identification utilisées pour demander des informations d’identification temporaires sont déduites des paramètres par défaut actuels du shell. Pour spécifier d'autres informations d'identification, utilisez les SecretKey paramètres - ProfileName ou - AccessKey /-.**  

```
Get-STSSessionToken
```
**Sortie** :  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Exemple 2 : renvoie une instance `Amazon.RuntimeAWSCredentials` contenant des informations d’identification temporaires valides pour une heure. Les informations d’identification utilisées pour effectuer la demande sont obtenues à partir du profil spécifié.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**Sortie** :  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Exemple 3 : renvoie une instance `Amazon.RuntimeAWSCredentials` contenant des informations d’identification temporaires valables pendant une heure en utilisant le numéro d’identification du dispositif MFA associé au compte dont les informations d’identification sont spécifiées dans le profil « myprofilename » et la valeur fournie par le dispositif.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**Sortie** :  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  Pour plus de détails sur l'API, reportez-vous [GetSessionToken](https://docs.aws.amazon.com/powershell/v4/reference)à la section *Référence des Outils AWS pour PowerShell applets de commande (V4)*. 

**Outils pour PowerShell V5**  
**Exemple 1 : renvoie une instance `Amazon.RuntimeAWSCredentials` contenant des informations d’identification temporaires valables pendant une période définie. Les informations d’identification utilisées pour demander des informations d’identification temporaires sont déduites des paramètres par défaut actuels du shell. Pour spécifier d'autres informations d'identification, utilisez les SecretKey paramètres - ProfileName ou - AccessKey /-.**  

```
Get-STSSessionToken
```
**Sortie** :  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Exemple 2 : renvoie une instance `Amazon.RuntimeAWSCredentials` contenant des informations d’identification temporaires valides pour une heure. Les informations d’identification utilisées pour effectuer la demande sont obtenues à partir du profil spécifié.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**Sortie** :  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Exemple 3 : renvoie une instance `Amazon.RuntimeAWSCredentials` contenant des informations d’identification temporaires valables pendant une heure en utilisant le numéro d’identification du dispositif MFA associé au compte dont les informations d’identification sont spécifiées dans le profil « myprofilename » et la valeur fournie par le dispositif.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**Sortie** :  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  Pour plus de détails sur l'API, reportez-vous [GetSessionToken](https://docs.aws.amazon.com/powershell/v5/reference)à la section *Référence des Outils AWS pour PowerShell applets de commande (V5)*. 

------
#### [ Python ]

**Kit SDK for Python (Boto3)**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples). 
Obtenez un jeton de session en transmettant un jeton MFA et utilisez-le pour répertorier les compartiments Amazon S3 pour le compte.  

```
def list_buckets_with_session_token_with_mfa(mfa_serial_number, mfa_totp, sts_client):
    """
    Gets a session token with MFA credentials and uses the temporary session
    credentials to list Amazon S3 buckets.

    Requires an MFA device serial number and token.

    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an Amazon Resource Name (ARN).
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    if mfa_serial_number is not None:
        response = sts_client.get_session_token(
            SerialNumber=mfa_serial_number, TokenCode=mfa_totp
        )
    else:
        response = sts_client.get_session_token()
    temp_credentials = response["Credentials"]

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Buckets for the account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  Pour plus de détails sur l'API, consultez [GetSessionToken](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/GetSessionToken)le *AWS manuel de référence de l'API SDK for Python (Boto3*). 

------

## Appels AssumeRole avec authentification MFA
<a name="MFAProtectedAPI-example-assumerole"></a>

Les exemples suivants, expliquent comment appeler `AssumeRole` et transmettre les informations d'authentification MFA. Les informations d'identification de sécurité temporaires renvoyées par `AssumeRole` sont ensuite utilisées pour répertorier tous les compartiments Amazon S3 du compte.

Pour plus d'informations sur ce scénario, consultez [Scénario : protection MFA pour la délégation entre comptes](id_credentials_mfa_configure-api-require.md#MFAProtectedAPI-cross-account-delegation). 

Les exemples de code suivants illustrent comment utiliser `AssumeRole`.

------
#### [ .NET ]

**SDK pour .NET**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/STS#code-examples). 

```
using System;
using System.Threading.Tasks;
using Amazon;
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;

namespace AssumeRoleExample
{
    class AssumeRole
    {
        /// <summary>
        /// This example shows how to use the AWS Security Token
        /// Service (AWS STS) to assume an IAM role.
        ///
        /// NOTE: It is important that the role that will be assumed has a
        /// trust relationship with the account that will assume the role.
        ///
        /// Before you run the example, you need to create the role you want to
        /// assume and have it trust the IAM account that will assume that role.
        ///
        /// See https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html
        /// for help in working with roles.
        /// </summary>

        // A region property may be used if the profile or credentials loaded do not specify a region,
        // or to use a specific region.
        private static readonly RegionEndpoint REGION = RegionEndpoint.USWest2;

        static async Task Main()
        {
            // Create the SecurityToken client and then display the identity of the
            // default user.
            var roleArnToAssume = "arn:aws:iam::123456789012:role/testAssumeRole";

            var client = new Amazon.SecurityToken.AmazonSecurityTokenServiceClient(REGION);

            // Get and display the information about the identity of the default user.
            var callerIdRequest = new GetCallerIdentityRequest();
            var caller = await client.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"Original Caller: {caller.Arn}");

            // Create the request to use with the AssumeRoleAsync call.
            var assumeRoleReq = new AssumeRoleRequest()
            {
                DurationSeconds = 1600,
                RoleSessionName = "Session1",
                RoleArn = roleArnToAssume
            };

            var assumeRoleRes = await client.AssumeRoleAsync(assumeRoleReq);

            // Now create a new client based on the credentials of the caller assuming the role.
            var client2 = new AmazonSecurityTokenServiceClient(credentials: assumeRoleRes.Credentials, REGION);

            // Get and display information about the caller that has assumed the defined role.
            var caller2 = await client2.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"AssumedRole Caller: {caller2.Arn}");
        }
    }
}
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/sts-2011-06-15/AssumeRole)la section *Référence des AWS SDK pour .NET API*. 

------
#### [ Bash ]

**AWS CLI avec le script Bash**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples). 

```
###############################################################################
# function iecho
#
# This function enables the script to display the specified text only if
# the global variable $VERBOSE is set to true.
###############################################################################
function iecho() {
  if [[ $VERBOSE == true ]]; then
    echo "$@"
  fi
}

###############################################################################
# function errecho
#
# This function outputs everything sent to it to STDERR (standard error output).
###############################################################################
function errecho() {
  printf "%s\n" "$*" 1>&2
}

###############################################################################
# function sts_assume_role
#
# This function assumes a role in the AWS account and returns the temporary
#  credentials.
#
# Parameters:
#       -n role_session_name -- The name of the session.
#       -r role_arn -- The ARN of the role to assume.
#
# Returns:
#       [access_key_id, secret_access_key, session_token]
#     And:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function sts_assume_role() {
  local role_session_name role_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function sts_assume_role"
    echo "Assumes a role in the AWS account and returns the temporary credentials:"
    echo "  -n role_session_name -- The name of the session."
    echo "  -r role_arn -- The ARN of the role to assume."
    echo ""
  }

  while getopts n:r:h option; do
    case "${option}" in
      n) role_session_name=${OPTARG} ;;
      r) role_arn=${OPTARG} ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done

  response=$(aws sts assume-role \
    --role-session-name "$role_session_name" \
    --role-arn "$role_arn" \
    --output text \
    --query "Credentials.[AccessKeyId, SecretAccessKey, SessionToken]")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/goto/aws-cli/sts-2011-06-15/AssumeRole)la section *Référence des AWS CLI commandes*. 

------
#### [ C\$1\$1 ]

**SDK pour C\$1\$1**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/sts#code-examples). 

```
bool AwsDoc::STS::assumeRole(const Aws::String &roleArn,
                             const Aws::String &roleSessionName,
                             const Aws::String &externalId,
                             Aws::Auth::AWSCredentials &credentials,
                             const Aws::Client::ClientConfiguration &clientConfig) {
    Aws::STS::STSClient sts(clientConfig);
    Aws::STS::Model::AssumeRoleRequest sts_req;

    sts_req.SetRoleArn(roleArn);
    sts_req.SetRoleSessionName(roleSessionName);
    sts_req.SetExternalId(externalId);

    const Aws::STS::Model::AssumeRoleOutcome outcome = sts.AssumeRole(sts_req);

    if (!outcome.IsSuccess()) {
        std::cerr << "Error assuming IAM role. " <<
                  outcome.GetError().GetMessage() << std::endl;
    }
    else {
        std::cout << "Credentials successfully retrieved." << std::endl;
        const Aws::STS::Model::AssumeRoleResult result = outcome.GetResult();
        const Aws::STS::Model::Credentials &temp_credentials = result.GetCredentials();

        // Store temporary credentials in return argument.
        // Note: The credentials object returned by assumeRole differs
        // from the AWSCredentials object used in most situations.
        credentials.SetAWSAccessKeyId(temp_credentials.GetAccessKeyId());
        credentials.SetAWSSecretKey(temp_credentials.GetSecretAccessKey());
        credentials.SetSessionToken(temp_credentials.GetSessionToken());
    }

    return outcome.IsSuccess();
}
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/goto/SdkForCpp/sts-2011-06-15/AssumeRole)la section *Référence des AWS SDK pour C\$1\$1 API*. 

------
#### [ CLI ]

**AWS CLI**  
**Pour endosser un rôle**  
La commande `assume-role` suivante extrait un ensemble d’informations d’identification à court terme pour le rôle IAM `s3-access-example`.  

```
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/xaccounts3access \
    --role-session-name s3-access-example
```
Sortie :  

```
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:s3-access-example",
        "Arn": "arn:aws:sts::123456789012:assumed-role/xaccounts3access/s3-access-example"
    },
    "Credentials": {
        "SecretAccessKey": "9drTJvcXLB89EXAMPLELB8923FB892xMFI",
        "SessionToken": "AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=",
        "Expiration": "2016-03-15T00:05:07Z",
        "AccessKeyId": "ASIAJEXAMPLEXEG2JICEA"
    }
}
```
La sortie de la commande contient une clé d’accès, une clé secrète et un jeton de session que vous pouvez utiliser pour vous authentifier auprès d’ AWS.  
Pour l'utilisation de la AWS CLI, vous pouvez configurer un profil nommé associé à un rôle. Lorsque vous utilisez le profil, la AWS CLI appelle assume-role et gère les informations d'identification pour vous. Pour plus d'informations, consultez la section [Utiliser un rôle IAM dans la AWS CLI du](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html) *Guide de l'utilisateur de la AWS CLI*.  
+  Pour plus de détails sur l'API, voir [AssumeRole](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)la section *Référence des AWS CLI commandes*. 

------
#### [ Java ]

**SDK pour Java 2.x**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/sts#code-examples). 

```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.sts.StsClient;
import software.amazon.awssdk.services.sts.model.AssumeRoleRequest;
import software.amazon.awssdk.services.sts.model.StsException;
import software.amazon.awssdk.services.sts.model.AssumeRoleResponse;
import software.amazon.awssdk.services.sts.model.Credentials;
import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.util.Locale;

/**
 * To make this code example work, create a Role that you want to assume.
 * Then define a Trust Relationship in the AWS Console. You can use this as an
 * example:
 *
 * {
 * "Version":"2012-10-17",		 	 	 
 * "Statement": [
 * {
 * "Effect": "Allow",
 * "Principal": {
 * "AWS": "<Specify the ARN of your IAM user you are using in this code example>"
 * },
 * "Action": "sts:AssumeRole"
 * }
 * ]
 * }
 *
 * For more information, see "Editing the Trust Relationship for an Existing
 * Role" in the AWS Directory Service guide.
 *
 * Also, set up your development environment, including your credentials.
 *
 * For information, see this documentation topic:
 *
 * https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
 */
public class AssumeRole {
    public static void main(String[] args) {
        final String usage = """

                Usage:
                    <roleArn> <roleSessionName>\s

                Where:
                    roleArn - The Amazon Resource Name (ARN) of the role to assume (for example, arn:aws:iam::000008047983:role/s3role).\s
                    roleSessionName - An identifier for the assumed role session (for example, mysession).\s
                """;

        if (args.length != 2) {
            System.out.println(usage);
            System.exit(1);
        }

        String roleArn = args[0];
        String roleSessionName = args[1];
        Region region = Region.US_EAST_1;
        StsClient stsClient = StsClient.builder()
                .region(region)
                .build();

        assumeGivenRole(stsClient, roleArn, roleSessionName);
        stsClient.close();
    }

    public static void assumeGivenRole(StsClient stsClient, String roleArn, String roleSessionName) {
        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();

            // Display the time when the temp creds expire.
            Instant exTime = myCreds.expiration();
            String tokenInfo = myCreds.sessionToken();

            // Convert the Instant to readable date.
            DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT)
                    .withLocale(Locale.US)
                    .withZone(ZoneId.systemDefault());

            formatter.format(exTime);
            System.out.println("The token " + tokenInfo + "  expires on " + exTime);

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }
}
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/sts-2011-06-15/AssumeRole)la section *Référence des AWS SDK for Java 2.x API*. 

------
#### [ JavaScript ]

**SDK pour JavaScript (v3)**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/sts#code-examples). 
Créez le client.  

```
import { STSClient } from "@aws-sdk/client-sts";
// Set the AWS Region.
const REGION = "us-east-1";
// Create an AWS STS service client object.
export const client = new STSClient({ region: REGION });
```
Assumez le rôle IAM.  

```
import { AssumeRoleCommand } from "@aws-sdk/client-sts";

import { client } from "../libs/client.js";

export const main = async () => {
  try {
    // Returns a set of temporary security credentials that you can use to
    // access Amazon Web Services resources that you might not normally
    // have access to.
    const command = new AssumeRoleCommand({
      // The Amazon Resource Name (ARN) of the role to assume.
      RoleArn: "ROLE_ARN",
      // An identifier for the assumed role session.
      RoleSessionName: "session1",
      // The duration, in seconds, of the role session. The value specified
      // can range from 900 seconds (15 minutes) up to the maximum session
      // duration set for the role.
      DurationSeconds: 900,
    });
    const response = await client.send(command);
    console.log(response);
  } catch (err) {
    console.error(err);
  }
};
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/sts/command/AssumeRoleCommand)la section *Référence des AWS SDK pour JavaScript API*. 

**SDK pour JavaScript (v2)**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascript/example_code/sts#code-examples). 

```
// Load the AWS SDK for Node.js
const AWS = require("aws-sdk");
// Set the region
AWS.config.update({ region: "REGION" });

var roleToAssume = {
  RoleArn: "arn:aws:iam::123456789012:role/RoleName",
  RoleSessionName: "session1",
  DurationSeconds: 900,
};
var roleCreds;

// Create the STS service object
var sts = new AWS.STS({ apiVersion: "2011-06-15" });

//Assume Role
sts.assumeRole(roleToAssume, function (err, data) {
  if (err) console.log(err, err.stack);
  else {
    roleCreds = {
      accessKeyId: data.Credentials.AccessKeyId,
      secretAccessKey: data.Credentials.SecretAccessKey,
      sessionToken: data.Credentials.SessionToken,
    };
    stsGetCallerIdentity(roleCreds);
  }
});

//Get Arn of current identity
function stsGetCallerIdentity(creds) {
  var stsParams = { credentials: creds };
  // Create STS service object
  var sts = new AWS.STS(stsParams);

  sts.getCallerIdentity({}, function (err, data) {
    if (err) {
      console.log(err, err.stack);
    } else {
      console.log(data.Arn);
    }
  });
}
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/goto/AWSJavaScriptSDK/sts-2011-06-15/AssumeRole)la section *Référence des AWS SDK pour JavaScript API*. 

------
#### [ PowerShell ]

**Outils pour PowerShell V4**  
**Exemple 1 : renvoie un ensemble d'informations d'identification temporaires (clé d'accès, clé secrète et jeton de session) qui peuvent être utilisées pendant une heure pour accéder à AWS des ressources auxquelles l'utilisateur demandeur n'a pas normalement accès. Les informations d’identification renvoyées disposent des autorisations autorisées par la stratégie d’accès du rôle assumé et par la politique fournie (vous ne pouvez pas utiliser la politique fournie pour accorder des autorisations supérieures à celles définies par la stratégie d’accès du rôle assumé).**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**Exemple 2 : renvoie un ensemble d’informations d’identification temporaires, valides pendant une heure, dotées des mêmes autorisations que celles définies dans la stratégie d’accès du rôle assumé.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**Exemple 3 : renvoie un ensemble d’informations d’identification temporaires fournissant le numéro de série et le jeton généré par une MFA associée aux informations d’identification de l’utilisateur utilisées pour exécuter l’applet de commande.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**Exemple 4 : renvoie un ensemble d’informations d’identification temporaires qui ont endossé un rôle défini dans le compte d’un client. Pour chaque rôle que le tiers peut assumer, le compte client doit créer un rôle à l'aide d'un identifiant qui doit être transmis dans le ExternalId paramètre - chaque fois que le rôle est assumé.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  Pour plus de détails sur l'API, reportez-vous [AssumeRole](https://docs.aws.amazon.com/powershell/v4/reference)à la section *Référence des Outils AWS pour PowerShell applets de commande (V4)*. 

**Outils pour PowerShell V5**  
**Exemple 1 : renvoie un ensemble d'informations d'identification temporaires (clé d'accès, clé secrète et jeton de session) qui peuvent être utilisées pendant une heure pour accéder à AWS des ressources auxquelles l'utilisateur demandeur n'a pas normalement accès. Les informations d’identification renvoyées disposent des autorisations autorisées par la stratégie d’accès du rôle assumé et par la politique fournie (vous ne pouvez pas utiliser la politique fournie pour accorder des autorisations supérieures à celles définies par la stratégie d’accès du rôle assumé).**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**Exemple 2 : renvoie un ensemble d’informations d’identification temporaires, valides pendant une heure, dotées des mêmes autorisations que celles définies dans la stratégie d’accès du rôle assumé.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**Exemple 3 : renvoie un ensemble d’informations d’identification temporaires fournissant le numéro de série et le jeton généré par une MFA associée aux informations d’identification de l’utilisateur utilisées pour exécuter l’applet de commande.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**Exemple 4 : renvoie un ensemble d’informations d’identification temporaires qui ont endossé un rôle défini dans le compte d’un client. Pour chaque rôle que le tiers peut assumer, le compte client doit créer un rôle à l'aide d'un identifiant qui doit être transmis dans le ExternalId paramètre - chaque fois que le rôle est assumé.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  Pour plus de détails sur l'API, reportez-vous [AssumeRole](https://docs.aws.amazon.com/powershell/v5/reference)à la section *Référence des Outils AWS pour PowerShell applets de commande (V5)*. 

------
#### [ Python ]

**Kit SDK for Python (Boto3)**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples). 
Assumez un rôle IAM qui nécessite un jeton MFA et utilisez des informations d’identification temporaires pour répertorier les compartiments Amazon S3 pour le compte.  

```
def list_buckets_from_assumed_role_with_mfa(
    assume_role_arn, session_name, mfa_serial_number, mfa_totp, sts_client
):
    """
    Assumes a role from another account and uses the temporary credentials from
    that role to list the Amazon S3 buckets that are owned by the other account.
    Requires an MFA device serial number and token.

    The assumed role must grant permission to list the buckets in the other account.

    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an ARN.
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    response = sts_client.assume_role(
        RoleArn=assume_role_arn,
        RoleSessionName=session_name,
        SerialNumber=mfa_serial_number,
        TokenCode=mfa_totp,
    )
    temp_credentials = response["Credentials"]
    print(f"Assumed role {assume_role_arn} and got temporary credentials.")

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Listing buckets for the assumed role's account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  Pour plus de détails sur l'API, consultez [AssumeRole](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/AssumeRole)le *AWS manuel de référence de l'API SDK for Python (Boto3*). 

------
#### [ Ruby ]

**Kit SDK pour Ruby**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples). 

```
  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/sts-2011-06-15/AssumeRole)la section *Référence des AWS SDK pour Ruby API*. 

------
#### [ Rust ]

**SDK pour Rust**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/sts/#code-examples). 

```
async fn assume_role(config: &SdkConfig, role_name: String, session_name: Option<String>) {
    let provider = aws_config::sts::AssumeRoleProvider::builder(role_name)
        .session_name(session_name.unwrap_or("rust_sdk_example_session".into()))
        .configure(config)
        .build()
        .await;

    let local_config = aws_config::from_env()
        .credentials_provider(provider)
        .load()
        .await;
    let client = Client::new(&local_config);
    let req = client.get_caller_identity();
    let resp = req.send().await;
    match resp {
        Ok(e) => {
            println!("UserID :               {}", e.user_id().unwrap_or_default());
            println!("Account:               {}", e.account().unwrap_or_default());
            println!("Arn    :               {}", e.arn().unwrap_or_default());
        }
        Err(e) => println!("{:?}", e),
    }
}
```
+  Pour plus de détails sur l'API, voir [AssumeRole](https://docs.rs/aws-sdk-sts/latest/aws_sdk_sts/client/struct.Client.html#method.assume_role)la section de *référence de l'API AWS SDK for Rust*. 

------
#### [ Swift ]

**Kit SDK pour Swift**  
 Il y en a plus sur GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift/example_code/iam#code-examples). 

```
import AWSSTS

    public func assumeRole(role: IAMClientTypes.Role, sessionName: String)
        async throws -> STSClientTypes.Credentials
    {
        let input = AssumeRoleInput(
            roleArn: role.arn,
            roleSessionName: sessionName
        )
        do {
            let output = try await stsClient.assumeRole(input: input)

            guard let credentials = output.credentials else {
                throw ServiceHandlerError.authError
            }

            return credentials
        } catch {
            print("Error assuming role: ", dump(error))
            throw error
        }
    }
```
+  Pour plus de détails sur l'API, reportez-vous [AssumeRole](https://sdk.amazonaws.com/swift/api/awssts/latest/documentation/awssts/stsclient/assumerole(input:))à la section *AWS SDK pour la référence de l'API Swift*. 

------

# Informations d’identification spécifiques au service pour les utilisateurs IAM
<a name="id_credentials_service-specific-creds"></a>

Les informations d'identification spécifiques à un service sont des mécanismes d'authentification spécialisés conçus pour des services spécifiques AWS . Ces informations d'identification fournissent une authentification simplifiée par rapport aux AWS informations d'identification standard et sont adaptées aux exigences d'authentification de chaque AWS service. Contrairement aux clés d'accès, qui peuvent être utilisées pour plusieurs AWS services, les informations d'identification spécifiques à un service sont conçues pour être utilisées uniquement avec le service pour lequel elles ont été créées. Cette approche ciblée améliore la sécurité en limitant la portée des informations d’identification.

Les informations d’identification spécifiques à un service se composent généralement d’un nom d’utilisateur et d’un mot de passe ou de clés d’API spécialisées dont le format est conforme aux exigences du service concerné. Lorsque vous créez des informations d’identification spécifiques à un service, celles-ci sont actives par défaut et peuvent être utilisées immédiatement. Vous pouvez avoir un maximum de deux ensembles d’informations d’identification spécifiques au service pour chaque service pris en charge par utilisateur IAM. Cette limite vous permet de conserver un ensemble actif tout en passant à un nouveau set en cas de besoin. AWS prend actuellement en charge les informations d'identification spécifiques au service pour les services suivants :

## Quand utiliser les informations d'identification spécifiques au service
<a name="id_credentials_service-specific-creds-usecase"></a>

Les informations d'identification spécifiques au service sont destinées à être compatibles avec des bibliothèques SDKs, des outils ou des applications tiers qui ne sont pas compatibles nativement avec les AWS informations d'identification, AWS SDKs ou. AWS APIs Ces cas d'utilisation incluent la migration vers des AWS services à partir d'une infrastructure auto-hébergée ou de services hébergés par d'autres fournisseurs.

Lorsque vous partez de zéro, et dans la mesure du possible, nous vous recommandons d'utiliser des informations d'identification AWS temporaires, telles que celles fournies par un rôle IAM, pour vous authentifier auprès d'un AWS service à l'aide d'un AWS SDK ou d'une bibliothèque qui prend en charge AWS les informations d'identification temporaires.

## Changement des informations d’identification spécifiques au service
<a name="id_credentials_service-specific-creds-rotation"></a>

En tant que bonne pratique en matière de sécurité, renouvelez régulièrement les informations d’identification spécifiques aux services. Pour changer les informations d’identification sans perturber vos applications :

1. Créez un deuxième ensemble d’informations d’identification spécifiques au service pour le même service et le même utilisateur IAM

1. Mettez à jour toutes les applications afin qu’elles utilisent les nouvelles informations d’identification et vérifiez qu’elles fonctionnent correctement

1. Modifiez le statut des informations d’identification d’origine en « Inactif »

1. Vérifiez que toutes les applications fonctionnent toujours correctement

1. Supprimez les informations d’identification spécifiques au service inactif lorsque vous êtes certain qu’elles ne sont plus nécessaires.

## Surveillance des informations d’identification spécifiques au service
<a name="id_credentials_service-specific-creds-monitoring"></a>

Vous pouvez l'utiliser AWS CloudTrail pour surveiller l'utilisation des informations d'identification spécifiques au service dans votre AWS compte. Pour consulter les CloudTrail événements liés à l'utilisation des informations d'identification spécifiques à un service, consultez les CloudTrail journaux des événements provenant du service où les informations d'identification sont utilisées. Pour de plus amples informations, veuillez consulter [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md).

Pour plus de sécurité, envisagez de configurer des CloudWatch alarmes pour vous avertir de modèles d'utilisation spécifiques des informations d'identification susceptibles d'indiquer un accès non autorisé ou d'autres problèmes de sécurité. Pour plus d'informations, consultez la section [Surveillance des fichiers CloudTrail CloudWatch journaux avec Amazon Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html) dans le *guide de AWS CloudTrail l'utilisateur*.

Les rubriques suivantes fournissent des informations sur les informations d’identification spécifiques au service.

**Topics**
+ [Quand utiliser les informations d'identification spécifiques au service](#id_credentials_service-specific-creds-usecase)
+ [Changement des informations d’identification spécifiques au service](#id_credentials_service-specific-creds-rotation)
+ [Surveillance des informations d’identification spécifiques au service](#id_credentials_service-specific-creds-monitoring)
+ [Clés d'API pour Amazon Bedrock et Amazon CloudWatch Logs](id_credentials_bedrock_cloudwatchlogs.md)
+ [Utilisation d’IAM avec Amazon Keyspaces (pour Apache Cassandra)](id_credentials_keyspaces.md)

# Clés d'API pour Amazon Bedrock et Amazon CloudWatch Logs
<a name="id_credentials_bedrock_cloudwatchlogs"></a>

**Note**  
Les clés d'API Amazon CloudWatch Logs sont actuellement disponibles en version préliminaire et seront généralement disponibles dans les semaines à venir. Les clés d'API Amazon CloudWatch Logs ressemblent étroitement aux clés d'API à long terme d'Amazon Bedrock décrites sur cette page. Pour en savoir plus sur les clés d'API à long terme d'Amazon CloudWatch Logs, consultez [Envoyer des journaux à Amazon CloudWatch Logs à l'aide du point de terminaison HLC](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_HLC_Endpoint.html).

Amazon Bedrock est un service entièrement géré qui propose des modèles de base provenant des principales entreprises d’IA et d’Amazon. Vous pouvez accéder à Amazon Bedrock via AWS Management Console et par programmation à l'aide de l' AWS CLI API ou. AWS Lorsque vous effectuez des demandes programmatiques auprès d’Amazon Bedrock, vous pouvez vous authentifier à l’aide d’[informations d’identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html) ou de clés API Amazon Bedrock. Amazon Bedrock prend en charge deux types de clés d’API :
+ **Clés d'API à** court terme — Une clé d'API à court terme est une URL pré-signée qui utilise AWS la version 4 de Signature. Les clés API à court terme partagent les mêmes autorisations et la même date d’expiration que les informations d’identification de l’identité qui génère la clé d’API. Elles sont valables pendant 12 heures maximum ou jusqu’à la fin de votre session sur la console, selon la durée la plus courte. Vous pouvez utiliser la console Amazon Bedrock, le package Python `aws-bedrock-token-generator` et les packages d’autres langages de programmation pour générer des clés d’API à court terme. Pour plus d’informations, consultez la section [Générer des clés d’API Amazon Bedrock pour accéder facilement à l’API Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html) dans le *Guide de l’utilisateur Amazon Bedrock*.
+ **Clés d’API à long terme **: les clés d’API à long terme sont associées à un utilisateur IAM et générées à l’aide d’[informations d’identification](id_credentials_service-specific-creds.md) spécifiques au service IAM. Ces informations d’identification sont conçues pour être utilisées uniquement avec Amazon Bedrock, ce qui renforce la sécurité en limitant leur portée. Vous pouvez définir une date d’expiration pour la clé d’API à long terme. Vous pouvez utiliser la console IAM ou Amazon Bedrock, la AWS CLI ou l' AWS API pour générer des clés d'API à long terme.

Un utilisateur IAM peut disposer d’un maximum de deux clés d’API à long terme pour Amazon Bedrock, ce qui vous aide à mettre en œuvre des pratiques sécurisées de rotation des clés. 

Lorsque vous générez une clé d'API à long terme, la politique AWS gérée [AmazonBedrockLimitedAccess](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonBedrockLimitedAccess)est automatiquement attachée à l'utilisateur IAM. Cette politique accorde l’accès aux principales opérations d’API Amazon Bedrock. Si vous avez besoin d’un accès supplémentaire à Amazon Bedrock, vous pouvez modifier les autorisations de l’utilisateur IAM. Pour plus d’informations sur la modification des autorisations, consultez [Ajout et suppression d'autorisations basées sur l'identité IAM](access_policies_manage-attach-detach.md). Pour plus d’informations sur l’utilisation d’une clé Amazon Bedrock, consultez la section [Utilisation d’une clé d’API Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-use.html) dans le *Guide de l’utilisateur Amazon Bedrock*.

**Note**  
Les clés d’API à long terme présentent un risque de sécurité plus élevé que les clés d’API à court terme. Nous vous recommandons d’utiliser des clés d’API à court terme ou des informations d’identification de sécurité temporaires si possible. Si vous utilisez des clés API à long terme, nous vous recommandons de mettre en place des pratiques régulières de rotation des clés.

## Conditions préalables
<a name="id_credentials_bedrock_prerequisites"></a>

Avant de pouvoir générer une clé d’API Amazon Bedrock à long terme à partir de la console IAM, vous devez remplir les conditions préalables suivantes :
+ Un utilisateur IAM à associer à la clé d’API à long terme. Pour plus d’informations sur la création d’un utilisateur IAM, consultez [Créez un utilisateur IAM dans votre Compte AWS](id_users_create.md).
+ Assurez-vous de disposer des autorisations de politique IAM suivantes pour gérer les informations d’identification spécifiques au service pour un utilisateur IAM. L’exemple de politique accorde l’autorisation de créer, répertorier, mettre à jour, supprimer et réinitialiser les informations d’identification spécifiques au service. Remplacez la valeur `username` dans l’élément Resource par le nom de l’utilisateur IAM pour lequel vous allez générer des clés d’API Amazon Bedrock :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "ManageBedrockServiceSpecificCredentials",
              "Effect": "Allow",
              "Action": [
                  "iam:CreateServiceSpecificCredential",
                  "iam:ListServiceSpecificCredentials",
                  "iam:UpdateServiceSpecificCredential",
                  "iam:DeleteServiceSpecificCredential",
                  "iam:ResetServiceSpecificCredential"
              ],
              "Resource": "arn:aws:iam::*:user/username"
          }
      ]
  }
  ```

------

## Génération d’une clé d’API à long terme pour Amazon Bedrock (console)
<a name="id_credentials_bedrock_console_create"></a>

**Pour générer une clé d’API à long terme pour Amazon Bedrock (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console IAM, sélectionnez **Utilisateurs**.

1. Sélectionnez l’utilisateur IAM pour lequel vous souhaitez générer des clés d’API Amazon Bedrock à long terme.

1. Choisissez l’onglet **Informations d’identification de sécurité.**

1. Dans la section **Clés d’API pour Amazon Bedrock**, choisissez **Générer une clé d’API**.

1. Pour **Epiration de la clé d’API**, effectuez l’une des actions suivantes :
   + Sélectionnez une durée d’expiration de la clé d’API de **1**, **5**, **30**, **90** ou **365** jours.
   + Choisissez **Durée personnalisée** pour spécifier une date d’expiration personnalisée pour la clé d’API.
   + Sélectionnez **Ne jamais expirer** (non recommandé)

1. Choisissez **Générer une clé d’API**.

1. Copiez ou téléchargez votre clé d’API. C’est le seul moment où vous pouvez voir la valeur de la clé API.
**Important**  
Stockez votre clé d’API en toute sécurité. Une fois la boîte de dialogue fermée, vous ne pouvez plus récupérer la clé d’API. Si vous perdez ou oubliez votre clé d’accès secrète, vous ne pourrez pas la récupérer. Créez plutôt une nouvelle clé d’accès et désactivez l’ancienne.

## Génération d’une clé d’API à long terme pour Amazon Bedrock (AWS CLI)
<a name="id_credentials_bedrock_cli_create"></a>

Pour générer une clé d'API à long terme Amazon Bedrock à l'aide de AWS CLI, procédez comme suit :

1. Créez un utilisateur IAM qui sera utilisé avec Amazon Bedrock à l’aide de la commande [create-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-user.html) :

   ```
   aws iam create-user \
       --user-name BedrockAPIKey_1
   ```

1. Associez la politique AWS gérée `AmazonBedrockLimitedAccess` à l'utilisateur Amazon Bedrock IAM à l'aide de la [ attach-user-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-user-policy.html)commande :

   ```
   aws iam attach-user-policy --user-name BedrockAPIKey_1 \
       --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess
   ```

1. Générez la clé d'API à long terme Amazon Bedrock à l'aide de la [ create-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-service-specific-credential.html)commande. Pour la durée de validité des informations d’identification, vous pouvez spécifier une valeur comprise entre 1 et 36 600 jours. Si vous ne spécifiez pas de durée de validité, la clé d’API n’expirera pas.

   Pour générer une clé d’API à long terme avec une expiration de 30 jours, procédez comme suit :

   ```
   aws iam create-service-specific-credential \
       --user-name BedrockAPIKey_1 \
       --service-name bedrock.amazonaws.com \
       --credential-age-days 30
   ```

La valeur `ServiceApiKeyValue` renvoyée dans la réponse est votre clé d’API Amazon Bedrock à long terme. Stockez la valeur `ServiceApiKeyValue` en toute sécurité, car vous ne pourrez pas la récupérer ultérieurement.

### Répertorier les clés d’API à long terme (AWS CLI)
<a name="id_credentials_bedrock_cli_list"></a>

Pour répertorier les métadonnées des clés d'API à long terme d'Amazon Bedrock pour un utilisateur spécifique, utilisez la [ list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html)commande avec le `--user-name` paramètre :

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --user-name BedrockAPIKey_1
```

Pour répertorier toutes les métadonnées des clés d'API à long terme Amazon Bedrock présentes dans le compte, utilisez la [ list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html)commande avec le `--all-users` paramètre :

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --all-users
```

### Mettre à jour le statut de la clé d’API à long terme (AWS CLI)
<a name="id_credentials_bedrock_cli_update"></a>

Pour mettre à jour le statut d'une clé d'API à long terme pour Amazon Bedrock, utilisez la [ update-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-service-specific-credential.html)commande :

```
aws iam update-service-specific-credential \
    --user-name "BedrockAPIKey_1" \
    --service-specific-credential-id "ACCA1234EXAMPLE1234" \
    --status Inactive|Active
```

## Génération d'une clé d'API à long terme pour Amazon Bedrock (AWS API)
<a name="id_credentials_bedrock_api"></a>

Vous pouvez utiliser les opérations d’API suivantes pour générer et gérer des clés d’API à long terme pour Amazon Bedrock :
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html) 

# Utilisation d’IAM avec Amazon Keyspaces (pour Apache Cassandra)
<a name="id_credentials_keyspaces"></a>

Amazon Keyspaces (pour Apache Cassandra) est un service de base de données compatible avec Apache Cassandra, évolutif, hautement disponible et géré. Vous pouvez accéder à Amazon Keyspaces par le biais du ou par AWS Management Console programme. Pour accéder à Amazon Keyspaces de manière programmatique avec des informations d'identification spécifiques au service, vous pouvez utiliser `cqlsh` ou des pilotes Cassandra open source. Les *informations d'identification spécifiques à un service* comprennent un nom d'utilisateur et un mot de passe similaires à ceux que Cassandra utilise pour l'authentification et la gestion des accès. Vous pouvez avoir un maximum de deux ensembles d'informations d’identification spécifiques au service pour chaque service pris en charge par utilisateur.

Pour accéder à Amazon Keyspaces par programmation à l'aide de clés d' AWS accès, vous pouvez utiliser le AWS SDK, le AWS Command Line Interface (AWS CLI) ou les pilotes Cassandra open source avec le plugin SigV4. Pour en savoir plus, consultez la section [Création et configuration des AWS informations d'identification pour Amazon Keyspaces](https://docs.aws.amazon.com//keyspaces/latest/devguide/access.credentials.html) (pour Apache Cassandra) dans le guide du développeur Amazon *Keyspaces (pour Apache Cassandra*).

**Note**  
Si vous envisagez d'interagir avec Amazon Keyspaces uniquement via la console, vous n'avez pas besoin de générer des informations d'identification spécifiques au service. Pour de plus amples informations, veuillez consulter la rubrique [Accès à Amazon Keyspaces à l'aide de la console](https://docs.aws.amazon.com/keyspaces/latest/devguide/console_keyspaces.html) dans le *Guide du développeur Amazon Keyspaces (pour Apache Cassandra)*.

Pour de plus amples informations sur les autorisations requises pour accéder à Amazon Keyspaces, veuillez consulter [Exemples de politiques basées sur l'identité Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console) dans le *Manuel du développeur Amazon Keyspaces (for Apache Cassandra)*.

## Génération d'informations d'identification Amazon Keyspaces (console)
<a name="keyspaces_credentials_console"></a>

Vous pouvez utiliser le AWS Management Console pour générer des informations d'identification Amazon Keyspaces (pour Apache Cassandra) pour vos utilisateurs IAM.

**Pour générer des informations d'identification spécifiques au service Amazon Keyspaces (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Users (Utilisateurs)**, puis choisissez le nom de l'utilisateur ayant besoin d'informations d'identification.

1. Dans l'onglet **Security Credentials** (informations d'identification de sécurité) sous **Credentials for Amazon Keyspaces (informations d’identification pour Amazon Keyspaces) (pour Apache Cassandra) (MCS)** sélectionnez **Generate credentials** (générer des informations d'identification).

1. Vos informations d'identification spécifiques au service sont disponibles. C'est la seule fois que vous pouvez afficher ou télécharger le mot de passe. Vous ne pourrez pas la récupérer plus tard. Cependant, vous pouvez réinitialiser votre mot de passe à tout moment. Enregistrez cet utilisateur et ce mot de passe dans un emplacement sécurisé, car vous en aurez besoin plus tard.

## Génération d'informations d'identification Amazon Keyspaces (AWS CLI)
<a name="keyspaces_credentials_cli"></a>

Vous pouvez utiliser le AWS CLI pour générer des informations d'identification Amazon Keyspaces (pour Apache Cassandra) pour vos utilisateurs IAM.

**Pour générer des informations d'identification spécifiques au service Amazon Keyspaces (AWS CLI)**
+ Utilisez la commande suivante :
  + [était iam create-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-specific-credential.html)

## Génération d'informations d'identification Amazon Keyspaces (API)AWS
<a name="keyspaces_credentials_api"></a>

Vous pouvez utiliser l' AWS API pour générer des informations d'identification Amazon Keyspaces (pour Apache Cassandra) pour vos utilisateurs IAM.

**Pour générer des informations d'identification (API) spécifiques au service Amazon Keyspaces AWS**
+ Complétez l'opération suivante :
  + [CreateServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 

# Trouver les AWS informations d'identification non utilisées
<a name="id_credentials_finding-unused"></a>

Pour renforcer la sécurité de votre compte Compte AWS, supprimez les informations d'identification utilisateur IAM (c'est-à-dire les mots de passe et les clés d'accès) qui ne sont pas nécessaires. Par exemple, lorsque des utilisateurs quittent votre organisation ou n'ont plus besoin d'y AWS accéder, recherchez les informations d'identification qu'ils utilisaient et assurez-vous qu'elles ne sont plus opérationnelles. Idéalement, supprimez les informations d'identification qui ne sont plus requises. Il est toujours possible de les recréer ultérieurement, si nécessaire. Vous devez au moins modifier le mot de passe ou désactiver les clés d'accès afin que les anciens utilisateurs ne soient plus en mesure de s'en servir.

La signification du mot *inutilisées* peut bien sûr varier : cela indique généralement que les informations d'identification n'ont pas été utilisées au cours d'un laps de temps spécifié.

## Recherche de mots de passe inutilisés
<a name="finding-unused-passwords"></a>

Vous pouvez utiliser le AWS Management Console pour consulter les informations relatives à l'utilisation des mots de passe par vos utilisateurs. Si vous disposez d'un nombre volumineux d'utilisateurs, vous pouvez utiliser la console pour télécharger un rapport d'informations d'identification contenant des données sur la dernière utilisation du mot de passe de console par chaque utilisateur. Vous pouvez également accéder aux informations à partir de l'API AWS CLI ou de l'API IAM.

**Pour rechercher les mots de passe inutilisés (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **utilisateurs**.

1. Au besoin, ajoutez la colonne **Console last sign-in (Dernière connexion à la console)** à la table des utilisateurs :

   1. Au-dessus de la table à l'extrême droite, choisissez l'icône des paramètres (![\[Settings icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. Dans **Sélectionner les colonnes visibles**, sélectionnez **Dernière connexion à la console**.

   1. Choisissez **Confirmer** pour revenir à la liste des utilisateurs.

1. La colonne **Dernière connexion à la console** indique la date à laquelle l'utilisateur s'est connecté pour la dernière fois AWS via la console. Ces informations vous permettent de rechercher les utilisateurs avec mots de passe ne s'étant pas connectés depuis une période donnée. La colonne affiche **Jamais** pour les utilisateurs avec mots de passe ne s'étant jamais connectés. **Aucun** indique les utilisateurs sans mot de passe. Les mots de passe qui n'ont pas été utilisés récemment peuvent être supprimés.
**Important**  
En raison d'un problème de service, les données de dernière d'utilisation du mot de passe n'incluent pas l'utilisation du mot de passe entre le 3 mai 2018 et le 23 mai 2018 22:50 14:08 PDT (heure du Pacifique). [Cela affecte les dates de [dernière connexion](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) affichées dans la console IAM et les dates de dernière utilisation du mot de passe dans le [rapport d'identification IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html), et renvoyées par l'opération d'API. GetUser ](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) Si des utilisateurs se sont connectés au cours de la période concernée, la date de dernière d'utilisation du mot de passe renvoyée est la date de la dernière connexion de l'utilisateur avant le 3 mai 2018. Pour les utilisateurs qui se sont connectés après le 23 mai 2018 14:08 PDT, la date de dernière utilisation du mot de passe renvoyée est exacte.  
Si vous utilisez les informations de dernière utilisation du mot de passe pour identifier les informations d'identification non utilisées à supprimer, par exemple en supprimant des utilisateurs qui ne se AWS sont pas connectés au cours des 90 derniers jours, nous vous recommandons d'ajuster votre fenêtre d'évaluation pour inclure les dates postérieures au 23 mai 2018. Par ailleurs, si vos utilisateurs utilisent des clés d'accès pour accéder AWS par programmation, vous pouvez vous référer aux dernières informations utilisées sur les clés d'accès, car elles sont exactes pour toutes les dates. 

**Pour rechercher les mots de passe inutilisés en téléchargeant le rapport d'informations d'identification (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Rapport sur les informations d'identification**.

1. Choisissez **Télécharger le rapport** pour télécharger un fichier CSV nommé `status_reports_<date>T<time>.csv`. La cinquième colonne contient la colonne `password_last_used` avec les dates ou l'une des mentions suivantes :
   + **N/A** : utilisateurs auxquels aucun mot de passe n'est affecté.
   + **no\$1information** : utilisateurs n'ayant pas utilisé leur mot de passe depuis le 20 octobre 2014, date à laquelle IAM a commencé le suivi de l'âge des mots de passe.

**Pour rechercher des mots de passe inutilisés (AWS CLI)**  
Exécutez la commande suivante pour rechercher les mots de passe inutilisés :
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)` retourne une liste d'utilisateurs, avec une valeur `PasswordLastUsed` pour chacun. Si la valeur est manquante, cela signifie que l'utilisateur ne dispose pas de mot de passe ou qu'il ne l'a pas utilisé depuis le 20 octobre 2014, date à laquelle IAM a commencé le suivi de l'âge des mots de passe.

**Pour trouver les mots de passe inutilisés (AWS API)**  
Appelez l'opération suivante pour rechercher les mots de passe inutilisés :
+  ` [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` retourne une collection d'utilisateurs, avec une valeur `<PasswordLastUsed>` pour chacun. Si la valeur est manquante, cela signifie que l'utilisateur ne dispose pas de mot de passe ou qu'il ne l'a pas utilisé depuis le 20 octobre 2014, date à laquelle IAM a commencé le suivi de l'âge des mots de passe.

Pour plus d'informations sur les commandes à utiliser pour le téléchargement du rapport d'informations d'identification, consultez [Obtention de rapports d'informations d'identification (AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi).

## Recherche des clés d'accès inutilisées
<a name="finding-unused-access-keys"></a>

Vous pouvez utiliser le AWS Management Console pour consulter les informations d'utilisation des clés d'accès pour vos utilisateurs. Si vous disposez d'un nombre volumineux d'utilisateurs, vous pouvez utiliser la console pour télécharger un rapport d'informations d'identification pour connaître la dernière utilisation des clés d'accès par chaque utilisateur. Vous pouvez également accéder aux informations à partir de l'API AWS CLI ou de l'API IAM.

**Pour rechercher les clés d'accès inutilisées (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Utilisateurs**.

1. Au besoin, ajoutez la colonne **Access key last used (Dernière utilisation de clé d'accès)** à la table des utilisateurs :

   1. Au-dessus de la table à l'extrême droite, choisissez l'icône des paramètres (![\[Settings icon\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. Dans **Sélectionner les colonnes visibles**, sélectionnez **Dernière clé d'accès utilisée**.

   1. Choisissez **Confirmer** pour revenir à la liste des utilisateurs.

1. La colonne **Clé d'accès utilisée pour la dernière fois** indique le nombre de jours écoulés depuis le dernier accès par AWS programme de l'utilisateur. Ces informations vous permettent de rechercher les utilisateurs avec des clés d'accès n'ayant pas été utilisées depuis une période donnée. La colonne affiche **–** pour les utilisateurs sans clés d'accès. Les clés d'accès qui n'ont pas été utilisées récemment peuvent être supprimées.

**Pour rechercher les clés d'accès inutilisées en téléchargeant le rapport d'informations d'identification (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Rapport sur les informations d'identification**.

1. Choisissez **Télécharger le rapport** pour télécharger un fichier CSV nommé `status_reports_<date>T<time>.csv`. Les colonnes 11 à 13 contiennent la date, la région et les informations de service de la dernière utilisation pour la clé d'accès 1. Les colonnes 16 à 18 contiennent les mêmes informations pour la clé d'accès 2. La valeur est **N/A** si l'utilisateur ne dispose pas de clé d'accès ou s'il ne l'a pas utilisée depuis le 22 avril 2015, date à laquelle IAM a commencé le suivi de l'âge des clés d'accès.

**Pour rechercher les clés d'accès inutilisées (AWS CLI)**  
Exécutez les commandes suivantes pour rechercher les clés d'accès inutilisées :
+ `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)` retourne des informations sur les clés d'accès d'un utilisateur, y compris l'`AccessKeyID`.
+ `[aws iam get-access-key-last-used](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)` utilise un ID de clé d'accès et retourne une sortie qui inclut la `LastUsedDate`, la `Region` dans laquelle la clé d'accès a été utilisée la dernière fois et le `ServiceName` du dernier service demandé. Si la valeur de `LastUsedDate` est manquante, ceci indique que la clé d'accès n'a pas été utilisée depuis le 22 avril 2015, date à laquelle IAM a commencé le suivi de l'âge des clés d'accès.

**Pour trouver les clés d'accès non utilisées (AWS API)**  
Appelez les opérations suivantes pour rechercher les clés d'accès inutilisées :
+ `[ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)` retourne une liste de valeurs `AccessKeyID` pour les clés d'accès associées à l'utilisateur spécifié. 
+ `[GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)` utilise un ID de clé d'accès et retourne une collection de valeurs. Il s'agit notamment de la `LastUsedDate`, de la `Region` dans laquelle la clé d'accès a été utilisée la dernière fois et du `ServiceName` du dernier service demandé. Si la valeur est manquante, cela signifie que l'utilisateur ne dispose pas de clé d'accès ou qu'il ne l'a pas utilisée depuis le 22 avril 2015, date à laquelle IAM a commencé le suivi de l'âge des clés d'accès.

Pour plus d'informations sur les commandes à utiliser pour le téléchargement du rapport d'informations d'identification, consultez [Obtention de rapports d'informations d'identification (AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi).

# Générez des rapports d'identification pour votre Compte AWS
<a name="id_credentials_getting-report"></a>

Vous pouvez générer et télécharger un *rapport sur les informations d'identification* qui répertorie tous les utilisateurs de votre compte et le statut de leurs diverses informations d'identification, notamment leurs mots de passe, clés d'accès et dispositifs MFA. Vous pouvez obtenir un rapport d'identification à partir des AWS Management Console[outils de ligne de commande [AWS SDKs](https://aws.amazon.com/tools)](https://aws.amazon.com/tools/#Command_Line_Tools)et ou de l'API IAM. 

**Note**  
Le rapport d'identification IAM inclut uniquement les informations d'identification gérées par IAM suivantes : les mots de passe, les deux premières clés d'accès par utilisateur, les appareils MFA et les certificats de signature X.509. Le rapport n'inclut pas les informations d'identification spécifiques au service (telles que les mots de CodeCommit passe, les clés d'API à long terme d'Amazon Bedrock ou les clés d'API à long terme d'Amazon CloudWatch Logs) ni aucune autre clé d'accès utilisateur au-delà des deux premières. Pour une visibilité complète des informations d'identification, utilisez le [ListServiceSpecificCredentials](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html)et [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) APIs.

Vous pouvez utiliser les rapports sur les informations d'identification à des fins d'audit et de conformité. Vous pouvez utiliser les rapports pour auditer les effets des exigences en matière de cycle de vie des informations d'identification, comme la mise à jour de mot de passe et de clé d'accès. Vous pouvez fournir les rapports à un auditeur externe ou accorder des autorisations à un auditeur pour qu'il télécharge les rapports directement.

Vous pouvez générer un rapport sur les informations d'identification à quelques heures d'intervalle. Lorsque vous demandez un rapport, IAM vérifie d'abord si un rapport Compte AWS a été généré au cours des quatre dernières heures. Le cas échéant, le rapport le plus récent est téléchargé. Si le rapport le plus récent pour le compte a été généré il y a plus de quatre heures ou qu'il n'y a pas eu d'autres rapport généré précédemment pour le compte, IAM génère et télécharge un nouveau rapport. 

**Topics**
+ [Autorisations requises](#id_credentials_required_permissions)
+ [Présentation du format du rapport](#id_credentials_understanding_the_report_format)
+ [Obtention de rapports d'informations d'identification (console)](#getting-credential-reports-console)
+ [Obtention de rapports d'informations d'identification (AWS CLI)](#getting-credential-reports-cliapi)
+ [Obtenir des rapports d'identification (AWS API)](#getting-credential-reports-api)

## Autorisations requises
<a name="id_credentials_required_permissions"></a>

Les autorisations suivantes sont nécessaires pour créer et télécharger des rapports :
+ Pour créer un rapport sur les informations d'identification : `iam:GenerateCredentialReport` 
+ Pour télécharger le rapport : `iam:GetCredentialReport`

## Présentation du format du rapport
<a name="id_credentials_understanding_the_report_format"></a>

Les rapports sur les informations d'identification sont formatés comme des fichiers CSV (valeurs séparées par une virgule). Vous pouvez ouvrir les fichiers CSV avec des logiciels de feuilles de calcul courants pour effectuer des analyses ou vous pouvez créer une application qui consomme les fichiers CSV par programmation et effectue des analyses personnalisées. 

Le fichier CSV contient les colonnes suivantes :

**user**  
Nom convivial de l'utilisateur. 

**arn**  
Amazon Resource Name (ARN) de l'utilisateur. Pour plus d'informations sur ARNs, voir[IAM ARNs](reference_identifiers.md#identifiers-arns). 

**user\$1creation\$1time**  
Date et heure de création de l'utilisateur, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601).

**password\$1enabled**  
Lorsqu'un utilisateur dispose d'un mot de passe, cette valeur est `TRUE`. Sinon, la valeur est définie comme `FALSE`. Cette valeur est `FALSE` pour les nouveaux comptes membres créés dans le cadre de votre organisation, car ils ne disposent pas des informations d’identification de l’utilisateur racine par défaut.

**password\$1last\$1used**  
Date et heure auxquelles le mot de passe de l'utilisateur Utilisateur racine d'un compte AWS ou de l'utilisateur a été utilisé pour la dernière fois pour se connecter à un AWS site Web, au format [date-heure ISO 8601](http://www.iso.org/iso/iso8601). AWS les sites Web qui enregistrent l'heure de dernière connexion d'un utilisateur sont AWS Management Console les forums de AWS discussion et le AWS Marketplace. Quand un mot de passe est utilisé plusieurs fois dans un intervalle de 5 minutes, seule la première utilisation est enregistrée dans ce champ.   
+ La valeur de ce champ est `no_information` dans les cas suivants :
  + Le mot de passe de l'utilisateur n'a jamais été utilisé.
  + Aucune donnée de connexion n'est associée au mot de passe, comme lorsque le mot de passe de l'utilisateur n'a pas été utilisé depuis le 20 octobre 2014, date de début du suivi de cette information par IAM.
+ La valeur de ce champ est `N/A` (non applicable) lorsque l'utilisateur ne dispose pas de mot de passe.

**Important**  
En raison d'un problème de service, les données de dernière d'utilisation du mot de passe n'incluent pas l'utilisation du mot de passe entre le 3 mai 2018 et le 23 mai 2018 22:50 14:08 PDT (heure du Pacifique). [Cela affecte les dates de [dernière connexion](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) affichées dans la console IAM et les dates de dernière utilisation du mot de passe dans le [rapport d'identification IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html), et renvoyées par l'opération d'API. GetUser ](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) Si des utilisateurs se sont connectés au cours de la période concernée, la date de dernière d'utilisation du mot de passe renvoyée est la date de la dernière connexion de l'utilisateur avant le 3 mai 2018. Pour les utilisateurs qui se sont connectés après le 23 mai 2018 14:08 PDT, la date de dernière utilisation du mot de passe renvoyée est exacte.  
Si vous utilisez les informations de dernière utilisation du mot de passe pour identifier les informations d'identification non utilisées à supprimer, par exemple en supprimant des utilisateurs qui ne se AWS sont pas connectés au cours des 90 derniers jours, nous vous recommandons d'ajuster votre fenêtre d'évaluation pour inclure les dates postérieures au 23 mai 2018. Par ailleurs, si vos utilisateurs utilisent des clés d'accès pour accéder AWS par programmation, vous pouvez vous référer aux dernières informations utilisées sur les clés d'accès, car elles sont exactes pour toutes les dates. 

**password\$1last\$1changed**  
Date et heure de la dernière définition du mot de passe de l'utilisateur, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601). Si l'utilisateur ne dispose pas d'un mot de passe, la valeur de ce champ est `N/A` (non applicable).

**password\$1next\$1rotation**  
Lorsque le compte dispose d'une [politique de mot de passe](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingPasswordPolicies.html) qui nécessite la rotation du mot de passe, ce champ contient la date et l'heure, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), auxquelles l'utilisateur doit définir un nouveau mot de passe. La valeur de Compte AWS (root) est toujours`not_supported`.

**mfa\$1active**  
Lorsqu'un périphérique d'[authentification multi-facteur](id_credentials_mfa.md) (MFA) a été activé pour l'utilisateur, cette valeur est `TRUE`. Sinon, la valeur est définie comme `FALSE`.

**access\$1key\$11\$1active**  
Lorsque l'utilisateur dispose d'une clé d'accès et que l'état de celle-ci est `Active`, cette valeur est `TRUE`. Sinon, la valeur est définie comme `FALSE`. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.

**access\$1key\$11\$1last\$1rotated**  
Date et heure, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), auxquelles la clé d'accès de l'utilisateur a été créée ou modifiée pour la dernière fois. Si l'utilisateur ne dispose pas d'une clé d'accès active, la valeur de ce champ est `N/A` (non applicable). S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.

**access\$1key\$11\$1last\$1used\$1date**  
Date et heure, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), auxquelles la clé d'accès de l'utilisateur a été utilisée pour la dernière fois pour se connecter à une demande d'API AWS . Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.  
La valeur de ce champ est `N/A` (non applicable) dans les cas suivants :  
+ L'utilisateur ne dispose pas d'une clé d'accès.
+ La clé d'accès n'a jamais été utilisée.
+ La clé d'accès n'a pas été utilisée depuis le 22 avril 2015, date de début du suivi de cette information par IAM.

**access\$1key\$11\$1last\$1used\$1region**  
[Région AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) dans laquelle la clé d'accès a été utilisée pour la dernière fois. Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.  
La valeur de ce champ est `N/A` (non applicable) dans les cas suivants :  
+ L'utilisateur ne dispose pas d'une clé d'accès.
+ La clé d'accès n'a jamais été utilisée.
+ La clé d'accès a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi de cette information par IAM.
+ Le dernier service utilisé n'est pas spécifique à une région, comme Amazon S3.

**access\$1key\$11\$1last\$1used\$1service**  
Le AWS service auquel vous avez accédé le plus récemment à l'aide de la clé d'accès. La valeur de ce champ utilise l'espace de noms du service (par exemple, `s3` pour Amazon S3 et `ec2` pour Amazon EC2). Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.  
La valeur de ce champ est `N/A` (non applicable) dans les cas suivants :  
+ L'utilisateur ne dispose pas d'une clé d'accès.
+ La clé d'accès n'a jamais été utilisée.
+ La clé d'accès a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi de cette information par IAM.

**access\$1key\$12\$1active**  
Lorsque l'utilisateur dispose d'une seconde clé d'accès et que l'état de celle-ci est `Active`, cette valeur est `TRUE`. Sinon, la valeur est définie comme `FALSE`. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.  
Les utilisateurs peuvent avoir jusqu'à deux clés d'accès, afin de faciliter la rotation en mettant d'abord à jour la clé, puis en supprimant la clé précédente. Pour plus d'informations sur la mise à jour des clés d'accès, veuillez consulter [Mise à jour des clés d’accès](id-credentials-access-keys-update.md).

**access\$1key\$12\$1last\$1rotated**  
Date et heure, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), de la création ou de la dernière mise à jour de la deuxième clé d'accès de l'utilisateur. Si l'utilisateur ne dispose pas d'une seconde clé d'accès active, la valeur de ce champ est `N/A` (non applicable). S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.

**access\$1key\$12\$1last\$1used\$1date**  
Date et heure, au [format date-heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), auxquelles la deuxième clé d'accès de l'utilisateur a été utilisée pour la dernière fois pour signer une AWS demande d'API. Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM.  
La valeur de ce champ est `N/A` (non applicable) dans les cas suivants :  
+ L'utilisateur ne dispose pas d'une seconde clé d'accès.
+ La seconde clé d'accès de l'utilisateur n'a jamais été utilisée.
+ La seconde clé d'accès de l'utilisateur a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi de cette information par IAM.

**access\$1key\$12\$1last\$1used\$1region**  
[Région AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) dans laquelle la seconde clé d'accès de l'utilisateur a été utilisée pour la dernière fois. Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM. La valeur de ce champ est `N/A` (non applicable) dans les cas suivants :  
+ L'utilisateur ne dispose pas d'une seconde clé d'accès.
+ La seconde clé d'accès de l'utilisateur n'a jamais été utilisée.
+ La seconde clé d'accès de l'utilisateur a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi de cette information par IAM.
+ Le dernier service utilisé n'est pas spécifique à une région, comme Amazon S3.

**access\$1key\$12\$1last\$1used\$1service**  
Le AWS service auquel l'utilisateur a accédé le plus récemment avec la deuxième clé d'accès. La valeur de ce champ utilise l'espace de noms du service (par exemple, `s3` pour Amazon S3 et `ec2` pour Amazon EC2). Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. S’applique à la fois à l’utilisateur racine du compte et aux utilisateurs IAM. La valeur de ce champ est `N/A` (non applicable) dans les cas suivants :  
+ L'utilisateur ne dispose pas d'une seconde clé d'accès.
+ La seconde clé d'accès de l'utilisateur n'a jamais été utilisée.
+ La seconde clé d'accès de l'utilisateur a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi de cette information par IAM.

**cert\$11\$1active**  
Lorsque l'utilisateur dispose d'un certificat de signature X.509 et que l'état de celui-ci est `Active`, cette valeur est `TRUE`. Sinon, la valeur est définie comme `FALSE`.

**cert\$11\$1last\$1rotated**  
Date et heure, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), auxquelles le certificat de signature de l'utilisateur a été créé ou modifié pour la dernière fois. Si l'utilisateur ne dispose pas d'un certificat de signature actif, la valeur de ce champ est `N/A` (non applicable).

**cert\$12\$1active**  
Lorsque l'utilisateur dispose d'un second certificat de signature X.509 et que l'état de celui-ci est `Active`, cette valeur est `TRUE`. Sinon, la valeur est définie comme `FALSE`.  
Les utilisateurs peuvent disposer de deux certificats de signature X.509 afin de faciliter la rotation des certificats.

**cert\$12\$1last\$1rotated**  
Date et heure, au [format de date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601), auxquelles le second certificat de signature de l'utilisateur a été créé ou modifié pour la dernière fois. Si l'utilisateur ne dispose pas d'un second certificat de signature actif, la valeur de ce champ est `N/A` (non applicable).

**information\$1accréditations\$1supplémentaires**  
Lorsque l'utilisateur possède plus de deux clés d'accès ou certificats, cette valeur correspond au nombre de clés d'accès ou de certificats supplémentaires et aux actions que vous pouvez utiliser pour répertorier les clés d'accès ou les certificats associés à l'utilisateur.

## Obtention de rapports d'informations d'identification (console)
<a name="getting-credential-reports-console"></a>

Vous pouvez utiliser le AWS Management Console pour télécharger un rapport d'identification sous forme de fichier CSV (valeurs séparées par des virgules).

**Pour télécharger un rapport sur les informations d'identification (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Rapport sur les informations d'identification**.

1. Choisissez **Télécharger le rapport**.

## Obtention de rapports d'informations d'identification (AWS CLI)
<a name="getting-credential-reports-cliapi"></a>

**Pour télécharger un rapport sur les informations d'identification (AWS CLI)**

1. Générez un rapport sur les informations d'identification. AWS stocke un seul rapport. Si un rapport existe, la génération d'un rapport sur les informations d'identification remplace le rapport précédent. [https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html)

1. Affichez le dernier rapport généré : [https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html)

## Obtenir des rapports d'identification (AWS API)
<a name="getting-credential-reports-api"></a>

**Pour télécharger un rapport d'identification (AWS API)**

1. Générez un rapport sur les informations d'identification. AWS stocke un seul rapport. Si un rapport existe, la génération d'un rapport sur les informations d'identification remplace le rapport précédent. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html)

1. Affichez le dernier rapport généré : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html)

# Informations d'identification IAM pour CodeCommit : informations d'identification Git, clés SSH et AWS clés d'accès
<a name="id_credentials_ssh-keys"></a>

CodeCommit est un service de contrôle de version géré qui héberge des référentiels Git privés dans le AWS cloud. Pour l'utiliser CodeCommit, vous devez configurer votre client Git pour qu'il communique avec CodeCommit les référentiels. Dans le cadre de cette configuration, vous fournissez des informations d'identification IAM qui CodeCommit peuvent être utilisées pour vous authentifier. IAM prend en charge CodeCommit trois types d'informations d'identification :
+ Informations d'identification Git, paire nom d'utilisateur et mot de passe générée par IAM que vous pouvez utiliser pour communiquer avec les CodeCommit référentiels via HTTPS.
+ Les clés SSH sont une paire de clés publique-privée générée localement que vous pouvez associer à votre utilisateur IAM pour communiquer avec les CodeCommit référentiels via SSH.
+  [AWS clés d'accès](id_credentials_access-keys.md), que vous pouvez utiliser avec l'assistant d'identification inclus dans le AWS CLI pour communiquer avec les CodeCommit référentiels via HTTPS.

**Note**  
Vous ne pouvez pas utiliser les clés SSH ni les informations d'identification Git pour accéder aux référentiels dans un autre compte AWS . *Pour savoir comment configurer l'accès aux CodeCommit référentiels pour les utilisateurs et les groupes IAM d'un autre utilisateur Compte AWS, voir [Configurer l'accès entre comptes à un AWS CodeCommit référentiel à l'aide de rôles](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) dans le Guide de l'AWS CodeCommit utilisateur.*

Pour plus d'informations sur chaque option, consultez les sections suivantes. 

## Utiliser les informations d'identification Git et HTTPS avec CodeCommit (recommandé)
<a name="git-credentials-code-commit"></a>

Avec les informations d'identification Git, vous générez une paire mot de passe-nom utilisateur statique pour votre utilisateur IAM, puis utilisez ces informations d'identification pour les connexions HTTPS. Vous pouvez également utiliser ces informations d'identification avec n'importe quel outil tiers ou environnement de développement intégré (IDE) prenant en charge les informations d'identification Git statiques.

Etant donné que ces informations d'identification sont universelles pour tous les systèmes d'exploitation pris en charge et compatibles avec la plupart des systèmes de gestion des informations d'identification, environnements de développement et autres outils de développement logiciel, c'est la méthode recommandée. Vous pouvez réinitialiser le mot de passe pour les informations d'identification Git à tout moment. Vous pouvez également désactiver les informations d'identification ou les supprimer si vous n'en avez plus besoin.

**Note**  
Pour les informations d'identification Git, vous ne pouvez pas choisir vous-même votre nom d'utilisateur et votre mot de passe. IAM génère ces informations d'identification pour vous aider à garantir qu'elles répondent aux normes de sécurité AWS et qu'elles sécurisent les référentiels dans. CodeCommit Vous pouvez télécharger les informations d'identification une seule fois, au moment elles sont générées. Veillez à enregistrer les informations d'identification dans un emplacement sûr. Si nécessaire, vous pouvez réinitialiser le mot de passe à tout moment, mais cela invalidera les connexions configurées avec l'ancien mot de passe. Vous devez reconfigurer les connexions pour qu'elles utilisent le nouveau mot de passe avant de vous connecter.

Pour plus d'informations, consultez les rubriques suivantes : 
+ Pour créer un utilisateur IAM, veuillez consulter [Créez un utilisateur IAM dans votre Compte AWS](id_users_create.md). 
+ Pour générer et utiliser des informations d'identification Git avec CodeCommit, consultez la section [Pour les utilisateurs HTTPS utilisant des informations d'identification Git](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) dans le *guide de AWS CodeCommit l'utilisateur*. 

**Note**  
Le fait de modifier le nom d'un utilisateur IAM après avoir généré des informations d'identification Git ne modifie pas le nom utilisateur des informations d'identification Git. Le nom utilisateur et le mot de passe restent identiques et sont toujours valides. 

**Pour mettre à jour les informations d'identification spécifiques au service**

1. Créez un second ensemble d'informations d'identification spécifiques au service en plus de l'ensemble actuellement en cours d'utilisation.

1. Mettez à jour toutes vos applications afin qu'elles utilisent le nouvel ensemble d'informations d'identification et vérifiez que les applications fonctionnent.

1. Modifiez l'état des informations d'identification d'origine et utilisez Inactif.

1. Vérifiez que toutes vos applications fonctionnent toujours.

1. Supprimer les informations d'identification spécifiques au service inactives.

## Utilisez des clés SSH et SSH avec CodeCommit
<a name="ssh-keys-code-commit"></a>

Avec les connexions SSH, vous créez des fichiers de clés publiques et privées sur votre machine locale que Git CodeCommit utilise pour l'authentification SSH. Vous associez la clé publique à votre utilisateur IAM et stockez la clé privée sur votre ordinateur local. Pour plus d'informations, consultez les rubriques suivantes : 
+ Pour créer un utilisateur IAM, veuillez consulter [Créez un utilisateur IAM dans votre Compte AWS](id_users_create.md). 
+ Pour créer une clé publique SSH et l'associer à un utilisateur IAM, consultez [Pour les connexions SSH sous Linux, macOS ou Unix](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-unixes.html) ou [Pour des connexions SSH sous Windows](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-windows.html) dans le *Guide de l'utilisateur AWS CodeCommit *. 

**Note**  
La clé publique doit être codée au format ssh-rsa ou PEM. Le longueur binaire minimale de la clé publique est de 2048 bits et la longueur maximale de 16 384 bits. Cette longueur est distincte de la taille du fichier que vous chargez. Par exemple, vous pouvez générer une clé de 2048 bits et le fichier PEM résultant a une longueur de 1679 octets. Si vous fournissez votre clé publique dans un autre format ou une autre taille, un message d'erreur vous indiquera que le format de clé n'est pas valide.

## Utilisez HTTPS avec l'assistant AWS CLI d'identification et CodeCommit
<a name="access-keys-code-commit"></a>

Comme alternative aux connexions HTTPS avec des informations d'identification Git, vous pouvez autoriser Git à utiliser une version signée cryptographiquement de vos informations d'identification utilisateur IAM ou de votre rôle d'instance Amazon EC2 chaque fois que Git doit s'authentifier pour interagir AWS avec des référentiels. CodeCommit Il s'agit de la seule méthode de connexion pour CodeCommit les référentiels qui ne nécessite pas d'utilisateur IAM. C'est également la seule méthode qui fonctionne avec un accès fédéré et des informations d'identification temporaires. Pour plus d'informations, consultez les rubriques suivantes :
+ Pour en savoir plus sur l'accès fédéré, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md) et [Accès aux utilisateurs authentifiés en externe (fédération d’identité)](id_roles_common-scenarios_federated-users.md). 
+ Pour en savoir plus sur les informations d'identification temporaires, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md) et [Accès temporaire à des référentiels CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html). 

L'assistant AWS CLI d'identification n'est pas compatible avec les autres systèmes d'assistance aux identifiants, tels que Keychain Access ou Windows Credential Management. Il existe d'autres considérations relatives à la configuration lorsque vous configurez des connexions HTTPS à l'aide de l'assistant d'informations d'identification. *Pour plus d'informations, voir [Pour les connexions HTTPS sous Linux, macOS ou Unix avec l'assistant AWS CLI d'identification ou Connexions HTTPS sous Windows avec l'assistant AWS CLI](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-unixes.html) [d'identification dans le guide de l'utilisateur.](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-windows.html)AWS CodeCommit *

# Gestion des certificats de serveur dans IAM
<a name="id_credentials_server-certs"></a>

*Pour activer les connexions HTTPS à votre site Web ou à votre application AWS, vous avez besoin d'un certificat de serveur SSL/TLS.* Pour les certificats dans une région prise en charge par AWS Certificate Manager (ACM), nous vous recommandons d'utiliser ACM pour allouer, gérer et déployer vos certificats de serveur. Dans les régions non prises en charge, vous devez utiliser IAM en tant que gestionnaire de certificats. Pour savoir quelles régions sont prises en charge par ACM, consultez [Points de terminaison et quotas AWS Certificate Manager](https://docs.aws.amazon.com/general/latest/gr/acm.html) (français non garanti) dans *Références générales AWS*.

**Important**  
ACM est l'outil préféré pour mettre en service, gérer et déployer vos certificats de serveur. Avec ACM, vous pouvez demander un certificat ou déployer un certificat ACM existant ou un certificat externe sur les AWS ressources. Les certificats fournis par ACM sont gratuits et renouvelés automatiquement. Dans une [région prise en charge](https://docs.aws.amazon.com/general/latest/gr/acm.html), vous pouvez utiliser ACM pour gérer des certificats de serveur depuis la console ou par programmation. Pour plus d'informations sur l'utilisation d'ACM, consultez le [https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). Pour plus d'informations sur la demande d'un certificat ACM, consultez [Demander un certificat public](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) ou [Demander in certificat privé](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) dans le *Guide de l'utilisateur AWS Certificate Manager *. Pour plus d'informations sur l'importation de certificats tiers dans ACM, consultez [Importation de certificats](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) dans le *Guide de l’utilisateur AWS Certificate Manager *.

Utilisez IAM comme gestionnaire de certificats uniquement lorsque vous devez prendre en charge des connexions HTTPS dans une région [non prise en charge par ACM](https://docs.aws.amazon.com/general/latest/gr/acm.html). IAM chiffre en toute sécurité vos clés privées et stocke la version chiffrée dans le magasin de certificats SSL IAM. IAM prend en charge le déploiement de certificats de serveur dans toutes les régions, mais vous devez obtenir votre certificat auprès d'un fournisseur externe pour pouvoir l'utiliser avec AWS. Vous ne pouvez pas télécharger de certificat ACM dans IAM. De plus, vous ne pouvez pas gérer vos certificats depuis la console IAM. 

Pour plus d'informations sur le chargement de certificats tiers dans IAM, consultez les rubriques suivantes.

**Topics**
+ [Téléchargez un certificat de serveur (AWS API)](#upload-server-certificate)
+ [AWS Opérations d'API pour les certificats de serveur](#id_credentials_server-certs-api)
+ [Résolution des problèmes liés aux certificats de serveur](#server-certificate-troubleshooting)

## Téléchargez un certificat de serveur (AWS API)
<a name="upload-server-certificate"></a>

Pour télécharger un certificat de serveur dans IAM, vous devez fournir le certificat et sa clé privée correspondante. Si le certificat n’est pas auto-signé, vous devez également fournir une chaîne de certificats. (Vous n’avez pas besoin d’une chaîne de certificats lorsque vous chargez un certificat auto-signé.) Avant de charger un certificat, vérifiez que vous avez tous ces éléments et qu’ils répondent aux critères suivants :
+ Le certificat doit être valide au moment du chargement. Vous ne pouvez pas charger un certificat avant le début de sa période de validité (date `NotBefore` du certificat) ou après son expiration (date `NotAfter` du certificat).
+ La clé privée doit être non chiffrée. Vous ne pouvez pas charger une clé privée qui est protégée par un mot de passe ou une phrase passe. Pour obtenir de l'aide pour déchiffrer une clé privée chiffrée, consultez [Résolution des problèmes liés aux certificats de serveur](#server-certificate-troubleshooting).
+ Le certificat, la clé privée et la chaîne de certificats doivent être codés PEM. Pour obtenir de l'aide pour convertir ces éléments au format PEM, consultez [Résolution des problèmes liés aux certificats de serveur](#server-certificate-troubleshooting).

Pour utiliser l'[API IAM](https://docs.aws.amazon.com/IAM/latest/APIReference/) afin de télécharger un certificat, envoyez une [UploadServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadServerCertificate.html)demande. L'exemple suivant montre comment procéder avec l'[AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/). Dans cet exemple il est supposé que :
+ Le certificat codé en PEM est stocké dans un fichier nommé `Certificate.pem`.
+ La chaîne de certificats codée en PEM est stockée dans un fichier nommé `CertificateChain.pem`.
+ La clé privée non chiffrée, codée en PEM est stockée dans un fichier nommé `PrivateKey.pem`.
+ (Facultatif) Vous souhaitez baliser le certificat de serveur avec une paire clé-valeur. Par exemple, vous pouvez ajouter la clé de balise `Department` et la valeur de balise `Engineering` pour vous aider à identifier et organiser vos certificats.

Pour utiliser l'exemple de commande suivant, remplacez ces noms de fichier par les vôtres. *ExampleCertificate*Remplacez-le par un nom pour le certificat que vous avez téléchargé. Si vous souhaitez étiqueter le certificat, remplacez la paire clé-valeur *ExampleKey* and *ExampleValue* tag par vos propres valeurs. Tapez la commande sur une seule ligne continue. L’exemple suivant inclut des sauts de ligne et des espaces supplémentaires pour le rendre plus facile à lire.

```
aws iam upload-server-certificate --server-certificate-name ExampleCertificate
                                    --certificate-body file://Certificate.pem
                                    --certificate-chain file://CertificateChain.pem
                                    --private-key file://PrivateKey.pem
                                    --tags '{"Key": "ExampleKey", "Value": "ExampleValue"}'
```

Lorsque la commande précédente aboutit, elle renvoie des métadonnées relatives au certificat chargé, y compris son [Amazon Resource Name (ARN)](reference_identifiers.md#identifiers-arns), son nom convivial, son identifiant (ID), sa date d'expiration, ses balises, etc.

**Note**  
Si vous téléchargez un certificat de serveur à utiliser avec Amazon CloudFront, vous devez spécifier un chemin à l'aide de l'`--path`option. Le chemin doit commencer par `/cloudfront` et doit inclure une barre oblique de fin (par exemple, `/cloudfront/test/`).

 AWS Tools for Windows PowerShell Pour télécharger un certificat, utilisez [IAMServerPublish-Certificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Publish-IAMServerCertificate.html&tocid=Publish-IAMServerCertificate).

## AWS Opérations d'API pour les certificats de serveur
<a name="id_credentials_server-certs-api"></a>

Utilisez les commandes suivantes pour afficher, étiqueter, renommer et supprimer les certificats de serveur.
+ [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html)À utiliser pour récupérer un certificat. Cette requête renvoie le certificat, la chaîne de certificats (si une chaîne de certificats a été chargée) et des métadonnées relatives au certificat.
**Note**  
Vous ne pouvez pas télécharger ou récupérer une clé privée depuis IAM après l'avoir téléchargée.
+ Utilisez [Get- IAMServer Certificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificate.html&tocid=Get-IAMServerCertificate) pour récupérer un certificat.
+ [ListServerCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificates.html)À utiliser pour répertorier les certificats de serveur que vous avez téléchargés. La requête renvoie une liste qui contient les métadonnées relatives à chaque certificat.
+ Utilisez [Get- IAMServer Certificates pour répertorier les certificats](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificates.html&tocid=Get-IAMServerCertificates) de serveur que vous avez téléchargés.
+ [TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html)À utiliser pour étiqueter un certificat de serveur existant. 
+ [UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html)À utiliser pour supprimer le balisage d'un certificat de serveur.
+ [UpdateServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServerCertificate.html)À utiliser pour renommer un certificat de serveur ou mettre à jour son chemin.

   L'exemple suivant montre comment procéder avec l’interface AWS CLI.

  Pour utiliser la commande suivante, remplacez les anciens et nouveaux noms de certificat et le chemin d'accès du certificat, et tapez la commande sur une seule ligne continue. L’exemple suivant inclut des sauts de ligne et des espaces supplémentaires pour le rendre plus facile à lire.

  ```
  aws iam update-server-certificate --server-certificate-name ExampleCertificate
                                      --new-server-certificate-name CloudFrontCertificate
                                      --new-path /cloudfront/
  ```

   AWS Tools for Windows PowerShell Pour renommer un certificat de serveur ou mettre à jour son chemin, utilisez [Update- IAMServer Certificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Update-IAMServerCertificate.html&tocid=Update-IAMServerCertificate).
+ [DeleteServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServerCertificate.html)À utiliser pour supprimer un certificat de serveur. 

   AWS Tools for Windows PowerShell Pour supprimer un certificat de serveur, utilisez [Remove- IAMServer Certificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Remove-IAMServerCertificate.html&tocid=Remove-IAMServerCertificate).

## Résolution des problèmes liés aux certificats de serveur
<a name="server-certificate-troubleshooting"></a>

Pour pouvoir charger un certificat vers IAM, vous devez vous assurer que le certificat, la clé privée et la chaîne de certificats sont tous codés PEM. Vous devez également vous assurer que la clé privée est non chiffrée. Voir les exemples suivantes.

**Example Exemple de certificat codé PEM**  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

**Example Clé privée non chiffrée codée PEM**  

```
-----BEGIN RSA PRIVATE KEY-----
Base64-encoded private key
-----END RSA PRIVATE KEY-----
```

**Example Chaîne de certificats codée PEM**  
Une chaîne de certificats contient un ou plusieurs certificats. Vous pouvez utiliser un éditeur de texte, la commande copy sous Windows ou la commande cat Linux pour concaténer vos fichiers de certificats dans une chaîne. Lorsque vous incluez plusieurs certificats, chacun d'entre eux doit approuver le certificat précédent. Vous pouvez effectuer cette opération en concaténant les certificats, y compris le certificat d'autorité de certification racine en dernier.  
L'exemple suivant contient trois certificats, mais votre chaîne de certificats peut en contenir plus ou moins.  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

Si ces éléments ne sont pas au bon format pour le téléchargement vers IAM, vous pouvez utiliser [OpenSSL](https://openssl.org/) pour les convertir au format approprié.

**Pour convertir un certificat ou une chaîne de certificats DER en PEM**  
Utilisez la [commande OpenSSL **x509**](https://openssl.org/docs/manmaster/man1/x509.html), comme dans l'exemple suivant. Dans la commande suivante, remplacez `Certificate.der` par le nom du fichier qui contient votre certificat codé DER. Remplacez `Certificate.pem` par le nom préféré du fichier de sortie devant contenir le certificat codé PEM.  

```
openssl x509 -inform DER -in Certificate.der -outform PEM -out Certificate.pem
```
 

**Pour convertir une clé privée de DER en PEM**  
Utilisez la [commande OpenSSL **rsa**](https://openssl.org/docs/manmaster/man1/rsa.html), comme dans l'exemple suivant. Dans la commande suivante, remplacez `PrivateKey.der` par le nom du fichier qui contient votre clé privée codée DER. Remplacez `PrivateKey.pem` par le nom préféré du fichier de sortie devant contenir la clé privée codée PEM.  

```
openssl rsa -inform DER -in PrivateKey.der -outform PEM -out PrivateKey.pem
```
 

**Pour déchiffrer une clé privée chiffrée (supprimer le mot de passe ou la phrase de passe)**  
Utilisez la [commande OpenSSL **rsa**](https://openssl.org/docs/manmaster/man1/rsa.html), comme dans l'exemple suivant. Pour utiliser la commande suivante, remplacez `EncryptedPrivateKey.pem` par le nom du fichier qui contient votre clé privée chiffrée. Remplacez `PrivateKey.pem` par le nom préféré du fichier de sortie devant contenir la clé privée non chiffrée codée PEM.  

```
openssl rsa -in EncryptedPrivateKey.pem -out PrivateKey.pem
```
 

**Pour convertir un ensemble de certificats de PKCS\$112 (PFX) en PEM**  
Utilisez la [commande OpenSSL **pkcs12**](https://openssl.org/docs/manmaster/man1/pkcs12.html), comme dans l'exemple suivant. Dans la commande suivante, remplacez `CertificateBundle.p12` par le nom du fichier qui contient votre ensemble de certificats codé PKCS\$112. Remplacez `CertificateBundle.pem` par le nom préféré du fichier de sortie devant contenir l'ensemble de certificats codé PEM.  

```
openssl pkcs12 -in CertificateBundle.p12 -out CertificateBundle.pem -nodes
```
 

**Pour convertir un ensemble de certificats de PKCS\$17 en PEM**  
Utilisez la [commande OpenSSL **pkcs7**](https://openssl.org/docs/manmaster/man1/pkcs7.html), comme dans l'exemple suivant. Dans la commande suivante, remplacez `CertificateBundle.p7b` par le nom du fichier qui contient votre ensemble de certificats codé PKCS\$17. Remplacez `CertificateBundle.pem` par le nom préféré du fichier de sortie devant contenir l'ensemble de certificats codé PEM.  

```
openssl pkcs7 -in CertificateBundle.p7b -print_certs -out CertificateBundle.pem
```

# Groupes d'utilisateurs IAM
<a name="id_groups"></a>

Un [*groupe d'utilisateurs*](#id_groups) IAM est un ensemble d'utilisateurs IAM. Les groupes d'utilisateurs vous permettent de spécifier des autorisations pour plusieurs utilisateurs, ce qui permet de gérer plus facilement les autorisations pour ces utilisateurs. Par exemple, vous pouvez avoir un groupe d'utilisateurs appelé *Admins* et accorder à ce groupe d'utilisateurs des autorisations d'administrateur typiques. Tous les utilisateurs de ce groupe d'utilisateurs reçoivent automatiquement les autorisations de groupe *Admins*. Si un nouvel utilisateur rejoint votre organisation et a besoin de privilèges d'administrateur, vous pouvez lui attribuer les autorisations appropriées en l'ajoutant au groupe d'utilisateurs *Admins*. Si une personne change de poste dans votre organisation, au lieu de modifier les autorisations de cet utilisateur, vous pouvez retirer celui-ci de l’ancien groupe IAM et l’ajouter aux nouveaux groupes IAM appropriés. 

Vous pouvez attacher une politique basée sur l'identité à un groupe d'utilisateurs afin que tous les utilisateurs de ce groupe reçoivent les autorisations de la politique. Vous ne pouvez pas identifier un groupe d'utilisateurs en tant que `Principal` dans une politique (telle qu'une politique basée sur les ressources) car les groupes se rapportent aux autorisations, et non à l'authentification, et les principaux sont des entités IAM authentifiées. Pour de plus amples informations sur les types de politiques, veuillez consulter [Politiques basées sur l'identité et Politiques basées sur une ressource](access_policies_identity-vs-resource.md).

Voici quelques caractéristiques importantes des groupes IAM :
+ Un groupe d'utilisateurs peut contenir de nombreux utilisateurs et un utilisateur peut appartenir à plusieurs groupes d'utilisateurs.
+ Les groupes IAM ne peuvent pas être imbriqués ; ils ne peuvent contenir que des utilisateurs, pas d’autres groupes IAM.
+ Il n'existe pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs de l' Compte AWS. Si vous souhaitez disposer d'un groupe d'utilisateurs de ce type, vous devez le créer et lui affecter chaque nouvel utilisateur.
+ Le nombre et la taille des ressources IAM dans un Compte AWS, tels que le nombre de groupes et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour de plus amples informations, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md).

Le schéma suivant illustre un exemple simple de petite entreprise. Le propriétaire de l'entreprise crée un groupe d'utilisateurs `Admins` pour que des utilisateurs créent et gèrent d'autres utilisateurs au fur et à mesure que l'entreprise se développe. Le groupe d'utilisateurs `Admins` crée un groupe d'utilisateurs `Developers` et un groupe d'utilisateurs `Test`. Chacun de ces groupes IAM est composé d'utilisateurs (humains et applications) qui interagissent avec AWS (Jim, Brad, DevApp 1, etc.). Chaque utilisateur dispose d'un ensemble individuel d'informations d'identification de sécurité. Dans cet exemple, chaque utilisateur appartient à un seul groupe d'utilisateurs. Cependant, les utilisateurs peuvent appartenir à plusieurs groupes IAM.

![\[Exemple de relation entre Comptes AWS les utilisateurs et les groupes IAM\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/Relationship_Between_Entities_Example.diagram.png)


# Création de groupes IAM
<a name="id_groups_create"></a>

**Note**  
En tant que [bonne pratique](best-practices.md), nous vous recommandons de demander aux utilisateurs humains d'utiliser la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires. Si vous suivez les bonnes pratiques, vous ne gérez pas les utilisateurs et les groupes IAM. Au lieu de cela, vos utilisateurs et vos groupes sont gérés en dehors de l'extérieur AWS et peuvent accéder aux AWS ressources en tant qu'*identité fédérée*. Une identité fédérée est un utilisateur de l'annuaire des utilisateurs de votre entreprise, un fournisseur d'identité Web, le AWS Directory Service, le répertoire Identity Center ou tout utilisateur qui accède AWS aux services à l'aide des informations d'identification fournies par le biais d'une source d'identité. Les identités fédérées utilisent les groupes définis par leur fournisseur d'identité. Si vous en utilisez AWS IAM Identity Center, consultez la section [Gérer les identités dans IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) dans le *Guide de l'AWS IAM Identity Center utilisateur* pour plus d'informations sur la création d'utilisateurs et de groupes dans IAM Identity Center.

Vous créez des groupes IAM pour gérer les autorisations d’accès de plusieurs utilisateurs ayant des rôles ou des responsabilités similaires. En associant des politiques à ces groupes, vous pouvez accorder ou révoquer des autorisations pour des ensembles complets d’utilisateurs. Cela simplifie la gestion de vos politiques de sécurité, car les modifications que vous apportez aux autorisations d’un groupe sont automatiquement appliquées à tous les membres de ce groupe, garantissant ainsi un contrôle d’accès cohérent. Après avoir créé le groupe, attribuez-lui des autorisations en fonction du type de tâches que vous prévoyez de confier aux utilisateurs IAM qui en feront partie, puis ajoutez les utilisateurs IAM au groupe.

Pour obtenir plus d’informations sur les autorisations nécessaires pour créer un groupe IAM, consultez [Autorisations requises pour accéder aux autres ressources IAM](access_permissions-required.md). 

## Pour créer un groupe IAM et attacher des politiques
<a name="id_groups_create-section-1"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs), puis **Create group** (Créer un groupe).

1. Pour **User group name** (Nom du groupe d'utilisateurs), saisissez le nom du groupe.
**Note**  
Le nombre et la taille des ressources IAM d'un AWS compte sont limités. Pour de plus amples informations, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md). Les noms de groupe peuvent combiner jusqu'à 128 lettres, chiffres et caractères suivants : plus (\$1), égal (=), virgule (,), point (.), arobase (@), trait de soulignement (\$1) et tiret (-). Les noms doivent être uniques au sein d'un compte. Ils ne sont pas sensibles à la casse. Par exemple, vous ne pouvez pas créer deux groupes nommés **ADMINS** et **admins**.

1. Dans la liste des utilisateurs, cochez la case en regard de chacun des utilisateurs à ajouter au groupe.

1. Dans la liste de politiques, activez la case à cocher en regard de chaque politique devant s'appliquer à tous les membres du groupe.

1. Choisissez **Créer un groupe**.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [aws iam create-group](https://docs.aws.amazon.com/cli/latest/reference/iam/create-group.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [CreateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html)

------

# Afficher les groupes IAM
<a name="id_groups_manage_list"></a>

Vous pouvez répertorier tous les groupes IAM de votre compte, les utilisateurs d’un groupe IAM ou les groupes IAM auxquels appartient un utilisateur. Si vous utilisez la CLI ou l’API, vous pouvez afficher tous les groupes IAM avec un préfixe de chemin d’accès spécifique.

------
#### [ Console ]

Pour répertorier tous les groupes IAM de votre compte
+ Dans le panneau de navigation, sélectionnez **Groupes d’utilisateurs**.

Pour répertorier les utilisateurs IAM d’un groupe IAM spécifique :
+ Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs). Sélectionnez ensuite le nom du groupe pour afficher sa page de détails. Consultez l’onglet **Utilisateurs** pour voir les membres du groupe.

Pour répertorier tous les groupes IAM auxquels appartient un utilisateur :
+ Dans le panneau de navigation, choisissez **utilisateurs**. Sélectionnez ensuite le nom d’utilisateur pour ouvrir la page des détails de l’utilisateur. Cliquez sur l’onglet **Groupes** pour voir la liste des groupes auxquels l’utilisateur appartient.

------
#### [ AWS CLI ]

Pour répertorier tous les groupes IAM de votre compte
+ [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html)

Pour répertorier les utilisateurs d’un groupe IAM spécifique :
+ [aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)

Pour répertorier tous les groupes IAM auxquels appartient un utilisateur :
+ [était un objectif list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)

------
#### [ API ]

Pour répertorier tous les groupes IAM de votre compte
+ [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html)

Pour répertorier les utilisateurs d’un groupe IAM spécifique :
+ [GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)

Pour répertorier tous les groupes IAM auxquels appartient un utilisateur :
+ [ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)

------

# Modification des utilisateurs dans les groupes IAM
<a name="id_groups_manage_add-remove-users"></a>

Utilisez les groupes IAM pour appliquer les mêmes politiques d’autorisations sur plusieurs utilisateurs à la fois. Vous pouvez ensuite ajouter des utilisateurs à un groupe IAM ou en supprimer. Cet utile à mesure que des utilisateurs arrivent dans votre organisation et la quittent.

## Vérification de l’accès des politiques
<a name="groups-remove_prerequisites"></a>

Avant de supprimer un groupe, utilisez la page des détails du groupe pour vérifier les membres (utilisateurs IAM) du groupe, les politiques associées au groupe dans l’onglet **Autorisations** et consulter l’activité récente au niveau du service dans l’onglet **Dernière consultation**. Ceci permet d’éviter de supprimer involontairement l’accès à partir d’un principal (personne ou application) qui l’utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md).

## Ajouter un utilisateur IAM à un groupe IAM
<a name="groups-add-remove-console"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs), puis choisissez le nom du groupe.

1. Sélectionnez l'onglet **Users** (Utilisateurs), puis **Add users** (Ajouter des utilisateurs). Cochez la case à côté de l'utilisateur que vous souhaitez ajouter.

1. Sélectionnez **Add users** (Ajouter des utilisateurs).

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam add-user-to-group](https://docs.aws.amazon.com/cli/latest/reference/iam/add-user-to-group.html)`

------
#### [ API ]

Appelez l’opération suivante :
+ `[AddUserToGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)`

------

## Supprimer un utilisateur IAM d’un groupe IAM
<a name="id_groups_manage_add-remove-users-section-1"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs), puis choisissez le nom du groupe.

1. Sélectionnez l’onglet **Utilisateurs**. Cochez la case en regard de l'utilisateur à supprimer, puis choisissez **Remove users (Supprimer des utilisateurs)**.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)`

------
#### [ API ]

Appelez l’opération suivante :
+ `[RemoveUserFromGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveUserFromGroup.html)`

------

# Attachement d’une politique à un groupe d’utilisateurs IAM
<a name="id_groups_manage_attach-policy"></a>

Vous pouvez associer une [politique AWS gérée](access_policies_managed-vs-inline.md#aws-managed-policies), c'est-à-dire une politique préécrite fournie par, AWSà un groupe d'utilisateurs, comme expliqué dans les étapes suivantes. Pour attacher une politique gérée par le client, c'est-à-dire une politique pour laquelle vous avez créé des autorisations personnalisées, vous devez d'abord créer la politique. Pour plus d'informations sur la création de politiques gérées par le client, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](access_policies_create.md). 

Pour plus d'informations sur les autorisations et les politiques, consultez [Gestion de l'accès aux AWS ressources](access.md). 

## Pour attacher une politique à un groupe IAM
<a name="id_groups_manage_attach-policy-section-1"></a>

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs), puis choisissez le nom du groupe.

1. Sélectionnez l’onglet **Autorisations**.

1. Choisissez **Ajouter des autorisations**, puis **Attacher des politiques**.

1. Les politiques actuellement attachées au groupe d'utilisateurs s'affichent dans la liste **Politiques d'autorisation actuelles**. Dans la liste des **Autres politiques d'autorisation**, cochez la case en regard des noms des politiques à attacher. Vous pouvez utiliser la barre de recherche pour filtrer la liste des politiques par type et nom de politique.

1. Sélectionnez la politique que vous souhaitez attacher à votre groupe IAM et choisissez **Attacher des politiques**.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ `[aws iam attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)`

------
#### [ API ]

Appelez l’opération suivante :
+ `[AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)`

------

# Affectation d’un nouveau nom à un groupe d’utilisateurs IAM
<a name="id_groups_manage_rename"></a>

Lorsque vous modifiez le nom ou le chemin d'accès d'un groupe d'utilisateurs, voici ce qui suit se produit : 
+ Toutes les politiques attachées au groupe d'utilisateurs restent dans le groupe sous le nouveau nom.
+ Le groupe d'utilisateurs conserve également tous ses utilisateurs sous le nouveau nom.
+ L'ID unique du groupe d'utilisateurs demeure le même. Pour plus d'informations sur le caractère unique IDs, consultez[Identifiants uniques](reference_identifiers.md#identifiers-unique-ids). 

IAM ne met pas automatiquement à jour les politiques qui font référence au groupe d'utilisateurs en tant que ressource de manière à utiliser le nouveau nom. Par conséquent, vous devez agir avec prudence lorsque vous renommez un groupe d'utilisateurs. Avant de renommer votre groupe d'utilisateurs, vous devez vérifier manuellement toutes vos politiques afin d'identifier les politiques dans lesquelles le nom de ce groupe d'utilisateurs est mentionné. Par exemple, supposons que Bob est responsable des tests pour l'organisation. Bob dispose d'une politique attachée à son entité d'utilisateur IAM lui permettant d'ajouter des utilisateurs au groupe d'utilisateurs Test et d'en supprimer. Si un administrateur renomme le groupe d'utilisateurs (ou modifie le chemin d'accès au groupe), l'administrateur doit également mettre à jour la politique attachée à Bob afin d'utiliser le nouveau nom ou chemin d'accès. Sinon Bob ne sera plus en mesure d'ajouter ou de supprimer des utilisateurs du groupe d'utilisateurs. 

**Pour rechercher des politiques qui font référence à un groupe IAM en tant que ressource :**

1. Dans le panneau de navigation de la console IAM, sélectionnez **Policies** (Politiques).

1. Triez par la colonne **Type** pour rechercher vos politiques personnalisées **gérées par le client**.

1. Sélectionnez le nom de la politique à modifier.

1. Choisissez l'onglet **Autorisations**, puis **Résumé**.

1. Choisissez **IAM** dans la liste des services, si ce service est disponible.

1. Recherchez le nom de votre groupe d'utilisateurs dans la colonne **Resource** (Ressource).

1. Choisissez **Modifier** pour changer le nom de votre groupe d'utilisateurs dans la politique.

## Pour modifier le nom d'un groupe IAM
<a name="id_groups_manage_rename-section-1"></a>

------
#### [ Console ]

1. Dans le panneau de navigation, sélectionnez **Groupes d’utilisateurs**, puis sélectionnez le nom du groupe.

1. Choisissez **Modifier**. Tapez le nom du nouveau groupe d'utilisateurs, puis choisissez **Save changes (Enregistrer les modifications)**.

------
#### [ AWS CLI ]

Exécutez la commande suivante :
+ [groupe de mise à jour aws iam](https://docs.aws.amazon.com/cli/latest/reference/iam/update-group.html)

------
#### [ API ]

Appelez l’opération suivante :
+ [UpdateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateGroup.html)

------

# Supprimer un groupe IAM
<a name="id_groups_manage_delete"></a>

Lorsque vous supprimez un groupe IAM dans la console, celle-ci supprime automatiquement tous les membres du groupe, détache toutes les politiques gérées attachées et supprime toutes les politiques en ligne. Cependant, comme IAM ne supprime pas automatiquement les politiques qui font référence au groupe IAM en tant que ressource, vous devez faire attention lorsque vous supprimez un groupe IAM. Avant de supprimer votre groupe IAM, vérifiez manuellement toutes vos politiques afin d’identifier les politiques dans lesquelles le nom de ce groupe est mentionné. Par exemple, John dispose d'une politique attachée à son entité d'utilisateur IAM lui permettant d'ajouter et supprimer des utilisateurs du groupe d'utilisateurs Test. Si un administrateur supprime le groupe, l'administrateur doit également supprimer la politique attachée à John. Sinon, si l'administrateur recrée le groupe supprimé et lui donne le même nom, les autorisations de John restent en place, même s'il a quitté l'équipe de test.

En revanche, lorsque vous utilisez la CLI, les kits SDK ou l’API pour supprimer un groupe d’utilisateurs, vous devez d’abord supprimer les utilisateurs du groupe. Puis, vous supprimez toutes les politiques en ligne intégrées au groupe IAM. Ensuite, vous détachez toutes les politiques gérées attachées au groupe. Enfin, vous supprimez le groupe IAM lui-même.

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs).

1. Dans la liste des groupes IAM, cochez la case en regard du nom des groupes IAM à supprimer. Vous pouvez utiliser la zone de recherche pour filtrer la liste des groupes IAM par type, autorisations et nom de groupe.

1. Sélectionnez **Delete (Supprimer)**.

1. Dans la zone de confirmation, si vous voulez supprimer un seul groupe, saisissez son nom et choisissez **Supprimer**. Si vous voulez supprimer plusieurs groupes, saisissez le nombre de groupes IAM à supprimer suivi de **user groups** et choisissez **Supprimer**. Par exemple, si vous souhaitez supprimer trois groupes, saisissez **3 **user groups****.

------
#### [ AWS CLI ]

1. Supprimez tous les utilisateurs du groupe IAM.
   + [aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html) (pour obtenir la liste des utilisateurs du groupe IAM) et [aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html) (pour supprimer un utilisateur du groupe IAM)

1. Supprimez toutes les politiques en ligne intégrées au groupe IAM.
   + [aws iam list-group-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-group-policies.html) (pour obtenir une liste des politiques intégrées du groupe IAM) et [aws iam delete-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-group-policy.html) (pour supprimer les politiques en ligne du groupe IAM)

1. Détachez toutes les politiques gérées attachées au groupe IAM.
   + [aws iam list-attached-group-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-group-policies.html) (pour obtenir la liste des politiques gérées associées au groupe IAM) et [aws iam detach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-group-policy.html) (pour détacher une politique gérée du groupe IAM)

1. Supprimez le groupe IAM.
   + [aws iam delete-group](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-group.html)

------
#### [ API ]

1. Supprimez tous les utilisateurs du groupe IAM.
   + [GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)(pour obtenir la liste des utilisateurs du groupe IAM) et [RemoveUserFromGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveUserFromGroup.html)(pour supprimer un utilisateur du groupe IAM)

1. Supprimez toutes les politiques en ligne intégrées au groupe IAM.
   + [ListGroupPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupPolicies.html)(pour obtenir une liste des politiques intégrées du groupe IAM) et [DeleteGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroupPolicy.html)(pour supprimer les politiques en ligne du groupe IAM)

1. Détachez toutes les politiques gérées attachées au groupe IAM.
   + [ListAttachedGroupPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedGroupPolicies.html)(pour obtenir une liste des politiques gérées associées au groupe IAM) et [DetachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachGroupPolicy.html)(pour détacher une politique gérée du groupe IAM)

1. Supprimez le groupe IAM.
   + [DeleteGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html)

------

# Rôles IAM
<a name="id_roles"></a>

Un *rôle* IAM est une identité IAM que vous pouvez créer dans votre compte et qui dispose d’autorisations spécifiques. Un rôle IAM est similaire à un utilisateur IAM, car il s'agit d'une identité AWS avec des politiques d'autorisation qui déterminent ce que l'identité peut et ne peut pas faire dans AWS. En revanche, au lieu d'être associé de manière unique à une personne, un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. En outre, un rôle ne dispose pas d’informations d’identification standard à long terme comme un mot de passe ou des clés d’accès associées. Au lieu de cela, lorsque vous adoptez un rôle, il vous fournit des informations d’identification de sécurité temporaires pour votre session de rôle.

Vous pouvez utiliser des rôles pour déléguer l'accès à des utilisateurs, à des applications ou à des services qui n'ont normalement pas accès à vos AWS ressources. Par exemple, vous pouvez autoriser les utilisateurs de votre AWS compte à accéder à des ressources dont ils ne disposent pas habituellement, ou autoriser les utilisateurs d'un compte à Compte AWS accéder aux ressources d'un autre compte. Vous pouvez également autoriser une application mobile à utiliser AWS des ressources, mais ne pas intégrer de AWS clés dans l'application (où elles peuvent être difficiles à mettre à jour et où les utilisateurs peuvent éventuellement les extraire). Parfois, vous souhaitez donner AWS accès à des utilisateurs dont l'identité est déjà définie à l'extérieur AWS, par exemple dans le répertoire de votre entreprise. Ou, vous pouvez accorder l'accès à votre compte à des tiers afin de leur permettre de réaliser un audit de vos ressources.

Pour ces scénarios, vous pouvez déléguer l'accès aux AWS ressources à l'aide d'un *rôle IAM*. Cette section présente les rôles et les différentes façons de les utiliser. Elle explique également quand et comment choisir les diverses approches et comment créer, gérer, prendre (endosser) et supprimer des rôles.

**Note**  
Lorsque vous créez votre Compte AWS, aucun rôle n'est créé par défaut. Au fur et à mesure que vous ajoutez des services à votre compte, ils peuvent ajouter des rôles liés à un service pour répondre à leurs cas d'utilisation.  
 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 à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.   
Avant de pouvoir supprimer les rôles liés à un service, vous devez d'abord supprimer les ressources qui leur sont associées. Vos ressources sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.  
Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Choisissez un **Yes** (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service.

**Topics**
+ [Quand créer un utilisateur IAM (au lieu d'un rôle)](#id_which-to-choose)
+ [Termes et concepts relatifs aux rôles](#id_roles_terms-and-concepts)
+ [Ressources supplémentaires](#id_roles_additional-resources)
+ [Le problème de l'adjoint confus](confused-deputy.md)
+ [Scénarios courants de rôles IAM](id_roles_common-scenarios.md)
+ [Création d’un rôle IAM](id_roles_create.md)
+ [Gestion des rôles IAM](id_roles_manage.md)
+ [Méthodes pour assumer un rôle](id_roles_manage-assume.md)

## Quand créer un utilisateur IAM (au lieu d'un rôle)
<a name="id_which-to-choose"></a>

Nous vous recommandons de n’utiliser les utilisateurs IAM que pour les cas d’utilisation non pris en charge par la fédération d’identité. Voici certaines des fonctionnalités les plus utilisées :
+ **Charges de travail qui ne peuvent pas utiliser de rôles IAM** — Vous pouvez exécuter une charge de travail à partir d'un emplacement qui a besoin d'accéder à AWS. Dans certains cas, vous ne pouvez pas utiliser les rôles IAM pour fournir des informations d'identification temporaires, par exemple pour les WordPress plug-ins. Dans ces situations, utilisez les clés d'accès à long terme de l'utilisateur IAM pour cette charge de travail afin de vous authentifier auprès de AWS.
+ ** AWS Clients tiers** : si vous utilisez des outils qui ne prennent pas en charge l'accès avec IAM Identity Center, tels que des AWS clients tiers ou des fournisseurs qui ne sont pas hébergés sur le site AWS, utilisez les clés d'accès à long terme des utilisateurs IAM.
+ **AWS CodeCommit accès** — Si vous avez l'habitude de CodeCommit stocker votre code, vous pouvez utiliser un utilisateur IAM doté de clés SSH ou d'informations d'identification spécifiques au service pour vous authentifier CodeCommit auprès de vos référentiels. Nous vous recommandons de procéder ainsi en plus de vous servir d'un utilisateur dans IAM Identity Center pour une authentification ordinaire. Les utilisateurs d'IAM Identity Center sont les membres de votre personnel qui ont besoin d'accéder à vos applications cloud Comptes AWS ou à celles de celles-ci. Pour permettre aux utilisateurs d'accéder à vos CodeCommit référentiels sans configurer les utilisateurs IAM, vous pouvez configurer l'**git-remote-codecommit**utilitaire. Pour plus d'informations sur IAM et CodeCommit, consultez[Informations d'identification IAM pour CodeCommit : informations d'identification Git, clés SSH et AWS clés d'accès](id_credentials_ssh-keys.md). Pour plus d'informations sur la configuration de l'**git-remote-codecommit**utilitaire, consultez la section [Connexion aux AWS CodeCommit référentiels avec des informations d'identification rotatives](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials) dans le *Guide de AWS CodeCommit l'utilisateur*.
+ **Amazon Keyspaces (for Apache Cassandra) access** (Accès Amazon Keyspaces (pour Apache Cassandra)) : dans une situation où vous n'êtes pas en mesure de vous servir des utilisateurs dans IAM Identity Center, par exemple à des fins de test de compatibilité avec Cassandra, vous pouvez utiliser un utilisateur IAM avec des informations d'identification spécifiques au service pour vous authentifier auprès d'Amazon Keyspaces. Les utilisateurs d'IAM Identity Center sont les membres de votre personnel qui ont besoin d'accéder à vos applications cloud Comptes AWS ou à celles de celles-ci. Vous pouvez également vous connecter à Amazon Keyspaces à l'aide d'informations d'identification temporaires. Pour de plus d'informations, veuillez consulter [Utilisation d'informations d'identification temporaires pour se connecter à Amazon Keyspaces à l'aide d'un rôle IAM et du plugin Sigv4](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM) dans le *Guide du développeur Amazon Keyspaces (pour Apache Cassandra)*.
+ **Accès d’urgence** : dans une situation où vous n’avez pas accès à votre fournisseur d’identité et où vous devez prendre des mesures sur votre Compte AWS. La création d'utilisateurs IAM bénéficiant d'un accès d'urgence peut faire partie de votre plan de résilience. Nous vous recommandons de veiller à ce que les informations d'identification des utilisateurs d'urgence soient étroitement contrôlées et sécurisées à l'aide de l'authentification multifactorielle (MFA).

## Termes et concepts relatifs aux rôles
<a name="id_roles_terms-and-concepts"></a>

Voici quelques termes de base pour vous aider à vous familiariser avec les rôles.

****Rôle****  
Une identité IAM que vous pouvez créer dans votre compte et qui dispose d'autorisations spécifiques. Un rôle IAM présente des similitudes avec un utilisateur IAM. Les rôles et les utilisateurs sont tous deux des identités AWS avec des politiques d'autorisations qui déterminent ce que l'identité peut ou ne peut pas faire dans AWS. En revanche, au lieu d'être associé de manière unique à une personne, un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. En outre, un rôle ne dispose pas d’informations d’identification standard à long terme comme un mot de passe ou des clés d’accès associées. Au lieu de cela, lorsque vous adoptez un rôle, il vous fournit des informations d’identification de sécurité temporaires pour votre session de rôle.  
Les rôles peuvent être endossés par :  
+ Un utilisateur IAM dans le même domaine Compte AWS ou dans un autre Compte AWS
+ Rôles IAM dans le même compte
+ Principes de service, à utiliser avec des AWS services et des fonctionnalités tels que :
  + Services qui vous permettent d'exécuter du code sur des services informatiques, tels qu'Amazon EC2 ou AWS Lambda
  + Fonctionnalités qui exécutent des actions sur vos ressources en votre nom, comme la réplication d’objets Amazon S3
  + Services fournissant des informations d'identification de sécurité temporaires à vos applications exécutées en dehors de AWS, telles que IAM Roles Anywhere ou Amazon ECS Anywhere
+ Un utilisateur externe authentifié par un service de fournisseur d’identité (IdP) externe, compatible avec SAML 2.0 ou OpenID Connect.

****AWS rôle de service****  
 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*. 

****AWS rôle lié au service****  
 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 à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.   
Si vous utilisez déjà un service lorsqu'il commence à prendre en charge des rôles liés à un service, vous pouvez recevoir un e-mail vous informant de l'existence d'un nouveau rôle sur votre compte. Dans ce cas, le service crée automatiquement le rôle lié à un service sur votre compte. Aucune action de votre part n'est requise pour prendre ce rôle en charge et il est préférable de ne pas le supprimer manuellement. Pour plus d’informations, veuillez consulter [Un nouveau rôle est apparu dans mon AWS compte](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared).
Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Choisissez un **Yes** (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service. Pour de plus amples informations, veuillez consulter [Créer un rôle lié à un service](id_roles_create-service-linked-role.md).

****Création de chaînes de rôles****  
La création de chaînes de rôles se produit lorsque vous utilisez un rôle pour assumer un second rôle. Vous pouvez effectuer un chaînage des rôles via le AWS Management Console en changeant de rôle AWS CLI, de ou d'API. Par exemple, `RoleA` dispose de l'autorisation d'assumer `RoleB`. Vous pouvez autoriser User1 à assumer `RoleA` en utilisant ses informations d'identification utilisateur à long terme dans le cadre du fonctionnement de l' AssumeRoleAPI. Cette opération renvoie les informations d'identification à court terme de `RoleA`. Avec le chaînage de rôles, vous pouvez utiliser les informations d'identification à court terme de `RoleA` pour permettre à User1 d'assumer `RoleB`.  
Lorsque vous endossez un rôle, vous pouvez passer une balise de session et la définir comme transitive. Les balises de session transitives sont transmises à toutes les sessions suivantes d'une chaîne de rôles. Pour en savoir plus sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).  
Le chaînage des rôles limite votre AWS Management Console session de rôle AWS CLI ou celle de l' AWS API à une heure maximum. Elle s’applique quelle que soit la durée maximale de session configurée pour les rôles individuels. Lorsque vous utilisez l'opération [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)d'API pour assumer un rôle, vous pouvez spécifier la durée de votre session de rôle à l'aide du `DurationSeconds` paramètre. Vous pouvez spécifier une valeur de paramètre jusqu'à 43200 secondes (12 heures), en fonction du paramètre de [durée de session maximale](id_roles_update-role-settings.md#id_roles_update-session-duration) de votre rôle. Toutefois, si vous endossez un rôle à l'aide de la création de chaînes de rôles et que vous définissez une valeur de paramètre `DurationSeconds` supérieure à une heure, l'opération échoue.  
Pour plus d'informations sur le passage à un rôle dans le AWS Management Console, consultez[Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md).

****Délégation****  
L'octroi à une personne d'autorisations lui permettant d'accéder aux ressources que vous contrôlez. La délégation implique la mise en place d'une confiance entre deux comptes. Le premier est le compte propriétaire de la ressource (le compte de confiance). Le second est le compte qui contient les utilisateurs qui doivent accéder à la ressource (le compte approuvé). Les comptes d'approbation et approuvés peuvent être :  
+ Un même compte.
+ Comptes distincts se trouvant tous deux sous le contrôle de votre organisation.
+ Deux comptes appartenant à des organisations différentes.
Pour déléguer l’autorisation d’accès à une ressource, vous [créez un rôle IAM](id_roles_create_for-user.md) dans le compte d’approbation auquel sont attachées deux politiques. La *politique d'autorisation* accorde à l'utilisateur du rôle les autorisations nécessaires pour exécuter les tâches prévues sur la ressource. La *politique d'approbation* détermine les membres du compte autorisés à endosser le rôle.  
Lorsque vous créez une politique d'approbation, vous ne pouvez pas spécifier de caractère générique (\$1) comme ARN dans l'élément de principal. La politique d'approbation est attachée au rôle dans le compte d'approbation, et représente la moitié des autorisations. L'autre moitié est une politique d'autorisation attachée à l'utilisateur dans le compte approuvé qui [autorise cet utilisateur à prendre ou endosser le rôle](id_roles_use_permissions-to-switch.md). Un utilisateur qui endosse un rôle temporairement abandonne ses propres autorisations, de manière à adopter celles du rôle. Lorsque l'utilisateur quitte le rôle ou cesse de l'utiliser, ses autorisations d'origine sont restaurées. Un paramètre supplémentaire appelé [ID externe](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) permet de sécuriser l'utilisation de rôles entre des comptes qui ne sont pas contrôlés par la même organisation.

****Politique d'approbation****  
[Document de politique JSON](reference_policies_grammar.md) dans lequel vous définissez les principaux en lesquels vous avez *confiance* pour endosser le rôle. Une politique d'approbation de rôle est une [politique basée sur les ressources](access_policies.md#policies_resource-based) requise qui est attachée à un rôle dans IAM. Les [principaux](reference_policies_elements_principal.md) que vous pouvez spécifier dans la politique d'approbation comprennent les utilisateurs, les rôles, les comptes et les services. Pour plus d’informations, consultez [Comment utiliser les politiques de confiance avec les rôles IAM](https://aws.amazon.com/blogs//security/how-to-use-trust-policies-with-iam-roles/) dans le *Blog de sécuritéAWS *.

****Rôle pour l'accès entre comptes****  
Un rôle qui octroie l'accès aux ressources d'un compte à un principal approuvé d'un autre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Cependant, certains AWS services vous permettent d'associer une politique directement à une ressource (au lieu d'utiliser un rôle comme proxy). C'est ce que l'on appelle des politiques basées sur les ressources, et vous pouvez les utiliser pour accorder aux principaux un autre Compte AWS accès à la ressource. Ces ressources incluent notamment les compartiments Amazon Simple Storage Service (S3), les coffres Amazon Glacier, les rubriques Amazon Simple Notification Service (SNS) et les files d’attente Amazon Simple Queue Service (SQS). Pour connaître les services qui prennent en charge les politiques basées sur les ressources, veuillez consulter [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour plus d'informations sur les politiques basées sur les ressources, consultez [Accès intercompte aux ressources dans IAM](access_policies-cross-account-resource-access.md).

## Ressources supplémentaires
<a name="id_roles_additional-resources"></a>

Les ressources suivantes peuvent vous aider à en savoir plus sur la terminologie IAM relative aux rôles IAM.
+ Les **principaux sont des** entités AWS qui peuvent effectuer des actions et accéder aux ressources. Un principal peut être un Utilisateur racine d'un compte AWS utilisateur IAM ou un rôle. Un principal qui représente l'identité d'un AWS service est un [principal de service](reference_policies_elements_principal.md#principal-services). Utilisez l’élément Principal dans les politiques d’approbation des rôles pour définir les principaux auxquels vous faites confiance pour assumer le rôle.

   Pour plus d’informations et des exemples de principaux que vous pouvez autoriser à assumer un rôle, consultez [AWS Éléments de politique JSON : Principal](reference_policies_elements_principal.md). 
+ **La fédération d'identité** crée une relation de confiance entre un fournisseur d'identité externe et AWS. Vous pouvez utiliser votre fournisseur OpenID Connect (OIDC) ou Security Assertion Markup Language (SAML) 2.0 pour gérer les utilisateurs autorisés à accéder aux ressources AWS . Lorsque vous utilisez OIDC et SAML 2.0 pour configurer une relation de confiance entre ces fournisseurs d'identité externes AWS , un rôle IAM est attribué à l'utilisateur. L'utilisateur reçoit également des informations d'identification temporaires qui lui permettent d'accéder à vos ressources AWS .

  Pour plus d’informations sur les principaux fédérés, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md).
+ Les **principes fédérés sont des** identités existantes provenant de l'annuaire Directory Service des utilisateurs de votre entreprise ou d'un fournisseur OIDC. AWS attribue un rôle à un principal fédéré lorsque l'accès est demandé par le biais d'un fournisseur d'[identité](id_roles_providers.md).

  Pour plus d’informations sur les principaux fédérés SAML ou OIDC, consultez [sessions d’utilisateur fédéré et rôle](introduction_access-management.md#intro-access-roles).
+ Les **politiques d’autorisation** sont des politiques basées sur l’identité qui définissent les actions et les ressources que le rôle peut utiliser. Le document est écrit conformément aux règles du langage de politique IAM. 

  Pour de plus amples informations, veuillez consulter [Référence de politique JSON IAM](reference_policies.md).
+ Les **limites des autorisations** sont une fonctionnalité avancée dans laquelle vous utilisez des politiques pour limiter les autorisations maximales qu’une politique basée sur l’identité peut accorder à un rôle. Vous ne pouvez pas appliquer une limite d'autorisations à un rôle lié à un service.

  Pour de plus amples informations, veuillez consulter [Limites d'autorisations pour les entités IAM](access_policies_boundaries.md).

# Le problème de l'adjoint confus
<a name="confused-deputy"></a>

Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. Pour éviter cela, AWS fournit des outils qui vous aident à protéger votre compte si vous fournissez à des tiers (*comptes croisés*) ou à d'autres AWS services (appelés *interservices) un* accès aux ressources de votre compte.

Il peut arriver que vous deviez accorder à un tiers l'accès à vos AWS ressources (accès délégué). Par exemple, vous décidez de faire appel à une société tierce appelée Example Corp pour surveiller vos coûts Compte AWS et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Example Corp surveille également de nombreux autres Comptes AWS pour d'autres clients. Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre compte Compte AWS et le compte Example Corp. Un aspect important de ce scénario est l’*ID externe*, un identifiant facultatif que vous pouvez utiliser dans une politique d’approbation des rôles IAM afin de désigner l’utilisateur autorisé à endosser le rôle. La fonction principale de l’ID externe est de traiter et de prévenir le problème du délégué confus.

Certains AWS services (services d'appel) utilisent leur principal de AWS service pour accéder aux AWS ressources d'autres AWS services (appelés services). Dans certaines de ces interactions de service, vous pouvez configurer les services d'appel pour communiquer avec les ressources d'un service appelé dans un autre pays Compte AWS. C'est le cas, par exemple, AWS CloudTrail de la configuration pour écrire dans un compartiment Amazon S3 central situé dans un autre compartiment Compte AWS. Le service d'appel CloudTrail est autorisé à accéder à votre compartiment S3 conformément à la politique du compartiment S3 en ajoutant une instruction d'autorisation pour`cloudtrail.amazonaws.com`.

Lorsqu'un principal de AWS service d'un service appelant accède à une ressource à partir d'un service appelé, la politique de ressources du service appelé autorise uniquement le principal de AWS service, et non l'acteur qui a configuré le service d'appel. Par exemple, un compartiment S3 qui fait confiance au principal du CloudTrail service sans aucune condition peut recevoir CloudTrail des journaux de la Comptes AWS part d'un administrateur de confiance configuré, mais également CloudTrail des journaux d'un acteur non autorisé Compte AWS, s'il connaît le nom du compartiment S3.

Le problème des adjoints confus se pose lorsqu'un acteur utilise la confiance du directeur de AWS service d'un service pour accéder à des ressources auxquelles il n'est pas censé avoir accès.

## Prévention du problème de l'adjoint confus entre comptes
<a name="mitigate-confused-deputy"></a>

Le diagramme suivant illustre le problème de l'adjoint confus entre comptes.

![\[Description d'un problème de député confus.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/confuseddeputyproblem2.png)


Ce scénario suppose que :
+ **AWS 1** est votre Compte AWS.
+ **AWS 1 : ExampleRole** est un rôle dans votre compte. La politique d'approbation du rôle approuve Example Corp en désignant le compte AWS d'Example Corp comme celui qui peut endosser le rôle.

Voici ce qui se produit :

1. Lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN **AWS 1 : ExampleRole** à Example Corp.

1. Example Corp utilise cet ARN de rôle pour obtenir des informations d'identification de sécurité temporaires afin d'accéder aux ressources de votre Compte AWS. Ainsi, vous approuvez Example Corp en tant que « député » autorisé à agir pour votre compte.

1. Un autre AWS client commence également à utiliser le service d'Example Corp, et ce client fournit également l'ARN **AWS 1 : ExampleRole** for Example Corp à utiliser. On peut supposer que l'autre client a appris ou deviné le **AWS 1 : ExampleRole**, ce qui n'est pas un secret.

1. Lorsque l'autre client demande à Example Corp d'accéder aux AWS ressources (qu'il prétend être) de son compte, Example Corp utilise **AWS 1 : ExampleRole** pour accéder aux ressources de votre compte.

C'est ainsi que l'autre client peut obtenir un accès non autorisé à vos ressources. Du fait que cet autre client a été en mesure de tromper Example Corp pour agir involontairement sur vos ressources, Example Corp est à présent un « député confus ».

Exemple Corp peut résoudre le problème de l'adjoint confus en exigeant que vous incluiez la vérification de la condition `ExternalId` dans la politique d'approbation du rôle. Exemple Corp génère une valeur `ExternalId` unique pour chaque client et utilise cette valeur dans sa demande de prise en charge du rôle. La valeur `ExternalId` doit être unique parmi les clients d'Example Corp et contrôlée par Example Corp, et non par ses clients. C'est pourquoi vous l'obtenez d'Example Corp et que vous ne créez pas le vôtre. Cela évite à Example Corp d'être un adjoint confus et d'accorder l'accès aux AWS ressources d'un autre compte.

Dans notre scénario, imaginez que l'identifiant unique d'Example Corp pour vous soit 12345, et que son identifiant pour l'autre client soit 67890. Ces identifiants sont simplifiés pour ce scénario. En général, ces identifiants sont GUIDs. Supposons que ces identifiants sont uniques pour chaque client d'Example Corp, ils constituent des valeurs sensibles à utiliser pour l'ID externe. 

Example Corp vous attribue la valeur d'ID externe 12345. Vous devez ensuite ajouter un élément `Condition` à la politique d’approbation du rôle qui nécessite que la valeur de [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts) soit 12345, comme suit :

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}
```

------

L'élément Condition de cette politique permet à Example Corp d'assumer le rôle uniquement lorsque l'appel d' AssumeRole API inclut la valeur d'ID externe 12345. Example Corp s'assure que chaque fois qu'elle assume un rôle au nom d'un client, elle inclut toujours la valeur d'identifiant externe de ce client dans l' AssumeRole appel. Même si un autre client fournit votre ARN à Example Corp, il ne peut pas contrôler l'ID externe qu'Example Corp inclut dans sa demande AWS. Cela permet d'éviter qu'un client non autorisé obtienne l'accès à vos ressources.

Le schéma suivant illustre ce processus.

![\[Procédure pour résoudre un problème de député confus.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/confuseddeputymitigation2.png)


1. Comme précédemment, lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN **AWS 1 : ExampleRole à Example** Corp.

1.  Lorsque Example Corp utilise ce rôle ARN pour assumer le rôle **AWS 1 : ExampleRole**, Example Corp inclut votre ID externe (12345) dans l'appel d' AssumeRole API. L'ID externe correspond à la politique de confiance du rôle. Ainsi, l'appel d' AssumeRole API aboutit et Example Corp obtient des informations de sécurité temporaires pour accéder aux ressources de votre. Compte AWS

1. Un autre AWS client commence également à utiliser le service d'Example Corp et, comme auparavant, ce client fournit également l'ARN **AWS 1 : ExampleRole** for Example Corp à utiliser. 

1. Mais cette fois, lorsque Example Corp tente d'assumer le rôle **AWS 1 : ExampleRole**, elle fournit l'ID externe associé à l'autre client (67890). L'autre client est dans l'impossibilité de changer cela. Example Corp procède ainsi, car la demande pour utiliser le rôle provient de l'autre client, 67890 indique donc les circonstances dans lesquelles Example Corp agit. Comme vous avez ajouté une condition avec votre propre ID externe (12345) à la politique de confiance de **AWS 1 : ExampleRole**, l'appel d' AssumeRole API échoue. L'autre client se voit refuser l'autorisation d'accéder aux ressources de votre compte (indiqué par la croix « X » rouge dans le diagramme).

L'ID externe empêche tout autre client de forcer Example Corp de manière trompeuse à accéder involontairement à vos ressources.

## Prévention du problème de l’adjoint confus entre services
<a name="cross-service-confused-deputy-prevention"></a>

Le schéma suivant illustre le problème de confusion entre les services adjoints en utilisant l' CloudTrail exemple d'interaction avec Amazon S3, dans lequel un acteur non autorisé écrit CloudTrail des journaux dans un compartiment Amazon S3 auquel il n'est pas autorisé à accéder.

![\[Un acteur non autorisé est autorisé à accéder à un compartiment Amazon S3 dans un autre compte en utilisant le CloudTrail service principal.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/cross-service-confused-deputy1.png)


Pour éviter qu'un acteur non autorisé n'utilise la confiance d'un AWS mandant pour accéder à vos ressources, les responsables de AWS service incluent des informations sur la AWS ressource et AWS l'organisation pour laquelle ils agissent pour le compte. Compte AWS

Ces informations sont disponibles sous forme de valeurs de clé de condition globale qui peuvent être utilisées dans une politique de ressources ou dans une politique de contrôle des ressources pour les demandes effectuées par les principaux AWS fournisseurs de service. Nous vous recommandons d'utiliser [aws:SourceArn](reference_policies_condition-keys.md#condition-keys-sourcearn)[aws:SourceAccount](reference_policies_condition-keys.md#condition-keys-sourceaccount),[aws:SourceOrgID](reference_policies_condition-keys.md#condition-keys-sourceorgid), ou [aws:SourceOrgPaths](reference_policies_condition-keys.md#condition-keys-sourceorgpaths) dans vos politiques de ressources chaque fois qu'un directeur de AWS service est autorisé à accéder à l'une de vos ressources. Ces clés de condition vous permettent de tester dans vos politiques de ressources, ou vos politiques de contrôle des ressources, que les responsables de AWS service accédant à vos ressources le font au nom des AWS ressources Comptes AWS, ou comme AWS Organizations vous vous y attendez.
+ `aws:SourceArn`À utiliser pour autoriser un directeur de AWS service à accéder à vos ressources au nom d'une ressource spécifique, telle qu'un AWS CloudTrail sentier ou une AppStream flotte spécifique.
+ `aws:SourceAccount`À utiliser pour autoriser un directeur AWS de service à accéder à vos ressources pour le compte d'une personne en particulier Compte AWS.
+ `aws:SourceOrgID`À utiliser pour autoriser un directeur AWS de service à accéder à vos ressources pour le compte d'un particulier AWS Organizations.
+ `aws:SourceOrgPaths`À utiliser pour autoriser le principal de AWS service à accéder à vos ressources au nom d'un AWS Organizations chemin spécifique.

Le schéma suivant illustre le scénario d'un adjoint confus entre services lorsqu'une ressource est configurée avec la clé de contexte de condition `aws:SourceAccount` globale et qu'un acteur non autorisé d'un autre compte tente d'accéder à AWS des ressources auxquelles il n'est pas censé avoir accès.

![\[Un acteur non autorisé se voit refuser l'accès à un compartiment Amazon S3 dans un autre compte en utilisant le CloudTrail service principal.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/cross-service-confused-deputy2.png)


L’utilisation des clés de condition globales `aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID` et `aws:SourceOrgPaths` dans une politique vous aide à vous assurer que les principaux de service accèdent à vos ressources en votre nom. Nous recommandons d'utiliser ces clés de condition chaque fois que l'accès à l'une de vos ressources est accordé à un principal AWS de service. 

**Note**  
Certaines Service AWS interactions comportent des contrôles supplémentaires qui permettent de se protéger contre les problèmes liés à la confusion entre les services qui mettent à l'épreuve l'accès des utilisateurs à une ressource. Par exemple, lorsqu'une attribution de clé KMS est accordée à un Service AWS, AWS KMS utilise le contexte de chiffrement associé à la ressource et l'attribution de clé pour éviter les problèmes de confusion entre les services auxiliaires.  
Veuillez consulter la documentation des services que vous utilisez pour plus d’informations sur les mécanismes spécifiques à chaque service qui peuvent aider à éviter les risques d’adjoint confus entre les services, et pour savoir si `aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID`, et `aws:SourceOrgPaths` sont pris en charge.

## Protection des adjoints confus entre les services avec des politiques basées sur les ressources
<a name="cross-service-confused-deputy-prevention-resource"></a>

L'exemple de politique suivant accorde au principal de service l'`cloudtrail.amazonaws.com`accès au compartiment Amazon S3, arn:aws:s3 : ::amzn-s3-demo-bucket1, uniquement lorsque le principal de service agit pour le compte de 111122223333. Compte AWS 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CloudTrailAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        },
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        }
    ]
}
```

------

Cet exemple de politique de compartiment accorde au principal du service l'`appstream.amazonaws.com`accès au script PowerShell examplefile.psh sur le site s3://amzn-s3-demo-bucket2 uniquement lorsqu'il agit pour le compte de la AppStream flotte Amazon spécifiée, en spécifiant l'ARN de la flotte avec. `aws:SourceArn`

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/ExampleFleetName"
                } 
            }
        }
    ]
}
```

------

## Protection des adjoints confus entre les services avec des politiques de contrôle des ressources
<a name="cross-service-confused-deputy-prevention-resource-control"></a>

Vous pouvez utiliser les politiques de contrôle des ressources (RCP) pour appliquer des contrôles adjoints interservices confus aux ressources prises en charge. Services AWS RCPs vous permettent d'appliquer de manière centralisée des contrôles adjoints interservices confus sur vos ressources. Vous pouvez utiliser des clés de condition telles que `aws:SourceOrgId` `aws:SourceOrgPaths` celles RCPs associées à vos AWS Organizations unités organisationnelles (UO) ou Comptes AWS au sein de votre organisation sans ajouter d'instructions à des politiques spécifiques basées sur les ressources. Pour plus d'informations sur les services pris en charge RCPs et les services pris en charge, consultez la section [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*.

Dans l'exemple suivant, le RCP refuse aux principaux de AWS service l'accès aux compartiments Amazon S3 de vos comptes membres lorsque la valeur n'`aws:SourceOrgID`est pas égale à o-. ExampleOrg Une autorisation correspondante doit être présente dans la politique basée sur les ressources du compartiment S3 pour autoriser Service AWS les principaux ayant une `SourceOrgID` valeur égale à o-. ExampleOrg

Cette politique n’applique le contrôle que sur les demandes des principaux de service (`"Bool": {"aws:PrincipalIsAWSService": "true"}`) qui ont la clé `aws:SourceAccount` présente (`"Null": {"aws:SourceAccount": "false"}`), de sorte que les intégrations de services qui ne nécessitent pas l’utilisation de la clé de condition et les appels de vos principaux ne sont pas impactés. Si la clé de condition `aws:SourceAccount` est présente dans le contexte de la demande, la condition Null sera évaluée comme vraie, ce qui entraînera l’application de `aws:SourceOrgID`. Nous utilisons `aws:SourceAccount` au lieu de `aws:SourceOrgID` dans l’opérateur de condition Null afin que le contrôle s’applique toujours si la demande provient d’un compte qui n’appartient pas à une organisation.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "RCPEnforceConfusedDeputyProtectionForS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceOrgID": "o-ExampleOrg"
        },
        "Null": {
          "aws:SourceAccount": "false"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        }
      }
    }
  ]
}
```

------

# Scénarios courants de rôles IAM
<a name="id_roles_common-scenarios"></a>

Comme pour la plupart des AWS fonctionnalités, vous pouvez généralement utiliser un rôle de deux manières : de manière interactive dans la console IAM ou par programmation avec les outils pour Windows PowerShell ou l' AWS CLI API.
+ Les utilisateurs IAM de votre compte qui utilisent la console IAM peuvent *basculer* vers un rôle leur permettant d'utiliser temporairement les autorisation du rôle dans la console. Les utilisateurs abandonnent leurs autorisations d'origine et acceptent les autorisations attribuées au rôle. Lorsque les utilisateurs quittent le rôle, leurs autorisations d'origine sont restaurées.
+ Une application ou un service proposé par AWS (comme Amazon EC2) peut *assumer* un rôle en demandant des informations d'identification de sécurité temporaires pour un rôle auquel envoyer des demandes programmatiques. AWS Vous utilisez ce rôle ainsi pour éviter de partager ou de conserver des informations d'identification de sécurité à long terme (par exemple, en créant un utilisateur IAM) pour chaque entité qui doit accéder à une ressource.

**Note**  
Ce manuel utilise les phrases *passer à un rôle* et *endosser un rôle* de manière interchangeable.

La forme d'utilisation des rôles la plus simple consiste à accorder à vos utilisateurs IAM l'autorisation de basculer vers des rôles que vous créez au sein de votre propre entreprise ou d'une autre Compte AWS. Ils peuvent changer de rôles facilement à l'aide de la console IAM pour utiliser des autorisations dont vous ne souhaitez pas qu'ils disposent d'ordinaire et il leur suffit de quitter le rôle pour renoncer à ces autorisations. Cela permet d'empêcher un accès *accidentel* à des ressources sensibles ou leur modification involontaire.

Pour utiliser les rôles de manière plus complexe, comme accorder l'accès à des applications et des services, ou à des utilisateurs externes fédérés, vous pouvez appeler l'API `AssumeRole`. Cet appel d'API renvoie un ensemble d'informations d'identification temporaires que l'application peut utiliser dans les appels d'API suivants. Les tentatives d'actions avec les informations d'identification temporaires ne disposent que des autorisations accordées par le rôle associé. Une application n'a pas besoin de « quitter » le rôle de la même manière qu'un utilisateur dans la console. L'application arrête simplement d'utiliser les informations d'identification temporaires et reprend ses appels avec les informations d'identification d'origine.

Les utilisateurs fédérés se connectent à l'aide des informations d'identification d'un fournisseur d'identité (IdP). AWS fournit ensuite des informations d'identification temporaires à l'IdP de confiance à transmettre à l'utilisateur pour les inclure dans les demandes de AWS ressources ultérieures. Ces informations d'identification fournissent des autorisations accordées au rôle attribué.

Cette section présente les scénarios suivants :
+ [Donnez accès à un utilisateur IAM dans un compte Compte AWS que vous possédez pour accéder aux ressources d'un autre compte que vous possédez](id_roles_common-scenarios_aws-accounts.md)
+ [Fournir un accès aux charges de travail qui n'appartiennent pas à AWS](id_roles_common-scenarios_non-aws.md)
+ [Octroyer un accès aux utilisateurs IAM dans des Comptes AWS appartenant à des tierces parties](id_roles_common-scenarios_third-party.md)
+ [Fournir un accès aux services offerts par AWS deux AWS ressources](id_roles_common-scenarios_services.md)
+ [Octroi de l'accès à des utilisateurs authentifiés en externe (fédération d'identité)](id_roles_common-scenarios_federated-users.md)

# Accès pour un utilisateur IAM à un autre utilisateur Compte AWS dont vous êtes le propriétaire
<a name="id_roles_common-scenarios_aws-accounts"></a>

Vous pouvez autoriser vos utilisateurs IAM à passer à des rôles au sein de vous Compte AWS ou à des rôles définis dans d'autres rôles Comptes AWS que vous possédez. 

**Note**  
Si vous souhaitez accorder l'accès à un compte que ne vous appartenant pas ou que vous ne contrôlez pas, consultez [Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md) ultérieurement dans cette rubrique. 

Imaginons que vous disposez d'instances Amazon EC2 qui sont critiques pour votre organisation. Au lieu d'accorder directement à vos utilisateurs l'autorisation de supprimer les instances, vous pouvez créer un rôle avec ces privilèges. Ensuite, autorisez les administrateurs à passer au rôle lorsqu'ils ont besoin de supprimer une instance. Cela ajoute les couches de protection suivantes aux instances :
+ Vous devez accorder explicitement à vos utilisateurs l'autorisation d'endosser le rôle.
+ Vos utilisateurs doivent passer activement au rôle à l'aide de l'API AWS Management Console or ou assumer le rôle à l'aide de l' AWS API AWS CLI or.
+ Vous pouvez ajouter une protection d'authentification multi-facteur (MFA) au rôle afin que seuls les utilisateurs qui se connectent avec un dispositif MFA puissent endosser le rôle. Pour apprendre à configurer un rôle afin que les utilisateurs qui l'endossent doivent d'abord être authentifiés à l'aide de l'authentification multi-facteur (MFA), consultez [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md).

Nous vous recommandons d'utiliser cette approche pour appliquer le *principe du moindre privilège*. Cela implique de restreindre l'utilisation des autorisations d'un niveau élevé aux seules fois où elles sont requises pour des tâches spécifiques. Grâce aux rôles, vous pouvez empêcher les modifications accidentelles apportées aux environnements sensibles, en particulier si vous les combinez à des [audits](cloudtrail-integration.md) pour vous assurer que les rôles sont utilisés uniquement quand ils sont requis.

Lorsque vous créez un rôle à cette fin, vous spécifiez les comptes en fonction de l'ID des utilisateurs ayant besoin d'accéder à l'élément `Principal` de la politique d'approbation du rôle. Vous pouvez ensuite accorder à des utilisateurs spécifiques de ces autres comptes des autorisations à passer au rôle. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez [Qu'est-ce qu'IAM Access Analyzer ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).

Un utilisateur d'un compte peut passer à un rôle dans le même compte ou dans un autre compte. Lorsqu'il utilise le rôle, l'utilisateur peut exécuter uniquement les actions et accéder uniquement aux ressources autorisées par le rôle. Leurs autorisations utilisateur d'origine sont suspendues. Lorsque l'utilisateur quitte le rôle, ses autorisations utilisateur d'origine sont restaurées.

## Exemple de scénario utilisant des comptes de développement et de production distincts
<a name="id_roles_common-scenarios_aws-accounts-example"></a>

Imaginez que votre entreprise en dispose de plusieurs Comptes AWS pour isoler un environnement de développement d'un environnement de production. Les utilisateurs du compte de développement peuvent parfois avoir besoin d'accéder aux ressources du compte de production. Par exemple, vous pouvez avoir besoin d'un accès entre comptes lorsque vous promouvez une mise à jour depuis l'environnement de développement vers l'environnement de production. Même si vous pouvez créer des identités (et mots de passe) distinctes pour les utilisateurs qui travaillent dans les deux comptes, la gestion des informations d'identification pour plusieurs comptes rend la gestion des identités difficile. Dans l'illustration suivante, tous les utilisateurs sont gérés dans le compte de développement, mais certains développeurs nécessitent un accès limité au compte de production. Le compte de développement se compose de deux groupes : les Développeurs et les Testeurs, chacun disposant de sa propre politique.

![\[Utiliser un rôle pour déléguer des autorisations à un utilisateur dans un autre compte\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)


1. Dans le compte de production, un administrateur utilise IAM pour créer le rôle `UpdateApp` dans ce compte. Dans le rôle, l'administrateur définit une politique d'approbation qui spécifie le compte de développement en tant que `Principal`, ce qui signifie que les utilisateurs autorisés du compte de développement peuvent utiliser le rôle `UpdateApp`. L'administrateur définit également une politique d'autorisations pour le rôle qui spécifie les autorisations de lecture et d'écriture sur le compartiment Amazon S3 appelé `productionapp`.

   L'administrateur partage ensuite les informations appropriées avec toute personne qui doit endosser le rôle. Ces informations sont le numéro de compte et le nom du rôle (pour les utilisateurs de AWS console) ou le nom de ressource Amazon (ARN) (pour AWS CLI AWS l'accès à l'API). L'ARN du rôle peut ressembler à `arn:aws:iam::123456789012:role/UpdateApp`, où le rôle est appelé `UpdateApp`. Le rôle a été créé dans le compte dont le numéro est 123456789012.
**Note**  
L'administrateur peut, facultativement, configurer le rôle afin que les utilisateurs qui endossent le rôle doivent d'abord être authentifiés à l'aide de l'authentification multi-facteur (MFA). Pour plus d’informations, veuillez consulter [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md). 

1. Dans le compte de développement, un administrateur accorde aux membres du groupe Développeurs l'autorisation de changer de rôle. Cela se fait en accordant au groupe de développeurs l'autorisation d'appeler l'`AssumeRole`API AWS Security Token Service (AWS STS) pour le `UpdateApp` rôle. Tout utilisateur IAM appartenant au groupe Développeurs dans le compte de développement peut à présent basculer vers le rôle `UpdateApp` du compte de production. Les autres utilisateurs n'appartenant pas au groupe de développeurs n'ont pas l'autorisation de passer au rôle et ne peuvent, donc, pas accéder au compartiment S3 dans le compte de production.

1. L'utilisateur demande les changements de rôle :
   + AWS console : l'utilisateur choisit le nom du compte dans la barre de navigation et choisit **Switch Role**. L'utilisateur spécifie l'ID (ou l'alias) du compte, ainsi que le nom du rôle. Sinon, l'utilisateur peut cliquer sur un lien envoyé par e-mail par l'administrateur. Le lien dirige l'utilisateur vers la page **Changer de rôle** avec les détails déjà remplis.
   + AWS API/AWS CLI : Un utilisateur du groupe Développeurs du compte de développement appelle la `AssumeRole` fonction pour obtenir les informations d'identification du `UpdateApp` rôle. L'utilisateur spécifie l'ARN du rôle `UpdateApp` dans le cadre de l'appel. Si un utilisateur du groupe Testeurs fait la même demande, la demande échoue, car les Testeurs ne sont pas autorisés à appeler `AssumeRole` pour l'ARN de rôle `UpdateApp`.

1. AWS STS renvoie des informations d'identification temporaires :
   + AWS console : AWS STS vérifie la demande avec la politique de confiance du rôle pour s'assurer que la demande provient d'une entité de confiance (il s'agit du compte de développement). Après vérification, AWS STS renvoie les [informations d'identification de sécurité temporaires](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) à la AWS console.
   + API/CLI : AWS STS vérifie la demande par rapport à la politique de confiance du rôle pour s'assurer que la demande provient d'une entité de confiance (il s'agit du compte de développement). Après vérification, AWS STS renvoie les [informations de sécurité temporaires](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) à l'application.

1. Les informations d'identification temporaires permettent d'accéder à la AWS ressource :
   + AWS console : la AWS console utilise les informations d'identification temporaires au nom de l'utilisateur pour toutes les actions de console suivantes, dans ce cas, pour lire et écrire dans le `productionapp` compartiment. La console ne peut pas accéder à d'autres ressources du compte de production. Lorsque l'utilisateur quitte le rôle, les autorisations dont ils disposait avant de changer de rôle sont restaurées.
   + API/CLI : L'application utilise les informations d'identification de sécurité temporaires pour mettre à jour le compartiment `productionapp`. Avec les informations d'identification de sécurité temporaires, l'application peut uniquement lire et écrire dans le compartiment `productionapp`, mais ne peut pas accéder à d'autres ressources du compte Production. L'application n'a pas besoin de quitter le rôle. Au contraire, elle arrête d'utiliser les informations d'identification temporaires et utilise les informations d'identification d'origine dans les appels d'API suivants.

## Ressources supplémentaires
<a name="id_roles_common-scenarios_more-info"></a>

Pour plus d’informations, consultez les ressources suivantes :
+ [Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md)

# Accès pour les applications autres que les charges AWS de travail
<a name="id_roles_common-scenarios_non-aws"></a>

[Un [rôle IAM](id_roles.md) est un objet dans Gestion des identités et des accès AWS (IAM) auquel des autorisations sont attribuées.](access_policies.md) Lorsque vous [assumez ce rôle](id_roles_manage-assume.md) en utilisant une identité IAM ou une identité extérieure AWS, cela vous fournit des informations d'identification de sécurité temporaires pour votre session de rôle. Il se peut que des charges de travail s'exécutent dans votre centre de données ou dans d'autres infrastructures extérieures AWS qui doivent accéder à vos AWS ressources. Au lieu de créer, de distribuer et de gérer des clés d'accès à long terme, vous pouvez utiliser Gestion des identités et des accès AWS Roles Anywhere (IAM Roles Anywhere) pour authentifier vos applications non AWS liées à des charges de travail. IAM Roles Anywhere utilise les certificats X.509 de votre autorité de certification (CA) pour authentifier les identités et fournir un accès sécurisé à l' Services AWS aide des informations d'identification temporaires fournies par un rôle IAM.

**Pour utiliser Rôles Anywhere IAM**

1. Configurez une autorité de certification à l’aide de [AWS Autorité de certification privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) ou utilisez une autorité de certification issue de votre propre infrastructure PKI.

1. Après avoir configuré une autorité de certification, vous créez un objet dans Rôles Anywhere IAM appelé *ancre d’approbation*. Ce point d’ancrage établit une approbation entre Rôles Anywhere IAM et votre autorité de certification pour l’authentification.

1. Vous pouvez ensuite configurer vos rôles IAM existants ou créer de nouveaux rôles qui font confiance au service IAM Roles Anywhere.

1. Authentifiez vos tâches non liées aux AWS charges de travail avec IAM Roles Anywhere à l'aide de l'ancre de confiance. AWS accorde les informations d'identification temporaires non liées à la AWS charge de travail au rôle IAM qui a accès à vos AWS ressources.

## Ressources supplémentaires
<a name="id_roles_non-aws_additional_resources"></a>

Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d’un accès aux charges de travail non AWS .
+ Pour plus d'informations sur IAM Roles Anywhere, consultez [Présentation de Gestion des identités et des accès AWS Rôle Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) dans le *Guide de l'utilisateur d'IAM Roles Anywhere*.
+ Pour savoir comment configurer une infrastructure à clé publique (PKI) pour Rôles Anywhere IAM, consultez la section [Rôles Anywhere IAM avec une autorité de certification externe](https://aws.amazon.com/blogs/) sur le *Blog de sécuritéAWS *.

# Accès à des Comptes AWS sites appartenant à des tiers
<a name="id_roles_common-scenarios_third-party"></a>

Lorsque des tiers ont besoin d'accéder aux AWS ressources de votre organisation, vous pouvez utiliser des rôles pour leur déléguer l'accès. Par exemple, un tiers peut fournir un service de gestion de vos ressources AWS . Avec les rôles IAM, vous pouvez accorder à ces tiers l'accès à vos AWS ressources sans partager vos informations d'identification AWS de sécurité. Au lieu de cela, le tiers peut accéder à vos AWS ressources en assumant un rôle que vous créez dans votre Compte AWS. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez [Qu'est-ce qu'IAM Access Analyzer ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).

Les tiers doivent vous fournir les informations suivantes pour vous permettre de créer un rôle qu'ils peuvent endosser :
+ **L' Compte AWS identifiant du tiers**. Vous spécifiez leur ID d' Compte AWS en tant que principal lorsque vous définissez la politique d'approbation pour le rôle.
+ **Un ID externe à attacher uniquement à ce rôle**. L'ID externe peut être n'importe quel identifiant qui n'est connu que de vous et de la tierce partie. Par exemple, vous pouvez utiliser un ID de facture entre les tiers et vous-même, mais n'utilisez aucun élément pouvant être deviné, tels que le nom ou le numéro de téléphone du tiers. Vous devez spécifier cet ID lorsque vous définissez la politique d'approbation pour le rôle. Les tiers doivent fournir cette ID lorsqu'ils endosser le rôle.
+ **Les autorisations dont le tiers a besoin pour utiliser vos ressources  AWS **. Vous devez spécifier ces autorisations lors de la définition de la politique d'autorisation du rôle. Cette politique définit les actions que les utilisateurs tiers peuvent entreprendre et les ressources auxquelles ils peuvent accéder.

Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle au tiers. Il a besoin de l'ARN de votre rôle pour endosser le rôle.

**Important**  
Lorsque vous accordez à des tiers l'accès à vos AWS ressources, ils peuvent accéder à toutes les ressources que vous spécifiez dans la politique. L'utilisation de vos ressources par ces tiers vous est facturée. Veillez à limiter leur utilisation de vos ressources de façon appropriée.

## IDs Externe pour accès par des tiers
<a name="id_roles_third-party_external-id"></a>

Un identifiant externe permet à l’utilisateur qui assume le rôle d’affirmer les circonstances dans lesquelles il travaille. Il permet également au titulaire du compte d'autoriser que le rôle soit endossé uniquement dans des circonstances spécifiques. La fonction principale de l'ID externe consiste à traiter et à prévenir [Le problème de l'adjoint confus](confused-deputy.md).

**Important**  
AWS ne traite pas l'identifiant externe comme un secret. Une fois que vous avez créé un secret, tel qu'une paire de clés d'accès ou un mot de passe AWS, vous ne pouvez plus le consulter. L'ID externe d'un rôle peut être vu par toute personne autorisée à consulter le rôle. 

## Quand est-il conseillé d'utiliser un ID externe ?
<a name="external-id-use"></a>

Utilisez un ID externe dans les situations suivantes :
+ Vous êtes Compte AWS propriétaire et vous avez configuré un rôle pour un tiers qui accède Comptes AWS à d'autres rôles que le vôtre. Vous devez demander à ce tiers un ID externe qu'il inclura lorsqu'il endossera votre rôle. Ensuite, vous vérifiez cet ID externe dans la politique d'approbation de votre rôle. Ainsi, la tierce partie peut endosser votre rôle uniquement lorsqu'elle agit en votre nom.
+ Vous êtes en position d'endosser des rôles pour le compte de différents clients comme Exemple Corp dans notre précédent scénario. Vous devez attribuer un ID externe unique à chaque client et leur demander de l'ajouter à leur politique d'approbation du rôle. Vous devez ensuite vous assurer de toujours inclure l'ID externe correct dans vos demandes pour endosser des rôles.

  Vous disposez probablement déjà d'un identifiant unique pour chacun de vos clients, et cet ID unique est suffisant pour être utilisé comme ID externe. L'ID externe n'est pas une valeur spéciale que vous devez créer de manière explicite, ou suivre séparément, juste à cette fin.

  Vous devez toujours spécifier l'ID externe dans vos appels d'API `AssumeRole`. De plus, lorsqu'un client vous fournit un ARN de rôle, vérifiez que vous pouvez endosser le rôle avec et sans l'ID externe correct. Si vous pouvez endosser le rôle sans l'ID externe approprié, ne stockez pas l'ARN du rôle du client dans votre système. Attendez que le client mette à jour la politique d'approbation du rôle pour demander l'ID externe. Ainsi, vous aidez vos clients à faire ce qu'il faut, ce qui vous permet de vous protéger tous les deux contre le problème du député confus.

## Exemple de scénario utilisant un ID externe
<a name="id_roles_third-party_example"></a>

Supposons, par exemple, que vous décidiez de faire appel à une société tierce appelée Example Corp pour surveiller vos coûts Compte AWS et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Example Corp surveille également de nombreux autres comptes AWS pour d'autres clients.

Ne donnez pas à Exemple Corp l'accès à un utilisateur IAM et à ses informations d'identification à long terme dans votre compte AWS . Utilisez plutôt un rôle IAM et ses informations d'identification de sécurité temporaires. Un rôle IAM fournit un mécanisme permettant à un tiers d'accéder à vos AWS ressources sans avoir à partager des informations d'identification à long terme (telles qu'une clé d'accès utilisateur IAM).

Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre Compte AWS et le compte Exemple Corp. Une fois cette relation établie, un membre du compte Example Corp peut appeler l' AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API pour obtenir des informations d'identification de sécurité temporaires. Les membres d'Example Corp peuvent ensuite utiliser les informations d'identification pour accéder aux AWS ressources de votre compte. 

**Note**  
Pour plus d'informations sur les opérations d' AWS API AssumeRole et sur les autres opérations que vous pouvez appeler pour obtenir des informations d'identification de sécurité temporaires, consultez[Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md).

Voici comment s'articule ce scénario :

1. Vous embauchez Example Corp qui crée un identifiant client unique pour vous. Ils vous fournissent cet identifiant client unique et leur Compte AWS numéro. Vous avez besoin de ces informations pour créer un rôle IAM à l'étape suivante. 
**Note**  
Example Corp peut utiliser n'importe quelle valeur de chaîne pour le ExternalId, à condition qu'elle soit unique pour chaque client. Il peut s'agir d'un numéro de compte client ou encore d'une chaîne aléatoire de caractères, à condition que chaque client ait une valeur différente. Elle n'est pas censée être « secrète ». Example Corp doit fournir la ExternalId valeur à chaque client. Ce qui compte, c'est qu'elle soit générée par Example Corp et ***non*** par ses clients afin de garantir que chaque ID externe est unique.

1. Vous vous connectez AWS et créez un rôle IAM qui permet à Example Corp d'accéder à vos ressources. Comme tout autre rôle IAM, celui-ci dispose de deux politiques, une politique d'autorisation et une politique d'approbation. La politique d'approbation du rôle spécifie qui peut endosser le rôle. Dans notre exemple de scénario, la politique spécifie le Compte AWS nombre d'Example Corp comme étant le`Principal`. Cela permet aux identités de ce compte d'endosser le rôle. En outre, vous ajoutez un élément `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` à la politique d'approbation. Cette `Condition` teste la clé de contexte `ExternalId` afin de s'assurer qu'elle correspond à l'ID client unique issu d'Exemple Corp. Exemple :

   ```
       "Principal": {"AWS": "Example Corp's Compte AWS ID"},
       "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
   ```

1. La politique d'autorisation du rôle spécifie ce que le rôle permet à un utilisateur de faire. Par exemple, vous pouvez spécifier que le rôle permet à un utilisateur de gérer uniquement vos ressources Amazon EC2 et Amazon RDS, mais pas vos utilisateurs ou groupes IAM. Dans notre exemple de scénario, vous utilisez la politique d'autorisation pour accorder à Example Corp un accès en lecture seule à toutes les ressources de votre compte.

1. Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle à Example Corp.

1. Lorsque Example Corp a besoin d'accéder à vos AWS ressources, un membre de l'entreprise appelle l' AWS `sts:AssumeRole`API. L'appel inclut l'ARN du rôle à assumer et le ExternalId paramètre correspondant à leur identifiant client.

Si la demande provient d'une personne utilisant Example Corp Compte AWS, et si l'ARN du rôle et l'ID externe sont corrects, la demande aboutit. Il fournit ensuite des informations de sécurité temporaires qu'Example Corp peut utiliser pour accéder aux AWS ressources autorisées par votre rôle.

Autrement dit, quand une politique de rôle inclut un ID externe, tous ceux qui souhaitent endosser le rôle doivent non seulement être spécifiés comme principaux dans le rôle, mais également inclure l'ID externe correct.

## Points clés pour les acteurs externes IDs
<a name="id_roles_third-party_key-points"></a>
+ Dans un environnement mutualisé où vous prenez en charge plusieurs clients avec différents AWS comptes, nous vous recommandons d'utiliser un identifiant externe par Compte AWS client. Cet ID doit être une chaîne aléatoire générée par le tiers.
+ Pour exiger que le tiers fournisse un ID externe lors de la prise en charge d'un rôle, mettez à jour la politique d'approbation du rôle avec l'ID externe de votre choix.
+ Pour fournir un identifiant externe lorsque vous assumez un rôle, utilisez l' AWS API AWS CLI or pour assumer ce rôle. Pour plus d'informations, consultez l'opération de l'[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API STS ou l'opération de la [CLI STS assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html).
+ La valeur `ExternalId` peut avoir un minimum de 2 caractères et un maximum de 1 224 caractères. La valeur doit être alphanumérique sans espaces. Elle peut également inclure les symboles suivants : signe plus (\$1), signe égal (=), virgule (,), point (.), arobase (@), deux points (:), barre oblique (/) et tiret (-).

## Ressources supplémentaires
<a name="id_roles_third-party_additional_resources"></a>

Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d’un accès aux Comptes AWS appartenant à des tiers.
+ Pour savoir comment autoriser d'autres personnes à effectuer des actions dans le vôtre Compte AWS, consultez[Création d’un rôle à l’aide de politiques d’approbation personnalisées](id_roles_create_for-custom.md).
+ Pour savoir comment accorder l’autorisation de basculer vers un rôle, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md)
+ Pour savoir comment créer et fournir à des utilisateurs de confiance des informations d’identification de sécurité temporaires, [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md).

# Accès à un AWS service
<a name="id_roles_common-scenarios_services"></a>

De nombreux AWS services nécessitent que vous utilisiez des rôles pour contrôler les accès auxquels ils peuvent accéder. Un rôle qu'un service endosse pour effectuer des actions en votre nom s'appelle un [rôle de service](id_roles.md#iam-term-service-role). Lorsqu’un rôle de service remplit un objectif spécial pour un service, il peut être défini comme [rôle lié à un service](id_roles.md#iam-term-service-linked-role). Consultez la [documentation AWS](https://docs.aws.amazon.com/) spécifique à chaque service pour vérifier s'il utilise des rôles et apprendre à attribuer un rôle au service afin qu'il l'utilise.

Pour plus de détails sur la création d'un rôle permettant de déléguer l'accès à un service proposé par AWS, consultez[Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md).

# Accès aux utilisateurs authentifiés en externe (fédération d’identité)
<a name="id_roles_common-scenarios_federated-users"></a>

Vos utilisateurs ont peut-être déjà une identité extérieure AWS, par exemple dans votre annuaire d'entreprise. Si ces utilisateurs doivent utiliser des AWS ressources (ou utiliser des applications qui accèdent à ces ressources), ils ont également besoin d'informations d'identification AWS de sécurité. A l'aide d'un rôle IAM, vous pouvez définir des autorisations pour des utilisateurs dont l'identité est fédérée par votre organisation ou un fournisseur d'identité (IdP) tiers.

**Note**  
En tant que bonne pratique de sécurité, nous vous recommandons de gérer l'accès des utilisateurs dans [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) à l'aide de la fédération d'identité plutôt que de créer des utilisateurs IAM. Pour en savoir plus sur les situations spécifiques dans lesquelles un utilisateur IAM est nécessaire, veuillez consulter [Quand créer un utilisateur IAM (au lieu d'un rôle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose).

## Fédération d'utilisateurs d'une application mobile ou web à l'aide d'Amazon Cognito
<a name="id_roles_common-scenarios_federated-users-cognito"></a>

Si vous créez une application mobile ou Web qui accède aux AWS ressources, l'application a besoin d'informations d'identification de sécurité pour pouvoir envoyer des demandes programmatiques à. AWS Pour la plupart des scénarios impliquant des applications mobiles, nous recommandons d'utiliser [Amazon Cognito](https://aws.amazon.com/cognito/). Vous pouvez utiliser ce service avec le [SDK AWS mobile pour iOS et AWS le SDK mobile pour](https://aws.amazon.com/sdkforios/) [Android et Fire OS afin de créer des identités uniques pour les utilisateurs et](https://aws.amazon.com/sdkforandroid/) de les authentifier afin de sécuriser l'accès à vos ressources. AWS Amazon Cognito prend en charge les mêmes fournisseurs d'identité que ceux répertoriés dans la section suivante, ainsi que les [identités authentifiées par le développeur](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) et les accès non authentifiés (invité). Amazon Cognito fournit également des opérations d'API pour la synchronisation des données utilisateur afin de les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour plus d’informations, veuillez consulter [Amazon Cognito pour les applications mobiles](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito). 

## Fédération d'utilisateurs à l'aide de fournisseurs d'identité publics ou d'OpenID Connect
<a name="id_roles_common-scenarios_federated-users-openId"></a>

Dans la mesure du possible, utilisez Amazon Cognito pour les scénarios d'applications mobiles et Web. Amazon Cognito effectue la majeure partie du behind-the-scenes travail avec les services des fournisseurs d'identité publics pour vous. Il fonctionne avec les mêmes services tiers et prend également en charge les connexions anonymes. Toutefois, dans le cas de scénarios plus complexes, vous pouvez avoir directement recours à un service tiers tel que Login with Amazon, Facebook, Google, ou tout autre IdP compatible avec OpenID Connect (OIDC). Pour plus d’informations sur l’utilisation de la fédération OIDC avec l’un de ces services, consultez [Fédération OIDC](id_roles_providers_oidc.md).

## Fédération d'utilisateurs avec SAML 2.0
<a name="id_roles_common-scenarios_federated-users-saml20"></a>

Si votre organisation utilise déjà un progiciel de fournisseur d'identité compatible avec le SAML 2.0 (Security Assertion Markup Language 2.0), vous pouvez créer un climat de confiance entre votre organisation en tant que fournisseur d'identité (IdP) et en AWS tant que fournisseur de services. Vous pouvez ensuite utiliser SAML pour fournir à vos utilisateurs une authentification unique (SSO) fédérée AWS Management Console ou un accès fédéré aux opérations d'API d'appel. AWS Par exemple, si votre entreprise utilise Microsoft Active Directory et Active Directory Federation Services, vous pouvez utiliser la fédération à l'aide de SAML 2.0. Pour plus d'informations sur l'utilisation des utilisateurs fédérés avec SAML 2.0, consultez [Fédération SAML 2.0](id_roles_providers_saml.md).

## Fédération d'utilisateurs via la création d'une application de broker d'identité personnalisé
<a name="id_roles_common-scenarios_federated-users-idbroker"></a>

Si votre base d'identités n'est pas compatible avec SAML 2.0, vous pouvez créer une application de broker d'identité personnalisé capable d'exécuter une fonction similaire. L'application broker authentifie les utilisateurs, leur demande des informations d'identification temporaires AWS, puis les fournit à l'utilisateur pour qu'il accède aux AWS ressources. 

Par exemple, de nombreux employés d'Example Corp. doivent exécuter des applications internes qui accèdent aux AWS ressources de l'entreprise. Ils disposent déjà d'identités dans le système d'identité et d'authentification de l'entreprise et, par conséquent, Example Corp. ne souhaite pas créer un utilisateur IAM séparé pour chacun de ses employés.

Bob est développeur chez Example Corp. Pour permettre aux applications internes d'Example Corp. d'accéder aux AWS ressources de l'entreprise, Bob développe une application personnalisée de courtier d'identité. L'application vérifie que les employés sont connectés au système d'identité et d'authentification existant d'Example Corp., par exemple LDAP, Active Directory ou un autre système. L'application de broker d'identité obtient ensuite des informations d'identification de sécurité temporaires pour les employés. Ce scénario est similaire au précédent (une application mobile utilisant un système d'authentification personnalisé), sauf que les applications qui ont besoin d'accéder aux AWS ressources s'exécutent toutes sur le réseau de l'entreprise et que l'entreprise dispose d'un système d'authentification existant.

Pour obtenir les informations d'identification de sécurité temporaires, l'application de broker d'identité appelle `AssumeRole` ou `GetFederationToken`, selon la façon dont Bob veut gérer les politiques des utilisateurs et le délai d'expiration des informations d'identification. Pour plus d'informations sur les différences entre ces opérations d'API, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md) et [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md).) L'appel renvoie des informations de sécurité temporaires composées d'un identifiant de clé d' AWS accès, d'une clé d'accès secrète et d'un jeton de session. L'application de broker d'identité rend ensuite ces informations d'identification de sécurité temporaires accessibles à l'application interne de l'entreprise. L'application peut alors utiliser ces informations d'identification de sécurité temporaires pour appeler directement AWS . L'application met en cache les informations d'identification jusqu'à ce qu'elles parviennent à expiration, puis demande un nouvel ensemble d'informations d'identification temporaires. L'illustration suivante décrit ce scénario.

![\[Exemple de flux avec une application de broker d'identité personnalisé\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)


Ce scénario utilise les attributs suivants :
+ L'application de broker d'identité dispose d'autorisations d'accès à l'API du service de jeton (STS) d'IAM pour créer des informations d'identification de sécurité temporaires.
+ L'application de broker d'identité peut vérifier que les employés sont authentifiés dans le système d'authentification existant.
+ Les utilisateurs peuvent obtenir une URL temporaire qui leur donne accès à la console de AWS gestion (appelée authentification unique).

Pour plus d'informations sur la création d'informations d'identification de sécurité temporaires, consultez [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md). Pour plus d'informations sur l'accès des principaux fédérés SAML à la console de AWS gestion, consultez. [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md)

# Création d’un rôle IAM
<a name="id_roles_create"></a>

Pour créer un rôle, vous pouvez utiliser les AWS Management Console AWS CLI outils pour Windows ou PowerShell l'API IAM.

Si vous utilisez le AWS Management Console, un assistant vous guide tout au long des étapes de création d'un rôle. Les étapes de l'assistant varient légèrement selon que vous créez un rôle pour un AWS service, pour un ou pour un Compte AWS principal fédéré SAML ou OIDC.

**Rôles pour les utilisateurs IAM**  
Créez ce rôle pour déléguer des autorisations au sein de votre Compte AWS ou à des rôles définis dans d'autres rôles Comptes AWS que vous possédez. Un utilisateur d'un compte peut passer à un rôle dans le même compte ou dans un autre compte. Lorsqu'il utilise le rôle, l'utilisateur peut exécuter uniquement les actions et accéder uniquement aux ressources autorisées par le rôle. Leurs autorisations utilisateur d'origine sont suspendues. Lorsque l'utilisateur quitte le rôle, ses autorisations utilisateur d'origine sont restaurées.

Pour de plus amples informations, veuillez consulter [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md).

Pour de plus amples informations sur la création de rôles avec un accès intercompte, consultez [Création d’un rôle à l’aide de politiques d’approbation personnalisées](id_roles_create_for-custom.md).

**Rôles des AWS services**  
Créez ce rôle pour déléguer des autorisations à un service qui peut effectuer des actions en votre nom. Un [rôle de service](id_roles.md#iam-term-service-role) que vous transmettez à un service doit avoir une politique IAM avec les autorisations qui permettent au service d’effectuer les actions associées à ce service. Différentes autorisations sont requises pour chaque service AWS .

Pour plus d’informations sur la création de rôles de service, consultez [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md).

Pour plus d’informations sur la création de rôles liés à un service, consultez [Créer un rôle lié à un service](id_roles_create-service-linked-role.md).

**Rôles pour la fédération d’identité**  
Créez ce rôle pour déléguer des autorisations aux utilisateurs qui ont déjà des identités en dehors d’ AWS. Lorsque vous utilisez un fournisseur d'identité , vous n'avez pas à créer de code de connexion personnalisé ni à gérer vos propres identités utilisateur. Vos utilisateurs externes se connectent via un IdP, et vous pouvez autoriser ces identités externes à utiliser les AWS ressources de votre compte. Les fournisseurs d'identité contribuent à la sécurité de votre AWS compte car vous n'avez pas à distribuer ou à intégrer des informations de sécurité à long terme, telles que des clés d'accès, dans votre application.

Pour de plus amples informations, veuillez consulter [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md).

# Créer un rôle pour attribuer des autorisations à un utilisateur IAM
<a name="id_roles_create_for-user"></a>

Vous pouvez utiliser les rôles IAM pour accéder à vos AWS ressources. Avec les rôles IAM, vous pouvez établir des relations de confiance entre votre compte de *confiance* et d'autres comptes de AWS *confiance*. Le compte d'approbation est propriétaire des ressources auxquelles les utilisateurs ont accès , tandis que le compte approuvé contient les utilisateurs devant accéder aux ressources. Toutefois, il est possible qu'un autre compte détienne une ressource dans votre compte. Par exemple, le compte de confiance peut autoriser le compte approuvé à créer de nouvelles ressources, telles que la création de nouveaux objets dans un compartiment Amazon S3. Dans ce cas, le compte qui crée la ressource la détient et contrôle les personnes pouvant y accéder.

Une fois que vous avez créé la relation de confiance, un utilisateur IAM ou une application du compte sécurisé peut utiliser l'opération d'[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API AWS Security Token Service (AWS STS). Cette opération fournit des informations de sécurité temporaires qui permettent d'accéder aux AWS ressources de votre compte.

Les deux comptes peuvent être contrôlés par vous-même, ou le compte contenant les utilisateurs peut être contrôlé par un tiers. Si l'autre compte associé aux utilisateurs est un compte Compte AWS que vous ne contrôlez pas, vous pouvez utiliser l'`externalId`attribut. L'ID externe peut être n'importe quel mot ou nombre convenu avec l'administrateur du compte tiers. Cette option ajoute automatiquement une condition à la politique d'approbation. Cette condition permet à l'utilisateur d'endosser le rôle uniquement si la demande inclut l'élément approprié `sts:ExternalID`. Pour de plus amples informations, veuillez consulter [Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md).

Pour plus d'informations sur la façon d'utiliser les rôles pour déléguer des autorisations, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts). Pour en savoir plus sur l'utilisation d'un rôle de service afin de permettre aux services l'accès aux ressources de votre compte, consultez [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md).

## Création d'un rôle IAM (console)
<a name="roles-creatingrole-user-console"></a>

Vous pouvez utiliser le AWS Management Console pour créer un rôle qu'un utilisateur IAM peut assumer. Supposons, par exemple, que votre organisation en dispose Comptes AWS de plusieurs pour isoler un environnement de développement d'un environnement de production. Pour des informations générales sur la création d'un rôle autorisant les utilisateurs du compte de développement à accéder aux ressources du compte de production, consultez [Exemple de scénario utilisant des comptes de développement et de production distincts](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example).

**Autorisations minimales**  
Pour effectuer les étapes suivantes, vous devez au moins disposer des autorisations IAM suivantes :  
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`

------
#### [ Console ]

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, choisissez **Rôles**, puis **Créer un rôle**.

1. Choisissez le type du rôle de l'**Compte AWS**.

1. Pour créer un rôle pour votre compte, choisissez **This account** (Ce compte). Pour créer un rôle pour un autre compte, choisissez **Another Compte AWS** (Autre ) et saisissez l'**Account ID** (ID de compte) auquel vous voulez octroyer l'accès à vos ressources.

   L'administrateur du compte spécifié peut accorder l'autorisation d'endosser ce rôle à n'importe quel utilisateur IAM de ce compte. Pour ce faire, l'administrateur attache une politique à l'utilisateur ou à un groupe qui donne l'autorisation pour l'action `sts:AssumeRole`. Cette politique doit spécifier l'ARN du rôle comme `Resource`. 

1. Si vous accordez des autorisations aux utilisateurs d'un compte que vous ne contrôlez pas et si les utilisateurs ont l'intention d'assumer ce rôle par programmation, alors sélectionnez **Require external ID** (Demander un ID externe). L'ID externe peut être n'importe quel mot ou nombre convenu avec l'administrateur du compte tiers. Cette option ajoute automatiquement une condition à la politique d'approbation. Cette condition permet à l'utilisateur d'endosser le rôle uniquement si la demande inclut l'élément approprié `sts:ExternalID`. Pour de plus amples informations, veuillez consulter [Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md).
**Important**  
Le choix de cette option restreint l'accès au rôle uniquement par le biais AWS CLI des outils pour Windows PowerShell ou de l' AWS API. Cela est dû au fait que vous ne pouvez pas utiliser la AWS console pour passer à un rôle dont la politique de confiance est assortie d'une `externalId` condition. Vous pouvez néanmoins créer ce type d'accès par programmation, en écrivant un script ou une application à l'aide du kit SDK approprié. Pour plus d'informations et un exemple de script, consultez [How to Enable Cross-Account Access to the AWS Management Console](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) sur AWS Security Blog.

1. Si vous souhaitez restreindre le rôle aux utilisateurs qui se connectent via une authentification MFA, sélectionnez **Demander l'authentification MFA**. Cela ajoute une condition à la politique d'approbation du rôle qui exige une authentification MFA. Un utilisateur qui veut endosser le rôle doit se connecter avec un mot de passe unique temporaire à partir d'un dispositif MFA configuré. Sans authentification MFA, les utilisateurs ne peuvent pas endosser le rôle. Pour plus d'informations sur l'authentification MFA, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md)

1. Choisissez **Suivant**.

1. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez **Créer une politique** pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer à toute personne endossant le rôle. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation.

1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée. 

   Ouvrez la section **Set permissions boundary (Définir une limite d'autorisations)** et choisissez **Use a permissions boundary to control the maximum role permissions (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle)**. Sélectionnez la politique à utiliser comme limite d'autorisations.

1. Choisissez **Suivant**.

1. Dans le champ **Role name** (Nom de rôle), saisissez un nom pour votre rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Lorsqu'un nom de rôle est utilisé dans une politique ou dans le cadre d'un ARN, il est sensible à la casse. Lorsque le nom d'un rôle apparaît aux clients dans la console, par exemple lors du processus de connexion, il n'est pas sensible à la casse. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création.

1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle.

1. Choisissez **Edit** (Modifier) dans les sections **Step 1: Select trusted entities** (Étape 1 : sélection d'entités de confiance) ou **Step 2: Add permissions** (Étape 2 : ajouter des autorisations) pour modifier les cas d'utilisation et les autorisations pour le rôle. Vous serez renvoyé aux pages précédentes pour effectuer les modifications.

1. (Facultatif) Ajoutez des métadonnées au rôle en associant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.
**Important**  
N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous devez également accorder aux utilisateurs individuels du compte approuvé des autorisations permettant de basculer vers le rôle dans la console ou d'endosser le rôle par programmation. Pour plus d’informations sur cette étape, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

------

## Création d'un rôle IAM (AWS CLI)
<a name="roles-creatingrole-user-cli"></a>

La création d'un rôle à partir de AWS CLI implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont effectuées pour vous, mais AWS CLI vous devez effectuer chaque étape vous-même de manière explicite. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle.

**Pour créer un rôle pour l'accès entre comptes (AWS CLI)**

1. Créez un rôle : [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)

1. Associez une politique d'autorisations gérées au rôle : [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)

    or

   Créez une politique d'autorisation intégrée pour le rôle : [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

1. (Facultatif) Ajoutez des attributs personnalisés au rôle en associant des balises : [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)

   Pour de plus amples informations, veuillez consulter [Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api).

1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)

   Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

L'exemple suivant illustre les deux premières étapes les plus courantes pour créer un rôle entre comptes dans un environnement simple. Cet exemple permet à tout utilisateur du compte `123456789012` d'endosser le rôle et d'afficher le compartiment Amazon S3 `example_bucket`. Cet exemple suppose également que vous utilisiez un ordinateur client exécutant Windows et que vous ayez déjà configuré votre interface de ligne de commande à l'aide des informations d'identification et de la région de votre compte. Pour plus d'informations, voir [Configuration de l'interface de ligne de AWS commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

Dans cet exemple, incluez la politique de confiance suivante dans la première commande lors de la création du rôle. Cette politique de confiance permet aux utilisateurs du compte `123456789012` d'endosser le rôle à l'aide de l'opération `AssumeRole`, mais uniquement s'ils fournissent l'authentification MFA à l'aide des paramètres `SerialNumber` et `TokenCode`. Pour plus d'informations sur l'authentification MFA, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md).

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
          "Effect": "Allow",
          "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
          "Action": "sts:AssumeRole",
          "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
      }
  ]
}
```

------

**Important**  
Si votre élément `Principal` contient l'ARN d'un rôle ou utilisateur IAM spécifique, alors cet ARN devient un ID du principal unique lorsque la politique est enregistrée. Cela permet de réduire le risque d'escalade des autorisations par la suppression et la nouvelle création du rôle ou de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN, lorsque la politique d'approbation est affichée. Toutefois, si vous supprimez le rôle ou l'utilisateur, l'ID principal apparaît dans la console car il n'est plus AWS possible de le mapper à un ARN. Par conséquent, si vous supprimez et recréez un utilisateur ou rôle référencé dans l'élément `Principal` d'une politique de confiance, vous devez modifier le rôle afin de remplacer l'ARN.

Lorsque vous utilisez la deuxième commande, vous devez attacher au rôle une politique gérée existante. La politique d'autorisations suivante permet à toute personne endossant le rôle d'exécuter uniquement l'action `ListBucket` sur le compartiment Amazon S3 `example_bucket`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
          "Effect": "Allow",
          "Action": "s3:ListBucket",
          "Resource": "arn:aws:s3:::example_bucket"
      }
  ]
}
```

------

Pour créer ce rôle `Test-UserAccess-Role`, vous devez d'abord enregistrer la précédente politique de confiance avec le nom `trustpolicyforacct123456789012.json` dans le dossier `policies` de votre disque local `C:`. Enregistrez ensuite la politique d'autorisation précédente en tant que politique gérée par le client dans votre Compte AWS nom`PolicyForRole`. Vous pouvez ensuite utiliser les commandes suivantes pour créer le rôle et attacher la politique gérée.

```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json

# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```

**Important**  
N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous devez également accorder à des utilisateurs individuels du compte approuvé les autorisations permettant de changer de rôle. Pour plus d’informations sur cette étape, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

Une fois que vous avez créé le rôle et que vous lui avez accordé les autorisations nécessaires pour effectuer des AWS tâches ou accéder aux AWS ressources, tous les utilisateurs du `123456789012` compte peuvent assumer le rôle. Pour de plus amples informations, veuillez consulter [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md).

## Création d'un rôle IAM (AWS API)
<a name="roles-creatingrole-user-api"></a>

La création d'un rôle à partir de l' AWS API implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont exécutées automatiquement pour vous, mais avec l'API vous devez exécuter explicitement chaque étape vous-même. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle.

**Pour créer un rôle dans le code (AWS API)**

1. Créez un rôle : [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)

   Vous pouvez spécifier un emplacement de fichier pour la politique d'approbation du rôle.

1. Associez une politique d'autorisation gérée au rôle : [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

   or

   Créez une politique d'autorisation intégrée pour le rôle : [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
**Important**  
N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous devez également accorder à des utilisateurs individuels du compte approuvé les autorisations permettant de changer de rôle. Pour plus d’informations sur cette étape, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

1. (Facultatif) Ajoutez des attributs personnalisés à l'utilisateur en attachant des balises : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

   Pour de plus amples informations, veuillez consulter [Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)](id_tags_users.md#id_tags_users_procs-cli-api).

1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)

   Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

Une fois que vous avez créé le rôle et que vous lui avez accordé les autorisations nécessaires pour effectuer des AWS tâches ou accéder aux AWS ressources, vous devez accorder des autorisations aux utilisateurs du compte pour leur permettre d'assumer le rôle. Pour plus d'informations sur l'endossement d'un rôle, consultez [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md).

## Création d'un rôle IAM (AWS CloudFormation)
<a name="roles_creatingrole-user-cloudformation"></a>

Pour plus d'informations sur la création d'un rôle IAM dans AWS CloudFormation, consultez la [référence sur les ressources et les propriétés](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) et les [exemples](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples) dans le *guide de l'AWS CloudFormation utilisateur*.

*Pour plus d'informations sur les modèles IAM dans AWS CloudFormation, consultez les [extraits de Gestion des identités et des accès AWS modèles](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html) dans le Guide de l'AWS CloudFormation utilisateur.*

# Création d'un rôle pour déléguer des autorisations à un AWS service
<a name="id_roles_create_for-service"></a>

De nombreux AWS services nécessitent que vous utilisiez des rôles pour permettre au service d'accéder aux ressources d'autres services en votre nom. Un rôle qu'un service endosse pour effectuer des actions en votre nom s'appelle un [rôle de service](id_roles.md#iam-term-service-role). Lorsqu’un rôle de service remplit un objectif spécial pour un service, il est défini comme [rôle lié à un service](id_roles.md#iam-term-service-linked-role). Pour savoir quels services prennent en charge par les rôles de service liés à un service ou déterminer si un service prend en charge une forme d'informations d'identification temporaires, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour découvrir comment un service individuel utilise des rôles, choisissez son nom dans le tableau pour afficher la documentation de ce service.

Lors de la définition de l’autorisation `PassRole`, vous devez vous assurer qu’un utilisateur ne transfère pas un rôle ayant plus d’autorisations que ce que vous souhaitez pour l’utilisateur. Par exemple, Alice n’est peut-être pas autorisée à effectuer des actions Amazon S3. Si Alice pouvait transmettre un rôle à un service autorisant les actions Amazon S3, le service pourrait effectuer des actions Amazon S3 pour le compte d’Alice lors de l’exécution de la tâche.

Pour plus d'informations sur la façon dont les rôles aident à déléguer des autorisations, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts).

## Autorisations de fonction de service
<a name="id_roles_create_service-permissions"></a>

Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur ou un rôle) de créer ou modifier un rôle lié à un service.

**Note**  
L'ARN d'un rôle lié à un service comprend un principal de service indiqué dans les politiques suivantes comme `SERVICE-NAME.amazonaws.com`. N'essayez pas de deviner le principal de service, car il est sensible à la casse et le format peut varier entre les services AWS . Pour afficher le principal de service d'un service, consultez la documentation de son rôle lié à un service.

**Pour permettre à une entité IAM de créer un rôle spécifique lié à un service**

Ajoutez la politique suivante à l'entité IAM qui doit créer le rôle lié à un service. Cette politique vous permet de créer un rôle lié au service spécifié et avec un nom spécifique. Vous pouvez ensuite attacher des politiques en ligne ou gérées à ce rôle. 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:CreateRole",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
        }
    ]
}
```

------

**Pour permettre à une entité IAM de créer n"importe quel rôle lié à un service**

AWS recommande de n'autoriser que les utilisateurs administratifs à créer un rôle de service. Une personne disposant des autorisations nécessaires pour créer un rôle et attacher n'importe quelle politique peut augmenter ses propres autorisations. Au lieu de cela, créez une politique qui l’autorise à créer uniquement les rôles dont elle a besoin ou de demander à un administrateur de créer la fonction du service en son nom.

Pour associer une politique permettant à un administrateur d'accéder à votre intégralité Compte AWS, utilisez la politique [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS gérée.

**Pour permettre à une entité IAM de modifier un rôle lié à un service**

Ajoutez la politique suivante à l'entité IAM qui doit modifier le rôle lié à un service.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "EditSpecificServiceRole",
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:DeleteRolePolicy",
                "iam:DetachRolePolicy",
                "iam:GetRole",
                "iam:GetRolePolicy",
                "iam:ListAttachedRolePolicies",
                "iam:ListRolePolicies",
                "iam:PutRolePolicy",
                "iam:UpdateRole",
                "iam:UpdateRoleDescription"
            ],
            "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
        },
        {
            "Sid": "ViewRolesAndPolicies",
            "Effect": "Allow",
            "Action": [
                "iam:GetPolicy",
                "iam:ListRoles"
            ],
            "Resource": "*"
        }
    ]
}
```

------

**Pour permettre à une entité IAM de supprimer un rôle spécifique lié à un service**

Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit supprimer le rôle lié à un service spécifié.

```
{
    "Effect": "Allow",
    "Action": "iam:DeleteRole",
    "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```

**Pour permettre à une entité IAM de supprimer un rôle de service**

AWS recommande de n'autoriser que les utilisateurs administratifs à supprimer un rôle de service. Au lieu de cela, créez une politique qui leur permet de supprimer uniquement les rôles dont ils ont besoin ou de demander à un administrateur de supprimer le rôle de service en leur nom.

Pour associer une politique permettant à un administrateur d'accéder à votre intégralité Compte AWS, utilisez la politique [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS gérée.

## Création d'un rôle pour un AWS service (console)
<a name="roles-creatingrole-service-console"></a>

Vous pouvez utiliser le AWS Management Console pour créer un rôle pour un service. Puisque certains services prennent en charge plus d'un rôle de service, consultez la documentation [AWS](https://docs.aws.amazon.com/) de votre service pour savoir quel cas d'utilisation choisir. Vous pouvez apprendre à attribuer les politiques d'approbation et d'autorisation nécessaires au rôle, afin que le service puisse endosser le rôle à votre place. Les étapes que vous pouvez utiliser pour contrôler les autorisations de votre rôle peuvent varier, selon la façon dont le service définit les cas d'utilisation et si vous créez un rôle lié à un service.

------
#### [ Console ]

**Pour créer un rôle pour une Service AWS (console IAM)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation de la console IAM, sélectionnez **Roles** (Rôles), puis **Create role** (Créer un rôle).

1. Pour **Trusted entity** (Entité de confiance), choisissez **Service AWS**.

1. Pour **Service ou cas d’utilisation**, choisissez un service, puis choisissez le cas d’utilisation. Les cas d'utilisation sont définis par le service pour inclure la politique d'approbation nécessaire au service.

1. Choisissez **Suivant**.

1. Pour **Politiques d’autorisations**, les options dépendent du cas d’utilisation que vous avez sélectionné :
   + Si le service définit les autorisations pour le rôle, il n’est pas possible de sélectionner les politiques d’autorisation.
   + Choisissez parmi un ensemble limité de politiques d’autorisation.
   + Choisissez parmi toutes les politiques d’autorisation.
   + Ne sélectionnez aucune politique d’autorisation, créez les politiques une fois le rôle créé, puis attachez-les au rôle.

1. (Facultatif) Définissez une [limite d'autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html). Il s’agit d’une fonctionnalité avancée disponible pour les fonctions de service, mais pas pour les rôles liés à un service.

   1. Ouvrez la section **Définir une limite des autorisations** et choisissez **Utiliser une limite des autorisations pour contrôler le nombre maximum d’autorisations de rôle**. 

      IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte.

   1. Sélectionnez la politique à utiliser comme limite d'autorisations.

1. Choisissez **Suivant**.

1. Pour **Nom du rôle**, les options dépendent du service :
   + Si le service définit le nom du rôle, vous ne pouvez pas modifier le nom du rôle.
   + Si le service définit un préfixe pour le nom du rôle, vous pouvez saisir un suffixe facultatif.
   + Si le service ne définit pas le nom du rôle, vous pouvez le nommer.
**Important**  
Lorsque vous nommez un rôle, notez ce qui suit :  
Les noms de rôles doivent être uniques au sein du Compte AWS vôtre et ne peuvent pas être rendus uniques au cas par cas.  
Par exemple, ne créez pas deux rôles nommés **PRODROLE** et **prodrole**. Lorsqu’un nom de rôle est utilisé dans une politique ou dans le cadre d’un ARN, le nom de rôle est sensible à la casse. Cependant, lorsqu’un nom de rôle apparaît aux clients dans la console, par exemple lors de la procédure d’ouverture de session, le nom de rôle est insensible à la casse.
Vous ne pouvez pas modifier le nom du rôle après sa création, car d’autres entités pourraient y faire référence.

1. (Facultatif) Pour **Description**, saisissez la description du rôle.

1. (Facultatif) Pour modifier les cas d’utilisation et les autorisations du rôle, dans les sections **Étape 1 : sélectionner les entités de confiance** ou **Étape 2 : ajouter des autorisations**, sélectionnez **Modifier**.

1. (Facultatif) Pour identifier, organiser ou rechercher le rôle, ajoutez des identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la section [Balises pour les Gestion des identités et des accès AWS ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le Guide de l'*utilisateur d'IAM*.

1. Passez en revue les informations du rôle, puis choisissez **Create role** (Créer un rôle).

------

## Création d'un rôle pour un service (AWS CLI)
<a name="roles-creatingrole-service-cli"></a>

La création d'un rôle à partir de AWS CLI implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont effectuées pour vous, mais AWS CLI vous devez effectuer chaque étape vous-même de manière explicite. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Si le service concerné est Amazon EC2 vous devez également créer un profil d'instance et lui ajouter le rôle. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle.

**Pour créer un rôle pour un AWS service à partir du AWS CLI**

1. La commande `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` suivante crée un rôle nommé *Rôle test* et lui attache une politique de confiance :

   `aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`

1. Associez une politique d'autorisations gérées au rôle : [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html).

   Par exemple, la commande `attach-role-policy` suivante attache la politique gérée par AWS , nommée `ReadOnlyAccess`, au rôle IAM nommé `ReadOnlyRole` :

   `aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`

    or

   Créez une politique d'autorisation intégrée pour le rôle : [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

   Pour ajouter une politique d'autorisations en ligne, reportez-vous à l'exemple suivant :

    `aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`

1. (Facultatif) Ajoutez des attributs personnalisés au rôle en associant des balises : [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)

   Pour de plus amples informations, veuillez consulter [Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api).

1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)

   Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

Si vous comptez utiliser le rôle avec Amazon EC2 ou un autre AWS service utilisant Amazon EC2, vous devez le stocker dans un profil d'instance. Un profil d'instance est un conteneur pour un rôle que vous pouvez attacher à une instance Amazon EC2 lorsqu'elle est lancée. Un profil d'instance peut contenir un rôle uniquement et cette limite ne peut pas être augmentée. Si vous créez le rôle à l'aide du AWS Management Console, le profil d'instance est créé pour vous sous le même nom que le rôle. Pour plus d'informations sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md). Pour de plus amples informations sur le lancement d’une instance EC2 avec un rôle, consultez [Contrôle de l’accès aux ressources Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) dans le *Guide de l’utilisateur Amazon EC2*.

**Pour créer un profil d'instance et y stocker le rôle (AWS CLI)**

1. Création d'un profil d'instance : [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)

1. Ajoutez le rôle au profil d'instance : [aws iam add-role-to-instance -profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html)

L' AWS CLI exemple de commande ci-dessous illustre les deux premières étapes de création d'un rôle et d'attribution d'autorisations. Il présente également les deux étapes de la création d'un profil d'instance et de l'ajout du rôle au profil. Cet exemple de politique de confiance permet au service Amazon EC2 d'endosser le rôle et d'afficher le compartiment Amazon S3 `example_bucket`. L'exemple suppose également que vous utilisiez un ordinateur client exécutant Windows et que vous ayez déjà configuré votre interface de ligne de commande avec vos informations d'identification et votre région. Pour plus d'informations, voir [Configuration de l'interface de ligne de AWS commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

Dans cet exemple, incluez la politique de confiance suivante dans la première commande lors de la création du rôle. Cette politique de confiance permet au service Amazon EC2 d'endosser le rôle. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }
}
```

------

Lorsque vous utilisez la deuxième commande, vous devez attacher une politique d'autorisations au rôle. L'exemple de politique d'autorisations suivant permet au rôle d'exécuter uniquement l'action `ListBucket` sur le compartiment Amazon S3 `example_bucket`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}
```

------

Pour créer ce rôle `Test-Role-for-EC2`, vous devez d'abord enregistrer la politique de confiance précédente avec le nom `trustpolicyforec2.json` et la politique d'autorisations précédente avec le nom `permissionspolicyforec2.json` dans le répertoire `policies` de votre disque local `C:`. Vous pouvez ensuite utiliser les commandes suivantes pour créer le rôle, attacher la politique, créer le profil d'instance et ajouter le rôle au profil d'instance.

```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json

# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json

# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3

# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```

Lorsque vous lancez l'instance EC2, spécifiez le nom du profil de l'instance sur la page **Configurer les détails de l'instance** si vous utilisez la AWS console. Si vous utilisez la commande CLI `aws ec2 run-instances`, précisez le paramètre `--iam-instance-profile`.

## Création d'un rôle pour un service (AWS API)
<a name="roles-creatingrole-service-api"></a>

La création d'un rôle à partir de l' AWS API implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont exécutées automatiquement pour vous, mais avec l'API vous devez exécuter explicitement chaque étape vous-même. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Si le service concerné est Amazon EC2 vous devez également créer un profil d'instance et lui ajouter le rôle. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle.

**Pour créer un rôle pour un AWS service (AWS API)**

1. Créez un rôle : [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)

   Vous pouvez spécifier un emplacement de fichier pour la politique d'approbation du rôle.

1. Associez une politique d'autorisations gérées au rôle : [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

    or

   Créez une politique d'autorisation intégrée pour le rôle : [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

1. (Facultatif) Ajoutez des attributs personnalisés à l'utilisateur en attachant des balises : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

   Pour de plus amples informations, veuillez consulter [Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)](id_tags_users.md#id_tags_users_procs-cli-api).

1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)

   Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

Si vous comptez utiliser le rôle avec Amazon EC2 ou un autre AWS service utilisant Amazon EC2, vous devez le stocker dans un profil d'instance. Un profil d'instance est un conteneur pour un rôle. Chaque profil d'instance peut contenir un rôle uniquement et cette limite ne peut pas être augmentée. Si vous créez le rôle dans le AWS Management Console, le profil d'instance est créé pour vous sous le même nom que le rôle. Pour plus d'informations sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md). Pour de plus amples informations sur le lancement d’une instance Amazon EC2 avec un rôle, consultez [Contrôle de l’accès aux ressources Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) dans le *Guide de l’utilisateur Amazon EC2*. 

**Pour créer un profil d'instance et y stocker le rôle (AWS API)**

1. Créez un profil d'instance : [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html)

1. Ajoutez le rôle au profil d'instance : [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html)

# Créer un rôle lié à un service
<a name="id_roles_create-service-linked-role"></a>

Un rôle lié à un service est un type unique de rôle IAM directement lié à un service AWS . Les rôles liés au service sont prédéfinis par le service et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom. Le service lié définit aussi la manière dont vous créez, modifiez et supprimez un rôle lié à un service. Un service peut créer ou supprimer automatiquement le rôle. Il peut vous permettre de créer, modifier ou supprimer le rôle dans le cadre des opérations d'un assistant ou d'un processus du service. Ou il peut vous demander d'utiliser IAM pour créer ou supprimer le rôle. Quelle que soit la méthode, les rôles liés à un service simplifient le processus de configuration d'un service étant donné que vous n'avez pas besoin d'ajouter manuellement les autorisations requises pour que le service effectue des actions en votre nom.

**Note**  
N'oubliez pas que les fonctions du service sont différentes des rôles liés à un service. 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*. 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 à un 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. 

Le service lié définit les autorisations de ses rôles liés à un service et, sauf définition contraire, seul ce service peut endosser les rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.

Avant que vous ne puissiez supprimer les rôles, vous devez d'abord supprimer les ressources qui leur sont associées. Ainsi, vous ne risquez pas de supprimer involontairement l’autorisation d’accéder aux ressources. 

**Astuce**  
Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Choisissez un **Yes** (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service.

## Autorisations de rôles liés à un service
<a name="service-linked-role-permissions"></a>

Vous devez configurer les autorisations d'une entité IAM (utilisateur ou rôle) de manière à permettre à l'utilisateur ou au rôle de créer ou modifier le rôle lié à un service.

**Note**  
L'ARN d'un rôle lié à un service comprend un principal de service indiqué dans les stratégies ci-dessous comme `SERVICE-NAME.amazonaws.com`. N'essayez pas de deviner le principal du service, car il distingue les majuscules et minuscules et le format peut varier d'un AWS service à l'autre. Pour afficher le principal de service d'un service, consultez la documentation de son rôle lié à un service.

**Pour permettre à une entité IAM de créer un rôle spécifique lié à un service**

Ajoutez la politique suivante à l'entité IAM qui doit créer le rôle lié à un service.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
            "Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
        }
    ]
}
```

------

**Pour permettre à une entité IAM de créer un rôle lié à un service**

Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit créer un rôle lié à un service, ou un rôle de service incluant les politiques requises. Cette instruction de politique n'autorise pas l'entité IAM à attacher une politique à ce rôle.

```
{
    "Effect": "Allow",
    "Action": "iam:CreateServiceLinkedRole",
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**Pour permettre à une entité IAM de modifier la description de rôles liés à un service**

Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit modifier la description d'un rôle lié à un service ou d'un rôle de service.

```
{
    "Effect": "Allow",
    "Action": "iam:UpdateRoleDescription",
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**Pour permettre à une entité IAM de supprimer un rôle spécifique lié à un service**

Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit supprimer le rôle lié à un service.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
    ],
    "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```

**Pour permettre à une entité IAM de supprimer un rôle lié à un service**

Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit supprimer un rôle lié à un service, mais pas le rôle de service.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
    ],
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**Pour permettre à une entité IAM de transmettre un rôle existant au service**

Certains AWS services vous permettent de transmettre un rôle existant au service, au lieu de créer un nouveau rôle lié au service. Pour ce faire, un utilisateur doit disposer des autorisations nécessaires pour *transmettre le rôle* au service. Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit transmettre un rôle. Cette instruction de politique autorise également l'entité à afficher une liste des rôles à partir de laquelle ils peuvent choisir le rôle à transmettre. Pour de plus amples informations, veuillez consulter [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](id_roles_use_passrole.md).

```
{
  "Sid": "PolicyStatementToAllowUserToListRoles",
  "Effect": "Allow",
  "Action": ["iam:ListRoles"],
  "Resource": "*"
},
{
  "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
  "Effect": "Allow",
  "Action": [ "iam:PassRole" ],
  "Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```

## Autorisations indirectes avec rôles liés à un service
<a name="create-service-linked-role-permissions-transfer"></a>

Les autorisations accordées par un rôle lié à un service peuvent être transférées indirectement à d'autres utilisateurs et rôles. Lorsqu'un rôle lié à un service est utilisé par un AWS service, ce rôle lié au service peut utiliser ses propres autorisations pour appeler d'autres services. AWS Cela signifie que les utilisateurs et les rôles ayant l'autorisation d'appeler un service qui utilise un rôle lié à un service peuvent avoir un accès indirect aux services auxquels ce rôle lié à un service peut accéder.

Par exemple, lorsque vous créez une instance de base données Amazon RDS, [un rôle lié à un service pour RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html) est automatiquement créé s'il n'existe pas déjà. Ce rôle lié au service permet à RDS d'appeler Amazon EC2, Amazon SNS, Amazon CloudWatch Logs et Amazon Kinesis en votre nom. Si vous autorisez les utilisateurs et les rôles de votre compte à modifier ou à créer des bases de données RDS, ils pourront peut-être interagir indirectement avec Amazon EC2, Amazon SNS, les journaux Amazon Logs et les ressources CloudWatch Amazon Kinesis en appelant RDS, car RDS utiliserait son rôle lié au service pour accéder à ces ressources.

### Méthodes pour créer un rôle lié à un service
<a name="create-service-linked-role"></a>

La méthode que vous utilisez pour créer un rôle lié à un service dépend dudit service. Dans certains cas, vous n'avez pas besoin de créer manuellement un rôle lié à un service. Par exemple, lorsque vous terminez une action donnée (comme créer une ressource) dans le service, le service peut créer le rôle lié au service à votre place. Ou, si vous utilisiez un service avant qu'il ne prenne en charge les rôles liés à un service, alors le service peut avoir créé automatiquement le rôle dans votre compte. Pour en savoir plus, veuillez consulter la section [Un nouveau rôle est apparu dans mon AWS compte](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared).

Dans d'autres cas, le service peut prendre en charge la création manuelle d'un rôle lié à un service à l'aide la console, l'API ou de la CLI. Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Pour savoir si le service prend en charge la création du rôle lié à un service, choisissez le lien **Oui** pour afficher la documentation du rôle lié à ce service.

Si le service ne prend pas en charge la création du rôle, alors vous pouvez utiliser IAM pour créer le rôle lié à un service.

**Important**  
Les rôles liés à un service comptent dans votre limite de [rôles IAM dans un Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities), mais si vous avez atteint cette limite, vous pouvez toujours créer des rôles liés à un service dans votre compte. Seuls les rôles liés à un service peuvent dépasser la limite sans conséquence.

### Création d'un rôle lié à un service (console)
<a name="create-service-linked-role-iam-console"></a>

Avant de créer un rôle lié à un service dans IAM, sachez si le service lié crée automatiquement des rôles liés au service et si vous pouvez créer le rôle depuis la console, l'API ou la CLI du service.<a name="create-service-linked-role-iam-console"></a>

**Pour créer un rôle lié à un service (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. Puis, choisissez **Create role** (Créer un rôle).

1. Choisissez le type de fonction du **service AWS **.

1. Choisissez le cas d'utilisation de votre service. Les cas d'utilisation sont définis par le service pour inclure la politique d'approbation requise par le service. Ensuite, choisissez **Suivant**.

1. Choisissez une ou plusieurs politiques d'autorisation à attacher au rôle. En fonction du cas d'utilisation sélectionné, le service peut effectuer n'importe laquelle des options suivantes :
   + Définissez les autorisations utilisées par le rôle.
   + Vous permet de choisir parmi un ensemble limité d'autorisations.
   + Vous permet de choisir parmi toutes les autorisations.
   + Vous permet de choisir de ne sélectionner aucune stratégie pour le moment, mais de créer les politiques plus tard et de les attacher au rôle.

   Cochez la case en regard de la politique qui affecte les autorisations que vous voulez octroyer au rôle, puis choisissez **Suivant**. 
**Note**  
Les autorisations que vous spécifiez sont disponibles à toutes les entités qui utilisent le rôle. Par défaut, un rôle ne dispose d'aucune autorisation.

1. Pour **Nom du rôle**, le degré de la personnalisation du nom du rôle est défini par le service. Si le service définit le nom du rôle, alors cette option n'est pas modifiable. Dans d'autres cas, le service peut définir un préfixe pour le rôle ou vous laisser saisir un suffixe facultatif.

   Si possible, saisissez un suffixe de nom de rôle à ajouter au nom par défaut. Ce suffixe vous aide à identifier l'objectif de ce rôle. Les noms de rôle de votre compte AWS doivent être uniques. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **<service-linked-role-name>\$1SAMPLE** et **<service-linked-role-name>\$1sample**. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création.

1. (Facultatif) Dans le champ **Description**, modifiez la description du nouveau rôle lié à un service.

1. Vous ne pouvez pas attacher des balises à des rôles liés à un service lors de la création. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.

### Création d'un rôle lié à un service (AWS CLI)
<a name="create-service-linked-role-iam-cli"></a>

Avant de créer un rôle lié à un service dans IAM, sachez si le service lié crée automatiquement des rôles liés au service et si vous pouvez créer le rôle depuis la CLI du service. Si la CLI du service n'est pas prise en charge, vous pouvez employer les commandes IAM pour créer un rôle lié à un service avec la politique d'approbation et les politiques en ligne dont le service a besoin pour endosser le rôle.

**Pour créer un rôle lié à un service (AWS CLI)**

Exécutez la commande suivante :

```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```

### Création d'un rôle lié à un service (API)AWS
<a name="create-service-linked-role-iam-api"></a>

Avant de créer un rôle lié à un service dans IAM, sachez si le service lié crée automatiquement des rôles liés au service et si vous pouvez créer le rôle depuis l'API du service. Si l'API de service n'est pas prise en charge, vous pouvez utiliser l' AWS API pour créer un rôle lié au service avec la politique de confiance et les politiques intégrées dont le service a besoin pour assumer ce rôle.

**Pour créer un rôle lié à un service (API)AWS **

Utilisez l'appel d'API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Dans la demande, spécifiez un nom de service sous la forme `SERVICE_NAME_URL.amazonaws.com`. 

Par exemple, pour créer le rôle lié à un service **Robots Lex**, utilisez `lex.amazonaws.com`.

# Créer un rôle pour un fournisseur d’identité tiers
<a name="id_roles_create_for-idp"></a>

Vous pouvez utiliser des fournisseurs d'identité au lieu de créer des utilisateurs IAM dans votre Compte AWS. Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et les fournisseurs d'identité, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md).

## Création d’un rôle pour les principaux fédérés OIDC et SAML (console)
<a name="roles-creatingrole-federated-users-console"></a>

Les procédures permettant de créer un rôle dépendent des fournisseurs tiers choisis :
+ Pour OpenID Connect (OIDC), consultez [Création d’un rôle pour la fédération OpenID Connect (console)](id_roles_create_for-idp_oidc.md).
+ Pour SAML 2.0, consultez [Création d’un rôle pour la fédération SAML 2.0 (console)](id_roles_create_for-idp_saml.md).

## Création d'un rôle pour l'accès fédéré (AWS CLI)
<a name="roles-creatingrole-identityprovider-cli"></a>

Les étapes à suivre pour la création d'un rôle pour les fournisseurs d'identité pris en charge (OIDC ou SAML) à partir de la AWS CLI sont identiques. La différence porte sur le contenu de la politique d'approbation que vous créez dans les étapes préalables requises. Commencez par suivre les étapes de la section **Prérequis** pour le type de fournisseur que vous utilisez :
+ Pour un fournisseur OIDC, consultez [Prérequis pour la création d’un rôle pour OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites).
+ Pour un fournisseur SAML, consultez [Prérequis pour la création d'un rôle pour SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites).

La création d'un rôle à partir de AWS CLI implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont effectuées pour vous, mais AWS CLI vous devez effectuer chaque étape vous-même de manière explicite. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle.

**Pour créer un rôle (AWS CLI)**

1. Créez un rôle : [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)

1. Associez une politique d'autorisation au rôle : [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)

    or

   Créez une politique d'autorisation intégrée pour le rôle : [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

1. (Facultatif) Ajoutez des attributs personnalisés au rôle en associant des balises : [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)

   Pour de plus amples informations, veuillez consulter [Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api).

1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)

   Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

L'exemple suivant illustre les deux premières étapes les plus courantes pour créer un rôle de fournisseur d'identité dans un environnement simple. Cet exemple permet à tout utilisateur du compte `123456789012` d'endosser le rôle et d'afficher le compartiment Amazon S3 `example_bucket`. Cet exemple suppose également que vous exécutez le AWS CLI sur un ordinateur exécutant Windows et que vous l'avez déjà configuré AWS CLI avec vos informations d'identification. Pour plus d’informations, consultez [Configuration de l’ AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

L'exemple de politique de confiance suivant est conçu pour une application mobile si l'utilisateur se connecte à l'aide d'Amazon Cognito. Dans cet exemple, *us-east:12345678-ffff-ffff-ffff-123456* représente l'ID du pool d'identités attribué par Amazon Cognito.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Sid": "RoleForCognito",
        "Effect": "Allow",
        "Principal": {"Federated": "cognito-identity.amazonaws.com"},
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
    }
}
```

------

La politique d'autorisations suivante permet à toute personne endossant le rôle d'exécuter uniquement l'action `ListBucket` sur le compartiment Amazon S3 `example_bucket`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}
```

------

Pour créer ce rôle `Test-Cognito-Role`, vous devez d'abord enregistrer la politique de confiance précédente avec le nom `trustpolicyforcognitofederation.json` et la politique d'autorisations précédente avec le nom `permspolicyforcognitofederation.json` dans le dossier `policies` de votre disque local `C:`. Vous pouvez ensuite utiliser les commandes suivantes pour créer le rôle et attacher la politique en ligne.

```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json

# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```

## Création d'un rôle pour l'accès fédéré (AWS API)
<a name="roles-creatingrole-identityprovider-api"></a>

Les étapes à suivre pour la création d'un rôle pour les fournisseurs d'identité pris en charge (OIDC ou SAML) à partir de la AWS CLI sont identiques. La différence porte sur le contenu de la politique d'approbation que vous créez dans les étapes préalables requises. Commencez par suivre les étapes de la section **Prérequis** pour le type de fournisseur que vous utilisez :
+ Pour un fournisseur OIDC, consultez [Prérequis pour la création d’un rôle pour OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites).
+ Pour un fournisseur SAML, consultez [Prérequis pour la création d'un rôle pour SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites).

**Pour créer un rôle (AWS API)**

1. Créez un rôle : [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)

1. Associez une politique d'autorisation au rôle : [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

    or

   Créez une politique d'autorisation intégrée pour le rôle : [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

1. (Facultatif) Ajoutez des attributs personnalisés à l'utilisateur en attachant des balises : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

   Pour de plus amples informations, veuillez consulter [Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)](id_tags_users.md#id_tags_users_procs-cli-api).

1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)

   Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée.

# Création d’un rôle pour la fédération OpenID Connect (console)
<a name="id_roles_create_for-idp_oidc"></a>

Vous pouvez utiliser les fournisseurs d'identité fédérés OpenID Connect (OIDC) au lieu de créer Gestion des identités et des accès AWS des utilisateurs dans votre. Compte AWS Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et IdPs, voir[Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md).

## Prérequis pour la création d’un rôle pour OIDC
<a name="idp_oidc_Prerequisites"></a>

Avant de pouvoir créer un rôle pour la fédération OIDC, vous devez tout d’abord suivre les étapes requises suivantes.<a name="oidc-prereqs"></a>

**Pour préparer la création d’un rôle pour la fédération OIDC**

1. Inscrivez-vous auprès d'un ou plusieurs services offrant une identité OIDC fédérée. Si vous créez une application qui a besoin d'accéder à vos AWS ressources, vous devez également configurer votre application avec les informations du fournisseur. Ainsi, le fournisseur vous communique un ID d'application ou de public unique pour votre application. (Les fournisseurs utilisent une terminologie différente pour ce processus. Ce guide utilise le terme *configurer* pour désigner le processus d'identification de votre application auprès du fournisseur.) Vous pouvez configurer plusieurs applications auprès de chaque fournisseur, ou plusieurs fournisseurs avec une seule application. Consultez les informations sur l'utilisation des fournisseurs d'identité comme suit :
   + [Login with Amazon Developer Center](https://login.amazon.com/)
   + [Add Facebook Login to Your App or Website](https://developers.facebook.com/docs/facebook-login/v2.1) sur le site des développeurs Facebook.
   + [Utilisation de la OAuth version 2.0 pour la connexion (OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login) sur le site des développeurs de Google.

1. <a name="idpoidcstep2"></a>Après avoir reçu les informations requises de la part de l'IdP, créez un IdP dans IAM. Pour de plus amples informations, veuillez consulter [Création d’un fournisseur d’identité OpenID Connect (OIDC) dans IAM](id_roles_providers_create_oidc.md).
**Important**  
Si vous utilisez un fournisseur d'identités OIDC de Google, Facebook ou Amazon Cognito, ne créez pas d'IdP IAM distinct dans l' AWS Management Console. Ces fournisseurs d'identité OIDC sont déjà intégrés AWS et sont à votre disposition. Ignorez cette étape et créez de nouveaux rôles à l'aide de votre IdP à l'étape suivante.

1. Préparez les politiques pour le rôle que les utilisateurs authentifiés auprès de l'IdP vont endosser. Comme n'importe quel rôle, celui d'une application mobile inclut deux politiques. L'une est la politique de confiance qui spécifie la personne capable d'endosser le rôle. L'autre est la politique d'autorisation qui spécifie les actions et les ressources AWS auxquelles l'application mobile peut accéder ou non.

   Pour le Web IdPs, nous vous recommandons d'utiliser [Amazon Cognito](https://aws.amazon.com/cognito/) pour gérer les identités. Dans ce cas, utilisez une politique de confiance semblable à cet exemple.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"Federated": "cognito-identity.amazonaws.com"},
           "Action": "sts:AssumeRoleWithWebIdentity",
           "Condition": {
               "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
               "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
           }
       }
   }
   ```

------

   Remplacez `us-east-2:12345678-abcd-abcd-abcd-123456` par l'ID du groupe d'identités qu'Amazon Cognito vous assigne.

   Si vous configurez manuellement un fournisseur d’identité OIDC, lorsque vous créez la politique de confiance, vous devez utiliser trois valeurs pour garantir que seule votre application peut endosser le rôle :
   + Pour l'élément `Action`, utilisez l'action `sts:AssumeRoleWithWebIdentity`.
   + Pour l'élément `Principal`, utilisez la chaîne `{"Federated":providerUrl/providerArn}`.
     + Pour certains OIDC courants IdPs, il `providerUrl` s'agit d'une URL. Les exemples suivants incluent des méthodes permettant de spécifier le principal pour certaines méthodes courantes IdPs :

       `"Principal":{"Federated":"cognito-identity.amazonaws.com"}`

       `"Principal":{"Federated":"www.amazon.com"}`

       `"Principal":{"Federated":"graph.facebook.com"}`

       `"Principal":{"Federated":"accounts.google.com"}`
     + Pour les autres fournisseurs OIDC, utilisez l'Amazon Resource Name (ARN) du fournisseur d'identité OIDC créé dans [Step 2](#idpoidcstep2), comme dans l'exemple suivant :

       `"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
   + Pour l'élément `Condition`, utilisez une condition `StringEquals` pour limiter les autorisations. Testez l'ID du groupe d'identités pour Amazon Cognito ou l'ID d'application pour les autres fournisseurs. L'ID du groupe d'identité doit correspondre à l'ID d'application obtenu lors de la configuration de l'application avec le fournisseur d'identité. Cette correspondance entre les IDs garantit que la demande provient de votre application.
**Note**  
Les rôles IAM pour les groupes d’identités Amazon Cognito font confiance au principal de service `cognito-identity.amazonaws.com` pour assumer ce rôle. Les rôles de ce type doivent contenir au moins une clé de condition pour limiter les principaux qui peuvent assumer le rôle.  
Des considérations supplémentaires s’appliquent aux groupes d’identités Amazon Cognito qui assument des [rôles IAM entre comptes](access_policies-cross-account-resource-access.md). Les politiques d’approbation associées à ces rôles doivent accepter le principal de service `cognito-identity.amazonaws.com` et contenir la clé de condition `aud` permettant de limiter l’attribution de rôles aux utilisateurs issus des groupes d’identités que vous souhaitez. Une politique qui fait confiance aux groupes d’identités Amazon Cognito sans cette condition crée un risque qu’un utilisateur d’un groupe d’identités non prévu puisse assumer le rôle. Pour plus d’informations, consultez la section [Politiques d’approbation pour les rôles IAM dans l’authentification de base (classique)](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies) dans le *Guide du développeur Amazon Cognito*.

     Créez un élément de condition semblable à un des exemples suivants, en fonction du fournisseur d'identité que vous utilisez : 

     `"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`

     `"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`

     `"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`

     `"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`

     Pour les fournisseurs OIDC, utilisez l'URL complète du fournisseur d'identité OIDC avec la clé de contexte `aud`, comme dans exemple suivant : 

     `"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**Note**  
Les valeurs du principal dans la politique de confiance pour le rôle sont propres à un fournisseur d'identité. Un rôle pour OIDC ne peut spécifier qu’un seul principal. Par conséquent, si l'application mobile autorise des utilisateurs à se connecter à partir de plusieurs fournisseurs d'identité, créez un rôle distinct pour chaque fournisseur d'identité que vous souhaitez prendre en charge. Créez des politiques de confiance distinctes pour chaque fournisseur d'identité.

   Si un utilisateur utilise une application mobile pour se connecter à partir de Login with Amazon (Connexion avec Amazon, l'exemple suivant de politique de confiance s'appliquerait. Dans l'exemple, *amzn1.application-oa2-123456* représente l'ID d'application attribué par Amazon lorsque vous avez configuré l'application à l'aide de Login with Amazon.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForLoginWithAmazon",
             "Effect": "Allow",
             "Principal": {"Federated": "www.amazon.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
         }]
     }
   ```

------

   Si un utilisateur utilise une application mobile pour se connecter à partir de Facebook, l'exemple suivant de politique de confiance s'appliquerait. Dans cet exemple, *111222333444555* représente l'ID d'application attribué par Facebook.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForFacebook",
             "Effect": "Allow",
             "Principal": {"Federated": "graph.facebook.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
         }]
     }
   ```

------

   Si un utilisateur utilise une application mobile pour se connecter à partir de Google, l'exemple suivant de politique de confiance s'appliquerait. Dans cet exemple, *666777888999000* représente l'ID d'application attribué par Google.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForGoogle",
             "Effect": "Allow",
             "Principal": {"Federated": "accounts.google.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
         }]
     }
   ```

------

   Si un utilisateur utilise une application mobile pour se connecter depuis Amazon Cognito, l'exemple de politique de confiance suivant s'applique. Dans cet exemple, *us-east:12345678-ffff-ffff-ffff-123456* représente l'ID du pool d'identités attribué par Amazon Cognito.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForCognito",
             "Effect": "Allow",
             "Principal": {"Federated": "cognito-identity.amazonaws.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
         }]
     }
   ```

------

## Création d’un rôle pour OIDC
<a name="idp_oidc_Create"></a>

Après avoir exécuté les prérequis, vous pouvez créer le rôle dans IAM. *Pour les fournisseurs d'identité OpenID Connect (OIDC) partagés reconnus (IdPs), IAM exige une évaluation explicite des revendications spécifiques dans les jetons Web JSON (JWTs), connus sous le nom de contrôles des fournisseurs d'identité.* Pour plus d'informations sur les OIDC IdPs dotés de *contrôles par fournisseur d'identité*, consultez. [Contrôles des fournisseurs d’identité pour les fournisseurs OIDC partagés](id_roles_providers_oidc_secure-by-default.md)

La procédure suivante décrit comment créer une le rôle pour la fédération OIDC dans la AWS Management Console. Pour créer un rôle à partir de l' AWS API AWS CLI or, consultez les procédures sur[Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md).

**Important**  
Si vous utilisez Amazon Cognito, utilisez la console Amazon Cognito pour configurer les rôles. Sinon, utilisez la console IAM pour créer un rôle pour la fédération OIDC.

**Pour créer un rôle IAM pour la fédération OIDC**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Roles** (Rôles), puis **Create role** (Créer un rôle).

1. Choisissez **l’identité Web** comme type d’entité d’approbation et sélectionnez **Suivant**.

1. Pour **Identity provider** (Fournisseur d'identité), choisissez l'IdP de votre rôle : 
   + Si vous créez un rôle pour un fournisseur d'identité Web individuel, choisissez entre **Login with Amazon** (Connexion avec Amazon), **Facebook** ou **Google**. 
**Note**  
Vous devez créer un rôle distinct pour chaque IdP que vous souhaitez prendre en charge.
   + Si vous souhaitez créer un rôle de scénario avancé pour Amazon Cognito, choisissez **Amazon Cognito**. 
**Note**  
Vous ne devez créer manuellement un rôle à utiliser avec Amazon Cognito que lorsque vous travaillez sur un scénario avancé. Sinon, Amazon Cognito peut créer des rôles pour vous. Pour plus d'informations sur Amazon Cognito, consultez [Fournisseurs d'identité externes - Pools d’identités (identités fédérées)](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) dans le *Manuel du développeur Amazon Cognito*. 
   + Si vous souhaitez créer un rôle pour GitHub Actions, vous devez commencer par ajouter le fournisseur GitHub OIDC à IAM. **Après avoir ajouté le fournisseur GitHub OIDC à IAM, choisissez token.actions.githubusercontent.com.** 
**Note**  
Pour plus d'informations sur la façon de AWS configurer le fournisseur OIDC GitHub de confiance en tant qu'identité fédérée, consultez [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Pour plus d'informations sur les meilleures pratiques en matière de limitation de l'accès aux rôles associés à l'IdP IAM GitHub pour, [Configuration d'un rôle pour le fournisseur d'identité GitHub OIDC](#idp_oidc_Create_GitHub) consultez cette page.
   + Si vous souhaitez créer un rôle pour HashiCorp Cloud Platform (HCP) Terraform, vous devez commencer par ajouter le fournisseur Terraform OIDC à IAM. Après avoir ajouté le fournisseur Terraform OIDC à IAM, choisissez **app.terraform.io.** 
**Important**  
Rôles IAM pour HashiCorp Cloud Platform (HCP) Le fournisseur Terraform OIDC doit évaluer la clé de condition IAM dans la politique de confiance des `app.terraform.io:sub` rôles. Cette clé de condition limite les organisations, les projets, les espaces de travail ou les phases d’exécution de HCP Terraform qui peuvent assumer le rôle. Sans cette clé de condition, votre politique de confiance accorde l'accès à votre rôle et à vos AWS ressources par des identités extérieures à votre organisation, ce qui n'est pas conforme au principe du moindre privilège.   
Si vous définissez ou modifiez une politique de confiance pour un rôle associé au fournisseur OIDC HCP Terraform dans votre AWS compte, mais que vous n'évaluez pas la clé de condition IAM`app.terraform.io:sub`, vous recevrez une erreur. De plus, AWS STS refusera les requêtes d’autorisation si votre politique d’approbation des rôles n’évalue pas cette clé de condition.

1. Les informations demandées varient en fonction du fournisseur OIDC que vous choisissez.
   + Saisissez l'identifiant de votre application. L'étiquette de l'identifiant varie selon le fournisseur que vous choisissez :
     + Si vous souhaitez créer un rôle pour Login with Amazon (Connexion avec Amazon), saisissez l'ID d'application dans le champ **Application ID** (ID d'application).
     + Si vous souhaitez créer un rôle pour Facebook, saisissez l'ID d'application dans le champ **Application ID** (ID d'application).
     + Si vous souhaitez créer un rôle pour Google, saisissez le nom du public cible dans le champ **Audience** (Public cible).
     + Si vous souhaitez créer un rôle pour Amazon Cognito, saisissez l'ID du groupe d'identités que vous avez créé pour vos applications Amazon Cognito dans le champ **Identity Pool ID** (ID du pool d'identités).
   + Si vous souhaitez créer un rôle pour GitHub Actions, entrez les informations suivantes :
     + Pour **Audience**, choisissez `sts.amazonaws.com`.
     + Pour **GitHub l'organisation**, entrez le nom de GitHub l'organisation. Le nom de GitHub l'organisation est obligatoire et doit être alphanumérique, y compris les tirets (-). Vous ne pouvez pas utiliser de caractères génériques (\$1 et ?) dans le nom GitHub de l'organisation.
     + (Facultatif) Pour le **GitHub référentiel**, entrez le nom du GitHub référentiel. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (`*`).
     + (Facultatif) Pour **GitHub la branche**, entrez le nom de la GitHub branche. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (`*`).
   + Si vous souhaitez créer un rôle pour HashiCorp Cloud Platform (HCP) Terraform, entrez les informations suivantes :
     + Pour **Audience**, choisissez `aws.workload.identity`.
     + Pour **Organisation**, saisissez le nom de l’organisation. Vous pouvez spécifier un caractère générique (`*`) pour toutes les organisations.
     + Pour **Projet**, saisissez le nom du projet. Vous pouvez spécifier un caractère générique (`*`) pour tous les projets.
     + Pour **Espace de travail**, saisissez le nom de l’espace de travail. Vous pouvez spécifier un caractère générique (`*`) pour tous les espaces de travail.
     + Pour **Phase d’exécution**, saisissez le nom de la phase d’exécution. Vous pouvez spécifier un caractère générique (`*`) pour toutes les phases d’exécution.

1. (Facultatif) Pour les **Conditions (facultatif)**, choisissez **Ajouter une condition** pour créer des conditions supplémentaires à réunir avant que les utilisateurs de votre application ne puissent utiliser les autorisations que le rôle accorde. Par exemple, vous pouvez ajouter une condition qui accorde l'accès aux AWS ressources uniquement pour un ID utilisateur IAM spécifique. Vous pouvez par ailleurs ajouter des conditions à la politique de confiance après la création du rôle. Pour de plus amples informations, veuillez consulter [Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md).

1. Vérifiez les informations OIDC que vous avez saisies, puis cliquez sur **Suivant**.

1. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez **Create policy** (Créer une politique) pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer aux utilisateurs OIDC. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation.

1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée.

   Ouvrez la section **Set permissions boundary** (Définir une limite d'autorisations) et choisissez **Use a permissions boundary to control the maximum role permissions** (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). Sélectionnez la politique à utiliser comme limite d'autorisations.

1. Choisissez **Suivant**.

1. Pour **Role name** (Nom du rôle), saisissez un nom de rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Ils ne dépendent pas de la casse. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois que vous l'avez créé.

1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle.

1. Pour modifier les cas d'utilisation et les autorisations pour le rôle, choisissez **Edit** (Modifier) dans les sections **Step 1: Select trusted entities** (Étape 1 : sélection d'entités de confiance) ou **Step 2: Select permissions** (Étape 2 : sélection d'autorisations). 

1. (Facultatif) Pour ajouter des métadonnées au rôle, attachez des balises en tant que paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.

## Configuration d'un rôle pour le fournisseur d'identité GitHub OIDC
<a name="idp_oidc_Create_GitHub"></a>

Si vous utilisez un GitHub fournisseur d'identité (IdP) OpenID Connect (OIDC), la meilleure pratique consiste à limiter le nombre d'entités pouvant assumer le rôle associé à l'IdP IAM. Lorsque vous incluez une déclaration de condition dans la politique de confiance, vous pouvez limiter le rôle à une GitHub organisation, un référentiel ou une branche spécifique. Vous pouvez utiliser la clé de condition `token.actions.githubusercontent.com:sub` avec des opérateurs de condition de chaîne pour limiter l'accès. Nous vous recommandons de limiter cette condition à un ensemble spécifique de référentiels ou de succursales au sein de votre GitHub organisation. Pour plus d'informations sur la façon de AWS configurer GitHub l'OIDC de confiance en tant qu'identité fédérée, consultez [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). 

Si vous utilisez GitHub des environnements dans des workflows d'action ou dans des politiques OIDC, nous vous recommandons vivement d'ajouter des règles de protection à l'environnement pour une sécurité accrue. Utilisez les branches et les balises de déploiement pour limiter les branches et les balises qui peuvent être déployées dans l’environnement. Pour plus d'informations sur la configuration des environnements dotés de règles de protection, consultez la section [Branches et balises GitHub de déploiement](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags) dans l'article *Utilisation des environnements pour le déploiement*.

Quand GitHub l'IdP OIDC est le principal fiable pour votre rôle, IAM vérifie la condition de la politique de confiance des rôles pour vérifier que la `token.actions.githubusercontent.com:sub` clé de condition est présente et que sa valeur n'est pas uniquement un caractère générique (\$1 et ?) ou nul. IAM effectue cette vérification lors de la création ou de la mise à jour de la politique IAM. Si la clé de condition `token.actions.githubusercontent.com:sub` est absente ou la valeur clé ne répond pas aux critères de valeur mentionnés, la demande échouera et renverra une erreur.

**Important**  
Si vous ne limitez pas la clé de condition `token.actions.githubusercontent.com:sub` à une organisation ou à un référentiel spécifique, GitHub les actions provenant d'organisations ou de référentiels indépendants de votre volonté peuvent assumer les rôles associés à l' GitHub IdP IAM dans votre compte. AWS 

L'exemple de politique de confiance suivant limite l'accès à l' GitHub organisation, au référentiel et à la succursale définis. La `token.actions.githubusercontent.com:sub` valeur de la clé de condition dans l'exemple suivant est le format de valeur d'objet par défaut documenté par GitHub.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
        }
      }
    }
  ]
}
```

------

L'exemple de condition suivant limite l'accès à l' GitHub organisation et au référentiel définis, mais accorde l'accès à n'importe quelle branche du référentiel.

```
"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
  }
}
```

L'exemple de condition suivant limite l'accès à n'importe quel référentiel ou branche au sein de l' GitHub organisation définie. Nous vous recommandons de limiter la clé de condition `token.actions.githubusercontent.com:sub` à une valeur spécifique qui limite l'accès aux GitHub actions au sein de votre GitHub organisation.

```
"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
  }
}
```

Pour plus d’informations sur les clés de fédération OIDC disponibles pour les contrôles de condition dans les politiques, consultez [Clés disponibles pour la AWS fédération OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif).

# Création d’un rôle pour la fédération SAML 2.0 (console)
<a name="id_roles_create_for-idp_saml"></a>

 Vous pouvez utiliser la fédération SAML 2.0 au lieu de créer des utilisateurs IAM dans votre. Compte AWS Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et les fournisseurs d'identité, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md).

**Note**  
Pour améliorer la résilience de la fédération, nous vous recommandons de configurer votre IdP et votre fédération AWS pour prendre en charge plusieurs points de terminaison de connexion SAML. Pour plus de détails, consultez l'article du blog sur la AWS sécurité [Comment utiliser les points de terminaison SAML régionaux pour](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover) le basculement.

## Prérequis pour la création d'un rôle pour SAML
<a name="idp_saml_Prerequisites"></a>

Avant de pouvoir créer un rôle pour la fédération SAML 2.0, vous devez tout d'abord suivre les étapes requises suivantes.<a name="saml-prereqs"></a>

**Pour préparer la création d'un rôle pour la fédération SAML 2.0**

1. <a name="idpsamlstep1"></a>Avant de créer un rôle pour la fédération SAML, vous devez créer un fournisseur SAML dans IAM. Pour plus d’informations, veuillez consulter [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md).

1. Préparez les politiques pour le rôle que les utilisateurs authentifiés SAML 2.0 vont endosser. Comme n'importe quel rôle, celui de la fédération SAML inclut deux politiques. L'une est la politique de confiance de rôle qui spécifie la personne capable d'endosser le rôle. L'autre est la politique d'autorisations IAM qui spécifie les AWS actions et les ressources auxquelles l'accès du principal fédéré SAML est autorisé ou refusé.

   Lorsque vous créez la politique de confiance pour votre rôle, vous devez utiliser trois valeurs pour vous assurer que seule votre application peut assumer le rôle :
   + Pour l'élément `Action`, utilisez l'action `sts:AssumeRoleWithSAML`.
   + Pour l'élément `Principal`, utilisez la chaîne `{"Federated":ARNofIdentityProvider}`. Remplacez `ARNofIdentityProvider` par l'ARN du [fournisseur d'identité SAML](id_roles_providers_saml.md) que vous avez créé dans [Step 1](#idpsamlstep1).
   + Pour l’élément `Condition`, utilisez une condition `StringEquals` pour vérifier que l’attribut `saml:aud` de la réponse SAML correspond à l’URL affichée par votre navigateur lorsque vous vous connectez à la console. Cette URL de point de terminaison de connexion correspond à l’attribut du destinataire SAML de votre fournisseur d’identité. Vous pouvez inclure la connexion URLs dans certaines régions. AWS recommande d'utiliser des points de terminaison régionaux plutôt que des points de terminaison mondiaux pour améliorer la résilience de la fédération. Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html).

     Si le chiffrement SAML est obligatoire, l’URL de connexion doit inclure l’identifiant unique qu’ AWS attribue à votre fournisseur SAML. Vous pouvez afficher l’identifiant unique en sélectionnant le fournisseur d’identité dans la console IAM afin d’afficher la page de détails.

     `https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

   L'exemple suivant de politique de confiance est conçu pour un utilisateur fédéré SAML :

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRoleWithSAML",
           "Principal": {
               "Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
           },
           "Condition": {
               "StringEquals": {
                   "SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
               }
           }
       }
   }
   ```

------

   Remplacez l'ARN principal par l'ARN réel pour le fournisseur SAML que vous avez créé dans IAM. Il utilisera votre propre ID de compte et nom du fournisseur. 

## Création d'un rôle pour SAML
<a name="idp_saml_Create"></a>

Après avoir exécuté les étapes prérequises, vous pouvez créer le rôle pour la fédération basée sur SAML. 

**Pour créer un rôle pour la fédération basée sur SAML**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console IAM, sélectionnez **Roles** (Rôles), puis **Create role** (Créer un rôle).

1. Choisissez le type de rôle **Fédération SAML 2.0**.

1. Pour **Select a SAML provider** (Sélectionnez un fournisseur SAML), choisissez le fournisseur de votre rôle. 

1. Choisissez la méthode de niveau d'accès SAML 2.0. 
   + Choisissez **Autoriser l'accès par programmation uniquement** pour créer un rôle pouvant être assumé par programmation à partir de l' AWS API ou. AWS CLI
   + Choisissez **Autoriser la programmation et AWS Management Console l'accès** pour créer un rôle qui peut être assumé par programmation et à partir du. AWS Management Console

   Les rôles créés par les deux méthodes sont similaires, mais le rôle qui peut aussi être endossé depuis la console inclut une politique d'approbation contenant une condition particulière. Cette condition vérifie explicitement que l’audience SAML (l’attribut `SAML:aud`) est définie sur le point de terminaison de connexion AWS pour votre fournisseur SAML

1. La procédure de définition des attributs varie en fonction du type d’accès.
   + Si vous créez un rôle pour un accès par programme, choisissez un attribut dans la liste **Attribut**. Ensuite, dans le champ **Value** (Valeur), tapez une valeur à inclure dans le rôle. Cette valeur restreint l'accès au rôle aux utilisateurs du fournisseur d'identité dont la réponse d'authentification SAML (assertion) inclut les attributs que vous spécifiez. Vous devez spécifier au moins un attribut afin de garantir la limitation du rôle à un sous-ensemble d'utilisateurs de votre organisation. 
   + Si vous créez un rôle pour la programmation et l' AWS Management Console accès, la section **Points de terminaison de connexion** définit l'URL que votre navigateur affiche lorsque vous vous connectez à la console. Ce point de terminaison est l’attribut de destinataire SAML de votre fournisseur d’identité, qui correspond à la clé de contexte [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml). Pour de plus amples informations, veuillez consulter [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md).

     1. Choisissez des **points de terminaison régionaux** ou des **points de terminaison non régionaux**. Nous recommandons d’utiliser plusieurs points de terminaison de connexion SAML régionaux afin d’améliorer la résilience de la fédération.

     1. Pour **les régions**, choisissez les régions prises en charge par votre fournisseur SAML pour la AWS connexion.

     1.  Pour que la **connexion URLs inclue des identifiants uniques, indiquez** si les points de terminaison de connexion incluent les identifiants uniques attribués à votre fournisseur d'identité AWS SAML. Cette option est requise pour les assertions SAML chiffrées. Pour de plus amples informations, veuillez consulter [Fédération SAML 2.0](id_roles_providers_saml.md).

1. Pour ajouter d'autres conditions liées aux attributs à la politique d'approbation, choisissez **Condition (optional)** (Conditions [facultatif]), sélectionnez la condition supplémentaire et spécifiez une valeur. 
**Note**  
La liste inclut les attributs SAML les plus couramment utilisés. IAM prend en charge des attributs supplémentaires que vous pouvez utiliser pour créer des conditions. Pour obtenir la liste des attributs pris en charge, veuillez consulter [Clés disponibles pour la fédération SAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml). Si vous avez besoin d'une condition pour un attribut SAML pris en charge ne figurant pas dans la liste, vous pouvez ajouter cette condition manuellement. Pour ce faire, modifiez la politique de confiance après la création du rôle.

1.  Passez en revue les informations d'approbation SAML 2.0, puis choisissez **Next: Permissions** (Suivant : Autorisations). 

1. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez **Create policy** (Créer une politique) pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer aux utilisateurs fédérés SAML. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation.

1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée.

   Ouvrez la section **Set permissions boundary** (Définir une limite d'autorisations) et choisissez **Use a permissions boundary to control the maximum role permissions** (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). Sélectionnez la politique à utiliser comme limite d'autorisations.

1. Choisissez **Suivant**.

1. Choisissez **Suivant : Vérification**.

1. Pour **Role name** (Nom du rôle), saisissez un nom de rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois celui-ci créé. 

1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle.

1. Choisissez **Edit** (Modifier) dans les sections **Step 1: Select trusted entities** (Étape 1 : sélection d'entités de confiance) ou **Step 2: Add permissions** (Étape 2 : ajouter des autorisations) pour modifier les cas d'utilisation et les autorisations pour le rôle. 

1. (Facultatif) Ajoutez des métadonnées au rôle en associant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.

Après avoir créé le rôle, vous devez finaliser la relation d'approbation SAML en configurant le logiciel de votre fournisseur d'identité à l'aide d'informations sur AWS. Ces informations incluent les rôles que vous souhaitez que vos utilisateurs fédérés SAML utilisent. Il s'agit de la configuration de la relation d'approbation des parties utilisatrices entre votre fournisseur d'identité et AWS. Pour de plus amples informations, veuillez consulter [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md). 

# Création d’un rôle à l’aide de politiques d’approbation personnalisées
<a name="id_roles_create_for-custom"></a>

Vous pouvez créer une politique de confiance personnalisée pour déléguer l'accès et permettre à d'autres personnes d'effectuer des actions dans votre Compte AWS. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start).

Pour plus d'informations sur la façon d'utiliser les rôles pour déléguer des autorisations, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts).

## Création d'un rôle IAM à l'aide d'une politique d'approbation personnalisée (console)
<a name="roles-creatingrole-custom-trust-policy-console"></a>

Vous pouvez utiliser le AWS Management Console pour créer un rôle qu'un utilisateur IAM peut assumer. Supposons, par exemple, que votre organisation en dispose Comptes AWS de plusieurs pour isoler un environnement de développement d'un environnement de production. Pour des informations générales sur la création d'un rôle autorisant les utilisateurs du compte de développement à accéder aux ressources du compte de production, consultez [Exemple de scénario utilisant des comptes de développement et de production distincts](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example).

**Pour créer un rôle à l'aide d'une politique d'approbation personnalisée (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, choisissez **Rôles**, puis **Créer un rôle**.

1. Choisissez le type de rôle **Custom trust policy** (Politique d'approbation personnalisée).

1. Dans la section **Custom trust policy** (Politique d'approbation personnalisée), saisissez ou collez la politique d'approbation personnalisée pour le rôle. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start).

1. Résolvez les avertissements de sécurité, les erreurs ou les avertissements généraux générés durant la [validation de la politique](access_policies_policy-validator.md), puis choisissez **Next** (Suivant).

1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée disponible pour les fonctions de service, mais pas pour les rôles liés à un service.

   Ouvrez la section **Set permissions boundary** (Définir une limite d'autorisations) et choisissez **Use a permissions boundary to control the maximum role permissions** (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser comme limite d'autorisations.

1. Choisissez **Suivant**.

1. Pour **Nom du rôle**, le degré de la personnalisation du nom du rôle est défini par le service. Si le service définit le nom du rôle, cette option n'est pas modifiable. Dans d'autres cas, le service peut définir un préfixe pour le rôle ou vous permettre de saisir un suffixe facultatif. Certains services vous permettent de spécifier le nom complet de votre rôle.

   Si possible, saisissez un nom de rôle ou un suffixe de nom de rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois celui-ci créé.

1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle.

1. (Facultatif) Choisissez **Modifier** dans les sections **Étape 1 : sélection d’entités de confiance** ou **Étape 2 : Ajouter des autorisations** pour modifier la politique et les autorisations personnalisées pour le rôle. 

1. (Facultatif) Ajoutez des métadonnées au rôle en associant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.

# Exemples de politiques pour la délégation d'accès
<a name="id_roles_create_policy-examples"></a>

Les exemples suivants montrent comment vous pouvez autoriser ou accorder l' Compte AWS accès aux ressources d'un autre Compte AWS. Pour apprendre à créer une politique IAM à l'aide de ces exemples de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

**Topics**
+ [Utiliser des rôles pour déléguer l'accès aux ressources d'une autre Compte AWS ressource](#example-delegate-xaccount-rolesapi)
+ [Utilisation d'une politique pour la délégation d'accès à des services](#id_roles_create_policy-examples-access-to-services)
+ [Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à un compartiment Amazon S3 dans un autre compte](#example-delegate-xaccount-S3)
+ [Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à une file d'attente Amazon SQS dans un autre compte](#example-delegate-xaccount-SQS)
+ [Délégation d'accès impossible lorsque l'accès est refusé au compte](#example-delegate-xaccount-SQS-denied)

## Utiliser des rôles pour déléguer l'accès aux ressources d'une autre Compte AWS ressource
<a name="example-delegate-xaccount-rolesapi"></a>

 Pour un didacticiel expliquant comment utiliser les rôles IAM pour accorder aux utilisateurs d'un compte l'accès aux AWS ressources d'un autre compte, voir[Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md). 

**Important**  
Vous pouvez inclure l'ARN d'un rôle ou d'un utilisateur dans l'élément `Principal` de la politique d'approbation d'un rôle. Lorsque vous enregistrez la politique, AWS transforme l'ARN en un identifiant principal unique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création du rôle ou de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN, lorsque la politique d'approbation est affichée. Cependant, si vous supprimez le rôle ou l'utilisateur, la relation est interrompue. La politique ne s'applique plus, même si vous recréez l'utilisateur ou le rôle, étant donné qu'il ne correspond pas à l'ID du principal stocké dans la politique d'approbation. Lorsque cela se produit, l'ID principal apparaît dans la console car il n'est plus AWS possible de le mapper à un ARN. Le résultat final est que si vous supprimez et recréez un utilisateur ou un rôle référencé dans l'élément `Principal` d'une politique d'approbation, vous devez modifier le rôle afin de remplacer l'ARN. Il deviendra le nouvel ID du principal lorsque vous enregistrez la politique.

## Utilisation d'une politique pour la délégation d'accès à des services
<a name="id_roles_create_policy-examples-access-to-services"></a>

L'exemple suivant illustre une politique qui est peut être attachée à un rôle. La politique permet à deux services, Amazon EMR et Amazon AWS Data Pipeline, d'assumer ce rôle. Les services peuvent ensuite effectuer toutes les tâches autorisées par la politique d'autorisation affectée au rôle (non illustré). Pour définir plusieurs principaux de service, vous ne spécifiez pas deux éléments `Service` ; vous ne devez en avoir qu'un seul. À la place, vous utilisez un tableau de plusieurs principaux de service comme valeur d'un élément `Service` unique.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

## Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à un compartiment Amazon S3 dans un autre compte
<a name="example-delegate-xaccount-S3"></a>

Dans cet exemple, le compte A utilise une politique basée sur les ressources (une [politique de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html) Amazon S3) pour octroyer au compte B l'accès complet au compartiment S3 du compte A. Ensuite, le compte B crée une politique d'utilisateur IAM pour déléguer l'accès au compartiment du compte A à l'un des utilisateurs du compte B. 

La politique de compartiment S3 du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A est nommé *amzn-s3-demo-bucket*, et le numéro de compte du compte B est 111122223333. Il ne spécifie pas d'utilisateurs ou de groupes dans le compte B, simplement le compte proprement dit.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}
```

------

Le compte A peut également utiliser les [listes de contrôle d'accès Amazon S3 (ACLs)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) pour accorder au compte B l'accès à un compartiment S3 ou à un seul objet au sein d'un compartiment. Dans ce cas, seule change la façon dont le compte A accorde l'accès au compte B. Le compte B utilise toujours une politique pour déléguer l'accès à un groupe IAM dans le compte B, comme décrit dans la dernière partie de cet exemple. Pour plus d’informations sur le contrôle de l'accès aux compartiments et aux objets S3, veuillez consulter [contrôle des accès](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) dans le *guide de l'utilisateur du service de stockage simple Amazon*. 

L'administrateur du compte B peut créer l'exemple de politique suivant. La politique donne un accès en lecture à un groupe ou à un utilisateur au sein du compte B. La politique précédente accorde l'accès au compte B. Toutefois, des groupes et des utilisateurs spécifiques au sein du compte B ne peuvent pas accéder à la ressource tant qu'une politique de groupe ou d'utilisateur ne leur accorde pas explicitement des autorisations pour cette ressource. Les autorisations de cette politique peuvent uniquement être un sous-ensemble de celles de la politique intercompte précédente. Le compte B ne peut pas accorder plus d'autorisations à ses utilisateurs et groupes que le compte A ne lui a accordé dans la première politique. Dans cette politique, l'élément `Action` est défini explicitement pour autoriser uniquement les actions `List`, tandis que l'élément `Resource` de cette politique correspond à l'élément `Resource` pour la politique de compartiment implémentée par le compte A.

Pour implémenter cette politique, le compte B utilise IAM pour l'attacher à l'utilisateur (ou au groupe) approprié dans le compte B. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}
```

------

## Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à une file d'attente Amazon SQS dans un autre compte
<a name="example-delegate-xaccount-SQS"></a>

Dans l'exemple suivant, le compte A est doté d'une file d'attente Amazon SQS qui utilise une politique basée sur les ressources attachée à celle-ci pour accorder au compte B l'accès à la file d'attente. Le compte B utilise ensuite une politique de groupe IAM pour déléguer l'accès à un groupe du compte B. 

L'exemple de politique de file d'attente suivant accorde au compte B l'autorisation d'effectuer les actions `SendMessage` et `ReceiveMessage` dans la file d'attente du compte A nommée *queue1*, mais uniquement entre midi et 15 heures le 30 novembre 2014. Le numéro de compte du compte B est 1111-2222-3333. Le compte A utilise Amazon SQS pour implémenter cette politique. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}
```

------

La politique du compte B pour la délégation d'accès à un groupe dans le compte B peut se présenter comme l'exemple suivant. Le compte B utilise IAM pour attacher cette politique à un groupe (ou utilisateur). 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}
```

------

Dans l'exemple de politique utilisateur IAM précédent, le compte B utilise un caractère générique pour accorder à son utilisateur l'accès à toutes les actions Amazon SQS dans la file d'attente du compte A. Cependant, le compte B peut déléguer l'accès dans la mesure où celui-ci lui a été accordé. Le groupe du compte B qui a une seconde politique peut accéder à la file d'attente uniquement entre midi et 15 heures le 30 novembre 2014. L'utilisateur peut uniquement effectuer les actions `SendMessage` et `ReceiveMessage`, tel que défini dans la politique de file d'attente Amazon SQS du compte A. 

## Délégation d'accès impossible lorsque l'accès est refusé au compte
<a name="example-delegate-xaccount-SQS-denied"></a>

 Compte AWS On ne peut pas déléguer l'accès aux ressources d'un autre compte si celui-ci a explicitement refusé l'accès au compte parent de l'utilisateur. Le rejet se propage aux utilisateurs sous ce compte, qu'ils aient ou non des politiques existantes leur accordant l'accès.

Par exemple, le compte A crée une politique de compartiment pour son compartiment S3 qui refuse explicitement au compte B l'accès à ce compartiment. Mais le compte B crée une politique d'utilisateur IAM qui accorde à un utilisateur du compte B l'accès au compartiment du compte A. Le refus explicite appliqué au compartiment S3 du compte A est propagé aux utilisateurs du compte B. Il remplace la politique d'utilisateur IAM qui accorde l'accès aux utilisateurs du compte B. (Pour des informations détaillées sur la façon dont les autorisations sont évaluées, consultez [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).) 

La politique de compartiment du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A est nommé *amzn-s3-demo-bucket*, et le numéro de compte du compte B est 1111-2222-3333. Le compte A utilise Amazon S3 pour implémenter cette politique. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }
}
```

------

Ce refus explicite remplace toutes les politiques au sein du compte B qui accordent l'accès au compartiment S3 du compte A. 

# Gestion des rôles IAM
<a name="id_roles_manage"></a>

Avant qu’un utilisateur, une application ou un service soit en mesure d’utiliser un rôle que vous avez créé, vous devez lui accorder les autorisations nécessaires pour changer de rôle. Pour accorder ces autorisations, vous pouvez utiliser n’importe quelle politique attachée à l’un des groupes ou des utilisateurs. Cette section décrit l'octroi d'autorisations aux utilisateurs pour utiliser un rôle. Il explique également comment l'utilisateur peut passer d'un rôle à un autre dans les Outils pour Windows PowerShell, le AWS Command Line Interface (AWS CLI) et l'[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API. AWS Management Console

**Important**  
Si vous créez un rôle par programmation plutôt que dans la console IAM, vous avez la possibilité d'ajouter un chemin `Path` de 512 caractères au maximum à l'élément `RoleName` qui lui, est de 64 caractères au maximum. Toutefois, si vous avez l'intention d'utiliser un rôle avec la fonctionnalité **Switch** Role dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères.

**Topics**
+ [Afficher l'accès au rôle](#roles-modify_prerequisites)
+ [Générer une politique sur la base d'informations d'accès](#roles-modify_gen-policy)
+ [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md)
+ [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](id_roles_use_passrole.md)
+ [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md)
+ [Mise à jour d’un rôle lié à un service](id_roles_update-service-linked-role.md)
+ [Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md)
+ [Mettre à jour les autorisations pour un rôle](id_roles_update-role-permissions.md)
+ [Mise à jour des paramètres pour un rôle](id_roles_update-role-settings.md)
+ [Suppression de rôles ou de profils d’instance](id_roles_manage_delete.md)

## Afficher l'accès au rôle
<a name="roles-modify_prerequisites"></a>

Avant de modifier les autorisations d'un rôle, vous devez passer en revue ses activités récentes au niveau service. Ceci est important, car vous ne souhaitez pas supprimer l'accès à partir d'un principal (personne ou application) qui l'utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md).

## Générer une politique sur la base d'informations d'accès
<a name="roles-modify_gen-policy"></a>

Vous pouvez parfois octroyer plus d'autorisations à une entité IAM (utilisateur ou rôle) qu'elle n'en a besoin. Pour affiner les autorisations que vous octroyez, vous pouvez générer une politique IAM basée sur l'activité d'accès d'une entité. IAM Access Analyzer examine vos AWS CloudTrail journaux et génère un modèle de politique contenant les autorisations qui ont été utilisées par l'entité dans la plage de dates que vous avez spécifiée. Vous pouvez utiliser le modèle pour créer une politique gérée avec des autorisations affinées, puis l'attacher à l'entité IAM. Ainsi, vous accordez uniquement les autorisations dont l'utilisateur ou 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ération d’une politique de l’analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).

# Octroi d’autorisations à un utilisateur pour endosser un rôle
<a name="id_roles_use_permissions-to-switch"></a>

Lorsqu'un administrateur [crée un rôle pour un accès intercompte](id_roles_create_for-user.md), il établit une relation d'approbation entre le compte propriétaire du rôle et des ressources (compte d'approbation) et le compte qui contient les utilisateurs (compte approuvé). Pour cela, l'administrateur du compte d'approbation spécifie le numéro du compte approuvé en tant que `Principal` dans la politique d'approbation du rôle. Cela permet *potentiellement* à n'importe quel utilisateur du compte approuvé d'endosser le rôle. Pour achever la configuration, l'administrateur du compte approuvé doit accorder l'autorisation d'endosser ce rôle à des groupes ou utilisateurs spécifiques du compte.

**Pour accorder l'autorisation de passer à un rôle**

1. En tant qu'administrateur du compte approuvé, créez une nouvelle politique pour l'utilisateur ou modifiez une politique existante pour y ajouter les éléments requis. Pour en savoir plus, consultez [Création ou modification de la politique](#roles-usingrole-createpolicy).

1. Choisissez ensuite la manière dont vous souhaitez partager les informations du rôle : 
   + **Lien du rôle :** envoyez aux utilisateurs un lien qui les dirige vers la page **Switch Role** (Changer de rôle) dans laquelle tous les détails sont déjà remplis. 
   + **ID ou alias du compte :** donnez à chaque utilisateur le nom du rôle ainsi que l'ID ou l'alias du compte. L'utilisateur accède ensuite à la page **Switch Role (Changer de rôle)** et ajoute les détails manuellement. 

   Pour en savoir plus, consultez [Fourniture d'informations à l'utilisateur](#roles-usingrole-giveuser).

Notez que vous ne pouvez changer de rôle que lorsque vous vous connectez en tant qu'utilisateur IAM, en tant que rôle fédéré SAML ou en tant que rôle fédéré d'identité Web. Vous ne pouvez pas changer de rôle lorsque vous vous connectez en tant qu' Utilisateur racine d'un compte AWS.

**Important**  
Vous ne pouvez pas changer AWS Management Console de rôle dans un rôle nécessitant une [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)valeur. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) qui prend en charge le paramètre `ExternalId`.

**Remarques**  
Cette rubrique décrit les politiques applicables aux *utilisateurs* car, en fin de compte, il s'agit ici d'accorder à un utilisateur les autorisations nécessaires pour effectuer une tâche. Cependant, nous vous déconseillons d'octroyer des autorisations directement à un utilisateur individuel. Lorsqu'un utilisateur assume un rôle, il reçoit également les autorisations associées.
Lorsque vous changez de rôle dans le AWS Management Console, la console utilise toujours vos informations d'identification d'origine pour autoriser le changement. Cela s'applique que vous soyez connecté en tant qu'utilisateur IAM, en tant que rôle fédéré SAML ou en tant que rôle fédéré d'identité web. Par exemple, si vous basculez sur RoleA, IAM utilise les informations d'identification du compte utilisateur ou du rôle fédéré d'origine pour déterminer si vous êtes autorisé à assumer le rôle RoleA. Si vous essayez ensuite de basculer sur RoleB *pendant que vous utilisez RoleA*, vos informations d'identification d'utilisateur ou du rôle fédéré **d'origine** sont utilisées pour autoriser votre tentative. Les informations d'identification de RoleA (Rôle A) ne sont pas utilisées pour cette action.

**Topics**
+ [Création ou modification de la politique](#roles-usingrole-createpolicy)
+ [Fourniture d'informations à l'utilisateur](#roles-usingrole-giveuser)

## Création ou modification de la politique
<a name="roles-usingrole-createpolicy"></a>

Une politique qui accorde à un utilisateur l'autorisation d'endosser un rôle doit inclure une instruction avec l'effet `Allow` sur les éléments suivants : 
+ L'action `sts:AssumeRole`
+ L'Amazon Resource Name (ARN) du rôle dans un élément `Resource`

Les utilisateurs bénéficiant de la politique sont autorisés à endosser les rôles figurant sur la ressource (via l'appartenance à un groupe ou directement).

**Note**  
Si `Resource` est définie sur `*`, l'utilisateur peut endosser n'importe quel rôle dans n'importe quel compte faisant confiance au compte de l'utilisateur. (En d'autres termes, la politique de confiance du rôle spécifie le compte de l'utilisateur en tant que `Principal`). La bonne pratique consiste à appliquer le [principe du moindre privilège](http://en.wikipedia.org/wiki/Principle_of_least_privilege) et à spécifier l'ARN complet uniquement pour les rôles dont l'utilisateur a besoin.

L'exemple suivant illustre une politique qui permet à l'utilisateur d'endosser des rôles dans un seul compte. En outre, la politique utilise un caractère générique (\$1) pour spécifier que l'utilisateur ne peut passer à un rôle que si le nom du rôle commence par les lettres `Test`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::111122223333:role/Test*"
    }
}
```

------

**Note**  
Les autorisations que le rôle octroie à l'utilisateur ne viennent pas s'ajouter aux autorisations dont il dispose déjà. Lorsqu'un utilisateur endosse un rôle, il abandonne temporairement ses autorisations d'origine, de manière à adopter celles accordées par le rôle. Lorsqu'il quitte le rôle, ses autorisations d'origine sont automatiquement restaurées. Par exemple, supposons que les autorisations de l'utilisateur lui permettent d'utiliser des instances Amazon EC2, mais que la politique des autorisations du rôle n'accorde pas ces autorisations. Dans ce cas, lorsque vous utilisez le rôle, l'utilisateur peut ne pas utiliser les instances Amazon EC2 dans la console. En outre, les informations d'identification temporaires obtenues via `AssumeRole` ne fonctionnent pas par programmation avec les instances Amazon EC2.

## Fourniture d'informations à l'utilisateur
<a name="roles-usingrole-giveuser"></a>

Une fois que vous avez créé un rôle et accordé à l'utilisateur les autorisations requises pour l'endosser, vous devez également fournir à l'utilisateur les éléments suivants :
+ Nom du rôle
+ ID ou alias du compte qui contient le rôle

Pour faciliter l'accès aux utilisateurs, vous pouvez leur envoyer un lien préconfiguré contenant l'ID du compte et le nom du rôle. Vous pouvez voir le lien du rôle après avoir terminé l'assistant **Créer un rôle** en sélectionnant la bannière **Afficher le rôle** ou sur la page **Résumé du rôle** pour n'importe quel rôle inter-comptes.

Vous pouvez également utiliser le format suivant pour créer le lien manuellement. Remplacez les deux paramètres de l'exemple suivant par l'ID ou l'alias de votre compte et le nom du rôle.

`https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name`

Nous vous recommandons de diriger vos utilisateurs vers la rubrique [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md) pour les guider à travers le processus. Pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous endossez un rôle, consultez [Je ne parviens pas à endosser un rôle](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role).

**Considérations**
+ Si vous créez le rôle par programmation, vous pouvez définir un chemin et un nom. Dans ce cas, vous devez fournir le chemin complet et le nom du rôle à vos utilisateurs afin qu'ils les saisissent sur la page **Switch Role** (Changer de rôle) de la AWS Management Console. Par exemple : `division_abc/subdivision_efg/role_XYZ`.
+ Si vous créez le rôle par programmation, vous pouvez ajouter un `Path` de 512 caractères au maximum , ainsi qu'un `RoleName`. Le nom du rôle peut comporter jusqu'à 64 caractères. Toutefois, pour utiliser un rôle avec la fonctionnalité **Switch Role** dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères.
+ Pour des raisons de sécurité, vous pouvez [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Vous pouvez utiliser la clé de condition `sts:SourceIdentity` dans la politique d'approbation de rôle pour exiger des utilisateurs qu'ils spécifient une identité lorsqu'ils endossent un rôle. Par exemple, vous pouvez exiger que les utilisateurs IAM spécifient leur propre nom d'utilisateur comme identité de source. Cela peut vous aider à déterminer quel utilisateur a effectué une action spécifique dans AWS. Pour de plus amples informations, veuillez consulter [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity). Vous pouvez utiliser [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname) pour exiger des utilisateurs qu'ils spécifient un nom de session lorsqu'ils endossent un rôle. Cela peut vous aider à différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux.

# Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service
<a name="id_roles_use_passrole"></a>

Pour configurer de nombreux AWS services, vous devez leur *transmettre* un rôle IAM. Cela autorise le service à assumer ultérieurement le rôle et à effectuer des actions en votre nom. Pour la plupart des services, il vous suffit de transférer le rôle au service une fois au cours de la configuration, et non chaque fois que le service assume le rôle. Par exemple, supposons que vous avez une application s'exécutant sur une instance Amazon EC2. Cette application a besoin d'informations d'identification temporaires pour l'authentification et d'autorisations pour autoriser l'application à exécuter des actions dans AWS. Lorsque vous configurez l'application, vous devez transmettre un rôle à Amazon EC2 à utiliser avec l'instance qui fournit ces informations d'identification. Vous définissez les autorisations pour les applications s'exécutant sur l'instance en attachant une politique IAM au rôle. L'application endosse le rôle chaque fois qu'elle doit effectuer les actions qui sont autorisées par le rôle.

Pour transmettre un rôle (et ses autorisations) à un AWS service, un utilisateur doit disposer des autorisations nécessaires pour *transmettre le rôle* au service. Cela permet aux administrateurs de s'assurer que seuls les utilisateurs autorisés peuvent configurer un service avec un rôle qui accorde des autorisations. Pour permettre à un utilisateur de transmettre un rôle à un AWS service, vous devez accorder l'`PassRole`autorisation à l'utilisateur, au rôle ou au groupe IAM de l'utilisateur.

**Avertissement**  
Vous ne pouvez utiliser cette `PassRole` autorisation que pour transmettre un rôle IAM à un service qui partage le même AWS compte. Pour transmettre un rôle du compte A à un service du compte B, vous devez d'abord créer un rôle IAM dans le compte B qui peut assumer le rôle du compte A, puis le rôle du compte B peut être transmis au service. Pour en savoir plus, consultez [Accès intercompte aux ressources dans IAM](access_policies-cross-account-resource-access.md).
N'essayez pas de contrôler les personnes susceptibles de faire passer un rôle en étiquetant ce rôle, puis en utilisant la clé de condition `ResourceTag` dans une politique avec l'action `iam:PassRole`. Cette approche ne produit pas des résultats fiables.

Lors de la définition de l’autorisation `PassRole`, vous devez vous assurer qu’un utilisateur ne transfère pas un rôle ayant plus d’autorisations que ce que vous souhaitez pour l’utilisateur. Par exemple, Alice n’est peut-être pas autorisée à effectuer des actions Amazon S3. Si Alice pouvait transmettre un rôle à un service autorisant les actions Amazon S3, le service pourrait effectuer des actions Amazon S3 pour le compte d’Alice lors de l’exécution de la tâche.

Lorsque vous spécifiez un rôle lié à un service, vous devez également posséder l'autorisation de transmettre ce rôle au service. Certains services créent automatiquement un rôle lié à un service dans votre compte lorsque vous effectuez une action dans ce service. Par exemple, Amazon EC2 Auto Scaling crée automatiquement le rôle lié au service `AWSServiceRoleForAutoScaling` la première fois que vous créez un groupe Auto Scaling. Si vous essayez de spécifier le rôle lié au service lorsque vous créez un groupe Auto Scaling sans l'autorisation `iam:PassRole`, vous recevez une erreur. Si vous ne spécifiez pas explicitement le rôle, l'autorisation `iam:PassRole` n'est pas requise et la valeur par défaut est d'utiliser le rôle `AWSServiceRoleForAutoScaling` pour toutes les opérations effectuées sur ce groupe. Pour savoir quels services prennent en charge les rôles liés à un service, veuillez consulter [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour savoir quels services créent automatiquement un rôle lié à un service lorsque vous effectuez une action dans ce service, choisissez le lien **Oui** et consultez la documentation relative au rôle lié à un service pour le service.

Un utilisateur peut transmettre un ARN de rôle comme paramètre dans n'importe quelle opération d'API qui utilise le rôle pour attribuer des autorisations au service. Le service vérifie ensuite si cet utilisateur dispose de l'autorisation `iam:PassRole`. Pour que l'utilisateur transfère uniquement les rôles approuvés, vous pouvez filtrer l'autorisation `iam:PassRole` à l'aide de l'élément `Resources` de l'instruction de politique IAM. 

Vous pouvez utiliser `Condition` cet élément dans une politique JSON pour tester la valeur des clés incluses dans le contexte de toutes les AWS demandes. Pour en savoir plus sur l'utilisation des clés de condition dans une politique, consultez la section [Éléments de politique JSON IAM : Condition](reference_policies_elements_condition.md). La clé de condition `iam:PassedToService` peut être utilisée pour spécifier le principal de service du service auquel un rôle peut être transmis. Pour en savoir plus sur l'utilisation de la clé de `iam:PassedToService` condition dans une politique, consultez [iam : PassedToService](reference_policies_iam-condition-keys.md#ck_PassedToService).

**Exemple 1**  
Supposons que vous vouliez accorder à un utilisateur la possibilité de transférer l'un des ensembles de rôles approuvés au service Amazon EC2 lors du lancement d'une instance. Vous avez besoin de trois éléments :
+ Une *politique d'autorisations* IAM attachée au rôle qui détermine les opérations pouvant être exécutées par le rôle. Limitez les autorisations aux seules actions nécessaires pour le rôle et aux seules ressources dont le rôle a besoin pour exécuter ces actions. Vous pouvez utiliser une politique d' AWS autorisations IAM gérée ou créée par le client.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": {
          "Effect": "Allow",
          "Action": [ "A list of the permissions the role is allowed to use" ],
          "Resource": [ "A list of the resources the role is allowed to access" ]
      }
  }
  ```

------
+ Une* politique d'approbation* pour le rôle, qui permet au service d'endosser le rôle. Par exemple, vous pourriez attacher la politique d'approbation suivante au rôle avec l'action `UpdateAssumeRolePolicy`. Cette politique d'approbation permet à Amazon EC2 d'utiliser le rôle et les autorisations attachées au rôle.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": {
          "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole",
          "Effect": "Allow",
          "Principal": { "Service": "ec2.amazonaws.com" },
         "Action": "sts:AssumeRole"
      }
  }
  ```

------
+ Une *politique d'autorisations* IAM attachée à l'utilisateur IAM, qui permet à l'utilisateur de transférer uniquement les rôles qui sont approuvés. Vous ajoutez généralement `iam:GetRole` à `iam:PassRole` pour que l'utilisateur puisse obtenir les détails du rôle à transférer. Dans cet exemple, l'utilisateur peut transférer uniquement les rôles qui existent dans le compte spécifié avec des noms commençant par l'interface `EC2-roles-for-XYZ-` :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iam:GetRole",
                  "iam:PassRole"
              ],
              "Resource": "arn:aws:iam::111122223333:role/EC2-roles-for-XYZ-*"
          }
      ]
  }
  ```

------

L'utilisateur peut maintenant démarrer une instance Amazon EC2 avec un rôle affecté. Les applications qui s'exécutent sur l'instance peuvent accéder à des informations d'identification temporaires pour le rôle via les métadonnées du profil d'instance. Les politiques d'autorisations attachées au rôle déterminent ce que peut faire l'instance. 

**Exemple 2**  
Amazon Relational Database Service (Amazon RDS) prend en charge une fonction appelée **surveillance améliorée**. Cette fonctionnalité permet à Amazon RDS de surveiller une instance de base de données grâce à un agent. Cela permet également à Amazon RDS d'enregistrer les métriques dans Amazon CloudWatch Logs. Pour activer cette fonctionnalité, vous devez créer un rôle de service pour accorder à Amazon RDS des autorisations pour surveiller et écrire des métriques dans vos journaux. 

**Pour créer un rôle pour la surveillance améliorée Amazon RDS**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Cliquez sur **Rôles**, puis sur **Créer un rôle**.

1. Choisissez le type **AWS de rôle de service**, puis pour **Cas d'utilisation pour les autres Services AWS**, choisissez le service **RDS.** Choisissez **RDS - Enhanced Monitoring** (RDS - Surveillance améliorée), puis **Next** (Suivant).

1. Choisissez la politique **d'RDSEnhancedMonitoringRoleautorisation d'Amazon**.

1. Choisissez **Suivant**.

1. Pour **Role name** (Nom du rôle), saisissez un nom de rôle vous permettant d'identifier le but de ce rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Lorsqu'un nom de rôle est utilisé dans une politique ou dans le cadre d'un ARN, il est sensible à la casse. Lorsque le nom d'un rôle apparaît aux clients dans la console, par exemple lors du processus de connexion, il n'est pas sensible à la casse. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création.

1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle.

1. (Facultatif) Ajoutez des métadonnées à l'utilisateur en associant les balises sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).

1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.

Le rôle obtient automatiquement une politique d'approbation qui accorde au service `monitoring.rds.amazonaws.com` les autorisations nécessaires pour endosser le rôle. Une fois cette opération effectuée, Amazon RDS peut exécuter toutes les actions que la politique `AmazonRDSEnhancedMonitoringRole` autorise.

L'utilisateur pour lequel vous souhaitez activer la surveillance améliorée a besoin d'une politique incluant une instruction lui permettant de lister les fonctions RDS et une autre lui prermettant de transférer la fonction comme suit. Utilisez votre numéro de compte et remplacez le nom du rôle par le nom fourni à l'étape 6.

```
    {
      "Sid": "PolicyStatementToAllowUserToListRoles",
      "Effect": "Allow",
      "Action": ["iam:ListRoles"],
      "Resource": "*"
    },
    {
        "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
        "Effect": "Allow",
        "Action": [ "iam:PassRole" ],
        "Resource": "arn:aws:iam::account-id:role/RDS-Monitoring-Role"
    }
```

Vous pouvez combiner cette instruction avec des instructions d'une autre politique ou la placer dans sa propre politique. Au lieu de spécifier que l'utilisateur peut transférer un rôle commençant par `RDS-`, vous pouvez remplacer le nom du rôle dans l'ARN d'une ressource par un caractère générique, comme suit.

```
        "Resource": "arn:aws:iam::account-id:role/RDS-*"
```

## `iam:PassRole`actions dans les AWS CloudTrail journaux
<a name="id_roles_use_passrole_logs"></a>

 `PassRole`n'est pas un appel d'API. `PassRole`est une autorisation, ce qui signifie qu'aucun CloudTrail journal n'est généré pour IAM`PassRole`. Pour vérifier quels rôles sont transférés Services AWS à qui CloudTrail, vous devez consulter le CloudTrail journal qui a créé ou modifié la AWS ressource recevant le rôle. Par exemple, un rôle est transmis à une AWS Lambda fonction lors de sa création. le journal répertoriant l'action `CreateFunction` affichera l'enregistrement du rôle qui a été transmis à la fonction. 

# Révocation des informations d’identification de sécurité temporaires d’un rôle IAM
<a name="id_roles_use_revoke-sessions"></a>

**Avertissement**  
Si vous suivez les étapes indiquées sur cette page, tous les utilisateurs dont les sessions ont été créées en assumant le rôle se voient refuser l'accès à toutes les AWS actions et ressources. Cela peut entraîner le risque pour les utilisateurs de perdre leur travail non sauvegardé.

Lorsque vous autorisez les utilisateurs à accéder AWS Management Console à une session de longue durée (12 heures, par exemple), leurs informations d'identification temporaires n'expirent pas aussi rapidement. Si les utilisateurs exposent par inadvertance leurs informations d'identification à un tiers non autorisé, celui-ci dispose d'un accès pendant la durée de la session. Cependant, vous pouvez révoquer immédiatement toutes les autorisations aux informations d'identification du rôle émises avant un moment donné, si nécessaire. Toutes les informations d'identification temporaires pour ce rôle qui ont été émises avant le moment spécifié deviennent non valides. Cela force tous les utilisateurs à s'authentifier de nouveau et demande de nouvelles informations d'identification.

 

**Note**  
Vous ne pouvez pas révoquer la session d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)*.

Lorsque vous révoquez des autorisations pour un rôle à l'aide de la procédure décrite dans cette rubrique, AWS vous associez une nouvelle politique intégrée au rôle qui refuse toutes les autorisations pour toutes les actions. Il inclut une condition qui applique les restrictions uniquement si l'utilisateur a endossé le rôle *avant* le moment où vous avez révoqué les autorisations. Si l'utilisateur endosse le rôle *après* la révocation des autorisations, la politique de rejet ne s'applique pas à cet utilisateur.

Pour plus d'informations sur le refus d'accès, veuillez consulter la rubrique [Désactivation des autorisations affectées aux informations d'identification de sécurité temporaires](id_credentials_temp_control-access_disable-perms.md).

**Important**  
Cette politique de rejet s'applique à tous les utilisateurs du rôle spécifié, pas seulement à ceux dont les sessions de console durent plus longtemps.

## Autorisations minimales pour révoquer les autorisations de session d'un rôle
<a name="revoke-session-permissions"></a>

Pour révoquer les autorisations de session d'un rôle avec succès, vous devez disposer de l'autorisation `PutRolePolicy` pour ce rôle. Cela vous permet d'attacher la politique en ligne `AWSRevokeOlderSessions` au rôle.

## Révocation des autorisations de session
<a name="revoke-session"></a>

Vous pouvez révoquer les autorisations de session d’un rôle afin de refuser toutes les autorisations à tout utilisateur qui a endossé le rôle.

**Note**  
Vous ne pouvez pas modifier les rôles qui ont été créés dans IAM à partir des jeux de permissions d’IAM IAM Identity Center. Vous devez révoquer la session d’ensemble d’autorisations active pour un utilisateur dans IAM Identity Center. Pour plus d’informations, consultez [Révocation des sessions de rôle IAM actives créées par des ensembles d’autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) dans le *Guide de l’utilisateur d’IAM Identity Center*.

**Pour refuser immédiatement toutes autorisations à tout utilisateur actuel des informations d'identification du rôle**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Rôles**, puis le nom (pas la case à cocher) du rôle dont vous voulez révoquer les autorisations.

1. Sur la page **Récapitulatif** du rôle sélectionné, choisissez l'onglet **Révoquer les sessions**.

1. Dans l'onglet **Révoquer les sessions**, choisissez **Révoquer les sessions actives**.

1. AWS vous demande de confirmer l'action. Cochez la case **Je reconnais que je révoque toutes les sessions actives pour ce rôle.** et choisissez **Révoquer les sessions actives** dans la boîte de dialogue.

   IAM attache ensuite une politique nommée `AWSRevokeOlderSessions` au rôle. Après avoir sélectionné **Révoquer les sessions actives**, la politique refuse tout accès aux utilisateurs qui ont assumé le rôle dans le passé ainsi qu’environ 30 secondes dans le futur. Ce choix du temps futur tient compte du délai de propagation de la politique afin de traiter une nouvelle session acquise ou renouvelée avant que la politique mise à jour ne soit en vigueur dans une région donnée. Tout utilisateur qui endosse le rôle plus de 30 secondes environ après que vous avez choisi Révoquer les sessions actives n’est pas affecté. Pour savoir pourquoi les modifications ne sont pas toujours visibles immédiatement, consultez la section [Les modifications que j'apporte ne sont pas toujours visibles immédiatement](troubleshoot.md#troubleshoot_general_eventual-consistency). 

**Note**  
Si vous choisissez **Révoquer les sessions actives** ultérieurement, l’horodatage de la politique sera actualisé et elle refusera à nouveau toutes les autorisations à tout utilisateur ayant endossé le rôle avant la nouvelle heure spécifiée.

Les utilisateurs valides dont les sessions sont révoquées de cette manière doivent obtenir des informations d'identification temporaires pour qu'une nouvelle session continue de fonctionner. Les informations d'identification sont mises en AWS CLI cache jusqu'à leur expiration. Pour forcer la CLI à supprimer et actualiser les informations d'identification mises en cache qui ne sont plus valides, exécutez l'une des commandes suivantes :

**Linux, macOS ou Unix**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```

## Révocation des autorisations de session avant une heure spécifiée
<a name="revoke-session-policy"></a>

 Vous pouvez également révoquer les autorisations de session à tout moment de votre choix à l'aide du SDK AWS CLI ou afin de spécifier une valeur pour la `aws:TokenIssueTime` clé dans l'élément Condition d'une politique. 

Cette politique refuse toutes les autorisations lorsque la valeur de `aws:TokenIssueTime` est antérieure aux date et heure spécifiées. La valeur de `aws:TokenIssueTime` correspond à l'exacte à laquelle les informations d'identification de sécurité temporaires ont été créées. La `aws:TokenIssueTime` valeur n'est présente que dans le contexte des AWS demandes signées avec des informations d'identification de sécurité temporaires, de sorte que l'instruction Deny de la politique n'affecte pas les demandes signées avec les informations d'identification à long terme de l'utilisateur IAM.

Cette politique peut également être attachée à un rôle. Dans ce cas, la politique affecte uniquement les informations d'identification de sécurité temporaires créées par le rôle avant la date et l'heure spécifiées.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}
```

------

Les utilisateurs valides dont les sessions sont révoquées de cette manière doivent obtenir des informations d'identification temporaires pour qu'une nouvelle session continue de fonctionner. Les informations d'identification sont mises en AWS CLI cache jusqu'à leur expiration. Pour forcer la CLI à supprimer et actualiser les informations d'identification mises en cache qui ne sont plus valides, exécutez l'une des commandes suivantes :

**Linux, macOS ou Unix**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```

# Mise à jour d’un rôle lié à un service
<a name="id_roles_update-service-linked-role"></a>

La méthode que vous utilisez pour modifier un rôle lié à un service dépend dudit service. Certains services peuvent vous permettre de modifier les autorisations d'un rôle lié à un service depuis la console, l'API ou la CLI. Cependant, une fois un rôle lié à un service créé, vous ne pouvez pas changer le nom d'un rôle car plusieurs entités peuvent faire référence au rôle. Vous pouvez modifier la description de n'importe quel rôle depuis la console IAM, l'API ou la CLI.

Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Pour savoir si le service prend en charge la modification du rôle lié à un service, choisissez le lien **Oui** pour afficher la documentation du rôle lié à ce service.

## Modification de la description d'un rôle lié à un service (console)
<a name="edit-service-linked-role-iam-console"></a>

Vous pouvez utiliser la console IAM pour modifier la description d'un rôle lié à un service.

**Pour modifier la description d'un rôle lié à un service (console)**

1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.

1. Choisissez le nom du rôle à modifier.

1. A l'extrême droite de **Description du rôle**, choisissez **Edit (Modifier)**. 

1. Saisissez une nouvelle description dans la zone et choisissez **Save (Enregistrer)**.

## Modification de la description d'un rôle lié à un service (AWS CLI)
<a name="edit-service-linked-role-iam-cli"></a>

Vous pouvez utiliser les commandes IAM depuis le AWS CLI pour modifier la description d'un rôle lié à un service.

**Pour changer la description d'un rôle lié à un service (AWS CLI)**

1. (Facultatif) Pour afficher la description actuelle d'un rôle, exécutez les commandes suivantes :

   ```
   aws iam [get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) --role-name ROLE-NAME
   ```

   Utilisez le nom du rôle, pas l'ARN, pour faire référence aux rôles avec les commandes CLI. Par exemple, si un rôle a l'ARN : `arn:aws:iam::123456789012:role/myrole`, vous faites référence au rôle en tant que **myrole**.

1. Pour mettre à jour la description d'un rôle lié à un service, exécutez la commande suivante :

   ```
   aws iam [update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) --role-name ROLE-NAME --description OPTIONAL-DESCRIPTION
   ```

## Modification d'une description de rôle liée à un service (API)AWS
<a name="edit-service-linked-role-iam-api"></a>

Vous pouvez utiliser l' AWS API pour modifier la description d'un rôle lié à un service.

**Pour modifier la description d'un rôle lié à un service (API)AWS**

1. (Facultatif) Pour afficher la description actuelle d'un rôle, appelez l'opération suivante et spécifiez le nom du rôle :

   AWS API : [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. Pour mettre à jour la description d'un rôle, appelez l'opération suivante et spécifiez le nom (et la description facultative) du rôle : 

   AWS API : [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) 

# Mise à jour d’une politique d’approbation de rôle
<a name="id_roles_update-role-trust-policy"></a>

Pour modifier la personne qui peut endosser un rôle, vous devez modifier la politique d'approbation du rôle. Vous ne pouvez pas modifier la politique d'approbation d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)*.

**Remarques**  
Si un utilisateur est répertorié comme principal dans la politique d'approbation d'un rôle, mais ne peut pas endosser le rôle, vérifiez les [limites d'autorisations](access_policies_boundaries.md) de l'utilisateur. Si une limite d'autorisation est définie pour l'utilisateur, elle doit autoriser l'action `sts:AssumeRole`.
Pour permettre aux utilisateurs d'assumer à nouveau le rôle actuel au cours d'une session de rôle, spécifiez l'ARN du rôle ou l' Compte AWS ARN comme principal dans la politique de confiance des rôles. Services AWS qui fournissent des ressources de calcul telles qu'Amazon EC2, Amazon ECS, Amazon EKS et Lambda fournissent des informations d'identification temporaires et mettent automatiquement à jour ces informations d'identification. Cela garantit que vous disposez toujours d'un ensemble d'informations d'identification valide. Pour ces services, il n'est pas nécessaire d'endosser à nouveau le rôle actuel pour obtenir des informations d'identification temporaires. Toutefois, si vous avez l'intention de transférer des [balises de session](id_session-tags.md) ou une [politique de session](access_policies.md#policies_session), vous devez endosser à nouveau le rôle actuel.


## Mise à jour d’une politique d’approbation de rôle (console)
<a name="id_roles_update-trust-policy-console"></a>

**Pour modifier une politique de confiance dans les rôles dans AWS Management Console**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.

1. Dans la liste des rôles de votre compte, choisissez le nom du rôle que vous souhaitez modifier.

1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la politique d'approbation).

1. Modifiez la politique d'approbation au besoin. Pour ajouter des principaux supplémentaires capables d'endosser le rôle, spécifiez-les dans l'élément `Principal`. Par exemple, l'extrait de politique suivant montre comment faire référence à deux éléments Comptes AWS dans l'`Principal`élément :

   ```
   "Principal": {
     "AWS": [
       "arn:aws:iam::111122223333:root",
       "arn:aws:iam::444455556666:root"
     ]
   },
   ```

   Si vous spécifiez un principal dans un autre compte, l'ajout d'un compte à la politique d'approbation d'un rôle n'est qu'une partie de la procédure d'établissement de la relation d'approbation entre comptes. Par défaut, aucun utilisateur des comptes approuvés ne peut endosser le rôle. L'administrateur du compte nouvellement approuvé doit accorder aux utilisateurs l'autorisation d'endosser le rôle. Pour ce faire, l'administrateur doit créer ou modifier une politique attachée à l'utilisateur pour lui permettre d'accéder à l'action `sts:AssumeRole`. Pour plus d'informations, consultez la procédure suivante ou [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

   L'extrait de politique suivant montre comment référencer deux AWS services dans l'`Principal`élément :

   ```
   "Principal": {
     "Service": [
       "opsworks.amazonaws.com",
       "ec2.amazonaws.com"
     ]
   },
   ```

1. Après avoir modifié votre politique d'approbation, choisissez **Mettre à jour la politique** pour enregistrer vos modifications.

   Pour plus d'informations sur la syntaxe et la structure de la politique, consultez les sections [Politiques et autorisations dans Gestion des identités et des accès AWS](access_policies.md) et [Référence de l’élément de politique JSON IAM](reference_policies_elements.md).

**Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle (console)**

Pour plus d'informations sur cette procédure, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

1. Connectez-vous à l'externe de confiance Compte AWS. 

1. Décidez si vous devez attacher les autorisations à un utilisateur ou à un groupe. Dans le panneau de navigation de la console IAM, sélectionnez **Users** (Utilisateurs) ou **User groups** (Groupes d'utilisateurs) selon le cas.

1. Choisissez le nom de l'utilisateur ou du groupe auquel vous souhaitez accorder l'accès, puis sélectionnez l'onglet **Autorisations**.

1. Effectuez l’une des actions suivantes :
   + Pour modifier une politique gérée par un client, choisissez le nom de la politique, choisissez **Modifier la politique**, puis l'onglet **JSON**. Vous ne pouvez pas modifier une politique AWS gérée. AWS les politiques gérées apparaissent avec l' AWS icône (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_icon.png)). Pour plus d'informations sur la différence entre les stratégies gérées AWS et les stratégies gérées par le client, consultez [Politiques gérées et politiques en ligne](access_policies_managed-vs-inline.md).
   + Pour modifier une politique en ligne, choisissez la flèche en regard du nom de la politique et choisissez **Modifier la politique**.

1. Dans l'éditeur de politiques, ajoutez un nouvel élément `Statement` spécifiant ce qui suit :

   ```
   {
     "Effect": "Allow",
     "Action": "sts:AssumeRole",
     "Resource": "arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME"
   }
   ```

   Remplacez l'ARN dans l'instruction par celui du rôle que l'utilisateur peut endosser.

1. Suivez les invites à l'écran pour terminer de modifier la politique. 

## Mise à jour d’une politique d’approbation de rôle (AWS CLI)
<a name="id_roles-update-trust-policy-cli"></a>

Vous pouvez utiliser le AWS CLI pour modifier les personnes autorisées à assumer un rôle.

**Pour modifier une politique d'approbation de rôle (AWS CLI)**

1. (Facultatif) Si vous ne connaissez pas le nom du rôle que vous souhaitez modifier, exécutez la commande suivante pour répertorier les rôles de votre compte :
   + [aws iam list-roles](https://docs.aws.amazon.com/cli/latest/reference/iam/list-roles.html)

1. (Facultatif) Pour afficher la politique d'approbation actuelle d'un rôle, exécutez la commande suivante :
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. Pour modifier les principaux approuvés ayant accès au rôle, créez un fichier texte avec la politique d'approbation mise à jour. Vous pouvez utiliser l'éditeur de texte pour créer la politique.

   Par exemple, la politique d'approbation suivante illustre comment référencer deux Comptes AWS dans l'élément `Principal`. Cela permet aux utilisateurs séparés Comptes AWS d'assumer ce rôle.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"AWS": [
               "arn:aws:iam::111122223333:root",
               "arn:aws:iam::444455556666:root"
           ]},
           "Action": "sts:AssumeRole"
       }
   }
   ```

------

   Si vous spécifiez un principal dans un autre compte, l'ajout d'un compte à la politique d'approbation d'un rôle n'est qu'une partie de la procédure d'établissement de la relation d'approbation entre comptes. Par défaut, aucun utilisateur des comptes approuvés ne peut endosser le rôle. L'administrateur du compte nouvellement approuvé doit accorder aux utilisateurs l'autorisation d'endosser le rôle. Pour ce faire, l'administrateur doit créer ou modifier une politique attachée à l'utilisateur pour lui permettre d'accéder à l'action `sts:AssumeRole`. Pour plus d'informations, consultez la procédure suivante ou [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

1. Pour utiliser le fichier créé afin de mettre à jour la politique de confiance, exécutez la commande suivante :
   + [était un objectif update-assume-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-assume-role-policy.html)

**Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle (AWS CLI)**

Pour plus d'informations sur cette procédure, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

1. Créez un fichier JSON contenant une politique d'autorisations qui accorde des autorisations permettant d'endosser le rôle. Par exemple, la politique suivante contient les autorisations nécessaires minimales :

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME"
       }
   }
   ```

------

   Remplacez l'ARN dans l'instruction par celui du rôle que l'utilisateur peut endosser.

1. Exécutez la commande suivante pour charger le fichier JSON contenant la politique de confiance dans IAM :
   + [aws iam create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html)

   Le résultat de cette commande inclut l'ARN de la politique. Notez cet ARN, car vous aurez besoin de l'utiliser ultérieurement. 

1. Décidez à quel utilisateur ou groupe attacher la politique. Si vous ne connaissez pas le nom de l'utilisateur ou du groupe concerné, utilisez les commandes suivantes pour répertorier les utilisateurs ou les groupes de votre compte :
   + [aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)
   + [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html)

1. Utilisez l'une des commandes suivantes pour attacher la politique créée dans l'étape précédente à l'utilisateur ou au groupe :
   + [était un objectif attach-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html)
   + [était un objectif attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)

## Mettre à jour une politique de confiance dans les rôles (AWS API)
<a name="id_roles-update-trust-policy-api"></a>

Vous pouvez utiliser l' AWS API pour modifier les personnes autorisées à assumer un rôle.

**Pour modifier une politique de confiance des rôles (AWS API)**

1. (Facultatif) Si vous ne connaissez pas le nom du rôle que vous souhaitez modifier, appelez l'opération suivante pour répertorier les rôles de votre compte :
   + [ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html)

1. (Facultatif) Pour afficher la politique d'approbation actuelle d'un rôle, appelez l'opération suivante :
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)

1. Pour modifier les principaux approuvés ayant accès au rôle, créez un fichier texte avec la politique d'approbation mise à jour. Vous pouvez utiliser l'éditeur de texte pour créer la politique.

   Par exemple, la politique d'approbation suivante illustre comment référencer deux Comptes AWS dans l'élément `Principal`. Cela permet aux utilisateurs séparés Comptes AWS d'assumer ce rôle.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"AWS": [
               "arn:aws:iam::111122223333:root",
               "arn:aws:iam::444455556666:root"
           ]},
           "Action": "sts:AssumeRole"
       }
   }
   ```

------

   Si vous spécifiez un principal dans un autre compte, l'ajout d'un compte à la politique d'approbation d'un rôle n'est qu'une partie de la procédure d'établissement de la relation d'approbation entre comptes. Par défaut, aucun utilisateur des comptes approuvés ne peut endosser le rôle. L'administrateur du compte nouvellement approuvé doit accorder aux utilisateurs l'autorisation d'endosser le rôle. Pour ce faire, l'administrateur doit créer ou modifier une politique attachée à l'utilisateur pour lui permettre d'accéder à l'action `sts:AssumeRole`. Pour plus d'informations, consultez la procédure suivante ou [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

1. Pour utiliser le fichier créé afin de mettre à jour la politique de confiance, appelez l'opération suivante :
   + [UpdateAssumeRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html)

**Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle (AWS API)**

Pour plus d'informations sur cette procédure, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).

1. Créez un fichier JSON contenant une politique d'autorisations qui accorde des autorisations permettant d'endosser le rôle. Par exemple, la politique suivante contient les autorisations nécessaires minimales :

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME"
       }
   }
   ```

------

   Remplacez l'ARN dans l'instruction par celui du rôle que l'utilisateur peut endosser.

1. Appelez l'opération suivante pour charger le fichier JSON contenant la politique de confiance dans IAM :
   + [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html)

   Le résultat de cette opération inclut l'ARN de la politique. Notez cet ARN, car vous aurez besoin de l'utiliser ultérieurement. 

1. Décidez à quel utilisateur ou groupe attacher la politique. Si vous ne connaissez pas le nom de l'utilisateur ou du groupe concerné, appelez les opérations suivantes pour répertorier les utilisateurs ou les groupes de votre compte :
   + [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)
   + [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html)

1. Appelez l'une des opérations suivantes pour attacher la politique créée à l'étape précédente à l'utilisateur ou au groupe :
   +  API : [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html)
   + [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)

# Mettre à jour les autorisations pour un rôle
<a name="id_roles_update-role-permissions"></a>

Utilisez les procédures suivantes pour mettre à jour les politiques d’autorisation et les limites des autorisations d’un rôle.

## Prérequis : afficher l’accès au rôle
<a name="roles-modify_prerequisites"></a>

Avant de modifier les autorisations d'un rôle, vous devez passer en revue ses activités récentes au niveau service. Ceci est important, car vous ne souhaitez pas supprimer l'accès à partir d'un principal (personne ou application) qui l'utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md).

## Mettre à jour une politique d’autorisation pour un rôle
<a name="id_roles_update-role-permissions-policy"></a>

Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle (ou les stratégies). Vous ne pouvez pas modifier la politique d'autorisations d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)* dans IAM. Vous pouvez modifier la politique d'autorisations dans le service dépendant du rôle. Pour vérifier si un service prend en charge cette fonctionnalité, reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services qui possèdent **Yes (Oui)**dans la colonne **Rôles liés à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.

### Mise à jour d’une politique d’autorisations de rôle (console)
<a name="id_roles_update-role-permissions-policy-console"></a>

**Pour changer les autorisations autorisées par un rôle (console)**

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.

1. Choisissez le nom du rôle à modifier, puis choisissez l'onglet **Autorisations**.

1. Effectuez l’une des actions suivantes :
   + Pour modifier une politique existante gérée par le client, choisissez le nom de la politique, puis choisissez **Modifier la politique**.
**Note**  
Vous ne pouvez pas modifier une politique AWS gérée. AWS les politiques gérées apparaissent avec l' AWS icône (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_icon.png)). Pour plus d'informations sur la différence entre les politiques AWS gérées et les politiques gérées par le client, consultez[Politiques gérées et politiques en ligne](access_policies_managed-vs-inline.md). 
   + Pour attacher une stratégie gérée existante au rôle, choisissez **Add permissions** (Ajouter des autorisations) puis choisissez **Attach policies** (Attacher des politiques).
   + Pour modifier une politique en ligne existante, développez la politique et choisissez **Edit** (Modifier).
   + Pour intégrer une nouvelle politique en ligne, choisissez **Add permissions** (Ajouter des autorisations) puis choisissez **Create inline policy** (Création de stratégie en ligne). 
   + Pour supprimer une politique existante du rôle, cochez la case située en regard du nom de la politique et sélectionnez **Retirer**.

### Mise à jour d’une politique d’autorisations de rôle (AWS CLI)
<a name="id_roles_update_permissions-policy-cli"></a>

Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle (ou les stratégies). Vous ne pouvez pas modifier la politique d'autorisations d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)* dans IAM. Vous pouvez modifier la politique d'autorisations dans le service dépendant du rôle. Pour vérifier si un service prend en charge cette fonctionnalité, reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services qui possèdent **Yes (Oui)**dans la colonne **Rôles liés à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.

**Pour modifier les autorisations autorisées par un rôle (AWS CLI)**

1. (Facultatif) Pour afficher les autorisations actuelles associées à un rôle, exécutez les commandes suivantes :

   1. [aws vise à list-role-policies répertorier](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-policies.html) les politiques en ligne

   1. [aws iam va list-attached-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html) répertorier les politiques gérées

1. La commande permettant de mettre à jour les autorisations du rôle varie selon que vous mettez à jour une politique gérée ou une politique en ligne.

   Pour mettre à jour une politique gérée, exécutez la commande suivante pour créer une nouvelle version de la politique gérée :
   + [était un objectif create-policy-version](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html)

   Pour mettre à jour une politique en ligne, exécutez la commande suivante :
   + [était un objectif put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

### Mettre à jour une politique d'autorisation de rôle (AWS API)
<a name="id_roles_update_permissions-policy-api"></a>

Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle (ou les stratégies). Vous ne pouvez pas modifier la politique d'autorisations d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)* dans IAM. Vous pouvez modifier la politique d'autorisations dans le service dépendant du rôle. Pour vérifier si un service prend en charge cette fonctionnalité, reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services qui possèdent **Yes (Oui)**dans la colonne **Rôles liés à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.

**Pour modifier les autorisations accordées par un rôle (AWS API)**

1. (Facultatif) Pour afficher les autorisations actuelles associées à un rôle, appelez les opérations suivantes :

   1. [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html)pour répertorier les politiques en ligne

   1. [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html)pour répertorier les politiques gérées

1. L'opération permettant de mettre à jour les autorisations du rôle varie selon que vous mettez à jour une politique gérée ou une politique en ligne.

   Pour mettre à jour une politique gérée, appelez l'opération suivante pour créer une nouvelle version de la politique gérée :
   + [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html)

   Pour mettre à jour une politique en ligne, appelez l'opération suivante :
   + [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

## Mettre à jour la limite des autorisations pour un rôle
<a name="id_roles_update-role-permissions-boundary"></a>

Pour modifier le nombre maximum d'autorisations permises pour un rôle, modifiez la [limite d'autorisations](access_policies_boundaries.md) du rôle

### Mise à jour d’une limite des autorisations de rôle (console)
<a name="id_roles_update-permissions-boundary-console"></a>

**Pour modifier la politique utilisée afin de définir la limite d'autorisations pour un rôle**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Rôles**.

1. Sélectionnez le nom du rôle présentant la [limite d'autorisations](access_policies_boundaries.md) que vous souhaitez modifier. 

1. Sélectionnez l’onglet **Autorisations**. Si nécessaire, ouvrez la section **Permissions boundary (Limite d'autorisations)**, puis choisissez **Change boundary (Modifier une limite)**.

1. Sélectionnez la politique que vous souhaitez utiliser pour la limite d'autorisations.

1. Choisissez **Change boundary (Modifier une limite)**.

   Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle.

### Mise à jour d’une limite des autorisations de rôle (AWS CLI)
<a name="id_roles_update_permissions-boundary-cli"></a>

**Pour modifier la politique gérée utilisée afin de définir la limite d'autorisations pour un rôle (AWS CLI)**

1. (Facultatif) Pour afficher la [limite d'autorisations](access_policies_boundaries.md) actuelle d'un rôle, exécutez la commande suivante : 
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. Pour utiliser une autre politique gérée afin de mettre à jour la limite d'autorisations d'un rôle, exécutez la commande suivante : 
   + [était un objectif put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)

   Un rôle peut disposer d'une seule politique gérée définie comme une limite d'autorisations. Si vous modifiez la limite d'autorisations, cela modifie le nombre maximum d'autorisations permises pour un rôle.

### Mettre à jour la limite d'autorisations d'un rôle (AWS API)
<a name="id_roles_update-permissions-boundary-api"></a>

**Pour modifier la politique gérée utilisée pour définir la limite des autorisations pour un rôle (AWS API)**

1. (Facultatif) Pour afficher la [limite d'autorisations](access_policies_boundaries.md) actuelle d'un rôle, appelez l'opération suivante : 
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)

1. Pour utiliser une autre politique gérée afin de mettre à jour la limite d'autorisations d'un rôle, appelez l'opération suivante : 
   + [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)

   Un rôle peut disposer d'une seule politique gérée définie comme une limite d'autorisations. Si vous modifiez la limite d'autorisations, cela modifie le nombre maximum d'autorisations permises pour un rôle.

# Mise à jour des paramètres pour un rôle
<a name="id_roles_update-role-settings"></a>

Utilisez les procédures suivantes pour mettre à jour la description d’un rôle ou modifier la durée maximale de session d’un rôle.

## Mettre à jour la description d’un rôle
<a name="id_roles_update-description"></a>

Pour modifier la description du rôle, modifiez le texte de la description.

### Mise à jour d’une description de rôle (console)
<a name="id_roles_update-description-console"></a>

**Pour modifier la description d'un rôle (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.

1. Choisissez le nom du rôle à modifier.

1. Dans la section **Summary** (Récapitulatif), sélectionnez **Edit** (Modifier).

1. Saisissez une nouvelle description dans le champ et sélectionnez **Save changes** (Enregistrer les modifications).

### Mise à jour de la description d’un rôle (AWS CLI)
<a name="id_roles_update-description-cli"></a>

**Pour modifier la description d'un rôle (AWS CLI)**

1. (Facultatif) Pour afficher la description actuelle d'un rôle, exécutez la commande suivante :
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. Pour mettre à jour la description d'un rôle, exécutez la commande suivante avec le paramètre de description :
   + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html)

### Mettre à jour la description d'un rôle (AWS API)
<a name="id_roles_update-description-api"></a>

**Pour modifier la description d'un rôle (AWS API)**

1. (Facultatif) Pour afficher la description actuelle d'un rôle, appelez l'opération suivante :
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. Pour mettre à jour la description d'un rôle, appelez l'opération suivante avec le paramètre de description :
   + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html)

## Mettre à jour la durée de session maximale pour un rôle
<a name="id_roles_update-session-duration"></a>

Pour spécifier le paramètre de durée de session maximale pour les rôles assumés à l'aide de la console, de l' AWS CLI AWS API ou de l'API, modifiez la valeur du paramètre de durée maximale de session. La valeur de ce paramètre peut varier de 1 heure à 12 heures. Si vous ne spécifiez pas de valeur, la valeur par défaut de 1 heure maximum est appliquée. Ce paramètre ne limite pas les sessions prises en charge par AWS les services.

### Mise à jour de la durée de session maximale d’un rôle (console)
<a name="id_roles_update-session-duration-console"></a><a name="id_roles_modify_max-session"></a>

**Pour modifier le paramètre de durée maximale de session pour les rôles assumés à l'aide de la console ou de AWS l'API (console) AWS CLI**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.

1. Choisissez le nom du rôle à modifier.

1. Dans la section **Summary** (Récapitulatif), sélectionnez **Edit** (Modifier).

1. Pour **Maximum session duration** (Durée de session maximale), choisissez une valeur. Autrement, vous pouvez choisir **Custom duration** (Durée personnalisée) et saisir une valeur (en secondes).

1. Sélectionnez **Enregistrer les modifications**.

   Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. Pour apprendre à révoquer des sessions existantes pour ce rôle, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md).

Dans le AWS Management Console, les sessions utilisateur IAM durent 12 heures par défaut. Les utilisateurs IAM qui changent de rôle dans la console se voient accorder la durée de session maximale du rôle ou le temps restant dans la session de l'utilisateur IAM, selon la durée la plus courte.

Toute personne assumant le rôle depuis l' AWS API AWS CLI or peut demander une session plus longue, jusqu'à ce maximum. Le paramètre `MaxSessionDuration` détermine la durée maximale de la session de rôle qui peut être demandée.
+ Pour spécifier une durée de session à l'aide du paramètre, AWS CLI utilisez le `duration-seconds` paramètre. Pour en savoir plus, veuillez consulter la section [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md).
+ Pour spécifier une durée de session à l'aide de l' AWS API, utilisez le `DurationSeconds` paramètre. Pour en savoir plus, veuillez consulter la section [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md). 

### Mise à jour de la durée de session maximale d’un rôle (AWS CLI)
<a name="id_roles_update-session-duration-cli"></a>

**Note**  
Toute personne assumant le rôle depuis l'API AWS CLI or peut utiliser le paramètre `duration-seconds` CLI ou le paramètre `DurationSeconds` API pour demander une session plus longue. Le paramètre `MaxSessionDuration` détermine la durée maximale de la session de rôle qui peut être demandée à l'aide du paramètre `DurationSeconds`. Si les utilisateurs ne spécifient pas de valeur pour le paramètre `DurationSeconds`, leurs informations d'identification de sécurité sont valides pendant une heure.

**Pour modifier le paramètre de durée maximale de session pour les rôles assumés à l'aide de AWS CLI (AWS CLI)**

1. (Facultatif) Pour afficher le paramètre de durée de session maximale d'un rôle, exécutez la commande suivante :
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. Pour mettre à jour le paramètre de durée de session maximale d'un rôle, exécutez la commande suivante avec le paramètre `max-session-duration` de l'interface de ligne de commande ou le paramètre `MaxSessionDuration` de l'API :
   + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html)

   Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. Pour apprendre à révoquer des sessions existantes pour ce rôle, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md).

### Mise à jour de la durée maximale des sessions de rôle (AWS API)
<a name="id_roles_update-session-duration-api"></a>

**Note**  
Toute personne assumant le rôle depuis l'API AWS CLI or peut utiliser le paramètre `duration-seconds` CLI ou le paramètre `DurationSeconds` API pour demander une session plus longue. Le paramètre `MaxSessionDuration` détermine la durée maximale de la session de rôle qui peut être demandée à l'aide du paramètre `DurationSeconds`. Si les utilisateurs ne spécifient pas de valeur pour le paramètre `DurationSeconds`, leurs informations d'identification de sécurité sont valides pendant une heure.

**Pour modifier le paramètre de durée maximale de session pour les rôles assumés à l'aide de l'API (AWS API)**

1. (Facultatif) Pour afficher le paramètre de durée de session maximale d'un rôle, appelez l'opération suivante :
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. Pour mettre à jour le paramètre de durée de session maximale d'un rôle, appelez l'opération suivante avec le paramètre `max-sessionduration` de la CLI ou le paramètre `MaxSessionDuration` de l'API :
   + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html)

   Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. Pour apprendre à révoquer des sessions existantes pour ce rôle, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md).

# Suppression de rôles ou de profils d’instance
<a name="id_roles_manage_delete"></a>

Si vous n'avez plus besoin d'un rôle, nous vous recommandons de supprimer le rôle et ses autorisations associées. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. 

Si le rôle était associé à une instance EC2, vous pouvez également le supprimer du profil d'instance, puis supprimer ce dernier.

**Avertissement**  
Vérifiez qu'aucune instance Amazon EC2 n'est en cours d'exécution avec le rôle ou le profil d'instance que vous êtes sur le point de supprimer. La suppression d'un rôle ou d'un profil d'instance associé à une instance en cours d'exécution arrêtera toutes les applications qui s'exécutent sur l'instance.

Si vous préférez ne pas supprimer définitivement un rôle, vous pouvez le désactiver. Pour ce faire, modifiez les politiques du rôle, puis révoquez toutes les sessions en cours. Par exemple, vous pouvez ajouter une politique au rôle qui refuse l'accès à tous AWS. Vous pouvez également modifier la politique d'approbation pour refuser l'accès à toute personne qui tente d'endosser le rôle. Pour en savoir plus sur la révocation des sessions, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md).

**Topics**
+ [Affichage de l’accès au rôle](#roles-delete_prerequisites)
+ [Suppression d'un rôle lié à un service](#id_roles_manage_delete_slr)
+ [Suppression d'un rôle IAM (console)](#roles-managingrole-deleting-console)
+ [Suppression d'un rôle IAM (AWS CLI)](#roles-managingrole-deleting-cli)
+ [Supprimer un rôle IAM (AWS API)](#roles-managingrole-deleting-api)
+ [Informations connexes](#roles-managingrole-deleting-related-info)

## Affichage de l’accès au rôle
<a name="roles-delete_prerequisites"></a>

Avant de supprimer un rôle, nous vous recommandons de vérifier la date de sa dernière utilisation. Vous pouvez le faire à l'aide de l'API AWS Management Console AWS CLI, du ou de l' AWS API. Vous devriez consulter ces informations, car vous ne voulez pas retirer l'accès à une personne utilisant ce rôle. 

La date de la dernière activité du rôle peut ne pas correspondre à la dernière date indiquée dans l’onglet **Dernière consultation**. L’onglet [**Dernière consultation**](access_policies_last-accessed-view-data.md) signale l’activité uniquement pour les services autorisés par les politiques d’autorisations du rôle. La date de la dernière activité du rôle inclut la dernière tentative d'accès à un service dans lequel le rôle a été créé AWS.

**Note**  
La période de suivi de la dernière activité d’un rôle et des données Dernière consultation correspond aux 400 jours précédents. Cette période peut être plus courte si votre région a commencé à prendre en charge ces fonctionnalités au cours de la dernière année. Le rôle aurait pu être utilisé il y a plus de 400 jours. Pour de plus amples informations sur la période de suivi, veuillez consulter [Où AWS suit les dernières informations consultées](access_policies_last-accessed.md#last-accessed_tracking-period).

**Pour afficher la date à laquelle un rôle a été utilisé pour la dernière fois (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Rôles**.

1. Recherchez la ligne du rôle dont vous souhaitez afficher l'activité. Vous pouvez utiliser le champ de recherche pour affiner les résultats. Affichez la colonne **Dernière activité** pour voir le nombre de jours écoulés depuis la dernière utilisation du rôle. Si le rôle n'a pas été utilisé pendant la période de suivi, le tableau affiche **Aucun**. 

1. Choisissez le nom du rôle pour afficher plus d'informations. La page **Summary** (Résumé) du rôle inclut également **Last activity** (Dernière activité), qui affiche la date à laquelle le rôle a été utilisé pour la dernière fois. Si le rôle n'a pas été utilisé au cours des 400 derniers jours, la **Dernière activité** affiche **Non consulté pendant la période de suivi**.

**Pour voir quand un rôle a été utilisé pour la dernière fois (AWS CLI)**  
`[aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)` - Exécutez cette commande pour renvoyer des informations sur un rôle, y compris l'objet `RoleLastUsed`. Cet objet contient la `LastUsedDate` et la `Region` dans laquelle le rôle a été utilisé pour la dernière fois. Si `RoleLastUsed` est présent mais ne contient pas de valeur, le rôle n'a pas été utilisé pendant la période de suivi.

**Pour voir quand un rôle a été utilisé pour la dernière fois (AWS API)**  
`[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/GetRole.html)` - Appelez cette opération pour renvoyer des informations sur un rôle, y compris l'objet `RoleLastUsed`. Cet objet contient la `LastUsedDate` et la `Region` dans laquelle le rôle a été utilisé pour la dernière fois. Si `RoleLastUsed` est présent mais ne contient pas de valeur, le rôle n'a pas été utilisé pendant la période de suivi.

## Suppression d'un rôle lié à un service
<a name="id_roles_manage_delete_slr"></a>

La méthode que vous utilisez pour supprimer un rôle lié à un service dépend dudit service. Dans certains cas, vous n'avez pas besoin de supprimer manuellement un rôle lié à un service. Par exemple, lorsque vous terminez une action donnée (comme supprimer une ressource) dans le service, le service peut supprimer le rôle lié au service à votre place. Dans d'autres cas, le service peut prendre en charge la suppression manuelle d'un rôle lié à un service à partir de la console, de l'API ou de la AWS CLI. 

Consultez la documentation relative au *[rôle lié au service](id_roles.md#iam-term-service-linked-role)* dans le service lié pour savoir comment supprimer le rôle. Pour afficher les rôles liés à un service de votre compte, rendez-vous sur la page **IAM Roles** (Rôles IAM) de la console. Les rôles liés à un service s'affichent avec **(Rôle lié à un service)** mentionné dans la colonne **Entités de confiance** du tableau. Une bannière sur la page **Summary** (Résumé) d'un rôle indique aussi que le rôle est lié à un service.

Si le service ne contient pas de documentation pour supprimer le rôle lié au service, vous pouvez utiliser la console IAM ou l'API pour supprimer le rôle. AWS CLI

## Suppression d'un rôle IAM (console)
<a name="roles-managingrole-deleting-console"></a>

Lorsque vous utilisez le AWS Management Console pour supprimer un rôle, IAM détache automatiquement les politiques gérées associées au rôle. Il supprime aussi automatiquement toute politique en ligne associée au rôle, ainsi que tout profil d'instance Amazon EC2 qui contient le rôle. 

**Important**  
Dans certains cas, un rôle peut être associé à un profil d'instance Amazon EC2, et le rôle et le profil d'instance peuvent porter exactement le même nom. Dans ce cas, vous pouvez utiliser le AWS Management Console pour supprimer le rôle et le profil d'instance. Ce lient se fait automatiquement pour les rôles et les profils d'instance que vous créez dans la console. Si vous avez créé le rôle à partir des outils pour Windows PowerShell ou de l' AWS API, le rôle et le profil d'instance peuvent porter des noms différents. AWS CLI Dans ce cas, vous ne pouvez pas utiliser la console pour les supprimer. Vous devez plutôt utiliser les AWS CLI outils pour Windows PowerShell ou l' AWS API pour supprimer d'abord le rôle du profil d'instance. Vous devez ensuite réaliser une étape distincte pour supprimer le rôle.

**Pour supprimer un rôle (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, choisissez **Rôles**, puis cochez la case en regard du rôle à supprimer. 

1. En haut de la page, sélectionnez **Delete** (Supprimer).

1. Dans la boîte de dialogue de confirmation, passez en revue les dernières informations consultées, qui indiquent la date à laquelle chacun des rôles sélectionnés a accédé pour la dernière fois à un AWS service. Cela vous permet de confirmer si le rôle est actif actuellement. Pour poursuivre, saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete (Supprimer)**. Si vous êtes sûr, procédez à la suppression même si les dernières informations consultées sont toujours en cours de chargement.

**Note**  
Vous ne pouvez pas utiliser la console pour supprimer un profil d'instance, sauf lorsqu'elle porte le même nom que le rôle. Le profil d'instance est supprimé dans le cadre du processus de suppression d'un rôle comme décrit dans la procédure précédente. Pour supprimer un profil d'instance sans supprimer également le rôle, vous devez utiliser l' AWS API AWS CLI or. Pour plus d’informations, consultez les sections suivantes.

## Suppression d'un rôle IAM (AWS CLI)
<a name="roles-managingrole-deleting-cli"></a>

Lorsque vous utilisez le AWS CLI pour supprimer un rôle, vous devez d'abord supprimer les politiques intégrées associées au rôle. Vous devez également détacher les politiques gérées associées au rôle. Si vous voulez supprimer le profil d'instance associé contenant le rôle, vous devez le supprimer séparément.

**Pour supprimer un rôle (AWS CLI)**

1. Si vous ne connaissez pas le nom du rôle que vous souhaitez supprimer, tapez la commande suivante pour répertorier les rôles dans votre compte :

   ```
   aws iam list-roles
   ```

   La liste inclut l'Amazon Resource Name (ARN) de chaque rôle. Utilisez le nom du rôle, pas l'ARN, pour faire référence aux rôles avec les commandes CLI. Par exemple, si un rôle a l'ARN : `arn:aws:iam::123456789012:role/myrole`, vous faites référence au rôle en tant que **myrole**.

1. Supprimez le rôle de tous les profils d'instance auxquels il est associé.

   1. Pour répertorier tous les profils d'instance auxquels un rôle est associé, tapez la commande suivante :

      ```
      aws iam list-instance-profiles-for-role --role-name role-name
      ```

   1. Pour supprimer le rôle d'un profil d'instance, saisissez la commande suivante pour chaque profil instance :

      ```
      aws iam remove-role-from-instance-profile --instance-profile-name instance-profile-name --role-name role-name
      ```

1. Supprimez toutes les politiques associées au rôle.

   1. Pour répertorier toutes les politiques en ligne que contient le rôle, saisissez la commande suivante :

      ```
      aws iam list-role-policies --role-name role-name
      ```

   1. Pour supprimer chaque politique en ligne du rôle, saisissez la commande suivante pour chaque politique : 

      ```
      aws iam delete-role-policy --role-name role-name --policy-name policy-name
      ```

   1. Pour répertorier toutes les politiques gérées attachées au rôle, saisissez la commande suivante :

      ```
      aws iam list-attached-role-policies --role-name role-name
      ```

   1. Pour détacher chaque politique gérée du rôle, saisissez la commande suivante pour chaque politique : 

      ```
      aws iam detach-role-policy --role-name role-name --policy-arn policy-arn
      ```

1. Tapez la commande suivante pour supprimer le rôle :

   ```
   aws iam delete-role --role-name role-name
   ```

1. Si vous ne prévoyez pas de réutiliser les profils d'instance associés au rôle, vous pouvez saisir la commande suivante pour les supprimer :

   ```
   aws iam delete-instance-profile --instance-profile-name instance-profile-name
   ```

## Supprimer un rôle IAM (AWS API)
<a name="roles-managingrole-deleting-api"></a>

Lorsque vous utilisez l'API IAM pour supprimer un rôle, vous devez d'abord supprimer les politiques en ligne associées au rôle. Vous devez également détacher les politiques gérées associées au rôle. Si vous voulez supprimer le profil d'instance associé contenant le rôle, vous devez le supprimer séparément.

**Pour supprimer un rôle (AWS API)**

1. Pour répertorier tous les profils d'instance auxquels un rôle est associé, appelez [ListInstanceProfilesForRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html).

   Pour supprimer le rôle d'un profil d'instance, appelez [RemoveRoleFromInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html). Vous devez transmettre le nom du rôle et le nom du profil d'instance. 

   Si vous ne comptez pas réutiliser un profil d'instance associé au rôle, appelez [DeleteInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html)pour le supprimer.

1. Pour répertorier toutes les politiques intégrées à un rôle, appelez [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html).

   Pour supprimer les politiques intégrées associées au rôle, appelez [DeleteRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRolePolicy.html). Vous devez transmettre le nom du rôle et le nom de la politique en ligne. 

1. Pour répertorier toutes les politiques gérées associées à un rôle, appelez [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html). 

   Pour détacher les politiques gérées associées au rôle, appelez [DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html). Vous devez transmettre le nom du rôle et l'ARN de la politique gérée. 

1. Appelez [DeleteRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRole.html)pour supprimer le rôle.

## Informations connexes
<a name="roles-managingrole-deleting-related-info"></a>

Pour obtenir des informations générales sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md).

Pour obtenir des informations générales sur les rôles liés à un service, veuillez consulter [Créer un rôle lié à un service](id_roles_create-service-linked-role.md).

# Méthodes pour assumer un rôle
<a name="id_roles_manage-assume"></a>

Avant qu’un utilisateur, une application ou un service soit en mesure d’utiliser un rôle que vous avez créé, vous devez lui [accorder les autorisations nécessaires pour changer](id_roles_use_permissions-to-switch.md) de rôle. Pour accorder ces autorisations, vous pouvez utiliser n’importe quelle politique attachée à l’un des groupes ou des utilisateurs. Une fois les autorisations accordées, l'utilisateur peut assumer un rôle dans les outils pour Windows PowerShell, le AWS Command Line Interface (AWS CLI) et l'[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API. AWS Management Console

**Important**  
Si vous créez un rôle par programmation plutôt que dans la console IAM, vous avez la possibilité d'ajouter un chemin `Path` de 512 caractères au maximum à l'élément `RoleName` qui lui, est de 64 caractères au maximum. Toutefois, si vous avez l'intention d'utiliser un rôle avec la fonctionnalité **Switch** Role dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères.

La méthode utilisée pour endosser le rôle détermine qui peut endosser le rôle et la durée de la session de rôle. Lorsque vous l'utilisez `AssumeRole*` les opérations d'API, le rôle IAM que vous endossez est la ressource. Le rôle ou l'utilisateur IAM qui appelle les opérations de l'API `AssumeRole*` est le principal.

Le tableau suivant compare les méthodes pour endosser des rôles.


|  Méthode permettant d'endosser le rôle |  **Qui peut endosser le rôle**  | **Méthode permettant de spécifier la durée de vie des informations d'identification** |  **Durée de vie des informations d'identification (min \$1 max \$1 par défaut)**  | 
| --- | --- | --- | --- | 
| AWS Management Console | Utilisateur ou rôles¹ (en [changeant de rôle](id_roles_use_switch-role-console.md)) | Durée de session maximale sur la page récapitulative des rôles | 15 min \$1 Durée de session maximale² \$1 1 h | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) |  Utilisateur ou rôle¹ | Paramètre de CLI duration-seconds ou d'API DurationSeconds | 15 min \$1 Durée de session maximale² \$1 1 h  | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Tout utilisateur authentifié utilisant SAML | Paramètre de CLI duration-seconds ou d'API DurationSeconds | 15 min \$1 Durée de session maximale² \$1 1 h  | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Tout utilisateur authentifié à l’aide d’un fournisseur OIDC | Paramètre de CLI duration-seconds ou d'API DurationSeconds | 15 min \$1 Durée de session maximale² \$1 1 h  | 
| [URL de console](id_roles_providers_enable-console-custom-url.md) construite avec AssumeRole  | Utilisateur ou rôle | Paramètre HTML SessionDuration dans l'URL | 15 min \$1 12 h \$1 1 h  | 
| [URL de console](id_roles_providers_enable-console-custom-url.md) construite avec AssumeRoleWithSAML  | Tout utilisateur authentifié utilisant SAML | Paramètre HTML SessionDuration dans l'URL | 15 min \$1 12 h \$1 1 h | 
| [URL de console](id_roles_providers_enable-console-custom-url.md) construite avec AssumeRoleWithWebIdentity  | Tout utilisateur authentifié à l’aide d’un fournisseur OIDC | Paramètre HTML SessionDuration dans l'URL | 15 min \$1 12 h \$1 1 h  | 

¹ L’utilisation des informations d’identification pour qu’un rôle endosse un rôle différent est appelée [création de chaînes de rôles](id_roles.md#iam-term-role-chaining). Lorsque vous utilisez la création de chaînes de rôles, la durée de session du rôle est limitée à une heure. Cela s'applique au changement de AWS Management Console rôle et aux opérations d'API. AWS CLI Cette limitation ne s'applique pas à l'attribution initiale d'un rôle à partir des informations d'identification de l'utilisateur, ni aux applications exécutées sur des EC2 instances Amazon à l'aide de profils d'instance.

² La valeur de ce paramètre peut varier de 1 heure à 12 heures. Pour en savoir plus sur la modification du paramètre de durée de session maximale, consultez [Gestion des rôles IAM](id_roles_manage.md). Ce paramètre détermine la durée de session maximale que vous pouvez demander lorsque vous obtenez les informations d'identification du rôle. Par exemple, lorsque vous utilisez les opérations d'API [AssumeRole\$1](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) pour assumer un rôle, vous pouvez spécifier une durée de session à l'aide du `DurationSeconds` paramètre. Utilisez ce paramètre pour spécifier la durée de la session du rôle entre 900 secondes (15 minutes) et la durée de session maximale pour le rôle. Les utilisateurs IAM qui changent de rôle dans la console se voient accorder la durée de session maximale ou le temps restant dans la session de l'utilisateur, selon la durée la plus courte. Supposons que vous définissiez une durée maximale de 5 heures sur un rôle. Un utilisateur IAM qui s'est connecté à la console pendant 10 heures (sur 12, le maximum par défaut) décide d'endosser le rôle. La durée de la session de rôle disponible est de 2 heures. Pour savoir comment afficher la valeur maximale pour votre rôle, consultez [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration) plus loin sur cette page.

**Remarques**  
Le paramètre de durée maximale de session ne limite pas les sessions endossées par les services AWS .
Les informations d'identification du rôle Amazon EC2 IAM ne sont pas soumises à la durée de session maximale configurée dans le rôle.
Pour permettre aux utilisateurs d'assumer à nouveau le rôle actuel au cours d'une session de rôle, spécifiez l'ARN ou l' Compte AWS ARN comme principal dans la politique de confiance des rôles. Services AWS qui fournissent des ressources de calcul telles qu'Amazon EC2, Amazon ECS, Amazon EKS et Lambda fournissent des informations d'identification temporaires et mettent automatiquement à jour ces informations d'identification. Cela garantit que vous disposez toujours d'un ensemble d'informations d'identification valide. Pour ces services, il n'est pas nécessaire d'endosser à nouveau le rôle actuel pour obtenir des informations d'identification temporaires. Toutefois, si vous avez l'intention de transférer des [balises de session](id_session-tags.md) ou une [politique de session](access_policies.md#policies_session), vous devez endosser à nouveau le rôle actuel. Pour savoir comment modifier une politique d'approbation des rôles afin d'ajouter l'ARN ou Compte AWS l'ARN du rôle principal, consultez[Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md).

**Topics**
+ [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md)
+ [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md)
+ [Basculer vers un rôle IAM (Outils pour Windows PowerShell)](id_roles_use_switch-role-twp.md)
+ [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md)
+ [Utilisation d’un rôle IAM pour accorder des autorisations à des applications s’exécutant sur des instances Amazon EC2](id_roles_use_switch-role-ec2.md)
+ [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md)

# Basculer d’un utilisateur à un rôle IAM (console)
<a name="id_roles_use_switch-role-console"></a>

Vous pouvez basculer d'un rôle à l'autre lorsque vous vous connectez en tant qu'utilisateur IAM, utilisateur de IAM Identity Center, rôle fédéré SAML ou rôle fédéré d'identité Web. Un *rôle* définit un ensemble d'autorisations que vous pouvez utiliser pour accéder aux AWS ressources dont vous avez besoin. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté en tant qu’utilisateur IAM, vous pouvez passer à un rôle IAM. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md).

Les autorisations de votre utilisateur et des rôles que vous assumez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement vos autorisations utilisateur et travaillez avec celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées.

Lorsque vous changez de rôle dans le AWS Management Console, la console utilise toujours vos informations d'identification d'origine pour autoriser le changement. Par exemple, si vous basculez sur RoleA, IAM utilise vos informations d’identification d’origine pour déterminer si vous êtes autorisé à endosser le rôle RoleA. Si vous passez ensuite à RoleB alors *que vous utilisez RoleA, utilisez* toujours **vos** informations d'identification d'origine pour autoriser le changement AWS , et non les informations d'identification pour RoleA.

**Note**  
Lorsque vous vous connectez en tant qu’utilisateur dans IAM Identity Center, en tant que rôle fédéré par SAML ou en tant que rôle fédéré par identité Web, vous endossez un rôle IAM lorsque vous démarrez votre session. Par exemple, lorsqu'un utilisateur d'IAM Identity Center se connecte au portail AWS d'accès, il doit choisir un ensemble d'autorisations correspondant à un rôle avant de pouvoir accéder aux AWS ressources.

## Séances de rôle
<a name="id_roles_iam_user-switch-role-sessions"></a>

Lorsque vous changez de rôle, votre AWS Management Console session dure 1 heure par défaut. Les sessions des utilisateurs IAM ont une durée de 12 heures par défaut, d’autres utilisateurs peuvent avoir des durées de session différentes. Lorsque vous changez de rôle dans la console, la durée maximale de la session du rôle ou la durée restante de votre session d’utilisateur vous est accordée, selon la durée la plus courte. Vous ne pouvez pas prolonger la durée de votre session en endossant un rôle.

Par exemple, supposons qu'une durée de session maximale de 10 heures soit définie pour un rôle. Vous êtes connecté à la console depuis huit heures lorsque vous décidez d’endosser le rôle. Il reste quatre heures dans votre session utilisateur IAM, de sorte que la durée autorisée de la session du rôle est de quatre heures, et non la durée maximale de la session de dix heures. Le tableau suivant montre comment déterminer la durée de session d'un utilisateur IAM lorsqu'il change de rôle dans la console.


| Le temps restant de la session de l'utilisateur IAM est... | La durée de la session de rôle est… | 
| --- | --- | 
| Moins que la durée de session maximale d'un rôle | Temps restant dans la session de l'utilisateur IAM | 
| Plus que la durée de session maximale du rôle | Valeur de durée de session maximale | 
| Égale à la durée de session maximale du rôle | Valeur de durée de session maximale (approximative) | 

L’utilisation des informations d’identification pour qu’un rôle endosse un rôle différent est appelée [création de chaînes de rôles](id_roles.md#iam-term-role-chaining). Lorsque vous utilisez le chaînage des rôles, la durée de la session est limitée à une heure, quel que soit le paramètre de durée maximale de session configuré pour chaque rôle. Cela s'applique au changement de AWS Management Console rôle et aux opérations d'API. AWS CLI

**Note**  
Certaines consoles AWS de service peuvent renouveler automatiquement votre session de rôle lorsqu'elle expire sans que vous n'ayez à effectuer aucune action. Certaines peuvent vous inviter à recharger la page de votre navigateur pour réauthentifier votre session.

## Considérations
<a name="id_roles_iam_user-switch-role-considerations"></a>
+ Vous ne pouvez pas changer de rôle si vous vous connectez en tant que Utilisateur racine d'un compte AWS. 
+ Les utilisateurs doivent être autorisés à changer de rôle conformément à la politique. Pour obtenir des instructions, veuillez consulter [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md).
+ Vous ne pouvez pas changer de rôle dans le rôle AWS Management Console pour un rôle qui nécessite une [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)valeur. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) qui prend en charge le paramètre `ExternalId`.

## Pour changer de rôle
<a name="id_roles_iam_user-switch-role-console-procedure"></a>

1. Suivez la procédure de connexion correspondant à votre type d’utilisateur, comme décrit dans la rubrique [Connexion à AWS Management Console](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l’utilisateur Connexion à AWS *.

1. Dans le AWS Management Console, choisissez votre nom d'utilisateur dans la barre de navigation en haut à droite. Cela ressemble généralement à ceci : ***username*@ *account\$1ID\$1number\$1or\$1alias***.

1. Choisissez l’une des méthodes suivantes pour changer de rôle :
   + Choisissez **Changer de rôle**.
   + Si vous avez opté pour la prise en charge multi-session, choisissez **Ajouter une session** et sélectionnez **Changer de rôle**.
**Note**  
Vous pouvez vous connecter à un maximum de cinq identités différentes simultanément dans un seul navigateur Web dans l’ AWS Management Console. Pour plus de détails, consultez la section [Connexion à plusieurs comptes](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html) dans le *Guide de démarrage AWS Management Console *.

1. Dans la page **Switch Role (Changer de rôle)**, entrez l'ID ou l'alias de compte, ainsi que le nom du rôle que vous a fourni l'administrateur.
**Note**  
Si l'administrateur a créé le rôle avec un chemin d'accès tel que `division_abc/subdivision_efg/roleToDoX`, vous devez entrer le chemin d'accès complet et le nom dans le champ **Rôle**. Si vous entrez uniquement le nom du rôle, ou si l'ensemble de `Path` et `RoleName` dépasse 64 caractères, le changement de rôle échoue. Cette restriction est imposée par les cookies du navigateur dans lesquels est stocké le nom du rôle. Dans ce cas, contactez votre administrateur et demandez-lui de réduire la taille du chemin d'accès et le nom du rôle.

1. (Facultatif) Vous pouvez saisir un nom d’affichage et sélectionner une couleur d’affichage qui mettra en évidence le rôle dans la barre de navigation de la console.
   + Pour **Nom d’affichage**, saisissez le texte que vous voulez afficher sur la barre de navigation à la place de votre nom utilisateur lorsque le rôle est actif. Un nom, basé sur les informations du compte et du rôle, est suggéré, mais vous pouvez le modifier à votre convenance. 
   + Pour **Couleur d’affichage**, sélectionnez une couleur pour mettre en évidence le nom d’affichage.

   Le nom et la couleur peuvent vous aider à savoir quand le rôle est actif, ce qui modifie vos autorisations. Par exemple, pour un rôle qui vous donne accès à l'environnement de test, vous pouvez spécifier un **Display name** (Nom d'affichage) de **Test** et sélectionner la couleur verte pour **Color**. Pour le rôle qui vous donne accès à la production, vous pouvez spécifier un **Display name** (Nom d'affichage) de **Production** et sélectionner la couleur rouge pour **Color**.

1. Choisissez **Changer de rôle**. Le nom d'affichage et la couleur remplacent votre nom utilisateur sur la barre de navigation et vous pouvez commencer à utiliser les autorisations que le rôle vous accorde.

1. Une fois que vous avez terminé les tâches nécessitant le rôle IAM, vous pouvez revenir à votre session d’origine. Cela supprimera les autorisations supplémentaires fournies par le rôle et vous ramènera à vos autorisations standard.

   1. Dans la console IAM, choisissez le nom d'affichage du rôle sous **Display Name (Nom d'affichage)** en haut à droite de la barre de navigation. 

   1. Choisissez **Revenir**.

      Par exemple, supposons que vous êtes connecté au numéro de compte `123456789012` à l'aide du nom d'utilisateur `Richard`. Une fois que vous avez utilisé le rôle `admin-role`, vous souhaitez cesser d'utiliser ce rôle et revenir à vos autorisations initiales. Pour arrêter d’utiliser le rôle, sélectionnez **admin-role @ 123456789012**, puis choisissez **Switch back.**  
![\[Graphique indiquant la fonction Revenir permettant d’arrêter d’utiliser un rôle IAM et de revenir à l’utilisateur d’origine.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/role-stop-using.png)

**Astuce**  
Les derniers rôles utilisés sont répertoriés dans le menu . La prochaine fois que vous voulez endosser l’un de ces rôles, choisissez simplement le rôle souhaité. Il vous suffit de saisir manuellement les informations sur le compte et le rôle si le rôle n’est pas affiché dans le menu.

## Ressources supplémentaires
<a name="id_roles_use_switch-role-console_additional_resources"></a>
+ [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md)
+ [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](id_roles_use_passrole.md)
+ [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md)
+ [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md)
+ [Résolution des problèmes liés aux rôles IAM](troubleshoot_roles.md)

# Basculer vers un rôle IAM (AWS CLI)
<a name="id_roles_use_switch-role-cli"></a>

Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS dont vous avez besoin. À cet égard, il est semblable à un [utilisateur IAM Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Lorsque vous vous connectez en tant qu'utilisateur, un ensemble spécifique d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté en tant qu'utilisateur, vous pouvez passer à un rôle. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). Pour connaître les différentes méthodes que vous pouvez utiliser pour endosser un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md).

**Important**  
Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement les autorisations utilisateur et de rôle précédentes et utilisez celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées.

Vous pouvez utiliser un rôle pour exécuter une AWS CLI commande lorsque vous êtes connecté en tant qu'utilisateur IAM. Vous pouvez également utiliser un rôle pour exécuter une AWS CLI commande lorsque vous êtes connecté en tant qu'[utilisateur authentifié de manière externe](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) ou [OIDC](id_roles_providers_oidc.md)) qui utilise déjà un rôle. De plus, vous pouvez utiliser un rôle pour exécuter une commande de la AWS CLI dans une instance Amazon EC2 attachée à un rôle via son profil d'instance. Il n'est pas possible d'assumer un rôle si vous êtes connecté en tant qu' Utilisateur racine d'un compte AWS.

[**Chaînage de rôles**](id_roles.md#iam-term-role-chaining) : vous pouvez aussi utiliser le chaînage de rôles, qui utilise les autorisations d'un rôle pour accéder à un second rôle.

Par défaut, votre session de rôle dure une heure. Lorsque vous endossez ce rôle à l'aide des opérations de la CLI `assume-role*`, vous pouvez spécifier une valeur pour le paramètre `duration-seconds`. Cette valeur peut être comprise entre 900 secondes (15 minutes) et la valeur de durée de session maximale définie pour le rôle. Si vous changez de rôle dans la console, la durée de votre session est limitée à une heure. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration). 

Si vous utilisez la création de chaînes de rôles, la durée de votre session est limitée à une heure maximum. Si vous utilisez ensuite le paramètre `duration-seconds` pour fournir une valeur supérieure à une heure, l'opération échoue.

## Exemple de scénario : passer à un rôle de production
<a name="switch-role-cli-scenario-prod-env"></a>

Imaginez que vous êtes un utilisateur IAM pour travailler dans l'environnement de développement. Dans ce scénario, vous devez parfois travailler avec l'environnement de production au niveau de la ligne de commande avec l'[AWS CLI](https://aws.amazon.com/cli/). Vous disposez déjà d'un ensemble d'informations d'identification de clé d'accès. Il peut s'agir de la paire de clés d'accès attribuée à votre utilisateur IAM standard. Ou, si vous êtes connecté en tant que principal fédéré SAML ou OIDC, il peut s’agir de la paire de clés d’accès pour le rôle qui vous a été attribué initialement. Si vos autorisations actuelles vous permettent d'assumer un rôle IAM spécifique, vous pouvez identifier ce rôle dans un « profil » des fichiers de AWS CLI configuration. Cette commande est ensuite exécutée avec les autorisations du rôle IAM spécifié, pas l'identité d'origine. Notez que lorsque vous spécifiez ce profil dans une AWS CLI commande, vous utilisez le nouveau rôle. Dans ce cas, vous ne pouvez pas utiliser vos autorisations d'origine dans le compte de développement en même temps. Ceci est dû au fait qu'un seul ensemble d'autorisations peut être actif à la fois.

**Note**  
Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname).

**Pour passer à un rôle de production (AWS CLI)**

1. <a name="step-configure-default"></a>Si vous n'avez jamais utilisé le AWS CLI, vous devez d'abord configurer votre profil CLI par défaut. Ouvrez une invite de commande et configurez votre AWS CLI installation pour utiliser la clé d'accès de votre utilisateur IAM ou de votre rôle fédéré. Pour plus d'informations, veuillez consulter [configuration de l'outil AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) dans le *guide de l'utilisateur de l'outil AWS Command Line Interface *.

   Exécutez la commande [aws configure](https://docs.aws.amazon.com/cli/latest/reference/configure/) comme suit :

   ```
   aws configure
   ```

   Lorsque vous y êtes invité, fournissez les informations suivantes :

   ```
   AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
   AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   Default region name [None]: us-east-2
   Default output format [None]: json
   ```

1. Créez un profil pour le rôle dans le `.aws/config` fichier Unix ou Linux, ou le fichier `C:\Users\USERNAME\.aws\config` dans Windows. L'exemple suivant crée un profil appelé `prodaccess` qui passe au rôle `ProductionAccessRole` dans le compte `123456789012`. Vous obtenez l'ARN du rôle auprès de l'administrateur du compte ayant créé le rôle. Lorsque ce profil est invoqué, il AWS CLI utilise les informations d'identification du `source_profile` pour demander les informations d'identification du rôle. De ce fait, l'identité référencée en tant que `source_profile` doit disposer des autorisations `sts:AssumeRole` pour le rôle spécifié dans le `role_arn`.

   ```
   [profile prodaccess]
       role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
       source_profile = default
   ```

1. Après avoir créé le nouveau profil, toute AWS CLI commande spécifiant le paramètre est `--profile prodaccess` exécutée sous les autorisations associées au rôle IAM `ProductionAccessRole` plutôt que sous celles de l'utilisateur par défaut.

   ```
   aws iam list-users --profile prodaccess
   ```

   Cette commande fonctionne si les autorisations affectées au rôle `ProductionAccessRole` permettent de répertorier les utilisateurs dans le compte AWS actuel.

1. Pour revenir aux autorisations accordées par vos informations d'identification d'origine, exécutez les commandes sans le paramètre `--profile`. Vous AWS CLI recommencez à utiliser les informations d'identification de votre profil par défaut, que vous avez configuré dans[Step 1](#step-configure-default).

Pour plus d'informations, consultez [Endossement d'un rôle](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) dans le *Guide de l'utilisateur AWS Command Line Interface *.

## Exemple de scénario : permettre à un rôle de profil d'instance de passer à un rôle dans un autre compte
<a name="switch-role-cli-scenario-ec2-instance"></a>

Imaginez que vous en utilisiez deux Comptes AWS et que vous souhaitiez autoriser une application exécutée sur une instance Amazon EC2 à exécuter des [AWS CLI](https://aws.amazon.com/cli/)commandes dans les deux comptes. Supposons que l'instance EC2 existe dans le compte `111111111111`. Cette instance inclut le rôle de profil d'instance `abcd` qui permet à l'appli d'effectuer les tâches Amazon S3 `amzn-s3-demo-bucket1` en lecture seule sur le compartiment dans le même compte `111111111111`. Toutefois, l'application doit également être autorisée à endosser le rôle `efgh` entre comptes pour effectuer des tâches dans le compte `222222222222`. Pour ce faire, le rôle de profil d'instance EC2 `abcd` doit disposer des autorisations suivantes :

***Politique d'autorisations de rôle `abcd` du compte 111111111111***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

Supposons que le rôle `efgh` entre comptes permet aux tâches Amazon S3 en lecture seule sur le compartiment `amzn-s3-demo-bucket2` dans le même compte `222222222222`. Pour ce faire, le rôle `efgh` entre comptes doit avoir la politique d'autorisations suivante :

***Politique d'autorisations de rôle `efgh` du compte 222222222222***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

Le rôle `efgh` doit autoriser le rôle de profil d'instance `abcd` à l'endosser. Pour ce faire, le rôle `efgh` doit avoir la politique de confiance suivante :

***Politique de confiance de rôle `efgh` du compte 222222222222***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

Pour exécuter ensuite AWS CLI les commandes dans le compte`222222222222`, vous devez mettre à jour le fichier de configuration de la CLI. Identifiez le rôle `efgh` en tant que « profil » et le rôle de profil d'instance EC2 `abcd` en tant que « source » d'informations d'identification dans le fichier de configuration d' AWS CLI . Ensuite, vos commandes de CLI sont exécutées avec les autorisations du rôle `efgh`, pas du rôle `abcd` d'origine.

**Note**  
Pour des raisons de sécurité, vous pouvez AWS CloudTrail vérifier l'utilisation des rôles dans le compte. Pour différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux dans les CloudTrail journaux, vous pouvez utiliser le nom de session du rôle. Lorsque le AWS CLI assume un rôle au nom d'un utilisateur tel que décrit dans cette rubrique, un nom de session de rôle est automatiquement créé sous le nom de`AWS-CLI-session-nnnnnnnn`. *nnnnnnnn*Voici un entier qui représente l'heure en temps d'[époque Unix](http://wikipedia.org/wiki/Unix_time) (le nombre de secondes écoulées depuis minuit UTC le 1er janvier 1970). Pour plus d'informations, consultez la section [Référence aux CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) dans le *guide de AWS CloudTrail l'utilisateur*.

**Pour autoriser un rôle de profil d'instance EC2 afin de passer à un rôle entre comptes (AWS CLI)**

1. Vous n'avez pas besoin de configurer un profil par défaut pour la CLI. Au lieu de cela, vous pouvez charger les informations d'identification à partir des métadonnées du profil d'instance EC2. Créez un profil pour le rôle dans le fichier `.aws/config`. L'exemple suivant crée un profil `instancecrossaccount` qui passe au rôle `efgh` dans le compte `222222222222`. Lorsque ce profil est appelé, l’interface AWS CLI utilise les informations d'identification des métadonnées du profil d'instance EC2 pour demander les informations d'identification du rôle. De ce fait, le rôle de profil d'instance EC2 doit disposer des autorisations `sts:AssumeRole` pour le rôle spécifié dans le `role_arn`.

   ```
   [profile instancecrossaccount]
   role_arn = arn:aws:iam::222222222222:role/efgh
   credential_source = Ec2InstanceMetadata
   ```

1. Après avoir créé le nouveau profil, toute AWS CLI commande spécifiant le paramètre `--profile instancecrossaccount` s'exécute sous les autorisations associées au `efgh` rôle dans le compte`222222222222`.

   ```
   aws s3 ls amzn-s3-demo-bucket2 --profile instancecrossaccount
   ```

   Cette commande fonctionne si les autorisations affectées au rôle `efgh` autorisent à répertorier les utilisateurs dans l' Compte AWS actuel.

1. Pour revenir au profil d'instance EC2 d'origine les autorisations de compte `111111111111`, exécutez les commandes de CLI sans le paramètre `--profile`.

Pour plus d'informations, consultez [Endossement d'un rôle](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) dans le *Guide de l'utilisateur AWS Command Line Interface *.

# Basculer vers un rôle IAM (Outils pour Windows PowerShell)
<a name="id_roles_use_switch-role-twp"></a>

Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS dont vous avez besoin. À cet égard, il est semblable à un [utilisateur IAM Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Lorsque vous vous connectez en tant qu'utilisateur, un ensemble spécifique d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté, vous pouvez endosser un rôle. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md).

**Important**  
Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement vos autorisations utilisateur et travaillez avec celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées.

Cette section décrit comment changer de rôles lorsque vous utilisez la ligne de commande avec AWS Tools for Windows PowerShell.

Imaginez que vous disposez d'un compte dans l'environnement de développement et que vous deviez parfois travailler avec l'environnement de production en ligne de commande à l'aide [des outils pour Windows PowerShell](https://aws.amazon.com/powershell/). Un ensemble d'informations d'identification de clé d'accès est déjà à votre disposition. Il peut s'agir de la paire de clés d'accès attribuée à votre utilisateur IAM standard. Ou, si vous êtes connecté en tant que principal fédéré SAML ou OIDC, il peut s’agir de la paire de clés d’accès pour le rôle qui vous a été attribué initialement. Ces informations d'identification vous permettent d'exécuter le cmdlet `Use-STSRole` qui transmet l'ARN d'un nouveau rôle en tant que paramètre. Cette commande renvoie es informations d'identification de sécurité temporaires du rôle demandé. Vous pouvez ensuite utiliser ces informations d'identification dans PowerShell les commandes suivantes avec les autorisations du rôle pour accéder aux ressources en production. Bien que vous utilisiez ce rôle, vous ne pouvez pas utiliser vos autorisations d'utilisateur dans le compte Développement, car un seul ensemble d'autorisations est en vigueur à la fois.

**Note**  
Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname).

Notez que toutes les clés d'accès et tous les jetons sont des exemples uniquement et ne peuvent pas être utilisés comme indiqué. Remplacez-les par les valeurs correspondantes de votre environnement en direct.

**Pour passer à un rôle (Outils pour Windows PowerShell)**

1. Ouvrez une invite de PowerShell commande et configurez le profil par défaut pour utiliser la clé d'accès de votre utilisateur IAM actuel ou de votre rôle fédéré. Si vous avez déjà utilisé les outils pour Windows PowerShell, cela est probablement déjà fait. Notez que vous ne pouvez changer de rôle que si vous êtes connecté en tant qu'utilisateur IAM, et non en tant que Utilisateur racine d'un compte AWS.

   ```
   PS C:\> Set-AWSCredentials -AccessKey AKIAIOSFODNN7EXAMPLE -SecretKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -StoreAs MyMainUserProfile
   PS C:\> Initialize-AWSDefaults -ProfileName MyMainUserProfile -Region us-east-2
   ```

   Pour plus d'informations, consultez la section [Utilisation des AWS informations d'identification](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html) dans le *guide de Outils AWS pour PowerShell l'utilisateur*.

1. Pour récupérer les informations d'identification du nouveau rôle, exécutez la commande suivante pour passer au rôle `RoleName` dans le compte 123456789012. Vous obtenez l'ARN du rôle auprès de l'administrateur du compte ayant créé le rôle. La commande nécessite que vous fournissiez un nom de session également. Pour cela, n'importe quel texte fera l'affaire. La commande suivante demande les informations d'identification et capture l'objet de propriété `Credentials` dans l'objet des résultats renvoyés et le stocke dans la variable `$Creds`.

   ```
   PS C:\> $Creds = (Use-STSRole -RoleArn "arn:aws:iam::123456789012:role/RoleName" -RoleSessionName "MyRoleSessionName").Credentials
   ```

   `$Creds` est un objet qui contient à présent les éléments `AccessKeyId`, `SecretAccessKey` et `SessionToken` dont vous avez besoin dans la procédure suivante. Les exemples de commandes suivants illustrent les valeurs habituelles.

   ```
   PS C:\> $Creds.AccessKeyId
   AKIAIOSFODNN7EXAMPLE
   
   PS C:\> $Creds.SecretAccessKey
   wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   
   PS C:\> $Creds.SessionToken
   AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvSRyh0FW7jEXAMPLEW+vE/7s1HRp
   XviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPy
   Oj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UuysgsKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/C
   s8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87eNhyDHq6ikBQ==
   
   PS C:\> $Creds.Expiration
   Thursday, June 18, 2018 2:28:31 PM
   ```

1. Pour utiliser ces informations d'identification dans n'importe quelle commande suivante, incluez-les dans le paramètre `-Credential`. Par exemple, la commande suivante utilise les informations d'identification du rôle et fonctionne uniquement si le rôle a l'autorisation `iam:ListRoles` et peut donc exécuter le cmdlet `Get-IAMRoles` :

   ```
           PS C:\> get-iamroles -Credential $Creds
   ```

1. Pour revenir à vos informations d'identification d'origine, arrêtez simplement d'utiliser le `-Credentials $Creds` paramètre et PowerShell autorisez le retour aux informations d'identification stockées dans le profil par défaut.

# Basculer vers un rôle IAM (AWS API)
<a name="id_roles_use_switch-role-api"></a>

Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS . À cet égard, il est semblable à un [utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Un principal (personne ou application) assume le rôle de recevoir des autorisations temporaires pour effectuer les tâches requises et interagir avec les AWS ressources. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). Pour connaître les différentes méthodes que vous pouvez utiliser pour endosser un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md).

**Important**  
Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement les autorisations utilisateur et de rôle précédentes et utilisez celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations originales sont automatiquement restaurées.

Pour assumer un rôle, une application appelle l'opération AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API et transmet l'ARN du rôle à utiliser. L'opération crée une nouvelle session avec des informations d'identification temporaires. Cette session possède les mêmes autorisations que les politiques basées sur une identité pour ce rôle. 

Lorsque vous appelez [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html), vous pouvez, si vous le souhaitez, transmettre des [politiques de session](access_policies.md#policies_session) en ligne ou gérées. Les politiques de session sont des politiques avancées que vous transmettez en tant que paramètre lorsque vous créez par programmation une session d’informations d’identification temporaires pour un rôle ou une session utilisateur fédérée. Vous pouvez transmettre un seul document de politique de session en ligne JSON à l'aide du paramètre `Policy`. Vous pouvez utiliser le paramètre `PolicyArns` pour spécifier jusqu'à 10 politiques de session gérées. Les autorisations de la session obtenues sont une combinaison des stratégies basées sur l'identité de l'entité et des stratégies de session. Les politiques de session s'avèrent utiles lorsque vous devez fournir les informations d'identification temporaires du rôle à une autre personne. Cette dernière peut utiliser les informations d'identification temporaires du rôle dans les appels d'API AWS suivants pour accéder aux ressources du compte qui possède le rôle. Vous ne pouvez pas utiliser les politiques de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité. Pour en savoir plus sur la manière de AWS déterminer les autorisations effectives d'un rôle, consultez[Logique d'évaluation de politiques](reference_policies_evaluation-logic.md). 

![\[PermissionsWhenPassingRoles_Schéma\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)


Vous pouvez appeler `AssumeRole` lorsque vous êtes connecté en tant qu’utilisateur IAM ou en tant qu’[utilisateur authentifié en externe](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) ou [OIDC](id_roles_providers_oidc.md)) utilisant déjà un rôle. Vous pouvez également utiliser la [*création de chaînes de rôles*](id_roles.md#iam-term-role-chaining), qui utilise un rôle pour endosser un deuxième rôle. Il n'est pas possible d'assumer un rôle si vous êtes connecté en tant qu' Utilisateur racine d'un compte AWS.

Par défaut, votre session de rôle dure une heure. Lorsque vous assumez ce rôle à l'aide des opérations d' AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API, vous pouvez spécifier une valeur pour le `DurationSeconds` paramètre. Cette valeur peut être comprise entre 900 secondes (15 minutes) et la valeur de durée de session maximale définie pour le rôle. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration). 

Si vous utilisez la création de chaînes de rôles, votre session est limitée à une durée maximale d'une heure. Si vous utilisez ensuite le paramètre `DurationSeconds` pour fournir une valeur supérieure à une heure, l'opération échoue.

**Note**  
Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname).

Les exemples de code suivants montrent comment créer un utilisateur et assumer un rôle.

**Avertissement**  
Afin d’éviter les risques de sécurité, n’employez pas les utilisateurs IAM pour l’authentification lorsque vous développez des logiciels spécialisés ou lorsque vous travaillez avec des données réelles. Préférez la fédération avec un fournisseur d’identité tel que [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html).
+ Créer un utilisateur sans autorisation.
+ Créer un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3 pour le compte.
+ Ajouter une politique pour permettre à l’utilisateur d’assumer le rôle.
+ Assumez le rôle et répertorier les compartiments S3 à l’aide d’informations d’identification temporaires, puis nettoyez les ressources.

------
#### [ .NET ]

**SDK pour .NET**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/IAM#code-examples). 

```
global using Amazon.IdentityManagement;
global using Amazon.S3;
global using Amazon.SecurityToken;
global using IAMActions;
global using IamScenariosCommon;
global using Microsoft.Extensions.DependencyInjection;
global using Microsoft.Extensions.Hosting;
global using Microsoft.Extensions.Logging;
global using Microsoft.Extensions.Logging.Console;
global using Microsoft.Extensions.Logging.Debug;


namespace IAMActions;

public class IAMWrapper
{
    private readonly IAmazonIdentityManagementService _IAMService;

    /// <summary>
    /// Constructor for the IAMWrapper class.
    /// </summary>
    /// <param name="IAMService">An IAM client object.</param>
    public IAMWrapper(IAmazonIdentityManagementService IAMService)
    {
        _IAMService = IAMService;
    }

    /// <summary>
    /// Attach an IAM policy to a role.
    /// </summary>
    /// <param name="policyArn">The policy to attach.</param>
    /// <param name="roleName">The role that the policy will be attached to.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> AttachRolePolicyAsync(string policyArn, string roleName)
    {
        var response = await _IAMService.AttachRolePolicyAsync(new AttachRolePolicyRequest
        {
            PolicyArn = policyArn,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Create an IAM access key for a user.
    /// </summary>
    /// <param name="userName">The username for which to create the IAM access
    /// key.</param>
    /// <returns>The AccessKey.</returns>
    public async Task<AccessKey> CreateAccessKeyAsync(string userName)
    {
        var response = await _IAMService.CreateAccessKeyAsync(new CreateAccessKeyRequest
        {
            UserName = userName,
        });

        return response.AccessKey;

    }


    /// <summary>
    /// Create an IAM policy.
    /// </summary>
    /// <param name="policyName">The name to give the new IAM policy.</param>
    /// <param name="policyDocument">The policy document for the new policy.</param>
    /// <returns>The new IAM policy object.</returns>
    public async Task<ManagedPolicy> CreatePolicyAsync(string policyName, string policyDocument)
    {
        var response = await _IAMService.CreatePolicyAsync(new CreatePolicyRequest
        {
            PolicyDocument = policyDocument,
            PolicyName = policyName,
        });

        return response.Policy;
    }


    /// <summary>
    /// Create a new IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <param name="rolePolicyDocument">The name of the IAM policy document
    /// for the new role.</param>
    /// <returns>The Amazon Resource Name (ARN) of the role.</returns>
    public async Task<string> CreateRoleAsync(string roleName, string rolePolicyDocument)
    {
        var request = new CreateRoleRequest
        {
            RoleName = roleName,
            AssumeRolePolicyDocument = rolePolicyDocument,
        };

        var response = await _IAMService.CreateRoleAsync(request);
        return response.Role.Arn;
    }


    /// <summary>
    /// Create an IAM service-linked role.
    /// </summary>
    /// <param name="serviceName">The name of the AWS Service.</param>
    /// <param name="description">A description of the IAM service-linked role.</param>
    /// <returns>The IAM role that was created.</returns>
    public async Task<Role> CreateServiceLinkedRoleAsync(string serviceName, string description)
    {
        var request = new CreateServiceLinkedRoleRequest
        {
            AWSServiceName = serviceName,
            Description = description
        };

        var response = await _IAMService.CreateServiceLinkedRoleAsync(request);
        return response.Role;
    }


    /// <summary>
    /// Create an IAM user.
    /// </summary>
    /// <param name="userName">The username for the new IAM user.</param>
    /// <returns>The IAM user that was created.</returns>
    public async Task<User> CreateUserAsync(string userName)
    {
        var response = await _IAMService.CreateUserAsync(new CreateUserRequest { UserName = userName });
        return response.User;
    }


    /// <summary>
    /// Delete an IAM user's access key.
    /// </summary>
    /// <param name="accessKeyId">The Id for the IAM access key.</param>
    /// <param name="userName">The username of the user that owns the IAM
    /// access key.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteAccessKeyAsync(string accessKeyId, string userName)
    {
        var response = await _IAMService.DeleteAccessKeyAsync(new DeleteAccessKeyRequest
        {
            AccessKeyId = accessKeyId,
            UserName = userName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM policy.
    /// </summary>
    /// <param name="policyArn">The Amazon Resource Name (ARN) of the policy to
    /// delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeletePolicyAsync(string policyArn)
    {
        var response = await _IAMService.DeletePolicyAsync(new DeletePolicyRequest { PolicyArn = policyArn });
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteRoleAsync(string roleName)
    {
        var response = await _IAMService.DeleteRoleAsync(new DeleteRoleRequest { RoleName = roleName });
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM role policy.
    /// </summary>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <param name="policyName">The name of the IAM role policy to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteRolePolicyAsync(string roleName, string policyName)
    {
        var response = await _IAMService.DeleteRolePolicyAsync(new DeleteRolePolicyRequest
        {
            PolicyName = policyName,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM user.
    /// </summary>
    /// <param name="userName">The username of the IAM user to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteUserAsync(string userName)
    {
        var response = await _IAMService.DeleteUserAsync(new DeleteUserRequest { UserName = userName });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM user policy.
    /// </summary>
    /// <param name="policyName">The name of the IAM policy to delete.</param>
    /// <param name="userName">The username of the IAM user.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteUserPolicyAsync(string policyName, string userName)
    {
        var response = await _IAMService.DeleteUserPolicyAsync(new DeleteUserPolicyRequest { PolicyName = policyName, UserName = userName });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Detach an IAM policy from an IAM role.
    /// </summary>
    /// <param name="policyArn">The Amazon Resource Name (ARN) of the IAM policy.</param>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DetachRolePolicyAsync(string policyArn, string roleName)
    {
        var response = await _IAMService.DetachRolePolicyAsync(new DetachRolePolicyRequest
        {
            PolicyArn = policyArn,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Gets the IAM password policy for an AWS account.
    /// </summary>
    /// <returns>The PasswordPolicy for the AWS account.</returns>
    public async Task<PasswordPolicy> GetAccountPasswordPolicyAsync()
    {
        var response = await _IAMService.GetAccountPasswordPolicyAsync(new GetAccountPasswordPolicyRequest());
        return response.PasswordPolicy;
    }


    /// <summary>
    /// Get information about an IAM policy.
    /// </summary>
    /// <param name="policyArn">The IAM policy to retrieve information for.</param>
    /// <returns>The IAM policy.</returns>
    public async Task<ManagedPolicy> GetPolicyAsync(string policyArn)
    {

        var response = await _IAMService.GetPolicyAsync(new GetPolicyRequest { PolicyArn = policyArn });
        return response.Policy;
    }


    /// <summary>
    /// Get information about an IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role to retrieve information
    /// for.</param>
    /// <returns>The IAM role that was retrieved.</returns>
    public async Task<Role> GetRoleAsync(string roleName)
    {
        var response = await _IAMService.GetRoleAsync(new GetRoleRequest
        {
            RoleName = roleName,
        });

        return response.Role;
    }


    /// <summary>
    /// Get information about an IAM user.
    /// </summary>
    /// <param name="userName">The username of the user.</param>
    /// <returns>An IAM user object.</returns>
    public async Task<User> GetUserAsync(string userName)
    {
        var response = await _IAMService.GetUserAsync(new GetUserRequest { UserName = userName });
        return response.User;
    }


    /// <summary>
    /// List the IAM role policies that are attached to an IAM role.
    /// </summary>
    /// <param name="roleName">The IAM role to list IAM policies for.</param>
    /// <returns>A list of the IAM policies attached to the IAM role.</returns>
    public async Task<List<AttachedPolicyType>> ListAttachedRolePoliciesAsync(string roleName)
    {
        var attachedPolicies = new List<AttachedPolicyType>();
        var attachedRolePoliciesPaginator = _IAMService.Paginators.ListAttachedRolePolicies(new ListAttachedRolePoliciesRequest { RoleName = roleName });

        await foreach (var response in attachedRolePoliciesPaginator.Responses)
        {
            attachedPolicies.AddRange(response.AttachedPolicies);
        }

        return attachedPolicies;
    }


    /// <summary>
    /// List IAM groups.
    /// </summary>
    /// <returns>A list of IAM groups.</returns>
    public async Task<List<Group>> ListGroupsAsync()
    {
        var groupsPaginator = _IAMService.Paginators.ListGroups(new ListGroupsRequest());
        var groups = new List<Group>();

        await foreach (var response in groupsPaginator.Responses)
        {
            groups.AddRange(response.Groups);
        }

        return groups;
    }


    /// <summary>
    /// List IAM policies.
    /// </summary>
    /// <returns>A list of the IAM policies.</returns>
    public async Task<List<ManagedPolicy>> ListPoliciesAsync()
    {
        var listPoliciesPaginator = _IAMService.Paginators.ListPolicies(new ListPoliciesRequest());
        var policies = new List<ManagedPolicy>();

        await foreach (var response in listPoliciesPaginator.Responses)
        {
            policies.AddRange(response.Policies);
        }

        return policies;
    }


    /// <summary>
    /// List IAM role policies.
    /// </summary>
    /// <param name="roleName">The IAM role for which to list IAM policies.</param>
    /// <returns>A list of IAM policy names.</returns>
    public async Task<List<string>> ListRolePoliciesAsync(string roleName)
    {
        var listRolePoliciesPaginator = _IAMService.Paginators.ListRolePolicies(new ListRolePoliciesRequest { RoleName = roleName });
        var policyNames = new List<string>();

        await foreach (var response in listRolePoliciesPaginator.Responses)
        {
            policyNames.AddRange(response.PolicyNames);
        }

        return policyNames;
    }


    /// <summary>
    /// List IAM roles.
    /// </summary>
    /// <returns>A list of IAM roles.</returns>
    public async Task<List<Role>> ListRolesAsync()
    {
        var listRolesPaginator = _IAMService.Paginators.ListRoles(new ListRolesRequest());
        var roles = new List<Role>();

        await foreach (var response in listRolesPaginator.Responses)
        {
            roles.AddRange(response.Roles);
        }

        return roles;
    }


    /// <summary>
    /// List SAML authentication providers.
    /// </summary>
    /// <returns>A list of SAML providers.</returns>
    public async Task<List<SAMLProviderListEntry>> ListSAMLProvidersAsync()
    {
        var response = await _IAMService.ListSAMLProvidersAsync(new ListSAMLProvidersRequest());
        return response.SAMLProviderList;
    }


    /// <summary>
    /// List IAM users.
    /// </summary>
    /// <returns>A list of IAM users.</returns>
    public async Task<List<User>> ListUsersAsync()
    {
        var listUsersPaginator = _IAMService.Paginators.ListUsers(new ListUsersRequest());
        var users = new List<User>();

        await foreach (var response in listUsersPaginator.Responses)
        {
            users.AddRange(response.Users);
        }

        return users;
    }


    /// <summary>
    /// Update the inline policy document embedded in a role.
    /// </summary>
    /// <param name="policyName">The name of the policy to embed.</param>
    /// <param name="roleName">The name of the role to update.</param>
    /// <param name="policyDocument">The policy document that defines the role.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> PutRolePolicyAsync(string policyName, string roleName, string policyDocument)
    {
        var request = new PutRolePolicyRequest
        {
            PolicyName = policyName,
            RoleName = roleName,
            PolicyDocument = policyDocument
        };

        var response = await _IAMService.PutRolePolicyAsync(request);
        return response.HttpStatusCode == HttpStatusCode.OK;
    }


    /// <summary>
    /// Add or update an inline policy document that is embedded in an IAM user.
    /// </summary>
    /// <param name="userName">The name of the IAM user.</param>
    /// <param name="policyName">The name of the IAM policy.</param>
    /// <param name="policyDocument">The policy document defining the IAM policy.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> PutUserPolicyAsync(string userName, string policyName, string policyDocument)
    {
        var request = new PutUserPolicyRequest
        {
            UserName = userName,
            PolicyName = policyName,
            PolicyDocument = policyDocument
        };

        var response = await _IAMService.PutUserPolicyAsync(request);
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }

    /// <summary>
    /// Wait for a new access key to be ready to use.
    /// </summary>
    /// <param name="accessKeyId">The Id of the access key.</param>
    /// <returns>A boolean value indicating the success of the action.</returns>
    public async Task<bool> WaitUntilAccessKeyIsReady(string accessKeyId)
    {
        var keyReady = false;

        do
        {
            try
            {
                var response = await _IAMService.GetAccessKeyLastUsedAsync(
                    new GetAccessKeyLastUsedRequest { AccessKeyId = accessKeyId });
                if (response.UserName is not null)
                {
                    keyReady = true;
                }
            }
            catch (NoSuchEntityException)
            {
                keyReady = false;
            }
        } while (!keyReady);

        return keyReady;
    }
}



using Microsoft.Extensions.Configuration;

namespace IAMBasics;

public class IAMBasics
{
    private static ILogger logger = null!;

    static async Task Main(string[] args)
    {
        // Set up dependency injection for the AWS service.
        using var host = Host.CreateDefaultBuilder(args)
            .ConfigureLogging(logging =>
                logging.AddFilter("System", LogLevel.Debug)
                    .AddFilter<DebugLoggerProvider>("Microsoft", LogLevel.Information)
                    .AddFilter<ConsoleLoggerProvider>("Microsoft", LogLevel.Trace))
            .ConfigureServices((_, services) =>
            services.AddAWSService<IAmazonIdentityManagementService>()
            .AddTransient<IAMWrapper>()
            .AddTransient<UIWrapper>()
            )
            .Build();

        logger = LoggerFactory.Create(builder => { builder.AddConsole(); })
            .CreateLogger<IAMBasics>();


        IConfiguration configuration = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("settings.json") // Load test settings from .json file.
            .AddJsonFile("settings.local.json",
                true) // Optionally load local settings.
            .Build();

        // Values needed for user, role, and policies.
        string userName = configuration["UserName"]!;
        string s3PolicyName = configuration["S3PolicyName"]!;
        string roleName = configuration["RoleName"]!;


        var iamWrapper = host.Services.GetRequiredService<IAMWrapper>();
        var uiWrapper = host.Services.GetRequiredService<UIWrapper>();

        uiWrapper.DisplayBasicsOverview();
        uiWrapper.PressEnter();

        // First create a user. By default, the new user has
        // no permissions.
        uiWrapper.DisplayTitle("Create User");
        Console.WriteLine($"Creating a new user with user name: {userName}.");
        var user = await iamWrapper.CreateUserAsync(userName);
        var userArn = user.Arn;

        Console.WriteLine($"Successfully created user: {userName} with ARN: {userArn}.");
        uiWrapper.WaitABit(15, "Now let's wait for the user to be ready for use.");

        // Define a role policy document that allows the new user
        // to assume the role.
        string assumeRolePolicyDocument = "{" +
          "\"Version\": \"2012-10-17\"," +
          "\"Statement\": [{" +
              "\"Effect\": \"Allow\"," +
              "\"Principal\": {" +
              $"	\"AWS\": \"{userArn}\"" +
              "}," +
              "\"Action\": \"sts:AssumeRole\"" +
          "}]" +
        "}";

        // Permissions to list all buckets.
        string policyDocument = "{" +
            "\"Version\": \"2012-10-17\"," +
            "	\"Statement\" : [{" +
                "	\"Action\" : [\"s3:ListAllMyBuckets\"]," +
                "	\"Effect\" : \"Allow\"," +
                "	\"Resource\" : \"*\"" +
            "}]" +
        "}";

        // Create an AccessKey for the user.
        uiWrapper.DisplayTitle("Create access key");
        Console.WriteLine("Now let's create an access key for the new user.");
        var accessKey = await iamWrapper.CreateAccessKeyAsync(userName);

        var accessKeyId = accessKey.AccessKeyId;
        var secretAccessKey = accessKey.SecretAccessKey;

        Console.WriteLine($"We have created the access key with Access key id: {accessKeyId}.");

        Console.WriteLine("Now let's wait until the IAM access key is ready to use.");
        var keyReady = await iamWrapper.WaitUntilAccessKeyIsReady(accessKeyId);

        // Now try listing the Amazon Simple Storage Service (Amazon S3)
        // buckets. This should fail at this point because the user doesn't
        // have permissions to perform this task.
        uiWrapper.DisplayTitle("Try to display Amazon S3 buckets");
        Console.WriteLine("Now let's try to display a list of the user's Amazon S3 buckets.");
        var s3Client1 = new AmazonS3Client(accessKeyId, secretAccessKey);
        var stsClient1 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey);

        var s3Wrapper = new S3Wrapper(s3Client1, stsClient1);
        var buckets = await s3Wrapper.ListMyBucketsAsync();

        Console.WriteLine(buckets is null
            ? "As expected, the call to list the buckets has returned a null list."
            : "Something went wrong. This shouldn't have worked.");

        uiWrapper.PressEnter();

        uiWrapper.DisplayTitle("Create IAM role");
        Console.WriteLine($"Creating the role: {roleName}");

        // Creating an IAM role to allow listing the S3 buckets. A role name
        // is not case sensitive and must be unique to the account for which it
        // is created.
        var roleArn = await iamWrapper.CreateRoleAsync(roleName, assumeRolePolicyDocument);

        uiWrapper.PressEnter();

        // Create a policy with permissions to list S3 buckets.
        uiWrapper.DisplayTitle("Create IAM policy");
        Console.WriteLine($"Creating the policy: {s3PolicyName}");
        Console.WriteLine("with permissions to list the Amazon S3 buckets for the account.");
        var policy = await iamWrapper.CreatePolicyAsync(s3PolicyName, policyDocument);

        // Wait 15 seconds for the IAM policy to be available.
        uiWrapper.WaitABit(15, "Waiting for the policy to be available.");

        // Attach the policy to the role you created earlier.
        uiWrapper.DisplayTitle("Attach new IAM policy");
        Console.WriteLine("Now let's attach the policy to the role.");
        await iamWrapper.AttachRolePolicyAsync(policy.Arn, roleName);

        // Wait 15 seconds for the role to be updated.
        Console.WriteLine();
        uiWrapper.WaitABit(15, "Waiting for the policy to be attached.");

        // Use the AWS Security Token Service (AWS STS) to have the user
        // assume the role we created.
        var stsClient2 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey);

        // Wait for the new credentials to become valid.
        uiWrapper.WaitABit(10, "Waiting for the credentials to be valid.");

        var assumedRoleCredentials = await s3Wrapper.AssumeS3RoleAsync("temporary-session", roleArn);

        // Try again to list the buckets using the client created with
        // the new user's credentials. This time, it should work.
        var s3Client2 = new AmazonS3Client(assumedRoleCredentials);

        s3Wrapper.UpdateClients(s3Client2, stsClient2);

        buckets = await s3Wrapper.ListMyBucketsAsync();

        uiWrapper.DisplayTitle("List Amazon S3 buckets");
        Console.WriteLine("This time we should have buckets to list.");
        if (buckets is not null)
        {
            buckets.ForEach(bucket =>
            {
                Console.WriteLine($"{bucket.BucketName} created: {bucket.CreationDate}");
            });
        }

        uiWrapper.PressEnter();

        // Now clean up all the resources used in the example.
        uiWrapper.DisplayTitle("Clean up resources");
        Console.WriteLine("Thank you for watching. The IAM Basics demo is complete.");
        Console.WriteLine("Please wait while we clean up the resources we created.");

        await iamWrapper.DetachRolePolicyAsync(policy.Arn, roleName);

        await iamWrapper.DeletePolicyAsync(policy.Arn);

        await iamWrapper.DeleteRoleAsync(roleName);

        await iamWrapper.DeleteAccessKeyAsync(accessKeyId, userName);

        await iamWrapper.DeleteUserAsync(userName);

        uiWrapper.PressEnter();

        Console.WriteLine("All done cleaning up our resources. Thank you for your patience.");
    }
}


namespace IamScenariosCommon;

using System.Net;

/// <summary>
/// A class to perform Amazon Simple Storage Service (Amazon S3) actions for
/// the IAM Basics scenario.
/// </summary>
public class S3Wrapper
{
    private IAmazonS3 _s3Service;
    private IAmazonSecurityTokenService _stsService;

    /// <summary>
    /// Constructor for the S3Wrapper class.
    /// </summary>
    /// <param name="s3Service">An Amazon S3 client object.</param>
    /// <param name="stsService">An AWS Security Token Service (AWS STS)
    /// client object.</param>
    public S3Wrapper(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService)
    {
        _s3Service = s3Service;
        _stsService = stsService;
    }

    /// <summary>
    /// Assumes an AWS Identity and Access Management (IAM) role that allows
    /// Amazon S3 access for the current session.
    /// </summary>
    /// <param name="roleSession">A string representing the current session.</param>
    /// <param name="roleToAssume">The name of the IAM role to assume.</param>
    /// <returns>Credentials for the newly assumed IAM role.</returns>
    public async Task<Credentials> AssumeS3RoleAsync(string roleSession, string roleToAssume)
    {
        // Create the request to use with the AssumeRoleAsync call.
        var request = new AssumeRoleRequest()
        {
            RoleSessionName = roleSession,
            RoleArn = roleToAssume,
        };

        var response = await _stsService.AssumeRoleAsync(request);

        return response.Credentials;
    }


    /// <summary>
    /// Delete an S3 bucket.
    /// </summary>
    /// <param name="bucketName">Name of the S3 bucket to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteBucketAsync(string bucketName)
    {
        var result = await _s3Service.DeleteBucketAsync(new DeleteBucketRequest { BucketName = bucketName });
        return result.HttpStatusCode == HttpStatusCode.OK;
    }

    /// <summary>
    /// List the buckets that are owned by the user's account.
    /// </summary>
    /// <returns>Async Task.</returns>
    public async Task<List<S3Bucket>?> ListMyBucketsAsync()
    {
        try
        {
            // Get the list of buckets accessible by the new user.
            var response = await _s3Service.ListBucketsAsync();

            return response.Buckets;
        }
        catch (AmazonS3Exception ex)
        {
            // Something else went wrong. Display the error message.
            Console.WriteLine($"Error: {ex.Message}");
            return null;
        }
    }

    /// <summary>
    /// Create a new S3 bucket.
    /// </summary>
    /// <param name="bucketName">The name for the new bucket.</param>
    /// <returns>A Boolean value indicating whether the action completed
    /// successfully.</returns>
    public async Task<bool> PutBucketAsync(string bucketName)
    {
        var response = await _s3Service.PutBucketAsync(new PutBucketRequest { BucketName = bucketName });
        return response.HttpStatusCode == HttpStatusCode.OK;
    }

    /// <summary>
    /// Update the client objects with new client objects. This is available
    /// because the scenario uses the methods of this class without and then
    /// with the proper permissions to list S3 buckets.
    /// </summary>
    /// <param name="s3Service">The Amazon S3 client object.</param>
    /// <param name="stsService">The AWS STS client object.</param>
    public void UpdateClients(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService)
    {
        _s3Service = s3Service;
        _stsService = stsService;
    }
}


namespace IamScenariosCommon;

public class UIWrapper
{
    public readonly string SepBar = new('-', Console.WindowWidth);

    /// <summary>
    /// Show information about the IAM Groups scenario.
    /// </summary>
    public void DisplayGroupsOverview()
    {
        Console.Clear();

        DisplayTitle("Welcome to the IAM Groups Demo");
        Console.WriteLine("This example application does the following:");
        Console.WriteLine("\t1. Creates an Amazon Identity and Access Management (IAM) group.");
        Console.WriteLine("\t2. Adds an IAM policy to the IAM group giving it full access to Amazon S3.");
        Console.WriteLine("\t3. Creates a new IAM user.");
        Console.WriteLine("\t4. Creates an IAM access key for the user.");
        Console.WriteLine("\t5. Adds the user to the IAM group.");
        Console.WriteLine("\t6. Lists the buckets on the account.");
        Console.WriteLine("\t7. Proves that the user has full Amazon S3 access by creating a bucket.");
        Console.WriteLine("\t8. List the buckets again to show the new bucket.");
        Console.WriteLine("\t9. Cleans up all the resources created.");
    }

    /// <summary>
    /// Show information about the IAM Basics scenario.
    /// </summary>
    public void DisplayBasicsOverview()
    {
        Console.Clear();

        DisplayTitle("Welcome to IAM Basics");
        Console.WriteLine("This example application does the following:");
        Console.WriteLine("\t1. Creates a user with no permissions.");
        Console.WriteLine("\t2. Creates a role and policy that grant s3:ListAllMyBuckets permission.");
        Console.WriteLine("\t3. Grants the user permission to assume the role.");
        Console.WriteLine("\t4. Creates an S3 client object as the user and tries to list buckets (this will fail).");
        Console.WriteLine("\t5. Gets temporary credentials by assuming the role.");
        Console.WriteLine("\t6. Creates a new S3 client object with the temporary credentials and lists the buckets (this will succeed).");
        Console.WriteLine("\t7. Deletes all the resources.");
    }

    /// <summary>
    /// Display a message and wait until the user presses enter.
    /// </summary>
    public void PressEnter()
    {
        Console.Write("\nPress <Enter> to continue. ");
        _ = Console.ReadLine();
        Console.WriteLine();
    }

    /// <summary>
    /// Pad a string with spaces to center it on the console display.
    /// </summary>
    /// <param name="strToCenter">The string to be centered.</param>
    /// <returns>The padded string.</returns>
    public string CenterString(string strToCenter)
    {
        var padAmount = (Console.WindowWidth - strToCenter.Length) / 2;
        var leftPad = new string(' ', padAmount);
        return $"{leftPad}{strToCenter}";
    }

    /// <summary>
    /// Display a line of hyphens, the centered text of the title, and another
    /// line of hyphens.
    /// </summary>
    /// <param name="strTitle">The string to be displayed.</param>
    public void DisplayTitle(string strTitle)
    {
        Console.WriteLine(SepBar);
        Console.WriteLine(CenterString(strTitle));
        Console.WriteLine(SepBar);
    }

    /// <summary>
    /// Display a countdown and wait for a number of seconds.
    /// </summary>
    /// <param name="numSeconds">The number of seconds to wait.</param>
    public void WaitABit(int numSeconds, string msg)
    {
        Console.WriteLine(msg);

        // Wait for the requested number of seconds.
        for (int i = numSeconds; i > 0; i--)
        {
            System.Threading.Thread.Sleep(1000);
            Console.Write($"{i}...");
        }

        PressEnter();
    }
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour .NET *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Bash ]

**AWS CLI avec le script Bash**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples). 

```
###############################################################################
# function iam_create_user_assume_role
#
# Scenario to create an IAM user, create an IAM role, and apply the role to the user.
#
#     "IAM access" permissions are needed to run this code.
#     "STS assume role" permissions are needed to run this code. (Note: It might be necessary to
#           create a custom policy).
#
# Returns:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function iam_create_user_assume_role() {
  {
    if [ "$IAM_OPERATIONS_SOURCED" != "True" ]; then

      source ./iam_operations.sh
    fi
  }

  echo_repeat "*" 88
  echo "Welcome to the IAM create user and assume role demo."
  echo
  echo "This demo will create an IAM user, create an IAM role, and apply the role to the user."
  echo_repeat "*" 88
  echo

  echo -n "Enter a name for a new IAM user: "
  get_input
  user_name=$get_input_result

  local user_arn
  user_arn=$(iam_create_user -u "$user_name")

  # shellcheck disable=SC2181
  if [[ ${?} == 0 ]]; then
    echo "Created demo IAM user named $user_name"
  else
    errecho "$user_arn"
    errecho "The user failed to create. This demo will exit."
    return 1
  fi

  local access_key_response
  access_key_response=$(iam_create_user_access_key -u "$user_name")
  # shellcheck disable=SC2181
  if [[ ${?} != 0 ]]; then
    errecho "The access key failed to create. This demo will exit."
    clean_up "$user_name"
    return 1
  fi

  IFS=$'\t ' read -r -a access_key_values <<<"$access_key_response"
  local key_name=${access_key_values[0]}
  local key_secret=${access_key_values[1]}

  echo "Created access key named $key_name"

  echo "Wait 10 seconds for the user to be ready."
  sleep 10
  echo_repeat "*" 88
  echo

  local iam_role_name
  iam_role_name=$(generate_random_name "test-role")
  echo "Creating a role named $iam_role_name with user $user_name as the principal."

  local assume_role_policy_document="{
    \"Version\": \"2012-10-17\",
    \"Statement\": [{
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"$user_arn\"},
        \"Action\": \"sts:AssumeRole\"
        }]
    }"

  local role_arn
  role_arn=$(iam_create_role -n "$iam_role_name" -p "$assume_role_policy_document")

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Created IAM role named $iam_role_name"
  else
    errecho "The role failed to create. This demo will exit."
    clean_up "$user_name" "$key_name"
    return 1
  fi

  local policy_name
  policy_name=$(generate_random_name "test-policy")
  local policy_document="{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]}"

  local policy_arn
  policy_arn=$(iam_create_policy -n "$policy_name" -p "$policy_document")
  # shellcheck disable=SC2181
  if [[ ${?} == 0 ]]; then
    echo "Created  IAM policy named $policy_name"
  else
    errecho "The policy failed to create."
    clean_up "$user_name" "$key_name" "$iam_role_name"
    return 1
  fi

  if (iam_attach_role_policy -n "$iam_role_name" -p "$policy_arn"); then
    echo "Attached policy $policy_arn to role $iam_role_name"
  else
    errecho "The policy failed to attach."
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn"
    return 1
  fi

  local assume_role_policy_document="{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"$role_arn\"}]}"

  local assume_role_policy_name
  assume_role_policy_name=$(generate_random_name "test-assume-role-")

  # shellcheck disable=SC2181
  local assume_role_policy_arn
  assume_role_policy_arn=$(iam_create_policy -n "$assume_role_policy_name" -p "$assume_role_policy_document")
  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Created  IAM policy named $assume_role_policy_name for sts assume role"
  else
    errecho "The policy failed to create."
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn"
    return 1
  fi

  echo "Wait 10 seconds to give AWS time to propagate these new resources and connections."
  sleep 10
  echo_repeat "*" 88
  echo

  echo "Try to list buckets without the new user assuming the role."
  echo_repeat "*" 88
  echo

  # Set the environment variables for the created user.
  # bashsupport disable=BP2001
  export AWS_ACCESS_KEY_ID=$key_name
  # bashsupport disable=BP2001
  export AWS_SECRET_ACCESS_KEY=$key_secret

  local buckets
  buckets=$(s3_list_buckets)

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    local bucket_count
    bucket_count=$(echo "$buckets" | wc -w | xargs)
    echo "There are $bucket_count buckets in the account. This should not have happened."
  else
    errecho "Because the role with permissions has not been assumed, listing buckets failed."
  fi

  echo
  echo_repeat "*" 88
  echo "Now assume the role $iam_role_name and list the buckets."
  echo_repeat "*" 88
  echo

  local credentials

  credentials=$(sts_assume_role -r "$role_arn" -n "AssumeRoleDemoSession")
  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Assumed role $iam_role_name"
  else
    errecho "Failed to assume role."
    export AWS_ACCESS_KEY_ID=""
    export AWS_SECRET_ACCESS_KEY=""
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"
    return 1
  fi

  IFS=$'\t ' read -r -a credentials <<<"$credentials"

  export AWS_ACCESS_KEY_ID=${credentials[0]}
  export AWS_SECRET_ACCESS_KEY=${credentials[1]}
  # bashsupport disable=BP2001
  export AWS_SESSION_TOKEN=${credentials[2]}

  buckets=$(s3_list_buckets)

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    local bucket_count
    bucket_count=$(echo "$buckets" | wc -w | xargs)
    echo "There are $bucket_count buckets in the account. Listing buckets succeeded because of "
    echo "the assumed role."
  else
    errecho "Failed to list buckets. This should not happen."
    export AWS_ACCESS_KEY_ID=""
    export AWS_SECRET_ACCESS_KEY=""
    export AWS_SESSION_TOKEN=""
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"
    return 1
  fi

  local result=0
  export AWS_ACCESS_KEY_ID=""
  export AWS_SECRET_ACCESS_KEY=""

  echo
  echo_repeat "*" 88
  echo "The created resources will now be deleted."
  echo_repeat "*" 88
  echo

  clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"

  # shellcheck disable=SC2181
  if [[ ${?} -ne 0 ]]; then
    result=1
  fi

  return $result
}
```
Fonctions IAM utilisées dans ce scénario.  

```
###############################################################################
# function iam_user_exists
#
# This function checks to see if the specified AWS Identity and Access Management (IAM) user already exists.
#
# Parameters:
#       $1 - The name of the IAM user to check.
#
# Returns:
#       0 - If the user already exists.
#       1 - If the user doesn't exist.
###############################################################################
function iam_user_exists() {
  local user_name
  user_name=$1

  # Check whether the IAM user already exists.
  # We suppress all output - we're interested only in the return code.

  local errors
  errors=$(aws iam get-user \
    --user-name "$user_name" 2>&1 >/dev/null)

  local error_code=${?}

  if [[ $error_code -eq 0 ]]; then
    return 0 # 0 in Bash script means true.
  else
    if [[ $errors != *"error"*"(NoSuchEntity)"* ]]; then
      aws_cli_error_log $error_code
      errecho "Error calling iam get-user $errors"
    fi

    return 1 # 1 in Bash script means false.
  fi
}

###############################################################################
# function iam_create_user
#
# This function creates the specified IAM user, unless
# it already exists.
#
# Parameters:
#       -u user_name  -- The name of the user to create.
#
# Returns:
#       The ARN of the user.
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_user() {
  local user_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user"
    echo "Creates an AWS Identity and Access Management (IAM) user. You must supply a username:"
    echo "  -u user_name    The name of the user. It must be unique within the account."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    User name:   $user_name"
  iecho ""

  # If the user already exists, we don't want to try to create it.
  if (iam_user_exists "$user_name"); then
    errecho "ERROR: A user with that name already exists in the account."
    return 1
  fi

  response=$(aws iam create-user --user-name "$user_name" \
    --output text \
    --query 'User.Arn')

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-user operation failed.$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_create_user_access_key
#
# This function creates an IAM access key for the specified user.
#
# Parameters:
#       -u user_name -- The name of the IAM user.
#       [-f file_name] -- The optional file name for the access key output.
#
# Returns:
#       [access_key_id access_key_secret]
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_user_access_key() {
  local user_name file_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user_access_key"
    echo "Creates an AWS Identity and Access Management (IAM) key pair."
    echo "  -u user_name   The name of the IAM user."
    echo "  [-f file_name]   Optional file name for the access key output."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:f:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      f) file_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  response=$(aws iam create-access-key \
    --user-name "$user_name" \
    --output text)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-access-key operation failed.$response"
    return 1
  fi

  if [[ -n "$file_name" ]]; then
    echo "$response" >"$file_name"
  fi

  local key_id key_secret
  # shellcheck disable=SC2086
  key_id=$(echo $response | cut -f 2 -d ' ')
  # shellcheck disable=SC2086
  key_secret=$(echo $response | cut -f 4 -d ' ')

  echo "$key_id $key_secret"

  return 0
}

###############################################################################
# function iam_create_role
#
# This function creates an IAM role.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_json -- The assume role policy document.
#
# Returns:
#       The ARN of the role.
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_role() {
  local role_name policy_document response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user_access_key"
    echo "Creates an AWS Identity and Access Management (IAM) role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_json -- The assume role policy document."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_document="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_document" ]]; then
    errecho "ERROR: You must provide a policy document with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam create-role \
    --role-name "$role_name" \
    --assume-role-policy-document "$policy_document" \
    --output text \
    --query Role.Arn)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_create_policy
#
# This function creates an IAM policy.
#
# Parameters:
#       -n policy_name -- The name of the IAM policy.
#       -p policy_json -- The policy document.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_policy() {
  local policy_name policy_document response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_policy"
    echo "Creates an AWS Identity and Access Management (IAM) policy."
    echo "  -n policy_name   The name of the IAM policy."
    echo "  -p policy_json -- The policy document."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) policy_name="${OPTARG}" ;;
      p) policy_document="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$policy_name" ]]; then
    errecho "ERROR: You must provide a policy name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_document" ]]; then
    errecho "ERROR: You must provide a policy document with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam create-policy \
    --policy-name "$policy_name" \
    --policy-document "$policy_document" \
    --output text \
    --query Policy.Arn)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"
}

###############################################################################
# function iam_attach_role_policy
#
# This function attaches an IAM policy to a tole.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_ARN -- The IAM policy document ARN..
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_attach_role_policy() {
  local role_name policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_attach_role_policy"
    echo "Attaches an AWS Identity and Access Management (IAM) policy to an IAM role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_ARN -- The IAM policy document ARN."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy ARN with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam attach-role-policy \
    --role-name "$role_name" \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports attach-role-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_detach_role_policy
#
# This function detaches an IAM policy to a tole.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_ARN -- The IAM policy document ARN..
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_detach_role_policy() {
  local role_name policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_detach_role_policy"
    echo "Detaches an AWS Identity and Access Management (IAM) policy to an IAM role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_ARN -- The IAM policy document ARN."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy ARN with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam detach-role-policy \
    --role-name "$role_name" \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports detach-role-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_delete_policy
#
# This function deletes an IAM policy.
#
# Parameters:
#       -n policy_arn -- The name of the IAM policy arn.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_policy() {
  local policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_policy"
    echo "Deletes an AWS Identity and Access Management (IAM) policy"
    echo "  -n policy_arn -- The name of the IAM policy arn."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:h" option; do
    case "${option}" in
      n) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy arn with the -n parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Policy arn:  $policy_arn"
  iecho ""

  response=$(aws iam delete-policy \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-policy operation failed.\n$response"
    return 1
  fi

  iecho "delete-policy response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_role
#
# This function deletes an IAM role.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_role() {
  local role_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_role"
    echo "Deletes an AWS Identity and Access Management (IAM) role"
    echo "  -n role_name -- The name of the IAM role."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  echo "role_name:$role_name"
  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Role name:  $role_name"
  iecho ""

  response=$(aws iam delete-role \
    --role-name "$role_name")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-role operation failed.\n$response"
    return 1
  fi

  iecho "delete-role response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_access_key
#
# This function deletes an IAM access key for the specified IAM user.
#
# Parameters:
#       -u user_name  -- The name of the user.
#       -k access_key -- The access key to delete.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_access_key() {
  local user_name access_key response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_access_key"
    echo "Deletes an AWS Identity and Access Management (IAM) access key for the specified IAM user"
    echo "  -u user_name    The name of the user."
    echo "  -k access_key   The access key to delete."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:k:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      k) access_key="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  if [[ -z "$access_key" ]]; then
    errecho "ERROR: You must provide an access key with the -k parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Username:   $user_name"
  iecho "    Access key:   $access_key"
  iecho ""

  response=$(aws iam delete-access-key \
    --user-name "$user_name" \
    --access-key-id "$access_key")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-access-key operation failed.\n$response"
    return 1
  fi

  iecho "delete-access-key response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_user
#
# This function deletes the specified IAM user.
#
# Parameters:
#       -u user_name  -- The name of the user to create.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_user() {
  local user_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_user"
    echo "Deletes an AWS Identity and Access Management (IAM) user. You must supply a username:"
    echo "  -u user_name    The name of the user."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    User name:   $user_name"
  iecho ""

  # If the user does not exist, we don't want to try to delete it.
  if (! iam_user_exists "$user_name"); then
    errecho "ERROR: A user with that name does not exist in the account."
    return 1
  fi

  response=$(aws iam delete-user \
    --user-name "$user_name")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-user operation failed.$response"
    return 1
  fi

  iecho "delete-user response:$response"
  iecho

  return 0
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des commandes de l’AWS CLI *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/PutUserPolicy)

------
#### [ C\$1\$1 ]

**SDK pour C\$1\$1**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/iam#code-examples). 

```
namespace AwsDoc {
    namespace IAM {
  
        //! Cleanup by deleting created entities.
        /*!
          \sa DeleteCreatedEntities
          \param client: IAM client.
          \param role: IAM role.
          \param user: IAM user.
          \param policy: IAM policy.
        */
        static bool DeleteCreatedEntities(const Aws::IAM::IAMClient &client,
                                          const Aws::IAM::Model::Role &role,
                                          const Aws::IAM::Model::User &user,
                                          const Aws::IAM::Model::Policy &policy);
    }

    static const int LIST_BUCKETS_WAIT_SEC = 20;

    static const char ALLOCATION_TAG[] = "example_code";
}

//! Scenario to create an IAM user, create an IAM role, and apply the role to the user.
// "IAM access" permissions are needed to run this code.
// "STS assume role" permissions are needed to run this code. (Note: It might be necessary to
//    create a custom policy).
/*!
  \sa iamCreateUserAssumeRoleScenario
  \param clientConfig: Aws client configuration.
  \return bool: Successful completion.
*/
bool AwsDoc::IAM::iamCreateUserAssumeRoleScenario(
        const Aws::Client::ClientConfiguration &clientConfig) {

    Aws::IAM::IAMClient client(clientConfig);
    Aws::IAM::Model::User user;
    Aws::IAM::Model::Role role;
    Aws::IAM::Model::Policy policy;

    // 1. Create a user.
    {
        Aws::IAM::Model::CreateUserRequest request;
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String userName = "iam-demo-user-" +
                               Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetUserName(userName);

        Aws::IAM::Model::CreateUserOutcome outcome = client.CreateUser(request);
        if (!outcome.IsSuccess()) {
            std::cout << "Error creating IAM user " << userName << ":" <<
                      outcome.GetError().GetMessage() << std::endl;
            return false;
        }
        else {
            std::cout << "Successfully created IAM user " << userName << std::endl;
        }

        user = outcome.GetResult().GetUser();
    }

    // 2. Create a role.
    {
        // Get the IAM user for the current client in order to access its ARN.
        Aws::String iamUserArn;
        {
            Aws::IAM::Model::GetUserRequest request;
            Aws::IAM::Model::GetUserOutcome outcome = client.GetUser(request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error getting Iam user. " <<
                          outcome.GetError().GetMessage() << std::endl;

                DeleteCreatedEntities(client, role, user, policy);
                return false;
            }
            else {
                std::cout << "Successfully retrieved Iam user "
                          << outcome.GetResult().GetUser().GetUserName()
                          << std::endl;
            }

            iamUserArn = outcome.GetResult().GetUser().GetArn();
        }

        Aws::IAM::Model::CreateRoleRequest request;

        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String roleName = "iam-demo-role-" +
                               Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetRoleName(roleName);

        // Build policy document for role.
        Aws::Utils::Document jsonStatement;
        jsonStatement.WithString("Effect", "Allow");

        Aws::Utils::Document jsonPrincipal;
        jsonPrincipal.WithString("AWS", iamUserArn);
        jsonStatement.WithObject("Principal", jsonPrincipal);
        jsonStatement.WithString("Action", "sts:AssumeRole");
        jsonStatement.WithObject("Condition", Aws::Utils::Document());

        Aws::Utils::Document policyDocument;
        policyDocument.WithString("Version", "2012-10-17");

        Aws::Utils::Array<Aws::Utils::Document> statements(1);
        statements[0] = jsonStatement;
        policyDocument.WithArray("Statement", statements);

        std::cout << "Setting policy for role\n   "
                  << policyDocument.View().WriteCompact() << std::endl;

        // Set role policy document as JSON string.
        request.SetAssumeRolePolicyDocument(policyDocument.View().WriteCompact());

        Aws::IAM::Model::CreateRoleOutcome outcome = client.CreateRole(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating role. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully created a role with name " << roleName
                      << std::endl;
        }

        role = outcome.GetResult().GetRole();
    }

    // 3. Create an IAM policy.
    {
        Aws::IAM::Model::CreatePolicyRequest request;
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String policyName = "iam-demo-policy-" +
                                 Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetPolicyName(policyName);

        // Build IAM policy document.
        Aws::Utils::Document jsonStatement;
        jsonStatement.WithString("Effect", "Allow");
        jsonStatement.WithString("Action", "s3:ListAllMyBuckets");
        jsonStatement.WithString("Resource", "arn:aws:s3:::*");

        Aws::Utils::Document policyDocument;
        policyDocument.WithString("Version", "2012-10-17");

        Aws::Utils::Array<Aws::Utils::Document> statements(1);
        statements[0] = jsonStatement;
        policyDocument.WithArray("Statement", statements);

        std::cout << "Creating a policy.\n   " << policyDocument.View().WriteCompact()
                  << std::endl;

        // Set IAM policy document as JSON string.
        request.SetPolicyDocument(policyDocument.View().WriteCompact());

        Aws::IAM::Model::CreatePolicyOutcome outcome = client.CreatePolicy(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating policy. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully created a policy with name, " << policyName <<
                      "." << std::endl;
        }

        policy = outcome.GetResult().GetPolicy();
    }

    // 4. Assume the new role using the AWS Security Token Service (STS).
    Aws::STS::Model::Credentials credentials;
    {
        Aws::STS::STSClient stsClient(clientConfig);

        Aws::STS::Model::AssumeRoleRequest request;
        request.SetRoleArn(role.GetArn());
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String roleSessionName = "iam-demo-role-session-" +
                                      Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetRoleSessionName(roleSessionName);

        Aws::STS::Model::AssumeRoleOutcome assumeRoleOutcome;

        // Repeatedly call AssumeRole, because there is often a delay
        // before the role is available to be assumed.
        // Repeat at most 20 times when access is denied.
        int count = 0;
        while (true) {
            assumeRoleOutcome = stsClient.AssumeRole(request);
            if (!assumeRoleOutcome.IsSuccess()) {
                if (count > 20 ||
                    assumeRoleOutcome.GetError().GetErrorType() !=
                    Aws::STS::STSErrors::ACCESS_DENIED) {
                    std::cerr << "Error assuming role after 20 tries. " <<
                              assumeRoleOutcome.GetError().GetMessage() << std::endl;

                    DeleteCreatedEntities(client, role, user, policy);
                    return false;
                }
                std::this_thread::sleep_for(std::chrono::seconds(1));
            }
            else {
                std::cout << "Successfully assumed the role after " << count
                          << " seconds." << std::endl;
                break;
            }
            count++;
        }

        credentials = assumeRoleOutcome.GetResult().GetCredentials();
    }


    // 5. List objects in the bucket (This should fail).
    {
        Aws::S3::S3Client s3Client(
                Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(),
                                          credentials.GetSecretAccessKey(),
                                          credentials.GetSessionToken()),
                Aws::MakeShared<Aws::S3::S3EndpointProvider>(ALLOCATION_TAG),
                clientConfig);
        Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets();
        if (!listBucketsOutcome.IsSuccess()) {
            if (listBucketsOutcome.GetError().GetErrorType() !=
                Aws::S3::S3Errors::ACCESS_DENIED) {
                std::cerr << "Could not lists buckets. " <<
                          listBucketsOutcome.GetError().GetMessage() << std::endl;
            }
            else {
                std::cout
                        << "Access to list buckets denied because privileges have not been applied."
                        << std::endl;
            }
        }
        else {
            std::cerr
                    << "Successfully retrieved bucket lists when this should not happen."
                    << std::endl;
        }
    }

    // 6. Attach the policy to the role.
    {
        Aws::IAM::Model::AttachRolePolicyRequest request;
        request.SetRoleName(role.GetRoleName());
        request.WithPolicyArn(policy.GetArn());

        Aws::IAM::Model::AttachRolePolicyOutcome outcome = client.AttachRolePolicy(
                request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating policy. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully attached the policy with name, "
                      << policy.GetPolicyName() <<
                      ", to the role, " << role.GetRoleName() << "." << std::endl;
        }
    }

    int count = 0;
    // 7. List objects in the bucket (this should succeed).
    // Repeatedly call ListBuckets, because there is often a delay
    // before the policy with ListBucket permissions has been applied to the role.
    // Repeat at most LIST_BUCKETS_WAIT_SEC times when access is denied.
    while (true) {
        Aws::S3::S3Client s3Client(
                Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(),
                                          credentials.GetSecretAccessKey(),
                                          credentials.GetSessionToken()),
                Aws::MakeShared<Aws::S3::S3EndpointProvider>(ALLOCATION_TAG),
                clientConfig);
        Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets();
        if (!listBucketsOutcome.IsSuccess()) {
            if ((count > LIST_BUCKETS_WAIT_SEC) ||
                listBucketsOutcome.GetError().GetErrorType() !=
                Aws::S3::S3Errors::ACCESS_DENIED) {
                std::cerr << "Could not lists buckets after " << LIST_BUCKETS_WAIT_SEC << " seconds. " <<
                          listBucketsOutcome.GetError().GetMessage() << std::endl;
                DeleteCreatedEntities(client, role, user, policy);
                return false;
            }

            std::this_thread::sleep_for(std::chrono::seconds(1));
        }
        else {

            std::cout << "Successfully retrieved bucket lists after " << count
                      << " seconds." << std::endl;
            break;
        }
        count++;
    }

    // 8. Delete all the created resources.
    return DeleteCreatedEntities(client, role, user, policy);
}

bool AwsDoc::IAM::DeleteCreatedEntities(const Aws::IAM::IAMClient &client,
                                        const Aws::IAM::Model::Role &role,
                                        const Aws::IAM::Model::User &user,
                                        const Aws::IAM::Model::Policy &policy) {
    bool result = true;
    if (policy.ArnHasBeenSet()) {
        // Detach the policy from the role.
        {
            Aws::IAM::Model::DetachRolePolicyRequest request;
            request.SetPolicyArn(policy.GetArn());
            request.SetRoleName(role.GetRoleName());

            Aws::IAM::Model::DetachRolePolicyOutcome outcome = client.DetachRolePolicy(
                    request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error Detaching policy from roles. " <<
                          outcome.GetError().GetMessage() << std::endl;
                result = false;
            }
            else {
                std::cout << "Successfully detached the policy with arn "
                          << policy.GetArn()
                          << " from role " << role.GetRoleName() << "." << std::endl;
            }
        }

        // Delete the policy.
        {
            Aws::IAM::Model::DeletePolicyRequest request;
            request.WithPolicyArn(policy.GetArn());

            Aws::IAM::Model::DeletePolicyOutcome outcome = client.DeletePolicy(request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error deleting policy. " <<
                          outcome.GetError().GetMessage() << std::endl;
                result = false;
            }
            else {
                std::cout << "Successfully deleted the policy with arn "
                          << policy.GetArn() << std::endl;
            }
        }

    }

    if (role.RoleIdHasBeenSet()) {
        // Delete the role.
        Aws::IAM::Model::DeleteRoleRequest request;
        request.SetRoleName(role.GetRoleName());

        Aws::IAM::Model::DeleteRoleOutcome outcome = client.DeleteRole(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error deleting role. " <<
                      outcome.GetError().GetMessage() << std::endl;
            result = false;
        }
        else {
            std::cout << "Successfully deleted the role with name "
                      << role.GetRoleName() << std::endl;
        }
    }

    if (user.ArnHasBeenSet()) {
        // Delete the user.
        Aws::IAM::Model::DeleteUserRequest request;
        request.WithUserName(user.GetUserName());

        Aws::IAM::Model::DeleteUserOutcome outcome = client.DeleteUser(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error deleting user. " <<
                      outcome.GetError().GetMessage() << std::endl;
            result = false;
        }
        else {
            std::cout << "Successfully deleted the user with name "
                      << user.GetUserName() << std::endl;
        }
    }

    return result;
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour C\$1\$1 *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/PutUserPolicy)

------
#### [ Go ]

**Kit SDK pour Go V2**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2/iam#code-examples). 
Exécutez un scénario interactif à une invite de commande.  

```
import (
	"context"
	"errors"
	"fmt"
	"log"
	"math/rand"
	"strings"
	"time"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/credentials"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
	"github.com/aws/aws-sdk-go-v2/service/s3"
	"github.com/aws/aws-sdk-go-v2/service/sts"
	"github.com/aws/smithy-go"
	"github.com/awsdocs/aws-doc-sdk-examples/gov2/demotools"
	"github.com/awsdocs/aws-doc-sdk-examples/gov2/iam/actions"
)

// AssumeRoleScenario shows you how to use the AWS Identity and Access Management (IAM)
// service to perform the following actions:
//
//  1. Create a user who has no permissions.
//  2. Create a role that grants permission to list Amazon Simple Storage Service
//     (Amazon S3) buckets for the account.
//  3. Add a policy to let the user assume the role.
//  4. Try and fail to list buckets without permissions.
//  5. Assume the role and list S3 buckets using temporary credentials.
//  6. Delete the policy, role, and user.
type AssumeRoleScenario struct {
	sdkConfig      aws.Config
	accountWrapper actions.AccountWrapper
	policyWrapper  actions.PolicyWrapper
	roleWrapper    actions.RoleWrapper
	userWrapper    actions.UserWrapper
	questioner     demotools.IQuestioner
	helper         IScenarioHelper
	isTestRun      bool
}

// NewAssumeRoleScenario constructs an AssumeRoleScenario instance from a configuration.
// It uses the specified config to get an IAM client and create wrappers for the actions
// used in the scenario.
func NewAssumeRoleScenario(sdkConfig aws.Config, questioner demotools.IQuestioner,
	helper IScenarioHelper) AssumeRoleScenario {
	iamClient := iam.NewFromConfig(sdkConfig)
	return AssumeRoleScenario{
		sdkConfig:      sdkConfig,
		accountWrapper: actions.AccountWrapper{IamClient: iamClient},
		policyWrapper:  actions.PolicyWrapper{IamClient: iamClient},
		roleWrapper:    actions.RoleWrapper{IamClient: iamClient},
		userWrapper:    actions.UserWrapper{IamClient: iamClient},
		questioner:     questioner,
		helper:         helper,
	}
}

// addTestOptions appends the API options specified in the original configuration to
// another configuration. This is used to attach the middleware stubber to clients
// that are constructed during the scenario, which is needed for unit testing.
func (scenario AssumeRoleScenario) addTestOptions(scenarioConfig *aws.Config) {
	if scenario.isTestRun {
		scenarioConfig.APIOptions = append(scenarioConfig.APIOptions, scenario.sdkConfig.APIOptions...)
	}
}

// Run runs the interactive scenario.
func (scenario AssumeRoleScenario) Run(ctx context.Context) {
	defer func() {
		if r := recover(); r != nil {
			log.Printf("Something went wrong with the demo.\n")
			log.Println(r)
		}
	}()

	log.Println(strings.Repeat("-", 88))
	log.Println("Welcome to the AWS Identity and Access Management (IAM) assume role demo.")
	log.Println(strings.Repeat("-", 88))

	user := scenario.CreateUser(ctx)
	accessKey := scenario.CreateAccessKey(ctx, user)
	role := scenario.CreateRoleAndPolicies(ctx, user)
	noPermsConfig := scenario.ListBucketsWithoutPermissions(ctx, accessKey)
	scenario.ListBucketsWithAssumedRole(ctx, noPermsConfig, role)
	scenario.Cleanup(ctx, user, role)

	log.Println(strings.Repeat("-", 88))
	log.Println("Thanks for watching!")
	log.Println(strings.Repeat("-", 88))
}

// CreateUser creates a new IAM user. This user has no permissions.
func (scenario AssumeRoleScenario) CreateUser(ctx context.Context) *types.User {
	log.Println("Let's create an example user with no permissions.")
	userName := scenario.questioner.Ask("Enter a name for the example user:", demotools.NotEmpty{})
	user, err := scenario.userWrapper.GetUser(ctx, userName)
	if err != nil {
		panic(err)
	}
	if user == nil {
		user, err = scenario.userWrapper.CreateUser(ctx, userName)
		if err != nil {
			panic(err)
		}
		log.Printf("Created user %v.\n", *user.UserName)
	} else {
		log.Printf("User %v already exists.\n", *user.UserName)
	}
	log.Println(strings.Repeat("-", 88))
	return user
}

// CreateAccessKey creates an access key for the user.
func (scenario AssumeRoleScenario) CreateAccessKey(ctx context.Context, user *types.User) *types.AccessKey {
	accessKey, err := scenario.userWrapper.CreateAccessKeyPair(ctx, *user.UserName)
	if err != nil {
		panic(err)
	}
	log.Printf("Created access key %v for your user.", *accessKey.AccessKeyId)
	log.Println("Waiting a few seconds for your user to be ready...")
	scenario.helper.Pause(10)
	log.Println(strings.Repeat("-", 88))
	return accessKey
}

// CreateRoleAndPolicies creates a policy that grants permission to list S3 buckets for
// the current account and attaches the policy to a newly created role. It also adds an
// inline policy to the specified user that grants the user permission to assume the role.
func (scenario AssumeRoleScenario) CreateRoleAndPolicies(ctx context.Context, user *types.User) *types.Role {
	log.Println("Let's create a role and policy that grant permission to list S3 buckets.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	listBucketsRole, err := scenario.roleWrapper.CreateRole(ctx, scenario.helper.GetName(), *user.Arn)
	if err != nil {
		panic(err)
	}
	log.Printf("Created role %v.\n", *listBucketsRole.RoleName)
	listBucketsPolicy, err := scenario.policyWrapper.CreatePolicy(
		ctx, scenario.helper.GetName(), []string{"s3:ListAllMyBuckets"}, "arn:aws:s3:::*")
	if err != nil {
		panic(err)
	}
	log.Printf("Created policy %v.\n", *listBucketsPolicy.PolicyName)
	err = scenario.roleWrapper.AttachRolePolicy(ctx, *listBucketsPolicy.Arn, *listBucketsRole.RoleName)
	if err != nil {
		panic(err)
	}
	log.Printf("Attached policy %v to role %v.\n", *listBucketsPolicy.PolicyName,
		*listBucketsRole.RoleName)
	err = scenario.userWrapper.CreateUserPolicy(ctx, *user.UserName, scenario.helper.GetName(),
		[]string{"sts:AssumeRole"}, *listBucketsRole.Arn)
	if err != nil {
		panic(err)
	}
	log.Printf("Created an inline policy for user %v that lets the user assume the role.\n",
		*user.UserName)
	log.Println("Let's give AWS a few seconds to propagate these new resources and connections...")
	scenario.helper.Pause(10)
	log.Println(strings.Repeat("-", 88))
	return listBucketsRole
}

// ListBucketsWithoutPermissions creates an Amazon S3 client from the user's access key
// credentials and tries to list buckets for the account. Because the user does not have
// permission to perform this action, the action fails.
func (scenario AssumeRoleScenario) ListBucketsWithoutPermissions(ctx context.Context, accessKey *types.AccessKey) *aws.Config {
	log.Println("Let's try to list buckets without permissions. This should return an AccessDenied error.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	noPermsConfig, err := config.LoadDefaultConfig(ctx,
		config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(
			*accessKey.AccessKeyId, *accessKey.SecretAccessKey, ""),
		))
	if err != nil {
		panic(err)
	}

	// Add test options if this is a test run. This is needed only for testing purposes.
	scenario.addTestOptions(&noPermsConfig)

	s3Client := s3.NewFromConfig(noPermsConfig)
	_, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
	if err != nil {
		// The SDK for Go does not model the AccessDenied error, so check ErrorCode directly.
		var ae smithy.APIError
		if errors.As(err, &ae) {
			switch ae.ErrorCode() {
			case "AccessDenied":
				log.Println("Got AccessDenied error, which is the expected result because\n" +
					"the ListBuckets call was made without permissions.")
			default:
				log.Println("Expected AccessDenied, got something else.")
				panic(err)
			}
		}
	} else {
		log.Println("Expected AccessDenied error when calling ListBuckets without permissions,\n" +
			"but the call succeeded. Continuing the example anyway...")
	}
	log.Println(strings.Repeat("-", 88))
	return &noPermsConfig
}

// ListBucketsWithAssumedRole performs the following actions:
//
//  1. Creates an AWS Security Token Service (AWS STS) client from the config created from
//     the user's access key credentials.
//  2. Gets temporary credentials by assuming the role that grants permission to list the
//     buckets.
//  3. Creates an Amazon S3 client from the temporary credentials.
//  4. Lists buckets for the account. Because the temporary credentials are generated by
//     assuming the role that grants permission, the action succeeds.
func (scenario AssumeRoleScenario) ListBucketsWithAssumedRole(ctx context.Context, noPermsConfig *aws.Config, role *types.Role) {
	log.Println("Let's assume the role that grants permission to list buckets and try again.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	stsClient := sts.NewFromConfig(*noPermsConfig)
	tempCredentials, err := stsClient.AssumeRole(ctx, &sts.AssumeRoleInput{
		RoleArn:         role.Arn,
		RoleSessionName: aws.String("AssumeRoleExampleSession"),
		DurationSeconds: aws.Int32(900),
	})
	if err != nil {
		log.Printf("Couldn't assume role %v.\n", *role.RoleName)
		panic(err)
	}
	log.Printf("Assumed role %v, got temporary credentials.\n", *role.RoleName)
	assumeRoleConfig, err := config.LoadDefaultConfig(ctx,
		config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(
			*tempCredentials.Credentials.AccessKeyId,
			*tempCredentials.Credentials.SecretAccessKey,
			*tempCredentials.Credentials.SessionToken),
		),
	)
	if err != nil {
		panic(err)
	}

	// Add test options if this is a test run. This is needed only for testing purposes.
	scenario.addTestOptions(&assumeRoleConfig)

	s3Client := s3.NewFromConfig(assumeRoleConfig)
	result, err := s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
	if err != nil {
		log.Println("Couldn't list buckets with assumed role credentials.")
		panic(err)
	}
	log.Println("Successfully called ListBuckets with assumed role credentials, \n" +
		"here are some of them:")
	for i := 0; i < len(result.Buckets) && i < 5; i++ {
		log.Printf("\t%v\n", *result.Buckets[i].Name)
	}
	log.Println(strings.Repeat("-", 88))
}

// Cleanup deletes all resources created for the scenario.
func (scenario AssumeRoleScenario) Cleanup(ctx context.Context, user *types.User, role *types.Role) {
	if scenario.questioner.AskBool(
		"Do you want to delete the resources created for this example? (y/n)", "y",
	) {
		policies, err := scenario.roleWrapper.ListAttachedRolePolicies(ctx, *role.RoleName)
		if err != nil {
			panic(err)
		}
		for _, policy := range policies {
			err = scenario.roleWrapper.DetachRolePolicy(ctx, *role.RoleName, *policy.PolicyArn)
			if err != nil {
				panic(err)
			}
			err = scenario.policyWrapper.DeletePolicy(ctx, *policy.PolicyArn)
			if err != nil {
				panic(err)
			}
			log.Printf("Detached policy %v from role %v and deleted the policy.\n",
				*policy.PolicyName, *role.RoleName)
		}
		err = scenario.roleWrapper.DeleteRole(ctx, *role.RoleName)
		if err != nil {
			panic(err)
		}
		log.Printf("Deleted role %v.\n", *role.RoleName)

		userPols, err := scenario.userWrapper.ListUserPolicies(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		for _, userPol := range userPols {
			err = scenario.userWrapper.DeleteUserPolicy(ctx, *user.UserName, userPol)
			if err != nil {
				panic(err)
			}
			log.Printf("Deleted policy %v from user %v.\n", userPol, *user.UserName)
		}
		keys, err := scenario.userWrapper.ListAccessKeys(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		for _, key := range keys {
			err = scenario.userWrapper.DeleteAccessKey(ctx, *user.UserName, *key.AccessKeyId)
			if err != nil {
				panic(err)
			}
			log.Printf("Deleted access key %v from user %v.\n", *key.AccessKeyId, *user.UserName)
		}
		err = scenario.userWrapper.DeleteUser(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		log.Printf("Deleted user %v.\n", *user.UserName)
		log.Println(strings.Repeat("-", 88))
	}

}

// IScenarioHelper abstracts input and wait functions from a scenario so that they
// can be mocked for unit testing.
type IScenarioHelper interface {
	GetName() string
	Pause(secs int)
}

const rMax = 100000

type ScenarioHelper struct {
	Prefix string
	Random *rand.Rand
}

// GetName returns a unique name formed of a prefix and a random number.
func (helper *ScenarioHelper) GetName() string {
	return fmt.Sprintf("%v%v", helper.Prefix, helper.Random.Intn(rMax))
}

// Pause waits for the specified number of seconds.
func (helper ScenarioHelper) Pause(secs int) {
	time.Sleep(time.Duration(secs) * time.Second)
}
```
Définissez une structure qui encapsule les actions du compte.  

```
import (
	"context"
	"log"

	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// AccountWrapper encapsulates AWS Identity and Access Management (IAM) account actions
// used in the examples.
// It contains an IAM service client that is used to perform account actions.
type AccountWrapper struct {
	IamClient *iam.Client
}



// GetAccountPasswordPolicy gets the account password policy for the current account.
// If no policy has been set, a NoSuchEntityException is error is returned.
func (wrapper AccountWrapper) GetAccountPasswordPolicy(ctx context.Context) (*types.PasswordPolicy, error) {
	var pwPolicy *types.PasswordPolicy
	result, err := wrapper.IamClient.GetAccountPasswordPolicy(ctx,
		&iam.GetAccountPasswordPolicyInput{})
	if err != nil {
		log.Printf("Couldn't get account password policy. Here's why: %v\n", err)
	} else {
		pwPolicy = result.PasswordPolicy
	}
	return pwPolicy, err
}



// ListSAMLProviders gets the SAML providers for the account.
func (wrapper AccountWrapper) ListSAMLProviders(ctx context.Context) ([]types.SAMLProviderListEntry, error) {
	var providers []types.SAMLProviderListEntry
	result, err := wrapper.IamClient.ListSAMLProviders(ctx, &iam.ListSAMLProvidersInput{})
	if err != nil {
		log.Printf("Couldn't list SAML providers. Here's why: %v\n", err)
	} else {
		providers = result.SAMLProviderList
	}
	return providers, err
}
```
Définissez une structure qui encapsule les actions de la politique.  

```
import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// PolicyWrapper encapsulates AWS Identity and Access Management (IAM) policy actions
// used in the examples.
// It contains an IAM service client that is used to perform policy actions.
type PolicyWrapper struct {
	IamClient *iam.Client
}



// ListPolicies gets up to maxPolicies policies.
func (wrapper PolicyWrapper) ListPolicies(ctx context.Context, maxPolicies int32) ([]types.Policy, error) {
	var policies []types.Policy
	result, err := wrapper.IamClient.ListPolicies(ctx, &iam.ListPoliciesInput{
		MaxItems: aws.Int32(maxPolicies),
	})
	if err != nil {
		log.Printf("Couldn't list policies. Here's why: %v\n", err)
	} else {
		policies = result.Policies
	}
	return policies, err
}



// PolicyDocument defines a policy document as a Go struct that can be serialized
// to JSON.
type PolicyDocument struct {
	Version   string
	Statement []PolicyStatement
}

// PolicyStatement defines a statement in a policy document.
type PolicyStatement struct {
	Effect    string
	Action    []string
	Principal map[string]string `json:",omitempty"`
	Resource  *string           `json:",omitempty"`
}

// CreatePolicy creates a policy that grants a list of actions to the specified resource.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper PolicyWrapper) CreatePolicy(ctx context.Context, policyName string, actions []string,
	resourceArn string) (*types.Policy, error) {
	var policy *types.Policy
	policyDoc := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:   "Allow",
			Action:   actions,
			Resource: aws.String(resourceArn),
		}},
	}
	policyBytes, err := json.Marshal(policyDoc)
	if err != nil {
		log.Printf("Couldn't create policy document for %v. Here's why: %v\n", resourceArn, err)
		return nil, err
	}
	result, err := wrapper.IamClient.CreatePolicy(ctx, &iam.CreatePolicyInput{
		PolicyDocument: aws.String(string(policyBytes)),
		PolicyName:     aws.String(policyName),
	})
	if err != nil {
		log.Printf("Couldn't create policy %v. Here's why: %v\n", policyName, err)
	} else {
		policy = result.Policy
	}
	return policy, err
}



// GetPolicy gets data about a policy.
func (wrapper PolicyWrapper) GetPolicy(ctx context.Context, policyArn string) (*types.Policy, error) {
	var policy *types.Policy
	result, err := wrapper.IamClient.GetPolicy(ctx, &iam.GetPolicyInput{
		PolicyArn: aws.String(policyArn),
	})
	if err != nil {
		log.Printf("Couldn't get policy %v. Here's why: %v\n", policyArn, err)
	} else {
		policy = result.Policy
	}
	return policy, err
}



// DeletePolicy deletes a policy.
func (wrapper PolicyWrapper) DeletePolicy(ctx context.Context, policyArn string) error {
	_, err := wrapper.IamClient.DeletePolicy(ctx, &iam.DeletePolicyInput{
		PolicyArn: aws.String(policyArn),
	})
	if err != nil {
		log.Printf("Couldn't delete policy %v. Here's why: %v\n", policyArn, err)
	}
	return err
}
```
Définissez une structure qui encapsule les actions du rôle.  

```
import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// RoleWrapper encapsulates AWS Identity and Access Management (IAM) role actions
// used in the examples.
// It contains an IAM service client that is used to perform role actions.
type RoleWrapper struct {
	IamClient *iam.Client
}



// ListRoles gets up to maxRoles roles.
func (wrapper RoleWrapper) ListRoles(ctx context.Context, maxRoles int32) ([]types.Role, error) {
	var roles []types.Role
	result, err := wrapper.IamClient.ListRoles(ctx,
		&iam.ListRolesInput{MaxItems: aws.Int32(maxRoles)},
	)
	if err != nil {
		log.Printf("Couldn't list roles. Here's why: %v\n", err)
	} else {
		roles = result.Roles
	}
	return roles, err
}



// CreateRole creates a role that trusts a specified user. The trusted user can assume
// the role to acquire its permissions.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper RoleWrapper) CreateRole(ctx context.Context, roleName string, trustedUserArn string) (*types.Role, error) {
	var role *types.Role
	trustPolicy := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:    "Allow",
			Principal: map[string]string{"AWS": trustedUserArn},
			Action:    []string{"sts:AssumeRole"},
		}},
	}
	policyBytes, err := json.Marshal(trustPolicy)
	if err != nil {
		log.Printf("Couldn't create trust policy for %v. Here's why: %v\n", trustedUserArn, err)
		return nil, err
	}
	result, err := wrapper.IamClient.CreateRole(ctx, &iam.CreateRoleInput{
		AssumeRolePolicyDocument: aws.String(string(policyBytes)),
		RoleName:                 aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't create role %v. Here's why: %v\n", roleName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// GetRole gets data about a role.
func (wrapper RoleWrapper) GetRole(ctx context.Context, roleName string) (*types.Role, error) {
	var role *types.Role
	result, err := wrapper.IamClient.GetRole(ctx,
		&iam.GetRoleInput{RoleName: aws.String(roleName)})
	if err != nil {
		log.Printf("Couldn't get role %v. Here's why: %v\n", roleName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// CreateServiceLinkedRole creates a service-linked role that is owned by the specified service.
func (wrapper RoleWrapper) CreateServiceLinkedRole(ctx context.Context, serviceName string, description string) (
	*types.Role, error) {
	var role *types.Role
	result, err := wrapper.IamClient.CreateServiceLinkedRole(ctx, &iam.CreateServiceLinkedRoleInput{
		AWSServiceName: aws.String(serviceName),
		Description:    aws.String(description),
	})
	if err != nil {
		log.Printf("Couldn't create service-linked role %v. Here's why: %v\n", serviceName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// DeleteServiceLinkedRole deletes a service-linked role.
func (wrapper RoleWrapper) DeleteServiceLinkedRole(ctx context.Context, roleName string) error {
	_, err := wrapper.IamClient.DeleteServiceLinkedRole(ctx, &iam.DeleteServiceLinkedRoleInput{
		RoleName: aws.String(roleName)},
	)
	if err != nil {
		log.Printf("Couldn't delete service-linked role %v. Here's why: %v\n", roleName, err)
	}
	return err
}



// AttachRolePolicy attaches a policy to a role.
func (wrapper RoleWrapper) AttachRolePolicy(ctx context.Context, policyArn string, roleName string) error {
	_, err := wrapper.IamClient.AttachRolePolicy(ctx, &iam.AttachRolePolicyInput{
		PolicyArn: aws.String(policyArn),
		RoleName:  aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't attach policy %v to role %v. Here's why: %v\n", policyArn, roleName, err)
	}
	return err
}



// ListAttachedRolePolicies lists the policies that are attached to the specified role.
func (wrapper RoleWrapper) ListAttachedRolePolicies(ctx context.Context, roleName string) ([]types.AttachedPolicy, error) {
	var policies []types.AttachedPolicy
	result, err := wrapper.IamClient.ListAttachedRolePolicies(ctx, &iam.ListAttachedRolePoliciesInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't list attached policies for role %v. Here's why: %v\n", roleName, err)
	} else {
		policies = result.AttachedPolicies
	}
	return policies, err
}



// DetachRolePolicy detaches a policy from a role.
func (wrapper RoleWrapper) DetachRolePolicy(ctx context.Context, roleName string, policyArn string) error {
	_, err := wrapper.IamClient.DetachRolePolicy(ctx, &iam.DetachRolePolicyInput{
		PolicyArn: aws.String(policyArn),
		RoleName:  aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't detach policy from role %v. Here's why: %v\n", roleName, err)
	}
	return err
}



// ListRolePolicies lists the inline policies for a role.
func (wrapper RoleWrapper) ListRolePolicies(ctx context.Context, roleName string) ([]string, error) {
	var policies []string
	result, err := wrapper.IamClient.ListRolePolicies(ctx, &iam.ListRolePoliciesInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't list policies for role %v. Here's why: %v\n", roleName, err)
	} else {
		policies = result.PolicyNames
	}
	return policies, err
}



// DeleteRole deletes a role. All attached policies must be detached before a
// role can be deleted.
func (wrapper RoleWrapper) DeleteRole(ctx context.Context, roleName string) error {
	_, err := wrapper.IamClient.DeleteRole(ctx, &iam.DeleteRoleInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't delete role %v. Here's why: %v\n", roleName, err)
	}
	return err
}
```
Définissez une structure qui encapsule les actions de l’utilisateur.  

```
import (
	"context"
	"encoding/json"
	"errors"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
	"github.com/aws/smithy-go"
)

// UserWrapper encapsulates user actions used in the examples.
// It contains an IAM service client that is used to perform user actions.
type UserWrapper struct {
	IamClient *iam.Client
}



// ListUsers gets up to maxUsers number of users.
func (wrapper UserWrapper) ListUsers(ctx context.Context, maxUsers int32) ([]types.User, error) {
	var users []types.User
	result, err := wrapper.IamClient.ListUsers(ctx, &iam.ListUsersInput{
		MaxItems: aws.Int32(maxUsers),
	})
	if err != nil {
		log.Printf("Couldn't list users. Here's why: %v\n", err)
	} else {
		users = result.Users
	}
	return users, err
}



// GetUser gets data about a user.
func (wrapper UserWrapper) GetUser(ctx context.Context, userName string) (*types.User, error) {
	var user *types.User
	result, err := wrapper.IamClient.GetUser(ctx, &iam.GetUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		var apiError smithy.APIError
		if errors.As(err, &apiError) {
			switch apiError.(type) {
			case *types.NoSuchEntityException:
				log.Printf("User %v does not exist.\n", userName)
				err = nil
			default:
				log.Printf("Couldn't get user %v. Here's why: %v\n", userName, err)
			}
		}
	} else {
		user = result.User
	}
	return user, err
}



// CreateUser creates a new user with the specified name.
func (wrapper UserWrapper) CreateUser(ctx context.Context, userName string) (*types.User, error) {
	var user *types.User
	result, err := wrapper.IamClient.CreateUser(ctx, &iam.CreateUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't create user %v. Here's why: %v\n", userName, err)
	} else {
		user = result.User
	}
	return user, err
}



// CreateUserPolicy adds an inline policy to a user. This example creates a policy that
// grants a list of actions on a specified role.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper UserWrapper) CreateUserPolicy(ctx context.Context, userName string, policyName string, actions []string,
	roleArn string) error {
	policyDoc := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:   "Allow",
			Action:   actions,
			Resource: aws.String(roleArn),
		}},
	}
	policyBytes, err := json.Marshal(policyDoc)
	if err != nil {
		log.Printf("Couldn't create policy document for %v. Here's why: %v\n", roleArn, err)
		return err
	}
	_, err = wrapper.IamClient.PutUserPolicy(ctx, &iam.PutUserPolicyInput{
		PolicyDocument: aws.String(string(policyBytes)),
		PolicyName:     aws.String(policyName),
		UserName:       aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't create policy for user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// ListUserPolicies lists the inline policies for the specified user.
func (wrapper UserWrapper) ListUserPolicies(ctx context.Context, userName string) ([]string, error) {
	var policies []string
	result, err := wrapper.IamClient.ListUserPolicies(ctx, &iam.ListUserPoliciesInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't list policies for user %v. Here's why: %v\n", userName, err)
	} else {
		policies = result.PolicyNames
	}
	return policies, err
}



// DeleteUserPolicy deletes an inline policy from a user.
func (wrapper UserWrapper) DeleteUserPolicy(ctx context.Context, userName string, policyName string) error {
	_, err := wrapper.IamClient.DeleteUserPolicy(ctx, &iam.DeleteUserPolicyInput{
		PolicyName: aws.String(policyName),
		UserName:   aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete policy from user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// DeleteUser deletes a user.
func (wrapper UserWrapper) DeleteUser(ctx context.Context, userName string) error {
	_, err := wrapper.IamClient.DeleteUser(ctx, &iam.DeleteUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// CreateAccessKeyPair creates an access key for a user. The returned access key contains
// the ID and secret credentials needed to use the key.
func (wrapper UserWrapper) CreateAccessKeyPair(ctx context.Context, userName string) (*types.AccessKey, error) {
	var key *types.AccessKey
	result, err := wrapper.IamClient.CreateAccessKey(ctx, &iam.CreateAccessKeyInput{
		UserName: aws.String(userName)})
	if err != nil {
		log.Printf("Couldn't create access key pair for user %v. Here's why: %v\n", userName, err)
	} else {
		key = result.AccessKey
	}
	return key, err
}



// DeleteAccessKey deletes an access key from a user.
func (wrapper UserWrapper) DeleteAccessKey(ctx context.Context, userName string, keyId string) error {
	_, err := wrapper.IamClient.DeleteAccessKey(ctx, &iam.DeleteAccessKeyInput{
		AccessKeyId: aws.String(keyId),
		UserName:    aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete access key %v. Here's why: %v\n", keyId, err)
	}
	return err
}



// ListAccessKeys lists the access keys for the specified user.
func (wrapper UserWrapper) ListAccessKeys(ctx context.Context, userName string) ([]types.AccessKeyMetadata, error) {
	var keys []types.AccessKeyMetadata
	result, err := wrapper.IamClient.ListAccessKeys(ctx, &iam.ListAccessKeysInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't list access keys for user %v. Here's why: %v\n", userName, err)
	} else {
		keys = result.AccessKeyMetadata
	}
	return keys, err
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Go *.
  + [AttachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.AttachRolePolicy)
  + [CreateAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateAccessKey)
  + [CreatePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreatePolicy)
  + [CreateRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateRole)
  + [CreateUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateUser)
  + [DeleteAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteAccessKey)
  + [DeletePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeletePolicy)
  + [DeleteRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteRole)
  + [DeleteUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUser)
  + [DeleteUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUserPolicy)
  + [DetachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DetachRolePolicy)
  + [PutUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.PutUserPolicy)

------
#### [ Java ]

**SDK pour Java 2.x**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/iam#code-examples). 
Créez des fonctions qui encapsulent les actions de l’utilisateur IAM.  

```
/*
  To run this Java V2 code example, set up your development environment, including your credentials.

  For information, see this documentation topic:

  https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html

  This example performs these operations:

  1. Creates a user that has no permissions.
  2. Creates a role and policy that grants Amazon S3 permissions.
  3. Creates a role.
  4. Grants the user permissions.
  5. Gets temporary credentials by assuming the role.  Creates an Amazon S3 Service client object with the temporary credentials.
  6. Deletes the resources.
 */

public class IAMScenario {
    public static final String DASHES = new String(new char[80]).replace("\0", "-");
    public static final String PolicyDocument = "{" +
            "  \"Version\": \"2012-10-17\"," +
            "  \"Statement\": [" +
            "    {" +
            "        \"Effect\": \"Allow\"," +
            "        \"Action\": [" +
            "            \"s3:*\"" +
            "       ]," +
            "       \"Resource\": \"*\"" +
            "    }" +
            "   ]" +
            "}";

    public static String userArn;

    public static void main(String[] args) throws Exception {

        final String usage = """

                Usage:
                    <username> <policyName> <roleName> <roleSessionName> <bucketName>\s

                Where:
                    username - The name of the IAM user to create.\s
                    policyName - The name of the policy to create.\s
                    roleName - The name of the role to create.\s
                    roleSessionName - The name of the session required for the assumeRole operation.\s
                    bucketName - The name of the Amazon S3 bucket from which objects are read.\s
                """;

        if (args.length != 5) {
            System.out.println(usage);
            System.exit(1);
        }

        String userName = args[0];
        String policyName = args[1];
        String roleName = args[2];
        String roleSessionName = args[3];
        String bucketName = args[4];

        Region region = Region.AWS_GLOBAL;
        IamClient iam = IamClient.builder()
                .region(region)
                .build();

        System.out.println(DASHES);
        System.out.println("Welcome to the AWS IAM example scenario.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println(" 1. Create the IAM user.");
        User createUser = createIAMUser(iam, userName);

        System.out.println(DASHES);
        userArn = createUser.arn();

        AccessKey myKey = createIAMAccessKey(iam, userName);
        String accessKey = myKey.accessKeyId();
        String secretKey = myKey.secretAccessKey();
        String assumeRolePolicyDocument = "{" +
                "\"Version\": \"2012-10-17\"," +
                "\"Statement\": [{" +
                "\"Effect\": \"Allow\"," +
                "\"Principal\": {" +
                "	\"AWS\": \"" + userArn + "\"" +
                "}," +
                "\"Action\": \"sts:AssumeRole\"" +
                "}]" +
                "}";

        System.out.println(assumeRolePolicyDocument);
        System.out.println(userName + " was successfully created.");
        System.out.println(DASHES);
        System.out.println("2. Creates a policy.");
        String polArn = createIAMPolicy(iam, policyName);
        System.out.println("The policy " + polArn + " was successfully created.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("3. Creates a role.");
        TimeUnit.SECONDS.sleep(30);
        String roleArn = createIAMRole(iam, roleName, assumeRolePolicyDocument);
        System.out.println(roleArn + " was successfully created.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("4. Grants the user permissions.");
        attachIAMRolePolicy(iam, roleName, polArn);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("*** Wait for 30 secs so the resource is available");
        TimeUnit.SECONDS.sleep(30);
        System.out.println("5. Gets temporary credentials by assuming the role.");
        System.out.println("Perform an Amazon S3 Service operation using the temporary credentials.");
        assumeRole(roleArn, roleSessionName, bucketName, accessKey, secretKey);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("6 Getting ready to delete the AWS resources");
        deleteKey(iam, userName, accessKey);
        deleteRole(iam, roleName, polArn);
        deleteIAMUser(iam, userName);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("This IAM Scenario has successfully completed");
        System.out.println(DASHES);
    }

    public static AccessKey createIAMAccessKey(IamClient iam, String user) {
        try {
            CreateAccessKeyRequest request = CreateAccessKeyRequest.builder()
                    .userName(user)
                    .build();

            CreateAccessKeyResponse response = iam.createAccessKey(request);
            return response.accessKey();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return null;
    }

    public static User createIAMUser(IamClient iam, String username) {
        try {
            // Create an IamWaiter object
            IamWaiter iamWaiter = iam.waiter();
            CreateUserRequest request = CreateUserRequest.builder()
                    .userName(username)
                    .build();

            // Wait until the user is created.
            CreateUserResponse response = iam.createUser(request);
            GetUserRequest userRequest = GetUserRequest.builder()
                    .userName(response.user().userName())
                    .build();

            WaiterResponse<GetUserResponse> waitUntilUserExists = iamWaiter.waitUntilUserExists(userRequest);
            waitUntilUserExists.matched().response().ifPresent(System.out::println);
            return response.user();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return null;
    }

    public static String createIAMRole(IamClient iam, String rolename, String json) {

        try {
            CreateRoleRequest request = CreateRoleRequest.builder()
                    .roleName(rolename)
                    .assumeRolePolicyDocument(json)
                    .description("Created using the AWS SDK for Java")
                    .build();

            CreateRoleResponse response = iam.createRole(request);
            System.out.println("The ARN of the role is " + response.role().arn());
            return response.role().arn();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return "";
    }

    public static String createIAMPolicy(IamClient iam, String policyName) {
        try {
            // Create an IamWaiter object.
            IamWaiter iamWaiter = iam.waiter();
            CreatePolicyRequest request = CreatePolicyRequest.builder()
                    .policyName(policyName)
                    .policyDocument(PolicyDocument).build();

            CreatePolicyResponse response = iam.createPolicy(request);
            GetPolicyRequest polRequest = GetPolicyRequest.builder()
                    .policyArn(response.policy().arn())
                    .build();

            WaiterResponse<GetPolicyResponse> waitUntilPolicyExists = iamWaiter.waitUntilPolicyExists(polRequest);
            waitUntilPolicyExists.matched().response().ifPresent(System.out::println);
            return response.policy().arn();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return "";
    }

    public static void attachIAMRolePolicy(IamClient iam, String roleName, String policyArn) {
        try {
            ListAttachedRolePoliciesRequest request = ListAttachedRolePoliciesRequest.builder()
                    .roleName(roleName)
                    .build();

            ListAttachedRolePoliciesResponse response = iam.listAttachedRolePolicies(request);
            List<AttachedPolicy> attachedPolicies = response.attachedPolicies();
            String polArn;
            for (AttachedPolicy policy : attachedPolicies) {
                polArn = policy.policyArn();
                if (polArn.compareTo(policyArn) == 0) {
                    System.out.println(roleName + " policy is already attached to this role.");
                    return;
                }
            }

            AttachRolePolicyRequest attachRequest = AttachRolePolicyRequest.builder()
                    .roleName(roleName)
                    .policyArn(policyArn)
                    .build();

            iam.attachRolePolicy(attachRequest);
            System.out.println("Successfully attached policy " + policyArn + " to role " + roleName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    // Invoke an Amazon S3 operation using the Assumed Role.
    public static void assumeRole(String roleArn, String roleSessionName, String bucketName, String keyVal,
            String keySecret) {

        // Use the creds of the new IAM user that was created in this code example.
        AwsBasicCredentials credentials = AwsBasicCredentials.create(keyVal, keySecret);
        StsClient stsClient = StsClient.builder()
                .region(Region.US_EAST_1)
                .credentialsProvider(StaticCredentialsProvider.create(credentials))
                .build();

        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();
            String key = myCreds.accessKeyId();
            String secKey = myCreds.secretAccessKey();
            String secToken = myCreds.sessionToken();

            // List all objects in an Amazon S3 bucket using the temp creds retrieved by
            // invoking assumeRole.
            Region region = Region.US_EAST_1;
            S3Client s3 = S3Client.builder()
                    .credentialsProvider(
                            StaticCredentialsProvider.create(AwsSessionCredentials.create(key, secKey, secToken)))
                    .region(region)
                    .build();

            System.out.println("Created a S3Client using temp credentials.");
            System.out.println("Listing objects in " + bucketName);
            ListObjectsRequest listObjects = ListObjectsRequest.builder()
                    .bucket(bucketName)
                    .build();

            ListObjectsResponse res = s3.listObjects(listObjects);
            List<S3Object> objects = res.contents();
            for (S3Object myValue : objects) {
                System.out.println("The name of the key is " + myValue.key());
                System.out.println("The owner is " + myValue.owner());
            }

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }

    public static void deleteRole(IamClient iam, String roleName, String polArn) {

        try {
            // First the policy needs to be detached.
            DetachRolePolicyRequest rolePolicyRequest = DetachRolePolicyRequest.builder()
                    .policyArn(polArn)
                    .roleName(roleName)
                    .build();

            iam.detachRolePolicy(rolePolicyRequest);

            // Delete the policy.
            DeletePolicyRequest request = DeletePolicyRequest.builder()
                    .policyArn(polArn)
                    .build();

            iam.deletePolicy(request);
            System.out.println("*** Successfully deleted " + polArn);

            // Delete the role.
            DeleteRoleRequest roleRequest = DeleteRoleRequest.builder()
                    .roleName(roleName)
                    .build();

            iam.deleteRole(roleRequest);
            System.out.println("*** Successfully deleted " + roleName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    public static void deleteKey(IamClient iam, String username, String accessKey) {
        try {
            DeleteAccessKeyRequest request = DeleteAccessKeyRequest.builder()
                    .accessKeyId(accessKey)
                    .userName(username)
                    .build();

            iam.deleteAccessKey(request);
            System.out.println("Successfully deleted access key " + accessKey +
                    " from user " + username);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    public static void deleteIAMUser(IamClient iam, String userName) {
        try {
            DeleteUserRequest request = DeleteUserRequest.builder()
                    .userName(userName)
                    .build();

            iam.deleteUser(request);
            System.out.println("*** Successfully deleted " + userName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK for Java 2.x *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/PutUserPolicy)

------
#### [ JavaScript ]

**SDK pour JavaScript (v3)**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/iam#code-examples). 
Créer un utilisateur IAM et un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3. L’utilisateur n’a que le droit d’assumer le rôle. Après avoir assumé le rôle, utilisez des informations d’identification temporaires pour répertorier les compartiments pour le compte.  

```
import {
  CreateUserCommand,
  GetUserCommand,
  CreateAccessKeyCommand,
  CreatePolicyCommand,
  CreateRoleCommand,
  AttachRolePolicyCommand,
  DeleteAccessKeyCommand,
  DeleteUserCommand,
  DeleteRoleCommand,
  DeletePolicyCommand,
  DetachRolePolicyCommand,
  IAMClient,
} from "@aws-sdk/client-iam";
import { ListBucketsCommand, S3Client } from "@aws-sdk/client-s3";
import { AssumeRoleCommand, STSClient } from "@aws-sdk/client-sts";
import { retry } from "@aws-doc-sdk-examples/lib/utils/util-timers.js";
import { ScenarioInput } from "@aws-doc-sdk-examples/lib/scenario/index.js";

// Set the parameters.
const iamClient = new IAMClient({});
const userName = "iam_basic_test_username";
const policyName = "iam_basic_test_policy";
const roleName = "iam_basic_test_role";

/**
 * Create a new IAM user. If the user already exists, give
 * the option to delete and re-create it.
 * @param {string} name
 */
export const createUser = async (name, confirmAll = false) => {
  try {
    const { User } = await iamClient.send(
      new GetUserCommand({ UserName: name }),
    );
    const input = new ScenarioInput(
      "deleteUser",
      "Do you want to delete and remake this user?",
      { type: "confirm" },
    );
    const deleteUser = await input.handle({}, { confirmAll });
    // If the user exists, and you want to delete it, delete the user
    // and then create it again.
    if (deleteUser) {
      await iamClient.send(new DeleteUserCommand({ UserName: User.UserName }));
      await iamClient.send(new CreateUserCommand({ UserName: name }));
    } else {
      console.warn(
        `${name} already exists. The scenario may not work as expected.`,
      );
      return User;
    }
  } catch (caught) {
    // If there is no user by that name, create one.
    if (caught instanceof Error && caught.name === "NoSuchEntityException") {
      const { User } = await iamClient.send(
        new CreateUserCommand({ UserName: name }),
      );
      return User;
    }
    throw caught;
  }
};

export const main = async (confirmAll = false) => {
  // Create a user. The user has no permissions by default.
  const User = await createUser(userName, confirmAll);

  if (!User) {
    throw new Error("User not created");
  }

  // Create an access key. This key is used to authenticate the new user to
  // Amazon Simple Storage Service (Amazon S3) and AWS Security Token Service (AWS STS).
  // It's not best practice to use access keys. For more information, see https://aws.amazon.com/iam/resources/best-practices/.
  const createAccessKeyResponse = await iamClient.send(
    new CreateAccessKeyCommand({ UserName: userName }),
  );

  if (
    !createAccessKeyResponse.AccessKey?.AccessKeyId ||
    !createAccessKeyResponse.AccessKey?.SecretAccessKey
  ) {
    throw new Error("Access key not created");
  }

  const {
    AccessKey: { AccessKeyId, SecretAccessKey },
  } = createAccessKeyResponse;

  let s3Client = new S3Client({
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
    },
  });

  // Retry the list buckets operation until it succeeds. InvalidAccessKeyId is
  // thrown while the user and access keys are still stabilizing.
  await retry({ intervalInMs: 1000, maxRetries: 300 }, async () => {
    try {
      return await listBuckets(s3Client);
    } catch (err) {
      if (err instanceof Error && err.name === "InvalidAccessKeyId") {
        throw err;
      }
    }
  });

  // Retry the create role operation until it succeeds. A MalformedPolicyDocument error
  // is thrown while the user and access keys are still stabilizing.
  const { Role } = await retry(
    {
      intervalInMs: 2000,
      maxRetries: 60,
    },
    () =>
      iamClient.send(
        new CreateRoleCommand({
          AssumeRolePolicyDocument: JSON.stringify({
            Version: "2012-10-17",
            Statement: [
              {
                Effect: "Allow",
                Principal: {
                  // Allow the previously created user to assume this role.
                  AWS: User.Arn,
                },
                Action: "sts:AssumeRole",
              },
            ],
          }),
          RoleName: roleName,
        }),
      ),
  );

  if (!Role) {
    throw new Error("Role not created");
  }

  // Create a policy that allows the user to list S3 buckets.
  const { Policy: listBucketPolicy } = await iamClient.send(
    new CreatePolicyCommand({
      PolicyDocument: JSON.stringify({
        Version: "2012-10-17",
        Statement: [
          {
            Effect: "Allow",
            Action: ["s3:ListAllMyBuckets"],
            Resource: "*",
          },
        ],
      }),
      PolicyName: policyName,
    }),
  );

  if (!listBucketPolicy) {
    throw new Error("Policy not created");
  }

  // Attach the policy granting the 's3:ListAllMyBuckets' action to the role.
  await iamClient.send(
    new AttachRolePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
      RoleName: Role.RoleName,
    }),
  );

  // Assume the role.
  const stsClient = new STSClient({
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
    },
  });

  // Retry the assume role operation until it succeeds.
  const { Credentials } = await retry(
    { intervalInMs: 2000, maxRetries: 60 },
    () =>
      stsClient.send(
        new AssumeRoleCommand({
          RoleArn: Role.Arn,
          RoleSessionName: `iamBasicScenarioSession-${Math.floor(
            Math.random() * 1000000,
          )}`,
          DurationSeconds: 900,
        }),
      ),
  );

  if (!Credentials?.AccessKeyId || !Credentials?.SecretAccessKey) {
    throw new Error("Credentials not created");
  }

  s3Client = new S3Client({
    credentials: {
      accessKeyId: Credentials.AccessKeyId,
      secretAccessKey: Credentials.SecretAccessKey,
      sessionToken: Credentials.SessionToken,
    },
  });

  // List the S3 buckets again.
  // Retry the list buckets operation until it succeeds. AccessDenied might
  // be thrown while the role policy is still stabilizing.
  await retry({ intervalInMs: 2000, maxRetries: 120 }, () =>
    listBuckets(s3Client),
  );

  // Clean up.
  await iamClient.send(
    new DetachRolePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
      RoleName: Role.RoleName,
    }),
  );

  await iamClient.send(
    new DeletePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
    }),
  );

  await iamClient.send(
    new DeleteRoleCommand({
      RoleName: Role.RoleName,
    }),
  );

  await iamClient.send(
    new DeleteAccessKeyCommand({
      UserName: userName,
      AccessKeyId,
    }),
  );

  await iamClient.send(
    new DeleteUserCommand({
      UserName: userName,
    }),
  );
};

/**
 *
 * @param {S3Client} s3Client
 */
const listBuckets = async (s3Client) => {
  const { Buckets } = await s3Client.send(new ListBucketsCommand({}));

  if (!Buckets) {
    throw new Error("Buckets not listed");
  }

  console.log(Buckets.map((bucket) => bucket.Name).join("\n"));
};
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour JavaScript *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/AttachRolePolicyCommand)
  + [CreateAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateAccessKeyCommand)
  + [CreatePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreatePolicyCommand)
  + [CreateRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateRoleCommand)
  + [CreateUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateUserCommand)
  + [DeleteAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteAccessKeyCommand)
  + [DeletePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeletePolicyCommand)
  + [DeleteRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteRoleCommand)
  + [DeleteUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserCommand)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserPolicyCommand)
  + [DetachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DetachRolePolicyCommand)
  + [PutUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/PutUserPolicyCommand)

------
#### [ Kotlin ]

**SDK pour Kotlin**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin/services/iam#code-examples). 
Créez des fonctions qui encapsulent les actions de l’utilisateur IAM.  

```
suspend fun main(args: Array<String>) {
    val usage = """
    Usage:
        <username> <policyName> <roleName> <roleSessionName> <fileLocation> <bucketName> 

    Where:
        username - The name of the IAM user to create. 
        policyName - The name of the policy to create. 
        roleName - The name of the role to create. 
        roleSessionName - The name of the session required for the assumeRole operation. 
        fileLocation - The file location to the JSON required to create the role (see Readme). 
        bucketName - The name of the Amazon S3 bucket from which objects are read. 
    """

    if (args.size != 6) {
        println(usage)
        exitProcess(1)
    }

    val userName = args[0]
    val policyName = args[1]
    val roleName = args[2]
    val roleSessionName = args[3]
    val fileLocation = args[4]
    val bucketName = args[5]

    createUser(userName)
    println("$userName was successfully created.")

    val polArn = createPolicy(policyName)
    println("The policy $polArn was successfully created.")

    val roleArn = createRole(roleName, fileLocation)
    println("$roleArn was successfully created.")
    attachRolePolicy(roleName, polArn)

    println("*** Wait for 1 MIN so the resource is available.")
    delay(60000)
    assumeGivenRole(roleArn, roleSessionName, bucketName)

    println("*** Getting ready to delete the AWS resources.")
    deleteRole(roleName, polArn)
    deleteUser(userName)
    println("This IAM Scenario has successfully completed.")
}

suspend fun createUser(usernameVal: String?): String? {
    val request =
        CreateUserRequest {
            userName = usernameVal
        }

    IamClient { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createUser(request)
        return response.user?.userName
    }
}

suspend fun createPolicy(policyNameVal: String?): String {
    val policyDocumentValue = """
    {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:*"
                ],
                "Resource": "*"
            }
        ]
    }
    """.trimIndent()

    val request =
        CreatePolicyRequest {
            policyName = policyNameVal
            policyDocument = policyDocumentValue
        }

    IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createPolicy(request)
        return response.policy?.arn.toString()
    }
}

suspend fun createRole(
    rolenameVal: String?,
    fileLocation: String?,
): String? {
    val jsonObject = fileLocation?.let { readJsonSimpleDemo(it) } as JSONObject

    val request =
        CreateRoleRequest {
            roleName = rolenameVal
            assumeRolePolicyDocument = jsonObject.toJSONString()
            description = "Created using the AWS SDK for Kotlin"
        }

    IamClient { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createRole(request)
        return response.role?.arn
    }
}

suspend fun attachRolePolicy(
    roleNameVal: String,
    policyArnVal: String,
) {
    val request =
        ListAttachedRolePoliciesRequest {
            roleName = roleNameVal
        }

    IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.listAttachedRolePolicies(request)
        val attachedPolicies = response.attachedPolicies

        // Ensure that the policy is not attached to this role.
        val checkStatus: Int
        if (attachedPolicies != null) {
            checkStatus = checkMyList(attachedPolicies, policyArnVal)
            if (checkStatus == -1) {
                return
            }
        }

        val policyRequest =
            AttachRolePolicyRequest {
                roleName = roleNameVal
                policyArn = policyArnVal
            }
        iamClient.attachRolePolicy(policyRequest)
        println("Successfully attached policy $policyArnVal to role $roleNameVal")
    }
}

fun checkMyList(
    attachedPolicies: List<AttachedPolicy>,
    policyArnVal: String,
): Int {
    for (policy in attachedPolicies) {
        val polArn = policy.policyArn.toString()

        if (polArn.compareTo(policyArnVal) == 0) {
            println("The policy is already attached to this role.")
            return -1
        }
    }
    return 0
}

suspend fun assumeGivenRole(
    roleArnVal: String?,
    roleSessionNameVal: String?,
    bucketName: String,
) {
    val stsClient = StsClient.fromEnvironment { region = "us-east-1" }
    val roleRequest =
        AssumeRoleRequest {
            roleArn = roleArnVal
            roleSessionName = roleSessionNameVal
        }

    val roleResponse = stsClient.assumeRole(roleRequest)
    val myCreds = roleResponse.credentials
    val key = myCreds?.accessKeyId
    val secKey = myCreds?.secretAccessKey
    val secToken = myCreds?.sessionToken

    val staticCredentials = StaticCredentialsProvider {
        accessKeyId = key
        secretAccessKey = secKey
        sessionToken = secToken
    }

    // List all objects in an Amazon S3 bucket using the temp creds.
    val s3 = S3Client.fromEnvironment {
        region = "us-east-1"
        credentialsProvider = staticCredentials
    }

    println("Created a S3Client using temp credentials.")
    println("Listing objects in $bucketName")

    val listObjects =
        ListObjectsRequest {
            bucket = bucketName
        }

    val response = s3.listObjects(listObjects)
    response.contents?.forEach { myObject ->
        println("The name of the key is ${myObject.key}")
        println("The owner is ${myObject.owner}")
    }
}

suspend fun deleteRole(
    roleNameVal: String,
    polArn: String,
) {
    val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" }

    // First the policy needs to be detached.
    val rolePolicyRequest =
        DetachRolePolicyRequest {
            policyArn = polArn
            roleName = roleNameVal
        }

    iam.detachRolePolicy(rolePolicyRequest)

    // Delete the policy.
    val request =
        DeletePolicyRequest {
            policyArn = polArn
        }

    iam.deletePolicy(request)
    println("*** Successfully deleted $polArn")

    // Delete the role.
    val roleRequest =
        DeleteRoleRequest {
            roleName = roleNameVal
        }

    iam.deleteRole(roleRequest)
    println("*** Successfully deleted $roleNameVal")
}

suspend fun deleteUser(userNameVal: String) {
    val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" }
    val request =
        DeleteUserRequest {
            userName = userNameVal
        }

    iam.deleteUser(request)
    println("*** Successfully deleted $userNameVal")
}

@Throws(java.lang.Exception::class)
fun readJsonSimpleDemo(filename: String): Any? {
    val reader = FileReader(filename)
    val jsonParser = JSONParser()
    return jsonParser.parse(reader)
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Kotlin*.
  + [AttachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreatePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeletePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DetachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [PutUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)

------
#### [ PHP ]

**Kit SDK pour PHP**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php/example_code/iam#code-examples). 

```
namespace Iam\Basics;

require 'vendor/autoload.php';

use Aws\Credentials\Credentials;
use Aws\S3\Exception\S3Exception;
use Aws\S3\S3Client;
use Aws\Sts\StsClient;
use Iam\IAMService;

echo("\n");
echo("--------------------------------------\n");
print("Welcome to the IAM getting started demo using PHP!\n");
echo("--------------------------------------\n");

$uuid = uniqid();
$service = new IAMService();

$user = $service->createUser("iam_demo_user_$uuid");
echo "Created user with the arn: {$user['Arn']}\n";

$key = $service->createAccessKey($user['UserName']);
$assumeRolePolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Principal\": {\"AWS\": \"{$user['Arn']}\"},
                    \"Action\": \"sts:AssumeRole\"
                }]
            }";
$assumeRoleRole = $service->createRole("iam_demo_role_$uuid", $assumeRolePolicyDocument);
echo "Created role: {$assumeRoleRole['RoleName']}\n";

$listAllBucketsPolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]
}";
$listAllBucketsPolicy = $service->createPolicy("iam_demo_policy_$uuid", $listAllBucketsPolicyDocument);
echo "Created policy: {$listAllBucketsPolicy['PolicyName']}\n";

$service->attachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']);

$inlinePolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"{$assumeRoleRole['Arn']}\"}]
}";
$inlinePolicy = $service->createUserPolicy("iam_demo_inline_policy_$uuid", $inlinePolicyDocument, $user['UserName']);
//First, fail to list the buckets with the user
$credentials = new Credentials($key['AccessKeyId'], $key['SecretAccessKey']);
$s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]);
try {
    $s3Client->listBuckets([
    ]);
    echo "this should not run";
} catch (S3Exception $exception) {
    echo "successfully failed!\n";
}

$stsClient = new StsClient(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]);
sleep(10);
$assumedRole = $stsClient->assumeRole([
    'RoleArn' => $assumeRoleRole['Arn'],
    'RoleSessionName' => "DemoAssumeRoleSession_$uuid",
]);
$assumedCredentials = [
    'key' => $assumedRole['Credentials']['AccessKeyId'],
    'secret' => $assumedRole['Credentials']['SecretAccessKey'],
    'token' => $assumedRole['Credentials']['SessionToken'],
];
$s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $assumedCredentials]);
try {
    $s3Client->listBuckets([]);
    echo "this should now run!\n";
} catch (S3Exception $exception) {
    echo "this should now not fail\n";
}

$service->detachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']);
$deletePolicy = $service->deletePolicy($listAllBucketsPolicy['Arn']);
echo "Delete policy: {$listAllBucketsPolicy['PolicyName']}\n";
$deletedRole = $service->deleteRole($assumeRoleRole['Arn']);
echo "Deleted role: {$assumeRoleRole['RoleName']}\n";
$deletedKey = $service->deleteAccessKey($key['AccessKeyId'], $user['UserName']);
$deletedUser = $service->deleteUser($user['UserName']);
echo "Delete user: {$user['UserName']}\n";
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour PHP *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Python ]

**Kit SDK for Python (Boto3)**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/iam#code-examples). 
Créer un utilisateur IAM et un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3. L’utilisateur n’a que le droit d’assumer le rôle. Après avoir assumé le rôle, utilisez des informations d’identification temporaires pour répertorier les compartiments pour le compte.  

```
import json
import sys
import time
from uuid import uuid4

import boto3
from botocore.exceptions import ClientError


def progress_bar(seconds):
    """Shows a simple progress bar in the command window."""
    for _ in range(seconds):
        time.sleep(1)
        print(".", end="")
        sys.stdout.flush()
    print()


def setup(iam_resource):
    """
    Creates a new user with no permissions.
    Creates an access key pair for the user.
    Creates a role with a policy that lets the user assume the role.
    Creates a policy that allows listing Amazon S3 buckets.
    Attaches the policy to the role.
    Creates an inline policy for the user that lets the user assume the role.

    :param iam_resource: A Boto3 AWS Identity and Access Management (IAM) resource
                         that has permissions to create users, roles, and policies
                         in the account.
    :return: The newly created user, user key, and role.
    """
    try:
        user = iam_resource.create_user(UserName=f"demo-user-{uuid4()}")
        print(f"Created user {user.name}.")
    except ClientError as error:
        print(
            f"Couldn't create a user for the demo. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        user_key = user.create_access_key_pair()
        print(f"Created access key pair for user.")
    except ClientError as error:
        print(
            f"Couldn't create access keys for user {user.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    print(f"Wait for user to be ready.", end="")
    progress_bar(10)

    try:
        role = iam_resource.create_role(
            RoleName=f"demo-role-{uuid4()}",
            AssumeRolePolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Principal": {"AWS": user.arn},
                            "Action": "sts:AssumeRole",
                        }
                    ],
                }
            ),
        )
        print(f"Created role {role.name}.")
    except ClientError as error:
        print(
            f"Couldn't create a role for the demo. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        policy = iam_resource.create_policy(
            PolicyName=f"demo-policy-{uuid4()}",
            PolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Action": "s3:ListAllMyBuckets",
                            "Resource": "arn:aws:s3:::*",
                        }
                    ],
                }
            ),
        )
        role.attach_policy(PolicyArn=policy.arn)
        print(f"Created policy {policy.policy_name} and attached it to the role.")
    except ClientError as error:
        print(
            f"Couldn't create a policy and attach it to role {role.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        user.create_policy(
            PolicyName=f"demo-user-policy-{uuid4()}",
            PolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Action": "sts:AssumeRole",
                            "Resource": role.arn,
                        }
                    ],
                }
            ),
        )
        print(
            f"Created an inline policy for {user.name} that lets the user assume "
            f"the role."
        )
    except ClientError as error:
        print(
            f"Couldn't create an inline policy for user {user.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    print("Give AWS time to propagate these new resources and connections.", end="")
    progress_bar(10)

    return user, user_key, role


def show_access_denied_without_role(user_key):
    """
    Shows that listing buckets without first assuming the role is not allowed.

    :param user_key: The key of the user created during setup. This user does not
                     have permission to list buckets in the account.
    """
    print(f"Try to list buckets without first assuming the role.")
    s3_denied_resource = boto3.resource(
        "s3", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret
    )
    try:
        for bucket in s3_denied_resource.buckets.all():
            print(bucket.name)
        raise RuntimeError("Expected to get AccessDenied error when listing buckets!")
    except ClientError as error:
        if error.response["Error"]["Code"] == "AccessDenied":
            print("Attempt to list buckets with no permissions: AccessDenied.")
        else:
            raise


def list_buckets_from_assumed_role(user_key, assume_role_arn, session_name):
    """
    Assumes a role that grants permission to list the Amazon S3 buckets in the account.
    Uses the temporary credentials from the role to list the buckets that are owned
    by the assumed role's account.

    :param user_key: The access key of a user that has permission to assume the role.
    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    """
    sts_client = boto3.client(
        "sts", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret
    )
    try:
        response = sts_client.assume_role(
            RoleArn=assume_role_arn, RoleSessionName=session_name
        )
        temp_credentials = response["Credentials"]
        print(f"Assumed role {assume_role_arn} and got temporary credentials.")
    except ClientError as error:
        print(
            f"Couldn't assume role {assume_role_arn}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    # Create an S3 resource that can access the account with the temporary credentials.
    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )
    print(f"Listing buckets for the assumed role's account:")
    try:
        for bucket in s3_resource.buckets.all():
            print(bucket.name)
    except ClientError as error:
        print(
            f"Couldn't list buckets for the account. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise




def teardown(user, role):
    """
    Removes all resources created during setup.

    :param user: The demo user.
    :param role: The demo role.
    """
    try:
        for attached in role.attached_policies.all():
            policy_name = attached.policy_name
            role.detach_policy(PolicyArn=attached.arn)
            attached.delete()
            print(f"Detached and deleted {policy_name}.")
        role.delete()
        print(f"Deleted {role.name}.")
    except ClientError as error:
        print(
            "Couldn't detach policy, delete policy, or delete role. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        for user_pol in user.policies.all():
            user_pol.delete()
            print("Deleted inline user policy.")
        for key in user.access_keys.all():
            key.delete()
            print("Deleted user's access key.")
        user.delete()
        print(f"Deleted {user.name}.")
    except ClientError as error:
        print(
            "Couldn't delete user policy or delete user. Here's why: "
            f"{error.response['Error']['Message']}"
        )


def usage_demo():
    """Drives the demonstration."""
    print("-" * 88)
    print(f"Welcome to the IAM create user and assume role demo.")
    print("-" * 88)
    iam_resource = boto3.resource("iam")
    user = None
    role = None
    try:
        user, user_key, role = setup(iam_resource)
        print(f"Created {user.name} and {role.name}.")
        show_access_denied_without_role(user_key)
        list_buckets_from_assumed_role(user_key, role.arn, "AssumeRoleDemoSession")
    except Exception:
        print("Something went wrong!")
    finally:
        if user is not None and role is not None:
            teardown(user, role)
        print("Thanks for watching!")


if __name__ == "__main__":
    usage_demo()
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK for Python (Boto3)*.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/PutUserPolicy)

------
#### [ Ruby ]

**Kit SDK pour Ruby**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples). 
Créer un utilisateur IAM et un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3. L’utilisateur n’a que le droit d’assumer le rôle. Après avoir assumé le rôle, utilisez des informations d’identification temporaires pour répertorier les compartiments pour le compte.  

```
# Wraps the scenario actions.
class ScenarioCreateUserAssumeRole
  attr_reader :iam_client

  # @param [Aws::IAM::Client] iam_client: The AWS IAM client.
  def initialize(iam_client, logger: Logger.new($stdout))
    @iam_client = iam_client
    @logger = logger
  end

  # Waits for the specified number of seconds.
  #
  # @param duration [Integer] The number of seconds to wait.
  def wait(duration)
    puts('Give AWS time to propagate resources...')
    sleep(duration)
  end

  # Creates a user.
  #
  # @param user_name [String] The name to give the user.
  # @return [Aws::IAM::User] The newly created user.
  def create_user(user_name)
    user = @iam_client.create_user(user_name: user_name).user
    @logger.info("Created demo user named #{user.user_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info('Tried and failed to create demo user.')
    @logger.info("\t#{e.code}: #{e.message}")
    @logger.info("\nCan't continue the demo without a user!")
    raise
  else
    user
  end

  # Creates an access key for a user.
  #
  # @param user [Aws::IAM::User] The user that owns the key.
  # @return [Aws::IAM::AccessKeyPair] The newly created access key.
  def create_access_key_pair(user)
    user_key = @iam_client.create_access_key(user_name: user.user_name).access_key
    @logger.info("Created accesskey pair for user #{user.user_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create access keys for user #{user.user_name}.")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  else
    user_key
  end

  # Creates a role that can be assumed by a user.
  #
  # @param role_name [String] The name to give the role.
  # @param user [Aws::IAM::User] The user who is granted permission to assume the role.
  # @return [Aws::IAM::Role] The newly created role.
  def create_role(role_name, user)
    trust_policy = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Principal: { 'AWS': user.arn },
        Action: 'sts:AssumeRole'
      }]
    }.to_json
    role = @iam_client.create_role(
      role_name: role_name,
      assume_role_policy_document: trust_policy
    ).role
    @logger.info("Created role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create a role for the demo. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  else
    role
  end

  # Creates a policy that grants permission to list S3 buckets in the account, and
  # then attaches the policy to a role.
  #
  # @param policy_name [String] The name to give the policy.
  # @param role [Aws::IAM::Role] The role that the policy is attached to.
  # @return [Aws::IAM::Policy] The newly created policy.
  def create_and_attach_role_policy(policy_name, role)
    policy_document = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Action: 's3:ListAllMyBuckets',
        Resource: 'arn:aws:s3:::*'
      }]
    }.to_json
    policy = @iam_client.create_policy(
      policy_name: policy_name,
      policy_document: policy_document
    ).policy
    @iam_client.attach_role_policy(
      role_name: role.role_name,
      policy_arn: policy.arn
    )
    @logger.info("Created policy #{policy.policy_name} and attached it to role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create a policy and attach it to role #{role.role_name}. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Creates an inline policy for a user that lets the user assume a role.
  #
  # @param policy_name [String] The name to give the policy.
  # @param user [Aws::IAM::User] The user that owns the policy.
  # @param role [Aws::IAM::Role] The role that can be assumed.
  # @return [Aws::IAM::UserPolicy] The newly created policy.
  def create_user_policy(policy_name, user, role)
    policy_document = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Action: 'sts:AssumeRole',
        Resource: role.arn
      }]
    }.to_json
    @iam_client.put_user_policy(
      user_name: user.user_name,
      policy_name: policy_name,
      policy_document: policy_document
    )
    puts("Created an inline policy for #{user.user_name} that lets the user assume role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create an inline policy for user #{user.user_name}. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Creates an Amazon S3 resource with specified credentials. This is separated into a
  # factory function so that it can be mocked for unit testing.
  #
  # @param credentials [Aws::Credentials] The credentials used by the Amazon S3 resource.
  def create_s3_resource(credentials)
    Aws::S3::Resource.new(client: Aws::S3::Client.new(credentials: credentials))
  end

  # Lists the S3 buckets for the account, using the specified Amazon S3 resource.
  # Because the resource uses credentials with limited access, it may not be able to
  # list the S3 buckets.
  #
  # @param s3_resource [Aws::S3::Resource] An Amazon S3 resource.
  def list_buckets(s3_resource)
    count = 10
    s3_resource.buckets.each do |bucket|
      @logger.info "\t#{bucket.name}"
      count -= 1
      break if count.zero?
    end
  rescue Aws::Errors::ServiceError => e
    if e.code == 'AccessDenied'
      puts('Attempt to list buckets with no permissions: AccessDenied.')
    else
      @logger.info("Couldn't list buckets for the account. Here's why: ")
      @logger.info("\t#{e.code}: #{e.message}")
      raise
    end
  end

  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end

  # Deletes a role. If the role has policies attached, they are detached and
  # deleted before the role is deleted.
  #
  # @param role_name [String] The name of the role to delete.
  def delete_role(role_name)
    @iam_client.list_attached_role_policies(role_name: role_name).attached_policies.each do |policy|
      @iam_client.detach_role_policy(role_name: role_name, policy_arn: policy.policy_arn)
      @iam_client.delete_policy(policy_arn: policy.policy_arn)
      @logger.info("Detached and deleted policy #{policy.policy_name}.")
    end
    @iam_client.delete_role({ role_name: role_name })
    @logger.info("Role deleted: #{role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't detach policies and delete role #{role.name}. Here's why:")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Deletes a user. If the user has inline policies or access keys, they are deleted
  # before the user is deleted.
  #
  # @param user [Aws::IAM::User] The user to delete.
  def delete_user(user_name)
    user = @iam_client.list_access_keys(user_name: user_name).access_key_metadata
    user.each do |key|
      @iam_client.delete_access_key({ access_key_id: key.access_key_id, user_name: user_name })
      @logger.info("Deleted access key #{key.access_key_id} for user '#{user_name}'.")
    end

    @iam_client.delete_user(user_name: user_name)
    @logger.info("Deleted user '#{user_name}'.")
  rescue Aws::IAM::Errors::ServiceError => e
    @logger.error("Error deleting user '#{user_name}': #{e.message}")
  end
end

# Runs the IAM create a user and assume a role scenario.
def run_scenario(scenario)
  puts('-' * 88)
  puts('Welcome to the IAM create a user and assume a role demo!')
  puts('-' * 88)
  user = scenario.create_user("doc-example-user-#{Random.uuid}")
  user_key = scenario.create_access_key_pair(user)
  scenario.wait(10)
  role = scenario.create_role("doc-example-role-#{Random.uuid}", user)
  scenario.create_and_attach_role_policy("doc-example-role-policy-#{Random.uuid}", role)
  scenario.create_user_policy("doc-example-user-policy-#{Random.uuid}", user, role)
  scenario.wait(10)
  puts('Try to list buckets with credentials for a user who has no permissions.')
  puts('Expect AccessDenied from this call.')
  scenario.list_buckets(
    scenario.create_s3_resource(Aws::Credentials.new(user_key.access_key_id, user_key.secret_access_key))
  )
  puts('Now, assume the role that grants permission.')
  temp_credentials = scenario.assume_role(
    role.arn, scenario.create_sts_client(user_key.access_key_id, user_key.secret_access_key)
  )
  puts('Here are your buckets:')
  scenario.list_buckets(scenario.create_s3_resource(temp_credentials))
  puts("Deleting role '#{role.role_name}' and attached policies.")
  scenario.delete_role(role.role_name)
  puts("Deleting user '#{user.user_name}', policies, and keys.")
  scenario.delete_user(user.user_name)
  puts('Thanks for watching!')
  puts('-' * 88)
rescue Aws::Errors::ServiceError => e
  puts('Something went wrong with the demo.')
  puts("\t#{e.code}: #{e.message}")
end

run_scenario(ScenarioCreateUserAssumeRole.new(Aws::IAM::Client.new)) if $PROGRAM_NAME == __FILE__
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Ruby *.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Rust ]

**SDK pour Rust**  
 Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/iam#code-examples). 

```
use aws_config::meta::region::RegionProviderChain;
use aws_sdk_iam::Error as iamError;
use aws_sdk_iam::{config::Credentials as iamCredentials, config::Region, Client as iamClient};
use aws_sdk_s3::Client as s3Client;
use aws_sdk_sts::Client as stsClient;
use tokio::time::{sleep, Duration};
use uuid::Uuid;

#[tokio::main]
async fn main() -> Result<(), iamError> {
    let (client, uuid, list_all_buckets_policy_document, inline_policy_document) =
        initialize_variables().await;

    if let Err(e) = run_iam_operations(
        client,
        uuid,
        list_all_buckets_policy_document,
        inline_policy_document,
    )
    .await
    {
        println!("{:?}", e);
    };

    Ok(())
}

async fn initialize_variables() -> (iamClient, String, String, String) {
    let region_provider = RegionProviderChain::first_try(Region::new("us-west-2"));

    let shared_config = aws_config::from_env().region(region_provider).load().await;
    let client = iamClient::new(&shared_config);
    let uuid = Uuid::new_v4().to_string();

    let list_all_buckets_policy_document = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]
    }"
    .to_string();
    let inline_policy_document = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"{}\"}]
    }"
    .to_string();

    (
        client,
        uuid,
        list_all_buckets_policy_document,
        inline_policy_document,
    )
}

async fn run_iam_operations(
    client: iamClient,
    uuid: String,
    list_all_buckets_policy_document: String,
    inline_policy_document: String,
) -> Result<(), iamError> {
    let user = iam_service::create_user(&client, &format!("{}{}", "iam_demo_user_", uuid)).await?;
    println!("Created the user with the name: {}", user.user_name());
    let key = iam_service::create_access_key(&client, user.user_name()).await?;

    let assume_role_policy_document = "{
        \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Principal\": {\"AWS\": \"{}\"},
                    \"Action\": \"sts:AssumeRole\"
                }]
            }"
    .to_string()
    .replace("{}", user.arn());

    let assume_role_role = iam_service::create_role(
        &client,
        &format!("{}{}", "iam_demo_role_", uuid),
        &assume_role_policy_document,
    )
    .await?;
    println!("Created the role with the ARN: {}", assume_role_role.arn());

    let list_all_buckets_policy = iam_service::create_policy(
        &client,
        &format!("{}{}", "iam_demo_policy_", uuid),
        &list_all_buckets_policy_document,
    )
    .await?;
    println!(
        "Created policy: {}",
        list_all_buckets_policy.policy_name.as_ref().unwrap()
    );

    let attach_role_policy_result =
        iam_service::attach_role_policy(&client, &assume_role_role, &list_all_buckets_policy)
            .await?;
    println!(
        "Attached the policy to the role: {:?}",
        attach_role_policy_result
    );

    let inline_policy_name = format!("{}{}", "iam_demo_inline_policy_", uuid);
    let inline_policy_document = inline_policy_document.replace("{}", assume_role_role.arn());
    iam_service::create_user_policy(&client, &user, &inline_policy_name, &inline_policy_document)
        .await?;
    println!("Created inline policy.");

    //First, fail to list the buckets with the user.
    let creds = iamCredentials::from_keys(key.access_key_id(), key.secret_access_key(), None);
    let fail_config = aws_config::from_env()
        .credentials_provider(creds.clone())
        .load()
        .await;
    println!("Fail config: {:?}", fail_config);
    let fail_client: s3Client = s3Client::new(&fail_config);
    match fail_client.list_buckets().send().await {
        Ok(e) => {
            println!("This should not run. {:?}", e);
        }
        Err(e) => {
            println!("Successfully failed with error: {:?}", e)
        }
    }

    let sts_config = aws_config::from_env()
        .credentials_provider(creds.clone())
        .load()
        .await;
    let sts_client: stsClient = stsClient::new(&sts_config);
    sleep(Duration::from_secs(10)).await;
    let assumed_role = sts_client
        .assume_role()
        .role_arn(assume_role_role.arn())
        .role_session_name(format!("iam_demo_assumerole_session_{uuid}"))
        .send()
        .await;
    println!("Assumed role: {:?}", assumed_role);
    sleep(Duration::from_secs(10)).await;

    let assumed_credentials = iamCredentials::from_keys(
        assumed_role
            .as_ref()
            .unwrap()
            .credentials
            .as_ref()
            .unwrap()
            .access_key_id(),
        assumed_role
            .as_ref()
            .unwrap()
            .credentials
            .as_ref()
            .unwrap()
            .secret_access_key(),
        Some(
            assumed_role
                .as_ref()
                .unwrap()
                .credentials
                .as_ref()
                .unwrap()
                .session_token
                .clone(),
        ),
    );

    let succeed_config = aws_config::from_env()
        .credentials_provider(assumed_credentials)
        .load()
        .await;
    println!("succeed config: {:?}", succeed_config);
    let succeed_client: s3Client = s3Client::new(&succeed_config);
    sleep(Duration::from_secs(10)).await;
    match succeed_client.list_buckets().send().await {
        Ok(_) => {
            println!("This should now run successfully.")
        }
        Err(e) => {
            println!("This should not run. {:?}", e);
            panic!()
        }
    }

    //Clean up.
    iam_service::detach_role_policy(
        &client,
        assume_role_role.role_name(),
        list_all_buckets_policy.arn().unwrap_or_default(),
    )
    .await?;
    iam_service::delete_policy(&client, list_all_buckets_policy).await?;
    iam_service::delete_role(&client, &assume_role_role).await?;
    println!("Deleted role {}", assume_role_role.role_name());
    iam_service::delete_access_key(&client, &user, &key).await?;
    println!("Deleted key for {}", key.user_name());
    iam_service::delete_user_policy(&client, &user, &inline_policy_name).await?;
    println!("Deleted inline user policy: {}", inline_policy_name);
    iam_service::delete_user(&client, &user).await?;
    println!("Deleted user {}", user.user_name());

    Ok(())
}
```
+ Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Rust*.
  + [AttachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.attach_role_policy)
  + [CreateAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_access_key)
  + [CreatePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_policy)
  + [CreateRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_role)
  + [CreateUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_user)
  + [DeleteAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_access_key)
  + [DeletePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_policy)
  + [DeleteRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_role)
  + [DeleteUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user)
  + [DeleteUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user_policy)
  + [DetachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.detach_role_policy)
  + [PutUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.put_user_policy)

------

# Utilisation d’un rôle IAM pour accorder des autorisations à des applications s’exécutant sur des instances Amazon EC2
<a name="id_roles_use_switch-role-ec2"></a>

Les applications qui s'exécutent sur une instance Amazon EC2 doivent inclure des AWS informations d'identification dans les demandes d' AWS API. Vous pouvez demander à vos développeurs de stocker les AWS informations d'identification directement dans l'instance Amazon EC2 et d'autoriser les applications de cette instance à utiliser ces informations d'identification. Toutefois, dans ce cas, ils doivent gérer les informations d'identification, les transmettre en toute sécurité à chaque instance, puis mettre à jour chaque instance Amazon EC2 lorsqu'il convient d'effectuer une mise à jour des informations d'identification. Ceci représente beaucoup de travail supplémentaire.

Au lieu de cela, il est recommandé d'utiliser un rôle IAM pour gérer les informations d'identification *temporaires* pour les applications qui s'exécutent sur une instance Amazon EC2. Lorsque vous utilisez un rôle, vous n'avez pas besoin de distribuer d'informations d'identification à long terme (telles que des informations de connexion ou des clés d'accès) à une instance Amazon EC2. Le rôle fournit plutôt des autorisations temporaires que les applications peuvent utiliser lorsqu'elles appellent d'autres AWS ressources. Lorsque vous lancez une instance Amazon EC2, vous spécifiez un rôle IAM à associer à celle-ci. Les applications qui s'exécutent sur l'instance peuvent ensuite utiliser les informations d'identification de sécurité temporaires fournies pour le rôle pour signer les demandes d'API.

L'utilisation de rôles pour l'octroi d'autorisations à des applications qui s'exécutent sur des instances Amazon EC2 requiert une configuration supplémentaire. Une application exécutée sur une instance Amazon EC2 est extraite du système AWS d'exploitation virtualisé. En raison de cette séparation supplémentaire, vous avez besoin d'une étape supplémentaire pour attribuer un AWS rôle et les autorisations associées à une instance Amazon EC2 et les mettre à la disposition de ses applications. Cette étape supplémentaire est la création d'un *[profil d'instance](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)* attaché à l'instance. Le profil d'instance contient le rôle et peut fournir les informations d'identification temporaires du rôle à une application qui s'exécute sur l'instance. Ces informations d'identification temporaires peuvent ensuite être utilisées dans les appels d'API de l'application pour accéder aux ressources et restreindre l'accès aux ressources spécifiées par le rôle uniquement.

**Note**  
Chaque instance Amazon EC2 ne peut se voir attribuer qu'un seul rôle à la fois, et toutes les applications de l'instance partagent le même rôle et les mêmes autorisations. Lorsque vous exploitez Amazon ECS pour gérer vos instances Amazon EC2, vous pouvez attribuer des rôles aux tâches Amazon ECS qui peuvent être différenciés du rôle de l'instance Amazon EC2 sur laquelle elles s'exécutent. L'attribution d'un rôle à chaque tâche est conforme au principe de l'accès au moindre privilège et permet un contrôle plus précis des actions et des ressources.  
Pour plus d'informations, veuillez consulter la rubrique [Using IAM roles with Amazon ECS tasks](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-iam-roles.html) dans le *Guide des bonnes pratiques pour Amazon Elastic Container Service*.

Une telle utilisation des rôles présente plusieurs avantages. Dans la mesure où les informations d'identification des rôles sont temporaires et font automatiquement l'objet d'une mise à jour, vous n'avez pas à les gérer ni à vous soucier de risques de sécurité à long terme. Par ailleurs, si vous utilisez le même rôle pour plusieurs instances, toute modification apportée au rôle se propage automatiquement à toutes les instances. 

**Note**  
Même si un rôle est généralement attribué à une instance Amazon EC2 lors du lancement, un rôle peut également être attaché à une instance Amazon EC2 en cours d'exécution. Pour savoir comment attacher un rôle à une instance en cours d'exécution, consultez [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role).

**Topics**
+ [Comment fonctionnent les rôles pour les instances Amazon EC2 ?](#roles-usingrole-ec2instance-roles)
+ [Autorisations requises pour l'utilisation de rôles avec Amazon EC2](#roles-usingrole-ec2instance-permissions)
+ [Comment puis-je commencer ?](#roles-usingrole-ec2instance-get-started)
+ [Informations connexes](#roles-usingrole-ec2instance-related-info)

## Comment fonctionnent les rôles pour les instances Amazon EC2 ?
<a name="roles-usingrole-ec2instance-roles"></a>

Dans l'illustration suivante, un développeur exécute une application sur une instance Amazon EC2 qui requiert l'accès à un compartiment S3 nommé `amzn-s3-demo-bucket-photos`. Un administrateur crée la fonction du service `Get-pics` et attache le rôle à l'instance Amazon EC2. Le rôle inclut une politique d'autorisations qui accorde un accès en lecture seule au compartiment S3 spécifié. Il inclut également une politique d'approbation qui permet à l'instance Amazon EC2 d'endosser le rôle et de récupérer les informations d'identification temporaires. Lorsque l'application s'exécute sur l'instance, elle peut accéder au compartiment photos en utilisant les informations d'identification temporaires du rôle. L'administrateur n'a pas besoin d'accorder au développeur l'autorisation d'accéder au compartiment photos et le développeur n'a à aucun moment besoin de partager ou gérer les informations d'identification.

![\[Application sur une instance Amazon EC2 accédant à une ressource AWS\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-usingrole-ec2roleinstance.png)


1. L'administrateur utilise IAM pour créer le rôle **Get-pics**. Dans la politique d'approbation du rôle, l'administrateur spécifie que seules les instances Amazon EC2 peuvent endosser le rôle. Dans la politique d'autorisation du rôle, l'administrateur définit des autorisations en lecture seule pour le compartiment `amzn-s3-demo-bucket-photos`.

1. Un développeur lance une instance Amazon EC2 et lui affecte le rôle `Get-pics`.
**Note**  
Si vous utilisez la console IAM, le profil d'instance est géré de manière quasiment transparente pour vous. Toutefois, si vous utilisez l'API AWS CLI or pour créer et gérer le rôle et l'instance Amazon EC2, vous devez créer le profil d'instance et lui attribuer le rôle séparément. Ensuite, lorsque vous lancez l'instance, vous devez spécifier le nom du profil d'instance à la place du nom de rôle.

1. Lorsque l'application est en cours d'exécution, elle obtient des informations d'identification de sécurité temporaires à partir des [métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) Amazon EC2, comme décrit dans [Extraction des informations d'identification de sécurité à partir des métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials). Il s'agit d'[informations d'identification de sécurité temporaires](id_credentials_temp.md) qui représentent le rôle et sont valides pendant une période limitée. 

   Dans certains cas [AWS SDKs](https://aws.amazon.com/tools/), le développeur peut utiliser un fournisseur qui gère les informations d'identification de sécurité temporaires de manière transparente. (La documentation individuelle AWS SDKs décrit les fonctionnalités prises en charge par ce SDK pour la gestion des informations d'identification.)

   Sinon, l'application peut obtenir les informations d'identification temporaires directement à partir des métadonnées d'instance de l'instance Amazon EC2. Les informations d'identification et les valeurs associées se trouvent dans la catégorie `iam/security-credentials/role-name` (dans cet exemple, `iam/security-credentials/Get-pics`) des métadonnées. Si l'application extrait les informations d'identification des métadonnées de l'instance, elle peut les mettre en cache.

1. À l'aide des informations d'identification temporaires obtenues, l'application peut accéder au compartiment photos. Compte tenu de la politique attachée au rôle **Get-pics**, l'application dispose d'autorisations en lecture seule. 

   Les informations d'identification de sécurité temporaires disponibles sur l'instance font automatiquement l'objet d'une mise à jour avant leur expiration, de manière à ce qu'un jeu d'identifiants valide soit toujours disponible. L'application doit simplement obtenir un nouvel ensemble d'informations d'identification à partir des métadonnées de l'instance avant l'expiration des informations d'identification actuelles. Il est possible d'utiliser le AWS SDK pour gérer les informations d'identification afin que l'application n'ait pas besoin d'inclure de logique supplémentaire pour actualiser les informations d'identification. Par exemple, instanciation de clients avec les fournisseurs d'informations d'identification de profil d'instance. En revanche, si l'application extrait les informations d'identification de sécurité temporaires des métadonnées d'instance, puis les met en cache, elle doit obtenir un ensemble d'informations d'identification actualisé toutes les heures, ou au moins 15 minutes avant l'expiration des informations d'identification actuelles. Le délai d'expiration est inclus dans les informations renvoyées dans la catégorie `iam/security-credentials/role-name`. 

## Autorisations requises pour l'utilisation de rôles avec Amazon EC2
<a name="roles-usingrole-ec2instance-permissions"></a>

Pour lancer une instance avec un rôle, le développeur doit avoir l'autorisation de lancer des instances Amazon EC2 et de transmettre des rôles IAM.

L'exemple de politique suivant permet aux utilisateurs d'utiliser le AWS Management Console pour lancer une instance avec un rôle. La politique inclut des caractères génériques (`*`) pour autoriser un utilisateur à transmettre n'importe quel rôle et à réaliser les actions Amazon EC2 énumérées. L'action `ListInstanceProfiles` permet aux utilisateurs d'afficher tous les rôles disponibles dans l' Compte AWS.

**Example Exemple de politique qui autorise les utilisateurs à lancer une instance avec n'importe quel rôle à l'aide de la console Amazon EC2**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "IamPassRole",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        },
        {
            "Sid": "ListEc2AndListInstanceProfiles",
            "Effect": "Allow",
            "Action": [
                "iam:ListInstanceProfiles",
                "ec2:Describe*",
                "ec2:Search*",
                "ec2:Get*"
            ],
            "Resource": "*"
        }
    ]
}
```

### Restreindre les rôles pouvant être transmis aux instances Amazon EC2 (en utilisant) PassRole
<a name="roles-usingrole-ec2instance-passrole"></a>

Vous pouvez utiliser l'autorisation `PassRole` pour spécifier les rôles qu'un utilisateur peut transmettre à une instance Amazon EC2 lors de son lancement. Cela évite que l'utilisateur exécute des applications ayant davantage d'autorisations qu'il n'en possède, autrement dit qu'il soit en mesure d'obtenir des droits élevés. Par exemple, supposons qu'une utilisatrice nommée Alice soit uniquement autorisée à lancer des instances Amazon EC2 et à utiliser des compartiments Amazon S3, mais que le rôle qu'elle transmet à une instance Amazon EC2 dispose d'autorisations permettant d'utiliser IAM et Amazon DynamoDB. Dans ce cas, il est possible qu'Alice soit en mesure de lancer l'instance, de s'y connecter, d'obtenir des informations d'identification de sécurité temporaires, puis d'effectuer plus d'actions IAM ou DynamoDB qu'elle n'est autorisée à le faire.

Pour limiter les rôles qu'un utilisateur peut transmettre à une instance Amazon EC2, vous pouvez créer une politique qui autorise l'action `PassRole`. Ensuite, vous attachez la politique à l'utilisateur (ou à un groupe IAM auquel il appartient) qui lancera les instances Amazon EC2. Dans l'élément `Resource` de la politique, vous répertoriez les rôles que l'utilisateur peut transmettre aux instances Amazon EC2. Lorsque l'utilisateur lance une instance et lui associe un rôle, Amazon EC2 vérifie si l'utilisateur est autorisé à transmettre ce rôle. Il est entendu que vous devez également vous assurer que le rôle que l'utilisateur est autorisé à transmettre n'inclut pas plus d'autorisations qu'il n'est censé en avoir.

**Note**  
L'action d'API `PassRole` est différente de `RunInstances` ou `ListInstanceProfiles`. Il s'agit plutôt d'une autorisation qui AWS vérifie chaque fois qu'un ARN de rôle est transmis en tant que paramètre à une API (ou que la console le fait au nom de l'utilisateur). Elle permet à un administrateur de contrôler les rôles susceptibles d'être transmis et par quels utilisateurs. Dans le cas présent, elle veille à ce que l'utilisateur soit autorisé à attacher un rôle spécifique à une instance Amazon EC2.

**Example Exemple de politique qui autorise un utilisateur à lancer une instance Amazon EC2 avec un rôle spécifique**  
Dans l'exemple suivant, la politique autorise les utilisateurs à lancer une instance avec un rôle à l'aide de l'API Amazon EC2. L'élément `Resource` spécifie l'Amazon Resource Name (ARN) d'un rôle. En spécifiant l'ARN, la politique accorde à l'utilisateur l'autorisation de transmettre uniquement le rôle `Get-pics`. Si l'utilisateur tente de spécifier un autre rôle lors du lancement d'une instance, l'action échoue. L'utilisateur est autorisé à exécuter n'importe quelle instance, qu'il s'agisse de transmettre un rôle ou non.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:RunInstances",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::111122223333:role/Get-pics"
        }
    ]
}
```

### Permettre à un rôle de profil d'instance de passer à un rôle dans un autre compte
<a name="switch-role-ec2-another-account"></a>

Vous pouvez permettre à une application qui s'exécute sur une instance Amazon EC2 d'exécuter des commandes dans un autre compte. Pour ce faire, vous devez autoriser le rôle d'instance Amazon EC2 dans le premier compte pour passer à un rôle dans le second compte.

Imaginons que vous en utilisiez deux Comptes AWS et que vous souhaitiez autoriser une application exécutée sur une instance Amazon EC2 à exécuter des [AWS CLI](https://aws.amazon.com/cli/)commandes dans les deux comptes. Supposons que l'instance Amazon EC2 existe dans le compte `111111111111`. Cette instance inclut le rôle de profil d'instance `abcd` qui permet à l'appli d'effectuer les tâches Amazon S3 `amzn-s3-demo-bucket1` en lecture seule sur le compartiment dans le même compte `111111111111`. Toutefois, l'application doit également être autorisée à endosser le rôle `efgh` entre comptes pour accéder au compartiment `amzn-s3-demo-bucket2` Amazon S3 dans le compte `222222222222`.

![\[Le schéma montre comment un développeur lance une instance Amazon EC2 dont le rôle est d’accéder aux photos d’un compartiment Amazon S3.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-instance-profile-cross-account.png)


Le rôle de profil d'instance Amazon EC2 `abcd` doit disposer des autorisations suivantes pour autoriser l'application à accéder au compartiment Amazon S3 `amzn-s3-demo-bucket1` :

***Politique d'autorisations de rôle `abcd` du compte 111111111111***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

Le rôle `abcd` doit faire confiance au service Amazon EC2 pour endosser le rôle. Pour ce faire, le rôle `abcd` doit avoir la politique de confiance suivante :

***Politique de confiance de rôle `abcd` du compte 111111111111***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "abcdTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"Service": "ec2.amazonaws.com"}
        }
    ]
}
```

------

Supposons que le rôle `efgh` entre comptes permet aux tâches Amazon S3 en lecture seule sur le compartiment `amzn-s3-demo-bucket2` dans le même compte `222222222222`. Pour ce faire, le rôle `efgh` entre comptes doit avoir la politique d'autorisations suivante :

***Politique d'autorisations de rôle `efgh` du compte 222222222222***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

Le rôle `efgh` doit autoriser le rôle de profil d'instance `abcd` à l'endosser. Pour ce faire, le rôle `efgh` doit avoir la politique de confiance suivante :

***Politique de confiance de rôle `efgh` du compte 222222222222***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

## Comment puis-je commencer ?
<a name="roles-usingrole-ec2instance-get-started"></a>

Pour comprendre le fonctionnement des rôles avec les instances Amazon EC2, vous devez utiliser la console IAM pour créer un rôle, lancer une instance Amazon EC2 utilisant ce rôle, puis examiner l'instance en cours d'exécution. Vous pouvez examiner les [métadonnées de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) pour voir comment les informations d'identification temporaires du rôle sont mises à la disposition d'une instance. Il est également possible d'étudier la façon dont une application exécutée sur l'instance peut utiliser un rôle donné. Consultez les ressources suivantes pour en savoir plus. 
+ [Didacticiel des rôles IAM sur les instances Amazon EC2](https://www.youtube.com/watch?v=TlCuOjviOhk). Cette vidéo montre comment utiliser un rôle IAM avec une instance Amazon EC2 pour contrôler ce qu'une application peut faire lorsqu'elle est exécutée sur l'instance. La vidéo montre comment l'application (écrite dans le AWS SDK) peut obtenir des informations d'identification de sécurité temporaires via le rôle. 
+ Procédures SDK. La documentation du AWS SDK inclut des procédures pas à pas qui montrent une application exécutée sur une instance Amazon EC2 qui utilise des informations d'identification temporaires pour les rôles afin de lire un compartiment Amazon S3. Chacune des procédures suivantes comporte des étapes similaires, avec un langage de programmation différent :
  + [Configuration de rôles IAM pour Amazon EC2 avec le kit SDK for Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) dans le *Manuel du développeur AWS SDK pour Java * 
  + [Lancer une instance Amazon EC2 à l'aide du kit SDK pour .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/run-instance.html) dans le *Manuel du développeur AWS SDK pour .NET *
  + [Création d'une instance Amazon EC2 avec le kit SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ec2-example-create-instance.html) dans le *Manuel du développeur AWS SDK pour Ruby *

## Informations connexes
<a name="roles-usingrole-ec2instance-related-info"></a>

Pour en savoir plus sur la création de rôles pour des instances Amazon EC2, consultez les informations suivantes :
+ Pour de plus amples informations sur l’[utilisation de rôles IAM avec des instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), accédez au *Guide de l’utilisateur Amazon EC2*.
+ Pour créer un rôle, consultez [Création d’un rôle IAM](id_roles_create.md)
+ Pour plus d'informations sur l'utilisation d'informations d'identification de sécurité temporaires, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md).
+ Si vous utilisez l'API ou l'interface de ligne de commande (CLI) IAM vous devez créer et gérer les profils d'instance IAM. Pour plus d'informations sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md).
+ Pour plus d’informations sur les informations d’identification de sécurité temporaires pour les rôles dans les métadonnées d’instance, consultez [Extraction des informations d’identification de sécurité à partir des métadonnées d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials) dans le *Guide de l’utilisateur Amazon EC2*.

# Utilisation des profils d’instance
<a name="id_roles_use_switch-role-ec2_instance-profiles"></a>

Utilisez un profil d'instance pour transmettre un rôle IAM à une instance EC2. Pour de plus amples informations sur les rôles IAM, consultez [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) dans le *Guide de l’utilisateur Amazon EC2*.

## Gestion de profils d'instance (console)
<a name="instance-profiles-manage-console"></a>

Si vous utilisez le AWS Management Console pour créer un rôle pour Amazon EC2, la console crée automatiquement un profil d'instance et lui donne le même nom que le rôle. Lorsque vous utilisez ensuite la console Amazon EC2 pour lancer une instance avec un rôle IAM, vous pouvez sélectionner un rôle à associer à l'instance. Sur la console, la liste qui s'affiche est une liste de noms de profils d'instance. La console ne crée pas de profil d'instance pour un rôle qui n'est pas associé à Amazon EC2.

Vous pouvez utiliser le AWS Management Console pour supprimer des rôles IAM et des profils d'instance pour Amazon EC2 si le rôle et le profil d'instance portent le même nom. Pour en savoir plus sur la suppression de profils d'instance, veuillez consulter [Suppression de rôles ou de profils d’instance](id_roles_manage_delete.md).

**Note**  
Pour mettre à jour les autorisations d’une instance, remplacez son profil d’instance. Nous vous déconseillons de supprimer un rôle d’un profil d’instance, car cette modification peut prendre jusqu’à une heure avant de prendre effet.

## Gestion des profils d'instance (AWS CLI ou AWS API)
<a name="instance-profiles-manage-cli-api"></a>

Si vous gérez vos rôles à partir de l'API AWS CLI ou de l' AWS API, vous créez des rôles et des profils d'instance en tant qu'actions distinctes. Étant donné que les rôles et les profils d'instance peuvent porter des noms différents, vous devez connaître les noms de vos profils d'instance, ainsi que ceux des rôles qu'ils contiennent. De cette façon, vous pouvez choisir le profil d'instance correct lorsque vous lancez une instance EC2. 

Vous pouvez attacher des balises à vos ressources IAM, y compris les profils d'instance, pour les identifier, les organiser et contrôler l'accès. Vous pouvez baliser les profils d'instance uniquement lorsque vous utilisez l' AWS API AWS CLI or. 

**Note**  
Un profil d'instance peut contenir un seul rôle IAM, mais un rôle peut être inclus dans plusieurs profils d'instance. Cette limite est d'un rôle par profil d'instance ne peut pas être augmentée. Vous pouvez supprimer le rôle existant, puis ajouter un autre rôle à un profil d'instance. Vous devez ensuite attendre que le changement apparaisse dans l'ensemble pour des AWS raisons de [cohérence éventuelle](https://en.wikipedia.org/wiki/Eventual_consistency). Pour forcer la modification, vous devez [dissocier le profil d'instance](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html), puis [associer le profil d'instance](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html), ou vous pouvez arrêter votre instance, puis la redémarrer.

### Gestion de profils d'instance (AWS CLI)
<a name="instance-profiles-manage-cli"></a>

Vous pouvez utiliser les AWS CLI commandes suivantes pour utiliser les profils d'instance d'un AWS compte. 
+ Création d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)
+ Balisage d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html)
+ Affichage de la liste des balises d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html)
+ Suppression des balises d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html)
+ Ajout d'un rôle à un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) 
+ Affichage d'une liste de profils d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html), [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html) 
+ Obtention d'informations sur un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html) 
+ Suppression d'un rôle d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html)
+ Suppression d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html) 

Vous pouvez également attacher un rôle à une instance EC2 déjà en cours d'exécution à l'aide des commandes suivantes. Pour de plus amples informations, veuillez consulter la section [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role).
+ Attachement d'un profil d'instance avec un rôle à une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) 
+ Obtention d'informations sur un profil d'instance attaché à une instance EC2 : [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) 
+ Détachement d'un profil d'instance avec un rôle d'une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html) 

### Gestion des profils d'instance (AWS API)
<a name="instance-profiles-manage-api"></a>

Vous pouvez appeler les opérations d' AWS API suivantes pour travailler avec des profils d'instance dans un Compte AWS.
+ Création d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) 
+ Balisage d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ Affichage de la liste des balises d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ Suppression des balises d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ Ajout d'un rôle à un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) 
+ Affichage d'une liste de profils d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html), [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html) 
+ Obtention d'informations sur un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html) 
+ Suppression d'un rôle d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html) 
+ Suppression d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) 

Vous pouvez également attacher un rôle à une instance EC2 déjà en cours d'exécution en appelant les opérations suivantes. Pour de plus amples informations, veuillez consulter la section [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role).
+ Attachement d'un profil d'instance avec un rôle à une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html) 
+ Obtention d'informations sur un profil d'instance attaché à une instance EC2 : [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html) 
+ Détachement d'un profil d'instance avec un rôle d'une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html) 

# Fournisseurs d'identité et fédération au sein de AWS
<a name="id_roles_providers"></a>

Il est recommandé de demander aux utilisateurs humains d'utiliser la fédération avec un fournisseur d'identité pour accéder aux AWS ressources au lieu de créer des utilisateurs IAM individuels dans votre Compte AWS. Avec un fournisseur d'identité (IdP), vous pouvez gérer les identités de vos utilisateurs en dehors de votre AWS compte et leur donner l'autorisation d'utiliser les AWS ressources de votre compte. Ceci est utile si votre organisation dispose déjà de son propre système d'identité, par exemple un répertoire d'utilisateurs d'entreprise. C'est également utile si vous créez une application mobile ou une application Web nécessitant un accès à AWS des ressources.

**Note**  
Vous pouvez également gérer les utilisateurs humains dans l’[IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) avec un fournisseur d’identité SAML externe plutôt que d’utiliser la fédération SAML dans IAM. La fédération IAM Identity Center avec un fournisseur d'identité vous permet de donner aux utilisateurs l'accès à plusieurs AWS comptes de votre organisation et à plusieurs AWS applications. Pour en savoir plus sur les situations spécifiques dans lesquelles un utilisateur IAM est nécessaire, veuillez consulter [Quand créer un utilisateur IAM (au lieu d'un rôle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose).

Si vous préférez utiliser un seul AWS compte sans activer IAM Identity Center, vous pouvez utiliser IAM avec un IdP externe qui fournit des informations d'identité à l'aide d' AWS OpenID [Connect (OIDC) ou de [SAML 2.0 (Security Assertion Markup Language 2.0](https://wiki.oasis-open.org/security))](http://openid.net/connect/). L'OIDC connecte des applications, telles que GitHub Actions, qui ne s'exécutent pas sur AWS des AWS ressources. Voici quelques exemples de fournisseurs d’identité SAML bien connus : Shibboleth et Active Directory Federation Services.

Lorsque vous utilisez un fournisseur d'identité , vous n'avez pas à créer de code de connexion personnalisé ni à gérer vos propres identités utilisateur. L'IdP prévoit cela pour vous. Vos utilisateurs externes se connectent via un IdP, et vous pouvez autoriser ces identités externes à utiliser les AWS ressources de votre compte. Les fournisseurs d'identité contribuent à votre Compte AWS sécurité car vous n'avez pas à distribuer ou à intégrer des informations de sécurité à long terme, telles que des clés d'accès, dans votre application.

Consultez le tableau suivant pour déterminer le type de fédération IAM le mieux adapté à votre cas d’utilisation : IAM, IAM Identity Center ou Amazon Cognito. Les résumés et le tableau suivants fournissent une vue d'ensemble des méthodes que vos utilisateurs peuvent utiliser pour obtenir un accès fédéré aux AWS ressources.


| Type de fédération IAM | Account type (Type de compte) | Gestion de l'accès de… | Source d'identité prise en charge | 
| --- | --- | --- | --- | 
|  Fédération avec IAM Identiy Center  |  Plusieurs comptes gérés par AWS Organizations  |  Les utilisateurs humains de votre personnel  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers.html)  | 
|  Fédération avec IAM  |  Compte unique et autonome  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers.html)  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers.html)  | 
|  Fédération avec les réserves d'identités Amazon Cognito  |  N’importe lequel  |  Les utilisateurs d'applications qui nécessitent une autorisation IAM pour accéder aux ressources  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers.html)  | 

## Fédération avec IAM Identiy Center
<a name="id_roles_providers_identity-center"></a>

Pour une gestion centralisée des accès des utilisateurs humains, nous vous recommandons d'utiliser [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) pour gérer l'accès à vos comptes et les autorisations au sein de ceux-ci. Les utilisateurs d'IAM Identity Center reçoivent des informations d'identification à court terme pour vos AWS ressources. Vous pouvez utiliser Active Directory, un fournisseur d'identité externe (IdP) ou un annuaire IAM Identity Center comme source d'identité permettant aux utilisateurs et aux groupes d'attribuer l'accès à vos ressources. AWS 

IAM Identity Center prend en charge la fédération des identités avec le langage SAML (Security Assertion Markup Language) 2.0 afin de fournir un accès d'authentification unique fédéré aux utilisateurs autorisés à utiliser les applications du portail d'accès. AWS Les utilisateurs peuvent ensuite se connecter de manière unique aux services compatibles SAML, notamment aux applications AWS Management Console et aux applications tierces, telles que Microsoft 365, SAP Concur et Salesforce.

## Fédération avec IAM
<a name="id_roles_providers_iam"></a>

Bien que nous recommandions fortement de gérer les utilisateurs humains dans IAM Identity Center, vous pouvez activer l’accès principal fédéré avec IAM pour les utilisateurs humains dans le cadre de déploiements à court terme et à petite échelle. IAM vous permet d'utiliser des protocoles SAML 2.0 et Open ID Connect (OIDC) distincts IdPs et d'utiliser des attributs principaux fédérés pour le contrôle d'accès. Avec IAM, vous pouvez transmettre des attributs utilisateur, tels que le centre de coûts, le titre ou les paramètres régionaux, de votre compte IdPs à AWS, et mettre en œuvre des autorisations d'accès détaillées en fonction de ces attributs.

Une *charge de travail* est un ensemble de ressources et de code qui fournit une valeur business, par exemple une application destinée au client ou un processus de backend. Votre charge de travail peut nécessiter une identité IAM pour envoyer des demandes aux AWS services, aux applications, aux outils opérationnels et aux composants. Ces identités incluent les machines exécutées dans vos AWS environnements, telles que les EC2 instances ou les AWS Lambda fonctions Amazon.

Vous pouvez également gérer les Identités machine pour les parties externes qui ont besoin d'un accès. Pour donner accès aux identités des machines, vous pouvez utiliser des rôles IAM. Les rôles IAM disposent d'autorisations spécifiques et fournissent un moyen d'accès AWS en s'appuyant sur des informations d'identification de sécurité temporaires associées à une session de rôle. En outre, il se peut AWS que des machines extérieures aient besoin d'accéder à vos AWS environnements. Pour les machines qui s'exécutent en dehors de AWS vous, vous pouvez utiliser [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html). Pour plus d'informations sur les rôles , consultez [Rôles IAM](id_roles.md). Pour plus de détails sur l'utilisation des rôles pour déléguer l'accès entre Comptes AWS eux, consultez[Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md).

Pour lier un IdP directement à IAM, vous devez créer une entité fournisseur d'identité afin d'établir une relation de confiance entre vous et Compte AWS l'IdP. Les supports IAM sont IdPs compatibles avec [OpenID Connect (OIDC) ou SAML 2.0 (](http://openid.net/connect/)[Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security). Pour plus d'informations sur l'utilisation de l'un d' IdPs entre eux avec AWS, consultez les sections suivantes :
+ [Fédération OIDC](id_roles_providers_oidc.md)
+ [Fédération SAML 2.0](id_roles_providers_saml.md)

## Fédération avec les réserves d'identités Amazon Cognito
<a name="id_roles_providers_cognito"></a>

Amazon Cognito est conçu pour les développeurs qui souhaitent authentifier et autoriser les utilisateurs dans leurs applications mobiles et Web. Les groupes d'utilisateurs Amazon Cognito ajoutent des fonctionnalités de connexion et d'inscription à votre application, et les réserves d'identités fournissent des informations d'identification IAM qui permettent à vos utilisateurs d'accéder aux ressources protégées que vous gérez dans AWS. Les réserves d'identités obtiennent des informations d'identification pour les sessions temporaires par le biais de l'opération API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html).

Amazon Cognito travaille avec des fournisseurs d'identité externes qui prennent en charge SAML et OpenID Connect, ainsi qu'avec des fournisseurs d'identité sociaux tels que Facebook, Google et Amazon. Votre application peut connecter un utilisateur appartenant à un groupe d'utilisateurs ou à un IdP externe, puis récupérer des ressources en son nom grâce à des sessions temporaires personnalisées dans un rôle IAM.

## Ressources supplémentaires
<a name="id_roles_providers_additional_resources"></a>
+ Pour une démonstration sur la création d'un proxy de fédération personnalisé qui permet l'authentification unique (SSO) à l' AWS Management Console aide du système d'authentification de votre organisation, voir. [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md)

# Scénarios courants
<a name="id_federation_common_scenarios"></a>

**Note**  
Nous vous recommandons de demander à vos utilisateurs humains d'utiliser des informations d'identification temporaires lors de l'accès AWS. Avez-vous envisagé d'en utiliser AWS IAM Identity Center ? Vous pouvez utiliser IAM Identity Center pour gérer de manière centralisée l'accès à plusieurs comptes Comptes AWS et fournir aux utilisateurs un accès par authentification unique protégé par le MFA à tous les comptes qui leur sont attribués à partir d'un seul endroit. Avec IAM Identity Center, vous pouvez créer et gérer les identités des utilisateurs dans IAM Identity Center ou vous connecter facilement à votre fournisseur d'identité compatible SAML 2.0 existant. 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 *.

Vous pouvez utiliser un fournisseur d’identité (IdP) externe pour gérer les identités des utilisateurs à l’extérieur d’ AWS et de l’IdP externe. Un IdP externe peut fournir des informations d'identité à l' AWS aide d'OpenID Connect (OIDC) ou du langage SAML (Security Assertion Markup Language). L'OIDC est couramment utilisé lorsqu'une application qui ne s'exécute pas AWS a besoin d'accéder à AWS des ressources.

Lorsque vous souhaitez configurer la fédération avec un IdP externe, vous créez un *fournisseur d'identité* IAM pour fournir des AWS informations sur l'IdP externe et sa configuration. Cela établit un climat de confiance entre votre Compte AWS IdP et l'IdP externe. Les rubriques suivantes présentent des scénarios courants d’utilisation des fournisseurs d’identité IAM.

**Topics**
+ [Amazon Cognito pour les applications mobiles](#id_roles_providers_oidc_cognito)
+ [Fédération OIDC pour applications mobiles](#id_roles_providers_oidc_manual)

## Amazon Cognito pour les applications mobiles
<a name="id_roles_providers_oidc_cognito"></a>

Le meilleur moyen d’utiliser la fédération OIDC consiste à utiliser [Amazon Cognito](https://aws.amazon.com/cognito/). Par exemple, la développeuse Adèle est en train de créer un jeu pour appareil mobile dans lequel les données utilisateur, telles que les scores et les profils, sont stockées dans Amazon S3 et Amazon DynamoDB. Adèle pourrait également stocker ces données en local sur l'appareil et utiliser Amazon Cognito pour les maintenir synchronisées sur les différents appareils. Elle sait que pour des raisons de sécurité et de maintenance, des informations d'identification (credentials) de sécurité AWS à long terme ne doivent pas être distribuées avec le jeu. Elle sait également que le jeu pourrait avoir un grand nombre d'utilisateurs. Pour toutes ces raisons, elle ne veut pas créer de nouvelles identités dans IAM pour chaque joueur. Au lieu de cela, elle développe le jeu de sorte que les utilisateurs puissent se connecter à l’aide d’une identité qu’ils ont déjà établie avec un fournisseur d’identité (IdP) externe connu, comme **Login with Amazon**, **Facebook**, **Google**, ou tout fournisseur d’identité compatible **OpenID Connect** (OIDC). Son jeu peut tirer parti du mécanisme d'authentification de l'un de ces fournisseurs afin de valider l'identité de l'utilisateur. 

Pour permettre à l'application mobile d'accéder à ses AWS ressources, Adele enregistre d'abord un identifiant de développeur auprès de son choix IdPs. Elle configure également l'application avec chacun de ces fournisseurs. Dans le dossier Compte AWS qui contient le compartiment Amazon S3 et la table DynamoDB du jeu, Adele utilise Amazon Cognito pour créer des rôles IAM qui définissent précisément les autorisations dont le jeu a besoin. Si elle utilise un IdP OIDC, elle crée également une entité de fournisseur d'identité IAM OIDC pour établir un lien de confiance entre le [pool d'identités Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) qu'elle possède et l'IdP. Compte AWS 

Dans le code de l'application, Adèle appelle l'interface de la connexion pour le fournisseur d'identité l'IdP qu'elle a configuré précédemment. L'IdP gère tous les détails relatifs à la connexion de l'utilisateur, et l'application obtient un jeton d' OAuth accès ou un jeton d'identification OIDC auprès du fournisseur. L'application d'Adele peut échanger ces informations d'authentification contre un ensemble d'informations de sécurité temporaires comprenant un identifiant de clé d' AWS accès, une clé d'accès secrète et un jeton de session. L'application peut ensuite utiliser ces informations d'identification pour accéder aux services Web proposés par AWS. L'application est limitée aux autorisations qui sont définies dans le rôle qu'elle endosse.

La figure suivante illustre un flux simplifié d'un fonctionnement possible, à l'aide de Login with Amazon comme fournisseur d'identité. Pour l'étape 2, l'application peut également utiliser Facebook, Google ou tout fournisseur d'identité OIDC compatible, mais ce n'est pas présenté ici.

![\[Exemple de flux de travail Amazon Cognito pour fédérer des utilisateurs pour une application mobile\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/mobile-app-web-identity-federation.diagram.png)


 

1. Un client démarre votre application sur un appareil mobile. L'application demande à l'utilisateur de se connecter.

1. L'application utilise des ressources Login with Amazon pour accepter les informations d'identification de l'utilisateur.

1. L'application utilise des opérations d'API Amazon Cognito `GetId` et `GetCredentialsForIdentity` pour échanger le jeton d'ID Login with Amazon (Connexion avec Amazon) contre un jeton Amazon Cognito. Amazon Cognito, qui a été configuré pour approuver votre projet Login with Amazon (Connexion avec Amazon), génère un jeton qu'il échange contre des informations d'identification de session temporaires avec AWS STS.

1. L'application reçoit des informations d'identification de sécurité temporaires d'Amazon Cognito. Votre application peut également utiliser le flux de travail de base (classique) d'Amazon Cognito pour récupérer des jetons lors de AWS STS l'utilisation. `AssumeRoleWithWebIdentity` Pour plus d'informations, consultez la rubrique [Flux d'authentification des groupes d'identités (identités fédérées)](https://docs.aws.amazon.com/cognito/latest/developerguide/authentication-flow.html) dans le Guide du développeur Amazon Cognito.

1. Les informations d'identification de sécurité temporaires peuvent être utilisées par l'application pour accéder aux ressources AWS requises par l'application pour fonctionner. Le rôle associé aux informations d'identification de sécurité temporaires et les politiques qui lui sont attribuées détermine ce qui est accessible.

Suivez le processus suivant pour configurer votre application afin qu'elle utilise Amazon Cognito afin d'authentifier les utilisateurs et de permettre à votre application d'accéder aux ressources. AWS Pour les étapes spécifiques permettant de réaliser ce scénario, consultez la documentation d'Amazon Cognito.

1. (Facultatif) Connectez-vous en tant que développeur auprès de Login with Amazon, Facebook, Google ou tout autre fournisseur d'identité compatible OpenID Connect (OIDC) et configurez une ou plusieurs applications avec le fournisseur. Cette étape est facultative, car Amazon Cognito prend également en charge l'accès non authentifié (invité) pour vos utilisateurs.

1. Accédez à [Amazon Cognito dans le. AWS Management Console](https://console.aws.amazon.com/cognito/home) Utilisez l'assistant Amazon Cognito pour créer un groupe d'identités, qui est un conteneur utilisé par Amazon Cognito pour maintenir des identités d'utilisateur final organisées pour vos applications. Vous pouvez partager des pools d'identité entre des applications. Lorsque vous configurez un groupe d'identités, Amazon Cognito crée un ou deux rôles IAM (un pour les identités authentifiées et un pour les identités « invitées » non authentifiées) qui définissent des autorisations pour les utilisateurs d'Amazon Cognito. 

1. Intégrez [AWS](https://docs.amplify.aws)Amplify avec votre application et importez les fichiers requis pour utiliser Amazon Cognito.

1. Créez une instance du fournisseur d'informations d'identification Amazon Cognito en transmettant l'ID de groupe d'identité, votre numéro d' Compte AWS et l'Amazon Resource Name (ARN) des rôles que vous avez associés au groupe d'identités. L'assistant Amazon Cognito AWS Management Console fournit un exemple de code pour vous aider à démarrer.

1. Lorsque votre application accède à une AWS ressource, transmettez l'instance du fournisseur d'informations d'identification à l'objet client, qui transmet les informations de sécurité temporaires au client. Les autorisations pour les informations d'identification sont basées sur le ou les rôles que vous avez définis précédemment.

Pour plus d’informations, consultez les ressources suivantes :
+ [Connectez-vous (Android)](https://docs.amplify.aws/lib/auth/signin/q/platform/android/) dans la documentation du AWS Amplify framework. 
+ [Connectez-vous (iOS)](https://docs.amplify.aws/lib/auth/signin/q/platform/ios/) dans la documentation du AWS Amplify framework.

## Fédération OIDC pour applications mobiles
<a name="id_roles_providers_oidc_manual"></a>

Vous obtiendrez les meilleurs résultats en utilisant Amazon Cognito comme fournisseur d’identité dans la quasi-totalité des scénarios de fédération OIDC. Amazon Cognito est facile à utiliser et offre des capacités supplémentaires, comme l'accès anonyme (sans authentification) et la synchronisation des données utilisateur entre les périphériques et les fournisseurs. Cependant, si vous avez déjà créé une application exploitant la fédération OIDC en appelant manuellement l’API `AssumeRoleWithWebIdentity`, vous pouvez continuer à l’utiliser : vos applications fonctionneront malgré tout. 

L’utilisation de la fédération OIDC ***sans*** Amazon Cognito se déroule comme suit : 

1. Inscrivez-vous en tant que développeur auprès de l'IdP externe et configurez votre application avec l'ID unique qu'il vous donnera. (Différents IdPs utilisent une terminologie différente pour ce processus. Ce plan utilise le terme *configurer* pour désigner le processus d'identification de votre application auprès de l'IdP.) Chaque IdP vous donne un identifiant d'application qui lui est propre. Ainsi, si vous configurez la même application avec plusieurs IdPs, votre application en aura plusieurs. IDs Vous pouvez configurer plusieurs applications auprès de chaque fournisseur. 

   Les liens externes suivants fournissent des informations sur l'utilisation de certains fournisseurs d'identité couramment utilisés (IdPs) : 
   + [Login with Amazon Developer Center](https://login.amazon.com/) 
   + [Add Facebook Login to Your App or Website](https://developers.facebook.com/docs/facebook-login/v2.1) sur le site des développeurs Facebook. 
   + [Utilisation de la OAuth version 2.0 pour la connexion (OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login) sur le site des développeurs de Google.
**Important**  
Si vous utilisez un fournisseur d'identité OIDC de Google, Facebook ou Amazon Cognito, ne créez pas de fournisseur d'identité IAM distinct dans le. AWS Management Console AWS intègre ces fournisseurs d'identité OIDC et les met à votre disposition. Ignorez l'étape suivante et passez directement à la création de rôles à l'aide de votre fournisseur d'identité.

1. Si vous utilisez un IdP autre que Google, Facebook ou Amazon Cognito, compatible avec OIDC, créez une entité de fournisseur d'identité IAM pour lui.

1. Dans IAM, [créez un ou plusieurs rôles](id_roles_create_for-idp.md). Pour chaque rôle, définissez qui peut endosser le rôle (politique d'approbation) et les autorisations accordées aux utilisateurs de l'application (politique d'autorisation). En général, vous créez un rôle pour chaque IdP pris en charge par l'application. Par exemple, vous pouvez créer un rôle qui est endossé par une application si l'utilisateur se connecte via Login with Amazon, un deuxième rôle pour la même application s'il se connecte via Facebook, et un troisième rôle s'il se connecte via Google. Pour la relation d'approbation, spécifiez l'IdP (par exemple, Amazon.com) en tant que `Principal` (l'entité de confiance) et incluez un élément `Condition` qui correspond à l'ID d'application attribué par l'IdP. Des exemples de rôles pour différents fournisseurs sont présentés dans la rubrique [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md). 

1. Dans votre application, authentifiez vos utilisateurs en recourant à l'IdP. La procédure à suivre varie en fonction de l'IdP utilisé (Login with Amazon, Facebook ou Google) et la plateforme sur laquelle s'exécute votre application. Par exemple, la méthode d'authentification d'une application Android peut être différente de celle d'une application iOS ou d'une application Web JavaScript basée sur le Web.

   En règle générale, si l'utilisateur n'est pas déjà connecté, l'IdP affiche une page de connexion. Une fois qu'il a authentifié l'utilisateur, l'IdP retourne un jeton d'authentification contenant des informations sur l'utilisateur à l'application. Ces informations dépendent de ce que l'IdP expose et des informations que l'utilisateur est disposé à partager. Vous pouvez utiliser ces informations dans votre application.

1. Dans l'application, effectuez un appel *non signé* à l'action `AssumeRoleWithWebIdentity` pour solliciter des informations d'identification de sécurité temporaires. Dans la demande, vous transmettez le jeton d'authentification de l'IdP et vous spécifiez le nom de ressource Amazon (ARN) pour le rôle IAM que vous avez créé pour cet IdP. AWS vérifie que le jeton est fiable et valide et, dans l'affirmative, renvoie les informations de sécurité temporaires à votre application qui disposent des autorisations pour le rôle que vous nommez dans la demande. La réponse inclut également des métadonnées se rapportant à l'utilisateur provenant de l'IdP telles que l'ID utilisateur unique que l'IdP associe à l'utilisateur.

1. À l'aide des informations de sécurité temporaires fournies dans la `AssumeRoleWithWebIdentity` réponse, votre application envoie des demandes signées aux opérations d' AWS API. Les informations d’identification de l’utilisateur provenant de l’IdP permettent de distinguer les utilisateurs de votre application. Par exemple, vous pouvez placer des objets dans des dossiers Amazon S3 qui incluent l’identifiant de l’utilisateur comme préfixe ou suffixe. Ceci vous permet de créer des politiques d'accès qui verrouillent un dossier, afin que seul l'utilisateur ayant l'ID approprié soit autorisé à y accéder. Pour de plus amples informations, veuillez consulter [AWS STS principes d'utilisateurs fédérés](reference_policies_elements_principal.md#sts-session-principals).

1. Votre application met généralement en cache ces informations d'identification de sécurité temporaires afin que vous n'ayez pas à en redemander à chaque fois que l'application doit envoyer une demande à AWS. Par défaut, les informations d'identification restent valides pendant une heure. Lorsque les informations d'identification expirent (ou avant le délai d'expiration), vous effectuez un autre appel à `AssumeRoleWithWebIdentity` pour obtenir un nouvel ensemble d'informations d'identification de sécurité temporaires. Selon l'IdP utilisé et la façon dont il gère ses jetons, il sera peut-être nécessaire d'actualiser le jeton de l'IdP avant un nouvel appel à `AssumeRoleWithWebIdentity`, car les jetons de l'IdP expirent généralement après un délai spécifié. Si vous utilisez le AWS SDK pour iOS ou AWS le SDK pour Android, vous pouvez utiliser l'action [STSCredentialsAmazon](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) Provider, qui gère les informations d'identification temporaires IAM, notamment en les actualisant si nécessaire.

# Fédération OIDC
<a name="id_roles_providers_oidc"></a>

Imaginez que vous créez une application qui accède à des AWS ressources, comme GitHub Actions, qui utilise des flux de travail pour accéder à Amazon S3 et DynamoDB. 

Lorsque vous utilisez ces flux de travail, vous envoyez des demandes aux AWS services qui doivent être signées à l'aide d'une clé d' AWS accès. Cependant, nous vous recommandons **vivement** de ne **pas** stocker les AWS informations d'identification à long terme dans des applications extérieures AWS. Configurez plutôt vos applications pour demander des informations d'identification de AWS sécurité temporaires de manière dynamique en cas de besoin à l'aide de la *fédération OIDC*. Les informations d'identification temporaires fournies correspondent à un AWS rôle qui dispose uniquement des autorisations nécessaires pour effectuer les tâches requises par l'application.

Lors de l’utilisation de la fédération OIDC, il n’est pas nécessaire de créer de code de connexion personnalisé ni de gérer vos propres identités utilisateur. Vous pouvez plutôt utiliser OIDC dans des applications, telles que GitHub Actions ou tout autre IdP compatible avec [OpenID Connect (](http://openid.net/connect/)OIDC), pour vous authentifier auprès de. AWS Ils reçoivent un jeton d'authentification, connu sous le nom de jeton Web JSON (JWT), puis échangent ce jeton contre des informations d'identification de sécurité temporaires associées à un rôle IAM autorisé à utiliser des ressources spécifiques dans votre. AWS Compte AWS L'utilisation d'un IdP vous aide à Compte AWS garantir votre sécurité, car vous n'avez pas à intégrer et à distribuer des informations de sécurité à long terme dans votre application.

La fédération OIDC prend en charge à la fois machine-to-machine l'authentification (comme les CI/CD pipelines, les scripts automatisés et les applications sans serveur) et l'authentification des utilisateurs humains. Pour les scénarios d’authentification des utilisateurs humains dans lesquels vous devez gérer l’inscription, la connexion et les profils des utilisateurs, envisagez d’utiliser [Amazon Cognito](https://aws.amazon.com/cognito/) comme fournisseur d’identité. Pour en savoir plus sur l’utilisation d’Amazon Cognito avec OIDC, consultez [Amazon Cognito pour les applications mobiles](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito).

**Note**  
Les jetons Web JSON (JWTs) émis par les fournisseurs d'identité OpenID Connect (OIDC) contiennent une date d'expiration dans la `exp` réclamation qui indique la date d'expiration du jeton. IAM fournit une fenêtre de cinq minutes au-delà du délai d’expiration spécifié dans le JWT pour tenir compte du décalage d’horloge, comme le permet la [norme OpenID Connect (OIDC) Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html). Cela signifie que les OIDC JWTs reçus par IAM après le délai d'expiration, mais dans ce délai de cinq minutes, sont acceptés pour une évaluation et un traitement plus approfondis.

**Topics**
+ [Ressources supplémentaires pour la fédération OIDC](#id_roles_providers_oidc_resources)
+ [Création d’un fournisseur d’identité OpenID Connect (OIDC) dans IAM](id_roles_providers_create_oidc.md)
+ [Obtention de l’empreinte numérique d’un fournisseur d’identité OpenID Connect](id_roles_providers_create_oidc_verify-thumbprint.md)
+ [Contrôles des fournisseurs d’identité pour les fournisseurs OIDC partagés](id_roles_providers_oidc_secure-by-default.md)

## Ressources supplémentaires pour la fédération OIDC
<a name="id_roles_providers_oidc_resources"></a>

Les ressources suivantes peuvent vous aider à en savoir plus sur la fédération OIDC :
+ Utilisez OpenID Connect dans vos GitHub flux de travail en configurant [OpenID Connect](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) dans Amazon Web Services
+ [Amazon Cognito Identity](https://docs.amplify.aws/lib/auth/advanced/q/platform/android/) dans le *Guide Amplify Libraries for Android* et [Amazon Cognito Identity](https://docs.amplify.aws/lib/auth/advanced/q/platform/ios/) dans le *Guide Amplify Libraries for Swift*.
+ [Comment utiliser un identifiant externe lors de l'octroi de l'accès à vos AWS ressources](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/). Le *blog sur la AWS sécurité* fournit des conseils sur la configuration sécurisée de l'accès entre comptes et de la fédération d'identité externe.

# Création d’un fournisseur d’identité OpenID Connect (OIDC) dans IAM
<a name="id_roles_providers_create_oidc"></a>

Les *fournisseurs d'identité OIDC IAM* sont des entités qui, dans IAM, décrivent un service de fournisseur d'identité (IdP) prenant en charge la norme [OpenID Connect](http://openid.net/connect/) (OIDC), comme Google ou Salesforce. Vous utilisez un fournisseur d'identité OIDC IAM lorsque vous souhaitez établir une approbation entre un fournisseur d'identité compatible OIDC et votre Compte AWS. Cela est utile lorsque vous créez une application mobile ou une application Web qui nécessite un accès à AWS des ressources, mais vous ne souhaitez pas créer de code de connexion personnalisé ou gérer vos propres identités d'utilisateur. Pour plus d'informations sur ce scénario, consultez [Fédération OIDC](id_roles_providers_oidc.md).

Vous pouvez créer et gérer un fournisseur d'identité IAM OIDC à l' AWS Management Console aide des AWS Command Line Interface outils pour Windows ou de l' PowerShellAPI IAM.

Après avoir créé un fournisseur d'identité OIDC IAM, vous devez créer un ou plusieurs rôles IAM. Un rôle est une identité AWS qui ne possède pas ses propres informations d'identification (comme le fait un utilisateur). Mais dans ce contexte, un rôle est attribué dynamiquement à un principal fédéré OIDC qui est authentifié par le fournisseur d’identité (IdP) de votre organisation. Le rôle permet à l'IdP de votre organisation de demander des informations d'identification de sécurité temporaires pour accéder à AWS. Les politiques attribuées au rôle déterminent ce que les utilisateurs sont autorisés à faire dans ce rôle AWS. Pour créer un rôle pour un fournisseur d'identité tiers, consultez la section [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md).

**Important**  
Lorsque vous configurez des politiques IAM basées sur l'identité pour les actions qui prennent en charge les ressources `oidc-provider`, IAM évalue l'URL complète du fournisseur d'identité OIDC, y compris les chemins spécifiés. Si l'URL de votre fournisseur d'identité OIDC comporte un chemin, vous devez inclure ce chemin dans l'ARN `oidc-provider` en tant que valeur de l'élément `Resource`. Vous avez également la possibilité d'ajouter une barre oblique et un caractère générique (`/*`) au domaine de l'URL ou d'utiliser des caractères génériques (`*` et `?`) à n'importe quel endroit du chemin de l'URL. Si l'URL du fournisseur d'identité OIDC dans la demande ne correspond pas à la valeur définie dans l'élément `Resource` de la politique, la demande échoue.

Pour résoudre les problèmes courants liés à la fédération IAM OIDC, consultez la section [Résoudre les erreurs liées à OIDC sur Re:post](https://repost.aws/knowledge-center/iam-oidc-idp-federation). AWS 

**Topics**
+ [Conditions préalables : valider la configuration de votre fournisseur d’identité](#manage-oidc-provider-prerequisites)
+ [Création et gestion d'un fournisseur OIDC (console)](#manage-oidc-provider-console)
+ [Création et gestion d'un fournisseur d'identité OIDC IAM (AWS CLI)](#manage-oidc-provider-cli)
+ [Création et gestion d'un fournisseur d'identité OIDC (AWS API)](#manage-oidc-provider-api)

## Conditions préalables : valider la configuration de votre fournisseur d’identité
<a name="manage-oidc-provider-prerequisites"></a>

Avant de créer un fournisseur d’identité IAM OIDC, vous devez obtenir les informations suivantes auprès de votre IdP. Pour plus d’informations sur l’obtention des informations de configuration du fournisseur OIDC, consultez la documentation de votre IdP.

1. Déterminez l’URL publique de votre fournisseur d’identité OIDC. L'URL doit commencer par https://. Per the OIDC standard, path com les points autorisés, mais pas les paramètres de requête. Généralement, l'URL se compose uniquement d'un nom d'hôte, par exemple https://server.example.org or https://example.com. L'URL ne doit pas contenir de numéro de port.

1. Ajoutez **/.well-known/openid-configuration** à la fin de l’URL de votre fournisseur d’identité OIDC pour voir le document de configuration et les métadonnées du fournisseur accessibles au public. Vous devez disposer d’un document de découverte au format JSON avec le document de configuration du fournisseur et les métadonnées qui peuvent être récupérées à partir de l’[URL du point de terminaison de découverte du fournisseur OpenID Connect](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig).

1. Confirmez que les valeurs suivantes sont incluses dans les informations de configuration de votre fournisseur. Si l’un de ces champs est absent de votre configuration OpenID, vous devez mettre à jour votre document de découverte. Ce processus peut varier en fonction de votre fournisseur d’identité, il convient donc de suivre la documentation de votre IdP pour mener à bien cette tâche.
   + émetteur : l’URL de votre domaine.
   + jwks\$1uri : point de terminaison JSON Web Key Set (JWKS) auprès duquel IAM obtient vos clés publiques. Votre fournisseur d’identité doit inclure un point de terminaison JSON Web Key Set (JWKS) dans la configuration OpenID. Cette URI définit où obtenir les clés publiques utilisées pour vérifier les jetons signés auprès de votre fournisseur d’identité.
**Note**  
Le JSON Web Key Set (JWKS) doit contenir au moins une clé et peut comporter au maximum 100 clés RSA et 100 clés EC. Si le JWKS de votre fournisseur d'identité OIDC contient plus de 100 clés RSA ou 100 clés EC, une `InvalidIdentityToken` exception sera renvoyée lors de l'utilisation de l'opération [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)API avec un JWT signé par un type de clé dépassant la limite de 100 clés. Par exemple, si un JWT est signé avec l’algorithme RSA et qu’il y a plus de 100 clés RSA dans le JWKS de votre fournisseur, une exception `InvalidIdentityToken` sera renvoyée.
   + claims\$1supported : informations sur l'utilisateur qui vous aident à garantir que les réponses d'authentification OIDC de votre IdP contiennent les attributs requis AWS utilisés dans les politiques IAM pour vérifier les autorisations des principaux fédérés OIDC. Pour obtenir la liste des clés de condition IAM pouvant être utilisées pour les demandes, consultez [Clés disponibles pour la AWS fédération OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif).
     + aud : Vous devez déterminer la valeur d'audience déclarée par votre IdP dans JSON Web Tokens ()JWTs. La demande de public (aud) est spécifique à l’application et identifie les destinataires prévus du jeton. Lorsque vous enregistrez une application mobile ou Web auprès d’un fournisseur OpenID Connect, celui-ci établit un identifiant client qui identifie l’application. L’ID client est un identifiant unique pour votre application. Il est transmis dans la demande aud pour l’authentification. La demande aud doit correspondre à la valeur Public lors de la création de votre fournisseur d’identité IAM OIDC.
     + iat : les réclamations doivent inclure une valeur pour `iat` qui représente l’heure à laquelle le jeton d’identification est émis.
     + iss : l’URL du fournisseur d’identité. L'URL doit commencer par https:// and should correspond to the Provider URL provided to IAM. Per the OIDC standard, path com les points autorisés, mais pas les paramètres de requête. Généralement, l'URL se compose uniquement d'un nom d'hôte, par exemple https://server.example.org or https://example.com. L'URL ne doit pas contenir de numéro de port.
   + response\$1types\$1supported: id\$1token
   + subject\$1types\$1supported: public
   + id\$1token\$1signing\$1alg\$1values\$1supported :,,,,, RS256 RS384 RS512 ES256 ES384 ES512
**Note**  
Vous pouvez inclure des réclamations supplémentaires comme `my_custom_claim` dans l'exemple ci-dessous, mais AWS STS vous ignorerez la réclamation.  

   ```
   {
     "issuer": "https://example-domain.com",
     "jwks_uri": "https://example-domain.com/jwks/keys",
     "claims_supported": [
       "aud",
       "iat",
       "iss",
       "name",
       "sub",
       "my_custom_claim"
     ],
     "response_types_supported": [
       "id_token"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "RS384",
       "RS512",
       "ES256",
       "ES384",
       "ES512"
     ],
     "subject_types_supported": [
       "public"
     ]
   }
   ```

## Création et gestion d'un fournisseur OIDC (console)
<a name="manage-oidc-provider-console"></a>

Observez les instructions suivantes pour créer et gérer un fournisseur d'identité OIDC IAM dans la AWS Management Console.

**Important**  
Si vous utilisez un fournisseur d'identité OIDC de Google, Facebook ou Amazon Cognito, ne créez pas de fournisseur d'identité IAM distinct selon cette procédure. Ces fournisseurs d'identité OIDC sont déjà intégrés AWS et sont disponibles pour votre usage. Au lieu de cela, créez de nouveaux rôles pour votre fournisseur d'identité, en consultant [Création d’un rôle pour la fédération OpenID Connect (console)](id_roles_create_for-idp_oidc.md).

**Pour créer un fournisseur d'identité OIDC IAM (console)**

1. <a name="idpoidcstep1"></a>Avant de créer un fournisseur d'identité OIDC IAM, vous devez enregistrer votre application auprès du fournisseur d'identité afin de recevoir un *ID client*. L'ID client (également appelé *public ciblé*) est un identifiant unique pour votre application. Il est émis lorsque vous enregistrez l'application auprès du fournisseur d'identité. Pour plus d'informations sur l'obtention d'un ID client, consultez la documentation de votre fournisseur d'identité. 
**Note**  
AWS sécurise les communications avec les fournisseurs d'identité OIDC (IdPs) à l'aide de notre bibliothèque d'autorités de certification racines fiables (CAs) pour vérifier le certificat TLS du point de terminaison JSON Web Key Set (JWKS). Si votre IdP OIDC repose sur un certificat qui n'est pas signé par l'un de ces fournisseurs de CAs confiance, ce n'est qu'alors que nous sécurisons les communications à l'aide des empreintes digitales définies dans la configuration de l'IdP. AWS reviendra à la vérification par empreinte digitale si nous ne parvenons pas à récupérer le certificat TLS ou si le protocole TLS v1.3 est requis.

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le panneau de navigation, sélectionnez **Fournisseurs d'identité**, puis **Ajouter un fournisseur**.

1. Pour **Configurer le fournisseur**, sélectionnez **OpenID Connect**. 

1. Sous **URL du fournisseur**, tapez l'URL du fournisseur d'identité. L'URL doit respecter les restrictions suivantes :
   + L'URL est sensible à la casse.
   + L'URL doit commencer par **https://**.
   + L'URL ne doit pas contenir de numéro de port. 
   + Au sein de votre Compte AWS, chaque fournisseur d'identité IAM OIDC doit utiliser une URL unique. Si vous essayez de soumettre une URL qui a déjà été utilisée pour un fournisseur OpenID Connect dans le Compte AWS, vous recevrez un message d'erreur.

1. Pour **Audience**, saisissez l'ID client de l'application que vous avez enregistrée auprès de l'IdP et dans [Step 1](#idpoidcstep1) laquelle vous avez envoyé des demandes. AWS Si vous avez des clients supplémentaires IDs (également appelés *audiences*) pour cet IdP, vous pouvez les ajouter ultérieurement sur la page détaillée du fournisseur.
**Note**  
Si votre jeton JWT IdP inclut la demande `azp`, saisissez cette valeur comme valeur Public.  
Si votre fournisseur d'identité OIDC définit à la fois les `azp` demandes `aud` et les réclamations dans le jeton, AWS STS il utilisera la valeur de la `azp` réclamation comme `aud` réclamation.

1. (Facultatif) Pour **Ajouter des balises**, vous pouvez ajouter des paires clé-valeur pour vous aider à identifier et à organiser votre. IdPs Vous pouvez également utiliser des balises pour contrôler l'accès aux ressources AWS . Pour en savoir plus sur le balisage des fournisseurs d'identité OIDC IAM, reportez-vous à la section [Balisage de fournisseurs d’identité OpenID Connect (OIDC)](id_tags_oidc.md). Choisissez **Ajouter une balise**. Saisissez des valeurs pour chaque paire clé-valeur de balise. 

1. Vérifiez les informations que vous avez fournies. Lorsque vous avez terminé, sélectionnez **Ajouter un fournisseur**. IAM tentera de récupérer et d’utiliser l’empreinte numérique de l’autorité de certification intermédiaire supérieure du certificat du serveur IdP OIDC pour créer le fournisseur d’identité IAM OIDC.
**Note**  
La chaîne de certificats du fournisseur d’identité OIDC doit commencer par l’URL du domaine ou de l’émetteur, puis par le certificat intermédiaire et enfin par le certificat racine. Si l’ordre de la chaîne de certificats est différent ou comprend des certificats en double ou supplémentaires, vous recevez une erreur de non-concordance de signature et STS ne parvient pas à valider le jeton Web JSON (JWT). Corrigez l’ordre des certificats dans la chaîne renvoyée par le serveur pour résoudre l’erreur. Pour plus d’informations sur les normes relatives aux chaînes de certificats, consultez [certificate\$1list dans la RFC 5246](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2) sur le site Web de la série RFC.

1. Attribuez un rôle IAM à votre fournisseur d'identité pour autoriser les identités d'utilisateurs externes gérées par votre fournisseur d'identité à accéder aux AWS ressources de votre compte. Pour en savoir plus sur la création de rôles pour la fédération d'identité, consultez la section [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md).
**Note**  
L'OIDC IdPs utilisé dans une politique d'approbation des rôles doit se trouver dans le même compte que le rôle qui l'approuve.

**Pour ajouter ou supprimer une empreinte pour un fournisseur d'identité OIDC IAM (console)**
**Note**  
AWS sécurise les communications avec les fournisseurs d'identité OIDC (IdPs) à l'aide de notre bibliothèque d'autorités de certification racines fiables (CAs) pour vérifier le certificat TLS du point de terminaison JSON Web Key Set (JWKS). Si votre IdP OIDC repose sur un certificat qui n'est pas signé par l'un de ces fournisseurs de CAs confiance, ce n'est qu'alors que nous sécurisons les communications à l'aide des empreintes digitales définies dans la configuration de l'IdP. AWS reviendra à la vérification par empreinte digitale si nous ne parvenons pas à récupérer le certificat TLS ou si le protocole TLS v1.3 est requis.

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le panneau de navigation, sélectionnez **Fournisseurs d'identité**. Sélectionnez ensuite le nom du fournisseur d'identité IAM que vous souhaitez mettre à jour.

1. Choisissez l’onglet **Vérification du point de terminaison**, puis dans la section **Empreintes numériques**, sélectionnez **Gérer**. Pour saisir une nouvelle valeur d'empreinte, sélectionnez **Ajouter une empreinte**. Pour supprimer une empreinte numérique, sélectionnez **Supprimer** en regard de l'empreinte que vous souhaitez supprimer.
**Note**  
Un fournisseur d'identité OIDC IAM peut avoir entre 1 (minimum) et 5 empreintes.

    Lorsque vous avez terminé, sélectionnez **Enregistrer les modifications**.

**Pour ajouter une audience pour un fournisseur d'identité OIDC IAM (console)**

1. Dans le panneau de navigation, sélectionnez **Identity providers** (Fournisseurs d'identité), puis le nom du fournisseur d'identité IAM que vous voulez mettre à jour.

1. Dans la section **Audiences**, sélectionnez **Actions** et **Ajouter une audience**. 

1. Entrez l'ID client de l'application que vous avez enregistrée auprès de l'IdP et dans [Step 1](#idpoidcstep1) laquelle vous allez envoyer des demandes. AWS Sélectionnez ensuite **Ajouter des audiences**.
**Note**  
Un fournisseur d'identité OIDC IAM peut avoir entre 1 (minimum) et 100 audiences (maximum).

**Pour supprimer une audience pour un fournisseur d'identité OIDC IAM (console)**

1. Dans le panneau de navigation, sélectionnez **Identity providers** (Fournisseurs d'identité), puis le nom du fournisseur d'identité IAM que vous voulez mettre à jour.

1. Dans la section **Audiences**, activez la case d'option en regard de l'audience que vous souhaitez supprimer, puis sélectionnez **Actions**.

1.  Sélectionnez **Supprimer l'audience**. Une nouvelle fenêtre s'ouvre.

1. Si vous supprimez une audience, les identités fédérées avec l'audience ne peuvent pas endosser les rôles associés à l'audience. Dans la fenêtre, lisez le message d'avertissement et confirmez que vous souhaitez supprimer l'audience en saisissant le mot `remove` dans le champ.

1. Sélectionnez **Supprimer** pour supprimer l'audience.

**Pour supprimer un fournisseur d'identité OIDC IAM (console)**

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le panneau de navigation, sélectionnez **Identity providers (Fournisseurs d'identité)**. 

1. Sélectionnez la case à cocher en regard du fournisseur d’identité IAM que vous souhaitez supprimer. Une nouvelle fenêtre s'ouvre.

1. Confirmez que vous souhaitez supprimer le fournisseur en saisissant le mot `delete` dans le champ. Ensuite, choisissez **Supprimer**.

## Création et gestion d'un fournisseur d'identité OIDC IAM (AWS CLI)
<a name="manage-oidc-provider-cli"></a>

Vous pouvez utiliser les AWS CLI commandes suivantes pour créer et gérer des fournisseurs d'identité IAM OIDC.

**Pour créer un fournisseur d'identité OIDC IAM (AWS CLI)**

1. (Facultatif) Pour obtenir la liste de tous les fournisseurs d'identité OIDC IAM de votre compte AWS , exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. Pour créer un fournisseur d'identité OIDC IAM, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html)

**Pour mettre à jour la liste des empreintes numériques de certificat de serveur pour un fournisseur d'identité OIDC IAM existant (AWS CLI)**
+ Pour mettre à jour la liste des empreintes de certificat de serveur pour un fournisseur d'identité OIDC IAM, exécutez la commande suivante :
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/update-open-id-connect-provider-thumbprint.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-open-id-connect-provider-thumbprint.html)

**Pour baliser un fournisseur d'identité OIDC IAM existant (AWS CLI)**
+ Pour baliser un fournisseur d'identité OIDC IAM existant, exécutez la commande suivante :
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html)

**Pour afficher la liste des balises d'un fournisseur d'identité OIDC IAM existant (AWS CLI)**
+ Pour afficher la liste des balises d'un fournisseur d'identité OIDC IAM existant, exécutez la commande suivante :
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html)

**Pour supprimer les balises d'un fournisseur d'identité OIDC IAM (AWS CLI)**
+ Pour supprimer les balises d'un fournisseur d'identité OIDC IAM existant, exécutez la commande suivante :
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html)

**Pour ajouter un ID client à un fournisseur d'identité OIDC IAM existant ou le supprimer (API AWS CLI)**

1. (Facultatif) Pour obtenir la liste de tous les fournisseurs d'identité OIDC IAM de votre compte AWS , exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. (Facultatif) Pour obtenir des informations détaillées sur un fournisseur d'identité OIDC IAM, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html)

1. Pour ajouter un nouvel ID client à un fournisseur d'identité OIDC IAM existant, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/add-client-id-to-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-client-id-to-open-id-connect-provider.html)

1. Pour supprimer un client d'un fournisseur d'identité OIDC IAM existant, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-client-id-from-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-client-id-from-open-id-connect-provider.html)

**Pour supprimer un fournisseur d'identité OIDC IAM (AWS CLI)**

1. (Facultatif) Pour obtenir la liste de tous les fournisseurs d'identité OIDC IAM de votre compte AWS , exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. (Facultatif) Pour obtenir des informations détaillées sur un fournisseur d'identité OIDC IAM, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html)

1. Pour supprimer un fournisseur d'identité OIDC IAM, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html)

## Création et gestion d'un fournisseur d'identité OIDC (AWS API)
<a name="manage-oidc-provider-api"></a>

Vous pouvez utiliser les commandes de l'API IAM suivantes pour créer et gérer des fournisseurs OICD.

**Pour créer un fournisseur d'identité (AWS API) IAM OIDC**

1. (Facultatif) Pour obtenir la liste de tous les fournisseurs d'identité OIDC IAM de votre compte AWS , appelez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. Pour créer un fournisseur d'identité OIDC IAM, appelez l'opération suivante : 
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html)

**Pour mettre à jour la liste des empreintes numériques des certificats de serveur pour un fournisseur d'identité (API) IAM OIDC existant AWS**
+ Pour mettre à jour la liste des empreintes de certificat de serveur pour un fournisseur d'identité OIDC IAM, appelez l'opération suivante :
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateOpenIDConnectProviderThumbprint.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateOpenIDConnectProviderThumbprint.html)

**Pour étiqueter un fournisseur d'identité (AWS API) IAM OIDC existant**
+ Pour baliser un fournisseur d'identité OIDC IAM existant, appelez l'opération suivante :
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html)

**Pour répertorier les balises d'un fournisseur d'identité (AWS API) IAM OIDC existant**
+ Pour afficher la liste des balises d'un fournisseur d'identité OIDC IAM existant, appelez l'opération suivante :
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html)

**Pour supprimer des balises sur un fournisseur d'identité (AWS API) IAM OIDC existant**
+ Pour supprimer les balises d'un fournisseur d'identité OIDC IAM existant, appelez l'opération suivante :
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html)

**Pour ajouter ou supprimer un ID client auprès d'un fournisseur d'identité (AWS API) IAM OIDC existant**

1. (Facultatif) Pour obtenir la liste de tous les fournisseurs d'identité OIDC IAM de votre compte AWS , appelez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. (Facultatif) Pour obtenir des informations détaillées sur un fournisseur d'identité OIDC IAM, appelez l'opération suivante : 
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html)

1. Pour ajouter un nouvel ID client à un fournisseur d'identité OIDC IAM existant, appelez l'opération suivante : 
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddClientIDToOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddClientIDToOpenIDConnectProvider.html)

1. Pour supprimer un ID client d'un fournisseur d'identité OIDC IAM existant, appelez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveClientIDFromOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveClientIDFromOpenIDConnectProvider.html)

**Pour supprimer un fournisseur d'identité (AWS API) IAM OIDC**

1. (Facultatif) Pour obtenir la liste de tous les fournisseurs d'identité OIDC IAM de votre compte AWS , appelez l'opération suivante : 
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. (Facultatif) Pour obtenir des informations détaillées sur un fournisseur d'identité OIDC IAM, appelez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html)

1. Pour supprimer un fournisseur d'identité OIDC IAM, appelez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteOpenIDConnectProvider.html)

# Obtention de l’empreinte numérique d’un fournisseur d’identité OpenID Connect
<a name="id_roles_providers_create_oidc_verify-thumbprint"></a>

Lorsque vous [créez un fournisseur d’identité OpenID Connect (OIDC)](id_roles_providers_create_oidc.md) dans IAM, ce dernier exige l’empreinte de l’autorité de certification intermédiaire supérieure qui a signé le certificat utilisé par le fournisseur d’identité (IdP) externe. L'empreinte est une signature pour le certificat de l'autorité de certification qui a été utilisé pour émettre le certificat pour l'IdP compatible avec OIDC. Lorsque vous créez un fournisseur d'identité IAM OIDC, vous faites confiance aux identités authentifiées par cet IdP pour avoir accès à votre. Compte AWS En utilisant l’empreinte numérique du certificat de l’autorité de certification, vous approuvez n’importe quel certificat émis par cette autorité de certification avec le même nom de DNS que celui qui est enregistré. Ainsi, vous n'avez plus besoin de mettre à jour les approbations dans chaque compte lorsque vous renouvelez le certificat de signature de l'IdP.

**Important**  
Dans la plupart des cas, le serveur de fédération utilise deux certificats différents.  
Le premier établit une connexion HTTPS entre AWS et votre IdP. Elle doit être émise par une autorité de certification racine publique bien connue, telle qu’ AWS Certificate Manager. Cela permet au client de vérifier la fiabilité et l'état du certificat.
Le second est utilisé pour crypter les jetons et doit être signé par un opérateur privé ou public *racine* CA.

Vous pouvez créer un fournisseur d'identité IAM OIDC à [l' AWS Command Line Interface aide de l'API Outils pour Windows PowerShell ou IAM](id_roles_providers_create_oidc.md#manage-oidc-provider-cli). Lorsque vous utilisez ces méthodes, vous avez la possibilité de fournir manuellement une empreinte numérique. Si vous choisissez de ne pas inclure d’empreinte numérique, IAM récupérera l’empreinte numérique de l’autorité de certification intermédiaire supérieure du certificat du serveur IdP OIDC. Si vous choisissez d’inclure une empreinte numérique, vous devez l’obtenir manuellement et la fournir à AWS.

Lorsque vous créez un fournisseur d’identité OIDC avec la [console IAM](id_roles_providers_create_oidc.md), IAM tente de récupérer l’empreinte numérique de l’autorité de certification intermédiaire supérieure du certificat du serveur IdP OIDC pour vous. 

Nous vous recommandons d’obtenir également l’empreinte numérique de votre IdP OIDC manuellement et de vérifier qu’IAM a récupéré la bonne empreinte numérique. Pour plus d’informations sur l’obtention d’empreintes numériques de certificat, consultez les sections suivantes.

**Note**  
AWS sécurise les communications avec les fournisseurs d'identité OIDC (IdPs) à l'aide de notre bibliothèque d'autorités de certification racines fiables (CAs) pour vérifier le certificat TLS du point de terminaison JSON Web Key Set (JWKS). Si votre IdP OIDC repose sur un certificat qui n'est pas signé par l'un de ces fournisseurs de CAs confiance, ce n'est qu'alors que nous sécurisons les communications à l'aide des empreintes digitales définies dans la configuration de l'IdP. AWS reviendra à la vérification par empreinte digitale si nous ne parvenons pas à récupérer le certificat TLS ou si le protocole TLS v1.3 est requis.

## Obtention de l’empreinte numérique du certificat
<a name="oidc-obtain-thumbprint"></a>

Vous utilisez un navigateur Web et l’outil de ligne de commande OpenSSL pour obtenir l’empreinte numérique du certificat pour un fournisseur OIDC. Toutefois, vous n’avez pas besoin d’obtenir manuellement l’empreinte numérique du certificat pour créer un fournisseur d’identité OIDC. Vous pouvez utiliser la procédure suivante pour obtenir l’empreinte numérique du certificat de votre fournisseur OIDC.

**Pour obtenir l'empreinte d'un IdP OIDC**

1. Avant d'obtenir l'empreinte pour un IdP OIDC, vous devez obtenir l'outil de ligne de commande OpenSSL. Cet outil vous permet de télécharger la chaîne de certificats de l'IdP OIDC et de fournir une empreinte du certificat final dans la chaîne de certificats. Si vous avez besoin d'installer et de configurer OpenSSL, suivez les instructions des sections [Installer OpenSSL](#oidc-install-openssl) et [Configurer OpenSSL](#oidc-configure-openssl).

1. Commencez par l'URL de l'IdP OIDC (par exemple, `https://server.example.com`), puis ajoutez `/.well-known/openid-configuration` pour former l'URL du document de configuration de l'IdP, comme suit :

   **https://*server.example.com*/.well-known/openid-configuration**

   Ouvrez cette URL dans un navigateur Web, en la *server.example.com* remplaçant par le nom de votre serveur IdP. 

1. <a name="thumbstep2"></a>Dans le document affiché, utilisez la fonction **rechercher** de votre navigateur web pour localiser le texte `"jwks_uri"`. Immédiatement après le texte `"jwks_uri"`, vous verrez apparaître deux points (:) suivis d'une URL. Copiez le nom de domaine complet de l'URL. N'incluez pas `https://` ou le chemin d'accès qui suit le domaine de niveau supérieur. 

   ```
   {
    "issuer": "https://accounts.example.com",
    "authorization_endpoint": "https://accounts.example.com/o/oauth2/v2/auth",
    "device_authorization_endpoint": "https://oauth2.exampleapis.com/device/code",
    "token_endpoint": "https://oauth2.exampleapis.com/token",
    "userinfo_endpoint": "https://openidconnect.exampleapis.com/v1/userinfo",
    "revocation_endpoint": "https://oauth2.exampleapis.com/revoke",
    "jwks_uri": "https://www.exampleapis.com/oauth2/v3/certs",
   ...
   ```

1. Utilisez l'outil de ligne de commande OpenSSL pour exécuter la commande suivante. *keys.example.com*Remplacez-le par le nom de domaine dans lequel vous l'avez obtenu[Step 3](#thumbstep2).

   ```
   openssl s_client -servername keys.example.com -showcerts -connect keys.example.com:443
   ```

1. Dans votre fenêtre de commande, faites défiler jusqu'à afficher un certificat similaire à l'exemple suivant. Si plusieurs certificats sont affichés, recherchez le dernier certificat affiché (à la fin de la sortie de commande). Celui-ci contient le certificat de l'autorité de certification (CA) intermédiaire supérieure dans la chaîne d'autorité de certification.

   ```
   -----BEGIN CERTIFICATE-----
    MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
    VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
    b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
    BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
    MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
    VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
    b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
    YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
    21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
    rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
    Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
    nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
    FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
    NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
    -----END CERTIFICATE-----
   ```

   Copiez le certificat (notamment les lignes `-----BEGIN CERTIFICATE-----` et `-----END CERTIFICATE-----`) et collez-le dans un fichier texte. Puis enregistrez le fichier sous le nom **certificate.crt**.
**Note**  
La chaîne de certificats du fournisseur d’identité OIDC doit commencer par l’URL du domaine ou de l’émetteur, inclure tous les certificats intermédiaires (le cas échéant) et se terminer par le certificat racine. Si l’ordre de la chaîne de certificats est différent ou comprend des certificats en double ou supplémentaires, vous recevrez une erreur de non-concordance de signature et STS ne parvient pas à valider le jeton Web JSON (JWT). Corrigez l’ordre des certificats dans la chaîne renvoyée par le serveur pour résoudre l’erreur. Pour plus d’informations sur les normes relatives aux chaînes de certificats, consultez [certificate\$1list dans la RFC 5246](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2) sur le site Web de la série RFC.

1. Utilisez l'outil de ligne de commande OpenSSL pour exécuter la commande suivante.

   ```
   openssl x509 -in certificate.crt -fingerprint -sha1 -noout
   ```

   Votre fenêtre de commande affiche l'empreinte du certificat qui semble similaire à l'exemple suivant :

   ```
   SHA1 Fingerprint=99:0F:41:93:97:2F:2B:EC:F1:2D:DE:DA:52:37:F9:C9:52:F2:0D:9E
   ```

   Supprimez les deux points (:) de cette chaîne pour générer l'empreinte finale, comme ceci :

   ```
   990F4193972F2BECF12DDEDA5237F9C952F20D9E
   ```

1. Si vous créez le fournisseur d'identité IAM OIDC à l'aide de l' AWS CLI API Tools for Windows ou IAM PowerShell, la fourniture d'une empreinte numérique est facultative. Si vous choisissez de ne pas inclure d’empreinte numérique lors de la création, IAM récupérera l’empreinte numérique de l’autorité de certification intermédiaire supérieure du certificat du serveur IdP OIDC. Une fois le fournisseur d’identité IAM OIDC créé, vous pouvez comparer cette empreinte numérique à celle récupérée par IAM.

   Si vous créez un fournisseur d’identité IAM OIDC dans la console IAM, cette dernière tente de récupérer l’empreinte numérique de l’autorité de certification intermédiaire supérieure du certificat du serveur IdP OIDC pour vous. Vous pouvez comparer cette empreinte numérique à celle récupérée par IAM. Une fois le fournisseur d’identité IAM OIDC créé, vous pouvez consulter son empreinte numérique dans l’onglet **Vérification du point de terminaison** de la page de la console **Récapitulatif** du fournisseur OIDC.
**Important**  
Si l’empreinte numérique que vous avez obtenue ne correspond pas à celle que vous voyez dans les détails de l’empreinte numérique du fournisseur d’identité IAM OIDC, vous ne devez pas utiliser le fournisseur OIDC. À la place, supprimez le fournisseur OIDC créé et réessayez de créer le fournisseur OIDC après un certain temps. Vérifiez que les empreintes numériques correspondent avant d’utiliser le fournisseur. Si les empreintes ne correspondent toujours pas après une seconde tentative, visitez le [Forum IAM](https://forums.aws.amazon.com/forum.jspa?forumID=76) pour contacter AWS.

## Installer OpenSSL
<a name="oidc-install-openssl"></a>

Si OpenSSL n'est pas déjà installée, suivez les instructions de cette section.

**Pour installer OpenSSL sous Linux ou Unix**

1. Accédez à [OpenSSL: Source, Tarballs](https://openssl.org/source/) (https://openssl.org/source/).

1. Téléchargez la source la plus récente et créez le package.

**Pour installer OpenSSL sous Windows**

1. Accédez à [OpenSSL : distributions binaires](https://wiki.openssl.org/index.php/Binaries) (https://wiki.openssl. org/index.php/Binaries) pour obtenir la liste des sites à partir desquels vous pouvez installer la version Windows.

1. Suivez les instructions sur le site que vous avez sélectionné pour démarrer l'installation.

1. Si vous êtes invité à installer le package **Microsoft Visual C\$1\$1 2008 Redistributable** et qu'il n'est pas déjà installé sur votre système, choisissez le lien de téléchargement correspondant à votre environnement. Suivez les instructions fournies par l'**Assistant d'installation de Microsoft Visual C\$1\$1 2008 Redistributable**.
**Note**  
Si vous n'êtes pas sûr que Microsoft Visual C\$1\$1 2008 Redistributable soit déjà installé sur votre système, vous pouvez essayer d'installer d'abord OpenSSL. Le programme d'installation d'OpenSSL affiche une alerte si Microsoft Visual C\$1\$1 2008 Redistributable n'est pas encore installé. Veillez à installer l'architecture (32 ou 64 bits) correspondant à la version d'OpenSSL que vous installez.

1. Après avoir installé le package Microsoft Visual C\$1\$1 2008 Redistributable, sélectionnez la version des fichiers binaires OpenSSL correspondant à votre environnement et enregistrez le fichier localement. Démarrer l'**Assistant d'installation d'OpenSSL**.

1. Suivez les instructions décrites dans l'**Assistant d'installation d'OpenSSL**.

## Configurer OpenSSL
<a name="oidc-configure-openssl"></a>

Avant d'utiliser les commandes OpenSSL, vous devez configurer le système d'exploitation afin qu'il sache où OpenSSL est installé.

**Pour configurer OpenSSL sous Linux ou Unix**

1. Sur la ligne de commande, définissez la variable `OpenSSL_HOME` à l'emplacement d'installation d'OpenSSL :

   ```
   $ export OpenSSL_HOME=path_to_your_OpenSSL_installation
   ```

1. Définissez le chemin d'accès de sorte à inclure l'installation d'OpenSSL :

   ```
   $ export PATH=$PATH:$OpenSSL_HOME/bin
   ```
**Note**  
Les modifications apportées aux variables d'environnement à l'aide de la commande `export` sont valides uniquement pour la session actuelle. Vous pouvez apporter des modifications persistantes aux variables d'environnement en les définissant dans votre fichier de configuration de shell. Pour plus d'informations, consultez la documentation de votre système d'exploitation.

**Pour configurer OpenSSL sous Windows**

1. Ouvrez une fenêtre d'**invite de commande**.

1. Définissez la variable `OpenSSL_HOME` à l'emplacement d'installation d'OpenSSL :

   ```
   C:\> set OpenSSL_HOME=path_to_your_OpenSSL_installation
   ```

1. Définissez la variable `OpenSSL_CONF` à l'emplacement du fichier de configuration dans votre installation d'OpenSSL :

   ```
   C:\> set OpenSSL_CONF=path_to_your_OpenSSL_installation\bin\openssl.cfg
   ```

1. Définissez le chemin d'accès de sorte à inclure l'installation d'OpenSSL :

   ```
   C:\> set Path=%Path%;%OpenSSL_HOME%\bin
   ```
**Note**  
Toutes les modifications que vous apportez aux variables d'environnement Windows dans une fenêtre d'**invite de commandes** ne sont valides que pour la session de ligne de commande en cours. Vous pouvez apporter des modifications persistantes aux variables d'environnement en les définissant comme propriétés système. Les procédures précises dépendent de la version de Windows que vous utilisez. (Par exemple, dans Windows 7, ouvrez le **Panneau de configuration**, puis **Système et sécurité**, **Système**. Ensuite, choisissez **Paramètres système avancés**, **Avancés**, **Variables d'environnement**.) Pour de plus amples informations, veuillez consulter la documentation Windows.

# Contrôles des fournisseurs d’identité pour les fournisseurs OIDC partagés
<a name="id_roles_providers_oidc_secure-by-default"></a>

Pour les fournisseurs d'identité OpenID Connect (OIDC) partagés reconnus (IdPs), IAM exige une évaluation explicite des revendications spécifiques dans les politiques de confiance en matière de rôles. Ces demandes obligatoires, appelées *contrôles des fournisseurs d’identité*, sont évaluées par IAM lors de la création des rôles et des mises à jour des politiques de confiance. Si la politique de confiance des rôles n’évalue pas les contrôles requis par l’IdP OIDC partagé, la création ou la mise à jour du rôle échouera. Cela garantit que seules les identités autorisées de l’organisation concernée peuvent assumer des rôles et accéder aux ressources AWS . Ce contrôle de sécurité est crucial lorsque les fournisseurs OIDC sont partagés entre plusieurs clients AWS .



Les contrôles des fournisseurs d’identité ne seront pas évalués par IAM pour les politiques de confiance des rôles OIDC existantes. Pour toute modification apportée à la politique de confiance des rôles pour les rôles OIDC existants, IAM exigera que les contrôles du fournisseur d’identité soient inclus dans la politique de confiance des rôles.

## Types de fournisseurs OIDC
<a name="id_roles_providers_oidc_idp_types"></a>

IAM classe les fournisseurs d’identité OIDC en deux types distincts : **privés** et **partagés**. Un IdP OIDC privé peut être détenu et géré par une seule organisation ou peut être un locataire d’un fournisseur SaaS, son URL d’émetteur OIDC servant d’identifiant unique spécifique à cette organisation. En revanche, un IdP OIDC partagé est utilisé par plusieurs organisations, où l’URL de l’émetteur OIDC peut être identique pour toutes les organisations utilisant ce fournisseur d’identité partagé.

Le tableau ci-dessous décrit les principales différences entre les fournisseurs OIDC privés et partagés :


| Caractéristiques | Fournisseur OIDC privé | Fournisseur OIDC partagé | 
| --- | --- | --- | 
|  Emetteur  |  Unique à l’organisation  |  Partagé entre plusieurs organisations  | 
|  Informations de location  |  Communiquées par l’intermédiaire d’un émetteur unique  |  Communiquées par le biais de réclamations dans JWT  | 
|  Exigences en matière de politique de confiance  |  Aucune évaluation de demande spécifique requise  |  Évaluation des demandes spécifiques requise  | 

## Fournisseurs d’identité OIDC partagés avec contrôles des fournisseurs d’identité
<a name="id_roles_providers_oidc_idp_shared_oidc_secure_support"></a>

Lorsque vous créez ou modifiez un fournisseur OIDC dans IAM, le système identifie et évalue automatiquement les revendications requises pour les fournisseurs OIDC partagés reconnus. Si les contrôles du fournisseur d'identité ne sont pas configurés dans la politique de confiance des rôles, la création ou la mise à jour des rôles échouera avec une MalformedPolicyDocument erreur.

Le tableau suivant répertorie les fournisseurs OIDC partagés qui nécessitent des contrôles de fournisseur d’identité dans les politiques de confiance des rôles, ainsi que des informations supplémentaires pour vous aider à configurer les contrôles de fournisseur d’identité.


| IdP OIDC | URL OIDC | Demande de location | Demandes requises | 
| --- | --- | --- | --- | 
| [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) |  `cognito-identity.amazonaws.com`  | aud |  `cognito-identity.amazonaws.com:aud`  | 
| [Azure Sentinel](https://learn.microsoft.com/en-us/azure/defender-for-cloud/sentinel-connected-aws) |  https://sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d  |  sts:RoleSessionName  |  sts:RoleSessionName  | 
| [Buildkite](https://buildkite.com/docs/pipelines/security/oidc/aws) |  https://agent.buildkite.com  |  sub  |  agent.buildkite.com:sub  | 
| [Codefresh SaaS](https://codefresh.io/docs/docs/integrations/oidc-pipelines/) | https://oidc.codefresh.io | sub |  oidc.codefresh.io:sub  | 
| [DVC Studio](https://dvc.org/doc/studio/user-guide/openid-connect) | https://studio.datachain.ai/api | sub |  studio.datachain.ai/api:sub  | 
| [GitHub actions](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) | https://token.actions.githubusercontent.com | sub |  token.actions.githubusercontent.com:sub  | 
| [GitHub diffusion en continu du journal d'audit](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise) | https://oidc-configuration.audit-log.githubusercontent.com | sub |  oidc-configuration.audit-log.githubusercontent.com:sub  | 
| [GitHub vstoken](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) | https://vstoken.actions.githubusercontent.com | sub |  vstoken.actions.githubusercontent.com:sub  | 
| [GitLab](https://docs.gitlab.com/ci/cloud_services/aws/) | https://gitlab.com | sub |  gitlab.com:sub  | 
| [IBM Turbonomic SaaS\$1](https://www.ibm.com/docs/en/tarm/8.16.x?topic=turbonomic-setting-up-aws-iam-role-saas-deployments) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers_oidc_secure-by-default.html)  | sub |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers_oidc_secure-by-default.html)  | 
| [Pulumi Cloud](https://www.pulumi.com/docs/pulumi-cloud/deployments/oidc/aws/) | https://api.pulumi.com/oidc | aud |  api.pulumi.com/oidc:aud  | 
| [sandboxes.cloud](https://docs.sandboxes.cloud/docs/cloud-resources-setup) | https://sandboxes.cloud | aud |  sandboxes.cloud:aud  | 
| [Scalr](https://docs.scalr.io/docs/aws) | https://scalr.io | sub |  scalr.io:sub  | 
| [Shisho Cloud](https://shisho.dev/docs/g/getting-started/integrate-apps/aws/) | https://tokens.cloud.shisho.dev | sub |  tokens.cloud.shisho.dev:sub  | 
| [Terraform Cloud](https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/aws-configuration) | https://app.terraform.io | sub |  app.terraform.io:sub  | 
| [Upbound](https://docs.upbound.io/providers/provider-aws/authentication/) | https://proidc.upbound.io | sub |  proidc.upbound.io:sub  | 
| [Point de terminaison global Vercel](https://vercel.com/docs/oidc/reference) | https://oidc.vercel.com | aud |  oidc.vercel.com:aud  | 

\$1 IBM Turbonomic met régulièrement à jour l’URL de l’émetteur OIDC avec les nouvelles versions de la plateforme. Nous ajouterons d’autres émetteurs Turbonomic OIDC dans le champ d’application en tant que fournisseur partagé, si nécessaire.

Pour tout nouvel OIDC IdPs identifié par IAM comme étant partagé, les contrôles du fournisseur d'identité requis pour les politiques de confiance en matière de rôles seront documentés et appliqués de la même manière.

## Ressources supplémentaires
<a name="concept_additional_resources"></a>

Ressources supplémentaires :
+ Pour en savoir plus sur la création d’un rôle IAM pour une fédération OIDC, consultez [Création d’un rôle pour la fédération OpenID Connect (console)](id_roles_create_for-idp_oidc.md).
+ Pour obtenir la liste des clés de condition IAM pouvant être utilisées pour les demandes, consultez [Clés disponibles pour la AWS fédération OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif).

# Fédération SAML 2.0
<a name="id_roles_providers_saml"></a>

AWS prend en charge la fédération d'identité avec [SAML 2.0 (Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security), un standard ouvert utilisé par de nombreux fournisseurs d'identité (IdPs). Cette fonctionnalité permet l'authentification unique fédérée (SSO), afin que les utilisateurs puissent se connecter aux opérations de l' AWS API AWS Management Console ou les appeler sans que vous ayez à créer un utilisateur IAM pour tous les membres de votre organisation. En utilisant SAML, vous pouvez simplifier le processus de configuration de la fédération avec AWS, car vous pouvez utiliser le service de l'IdP au lieu d'[écrire un code proxy d'identité personnalisé](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html).

**Note**  
La fédération d'identité IAM SAML prend en charge les réponses SAML cryptées provenant de fournisseurs d'identité fédérés basés sur le protocole SAML (). IdPs IAM Identity Center et Amazon Cognito ne prennent pas en charge les assertions SAML chiffrées provenant des fournisseurs d’identité SAML IAM.  
Vous pouvez ajouter indirectement la prise en charge des assertions SAML chiffrées à la fédération des groupes d’identités Amazon Cognito avec les groupes d’utilisateurs Amazon Cognito. Les groupes d’utilisateurs disposent d’une fédération SAML indépendante de la fédération SAML IAM et qui prend en charge la [signature et le chiffrement SAML](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html). Bien que cette fonctionnalité ne s'étende pas directement aux groupes d'identités, les groupes d'utilisateurs peuvent être destinés IdPs aux groupes d'identités. Pour utiliser le chiffrement SAML avec des groupes d’identités, ajoutez un fournisseur SAML avec chiffrement à un groupe d’utilisateurs qui est un IdP d’un groupe d’identités.  
Votre fournisseur SAML doit être en mesure de chiffrer les assertions SAML à l’aide d’une clé fournie par votre groupe d’utilisateurs. Les groupes d’utilisateurs n’accepteront pas les assertions chiffrées à l’aide d’un certificat fourni par IAM.

La fédération IAM prend en charge les cas d'utilisation suivants : 
+ [**Accès fédéré pour permettre à un utilisateur ou à une application de votre organisation d'appeler des opérations AWS d'API**](#CreatingSAML-configuring). Ce cas d’utilisation est traité dans la section suivante. Vous utilisez une assertion SAML (dans le cadre de la réponse d'authentification) qui est générée dans votre organisation pour l'obtention d'informations d'identification temporaires. Ce scénario est similaire à d'autres scénarios de fédération pris en charge par IAM, tels que ceux décrits dans [Demande d’identifiants de sécurité temporaires](id_credentials_temp_request.md) et [Fédération OIDC](id_roles_providers_oidc.md). Toutefois, les systèmes SAML 2.0 de votre IdPs organisation gèrent de nombreux détails lors de l'exécution de l'authentification et de la vérification des autorisations.
+ [**Authentification unique (SSO) basée sur le Web AWS Management Console auprès de votre organisation**](id_roles_providers_enable-console-saml.md). Les utilisateurs peuvent se AWS connecter à un portail de votre organisation hébergé par un IdP compatible SAML 2.0, sélectionner une option d'accès et être redirigés vers la console sans avoir à fournir d'informations de connexion supplémentaires. Vous pouvez utiliser un IdP SAML tiers pour établir un accès SSO à la console ou créer un IdP personnalisé pour autoriser l'accès de vos utilisateurs externes à la console. Pour plus d'informations sur la création d'un IdP personnalisé, consultez la page [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).

**Topics**
+ [Utilisation de la fédération basée sur SAML pour l'accès à l'API AWS](#CreatingSAML-configuring)
+ [Présentation de la configuration de la fédération SAML 2.0](#CreatingSAML-configuring-IdP)
+ [Vue d'ensemble du rôle permettant d'autoriser l'accès fédéré par SAML à vos ressources AWS](#CreatingSAML-configuring-role)
+ [Identification unique des utilisateurs dans la fédération SAML](#CreatingSAML-userid)
+ [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md)
+ [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md)
+ [Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md)
+ [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md)
+ [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md)
+ [Affichage d’une réponse SAML dans votre navigateur](troubleshoot_saml_view-saml-response.md)

## Utilisation de la fédération basée sur SAML pour l'accès à l'API AWS
<a name="CreatingSAML-configuring"></a>

Supposons que vous voulez permettre aux employés de copier les données de leurs ordinateurs dans un dossier de sauvegarde. Vous créez une application que les utilisateurs peuvent exécuter sur leurs ordinateurs. Sur l’instance principale, l’application lit et écrit les objets dans un compartiment Amazon S3. Les utilisateurs n'ont pas un accès direct à AWS. À la place, le processus suivant est utilisé :

![\[Obtention d'informations d'identification de sécurité temporaires basée sur une assertion SAML\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/saml-based-federation-diagram.png)


1. A l'aide d'une application cliente, un utilisateur de l'organisation demande son authentification par l'IdP de l'organisation.

1. L'IdP authentifie l'utilisateur en le comparant à la base d'identités de l'organisation.

1. L'IdP crée une assertion SAML à l'aide des informations concernant l'utilisateur et l'envoie à l'application client. Lorsque vous activez le chiffrement SAML pour votre IdP SAML IAM, cette assertion est chiffrée par votre IdP externe.

1. L'application cliente appelle l' AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)API en transmettant l'ARN du fournisseur SAML, l'ARN du rôle à assumer et l'assertion SAML de l'IdP. Si le chiffrement est activé, l’assertion transmise via l’application cliente reste chiffrée pendant le transfert.

1. (Facultatif) AWS STS utilise la clé privée que vous avez téléchargée depuis votre IdP externe pour déchiffrer l'assertion SAML cryptée.

1. La réponse de l'API à l'application cliente inclut des informations d'identification de sécurité temporaires.

1. L'application cliente utilise ces informations d'identification de sécurité temporaires pour appeler les opérations d'API Amazon S3. 

## Présentation de la configuration de la fédération SAML 2.0
<a name="CreatingSAML-configuring-IdP"></a>

Avant de pouvoir utiliser la fédération basée sur SAML 2.0 comme décrit dans le scénario et le schéma précédents, vous devez configurer l'IdP de votre organisation et le vôtre de manière à ce qu'ils se fassent mutuellement confiance. Compte AWS La procédure suivante décrit le processus général permettant de configurer cette relation d'approbation. Votre organisation doit utiliser un [IdP prenant en charge SAML 2.0](id_roles_providers_saml_3rd-party.md), comme Microsoft Active Directory Federation Service (services ADFS qui font partie de Windows Server), Shibboleth, ou tout autre fournisseur compatible avec SAML 2.0. 

**Note**  
Pour améliorer la résilience de la fédération, nous vous recommandons de configurer votre IdP et votre fédération AWS pour prendre en charge plusieurs points de terminaison de connexion SAML. Pour plus de détails, consultez l'article du blog sur la AWS sécurité [Comment utiliser les points de terminaison SAML régionaux pour](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover) le basculement.

**Configurez l'IdP de votre organisation et AWS faites-vous confiance**

1. Inscrivez-vous AWS en tant que fournisseur de services (SP) auprès de l'IdP de votre organisation. Utilisez le document de métadonnées SAML à partir de `https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` 

   Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html).

   Vous pouvez éventuellement utiliser le document de métadonnées SAML à partir de `https://signin.aws.amazon.com/static/saml-metadata.xml` .

1. <a name="createxml"></a>À l’aide de l’IdP de l’organisation, vous générez un fichier XML de métadonnées SAML équivalent, capable de décrire cet IdP en tant que fournisseur d’identité IAM dans AWS. Il doit inclure le nom de l'émetteur, une date de création, une date d'expiration et les clés qui AWS peuvent être utilisées pour valider les réponses d'authentification (assertions) de votre organisation. 

   Si vous autorisez l'envoi d'assertions SAML chiffrées depuis votre IdP externe, vous devez générer un fichier de clé privée à l'aide de l'IdP de votre organisation et télécharger ce fichier dans votre configuration IAM SAML au format de fichier .pem. AWS STS a besoin de cette clé privée pour déchiffrer les réponses SAML qui correspondent à la clé publique téléchargée sur votre IdP.
**Note**  
Comme défini par la [version 1.0 du profil d’interopérabilité des métadonnées SAML V2.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html), IAM n’évalue pas et ne prend aucune mesure concernant l’expiration des certificats X.509 dans les documents de métadonnées SAML. Si vous êtes préoccupé par les certificats X.509 expirés, nous vous recommandons de surveiller les dates d’expiration des certificats et de les renouveler conformément aux politiques de gouvernance et de sécurité de votre organisation.

1. <a name="samlovrcreateentity"></a>Dans la console IAM, vous créez un fournisseur d’identité SAML. Au cours du processus, vous chargez le document de métadonnées SAML et la clé de déchiffrement privée générés par l’IdP de votre organisation à l’étape [Step 2](#createxml). Pour de plus amples informations, veuillez consulter [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md).

1. <a name="samlovrcreaterole"></a>Dans IAM, créez un ou plusieurs rôles IAM. Dans la politique de confiance du rôle, vous définissez le fournisseur SAML comme principal, ce qui établit une relation de confiance entre votre organisation et AWS. La politique d'autorisation du rôle détermine les actions que les utilisateurs de l'organisation sont autorisés à effectuer dans AWS. Pour de plus amples informations, veuillez consulter [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md).
**Note**  
Le SAML IDPs utilisé dans une politique de confiance des rôles doit se trouver dans le même compte que celui dans lequel se trouve le rôle.

1. Dans l'IdP de l'organisation, vous définissez les assertions qui associent les utilisateurs et les groupes de l'organisation aux rôles IAM. Notez que différents utilisateurs et groupes de l'organisation peuvent être associés à différents rôles IAM. La procédure exacte pour leur mappage dépend de l'IdP utilisé. Dans le [scénario précédent](#CreatingSAML-configuring) d'un dossier Amazon S3 pour les utilisateurs, tous les utilisateurs peuvent être associés au rôle qui fournit les autorisations Amazon S3. Pour de plus amples informations, veuillez consulter [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md).

   Si votre IdP active l'authentification unique sur la AWS console, vous pouvez configurer la durée maximale des sessions de console. Pour de plus amples informations, veuillez consulter [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md).

1. Dans l'application que vous créez, vous appelez l' AWS Security Token Service `AssumeRoleWithSAML`API en lui transmettant l'ARN du fournisseur SAML dans lequel vous l'avez créé[Step 3](#samlovrcreateentity), l'ARN du rôle dans lequel vous devez supposer que vous l'avez créé et l'assertion SAML concernant l'utilisateur actuel que vous obtenez de votre IdP. [Step 4](#samlovrcreaterole) AWS s'assure que la demande pour assumer le rôle provient de l'IdP référencé dans le fournisseur SAML. 

   Pour plus d'informations, consultez la section [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) dans la *référence de l'AWS Security Token Service API*. 

1. Si la demande aboutit, l'API retourne des informations d'identification de sécurité temporaires que votre application peut utiliser pour adresser des demandes signées à AWS. Votre application dispose d'informations sur l'utilisateur actuel et peut accéder aux compartiments Amazon S3 spécifiques à celui-ci, comme décrit dans le scénario précédent. 

## Vue d'ensemble du rôle permettant d'autoriser l'accès fédéré par SAML à vos ressources AWS
<a name="CreatingSAML-configuring-role"></a>

Les rôles que vous créez dans IAM définissent ce que les principaux fédérés SAML de votre organisation sont en mesure d’effectuer dans AWS. Lorsque vous créez la politique d'approbation pour le rôle, vous spécifiez le fournisseur d'identité SAML créé précédemment en tant que `Principal`. Vous pouvez également ajouter une `Condition` à la politique d'approbation, afin d'autoriser uniquement les utilisateurs correspondant à certains attributs SAML à accéder au rôle. Par exemple, il est possible de spécifier que seuls les utilisateurs dont l'affiliation SAML est `staff` (comme stipulé sur https://openidp.feide.no) sont autorisés à accéder au rôle, comme illustré dans l'exemple de politique suivant :

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://us-east-1.signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}
```

------

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws-cn:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:aud": "https://ap-east-1.signin.amazonaws.cn/saml",
                    "saml:iss": "https://openidp.feide.no"
                },
                "ForAllValues:StringLike": {
                    "saml:edupersonaffiliation": [
                        "staff"
                    ]
                }
            }
        }
    ]
}
```

------

**Note**  
Le SAML IDPs utilisé dans une politique de confiance des rôles doit se trouver dans le même compte que celui dans lequel se trouve le rôle.

La clé contextuelle `saml:aud` dans la politique spécifie l’URL que votre navigateur affiche lorsque vous vous connectez à la console. Cette URL de point de terminaison de connexion doit correspondre à l’attribut du destinataire de votre fournisseur d’identité. Vous pouvez inclure la connexion URLs dans certaines régions. AWS recommande d'utiliser des points de terminaison régionaux plutôt que des points de terminaison mondiaux pour améliorer la résilience de la fédération. Si vous n’avez configuré qu’un seul point de terminaison, vous ne pourrez pas vous fédérer à AWS dans le cas peu probable où le point de terminaison deviendrait indisponible. Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html).

L’exemple suivant montre le format d’URL de connexion avec la `region-code` facultative.

`https://region-code.signin.aws.amazon.com/saml`

Si le chiffrement SAML est obligatoire, l’URL de connexion doit inclure l’identifiant unique qu’ AWS attribue à votre fournisseur SAML, que vous trouverez sur la page de détails du fournisseur d’identité. Dans l’exemple suivant, l’URL de connexion comprend un identifiant unique d’IdP, qui nécessite l’ajout de /acs/ au chemin d’accès de connexion.

`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

Vous spécifiez la politique d'autorisation dans le rôle comme pour tout autre rôle. Par exemple, si les utilisateurs de votre organisation sont autorisés à administrer des instances Amazon Elastic Compute Cloud, vous devez explicitement autoriser les actions Amazon EC2 dans la politique d'autorisation, comme celles figurant dans la politique EC2 FullAccess gérée par **Amazon**. 

Pour plus d'informations sur les clés SAML que vous pouvez utiliser dans une politique, consultez [Clés disponibles pour la fédération basée sur SAML AWS STS](reference_policies_iam-condition-keys.md#condition-keys-saml).

## Identification unique des utilisateurs dans la fédération SAML
<a name="CreatingSAML-userid"></a>

Lors de la création de politiques d'accès dans IAM, il est souvent utile de pouvoir spécifier des autorisations en fonction de l'identité des utilisateurs. Par exemple, dans le cas d'utilisateurs fédérés à l'aide de SAML, une application peut conserver les informations dans Amazon S3 à l'aide d'une structure similaire à celle-ci : 

```
amzn-s3-demo-bucket/app1/user1
amzn-s3-demo-bucket/app1/user2
amzn-s3-demo-bucket/app1/user3
```

Vous pouvez créer le compartiment (`amzn-s3-demo-bucket`) et le dossier (`app1`) via la console Amazon S3 ou le AWS CLI, car il s'agit de valeurs statiques. Cependant, les dossiers spécifiques à l'utilisateur (*user1*,*user2*,*user3*, etc.) doivent être créés au moment de l'exécution à l'aide de code, car la valeur identifiant l'utilisateur n'est connue que la première fois que l'utilisateur se connecte dans le cadre du processus de fédération. 

Pour créer des politiques qui référencent des détails spécifiques à l'utilisateur dans le nom d'une ressource, l'identité de l'utilisateur doit figurer dans des clés SAML pouvant être utilisées dans les conditions des politiques. Les clés suivantes sont disponibles pour la fédération basée sur SAML 2.0 à utiliser dans les politiques IAM. Vous pouvez utiliser les valeurs retournées par les clés suivantes pour créer des identifiants utilisateur uniques pour des ressources comme des dossiers Amazon S3. 
+ `AWS`. Valeur de hachage basée sur la concaténation de la valeur de réponse `Issuer` (`saml:iss`) et d'une chaîne avec l'ID de compte `saml:namequalifier` et le nom convivial (dernière partie de l'ARN) du fournisseur SAML dans IAM. La concaténation de l'ID de compte et du nom convivial du fournisseur SAML est disponible dans les politiques IAM en tant que clé `saml:doc`. L'ID de compte et le nom du fournisseur doivent être séparés par un caractère « / », comme dans « 123456789012/provider\$1name ». Pour plus d'informations, reportez-vous à la clé `saml:doc` dans [Clés disponibles pour la fédération basée sur SAML AWS STS](reference_policies_iam-condition-keys.md#condition-keys-saml).

  La combinaison de `NameQualifier` et `Subject` permet d’identifier de manière unique un principal fédéré SAML. L’exemple de pseudo-code suivant montre comment cette valeur est calculée. Dans ce pseudo-code, `+` indique une concaténation, `SHA1` représente une fonction qui génère un résumé de message à l'aide de SHA-1 et `Base64` représente une fonction qui génère une version encodée en Base64 de la sortie de hachage.

   `Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )` 

   Pour plus d'informations sur les clés de politique disponibles pour la fédération SAML, consultez [Clés disponibles pour la fédération basée sur SAML AWS STS](reference_policies_iam-condition-keys.md#condition-keys-saml).
+ `saml:sub` (chaîne). Objet de la demande, qui inclut une valeur qui identifie de manière unique un utilisateur individuel au sein d'une organisation (par exemple, `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`). 
+ `saml:sub_type` (chaîne). Cette clé peut être `persistent`, `transient` ou l'URI `Format` complet des éléments `Subject` et `NameID` utilisés dans votre assertion SAML. Une va leur `persistent` indique que la valeur de `saml:sub` reste la même pour l'utilisateur pour toutes les sessions. Si la valeur est `transient`, l'utilisateur a une valeur `saml:sub` différente pour chaque session. Pour plus d'informations sur l'attribut `NameID` de l'élément `Format`, consultez [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). 

L'exemple suivant illustre une politique d'autorisation qui utilise les clés précédentes pour accorder des autorisations à un dossier spécifique à un utilisateur dans Amazon S3. La politique suppose que les objets Amazon S3 sont identifiés à l'aide d'un préfixe qui inclut à la fois `saml:namequalifier` et `saml:sub`. Notez que l'élément `Condition` inclut un test pour vérifier que la valeur de `saml:sub_type` est définie sur `persistent`. Si la valeur est `transient`, l'élément `saml:sub` de l'utilisateur peut être différent pour chaque session et vous ne devez pas combiner les valeurs pour identifier des dossiers spécifiques aux utilisateurs. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}
```

------

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}
```

------

Pour plus d'informations sur le mappage d'assertions de l'IdP et les clés de politique, consultez [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). 

# Création d’un fournisseur d’identité SAML dans IAM
<a name="id_roles_providers_create_saml"></a>

Un fournisseur d'identité SAML 2.0 IAM est une entité dans IAM qui décrit un service de fournisseur d'identité (IdP) externe prenant en charge la norme [SAML 2.0 (Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security). Vous utilisez un fournisseur d'identité IAM lorsque vous souhaitez établir un lien de confiance entre un IdP compatible SAML tel que Shibboleth ou Active Directory Federation Services AWS et afin que vos utilisateurs puissent accéder aux ressources. AWS Les fournisseurs d'identité SAML IAM sont utilisés en tant que principaux dans une politique d'approbation IAM. 

Pour plus d'informations sur ce scénario, consultez [Fédération SAML 2.0](id_roles_providers_saml.md).

Vous pouvez créer et gérer un fournisseur d'identité IAM dans AWS Management Console ou avec des AWS CLI outils pour Windows ou PowerShell des appels AWS d'API. 

Après avoir créé un fournisseur SAML, vous devez créer un ou plusieurs rôles IAM. Un rôle est une identité AWS qui ne possède pas ses propres informations d'identification (comme le fait un utilisateur). Mais dans ce contexte, un rôle est attribué dynamiquement à un principal fédéré SAML qui est authentifié par votre IdP. Le rôle permet à votre IdP de demander des informations d'identification de sécurité temporaires pour accéder à AWS. Les politiques attribuées au rôle déterminent ce que les utilisateurs sont autorisés à faire dans ce rôle AWS. Pour créer un rôle pour la fédération SAML, consultez [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md). 

Enfin, après avoir créé le rôle, vous complétez l'approbation SAML en configurant votre IdP avec les AWS informations et les rôles que vous souhaitez que vos principaux fédérés SAML utilisent. Il s'agit de la configuration de la relation d'approbation des parties utilisatrices entre votre IdP et AWS. Pour configurer la relation d'approbation des parties utilisatrices, consultez [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md). 

**Topics**
+ [Conditions préalables](#idp-manage-identityprovider-prerequisites)
+ [Création et gestion d’un fournisseur d’identité SAML IAM (console)](#idp-manage-identityprovider-console)
+ [Gestion des clés de chiffrement SAML](#id_federation_manage-saml-encryption)
+ [Création et gestion d’un fournisseur d’identité SAML IAM (AWS CLI)](#idp-create-identityprovider-CLI)
+ [Création et gestion d'un fournisseur d'identité (AWS API) IAM SAML](#idp-create-identityprovider-API)
+ [Étapes suivantes](#id_roles_create-for-saml-next-steps)

## Conditions préalables
<a name="idp-manage-identityprovider-prerequisites"></a>

Avant de créer un fournisseur d’identité SAML, vous devez obtenir les informations suivantes auprès de votre IdP.
+ Obtenez le document de métadonnées SAML auprès de votre IdP. Ce document inclut le nom de l'auteur, des informations d'expiration et des clés qui peuvent être utilisées pour valider les réponses d'authentification (assertions) SAML reçues du fournisseur d'identité (IdP). Pour générer le document de métadonnées, utilisez le logiciel de gestion des identités fournit par votre IdP externe.
**Important**  
Ce fichier de métadonnées inclut le nom de l'auteur, des informations d'expiration et des clés qui peuvent être utilisées pour valider les réponses d'authentification (assertions) SAML reçues du fournisseur d'identité (IdP). Le fichier de métadonnées doit être codé au format UTF-8 sans marque d'ordre d'octet (BOM). Pour supprimer la marque d'ordre d'octet (BOM), vous pouvez coder le fichier au format UTF-8 à l'aide d'un outil d'édition de texte, tel que Notepad\$1\$1.  
Le certificat X.509 inclus comme partie du document des métadonnées SAML doit utiliser une taille de clé au moins égale à 1 024 bits. De plus, le certificat X.509 doit également être exempt de toute extension répétée. Vous pouvez utiliser des extensions, mais elles ne peuvent apparaître qu'une seule fois dans le certificat. Si le certificat X.509 ne répond à aucune des conditions, la création de l’IdP échoue et renvoie une erreur « impossible d’analyser les métadonnées ».  
Comme défini par la [version 1.0 du profil d’interopérabilité des métadonnées SAML V2.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html), IAM n’évalue pas et ne prend aucune mesure concernant l’expiration des certificats X.509 dans les documents de métadonnées SAML. Si vous êtes préoccupé par les certificats X.509 expirés, nous vous recommandons de surveiller les dates d’expiration des certificats et de les renouveler conformément aux politiques de gouvernance et de sécurité de votre organisation.
+ Lorsque vous choisissez d’activer le chiffrement SAML, vous devez générer un fichier de clé privée à l’aide de votre IdP et charger ce fichier dans votre configuration SAML IAM au format .pem. AWS STS a besoin de cette clé privée pour déchiffrer les réponses SAML qui correspondent à la clé publique chargée vers votre IdP. Les algorithmes suivants sont pris en charge :
  + Algorithmes de chiffrement
    + AES-128
    + AES-256
    + RSA-OAEP
  + Algorithme de transport de clés
    + AES-CBC
    + AES-GCM

  Consultez la documentation de votre fournisseur d’identité pour connaître les étapes à suivre pour générer une clé privée.
**Note**  
IAM Identity Center et Amazon Cognito ne prennent pas en charge les assertions SAML chiffrées provenant des fournisseurs d’identité SAML IAM. Vous pouvez ajouter indirectement la prise en charge des assertions SAML chiffrées à la fédération des groupes d’identités Amazon Cognito avec les groupes d’utilisateurs Amazon Cognito. Les groupes d’utilisateurs disposent d’une fédération SAML indépendante de la fédération SAML IAM et qui prend en charge la [signature et le chiffrement SAML](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html). Bien que cette fonctionnalité ne s'étende pas directement aux groupes d'identités, les groupes d'utilisateurs peuvent s'appliquer IdPs aux groupes d'identités. Pour utiliser le chiffrement SAML avec des groupes d’identités, ajoutez un fournisseur SAML avec chiffrement à un groupe d’utilisateurs qui est un IdP d’un groupe d’identités.  
Votre fournisseur SAML doit être en mesure de chiffrer les assertions SAML à l’aide d’une clé fournie par votre groupe d’utilisateurs. Les groupes d’utilisateurs n’accepteront pas les assertions chiffrées à l’aide d’un certificat fourni par IAM.

Pour obtenir des instructions sur la façon de configurer la plupart des éléments disponibles IdPs pour les utiliser AWS, notamment sur la façon de générer le document de métadonnées SAML requis, consultez[Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md).

Pour obtenir de l’aide concernant la fédération SAML, consultez la section [Résolution des problèmes liés à la fédération SAML.](troubleshoot_saml.md)

## Création et gestion d’un fournisseur d’identité SAML IAM (console)
<a name="idp-manage-identityprovider-console"></a>

Vous pouvez utiliser le AWS Management Console pour créer, mettre à jour et supprimer des fournisseurs d'identité IAM SAML. Pour obtenir de l’aide concernant la fédération SAML, consultez la section [Résolution des problèmes liés à la fédération SAML.](troubleshoot_saml.md)

**Pour créer un fournisseur d'identité SAML IAM (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Fournisseurs d'identité**, puis **Ajouter un fournisseur**. 

1. Pour **Configurer le fournisseur**, sélectionnez **SAML**. 

1. Saisissez un nom pour le fournisseur d'identité.

1. Pour **Document de métadonnées**, sélectionnez **Choisir un fichier**, spécifiez le document de métadonnées SAML que vous avez téléchargé dans [Conditions préalables](#idp-manage-identityprovider-prerequisites).
**Note**  
L’attribut `validUntil` ou `cacheDuration` dans votre document de métadonnées SAML définit la **date d’expiration** pour le fournisseur d’identité. Si votre document de métadonnées SAML ne comprend pas d’attribut de période de validité, la **date d’expiration** ne correspondra pas à la date d’expiration de votre certificat X.509.  
IAM n’évalue pas et ne prend aucune mesure concernant l’expiration des certificats X.509 dans les documents de métadonnées SAML. Si vous êtes préoccupé par les certificats X.509 expirés, nous vous recommandons de surveiller les dates d’expiration des certificats et de les renouveler conformément aux politiques de gouvernance et de sécurité de votre organisation.

1. (Facultatif) Pour le **chiffrement SAML**, choisissez **Choisir un fichier**, puis sélectionnez le fichier de clé privée que vous avez créé dans [Conditions préalables](#idp-manage-identityprovider-prerequisites). Choisissez **Exiger le chiffrement** pour n’accepter que les requêtes chiffrées provenant de votre IdP.

1. (Facultatif) Pour **Ajouter des balises**, vous pouvez ajouter des paires clé-valeur pour vous aider à identifier et à organiser votre. IdPs Vous pouvez également utiliser des balises pour contrôler l'accès aux ressources AWS . Pour en savoir plus sur le balisage des fournisseurs d'identité SAML, reportez-vous à la section [Balisage de fournisseurs d’identité SAML IAM](id_tags_saml.md).

   Choisissez **Ajouter une balise**. Saisissez des valeurs pour chaque paire clé-valeur de balise. 

1. Vérifiez les informations que vous avez fournies. Lorsque vous avez terminé, sélectionnez **Ajouter un fournisseur**. 

1. Attribuez un rôle IAM à votre fournisseur d’identité. Ce rôle donne aux identités d'utilisateurs externes gérées par votre fournisseur d'identité l'autorisation d'accéder aux AWS ressources de votre compte. Pour en savoir plus sur la création de rôles pour la fédération d'identité, consultez la section [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md).
**Note**  
Le SAML IDPs utilisé dans une politique de confiance des rôles doit se trouver dans le même compte que celui dans lequel se trouve le rôle.

**Pour supprimer un fournisseur SAML (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Fournisseurs d'identité**.

1. Activez la case d'option en regard du fournisseur d'identité que vous souhaitez supprimer.

1. Sélectionnez **Delete (Supprimer)**. Une nouvelle fenêtre s'ouvre.

1. Confirmez que vous souhaitez supprimer le fournisseur en saisissant le mot `delete` dans le champ. Ensuite, choisissez **Supprimer**.

## Gestion des clés de chiffrement SAML
<a name="id_federation_manage-saml-encryption"></a>

Vous pouvez configurer les fournisseurs SAML IAM pour recevoir des assertions chiffrées dans la réponse SAML de votre IdP externe. Les utilisateurs peuvent jouer un rôle dans AWS les assertions SAML chiffrées en appelant. `[sts:AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)`

Le chiffrement SAML garantit que les assertions sont sécurisées lorsqu’elles passent par des intermédiaires ou des tiers. En outre, cette fonctionnalité vous aide à répondre aux exigences de FedRAMP ou de toute politique de conformité interne qui impose le chiffrement des assertions SAML.

Pour configurer un fournisseur d’identité SAML IAM, consultez [Création d’un fournisseur d’identité SAML dans IAM](#id_roles_providers_create_saml). Pour obtenir de l’aide concernant la fédération SAML, consultez la section [Résolution des problèmes liés à la fédération SAML.](troubleshoot_saml.md)

### Rotation d’une clé de chiffrement SAML
<a name="id_federation_manage-saml-keys-rotate"></a>

IAM utilise la clé privée que vous avez téléchargée auprès du fournisseur SAML IAM pour déchiffrer les assertions SAML chiffrées de votre IdP. Vous pouvez enregistrer jusqu’à deux fichiers de clés privées pour chaque fournisseur d’identité, ce qui vous permet d’effectuer une rotation des clés privées si nécessaire. Lorsque deux fichiers sont enregistrés, chaque requête tente d’abord d’être déchiffrée avec la date d’**ajout** la plus récente, puis IAM tente de déchiffrer la requête avec la date d’**ajout** la plus ancienne.

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation, sélectionnez **Fournisseurs d’identité**, puis sélectionnez votre fournisseur dans la liste. 

1. Choisissez l’onglet **Chiffrement SAML**, puis sélectionnez **Ajouter une nouvelle clé**.

1. Sélectionnez **Choisir un fichier** et chargez la clé privée que vous avez téléchargée depuis votre IdP sous forme de fichier .pem. Ensuite, choisissez **Ajouter une clé.**

1. Dans la section **Clés privées pour le déchiffrement SAML**, sélectionnez le fichier de clé privée expiré et choisissez **Supprimer.** Nous vous recommandons de supprimer la clé privée expirée après avoir ajouté une nouvelle clé privée afin de garantir la réussite de la première tentative de déchiffrement de votre assertion.

## Création et gestion d’un fournisseur d’identité SAML IAM (AWS CLI)
<a name="idp-create-identityprovider-CLI"></a>

Vous pouvez utiliser le AWS CLI pour créer, mettre à jour et supprimer des fournisseurs SAML. Pour obtenir de l’aide concernant la fédération SAML, consultez la section [Résolution des problèmes liés à la fédération SAML.](troubleshoot_saml.md)

**Pour créer un fournisseur d'identité IAM et télécharger un document de métadonnées (AWS CLI)**
+ Exécutez cette commande : [https://docs.aws.amazon.com/cli/latest/reference/iam/create-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-saml-provider.html) 

**Pour mettre à jour un fournisseur d’identité SAML IAM (AWS CLI)**

Vous pouvez mettre à jour le fichier de métadonnées, les paramètres de chiffrement SAML et effectuer la rotation des fichiers de déchiffrement par clé privée pour votre fournisseur SAML IAM. Pour faire pivoter les clés privées, ajoutez votre nouvelle clé privée, puis supprimez l’ancienne clé dans une demande distincte. Pour plus d’informations sur la rotation des clés privées, consultez [Gestion des clés de chiffrement SAML](#id_federation_manage-saml-encryption).
+ Exécutez cette commande : [https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html) 

**Pour baliser un fournisseur d'identité IAM existant (AWS CLI)**
+ Exécutez cette commande : [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html) 

**Pour afficher la liste des balises d'un fournisseur d'identité IAM existant (AWS CLI)**
+ Exécutez cette commande : [https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html) 

**Pour supprimer les balises d'un fournisseur d'identité IAM (AWS CLI) existant**
+ Exécutez cette commande : [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html) 

**Pour supprimer un fournisseur d'identité SAML IAM (AWS CLI)**

1. (Facultatif) Pour répertorier des informations pour tous les fournisseurs, comme l'ARN, la date de création et l'expiration, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-providers.html)

1. (Facultatif) Pour obtenir des informations sur un fournisseur spécifique, telles que l’ARN, la date de création, la date d’expiration, les paramètres de chiffrement et les informations relatives à la clé privée, exécutez la commande :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-saml-provider.html)

1. Pour supprimer un fournisseur d'identité IAM, exécutez la commande suivante :
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-saml-provider.html)

## Création et gestion d'un fournisseur d'identité (AWS API) IAM SAML
<a name="idp-create-identityprovider-API"></a>

Vous pouvez utiliser l' AWS API pour créer, mettre à jour et supprimer des fournisseurs SAML. Pour obtenir de l’aide concernant la fédération SAML, consultez la section [Résolution des problèmes liés à la fédération SAML.](troubleshoot_saml.md)

**Pour créer un fournisseur d'identité IAM et télécharger un document de métadonnées (AWS API)**
+ Appelez cette opération : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html)

**Pour mettre à jour un fournisseur d'identité (AWS API) IAM SAML**

Vous pouvez mettre à jour le fichier de métadonnées, les paramètres de chiffrement SAML et effectuer la rotation des fichiers de déchiffrement par clé privée pour votre fournisseur SAML IAM. Pour faire pivoter les clés privées, ajoutez votre nouvelle clé privée, puis supprimez l’ancienne clé dans une demande distincte. Pour plus d’informations sur la rotation des clés privées, consultez [Gestion des clés de chiffrement SAML](#id_federation_manage-saml-encryption).
+ Appelez cette opération : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html)

**Pour baliser un fournisseur d'identité (AWS API) IAM existant**
+ Appelez cette opération : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html)

**Pour répertorier les balises d'un fournisseur d'identité (AWS API) IAM existant**
+ Appelez cette opération : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html)

**Pour supprimer des balises sur un fournisseur d'identité (AWS API) IAM existant**
+ Appelez cette opération : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html)

**Pour supprimer un fournisseur d'identité (AWS API) IAM**

1. (Facultatif) Pour répertorier les informations relatives à tous IdPs, telles que l'ARN, la date de création et l'expiration, effectuez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviders.html)

1. (Facultatif) Pour obtenir des informations sur un fournisseur spécifique, telles que l’ARN, la date de création, la date d’expiration, les paramètres de chiffrement et les informations relatives à la clé privée, appelez l’opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetSAMLProvider.html)

1. Pour supprimer un IdP, appelez l'opération suivante :
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSAMLProvider.html)

## Étapes suivantes
<a name="id_roles_create-for-saml-next-steps"></a>

Après avoir créé un fournisseur d’identité SAML, configurez l’approbation des parties utilisatrices avec votre IdP. Vous pouvez également utiliser les demandes de la réponse d’authentification de votre IdP dans les politiques pour contrôler l’accès à un rôle.
+ Vous devez en informer l'IdP en AWS tant que fournisseur de services. Il s’agit là de l’ajout d’une relation d’approbation des parties utilisatrices entre votre IdP et AWS. Le processus exact utilisé pour ajouter une approbation de partie utilisatrice dépend de l'IdP que vous utilisez. Pour en savoir plus, consultez [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md).
+ Lorsque l'IdP envoie la réponse contenant les demandes à AWS, de nombreuses demandes entrantes sont associées à des clés de AWS contexte. Vous pouvez utiliser ces clés de contexte dans les politiques IAM à l’aide de l’élément Condition pour contrôler l’accès à un rôle. Pour plus d’informations, consultez [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md).

# Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes
<a name="id_roles_providers_create_saml_relying-party"></a>

Lorsque vous créez un fournisseur d'identité IAM et le rôle pour l'accès SAML, vous donnez des informations à AWS sur le fournisseur d'identité (IdP) externe et sur les actions que les utilisateurs sont autorisés à effectuer. L'étape suivante consiste à en informer l'IdP en AWS tant que fournisseur de services. Il s'agit là de l'ajout d'une *relation d'approbation des parties utilisatrices* entre votre IdP et AWS. Le processus exact utilisé pour ajouter une approbation de partie utilisatrice dépend de l'IdP que vous utilisez. Pour plus d'informations, consultez la documentation de votre logiciel de gestion des identités. 

Beaucoup vous IdPs permettent de spécifier une URL à partir de laquelle l'IdP peut lire un document XML contenant des informations et des certificats relatifs à une partie utilisatrice. Pour AWS, utilisez l'URL du point de terminaison de connexion. L’exemple suivant montre le format d’URL avec la `region-code` facultative.

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml`

Si le chiffrement SAML est requis, l'URL doit inclure l'identifiant unique AWS attribué à votre fournisseur SAML, que vous trouverez sur la page détaillée du fournisseur d'identité. L’exemple suivant montre une URL de connexion régionale qui comprend un identifiant unique.

`https://region-code.signin.aws.amazon.com/static/saml/IdP-ID/saml-metadata.xml`

Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Pour la AWS valeur, vous pouvez également utiliser le point de terminaison `https://signin.aws.amazon.com/saml` non régional.

S'il n'est pas possible de spécifier directement une URL, téléchargez le document XML à partir de l'URL ci-dessus et importez-le dans l'application de votre IdP. 

Vous devez également créer des règles de réclamation appropriées dans votre IdP qui spécifient en AWS tant que partie de confiance. *Lorsque l'IdP envoie une réponse SAML au point de AWS terminaison, elle inclut une *assertion* SAML contenant une ou plusieurs revendications.* Une demande contient des informations sur l'utilisateur et ses groupes. Une règle de demande mappe ces informations à des attributs SAML. Cela vous permet de vous assurer que les réponses d'authentification SAML de votre IdP contiennent les attributs AWS nécessaires utilisés dans les politiques IAM pour vérifier les autorisations des principaux fédérés SAML. Pour plus d’informations, consultez les rubriques suivantes :
+  [Vue d'ensemble du rôle permettant d'autoriser l'accès fédéré par SAML à vos ressources AWS](id_roles_providers_saml.md#CreatingSAML-configuring-role). Cette rubrique décrit les clés spécifiques à SAML dans les politiques IAM et explique comment les utiliser pour limiter les autorisations des principaux fédérés SAML.
+ [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). Cette rubrique explique comment configurer des demandes SAML contenant des informations sur l'utilisateur. Les demandes sont regroupées dans une assertion SAML et intégrées dans la réponse SAML qui est envoyée à AWS. Vous devez vous assurer que les informations requises par AWS les politiques sont incluses dans l'assertion SAML sous une forme AWS reconnaissable et utilisable.
+  [Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md). Cette rubrique fournit des liens vers la documentation fournie par des organisations tierces sur la manière d'intégrer des solutions d'identité à AWS. 

**Note**  
Pour améliorer la résilience de la fédération, nous vous recommandons de configurer votre IdP et votre fédération AWS pour prendre en charge plusieurs points de terminaison de connexion SAML. Pour plus de détails, consultez l'article du blog sur la AWS sécurité [Comment utiliser les points de terminaison SAML régionaux pour](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover) le basculement.

# Intégrez des fournisseurs de solutions SAML tiers avec AWS
<a name="id_roles_providers_saml_3rd-party"></a>

**Note**  
Nous vous recommandons de demander à vos utilisateurs humains d'utiliser des informations d'identification temporaires lors de l'accès AWS. Avez-vous envisagé d'en utiliser AWS IAM Identity Center ? Vous pouvez utiliser IAM Identity Center pour gérer de manière centralisée l'accès à plusieurs comptes Comptes AWS et fournir aux utilisateurs un accès par authentification unique protégé par le MFA à tous les comptes qui leur sont attribués à partir d'un seul endroit. Avec IAM Identity Center, vous pouvez créer et gérer les identités des utilisateurs dans IAM Identity Center ou vous connecter facilement à votre fournisseur d'identité compatible SAML 2.0 existant. 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 *.

Les liens suivants vous aident à configurer des solutions de fournisseur d'identité (IdP) SAML 2.0 tiers pour qu'elles fonctionnent avec AWS la fédération. Vérifiez auprès de votre fournisseur d’identité s’il prend en charge le chiffrement par jeton SAML. Pour les exigences de chiffrement SAML, consultez [Gestion des clés de chiffrement SAML](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption).

**Astuce**  
AWS Les ingénieurs de support peuvent aider les clients disposant de plans de support professionnels et professionnels à effectuer certaines tâches d'intégration impliquant des logiciels tiers. Pour obtenir la liste actuelle des plateformes et applications prises en charge, voir [Quels logiciels tiers sont pris en charge ?](https://aws.amazon.com/premiumsupport/faqs/#what3rdParty) dans le *AWS Support FAQs*.


****  

| Solution | En savoir plus | 
| --- | --- | 
| Auth0 |  [Intégration à Amazon Web Services](https://auth0.com/docs/integrations/aws) — Cette page du site Web de documentation Auth0 contient des liens vers des ressources qui décrivent comment configurer l'authentification unique (SSO) avec le AWS Management Console et inclut un exemple. JavaScript Vous pouvez configurer Auth0 pour transmettre les [balises de session](id_session-tags.md). Pour plus d'informations, voir [Auth0 annonce un partenariat avec AWS for IAM Session Tags](https://auth0.com/blog/auth0-partners-with-aws-for-iam-session-tags/). | 
| Microsoft Entra |  [Tutoriel : intégration de Microsoft Entra SSO à l'accès AWS à compte unique](https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial) — Ce didacticiel disponible sur le site Web de Microsoft explique comment configurer Microsoft Entra (anciennement Azure AD) en tant que fournisseur d'identité (IdP) à l'aide de la fédération SAML. | 
| Centrify | [Configurer Centrify et utiliser SAML pour le SSO pour AWS](https://docs.centrify.com/Content/Applications/AppsWeb/AmazonSAML.htm) — Cette page du site Web de Centrify explique comment configurer Centrify pour utiliser le SAML pour le SSO pour. AWS | 
| CyberArk | Configurez [CyberArk](https://docs.cyberark.com/Product-Doc/OnlineHelp/Idaptive/Latest/en/Content/Applications/AppsWeb/AmazonSAML.htm)pour fournir un accès Amazon Web Services (AWS) aux utilisateurs qui se connectent via l'authentification unique (SSO) SAML depuis le CyberArk portail utilisateur. | 
| ForgeRock | La [plateforme ForgeRock d'identité](https://backstage.forgerock.com/docs/am/6.5/saml2-guide/#saml2-create-hosted-idp) s'intègre à AWS. Vous pouvez configurer ForgeRock pour transmettre les [balises de session](id_session-tags.md). Pour de plus amples informations, veuillez consulter [Attribute Based Access Control for Amazon Web Services](https://www.forgerock.com/blog/attribute-based-access-control-amazon-web-services). | 
| Google Workspace | [Application cloud Amazon Web Services](https://support.google.com/a/answer/6194963) — Cet article du site d'aide aux administrateurs de Google Workspace explique comment configurer Google Workspace en tant qu'IdP SAML 2.0 AWS avec comme fournisseur de services. | 
| IBM | Vous pouvez configurer IBM pour transmettre des [balises de session](id_session-tags.md). Pour plus d'informations, consultez [IBM Cloud Identity IDaa S, l'un des premiers à prendre en charge les balises de AWS session](https://community.ibm.com/community/user/security/blogs/adam-case/2019/11/25/ibm-cloud-identity-idaas-one-of-first-to-support-aws-session-tags). | 
| JumpCloud |  [Octroi d'accès via des rôles IAM pour l'authentification unique (SSO) avec Amazon AWS](https://support.jumpcloud.com/support/s/article/Granting-Access-via-IAM-Roles-for-Single-Sign-On-SSO-with-Amazon-AWS) — Cet article du site JumpCloud Web explique comment configurer et activer l'authentification unique en fonction des rôles IAM pour. AWS | 
| Matrix42 | [MyWorkspace Guide de démarrage](https://myworkspace.matrix42.com/documents/MyWorkspace-Getting-Started-with-AWS.pdf) — Ce guide explique comment intégrer les services d' AWS identité à MyWorkspace Matrix42. | 
| Microsoft Active Directory Federation Services (AD FS) |  [Remarques sur le terrain : intégration du service de fédération Active Directory à AWS IAM Identity Center](https://aws.amazon.com/blogs/architecture/field-notes-integrating-active-directory-federation-service-with-aws-single-sign-on/) — Ce billet du blog sur AWS l'architecture explique le flux d'authentification entre AD FS et AWS IAM Identity Center (IAM Identity Center). IAM Identity Center prend en charge la fédération d'identité avec SAML 2.0, ce qui permet l'intégration avec les solutions AD FS. Les utilisateurs peuvent se connecter au portail IAM Identity Center avec leurs informations d'identification d'entreprise, ce qui réduit les coûts administratifs liés à la gestion des informations d'identification distinctes sur IAM Identity Center. Vous pouvez également configurer AD FS pour transmettre des [balises de session](id_session-tags.md). Pour de plus amples informations, veuillez consulter [Use attribute-based access control with AD FS to simplify IAM permissions management](https://aws.amazon.com/blogs/security/attribute-based-access-control-ad-fs-simplify-iam-permissions-management/).  | 
| miniOrange | [SSO pour AWS](http://miniorange.com/amazon-web-services-%28aws%29-single-sign-on-%28sso%29) — Cette page du site Web de MiniOrange explique comment établir un accès sécurisé AWS pour les entreprises et un contrôle total de l'accès aux AWS applications.  | 
| Okta |  [Integrating the Amazon Web Services Command Line Interface Using Okta](https://support.okta.com/help/Documentation/Knowledge_Article/Integrating-the-Amazon-Web-Services-Command-Line-Interface-Using-Okta) : sur cette page du site d'assistance Okta, vous apprenez à configurer Okta en vue d'une utilisation avec AWS. Vous pouvez configurer Okta pour transmettre des [balises de session](id_session-tags.md). Pour plus d'informations, consultez [Okta et AWS son partenariat pour simplifier l'accès via des balises de session](https://www.okta.com/blog/2019/11/okta-and-aws-partner-to-simplify-access-via-session-tags/). | 
| Okta | [AWS Fédération de comptes](https://help.okta.com/oie/en-us/Content/Topics/DeploymentGuides/AWS/aws-deployment.htm) : cette section du site Web d'Okta explique comment configurer et activer IAM Identity Center pour. AWS | 
| OneLogin | Dans la [OneLoginbase de connaissances](https://onelogin.service-now.com/support), SAML AWS recherchez une liste d'articles expliquant comment configurer les fonctionnalités d'IAM Identity Center entre OneLogin et AWS pour des scénarios à rôle unique et à rôles multiples. Vous pouvez configurer OneLogin pour transmettre les [balises de session](id_session-tags.md). Pour plus d'informations, voir [OneLogin et Tags de session : contrôle d'accès basé sur les attributs pour les AWS ressources](https://www.onelogin.com/blog/aws-session-tags-integration). | 
| Ping Identity |  [PingFederate AWS Connecteur](https://support.pingidentity.com/s/marketplace-integration-details?recordId=a7i1W0000004HBwQAM) : consultez les détails du PingFederate AWS connecteur, un modèle de connexion rapide permettant de configurer facilement une connexion d'authentification unique (SSO) et de provisionnement. Lisez la documentation et téléchargez le dernier PingFederate AWS connecteur pour les intégrations avec AWS. Vous pouvez configurer Ping Identity pour transmettre des [balises de session](id_session-tags.md). Pour de plus amples informations, veuillez consulter [Announcing Ping Identity Support for Attribute-Based Access Control in AWS](https://support.pingidentity.com/s/document-item?bundleId=integrations&topicId=pon1571779451105.html).  | 
| RadiantLogic | [Partenaires technologiques de Radiant Logic](http://www.radiantlogic.com/about/partners/technology-partners/) — Le service d'identité RadiantOne fédéré de Radiant Logic s'intègre AWS pour fournir un hub d'identité pour le SSO basé sur SAML.  | 
| RSA | [Amazon Web Services – Guide de mise en œuvre prêt pour RSA](https://community.rsa.com/s/article/Amazon-Web-Services-RSA-Ready-Implementation-Guide) fournit des conseils pour l’intégration d’ AWS et de RSA. Pour plus d’informations sur la configuration SAML, consultez [Amazon Web Services – Configuration SSO de ma page SAML – Guide de mise en œuvre prêt pour RSA](https://community.rsa.com/s/article/Amazon-Web-Services-SAML-My-Page-SSO-Configuration-RSA-Ready-Implementation-Guide). | 
| Salesforce.com |  [Comment configurer l'authentification unique depuis Salesforce vers AWS](https://developer.salesforce.com/page/Configuring-SAML-SSO-to-AWS) : cet article pratique sur le site destiné aux développeurs de Salesforce.com explique comment configurer un fournisseur d'identité (IdP) dans Salesforce et le configurer en tant que fournisseur de services. AWS  | 
| SecureAuth |  [AWS - SSO SecureAuth SAML](https://docs.secureauth.com/2104/en/amazon-web-services--aws---idp-initiated--integration-guide.html) — Cet article du site SecureAuth Web explique comment configurer l'intégration SAML AWS pour une appliance. SecureAuth  | 
| Shibboleth |  [Comment utiliser Shibboleth pour l'authentification unique AWS Management Console— Cet article du blog sur la AWS sécurité fournit un step-by-step didacticiel sur la façon de configurer Shibboleth et de le configurer en tant](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console) que fournisseur d'identité pour. AWS Vous pouvez configurer Shibboleth pour transmettre des [balises de session](id_session-tags.md). | 

Pour plus de détails, consultez la page des [partenaires IAM](https://aws.amazon.com/iam/partners/) sur le AWS site Web. 

# Configuration d’assertions SAML pour la réponse d’authentification
<a name="id_roles_providers_create_saml_assertions"></a>

Après avoir vérifié l'identité d'un utilisateur dans votre organisation, le fournisseur d'identité externe (IdP) envoie une réponse d'authentification à l'URL du point de terminaison de AWS connexion. La réponse est une demande POST incluant un jeton SAML conforme à la norme de [liaison HTTP POST pour SAML 2.0](http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) et contenant les éléments suivants, ou *demandes*. Vous les configurez dans votre IdP compatible avec SAML. Pour obtenir des instructions sur la procédure visant à entrer ces demandes, consultez la documentation de votre IdP.

Lorsque l'IdP envoie la réponse contenant les demandes à AWS, de nombreuses demandes entrantes sont associées à des clés de AWS contexte. Ces clés de contexte peuvent être vérifiées dans les politiques IAM à l'aide de l'élément `Condition`. Pour obtenir une liste des mappages disponibles, consultez la section [Mappage des attributs SAML avec des clés AWS contextuelles de politique de confiance](#saml-attribute-mapping).

## `Subject` et `NameID`
<a name="saml_subject-name-id"></a>

La réponse doit inclure exactement 1 élément `SubjectConfirmation` avec un élément `SubjectConfirmationData` comprenant à la fois l’attribut `NotOnOrAfter` et un attribut `Recipient`. L'attribut Recipient doit inclure une valeur correspondant à l'URL du point de terminaison de AWS connexion. Votre IdP peut utiliser le terme `ACS`, `Recipient`, ou `Target` pour faire référence à cet attribut.

Si le chiffrement SAML est obligatoire, l’URL de connexion doit inclure l’identifiant unique qu’ AWS attribue à votre fournisseur SAML, que vous trouverez sur la page de détails du fournisseur d’identité. L’exemple suivant montre le format d’URL de connexion avec la `region-code` facultative.

`https://region-code.signin.aws.amazon.com/saml`

Dans l’exemple suivant, l’URL de connexion comprend un identifiant unique, qui nécessite l’ajout de /acs/ au chemin d’accès de connexion.

`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Pour la AWS valeur, vous pouvez également utiliser le point de terminaison `https://signin.aws.amazon.com/saml` de connexion global.

Les éléments `NameID` peuvent avoir la valeur persistante, transitoire ou consister en l'URI de format complet tel que fourni par la solution d'IdP. La valeur persistante indique que la valeur dans `NameID` reste la même pour l'utilisateur entre les sessions. Si la valeur est transitoire, l'utilisateur a une valeur `NameID` différente pour chaque session. Les interactions avec authentification unique prennent en charge les types d'identifiants suivants :
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`

L'extrait suivant en présente un exemple. Substituez vos propres valeurs avec les valeurs marquées.

```
<Subject>
  <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">_cbb88bf52c2510eabe00c1642d4643f41430fe25e3</NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData NotOnOrAfter="2013-11-05T02:06:42.876Z" Recipient="https://region-code.signin.aws.amazon.com/saml/SAMLSP4SHN3UIS2D558H46"/>
  </SubjectConfirmation>
</Subject>
```

**Important**  
La clé de contexte `saml:aud` vient de l'attribut *destinataire* SAML, qui est l'équivalent SAML du champ d'audience d'OIDC, par exemple `accounts.google.com:aud`.

## Attribut SAML `PrincipalTag`
<a name="saml_role-session-tags"></a>

(Facultatif) Vous pouvez utiliser un élément `Attribute` dont l'attribut `Name` est défini sur `https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}`. Cet élément vous permet de transmettre des attributs en tant que balises de session dans l'assertion SAML. Pour de plus amples informations sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

Pour transmettre des attributs en tant que balises de session, incluez l'élément `AttributeValue` qui spécifie la valeur de la balise. Par exemple, pour transmettre les paires clé-valeur de balise `Project` = `Marketing` et `CostCenter` = `12345`, utilisez l'attribut suivant. Incluez un élément `Attribute` distinct pour chaque balise.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Marketing</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
```

Pour définir les balises ci-dessus comme transitives, incluez un autre élément `Attribute` dont l'attribut `Name` est défini sur `https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys`. Il s'agit d'un attribut facultatif à valeurs multiples qui définit vos balises de session comme transitives. Les balises transitives persistent lorsque vous utilisez la session SAML pour endosser un autre rôle dans AWS. Ceci est connu sous le nom de [chaînage de rôles](id_roles.md#iam-term-role-chaining). Par exemple, pour définir les balises `Principal` et `CostCenter` comme transitives, utilisez l'attribut suivant pour spécifier les clés.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>CostCenter</AttributeValue>
</Attribute>
```

## Attribut SAML `Role`
<a name="saml_role-attribute"></a>

Vous pouvez utiliser un élément `Attribute` avec l'attribut `Name` défini sur `https://aws.amazon.com/SAML/Attributes/Role` Cet élément contient un ou plusieurs éléments `AttributeValue` qui répertorient le fournisseur d'identité et le rôle IAM auxquels l'utilisateur est mappé par votre IdP. [Le rôle IAM et le fournisseur d'identité IAM sont spécifiés sous la forme d'une paire séparée par des ARNs virgules au même format que les `PrincipalArn` paramètres `RoleArn` et transmis au SAML. AssumeRoleWith](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) Cet élément doit contenir au moins une paire de fournisseur de rôles (élément `AttributeValue`) et peut contenir plusieurs paires. Si l'élément contient plusieurs paires, l'utilisateur doit choisir le rôle à endosser lorsqu'il utilise WebSSO afin de se connecter à la AWS Management Console.

**Important**  
La valeur de l'attribut `Name` dans la balise `Attribute` est sensible à la casse. Il doit être défini sur `https://aws.amazon.com/SAML/Attributes/Role` précisément.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
  <AttributeValue>arn:aws:iam::account-number:role/role-name1,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
  <AttributeValue>arn:aws:iam::account-number:role/role-name2,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
  <AttributeValue>arn:aws:iam::account-number:role/role-name3,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
</Attribute>
```

## Attribut SAML `RoleSessionName`
<a name="saml_role-session-attribute"></a>

Vous pouvez utiliser un élément `Attribute` avec l'attribut `Name` défini sur `https://aws.amazon.com/SAML/Attributes/RoleSessionName` Cet élément contient un élément `AttributeValue` qui fournit un identifiant pour les informations d'identification temporaires qui sont émises lorsque le rôle est endossé. Vous pouvez l'utiliser pour associer les informations d'identification temporaires à l'utilisateur qui utilise votre application. Cet élément est utilisé pour afficher les informations utilisateur dans le AWS Management Console. La valeur de l'élément `AttributeValue` doit comporter entre 2 et 64 caractères. Elle ne peut contenir que des caractères alphanumériques, des traits de soulignement et les caractères suivants : **. , \$1 = @ -** (tiret). Il ne doit pas contenir d'espace. La valeur est généralement un ID utilisateur (`john`) ou une adresse e-mail (`johndoe@example.com`). Il ne peut pas contenir d'espace, comme dans le nom complet de l'utilisateur (`John Doe`).

**Important**  
La valeur de l'attribut `Name` dans la balise `Attribute` est sensible à la casse. Il doit être défini sur `https://aws.amazon.com/SAML/Attributes/RoleSessionName` précisément.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName">
  <AttributeValue>user-id-name</AttributeValue>
</Attribute>
```

## Attribut SAML `SessionDuration`
<a name="saml_role-session-duration"></a>

(Facultatif) Vous pouvez utiliser un élément `Attribute` dont l'attribut `Name` est défini sur `https://aws.amazon.com/SAML/Attributes/SessionDuration"`. Cet élément contient un `AttributeValue` élément qui indique pendant combien de temps l'utilisateur peut accéder au AWS Management Console avant de devoir demander de nouvelles informations d'identification temporaires. La valeur est un nombre entier représentant le nombre de secondes pour la session. La valeur peut être comprise entre 900 secondes (15 minutes) et 43 200 secondes (12 heures). Si cet attribut n'est pas présent, la durée des informations d'identification est d'une d'heure (valeur par défaut du paramètre `DurationSeconds` de l'API `AssumeRoleWithSAML`).

Pour utiliser cet attribut, vous devez configurer le fournisseur SAML pour fournir un accès AWS Management Console par authentification unique au point de terminaison Web de connexion à la console à l'adresse. `https://region-code.signin.aws.amazon.com/saml` Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Vous pouvez éventuellement utiliser l'URL suivante : `https://signin.aws.amazon.com/static/saml`. Notez que cet attribut prolonge les sessions uniquement à la AWS Management Console. Il ne peut pas prolonger la durée de vie des autres informations d'identification. Cependant, s'il est présent dans un appel d'API `AssumeRoleWithSAML`, il peut être utilisé pour *raccourcir* la durée de la session. La durée de vie par défaut des informations d'identification renvoyées par l'appel est de 60 minutes. 

Notez également que si un attribut `SessionNotOnOrAfter` est également défini, la valeur la ***plus faible*** des deux attributs `SessionDuration` ou `SessionNotOnOrAfter` établit la durée maximale de la session de console.

Lorsque vous activez les sessions de console avec une durée prolongée, le risque de divulgation des informations d'identification augmente. Pour vous aider à réduire ce risque, vous pouvez immédiatement désactiver les sessions de console actives pour un rôle en sélectionnant **Revoke Sessions** (Révoquer les sessions) sur la page **Role Summary** (Résumé du rôle) de la console IAM. Pour plus d'informations, veuillez consulter [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md). 

**Important**  
La valeur de l'attribut `Name` dans la balise `Attribute` est sensible à la casse. Il doit être défini sur `https://aws.amazon.com/SAML/Attributes/SessionDuration` précisément.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SessionDuration">
  <AttributeValue>1800</AttributeValue>
</Attribute>
```

## Attribut SAML `SourceIdentity`
<a name="saml_sourceidentity"></a>

(Facultatif) Vous pouvez utiliser un élément `Attribute` dont l'attribut `Name` est défini sur `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Cet élément contient un élément `AttributeValue` qui fournit un identifiant pour la personne ou l'application qui utilise un rôle IAM. La valeur de l'identité source est conservée lorsque vous utilisez la session SAML pour assumer un autre rôle AWS connu sous le nom de [chaînage de rôles](id_roles.md#iam-term-role-chaining). La valeur de l'identité source est présente dans la demande pour chaque action effectuée durant la session de rôle. La valeur définie ne peut pas être modifiée durant la session de rôle. Les administrateurs peuvent ensuite utiliser AWS CloudTrail les journaux pour surveiller et auditer les informations d'identité source afin de déterminer qui a effectué des actions avec des rôles partagés.

La valeur de l'élément `AttributeValue` doit comporter entre 2 et 64 caractères. Elle ne peut contenir que des caractères alphanumériques, des traits de soulignement et les caractères suivants : **. , \$1 = @ -** (tiret). Il ne doit pas contenir d'espace. La valeur est généralement un attribut associé à l'utilisateur, comme un id utilisateur (`john`) ou une adresse e-mail (`johndoe@example.com`). Il ne peut pas contenir d'espace, comme dans le nom complet de l'utilisateur (`John Doe`). Pour de plus amples informations sur l'utilisation de l'identité source, veuillez consulter [Surveiller et contrôler les actions prises avec les rôles endossés](id_credentials_temp_control-access_monitor.md).

**Important**  
Si votre assertion SAML est configurée pour utiliser l'attribut [`SourceIdentity`](#saml_sourceidentity), votre politique d'approbation de rôle doit également inclure l'action `sts:SetSourceIdentity`, sinon l'opération endosser le rôle échouera. Pour de plus amples informations sur l'utilisation de l'identité source, veuillez consulter [Surveiller et contrôler les actions prises avec les rôles endossés](id_credentials_temp_control-access_monitor.md).

Pour transmettre un attribut d'identité source, incluez l'élément `AttributeValue` qui spécifie la valeur de l'identité source. Par exemple, pour transmettre l'identité source `Diego`, utilisez l'attribut suivant.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
  <AttributeValue>Diego</AttributeValue>
```

## Mappage des attributs SAML avec des clés AWS contextuelles de politique de confiance
<a name="saml-attribute-mapping"></a>

Les tableaux de cette section répertorient les attributs SAML utilisés couramment et leur correspondance avec les clés de contexte de condition de politique d'approbation dans AWS. Vous pouvez utiliser ces clés pour contrôler l'accès à un rôle. Pour ce faire, comparez les clés aux valeurs incluses dans les assertions qui accompagnent une demande d'accès SAML.

**Important**  
Ces clés sont disponibles uniquement dans les politiques d'approbation IAM (politiques qui déterminent qui peut endosser un rôle) et ne sont pas applicables aux politiques d'autorisations.

Dans le tableau des attributs eduPerson et eduOrg, les valeurs sont saisies sous forme de chaînes ou de listes de chaînes. Pour les valeurs de chaînes, vous pouvez tester ces valeurs dans des politiques d'approbation IAM à l'aide des conditions `StringEquals` ou `StringLike`. Concernant les valeurs qui contiennent une liste de chaînes, vous pouvez utiliser les [opérateurs d'ensemble de politique](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys) `ForAnyValue` et `ForAllValues` pour tester les valeurs dans les politiques de confiance.

**Note**  
Vous ne devez inclure qu'une seule réclamation par clé de AWS contexte. Si vous incluez plusieurs demandes, une seule d'entre elles sera mappée. 

Le tableau suivant présente les attributs eduPerson et eduOrg.


| Attribut eduPerson ou eduOrg (`Name` clé) | Correspond à cette clé AWS contextuelle (`FriendlyName`clé) | Type | 
| --- | --- | --- | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.1`   |   `eduPersonAffiliation`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.2`   |   `eduPersonNickname`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.3`   |   `eduPersonOrgDN`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.4`   |   `eduPersonOrgUnitDN`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.5`   |   `eduPersonPrimaryAffiliation`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.6`   |   `eduPersonPrincipalName`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.7`   |   `eduPersonEntitlement`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.8`   |   `eduPersonPrimaryOrgUnitDN`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.9`   |   `eduPersonScopedAffiliation`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.10`   |   `eduPersonTargetedID`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.11`   |   `eduPersonAssurance`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.2`   |   `eduOrgHomePageURI`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.3`   |   `eduOrgIdentityAuthNPolicyURI`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.4`   |   `eduOrgLegalName`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.5`   |   `eduOrgSuperiorURI`   |  Liste de chaînes  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.6`   |   `eduOrgWhitePagesURI`   |  Liste de chaînes  | 
|   `urn:oid:2.5.4.3`   |   `cn`   |  Liste de chaînes  | 

Le tableau suivant présente les attributs Active Directory.


| Attribut AD | Cartes correspondant à cette clé de AWS contexte | Type | 
| --- | --- | --- | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`  |  `name`  |  Chaîne  | 
|  `http://schemas.xmlsoap.org/claims/CommonName`  |  `commonName`  |  Chaîne  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`  |  `givenName`  |  Chaîne  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`  |  `surname`  |  Chaîne  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`  |  `mail`  |  Chaîne  | 
|  `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid`  |  `uid`  |  String  | 

Le tableau suivant présente les attributs X.500.


| Attribut X.500 | Cartes correspondant à cette clé de AWS contexte | Type | 
| --- | --- | --- | 
|  `2.5.4.3`  |  `commonName`  |  Chaîne  | 
|  `2.5.4.4`  |  `surname`  |  Chaîne  | 
|  `2.4.5.42`  |  `givenName`  |  Chaîne  | 
|  `2.5.4.45`  |  `x500UniqueIdentifier`  |  Chaîne  | 
|  `0.9.2342.19200300100.1.1`  |  `uid`  |  Chaîne  | 
|  `0.9.2342.19200300100.1.3`  |  `mail`  |  Chaîne  | 
|  `0.9.2342.19200300.100.1.45`  |  `organizationStatus`  |  String  | 

# Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console
<a name="id_roles_providers_enable-console-saml"></a>

Vous pouvez utiliser un rôle pour configurer votre fournisseur d'identité (IdP) conforme à SAML 2.0 et AWS pour autoriser les principaux fédérés SAML à accéder au. AWS Management Console Le rôle accorde aux utilisateurs les autorisations nécessaires pour effectuer des tâches dans la console. Si vous souhaitez donner aux principaux fédérés SAML d'autres moyens d'accès AWS, consultez l'une des rubriques suivantes :
+ AWS CLI: [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md)
+ Outils pour Windows PowerShell : [Basculer vers un rôle IAM (Outils pour Windows PowerShell)](id_roles_use_switch-role-twp.md)
+ AWS API : [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md)

## Présentation de
<a name="enable-console-saml-overview"></a>

Le diagramme suivant illustre le flux d'une authentification unique SAML. 

**Note**  
Cette utilisation spécifique de SAML diffère de l'utilisation plus générale illustrée ici [Fédération SAML 2.0](id_roles_providers_saml.md) car ce flux de travail ouvre le fichier AWS Management Console au nom de l'utilisateur. Cette procédure requiert l'utilisation du point de terminaison SSO AWS au lieu d'un appel direct de l'API `AssumeRoleWithSAML`. Le point de terminaison appelle l'API pour l'utilisateur, puis retourne une URL qui redirige automatiquement le navigateur de l'utilisateur vers AWS Management Console.

![\[Authentification unique (SSO) à la console de AWS gestion à l'aide de SAML\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/saml-based-sso-to-console.diagram.png)


Le diagramme suivant illustre les étapes suivantes :

1. L'utilisateur se rend sur le portail de l'organisation, puis choisit d'accéder à l'interface AWS Management Console. Dans votre organisation, le portail est généralement une fonction de votre IdP qui gère l'échange de confiance entre votre organisation et. AWS Par exemple, dans les services Active Directory Federation Services, l'URL du portail est : `https://ADFSServiceName/adfs/ls/IdpInitiatedSignOn.aspx` 

1. Le portail vérifie l'identité de l'utilisateur dans l'organisation.

1. Il génère ensuite une réponse d'authentification SAML contenant des assertions qui identifient l'utilisateur et incluent des attributs spécifiques à celui-ci. Vous pouvez également configurer votre IdP pour inclure un attribut d'assertion SAML appelé `SessionDuration` qui spécifie la durée de validité de la session de console. Vous pouvez également configurer le fournisseur d'identité pour qu'il transmette des attributs en tant que [balises de session](id_session-tags.md). Le portail envoie cette réponse au navigateur client.

1. Le navigateur client est redirigé vers le point de terminaison d'authentification AWS unique et publie l'assertion SAML. 

1. Le point de terminaison demande des informations d'identification de sécurité temporaires pour le compte de l'utilisateur et crée une URL de connexion à la console qui utilise ces informations. 

1. AWS renvoie l'URL de connexion au client sous forme de redirection.

1. Le navigateur client est redirigé vers AWS Management Console. Si la réponse d'authentification SAML inclut des attributs associés à plusieurs rôles IAM, l'utilisateur est d'abord invité à sélectionner le rôle utilisé pour accéder à la console. 

Du point de vue de l'utilisateur, le processus se déroule de manière transparente : l'utilisateur commence sur le portail interne de votre organisation et se retrouve sur le portail AWS Management Console, sans jamais avoir à fournir d'informations d' AWS identification.

Consultez les sections suivantes pour une présentation de la configuration de ce comportement, ainsi que des liens vers des procédures détaillées.

## Configurez votre réseau en tant que fournisseur SAML pour AWS
<a name="fedconsole-config-network-as-saml"></a>

Au sein du réseau de votre organisation, vous configurez votre base d'identités (par ex., Windows Active Directory) afin qu'il fonctionne de concert avec un fournisseur d'identité (IdP) SAML tel que Windows Active Directory Federation Services, Shibboleth, etc. À l'aide de l'IdP, vous générez un document de métadonnées qui décrit votre organisation en tant que fournisseur d'identité et inclut des clés d'authentification. Vous configurez également le portail de votre organisation pour acheminer les demandes des utilisateurs vers le point de terminaison AWS SAML AWS Management Console à des fins d'authentification à l'aide d'assertions SAML. La configuration de l'IdP pour la génération d'un fichier metadata.xml varie en fonction de l'IdP. Pour savoir comment procéder, reportez-vous à la documentation de votre IdP, ou consultez [Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md) pour obtenir des liens vers la documentation web de nombreux fournisseurs SAML pris en charge.

## Créer un fournisseur SAML dans IAM
<a name="fedconsole-create-saml-provider"></a>

Ensuite, vous vous connectez à la console IAM AWS Management Console et vous y accédez. Dans la console, vous créez un nouveau fournisseur SAML, c'est-à-dire une entité IAM qui contient des informations sur le fournisseur d'identité de votre organisation. Au cours du processus, vous téléchargez le document de métadonnées généré par le logiciel de l'IdP de votre organisation à l'étape précédente. Pour en savoir plus, consultez [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md). 

## Configurer les autorisations AWS pour les principaux fédérés SAML
<a name="fedconsole-grantperms"></a>

L'étape suivante consiste à créer un rôle IAM qui établit une relation d'approbation entre IAM et le fournisseur d'identités de votre organisation. Ce rôle doit identifier votre fournisseur d'identité en tant que principal (entité de confiance) pour les besoins de la fédération. Le rôle définit également ce que les utilisateurs authentifiés par l'IdP de votre organisation sont autorisés à faire. AWS Vous pouvez créer ce rôle à l'aide de la console IAM. Lorsque vous créez la politique d'approbation qui indique qui peut endosser le rôle, vous indiquez le fournisseur SAML que vous avez créé précédemment dans IAM. Vous indiquez également un ou plusieurs attributs SAML auxquels un utilisateur doit correspondre pour être autorisé à endosser le rôle. Par exemple, vous pouvez spécifier que seuls les utilisateurs dont la valeur `[eduPersonOrgDN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_edupersonorgdn)` SAML est `ExampleOrg` sont autorisés à se connecter. L'assistant de rôle ajoute automatiquement une condition pour tester l'attribut `saml:aud` afin de vérifier que le rôle est endossé uniquement pour la connexion à AWS Management Console.

Si le chiffrement SAML est obligatoire, l’URL de connexion doit inclure l’identifiant unique qu’ AWS attribue à votre fournisseur SAML, que vous trouverez sur la page de détails du fournisseur d’identité. La politique d'approbation du rôle peut se présenter comme suit :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:edupersonorgdn": "ExampleOrg",
                    "saml:aud": "https://region-code.signin.aws.amazon.com/saml/acs/SAMLSP4SHN3UIS2D558H46"
                }
            }
        }
    ]
}
```

------

**Note**  
Le SAML IDPs utilisé dans une politique de confiance des rôles doit se trouver dans le même compte que celui dans lequel se trouve le rôle.

Nous recommandons d’utiliser des points de terminaison régionaux pour l’attribut `saml:aud` ici `https://region-code.signin.aws.amazon.com/static/saml-metadata.xml`. Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html).

Dans la [politique d'autorisation](access_policies.md) du rôle, vous spécifiez les autorisations comme pour tout autre rôle, utilisateur ou groupe. Par exemple, si les utilisateurs de votre organisation sont autorisés à administrer les instances Amazon EC2, vous autorisez explicitement les actions Amazon EC2 dans la politique d'autorisation. Pour ce faire, vous pouvez affecter une [politique gérée](access_policies_manage-attach-detach.md) comme **Amazon EC2 Full Access**. 

Pour plus d'informations sur la création d'un rôle pour un IdP SAML, consultez [Création d’un rôle pour la fédération SAML 2.0 (console)](id_roles_create_for-idp_saml.md). 

## Terminer la configuration et créer des assertions SAML
<a name="fedconsole-configassertions"></a>

Indiquez à votre IdP SAML AWS qu'il s'agit de votre fournisseur de services en installant `saml-metadata.xml` le fichier trouvé `https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` sur ou. `https://signin.aws.amazon.com/static/saml-metadata.xml` Si SAMl le chiffrement est requis, le fichier se trouve à l'adresse`https://region-code.signin.aws.amazon.com/static/saml/SAMLSP4SHN3UIS2D558H46/saml-metadata.xml`.

Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). 

L'installation du fichier est différente selon votre IdP. Certains fournisseurs vous permettent d'entrer l'URL, après quoi ils récupèrent et installent le fichier pour vous. D’autres fournisseurs exigent que vous téléchargiez le fichier à partir de l’URL afin de le fournir en tant que fichier local. Pour plus d'informations, reportez-vous à la documentation de votre IdP, ou consultez [Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md) pour obtenir des liens vers la documentation web de nombreux fournisseurs SAML pris en charge.

Vous devez également configurer les informations que l'IdP doit transmettre à AWS en tant qu'attributs SAML dans le cadre de la réponse d'authentification. La plupart de ces informations apparaissent AWS sous forme de clés contextuelles de condition que vous pouvez évaluer dans vos politiques. Ces clés de condition garantissent que seuls les utilisateurs autorisés dans les contextes appropriés sont autorisés à accéder à vos ressources AWS . Vous pouvez spécifier des fenêtres horaires qui limitent l'utilisation de la console. Vous pouvez également spécifier la durée maximale (jusqu'à 12 heures) pendant laquelle les utilisateurs peuvent accéder à la console avant d'avoir à actualiser leurs informations d'identification. Pour en savoir plus, consultez [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md).

# Affichage d’une réponse SAML dans votre navigateur
<a name="troubleshoot_saml_view-saml-response"></a>

Les procédures suivantes décrivent l'affichage de la réponse SAML de votre fournisseur de services dans votre navigateur lors du dépannage d'un problème lié à SAML 2.0. 

Pour tous les navigateurs, accédez à la page où vous pouvez reproduire le problème. Ensuite, suivez les étapes correspondant au navigateur approprié :

**Topics**
+ [Google Chrome](#chrome)
+ [Mozilla Firefox](#firefox)
+ [Apple Safari](#safari)
+ [Que faire de la réponse SAML encodée au format Base64](#whatnext)

## Google Chrome
<a name="chrome"></a>

**Pour afficher une réponse SAML dans Chrome**

Ces étapes ont été testées à l'aide de la version 106.0.5249.103 (build officielle) (arm64) de Google Chrome. Si vous utilisez une autre version, il vous faudra peut-être modifier les étapes en conséquence.

1. Appuyez sur **F12** pour démarrer la console **Outils pour développeurs**.

1. Sélectionnez l'onglet **Réseau**, puis sélectionnez **Conserver le journal** en haut à gauche de la fenêtre **Outils pour développeurs**.

1. Reproduisez le problème.

1. (Facultatif) Si la colonne **Méthode** n'est pas visible dans le volet du journal **Outils pour développeurs** **Réseau**, cliquez avec le bouton droit sur l'étiquette d'une colonne et choisissez **Méthode** pour ajouter la colonne.

1. Recherchez une **Publication SAML** dans le volet du journal **Outils pour développeurs** **Réseau**. Sélectionnez cette ligne, puis affichez l'onglet **Charge utile** en haut. Recherchez l'**SAMLResponse**élément qui contient la demande codée. La valeur associée est la réponse encodée au format Base64.

## Mozilla Firefox
<a name="firefox"></a>

**Pour afficher une réponse SAML dans Firefox**

Cette procédure a été testée avec la version 105.0.3 (64 bits) de Mozilla Firefox. Si vous utilisez une autre version, il vous faudra peut-être modifier les étapes en conséquence.

1. Appuyez sur **F12** pour démarrer la console **Outils Web Developer**.

1. Sélectionnez l'onglet **Réseau**. 

1. Dans le coin supérieur droit de la fenêtre **Outils Web Developer**, cliquez sur options (petite icône d'engrenage). Sélectionnez **Conserver les journaux**. 

1. Reproduisez le problème.

1. (Facultatif) Si la colonne **Méthode** n'est pas visible dans le volet du journal **Outils Web Developer** **Réseau**, cliquez avec le bouton droit sur l'étiquette d'une colonne et choisissez **Méthode** pour ajouter la colonne.

1. Recherchez un **POST** **SAML** dans le tableau. Sélectionnez cette ligne, puis consultez l'onglet **Demande** et recherchez l'**SAMLResponse**élément. La valeur associée est la réponse encodée au format Base64.

## Apple Safari
<a name="safari"></a>

**Pour afficher une réponse SAML dans Safari**

Ces étapes ont été testées à l'aide de la version 16.0 (17614.1.25.9.10, 17614) d'Apple Safari. Si vous utilisez une autre version, il vous faudra peut-être modifier les étapes en conséquence.

1. Activez Web Inspector dans Safari. Ouvrez la fenêtre **Préférences**, sélectionnez l'onglet **Avancées**, puis sélectionnez **Afficher le menu Développement dans la barre de menus**.

1. Vous pouvez maintenant ouvrir Web Inspector. Choisissez **Développement** dans la barre de menu, puis sélectionnez **Afficher Web Inspector**.

1. Sélectionnez l'onglet **Réseau**.

1. Dans l'angle supérieur gauche de la fenêtre **Web Inspector**, choisissez les options (l'icône représentant un petit cercle contenant trois lignes horizontales). Sélectionnez **Conserver le journal**.

1. (Facultatif) Si la colonne **Méthode** n'est pas visible dans le volet du journal **Web Inspector** **Réseau**, cliquez avec le bouton droit sur l'étiquette d'une colonne et choisissez **Méthode** pour ajouter la colonne.

1. Reproduisez le problème.

1. Recherchez un **POST** **SAML** dans le tableau. Sélectionnez cette ligne, puis affichez l'onglet En-têtes.

1. Recherchez l'**SAMLResponse**élément qui contient la demande codée. Faites défiler la liste pour localiser l'élément `Request Data` nommé `SAMLResponse`. La valeur associée est la réponse encodée au format Base64.

## Que faire de la réponse SAML encodée au format Base64
<a name="whatnext"></a>

Une fois que vous avez trouvé l'élément contenant la réponse SAML encodée au format Base64 dans votre navigateur, copiez-le et utilisez votre outil de décodage Base64 favori pour extraire la réponse avec balise XML.

**Conseil de sécurité**  
Dans la mesure où les données de réponse SAML que vous affichez peuvent être des données de sécurité sensibles, il est recommandé de ne pas utiliser un décodeur Base64 *en ligne*. Préférez un outil installé sur un ordinateur local qui n'achemine pas les données SAML via le réseau.

**Option intégrée pour les systèmes Windows (PowerShell) :**

```
PS C:\> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("base64encodedtext"))
```

**Option intégrée pour les systèmes MacOS et Linux :**

```
$ echo "base64encodedtext" | base64 --decode
```

**Révision des valeurs dans le fichier décodé**  
Révisez les valeurs dans le fichier de réponse SAML décodé 
+ Vérifiez que la valeur de l’attribut saml:NameID correspond au nom d’utilisateur de l’utilisateur authentifié.
+ Vérifiez la valeur des https://aws.amazon.com/SAML/ attributs/rôles. L’ARN et le fournisseur SAML sont sensibles à la casse, et l’[ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) doit correspondre à la ressource de votre compte.
+ Vérifiez la valeur de https://aws.amazon.com/SAML/ Attributes/RoleSessionName. La valeur doit correspondre à la valeur de la [règle de demande](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_relying-party.html).
+ Si vous configurez la valeur d’attribut pour une adresse e-mail ou un nom de compte, assurez-vous que les valeurs sont correctes. Les valeurs doivent correspondre à l’adresse e-mail ou au nom de compte de l’utilisateur authentifié.

**Cérification des erreurs et confirmation de la configuration**  
Vérifiez si les valeurs contiennent des erreurs et confirmez que les configurations suivantes sont correctes.
+ Les règles de réclamation répondent aux éléments requis et ARNs sont toutes correctes. Pour de plus amples informations, veuillez consulter [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md).
+ Vous avez chargé le dernier fichier de métadonnées de votre IdP AWS dans votre fournisseur SAML. Pour de plus amples informations, veuillez consulter [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md).
+ Vous avez correctement configuré la politique de confiance du rôle IAM. Pour de plus amples informations, veuillez consulter [Méthodes pour assumer un rôle](id_roles_manage-assume.md).

# Fédérer les AWS identités avec des services externes
<a name="id_roles_providers_outbound"></a>

La fédération des identités sortantes IAM permet à vos AWS charges de travail d'accéder en toute sécurité à des services externes sans stocker d'informations d'identification à long terme. Vos AWS charges de travail peuvent demander des jetons Web JSON de courte durée (JWTs) au AWS Security Token Service (AWS STS) en appelant l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API. Ces jetons sont signés cryptographiquement, vérifiables publiquement et contiennent un ensemble complet de revendications qui affirment l'identité de votre AWS charge de travail auprès de services externes. Vous pouvez utiliser ces jetons avec un large éventail de fournisseurs de cloud tiers, de plateformes SaaS et d'applications auto-hébergées. Les services externes vérifient l'authenticité du jeton à l'aide AWS de clés de vérification publiées sur des points de terminaison connus et utilisent les informations contenues dans les jetons pour prendre des décisions d'authentification et d'autorisation.

La fédération des identités sortantes élimine le besoin de stocker des informations d'identification à long terme telles que des clés d'API ou des mots de passe dans le code de votre application ou des variables d'environnement, améliorant ainsi votre niveau de sécurité. Vous pouvez contrôler l'accès à la génération de jetons et appliquer les propriétés des jetons telles que les algorithmes de signature, les audiences autorisées et la durée à l'aide des politiques IAM. Toutes les demandes de jetons sont enregistrées AWS , fournissant des pistes d'audit complètes pour la surveillance de la sécurité et les rapports de conformité. Vous pouvez également personnaliser les jetons avec des balises qui apparaissent sous forme de revendications personnalisées, ce qui permet aux services externes de mettre en œuvre un contrôle d'accès précis basé sur les attributs.

## Cas d’utilisation courants
<a name="outbound-federation-use-cases"></a>

Grâce à la fédération des identités sortantes, vos AWS charges de travail peuvent en toute sécurité :
+ Accédez aux ressources et aux services des fournisseurs de cloud externes. Par exemple, une fonction Lambda traitant des données peut écrire les résultats dans le service de stockage d'un fournisseur de cloud externe ou interroger sa base de données.
+ Intégrez des fournisseurs externes software-as-a-service (SaaS) pour l'analyse, le traitement des données, la surveillance, etc. Par exemple, vos fonctions Lambda peuvent envoyer des métriques aux plateformes d'observabilité.
+ Authentifiez-vous auprès de vos propres applications hébergées sur AWS des fournisseurs de cloud externes ou des centres de données sur site, afin de mettre en place des architectures hybrides et multicloud sécurisées. Par exemple, vos AWS charges de travail peuvent interagir avec des applications conteneurisées exécutées dans votre cluster Kubernetes sur site.

## Comment ça marche
<a name="outbound-federation-how-it-works"></a>

![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/outbound-use-cases.png)


1. La fonction Lambda appelle l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API pour demander un jeton Web JSON (JWT) au AWS Security Token Service ().AWS STS

1. AWS STS valide la demande et renvoie un JWT signé à la fonction Lambda.

1. La fonction Lambda envoie le JWT au service externe.

1. Le service externe extrait l'URL de l'émetteur du jeton, vérifie qu'il correspond à un émetteur fiable connu et récupère les clés de vérification et les métadonnées depuis le AWS point de terminaison de découverte OIDC.

1. Le service externe utilise les clés de vérification pour vérifier la signature du jeton et valide les demandes telles que le délai d'expiration, le sujet et le public.

1. Une fois la validation réussie, le service externe autorise l'accès à la fonction Lambda.

# Commencer à utiliser la fédération des identités sortantes
<a name="id_roles_providers_outbound_getting_started"></a>

Ce guide explique comment activer la fédération d'identité sortante pour votre AWS compte et obtenir votre premier jeton Web JSON (JWT) (à l'aide de l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API). Vous allez activer la fonctionnalité, établir une relation de confiance avec un service externe, configurer les autorisations IAM et demander un jeton à l'aide de la AWS CLI ou du AWS SDK for Python (Boto3).

## Conditions préalables
<a name="outbound-federation-prerequisites"></a>

Avant de commencer, assurez-vous de disposer des éléments suivants :
+ Dernière version de la AWS CLI ou de Python 3.8 (ou version ultérieure) et Boto3 installés (pour des exemples de AWS SDK)
+ Un compte de service externe dans lequel vous pouvez configurer des relations de confiance (tel qu'un fournisseur de cloud externe, un fournisseur SaaS ou une application de test)

**Note**  
L'`GetWebIdentityToken`API n'est pas disponible sur le point de terminaison STS Global.
Les jetons Web JSON (JWTs) générés par l'`GetWebIdentityToken`API ne peuvent pas être utilisés pour la fédération OpenID Connect (OIDC) dans AWS (via l'[AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)API).

## Activez la fédération d'identité sortante pour votre compte
<a name="enable-outbound-federation"></a>

Vous devez activer la fédération d'identité sortante avant de pouvoir demander des jetons. Vous pouvez activer la fonctionnalité à l'aide de la console AWS de gestion ou par programmation à l'aide de l'[EnableOutboundWebIdentityFederation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOutboundWebIdentityFederation.html)API.

### Utilisation de la AWS CLI
<a name="enable-using-cli"></a>

```
aws iam enable-outbound-web-identity-federation
```

### Utilisation du AWS SDK pour Python
<a name="enable-using-sdk"></a>

```
import boto3

# Create IAM client
iam_client = boto3.client('iam')

# Enable outbound identity federation
response = iam_client.enable_outbound_web_identity_federation()
print(f"Feature enabled. Issuer URL: {response['IssuerUrl']}")
print(f"Status: {response['Status']}")
```

### Utilisation de la AWS console
<a name="enable-using-console"></a>

Accédez à IAM et sélectionnez **Paramètres du compte** dans la section **Gestion des accès** du menu de navigation de gauche

![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/outbound-screen-1.png)


Une fois cette fonctionnalité activée, notez l'URL de l'émetteur spécifique à votre compte. Vous utiliserez cette URL lors de la configuration des relations de confiance dans les services externes. Vous pouvez également récupérer l'URL de cet émetteur selon vos besoins à l'aide de l'[GetOutboundWebIdentityFederationInfo](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOutboundWebIdentityFederationInfo.html)API.

![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/outbound-screen-2.png)


## Établir une relation de confiance dans le service externe
<a name="establish-trust-relationship"></a>

Configurez le service externe pour qu'il approuve et accepte les jetons émis par votre AWS compte. Les étapes spécifiques varient selon le service, mais impliquent généralement :
+ Enregistrement de l'URL de l'émetteur de votre AWS compte en tant que fournisseur d'identité de confiance
+ Configuration des affirmations à valider (public, modèles de sujets)
+ Mappage des demandes de jetons avec des autorisations dans le service externe

Reportez-vous à la documentation du service externe pour obtenir des instructions de configuration détaillées.

## Configuration des autorisations IAM
<a name="configure-iam-permissions"></a>

Créez une politique IAM qui autorise l'appel de l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API et associez la politique à un rôle IAM qui doit générer des jetons.

Cet exemple de politique accorde l'accès à la génération de jetons avec des restrictions spécifiques. Il permet de demander des jetons uniquement pour « https://api.example.com » en tant que public et impose une durée de vie maximale des jetons de 5 minutes (300 secondes). Consultez la [Clés de contexte IAM et de AWS STS condition](reference_policies_iam-condition-keys.md) liste des clés de condition que vous pouvez utiliser pour appliquer les propriétés des jetons.

### Exemple de politique IAM
<a name="example-iam-policy"></a>

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "sts:IdentityTokenAudience": "https://api.example.com"
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                }
            }
        }
    ]
}
```

## Demandez votre premier jeton Web JSON (JWT)
<a name="request-first-jwt"></a>

Vous pouvez demander un jeton Web JSON à l'aide de l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API. Vous pouvez spécifier les paramètres suivants lorsque vous appelez l'API :
+ **Public (obligatoire) :** le destinataire prévu du jeton. Cette valeur renseigne la réclamation « aud » dans le JWT. Les services externes valident cette affirmation pour s'assurer que le jeton leur était destiné.
+ **SigningAlgorithm (obligatoire) :** algorithme cryptographique utilisé pour signer le jeton. Les valeurs valides sont ES384 et RS256. ES384 À utiliser pour une sécurité et des performances optimales, ou RS256 pour une compatibilité accrue avec les systèmes qui ne prennent pas en charge l'ECDSA.
+ **DurationSeconds (facultatif) :** durée de vie du jeton en secondes. Les valeurs valides sont comprises entre 60 et 3 600. La valeur par défaut est 300 (5 minutes). Nous recommandons de raccourcir la durée de vie des jetons pour une sécurité accrue.
+ **Tags (facultatif) :** liste de paires clé-valeur à inclure en tant que revendications personnalisées dans le jeton. Les services externes peuvent utiliser ces demandes pour obtenir une autorisation précise.

L'API renvoie les champs suivants :
+ **IdentityToken:** Le JWT signé sous forme de chaîne codée en base64url. Incluez ce jeton dans les demandes adressées aux services externes.
+ **Expiration :** horodatage UTC indiquant la date d'expiration du jeton.

### Utilisation de la AWS CLI
<a name="using-aws-cli"></a>

```
aws sts get-web-identity-token \
    --audience "https://api.example.com" \
    --signing-algorithm ES384 \
    --duration-seconds 300 \
    --tags Key=team,Value=data-engineering \
           Key=environment,Value=production \
           Key=cost-center,Value=analytics
```

### Utilisation du AWS SDK pour Python
<a name="using-aws-sdk-python"></a>

```
import boto3

sts_client = boto3.client('sts')

response = sts_client.get_web_identity_token(
    Audience=['https://api.example.com'],
    DurationSeconds=300,
    SigningAlgorithm='RS256',
    Tags=[
        {'Key': 'team', 'Value': 'data-engineering'},
        {'Key': 'environment', 'Value': 'production'},
        {'Key': 'cost-center', 'Value': 'analytics'}
    ]
)

token = response['WebIdentityToken']
```

Vous pouvez également décoder le JWT pour inspecter son contenu à l'aide de bibliothèques JWT standard telles que PyJWT, Python-JOSE pour Python, Nimbus JOSE\$1JWT pour Java ou de débogueurs tels que jwt.io. Reportez-vous à [Comprendre les réclamations symboliques](id_roles_providers_outbound_token_claims.md) pour plus d'informations sur les réclamations incluses dans le jeton.

## Utiliser le jeton avec un service externe
<a name="use-token-with-external-service"></a>

Après avoir reçu le jeton, incluez-le dans les demandes adressées au service externe. La méthode varie en fonction du service, mais la plupart des services acceptent les jetons dans l'en-tête Authorization. Le service externe doit mettre en œuvre une logique de validation des jetons qui récupère les clés JWKS depuis le point de terminaison bien connu de votre émetteur, vérifie la signature du jeton et valide les demandes essentielles avant d'accorder l'accès à vos charges de travail. AWS 

## Récupérez les clés de vérification et les métadonnées depuis les points de terminaison OpenID Connect (OIDC)
<a name="fetch-verification-keys"></a>

L'URL unique de l'émetteur de votre AWS compte héberge les points de terminaison de découverte OpenID Connect (OIDC) qui contiennent les clés de vérification et les métadonnées nécessaires à la vérification des jetons.

L'URL du point de terminaison de découverte OIDC contient les métadonnées que certains fournisseurs utilisent pour vérifier les jetons. Il est disponible à l'adresse suivante :

```
{issuer_url}/.well-known/openid-configuration
```

Le point de terminaison JWKS (JSON Web Key Set) contient les clés utilisées pour vérifier les signatures de jetons. Il est disponible à l'adresse suivante :

```
{issuer_url}/.well-known/jwks.json
```

### Récupérez JWKS en utilisant curl
<a name="fetch-jwks-curl"></a>

```
curl https://{issuer_url}/.well-known/jwks.json
```

Réponse :

```
{
  "keys": [
    {
      "kty": "EC",
      "use": "sig",
      "kid": "key-id-1",
      "alg": "ES384",
      "crv": "P-384",
      "x": "base64-encoded-x-coordinate",
      "y": "base64-encoded-y-coordinate"
    },
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "key-id-2",
      "n": "base64-encoded-modulus",
      "e": "AQAB"
    }
  ]
}
```

### Utilisation du AWS SDK pour Python
<a name="fetch-using-sdk"></a>

```
import requests

# Fetch Openid Configuration
open_id_config_response = requests.get("https://{issuer_url}/.well-known/openid-configuration")
open_id_config = open_id_config_response.json()

# Fetch JWKS
jwks_response = requests.get("https://{issuer_url}/.well-known/jwks.json")
jwks = jwks_response.json()
```

Nous vous recommandons de mettre ces clés en cache afin d'éviter de les récupérer à chaque vérification de jeton.

### Validations de réclamations essentielles
<a name="essential-claim-validations"></a>
+ **Sujet (sous) :** Vérifiez que l'objet de la réclamation contient le modèle d'ARN principal IAM attendu.
+ **Expiration (exp) :** assurez-vous que le jeton n'a pas expiré. Les bibliothèques JWT gèrent généralement cela automatiquement.
+ **Audience (aud) :** Vérifiez que l'audience correspond à la valeur attendue. Cela empêche l'utilisation de jetons destinés à d'autres services avec les vôtres.
+ **Émetteur (iss) :** Vérifiez que l'émetteur correspond au (x) AWS compte (s) auquel vous faites confiance. Tenez à jour une liste d'émetteurs URLs fiables.

Dans la mesure du possible, vous devez valider des demandes AWS spécifiques supplémentaires afin de mettre en œuvre un contrôle d'accès précis dans votre service externe. Par exemple, validez la revendication org\$1id pour restreindre l'accès aux principaux IAM de votre AWS organisation, cochez principal\$1tags pour appliquer le contrôle d'accès basé sur les attributs (par exemple en autorisant uniquement les environnements de production ou des équipes spécifiques), ou vérifiez les affirmations relatives au contexte de session telles que lambda\$1source\$1function\$1arn ou ec2\$1instance\$1source\$1vpc pour restreindre l'accès en fonction de la ressource de calcul. Reportez-vous à [la section Comprendre les réclamations liées aux jetons](id_roles_providers_outbound_token_claims.md) pour obtenir la liste complète des réclamations incluses dans le jeton.

# Comprendre les réclamations symboliques
<a name="id_roles_providers_outbound_token_claims"></a>

Lorsque vous appelez l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API, le AWS Security Token Service renvoie un jeton Web JSON (JWT) signé qui contient un ensemble de revendications représentant l'identité du principal IAM. Ces jetons sont conformes à la [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). La compréhension de la structure et du contenu de ces jetons vous permet de mettre en œuvre des flux d'authentification sécurisés, de configurer des validations de réclamations appropriées dans les services externes et d'utiliser efficacement les demandes personnalisées pour un contrôle d'accès précis.

Le JWT inclut des revendications OpenID Connect (OIDC) standard telles que le sujet (« sub »), l'audience (« aud »), l'émetteur (« iss ») afin de faciliter l'interopérabilité entre les différents services externes. AWS STS remplit le jeton avec des revendications AWS spécifiques à l'identité (comme l'ID de AWS compte et les balises Principal) et des revendications de contexte de session (comme une EC2 instance ARNs) le cas échéant. Vous pouvez également ajouter des revendications personnalisées au jeton en les transmettant sous forme de balises de requête à l'[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API. Les revendications AWS spécifiques à l'identité, les revendications relatives au contexte de session et les revendications personnalisées sont imbriquées sous l'espace de noms «https://sts.amazonaws.com/» du jeton.

Reportez-vous à l'exemple de jeton ci-dessous pour obtenir la liste des réclamations incluses dans le jeton. Veuillez noter que toutes ces réclamations peuvent ne pas être présentes sous forme de jeton en même temps. 

```
{
  "iss": "https://abc123-def456-ghi789-jkl012.tokens.sts.global.api.aws",
  "aud": "https://api.example.com",
  "sub": "arn:aws:iam::123456789012:role/DataProcessingRole",
  "iat": 1700000000,
  "exp": 1700000900,
  "jti": "xyz123-def456-ghi789-jkl012",
  "https://sts.amazonaws.com/": {
    "aws_account": "123456789012",
    "source_region": "us-east-1",
    "org_id": "o-abc1234567",
    "ou_path": "o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/",
    "principal_tags": {
      "environment": "production",
      "team": "data-engineering",
      "cost-center": "engineering"
    },
    "lambda_source_function_arn": "arn:aws:lambda:us-east-1:123456789012:function:process-data",
    "request_tags": {
        "job-id": "job-2024-001",
        "priority": "high",
        "data-classification": "sensitive"
    }
  }
}
```

## Réclamations standard
<a name="standard-claims"></a>

Les allégations OIDC standard présentes dans les jetons facilitent l'interopérabilité avec un large éventail de services externes. Ces affirmations peuvent être validées à l'aide de la plupart des bibliothèques JWT.


| Demander | Nom | Description | Exemple de valeur | 
| --- | --- | --- | --- | 
| iss | Emetteur | URL de l'émetteur spécifique à votre compte. Les services externes valident cette réclamation pour s'assurer qu'elle correspond à leur émetteur de confiance. | https://abc123-def456-ghi789-jkl012.tokens.sts.global.api.aws | 
| aud | Public ciblé | Destinataire prévu pour le jeton spécifié dans la [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)demande. | https://api.example.com | 
| sub | Sujet | L'ARN du principal IAM qui a demandé le jeton. | arn:aws:iam : :123456789012:role/ DataProcessingRole | 
| iat | Délivré à | NumericDate valeur qui identifie l'heure à laquelle le JWT a été émis. | 1700000000 | 
| exp | Expiration | NumericDate valeur qui identifie l'heure d'expiration à laquelle ou après laquelle le JWT NE DOIT PAS être accepté pour traitement. | 1700000900 | 
| jti | IDENTIFIANT JWT | Identifiant unique pour cette instance de jeton. | xyz123-def456-ghi789-jkl012 | 

## Réclamations personnalisées
<a name="custom-claims"></a>

Outre les revendications OIDC standard, AWS STS ajoute des allégations concernant l'identité et le contexte de session, le cas échéant. Vous pouvez également ajouter vos propres revendications au jeton en les transmettant sous forme de balises de demande. Les revendications personnalisées sont imbriquées sous l'espace de noms https://sts.amazonaws.com/.

### AWS demandes d'identité
<a name="aws-identity-claims"></a>

Ces réclamations fournissent des informations détaillées sur votre AWS compte, la structure de votre organisation et le directeur d'IAM.


| Demander | Description | Cartes vers la clé de condition | Exemple de valeur | 
| --- | --- | --- | --- | 
| compte aws\$1 | L'identifiant AWS de votre compte | [lois : PrincipalAccount](reference_policies_condition-keys.md#condition-keys-principalaccount) | 123456789012 | 
| source\$1region | La AWS région où le jeton a été demandé | [lois : RequestedRegion](reference_policies_condition-keys.md#condition-keys-requestedregion) | us-east-1 | 
| org\$1id | Votre identifiant d' AWS organisation (si votre compte fait partie d'une organisation) | [lois : PrincipalOrg ID](reference_policies_condition-keys.md#condition-keys-principalorgid) | o-abc1234567 | 
| ou\$1path | Le parcours de votre unité organisationnelle (le cas échéant) | [lois : PrincipalOrgPaths](reference_policies_condition-keys.md#condition-keys-principalorgpaths) | o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-222222222222/ | 
| principal\$1tags | Balises associées à la session de rôle principal ou assumé par l'IAM. Lorsqu'un jeton est demandé alors que le principal IAM demandeur possède à la fois des balises principales et des balises de session, les balises de session seront présentes dans le JWT. | [lois :PrincipalTag/](reference_policies_condition-keys.md#condition-keys-principaltag)<tag-key> | \$1"environnement » : « production », « équipe » : « ingénierie des données », « centre de coûts » « ingénierie »\$1 | 

### Déclarations relatives au contexte de session
<a name="session-context-claims"></a>

Ces allégations fournissent des informations sur l'environnement informatique et la session d'où provient la demande de jeton. AWS AWS STS inclut automatiquement ces réclamations, le cas échéant, en fonction du contexte de session du principal demandeur.


| Demander | Description | Cartes vers la clé de condition | Exemple de valeur | 
| --- | --- | --- | --- | 
| exp de session originale | Quand les informations d'identification de la session de rôle d'origine expireront (pour les rôles assumés) | N/A | 2024-01-15T 10:00:00 Z | 
| fournisseur\$1fédéré | Le nom du fournisseur d'identité pour les sessions fédérées | [lois : FederatedProvider](reference_policies_condition-keys.md#condition-keys-federatedprovider) | arn:aws:iam : :111122223333:oidc-provider/your\$1oidc\$1provider | 
| identity\$1store\$1user\$1id | ID utilisateur du centre d'identité IAM | [boutique d'identité : UserId](reference_policies_condition-keys.md#condition-keys-identity-store-user-id) | user-abc123def456 | 
| identity\$1store\$1arn | ARN de la boutique d'identités Identity Center | [boutique d'identité : IdentityStoreArn](https://docs.aws.amazon.com/singlesignon/latest/userguide/condition-context-keys-sts-idc.html#condition-keys-identity-store-arn) | arn:aws:identitystore : :123456789012 : identitystore/d-abc1234567 | 
| ec2\$1source\$1instance\$1arn | ARN de l' EC2 instance demandeuse | [EC2 : SourceInstanceArn](reference_policies_condition-keys.md#condition-keys-ec2-source-instance-arn) | arn:aws:ec2:us-east- 1:123456789012 : instance/i-abc123def456 | 
| ec2\$1instance\$1source\$1vpc | ID VPC où les informations d'identification du EC2 rôle ont été fournies | [AWS : EC2 InstanceSourceVpc](reference_policies_condition-keys.md#condition-keys-ec2instancesourcevpc) | vpc-abc123def456 | 
| ec2\$1instance\$1source\$1private\$1ipv4 |  IPv4 Adresse privée de l' EC2 instance | [AWS : EC2 InstanceSourcePrivate IPv4](reference_policies_condition-keys.md#condition-keys-ec2instancesourceprivateip4) | 10,0.1,25 | 
| ec2\$1role\$1delivery | Version du service de métadonnées d'instance | [EC2 : RoleDelivery](reference_policies_condition-keys.md#condition-keys-ec2-role-delivery) | 2 | 
| identité\$1source | Identité de la source définie par le principal | [lois : SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) | utilisateur-administrateur | 
| lambda\$1source\$1function\$1arn | ARN de la fonction Lambda appelante | [lambda : SourceFunctionArn](reference_policies_condition-keys.md#condition-keys-lambda-source-function-arn) | arn:aws:lambda:us-east- 1:123456789012 : fonction:my-function | 
| glue\$1credential\$1issuing\$1service | AWS Identifiant du service Glue pour les tâches Glue | [colle : CredentialIssuingService](reference_policies_condition-keys.md#condition-keys-glue-credential-issuing) | glue.amazonaws.com | 

### Tags de demande
<a name="request-tags"></a>

Vous pouvez ajouter des revendications personnalisées aux jetons en spécifiant des balises dans la demande [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)d'API. Ces demandes apparaissent sous le champ request\$1tags du jeton et vous permettent de transmettre des informations spécifiques que les services externes peuvent utiliser pour des décisions d'autorisation précises. Vous pouvez spécifier jusqu'à 50 balises par demande.

Exemple de demande :

```
response = sts_client.get_web_identity_token(
    Audience=['https://api.example.com'],
    SigningAlgorithm='ES384'
    Tags=[
        {'Key': 'team', 'Value': 'data-engineering'},
        {'Key': 'cost-center', 'Value': 'analytics'},
        {'Key': 'environment', 'Value': 'production'}
    ]
)
```

Réclamations qui en résultent sous forme de jetons :

```
{
  "request_tags": {
    "team": "data-engineering",
    "cost-center": "analytics",
    "environment": "production"
  }
}
```

# Contrôle de l'accès à l'aide de politiques IAM
<a name="id_roles_providers_outbound_policies"></a>

IAM fournit plusieurs types de politiques pour contrôler l'accès à la fonctionnalité de fédération des identités sortantes. Vous pouvez utiliser des [politiques basées sur l'identité](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) pour contrôler les principaux IAM autorisés à demander des jetons et appliquer des propriétés de jetons spécifiques telles que l'audience, la durée de vie et les algorithmes de signature. Les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) vous permettent d'appliquer des restrictions à l'échelle de l'organisation sur la génération de jetons sur tous les comptes de vos organisations AWS . Les [politiques de contrôle des ressources](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) (RCPs) contrôlent l'accès au niveau des ressources. Vous pouvez également utiliser les [politiques relatives aux points de terminaison VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) pour limiter les principaux autorisés à accéder à l' AWS STS `GetWebIdentityToken`API via vos points de terminaison VPC, en ajoutant des contrôles au niveau du réseau à votre posture de sécurité. Cette section explique comment implémenter des contrôles d'accès précis à l'aide de ces types de politiques et de ces clés de condition.

Pour demander des jetons d'identité, un principal IAM doit avoir l'`sts:GetWebIdentityToken`autorisation. Accordez cette autorisation par le biais de politiques d'identité associées aux utilisateurs ou aux rôles IAM. Pour autoriser la transmission de balises (clés, paires de valeurs) à l' GetWebIdentityToken appel, le principal IAM doit en avoir l'`sts:TagGetWebIdentityToken`autorisation.
+ Utilisez la touche de IdentityTokenAudience condition [sts :](reference_policies_iam-condition-keys.md#ck_identitytokenaudience) pour limiter les services externes autorisés à recevoir des jetons.
+ Utilisez la clé de DurationSeconds condition [sts :](reference_policies_iam-condition-keys.md#ck_durationseconds) pour appliquer la durée de vie maximale des jetons.
+ Utilisez la clé de SigningAlgorithm condition [sts :](reference_policies_iam-condition-keys.md#ck_signingalgorithm) pour demander des algorithmes cryptographiques spécifiques.
+ Utilisez la clé de RequestTag condition [aws :](reference_policies_condition-keys.md#condition-keys-requesttag) comparez la paire clé-valeur de balise transmise dans la demande avec la paire de balises que vous spécifiez dans la politique.
+ Utilisez la clé de TagKeys condition [aws :](reference_policies_condition-keys.md#condition-keys-tagkeys) pour comparer les clés de balise d'une demande avec les clés que vous spécifiez dans la politique.

Reportez-vous aux [rubriques IAM et](reference_policies_iam-condition-keys.md) clés de AWS STS condition pour en savoir plus sur les clés de condition disponibles dans les politiques IAM.

Cet exemple de politique d'identité combine plusieurs clés de condition :

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowTokenGenerationWithRestrictions",
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "sts:IdentityTokenAudience": [
                        "https://api1.example.com",
                        "https://api2.example.com"
                    ]
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                },
                "StringEquals": {
                    "sts:SigningAlgorithm": "ES384"
                }
            }
        }
    ]
}
```

## Bonnes pratiques
<a name="outbound-best-practices"></a>

Suivez ces recommandations pour fédérer en toute sécurité vos AWS identités avec des services externes.
+ **Utilisez des durées de vie des jetons courtes :** demandez les jetons dont la durée de vie est la plus courte et qui répondent à vos besoins opérationnels.
+ **Mettez en œuvre l'accès avec le moindre privilège et limitez les propriétés des jetons grâce aux politiques IAM :** accordez l'`sts:GetWebIdentityToken`autorisation uniquement aux principaux IAM qui en ont besoin. Utilisez les clés de condition pour spécifier les algorithmes de signature, les audiences de jetons autorisées et la durée de vie maximale des jetons selon vos besoins.
+ **Validez les réclamations auprès de services externes :** pour des raisons de sécurité, validez toujours les demandes pertinentes telles que le sujet (« sub »), le public (« aud »), etc. pour vous assurer qu'elles correspondent aux valeurs que vous attendez. Validez les demandes personnalisées dans la mesure du possible afin de permettre des décisions d'autorisation précises dans les services externes.

# Informations d'identification de sécurité temporaires dans IAM
<a name="id_credentials_temp"></a>

Vous pouvez utiliser le AWS Security Token Service (AWS STS) pour créer et fournir à des utilisateurs de confiance des informations d'identification de sécurité temporaires qui peuvent contrôler l'accès à vos AWS ressources. Les informations d'identification temporaires fonctionnent de manière presque identique aux informations d'identification des clés d'accès à long terme, à quelques différences près :
+ Les informations d'identification de sécurité temporaires sont *à court terme*, comme leur nom l'indique. Elles peuvent être configurées pour être valides de quelques minutes à plusieurs heures. Une fois les informations d'identification AWS expirées, il ne les reconnaît plus ou n'autorise aucun type d'accès à partir des demandes d'API effectuées avec elles.
+ Les informations d'identification de sécurité temporaires ne sont pas stockées avec l'utilisateur, mais sont générées automatiquement et fournies à l'utilisateur sur demande. Lorsque (ou même avant) les informations d'identification de sécurité temporaires arrivent à expiration, l'utilisateur peut en demander de nouvelles, tant qu'il y est autorisé.

Par conséquent, les informations d'identification temporaires présentent les avantages suivants par rapport aux informations d'identification à long terme :
+ Il n'est pas nécessaire de distribuer ou d'intégrer des informations de AWS sécurité à long terme dans une application.
+ Vous pouvez donner accès à vos AWS ressources aux utilisateurs sans avoir à définir leur AWS identité. Les informations d’identification temporaires sont le fondement des [rôles](id_roles.md) et de la [fédération d’identité](id_roles_providers.md).
+ Les informations d'identification de sécurité temporaires ont une durée de vie limitée. Il n'est donc pas nécessaire de les mettre à jour ou de les révoquer explicitement lorsqu'elles deviennent obsolètes. Une fois que les informations d'identification de sécurité temporaires arrivent à expiration, elles ne peuvent pas être réutilisées. Vous pouvez spécifier le délai de validité des informations d'identification, jusqu'à une certaine limite. 

## AWS STS et AWS régions
<a name="sts-regionalization"></a>

Les informations d'identification de sécurité temporaires sont générées par AWS STS. Par défaut, AWS STS il s'agit d'un service global avec un seul point de terminaison à`https://sts.amazonaws.com`. Toutefois, vous pouvez également choisir d'effectuer des appels d' AWS STS API vers des points de terminaison situés dans toute autre région prise en charge. Cela permet de réduire la latence (décalage serveur) en envoyant des demandes aux serveurs situés dans une région géographiquement plus proche de vous. Quelle que soit la région d'où proviennent vos informations d'identification, elles fonctionnent dans le monde entier. Pour plus d'informations, veuillez consulter [Gérez AWS STS dans un Région AWS](id_credentials_temp_enable-regions.md).

## Scénarios courants d'informations d'identification temporaires
<a name="sts-introduction"></a>

Les informations d'identification temporaires sont utiles dans des scénarios impliquant la fédération d'identité, la délégation, l'accès entre comptes et les rôles IAM.

### Fédération des identités
<a name="id-federation"></a>

Vous pouvez gérer les identités de vos utilisateurs dans un système externe AWS et accorder aux utilisateurs qui se connectent à partir de ces systèmes l'accès pour effectuer AWS des tâches et accéder à vos AWS ressources. IAM prend en charge deux types de fédération d'identité. Dans les deux cas, les identités sont stockées à l'extérieur de AWS. La distinction réside dans l'endroit où se trouve le système externe : dans votre centre de données ou dans un tiers externe sur le Web. Pour comparer les fonctionnalités d’informations d’identification de sécurité temporaires pour la fédération d’identité, consultez [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md).

Pour plus d'informations sur les fournisseurs d'identité externes, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md).
+ **Fédération OpenID Connect (OIDC)** : vous pouvez autoriser les utilisateurs à se connecter à l’aide d’un fournisseur d’identité tiers bien établi, tel que Login with Amazon, Facebook, Google, ou tout autre fournisseur compatible OIDC 2.0 pour votre application mobile ou Web ; vous n’avez pas besoin de créer un code de connexion personnalisé ni de gérer vos propres identités d’utilisateur. L'utilisation de la fédération OIDC vous aide à Compte AWS garantir votre sécurité, car vous n'avez pas à distribuer des informations de sécurité à long terme, telles que des clés d'accès utilisateur IAM, avec votre application. Pour de plus amples informations, veuillez consulter [Fédération OIDC](id_roles_providers_oidc.md).

  AWS STS La fédération OIDC prend en charge Login with Amazon, Facebook, Google et tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC).
**Note**  
Pour les applications mobiles, nous vous recommandons d'utiliser Amazon Cognito. Vous pouvez utiliser ce service avec AWS SDKs for mobile development afin de créer des identités uniques pour les utilisateurs et de les authentifier afin de sécuriser l'accès à vos AWS ressources. Amazon Cognito prend en charge les mêmes fournisseurs d'identité AWS STS, prend également en charge l'accès non authentifié (invité) et vous permet de migrer les données utilisateur lorsqu'un utilisateur se connecte. Amazon Cognito fournit également des opérations d'API pour la synchronisation des données utilisateur afin de les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour plus d'informations, consultez [Authentification avec Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) dans la *documentation Amplify*.
+ **Fédération SAML** : vous pouvez authentifier les utilisateurs sur le réseau de votre organisation, puis leur fournir un accès AWS sans leur créer de nouvelles AWS identités ni leur demander de se connecter avec des informations d'identification différentes. C'est ce que l'on appelle l'approche *d'authentification unique* pour l'accès temporaire. AWS STS prend en charge les normes ouvertes telles que le langage SAML (Security Assertion Markup Language) 2.0, avec lequel vous pouvez utiliser Microsoft AD FS pour tirer parti de votre Microsoft Active Directory. SAML 2.0 vous permet également de gérer votre propre solution pour fédérer les identités des utilisateurs. Pour de plus amples informations, veuillez consulter [Fédération SAML 2.0](id_roles_providers_saml.md).
  + **Courtier de fédération personnalisé** : vous pouvez utiliser le système d'authentification de votre organisation pour accorder l'accès aux AWS ressources. Pour obtenir un exemple de scénario, consultez [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).
  + **Federation using SAML 2.0** (Fédération à l'aide de SAML 2.0) : vous pouvez utiliser le système d'authentification de votre organisation et SAML pour accorder l'accès aux ressources AWS . Pour obtenir des informations et un exemple de scénario, consultez [Fédération SAML 2.0](id_roles_providers_saml.md).

### Rôles pour l'accès entre comptes
<a name="role_cross-account"></a>

De nombreuses organisations gèrent plusieurs Compte AWS. À l'aide des rôles et de l'accès entre comptes, vous pouvez définir des identités utilisateur dans un compte et utiliser ces identités pour accéder aux ressources AWS dans d'autres comptes qui appartiennent à votre organisation. Cette procédure s'appelle la *délégation* pour un accès temporaire. Pour de plus amples informations sur la création de rôles entre comptes, veuillez consulter la rubrique [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md). Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, veuillez consulter [Qu'est-ce que l'Analyseur d'accès IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).

### Rôles pour Amazon EC2
<a name="role_ec2"></a>

Si vous exécutez des applications sur des instances Amazon EC2 et que ces applications doivent accéder à des ressources AWS , vous pouvez fournir des informations d'identification de sécurité temporaires à vos instances lorsque vous les lancez. Ces informations d'identification de sécurité temporaires sont disponibles pour toutes les applications qui s'exécutent sur l'instance, vous n'avez donc pas besoin de stocker des informations d'identification à long terme sur l'instance. Pour de plus amples informations, veuillez consulter [Utilisation d’un rôle IAM pour accorder des autorisations à des applications s’exécutant sur des instances Amazon EC2](id_roles_use_switch-role-ec2.md).

Pour en savoir plus sur les informations d’identification des rôles IAM Amazon EC2, consultez [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud.*

### Autres AWS services
<a name="other-services"></a>

Vous pouvez utiliser des informations d'identification de sécurité temporaires pour accéder à la plupart AWS des services. Pour obtenir une liste des services qui acceptent les informations d'identification de sécurité temporaires, consultez la section [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md).

## Exemples d'application qui utilisent des informations d'identification temporaires
<a name="id_credentials_temp_sample-apps"></a>

Vous pouvez utiliser AWS Security Token Service (AWS STS) pour créer et fournir à des utilisateurs de confiance des informations d'identification de sécurité temporaires qui peuvent contrôler l'accès à vos AWS ressources. Pour plus d'informations sur AWS STS, voir[Informations d'identification de sécurité temporaires dans IAM](#id_credentials_temp). Pour découvrir comment gérer les informations d'identification AWS STS de sécurité temporaires, vous pouvez télécharger les exemples d'applications suivants qui mettent en œuvre des exemples de scénarios complets :
+ [Activation de la fédération pour AWS utiliser Windows Active Directory, ADFS et SAML 2.0.](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/) Démontre comment déléguer l'accès à l'aide de la fédération d'entreprise à AWS Windows Active Directory (AD), Active Directory Federation Services (ADFS) 2.0 et SAML (Security Assertion Markup Language) 2.0.
+ [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md)Explique comment créer un proxy de fédération permettant d'autoriser l'authentification unique (SSO) afin que les utilisateurs Active Directory existants puissent se connecter à AWS Management Console.
+ [Comment utiliser Shibboleth pour l'authentification unique au. AWS Management Console](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/) . Explique comment utiliser [Shibboleth](http://shibboleth.net/) et [SAML](id_roles_providers_saml.md) pour fournir aux utilisateurs un accès avec authentification unique (SSO) à l' AWS Management Console.

### Exemples pour la fédération OIDC
<a name="sts-sample-apps-wif"></a>

Les exemples d'applications suivants montrent comment les utiliser OIDCfederation avec des fournisseurs tels que Login with Amazon, Amazon Cognito, Facebook ou Google. Vous pouvez échanger l'authentification de ces fournisseurs contre des informations AWS de sécurité temporaires pour accéder aux AWS services.
+ [Tutoriels Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html) — Nous vous recommandons d'utiliser Amazon Cognito pour AWS SDKs le développement mobile. Amazon Cognito offre le moyen le plus simple de gérer l'identité pour les applications mobiles et fournit des fonctions supplémentaires telles que la synchronisation et l'identité entre périphériques. Pour plus d'informations sur Amazon Cognito, consultez [Authentification avec Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) dans la *documentation Amplify*.

## Ressources supplémentaires pour les informations d'identification de sécurité temporaires
<a name="id_credentials_temp_related-topics"></a>

Les scénarios et applications suivants peuvent vous aider à utiliser les informations d'identification de sécurité temporaires : 
+ [Comment intégrer AWS STS SourceIdentity votre fournisseur d'identité](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/). Cet article explique comment configurer l' AWS STS `SourceIdentity`attribut lorsque vous utilisez Okta, Ping ou OneLogin comme IdP.
+  [Fédération OIDC](id_roles_providers_oidc.md). Cette section explique comment configurer les rôles IAM lorsque vous utilisez la fédération OIDC et l’API `AssumeRoleWithWebIdentity`. 
+ [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md). Cette rubrique explique comment utiliser les rôles pour exiger l'authentification multi-facteur (MFA) afin de protéger les actions d'API sensibles de votre compte.

Pour plus d'informations sur les politiques et les autorisations, AWS consultez les rubriques suivantes :
+ [Gestion de l'accès aux AWS ressources](access.md)
+ [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).
+ [Managing Access Permissions to Your Amazon S3 Resources (gestion des autorisations d'accès à vos ressources Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) dans le *guide de l'utilisateur du service de stockage simple Amazon*.
+  Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, veuillez consulter [Qu'est-ce que l'Analyseur d'accès IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).

# Comparez les AWS STS informations d'identification
<a name="id_credentials_sts-comparison"></a>

Le tableau suivant compare les fonctionnalités des opérations d'API AWS STS qui renvoient des informations d'identification de sécurité temporaires. Pour en savoir plus sur les différentes méthodes disponibles pour demander des identifiants de sécurité temporaires en endossant un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md). Pour en savoir plus sur les différentes opérations d' AWS STS API qui vous permettent de transmettre des balises de session, consultez[Transmettez les tags de session AWS STS](id_session-tags.md).

**Note**  
Vous pouvez envoyer des appels AWS STS d'API soit à un point de terminaison global, soit à l'un des points de terminaison régionaux. En choisissant un point de terminaison plus proche de vous, il est possible de réduire la latence et d'améliorer les performances de vos appels d'API. Vous pouvez également diriger vos appels vers un autre point de terminaison régional si vous n'êtes plus en mesure de communiquer avec le point de terminaison initial. Si vous utilisez l'une des différentes méthodes AWS SDKs, utilisez cette méthode du SDK pour spécifier une région avant d'effectuer l'appel d'API. Si vous créez manuellement des demandes d'API HTTP, vous devez les diriger vous-même vers le point de terminaison approprié. Pour plus d'informations, consultez la [section AWS STS de *Régions et points de terminaison*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) et [Gérez AWS STS dans un Région AWS](id_credentials_temp_enable-regions.md).


|  **AWS STS API**  |  **Qui peut appeler**  |  **Durée de vie des informations d'identification (min \$1 max \$1 par défaut)**  |  **Prise en charge de l'authentification MFA**¹  |  **Prise en charge de la politique de session**²  |  **Restrictions applicables aux informations d'identification temporaires générées**  | 
| --- | --- | --- | --- | --- | --- | 
|  [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)  | Utilisateur IAM ou rôle IAM disposant d'informations d'identification de sécurité temporaires existantes  | 15 min \$1 Durée de session maximale³ \$1 1 h  | Oui  | Oui |  Impossible d'appeler `GetFederationToken` ou `GetSessionToken`.  | 
|  [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)  | N'importe quel utilisateur ; le principal doit transmettre une réponse d'authentification SAML qui spécifie l'authentification par un fournisseur d'identité reconnu | 15 min \$1 Durée de session maximale³ \$1 1 h  | Non | Oui |  Impossible d'appeler `GetFederationToken` ou `GetSessionToken`.  | 
|  [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)  | Tout utilisateur ; l’appelant doit transmettre un jeton JWT conforme à l’OIDC qui atteste d’une authentification auprès d’un fournisseur d’identité connu | 15 min \$1 Durée de session maximale³ \$1 1 h  | Non | Oui |  Impossible d'appeler `GetFederationToken` ou `GetSessionToken`.  | 
| [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | Utilisateur IAM ou Utilisateur racine d'un compte AWS |  Utilisateur IAM : 15 min \$1 36 h \$1 12 h Utilisateur racine : 15 min \$1 1 heure \$1 1 heure  | Non  | Oui  |  Impossible d'appeler des opérations IAM à l'aide de l' AWS API AWS CLI or. Cette limitation ne s'applique pas aux sessions de console. Impossible d'appeler AWS STS les opérations sauf `GetCallerIdentity` .⁴ Connexion avec authentification unique (SSO) à la console autorisée.⁵  | 
| [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | Utilisateur IAM ou Utilisateur racine d'un compte AWS |  Utilisateur IAM : 15 min \$1 36 h \$1 12 h Utilisateur racine : 15 min \$1 1 heure \$1 1 heure  | Oui  | Non  |  Impossible d'appeler les opérations d'API IAM si les informations MFA ne figurent pas dans la demande. Impossible d'appeler les opérations d' AWS STS API sauf `AssumeRole` ou`GetCallerIdentity`. Connexion avec authentification unique (SSO) à la console non autorisée.⁶  | 

 ¹ **Prise en charge de l'authentification MFA**. Vous pouvez inclure des informations sur un dispositif d'authentification multifactorielle (MFA) lorsque vous appelez AssumeRole les opérations GetSessionToken et API. De cette façon, les informations d'identification de sécurité temporaires obtenues lors l'appel d'API peuvent uniquement être utilisées par des utilisateurs authentifiés à l'aide d'un dispositif MFA. Pour plus d’informations, veuillez consulter [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md). 

 ² **Prise en charge de la politique de session**. Les politiques de session sont des politiques que vous transmettez en paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou une session utilisateur AWS STS fédérée. Cette politique limite les autorisations à partir de la politique basée sur l'identité du rôle ou de l'utilisateur qui sont attribuées à la session. Les autorisations de la session obtenues sont une combinaison des stratégies basées sur l'identité de l'entité et des stratégies de session. Les politiques de session ne peuvent pas être utilisées pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour de plus amples informations sur les autorisations de session de rôle, veuillez consulter [Politiques de session](access_policies.md#policies_session).

³ **Paramètre de durée de session maximale**. Utilisez le paramètre `DurationSeconds` pour spécifier la durée de la session de votre rôle entre 900 secondes (15 minutes) et la durée de session maximale pour le rôle. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration).

⁴ **GetCallerIdentity**. Aucune autorisation n'est requise pour effectuer cette opération. Si un administrateur ajoute une politique à votre utilisateur ou rôle IAM qui refuse explicitement l'accès à l'action `sts:GetCallerIdentity`, vous pouvez toujours effectuer cette opération. Les autorisations ne sont pas requises, car les mêmes informations sont renvoyées lorsqu'un utilisateur ou un rôle IAM se voit refuser l'accès. Pour afficher un exemple de réponse, consultez [Je ne suis pas autorisé à exécuter : iam : DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa).

⁵ **Connexion avec authentification unique (SSO) à la console**. Pour prendre en charge l'authentification unique, vous AWS pouvez appeler un point de terminaison de fédération (`https://signin.aws.amazon.com/federation`) et transmettre des informations d'identification de sécurité temporaires. Le point de terminaison retourne un jeton que vous pouvez utiliser pour créer une URL qui connecte directement l'utilisateur à la console, sans avoir besoin d'un mot de passe. Pour plus d'informations, consultez [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md) la section [Comment activer l'accès multicompte à la console de AWS gestion](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) dans le blog sur la AWS sécurité. 

⁶ Une fois que vous avez récupéré vos informations d'identification temporaires, vous ne pouvez pas accéder à l’interface AWS Management Console en transmettant les informations d'identification au point de terminaison d'authentification unique de fédération. Pour de plus amples informations, veuillez consulter [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).

# Jeton porteur de service
<a name="id_credentials_bearer"></a>

Certains AWS services nécessitent que vous soyez autorisé à obtenir un jeton de support de AWS STS service avant de pouvoir accéder à leurs ressources par programmation. Ces services prennent en charge un protocole qui vous oblige à utiliser un jeton porteur au lieu d’utiliser une [AWS Signature Version 4 pour les demandes d'API](reference_sigv.md) traditionnelle. Lorsque vous effectuez des opérations AWS CLI ou des opérations d' AWS API qui nécessitent des jetons porteurs, le AWS service demande un jeton porteur en votre nom. Le service vous fournit le jeton, que vous pouvez ensuite utiliser pour effectuer toute opération ultérieure dans ce service. 

AWS STS les jetons de support incluent des informations issues de votre authentification principale d'origine qui peuvent affecter vos autorisations. Ces informations peuvent comprendre des balises de principal ou de session, ainsi que des politiques de session. L'ID de clé d'accès du jeton commence par le préfixe `ABIA`. Cela vous aide à identifier les opérations effectuées à l'aide de jetons porteurs de service dans les journaux CloudTrail.

**Important**  
Le jeton porteur ne peut être utilisé que pour les appels vers le service qui le génère et dans la région dans laquelle il a été généré. Vous ne pouvez pas l'utiliser pour effectuer des opérations dans d'autres services ou régions.

Un exemple de service qui prend en charge les jetons au porteur est AWS CodeArtifact. Avant de pouvoir interagir avec AWS CodeArtifact un gestionnaire de packages tel que NPM, Maven ou PIP, vous devez appeler l'opération. `aws codeartifact get-authorization-token` Cette opération renvoie un jeton porteur que vous pouvez utiliser pour effectuer des AWS CodeArtifact opérations. Si vous préférez, vous pouvez aussi utiliser la commande `aws codeartifact login` qui exécute la même opération, puis configure automatiquement votre client. 

Si vous effectuez une action dans un AWS service qui génère un jeton porteur pour vous, vous devez disposer des autorisations suivantes dans votre politique IAM :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowServiceBearerToken",
            "Effect": "Allow",
            "Action": "sts:GetServiceBearerToken",
            "Resource": "*"
        }
    ]
}
```

------

Pour obtenir un exemple de jeton de support de service, consultez[Utilisation de stratégies basées sur l'identité pour AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html) dans le Guide de l'utilisateur *AWS CodeArtifact*.

# Demande d’identifiants de sécurité temporaires
<a name="id_credentials_temp_request"></a>

Pour demander des informations d'identification de sécurité temporaires, vous pouvez utiliser les opérations AWS Security Token Service (AWS STS) dans l' AWS API. Il s'agit notamment d'opérations visant à créer et à fournir à des utilisateurs de confiance des informations d'identification de sécurité temporaires qui peuvent contrôler l'accès à vos AWS ressources. Pour plus d'informations sur AWS STS, voir[Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md). Pour en savoir plus sur les différentes méthodes disponibles pour demander des informations d'identification de sécurité temporaires en endossant un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md).

Pour appeler les opérations de l'API, vous pouvez utiliser l'une des [AWS SDKs](https://aws.amazon.com/tools/). Ils SDKs sont disponibles pour une variété de langages de programmation et d'environnements, notamment Java, .NET, Python, Ruby, Android et iOS. Ils se SDKs chargent de tâches telles que la signature cryptographique de vos demandes, les réessayer si nécessaire et le traitement des réponses aux erreurs. Vous pouvez également utiliser l'API AWS STS Query, qui est décrite dans la [référence des AWS Security Token Service API](https://docs.aws.amazon.com/STS/latest/APIReference/). Enfin, deux outils de ligne de commande prennent en charge les AWS STS commandes : le [AWS Command Line Interface](https://aws.amazon.com/documentation/cli), et le [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell). 

Les opérations d' AWS STS API créent une nouvelle session avec des informations d'identification de sécurité temporaires qui incluent une paire de clés d'accès et un jeton de session. La paire de clés d'accès comprend un ID de clé d'accès et une clé secrète. Ces informations d'identification permettent aux utilisateurs (ou une application exécutée par l'utilisateur) d'accéder à vos ressources. Vous pouvez créer une session de rôle et transmettre des politiques de session et des balises de session par programmation à l'aide des opérations d' AWS STS API. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Pour de amples informations sur les politiques de session, veuillez consulter [Politiques de session](access_policies.md#policies_session). Pour de plus amples informations sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

**Note**  
La taille du jeton de session renvoyé par les opérations d' AWS STS API n'est pas fixe. Nous vous recommandons fortement de ne pas formuler d'hypothèses quant à sa taille maximale. La taille du jeton est en général inférieure à 4 096 octets, mais elle peut varier.

## Utilisation AWS STS avec AWS les régions
<a name="using_sts_regions"></a>

Vous pouvez envoyer des appels AWS STS d'API soit à un point de terminaison global, soit à l'un des points de terminaison régionaux. En choisissant un point de terminaison plus proche de vous, il est possible de réduire la latence et d'améliorer les performances de vos appels d'API. Vous pouvez également diriger vos appels vers un autre point de terminaison régional si vous n'êtes plus en mesure de communiquer avec le point de terminaison initial. Si vous utilisez l'une des différentes méthodes AWS SDKs, utilisez cette méthode du SDK pour spécifier une région avant d'effectuer l'appel d'API. Si vous créez manuellement des demandes d'API HTTP, vous devez les diriger vous-même vers le point de terminaison approprié. Pour plus d'informations, consultez la [section AWS STS de *Régions et points de terminaison*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) et [Gérez AWS STS dans un Région AWS](id_credentials_temp_enable-regions.md).

Voici les opérations d'API que vous pouvez utiliser pour obtenir des informations d'identification temporaires à utiliser dans votre AWS environnement et vos applications.

## Demande d’informations d’identification pour la délégation et la fédération entre comptes par l’intermédiaire d’un fournisseur d’identité personnalisé
<a name="api_assumerole"></a>

Le fonctionnement de l'[https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html)API est utile pour permettre aux utilisateurs IAM existants d'accéder à AWS des ressources auxquelles ils n'ont pas encore accès. Par exemple, l'utilisateur peut avoir besoin d'accéder aux ressources d'un autre Compte AWS. Il est également utile comme moyen d'obtenir temporairement un accès privilégié, par exemple, pour fournir une authentification multi-facteur (MFA). Vous devez appeler cette API à l'aide d'informations d'identification actives. Pour savoir qui peut appeler cette opération, consultez [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md). Pour plus d’informations, consultez [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md) et [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md).

**Pour demander des justificatifs de sécurité temporaires pour la délégation et la fédération de comptes croisés par l’intermédiaire d’un fournisseur d’identité personnalisé**

1. Authentifiez-vous à l'aide de vos identifiants AWS de sécurité. Cet appel doit être effectué à l'aide d'informations d'identification de sécurité AWS valides.

1. Appelez l’opération [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html).

L'exemple suivant illustre une demande et une réponse qui utilisent `AssumeRole`. Cet exemple de demande endosse le rôle `demo` pour la durée spécifiée avec la [politique de session](access_policies.md#policies_session), les [balises de session](id_session-tags.md) et l'[ID externe](id_roles_common-scenarios_third-party.md) et l'[identité source](id_credentials_temp_control-access_monitor.md) inclus. La session obtenue est nommée `John-session`. 

**Example Exemple de demande**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=John-session
&RoleArn=arn:aws::iam::123456789012:role/demo
&Policy=%7B%22Version%22%3A%222012-10-17		 	 	 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&ExternalId=123ABC
&SourceIdentity=DevUser123
&AUTHPARAMS
```

La valeur de politique indiquée dans l'exemple précédent est la version encodée en URL de la politique suivante :

------
#### [ JSON ]

****  

```
{"Version":"2012-10-17",		 	 	 "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
```

------

Le paramètre `AUTHPARAMS` de l'exemple est un espace réservé pour votre *signature*. Une signature est l'information d'authentification que vous devez inclure dans les demandes d'API AWS HTTP. Nous vous recommandons d'utiliser le [AWS SDKs](https://aws.amazon.com/tools/)pour créer des demandes d'API, et l'un des avantages de cette méthode est qu'il SDKs gère la signature des demandes pour vous. Si vous devez créer et signer des demandes d'API manuellement, consultez [la section Signature des AWS demandes à l'aide de la version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) du *Référence générale d'Amazon Web Services*pour savoir comment signer une demande.

Outre les informations d'identification de sécurité temporaires, la réponse inclut l'Amazon Resource Name (ARN) de l'utilisateur fédéré et la date d'expiration des informations d'identification.

**Example Exemple de réponse**  

```
<AssumeRoleResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<AssumeRoleResult>
<SourceIdentity>DevUser123</SourceIdentity>
<Credentials>
  <SessionToken>
   AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
   LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
   QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
   9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
   +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
  </SessionToken>
  <SecretAccessKey>
   wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2019-07-15T23:28:33.359Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
<AssumedRoleUser>
  <Arn>arn:aws:sts::123456789012:assumed-role/demo/John</Arn>
  <AssumedRoleId>ARO123EXAMPLE123:John</AssumedRoleId>
</AssumedRoleUser>
<PackedPolicySize>8</PackedPolicySize>
</AssumeRoleResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</AssumeRoleResponse>
```

**Note**  
Une AWS conversion compresse les politiques de session et les balises de session adoptées dans un format binaire compressé doté d'une limite distincte. Votre demande peut échouer pour cette limite, même si votre texte brut répond aux autres exigences. L'élément de réponse `PackedPolicySize` indique en pourcentage la proximité des stratégies et des balises de votre requête par rapport à la limite de taille supérieure.

## Demande d’informations d’identification par le biais d’un fournisseur OIDC
<a name="api_assumerolewithwebidentity"></a>

L’opération d’API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) renvoie un ensemble d’informations d’identification de sécurité temporaires AWS en échange d’un jeton Web JSON (JWT). Cela inclut les fournisseurs d'identité publics, tels que Login with Amazon, Facebook, Google, et les fournisseurs qui émettent JWTs des données compatibles avec la découverte d'OpenID Connect (OIDC), tels que GitHub Actions ou Azure Devops. Pour de plus amples informations, veuillez consulter [Fédération OIDC](id_roles_providers_oidc.md).

**Note**  
Les requêtes `AssumeRoleWithWebIdentity` ne sont pas signées et ne nécessitent pas d’informations d’identification AWS .

**Demande d’informations d’identification par le biais d’un fournisseur OIDC**

1. Appelez l’opération [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html).

   Lorsque vous appelez`AssumeRoleWithWebIdentity`, AWS valide le jeton présenté en vérifiant la signature numérique à l'aide des clés publiques mises à disposition via le jeu de clés Web JSON (JWKS) de votre IdP. Si le jeton est valide et que toutes les conditions définies dans la politique de confiance des rôles IAM sont remplies, vous AWS renvoie les informations suivantes :
   + Un ensemble d'informations d'identification de sécurité temporaires. Il s'agit d'un ID de clé d'accès, d'une clé d'accès secrète et d'un jeton de session.
   + L'ID de rôle et l'ARN du rôle endossé.
   + Une valeur `SubjectFromWebIdentityToken` qui contient l'ID utilisateur unique.

1. Votre application peut ensuite utiliser les informations d'identification de sécurité temporaires renvoyées dans la réponse pour effectuer des appels AWS d'API. Ce processus est identique à celui d'un appel d' AWS API avec des informations d'identification de sécurité à long terme. La différence est que vous devez inclure le jeton de session, qui permet de AWS vérifier que les informations d'identification de sécurité temporaires sont valides.

Votre application doit mettre en cache les informations d'identification renvoyées par AWS STS et les actualiser si nécessaire. Si votre application est créée à l'aide d'un AWS SDK, celui-ci dispose de fournisseurs d'informations d'identification capables de gérer les appels `AssumeRoleWithWebIdentity` et d'actualiser les AWS informations d'identification avant leur expiration. Pour plus d'informations, consultez la section [Fournisseurs d'informations d'identification standardisés AWS SDKs et Tools](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html) dans le *guide de référence AWS SDKs and Tools*.

## Demande d’informations d’identification via un fournisseur d’identité SAML 2.0
<a name="api_assumerolewithsaml"></a>

L’opération d’API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) renvoie un ensemble d’informations d’identification de sécurité temporaires pour les principaux fédérés SAML authentifiés par le système d’identité existant de votre organisation. Les utilisateurs doivent également utiliser [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0 (Security Assertion Markup Language) pour transmettre les informations d'authentification et d'autorisation à AWS. Cette opération d'API s'avère utile pour les organisations qui ont intégré leurs systèmes d'identité (comme Windows Active Directory ou OpenLDAP) à un logiciel capable de générer des assertions SAML. Cette intégration fournit des informations sur l'identité et les autorisations des utilisateurs (comme Active Directory Federation Services ou Shibboleth). Pour de plus amples informations, veuillez consulter [Fédération SAML 2.0](id_roles_providers_saml.md).

1. Appelez l’opération [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html).

   Il s'agit d'un appel non signé, ce qui signifie que vous n'avez pas besoin d'authentifier les informations AWS de sécurité avant de faire la demande.
**Note**  
Un appel à `AssumeRoleWithSAML` n'est pas signé (chiffré). Par conséquent, vous devez uniquement inclure des politiques de session facultatives si la demande est transmise via un intermédiaire approuvé. Dans ce cas, une personne peut modifier la politique afin de supprimer les restrictions.

1. Lorsque vous appelez`AssumeRoleWithSAML`, AWS vérifie l'authenticité de l'assertion SAML. En supposant que le fournisseur d'identité valide l'assertion, il vous AWS renvoie les informations suivantes :
   + Un ensemble d'informations d'identification de sécurité temporaires. Il s'agit d'un ID de clé d'accès, d'une clé d'accès secrète et d'un jeton de session. 
   + L'ID de rôle et l'ARN du rôle endossé. 
   + Une valeur `Audience` qui contient la valeur de l'attribut `Recipient` de l'élément `SubjectConfirmationData` de l'assertion SAML.
   + Une valeur `Issuer` qui contient la valeur de l'élément `Issuer` de l'assertion SAML.
   + `NameQualifier`Élément contenant une valeur de hachage créée à partir de la `Issuer` valeur, de l' Compte AWS ID et du nom convivial du fournisseur SAML. Lors de la combinaison avec l’élément `Subject`, ils identifient de manière unique le principal fédéré SAML.
   + Un élément `Subject` qui contient la valeur de l'élément `NameID` dans l'élément `Subject` de l'assertion SAML.
   + Un élément `SubjectType` qui indique le format de l'élément `Subject`. La valeur peut être `persistent`, `transient` ou l'URI `Format` complet des éléments `Subject` et `NameID` utilisés dans votre assertion SAML. Pour plus d'informations sur l'attribut `NameID` de l'élément `Format`, consultez [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). 

1. Utilisez les informations de sécurité temporaires renvoyées dans la réponse pour effectuer des appels AWS d'API. Ce processus est identique à celui d'un appel d' AWS API avec des informations d'identification de sécurité à long terme. La différence est que vous devez inclure le jeton de session, ce qui permet à AWS de vérifier la validité des informations d'identification de sécurité temporaires.

Votre application met en cache les informations d'identification. Par défaut, les informations d'identification expirent au bout d'une heure. Si vous n'utilisez pas l'action [Amazon STSCredentials Provider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) dans le AWS SDK, c'est à vous et à votre application de `AssumeRoleWithSAML` réappeler. Appelez cette opération pour obtenir un nouvel ensemble d'informations d'identification de sécurité temporaires avant l'expiration des anciennes.

## Demande d’informations d’identification via un fournisseur d’identité personnalisé
<a name="api_getfederationtoken"></a>

L'opération [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API renvoie un ensemble d'informations d'identification de sécurité temporaires pour les utilisateurs principaux AWS STS fédérés. La différence entre cette API et `AssumeRole` réside dans le fait que le délai d'expiration par défaut est considérablement plus long (12 heures au lieu d'une heure). De plus, vous pouvez utiliser le paramètre `DurationSeconds` pour spécifier une durée pour que les informations d'identification de sécurité temporaires restent valides. Les informations d’identification qui en résultent sont valables pour la durée spécifiée, entre 900 secondes (15 minutes) et 129 600 secondes (36 heures). La période d'expiration plus longue peut contribuer à réduire le nombre d'appels, AWS car vous n'avez pas besoin de nouvelles informations d'identification aussi souvent.

1. Authentifiez-vous avec les informations de AWS sécurité de votre utilisateur IAM spécifique. Cet appel doit être effectué à l'aide d'informations AWS de sécurité valides.

1. Appelez l’opération [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).

L'appel à `GetFederationToken` retourne des informations d'identification de sécurité temporaires constituées d'un jeton de session, d'une clé d'accès, d'une clé secrète et d'un délai d'expiration. Vous pouvez utiliser `GetFederationToken` si vous souhaiter gérer les autorisations au sein de l'organisation (par exemple, pour octroyer des autorisations à l'aide de l'application proxy).

L'exemple suivant illustre une demande et une réponse qui utilisent `GetFederationToken`. Cet exemple de demande fédère l'utilisateur appelant pour la durée spécifiée avec l'ARN de [politique de session](access_policies.md#policies_session) et les [balises de session](id_session-tags.md). La session obtenue est nommée `Jane-session`.

**Example Exemple de demande**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetFederationToken
&Name=Jane-session
&PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&AUTHPARAMS
```

L'ARN de politique illustrée dans l'exemple précédent inclut les ARN encodés en URL suivants : 

`arn:aws:iam::123456789012:policy/Role1policy`

Notez également que le paramètre `&AUTHPARAMS` dans l'exemple est conçu comme un espace réservé pour les informations d'authentification. Il s'agit de la *signature* que vous devez inclure dans les demandes d'API AWS HTTP. Nous vous recommandons d'utiliser le [AWS SDKs](https://aws.amazon.com/tools/)pour créer des demandes d'API, et l'un des avantages de cette méthode est qu'il SDKs gère la signature des demandes pour vous. Si vous devez créer et signer des demandes d'API manuellement, consultez la [section Signing AWS Requests By Using Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) du *Référence générale d'Amazon Web Services*pour savoir comment signer une demande.

Outre les informations d'identification de sécurité temporaires, la réponse inclut l'Amazon Resource Name (ARN) de l'utilisateur fédéré et la date d'expiration des informations d'identification.

**Example Exemple de réponse**  

```
<GetFederationTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetFederationTokenResult>
<Credentials>
  <SessionToken>
   AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
   LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
   QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
   9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
   +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE==
  </SessionToken>
  <SecretAccessKey>
  wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2019-04-15T23:28:33.359Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE;</AccessKeyId>
</Credentials>
<FederatedUser>
  <Arn>arn:aws:sts::123456789012:federated-user/Jean</Arn>
  <FederatedUserId>123456789012:Jean</FederatedUserId>
</FederatedUser>
<PackedPolicySize>4</PackedPolicySize>
</GetFederationTokenResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</GetFederationTokenResponse>
```

**Note**  
Une AWS conversion compresse les politiques de session et les balises de session adoptées dans un format binaire compressé doté d'une limite distincte. Votre demande peut échouer pour cette limite, même si votre texte brut répond aux autres exigences. L'élément de réponse `PackedPolicySize` indique en pourcentage la proximité des stratégies et des balises de votre requête par rapport à la limite de taille supérieure.

AWS recommande d'accorder des autorisations au niveau des ressources (par exemple, si vous attachez une politique basée sur les ressources à un compartiment Amazon S3), vous pouvez omettre le paramètre. `Policy` Toutefois, si vous n'incluez pas de politique pour l'utilisateur principal AWS STS fédéré, les informations d'identification de sécurité temporaires n'accorderont aucune autorisation. Dans ce cas, vous *devez* utiliser des politiques de ressources pour accorder à l'utilisateur fédéré l'accès à vos ressources AWS .

Par exemple, supposons que votre Compte AWS numéro est 111122223333 et que vous souhaitez autoriser Susan à accéder à un compartiment Amazon S3. Les informations d'identification de sécurité temporaires de Susan ne comprennent pas de politique pour ce compartiment. Dans ce cas, vous devez vous assurer que le compartiment est doté d'une politique avec un ARN correspondant à celui de Susan, par exemple `arn:aws:sts::111122223333:federated-user/Susan`. 

## Demande d’informations d’identification temporaires pour les utilisateurs dans des environnements non fiables
<a name="api_getsessiontoken"></a>

L’opération d’API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) retourne un ensemble d’informations d’identification de sécurité temporaires pour un utilisateur IAM existant. Cela est utile pour renforcer la sécurité, par exemple pour autoriser les AWS demandes uniquement lorsque la MFA est activée pour l'utilisateur IAM. Dans la mesure où les informations d'identification sont temporaires, elles offrent une sécurité améliorée lorsqu'un utilisateur IAM accède à vos ressources par le biais d'un environnement moins sécurisé. Les exemples d'environnements moins sécurisés incluent un périphérique mobile ou un navigateur web.

1. Authentifiez-vous avec les informations de AWS sécurité de votre utilisateur IAM spécifique. Cet appel doit être effectué à l'aide d'informations AWS de sécurité valides.

1. Appelez l’opération [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html).

1. `GetSessionToken` retourne des informations d'identification de sécurité temporaires constituées d'un jeton de session, d'un ID de clé d'accès et d'une clé d'accès secrète.

Par défaut, les informations d'identification de sécurité temporaires d'un utilisateur IAM restent valides pendant 12 heures maximum. Mais vous pouvez demander un durée de validité allant de 15 minutes à 36 heures à l'aide du paramètre `DurationSeconds`. Pour des raisons de sécurité, la durée d'un jeton Utilisateur racine d'un compte AWS est limitée à une heure.

L'exemple suivant illustre une demande et une réponse qui utilisent `GetSessionToken`. La réponse inclut également l'heure d'expiration des informations d'identification de sécurité temporaires. 

**Example Exemple de demande**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=1800
&AUTHPARAMS
```

Le paramètre `AUTHPARAMS` de l'exemple est un espace réservé pour votre *signature*. Une signature est l'information d'authentification que vous devez inclure dans les demandes d'API AWS HTTP. Nous vous recommandons d'utiliser le [AWS SDKs](https://aws.amazon.com/tools/)pour créer des demandes d'API, et l'un des avantages de cette méthode est qu'il SDKs gère la signature des demandes pour vous. Si vous devez créer et signer des demandes d'API manuellement, consultez la [section Signing AWS Requests By Using Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) du *Référence générale d'Amazon Web Services*pour savoir comment signer une demande.

**Example Exemple de réponse**  

```
<GetSessionTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetSessionTokenResult>
<Credentials>
  <SessionToken>
   AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L
   To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z
   rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp
   Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE
  </SessionToken>
  <SecretAccessKey>
  wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2011-07-11T19:55:29.611Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
</GetSessionTokenResult>
<ResponseMetadata>
<RequestId>58c5dbae-abef-11e0-8cfe-09039844ac7d</RequestId>
</ResponseMetadata>
</GetSessionTokenResponse>
```

Facultativement, la `GetSessionToken` demande peut inclure `SerialNumber` des `TokenCode` valeurs pour la vérification de l' AWS authentification multifactorielle (MFA). Si les valeurs fournies sont valides, AWS STS fournit des informations d'identification de sécurité temporaires qui incluent l'état de l'authentification MFA. Les informations d'identification de sécurité temporaires peuvent ensuite être utilisées pour accéder aux opérations d'API ou aux AWS sites Web protégés par le MFA tant que l'authentification MFA est valide. 

L'exemple suivant illustre une demande `GetSessionToken` qui comprend un code de vérification MFA et un numéro de série du dispositif. 

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=7200
&SerialNumber=YourMFADeviceSerialNumber
&TokenCode=123456
&AUTHPARAMS
```

**Note**  
L'appel AWS STS peut être dirigé vers le point de terminaison mondial ou vers l'un des points de terminaison régionaux pour lesquels vous activez votre Compte AWS. Pour plus d'informations, veuillez consulter la [section AWS STS de *Régions et points de terminaison*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region).  
Le paramètre `AUTHPARAMS` de l'exemple est un espace réservé pour votre *signature*. Une signature est l'information d'authentification que vous devez inclure dans les demandes d'API AWS HTTP. Nous vous recommandons d'utiliser le [AWS SDKs](https://aws.amazon.com/tools/)pour créer des demandes d'API, et l'un des avantages de cette méthode est qu'il SDKs gère la signature des demandes pour vous. Si vous devez créer et signer des demandes d'API manuellement, consultez [la section Signature des AWS demandes à l'aide de la version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) du *Référence générale d'Amazon Web Services*pour savoir comment signer une demande.

# Utiliser des informations d'identification temporaires avec AWS les ressources
<a name="id_credentials_temp_use-resources"></a>

Vous pouvez utiliser des informations d'identification de sécurité temporaires pour effectuer des demandes programmatiques de AWS ressources à l'aide de l' AWS API AWS CLI or (à l'aide du [AWS SDKs](https://aws.amazon.com/tools/)). Les informations d'identification temporaires fournissent les mêmes autorisations que les informations d'identification de sécurité à long terme, telles que les informations d'identification de l'utilisateur IAM. Toutefois, il existe quelques différences :
+ Lorsque vous passez un appel à l'aide d'informations d'identification de sécurité temporaires, l'appel doit inclure un jeton de session, qui est renvoyé avec ces informations d'identification temporaires. AWS utilise le jeton de session pour valider les informations d'identification de sécurité temporaires. 
+ Les informations d'identification temporaires arrivent à expiration après un intervalle spécifique. Une fois les informations d'identification temporaires arrivées à expiration, tous les appels que vous effectuez avec elles échoueront. Vous devez donc générer un nouvel ensemble d'informations d'identification temporaires. Les informations d'identification temporaires ne peuvent pas être étendues ou actualisées au-delà de l'intervalle spécifié d'origine.
+ Lorsque vous utilisez des informations d'identification temporaires pour effectuer une demande, votre principal peut inclure un ensemble d’étiquettes. Ces balises proviennent de balises de session et de balises attachées au rôle que vous endossez. Pour de plus amples informations sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

Si vous utilisez le [AWS SDKs](https://aws.amazon.com/tools), le [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/)(AWS CLI) ou les [Outils pour Windows PowerShell](https://aws.amazon.com/powershell), la manière d'obtenir et d'utiliser les informations d'identification de sécurité temporaires varie selon le contexte. Si vous exécutez du code ou AWS CLI des PowerShell commandes Tools for Windows dans une instance EC2, vous pouvez tirer parti des rôles pour Amazon EC2. Sinon, vous pouvez appeler une [API AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) pour obtenir les informations d'identification temporaires, puis les utiliser explicitement pour effectuer des appels aux services AWS .

**Note**  
Vous pouvez utiliser AWS Security Token Service (AWS STS) pour créer et fournir à des utilisateurs de confiance des informations d'identification de sécurité temporaires qui peuvent contrôler l'accès à vos AWS ressources. Pour plus d'informations sur AWS STS, voir[Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md). AWS STS est un service global dont le point de terminaison par défaut est situé à`https://sts.amazonaws.com`. Ce point de terminaison se trouve dans la région USA Est (Virginie du Nord), bien que les informations d'identification que vous obtenez de ce point de terminaison et d'autres soient valides dans le monde entier. Ces informations d'identification fonctionnent avec les services et les ressources dans n'importe quelle région. Vous pouvez également choisir d'effectuer des appels d' AWS STS API vers des points de terminaison situés dans l'une des régions prises en charge. Cela permet de réduire la latence en effectuant les demandes depuis les serveurs situés dans une région géographiquement plus proche de vous. Quelle que soit la région d'où proviennent vos informations d'identification, elles fonctionnent dans le monde entier. Pour plus d’informations, veuillez consulter [Gérez AWS STS dans un Région AWS](id_credentials_temp_enable-regions.md).

**Contents**
+ [Utilisation d'informations d'identification temporaires dans les instances Amazon EC2](#using-temp-creds-sdk-ec2-instances)
+ [En utilisant des informations de sécurité temporaires avec AWS SDKs](#using-temp-creds-sdk)
+ [En utilisant des informations de sécurité temporaires avec AWS CLI](#using-temp-creds-sdk-cli)
+ [Utilisation d'informations d'identification de sécurité temporaires avec des opérations d'API](#RequestWithSTS)
+ [En savoir plus](#using-temp-creds-more-info)

## Utilisation d'informations d'identification temporaires dans les instances Amazon EC2
<a name="using-temp-creds-sdk-ec2-instances"></a>

Si vous souhaitez exécuter des AWS CLI commandes ou du code dans une instance EC2, il est recommandé d'utiliser des [rôles pour Amazon EC2 pour](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) obtenir des informations d'identification. Vous créez un rôle IAM qui spécifie les autorisations que vous souhaitez accorder aux applications qui s'exécutent sur les instances EC2. Lorsque vous lancez l'instance, vous associez le rôle à cette instance.

Les PowerShell commandes Applications et Outils pour Windows qui s'exécutent sur l'instance peuvent ensuite obtenir des informations d'identification de sécurité temporaires automatiques à partir des métadonnées de l'instance. AWS CLI Vous n'avez pas besoin d'obtenir explicitement les informations d'identification de sécurité temporaires. Les outils AWS SDKs, AWS CLI, et pour Windows obtiennent PowerShell automatiquement les informations d'identification du service de métadonnées d'instance EC2 (IMDS) et les utilisent. Les informations d'identification temporaires disposent d'autorisations que vous définissez pour le rôle associé à l'instance.

Pour plus d'informations et d'exemples, consultez ce qui suit :
+  [Utilisation des rôles IAM pour accorder l'accès aux AWS ressources sur Amazon Elastic Compute Cloud —](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) AWS SDK pour Java
+  [Octroi d'accès à l'aide d'un rôle IAM —](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) AWS SDK pour .NET 
+  [Création d'un rôle](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html) — AWS SDK pour Ruby

## En utilisant des informations de sécurité temporaires avec AWS SDKs
<a name="using-temp-creds-sdk"></a>

Pour utiliser des informations d'identification de sécurité temporaires dans le code, vous appelez par programmation une AWS STS API similaire `AssumeRole` et vous extrayez les informations d'identification et le jeton de session qui en résultent. Vous utilisez ensuite ces valeurs comme informations d'identification pour les appels suivants à AWS. L'exemple suivant montre un pseudocode expliquant comment utiliser les informations d'identification de sécurité temporaires si vous utilisez un AWS SDK :

```
assumeRoleResult = AssumeRole(role-arn);
tempCredentials = new SessionAWSCredentials(
   assumeRoleResult.AccessKeyId, 
   assumeRoleResult.SecretAccessKey, 
   assumeRoleResult.SessionToken);
s3Request = CreateAmazonS3Client(tempCredentials);
```

Pour un exemple écrit en Python (en utilisant l'[AWS SDK pour Python (Boto)](https://aws.amazon.com/sdk-for-python/)), veuillez consulter [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md). Cet exemple montre comment appeler `AssumeRole` pour obtenir des informations d'identification de sécurité temporaires, puis utiliser ces informations d'identification pour appeler Amazon S3.

Pour plus d'informations sur la façon d'appeler `AssumeRole`, `GetFederationToken` et d'autres opérations d'API, consultez la [Référence sur l'API AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/). Pour plus d'informations sur l'obtention des informations d'identification de sécurité temporaires et du jeton de session à partir des résultats, consultez la documentation du kit SDK que vous utilisez. Vous pouvez trouver la documentation de tous AWS SDKs sur la [page de AWS documentation](https://aws.amazon.com/documentation) principale, dans la section **SDKs et boîtes à outils**.

Vous devez vérifier que vous obtenez un nouvel ensemble d'informations d'identification avant que les anciennes arrivent à expiration. Dans certains SDKs cas, vous pouvez utiliser un fournisseur qui gère le processus d'actualisation des informations d'identification à votre place ; consultez la documentation du SDK que vous utilisez. 

## En utilisant des informations de sécurité temporaires avec AWS CLI
<a name="using-temp-creds-sdk-cli"></a>

Vous pouvez utiliser les informations d'identification de sécurité temporaires avec l’interface AWS CLI. Cela peut vous être utile lors de test de politiques. 

À l'aide de l'[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/), vous pouvez appeler une [API AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) telle que `AssumeRole` ou `GetFederationToken`, puis capturer la sortie obtenue. L'exemple suivant illustre un appel à `AssumeRole` qui envoie la sortie dans un fichier. Dans l'exemple, le `profile` paramètre est supposé être un profil dans le fichier AWS CLI de configuration. Il est également supposé référencer les informations d'identification d'un utilisateur IAM qui a les autorisations d'endosser le rôle.

```
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt
```

Une fois l'exécution de la commande terminée, vous pouvez extraire l'ID de clé d'accès, la clé d'accès secrète et le jeton de session de la variable. Vous pouvez le faire manuellement ou à l'aide d'un script. Vous pouvez ensuite affecter ces valeurs aux variables d'environnement. 

Lorsque vous exécutez des AWS CLI commandes, les AWS CLI informations d'identification sont recherchées dans un ordre spécifique, d'abord dans les variables d'environnement, puis dans le fichier de configuration. Par conséquent, une fois que vous avez placé les informations d'identification temporaires dans les variables d'environnement, elles AWS CLI utilisent ces informations d'identification par défaut. (Si vous spécifiez un `profile` paramètre dans la commande, les variables d'environnement AWS CLI sont ignorées. Ils apparaissent plutôt AWS CLI dans le fichier de configuration, qui vous permet de remplacer les informations d'identification des variables d'environnement si nécessaire.) 

L'exemple suivant montre comment définir les variables d'environnement pour les informations d'identification de sécurité temporaires, puis appeler une AWS CLI commande. Comme aucun `profile` paramètre n'est inclus dans la AWS CLI commande, AWS CLI elle recherche d'abord les informations d'identification dans les variables d'environnement et utilise donc les informations d'identification temporaires. 

**Linux**

```
$ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
$ export AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of session token>
$ aws ec2 describe-instances --region us-west-1
```

**Windows**

```
C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of token> 
C:\> aws ec2 describe-instances --region us-west-1
```

## Utilisation d'informations d'identification de sécurité temporaires avec des opérations d'API
<a name="RequestWithSTS"></a>

Si vous envoyez des demandes d'API HTTPS directes à AWS, vous pouvez signer ces demandes avec les informations d'identification de sécurité temporaires que vous obtenez du AWS Security Token Service (AWS STS). Pour ce faire, vous utilisez l'ID de clé d'accès et la clé d'accès secrète que vous recevez AWS STS. Vous utilisez l'ID de clé d'accès et la clé d'accès secrète de la même façon que vous utiliseriez des informations d'identification à long terme pour signer une demande. Vous ajoutez également à votre demande d'API le jeton de session que vous recevez AWS STS. Vous ajoutez le jeton de session à un en-tête HTTP ou à un paramètre de chaîne de requête appelé `X-Amz-Security-Token`. Vous ajoutez le jeton de session à l'en-tête HTTP *ou* au paramètre de chaîne de requête, mais pas les deux. Pour plus d'informations sur la signature des demandes d'API HTTPS, consultez [la section Signature des demandes d' AWS API](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) dans le *Références générales AWS*.

## En savoir plus
<a name="using-temp-creds-more-info"></a>

Pour plus d'informations sur l'utilisation AWS STS avec d'autres AWS services, consultez les liens suivants :
+ **Amazon S3**. Veuillez consulter [Making Requests Using IAM User Temporary Credentials](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) (Envoyer des demandes au moyen d'informations d'identification temporaires de l'utilisateur IAM) ou [Making Requests Using Federated User Temporary Credentials](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html) (Envoyer des demandes au moyen d'informations d'identification temporaires de l'utilisateur fédéré) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
+ **Amazon SNS**. Consultez la rubrique [Utilisation de politiques basées sur une identité avec Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS) dans le *Guide du développeur Amazon Simple Notification Service*.
+ **Amazon SQS**. Consultez [Identity and Access Management dans Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS) dans le *Guide du développeur Amazon Simple Queue Service*
+ **Amazon SimpleDB**. Veuillez consulter [Using Temporary Security Credentials (Utilisation d'informations d'identification de sécurité temporaires)](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html) dans le *Manuel du développeur Amazon SimpleDB*.

# Autorisations affectées aux informations d’identification de sécurité temporaires
<a name="id_credentials_temp_control-access"></a>

Vous pouvez utiliser AWS Security Token Service (AWS STS) pour créer et fournir à des utilisateurs de confiance des informations d'identification de sécurité temporaires qui peuvent contrôler l'accès à vos AWS ressources. Pour plus d'informations sur AWS STS, voir[Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md). Lorsqu' AWS STS émet des informations d'identification de sécurité temporaires, celles-ci sont valides jusqu'au délai d'expiration spécifié et elles ne peuvent pas être annulées. Toutefois, les autorisations octroyées aux informations d'identification de sécurité temporaires sont évaluées chaque fois qu'une demande est effectuée à l'aide de ces informations. Il est donc possible de révoquer les informations d'identification en modifiant leurs droits d'accès après leur émission. 

Les rubriques suivantes supposent que vous avez une connaissance pratique des AWS autorisations et des politiques. Pour plus d'informations sur ces rubriques, consultez [Gestion de l'accès aux AWS ressources](access.md). 

**Topics**
+ [Autorisations pour AssumeRole, AssumeRoleWith SAML et AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md)
+ [Surveiller et contrôler les actions prises avec les rôles endossés](id_credentials_temp_control-access_monitor.md)
+ [Autorisations pour GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md)
+ [Autorisations pour GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md)
+ [Désactivation des autorisations affectées aux informations d'identification de sécurité temporaires](id_credentials_temp_control-access_disable-perms.md)
+ [Octroi d'autorisations pour créer des informations d'identification de sécurité temporaires](id_credentials_temp_control-access_enable-create.md)
+ [Octroi d’autorisations pour l’utilisation de sessions de console à identité renforcée](id_credentials_temp_control-access_sts-setcontext.md)

# Autorisations pour AssumeRole, AssumeRoleWith SAML et AssumeRoleWithWebIdentity
<a name="id_credentials_temp_control-access_assumerole"></a>

La politique d'autorisations du rôle endossé actuellement déterminé les autorisations octroyées aux informations d'identification de sécurité temporaires renvoyées par `AssumeRole`, `AssumeRoleWithSAML` et `AssumeRoleWithWebIdentity`. Vous définissez ces autorisations lors de la définition ou de la mise à jour du rôle. 

Le cas échéant, vous pouvez transmettre des [politiques de session](access_policies.md#policies_session) en ligne ou gérées en tant que paramètre des opérations d'API `AssumeRole`, `AssumeRoleWithSAML` ou `AssumeRoleWithWebIdentity`. Les politiques de session limitent les autorisations pour la session d'informations d'identification temporaires du rôle. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Vous pouvez utiliser les informations d'identification temporaires du rôle lors des appels d' AWS API suivants pour accéder aux ressources du compte propriétaire du rôle. Vous ne pouvez pas utiliser les politiques de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour en savoir plus sur la façon dont AWS détermine les autorisations effectives d'un rôle, consultez [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).

![\[PermissionsWhenPassingRoles_Schéma\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)


Les politiques associées aux informations d'identification à l'origine de l'appel ne `AssumeRole` sont pas évaluées AWS lors de la prise de la décision d' « autoriser » ou de « refuser » l'autorisation. L'utilisateur renonce temporairement à ses autorisations d'origine en faveur de celles affectées au rôle endossé. Dans le cas des opérations `AssumeRoleWithSAML` et de l'`AssumeRoleWithWebIdentity`API, il n'y a aucune politique à évaluer car l'appelant de l'API n'est pas une AWS identité.

## Exemple : attribution d'autorisations à l'aide de AssumeRole
<a name="permissions-assume-role-example"></a>

Vous pouvez utiliser l'opération d'API `AssumeRole` avec différents types de politiques. Voici quelques exemples.

### Politique d'autorisations de rôle
<a name="permissions-assume-role-example-role-access-policy"></a>

Dans cet exemple, vous appelez l'opération d'API `AssumeRole` sans spécifier la politique de session dans le paramètre `Policy` facultatif. Les autorisations affectées aux informations d'identification temporaires sont déterminées par la politique d'autorisations du rôle endossé. L'exemple de politique d'autorisations suivant accorde au rôle l'autorisation de répertorier tous les objets contenus dans un compartiment S3 nommé `productionapp`. Il permet également au rôle d'obtenir, de placer et de supprimer des objets dans ce compartiment.

**Example Exemple de politique d'autorisations de rôle**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}
```

### Politique de session transmise en tant que paramètre
<a name="permissions-assume-role-example-passed-policy"></a>

Imaginons que vous souhaitiez autoriser un utilisateur à endosser le même rôle que dans l'exemple suivant. Mais, dans ce cas, vous voulez que la session de rôle ait uniquement l'autorisation d'obtenir et de placer des objets dans le compartiment `productionapp` S3. Vous ne souhaitez pas l'autoriser à supprimer des objets. Pour cela, vous pouvez créer un rôle et spécifier les autorisations souhaitées dans la politique d'autorisations du rôle. Vous pouvez également appeler l'API `AssumeRole` et inclure des politiques de session dans le paramètre `Policy` facultatif dans le cadre de l'opération d'API. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Les politiques de session ne peuvent pas être utilisées pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour de plus amples informations sur les autorisations de session de rôle, veuillez consulter [Politiques de session](access_policies.md#policies_session). 

Une fois que vous avez récupéré les informations d'identification temporaires de la nouvelle session, vous pouvez les transmettre à l'utilisateur auquel vous voulez donner ces autorisations.

Par exemple, imaginons que la politique suivante soit transmise en tant que paramètre de l'appel d'API. La personne qui utilise la session dispose d'autorisations pour effectuer uniquement les actions suivantes : 
+ Répertorier tous les objets du compartiment `productionapp`.
+ Obtenir et placer des objets dans le compartiment `productionapp`.

Dans la session suivante, l'autorisation `s3:DeleteObject` est exclue du filtre et la session endossée n'obtient pas l'autorisation `s3:DeleteObject`. La politique définit les autorisations maximales pour la session de rôle afin qu'elle remplace les politiques d'autorisations existantes sur le rôle.

**Example Exemple de politique de session transmise avec l'appel d'API `AssumeRole`**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}
```

### Politique basée sur une ressource
<a name="permissions-assume-role-example-resource-based-policy"></a>

Certaines AWS ressources prennent en charge les politiques basées sur les ressources, et ces politiques fournissent un autre mécanisme pour définir les autorisations qui affectent les informations d'identification de sécurité temporaires. Seules quelques ressources, comme les compartiments Amazon S3, les rubriques Amazon SNS et les files d'attente Amazon SQS, prennent en charge les politiques basées sur des ressources. L'exemple suivant développe les exemples précédents, à l'aide d'un compartiment S3 nommé `productionapp`. La politique suivante est attachée au compartiment. 

Lorsque vous attachez la politique basée sur les ressources suivante au compartiment `productionapp`, *tous* les utilisateurs se voient refuser l'autorisation de supprimer des objets du compartiment. (Voir l'élément `Principal` dans la politique.) Cela inclut tous les utilisateurs du rôle endossé, même si la politique d'autorisations du rôle accorde l'autorisation `DeleteObject`. Une instruction `Deny` explicite a toujours priorité sur une instruction `Allow`.

**Example Exemple de politique de compartiment**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}
```

Pour plus d'informations sur la façon dont plusieurs types de politiques sont combinés et évalués par AWS, voir[Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).

# Surveiller et contrôler les actions prises avec les rôles endossés
<a name="id_credentials_temp_control-access_monitor"></a>

Un [rôle IAM](id_roles.md) est un objet dans IAM auquel sont affectées des [autorisations](access_policies.md). Lorsque vous [assumez ce rôle](id_roles_manage-assume.md) en utilisant une identité IAM ou une identité extérieure AWS, vous recevez une session avec les autorisations attribuées au rôle. 

Lorsque vous effectuez des actions dans AWS, les informations relatives à votre session peuvent être enregistrées AWS CloudTrail pour que l'administrateur de votre compte puisse les surveiller. Les administrateurs peuvent configurer les rôles de sorte à exiger des identités qu'elles transmettent une chaîne personnalisée identifiant la personne ou l'application qui effectue des actions dans AWS. Ces informations d'identité sont stockées en tant qu'*identité source* dans AWS CloudTrail. Lorsque l'administrateur examine l'activité dans CloudTrail, il peut consulter les informations d'identité de la source afin de déterminer qui ou quoi a effectué des actions dans le cadre de sessions à rôle assumé.

Une fois qu'une identité source est définie, elle est présente dans les demandes concernant toute AWS action entreprise au cours de la session de rôle. La valeur définie est conservée lorsqu'un rôle est utilisé pour assumer un autre rôle via l' AWS API AWS CLI or, ce que l'on appelle le [chaînage de rôles](id_roles.md#iam-term-role-chaining). La valeur définie ne peut pas être modifiée durant la session de rôle. Les administrateurs peuvent configurer des autorisations granulaires en fonction de la présence ou de la valeur de l'identité source afin de mieux contrôler les AWS actions entreprises avec des rôles partagés. Vous pouvez décider si l'attribut d'identité source peut être utilisé, s'il est requis ; et quelle valeur peut être utilisée.



L'utilisation de l'identité source est radicalement différente de celle du nom de session de rôle et des balises de session. La valeur d'identité source ne peut pas être modifiée une fois qu'elle est définie, et elle persiste pour toutes les actions supplémentaires qui sont prises durant la session de rôle. Voici comment utiliser les balises de session et le nom de session de rôle : 
+ **Session tags** (Balises de session) : vous pouvez transmettre des balises de session lorsque vous endossez un rôle ou fédérez un utilisateur. Les balises de session sont présentes lorsqu'un rôle est endossé. Vous pouvez définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Vous pouvez ensuite l'utiliser CloudTrail pour afficher les demandes faites pour assumer des rôles ou fédérer des utilisateurs. Pour en savoir plus sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).
+ **Role session name** (Nom de la session de rôle) : vous pouvez utiliser la clé de condition `sts:RoleSessionName` dans une politique d'approbation de rôle pour exiger que vos utilisateurs fournissent un nom de session spécifique lorsqu'ils endossent un rôle. Le nom de session de rôle peut servir à différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux. Pour en savoir plus sur le nom de session de rôle, consultez [sts : RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname).

Nous vous recommandons d'utiliser l'identité source pour contrôler l'identité qui endosse un rôle. L'identité de la source est également utile pour les CloudTrail journaux de minage afin de déterminer qui a utilisé le rôle pour effectuer des actions. 

**Topics**
+ [Configuration d'utilisation de l'identité source](#id_credentials_temp_control-access_monitor-setup)
+ [Ce qu'il faut savoir sur l'identité source](#id_credentials_temp_control-access_monitor-know)
+ [Autorisations requises pour définir l'identité source](#id_credentials_temp_control-access_monitor-perms)
+ [Spécification d'une identité source lorsqu'un rôle est endossé](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [Utilisation de l'identité source avec AssumeRole](#id_credentials_temp_control-access_monitor-assume-role)
+ [Utilisation de l'identité source avec AssumeRoleWith SAML](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [Utilisation de l'identité source avec AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [Contrôle de l'accès au moyen des informations d'identité source](#id_credentials_temp_control-access_monitor-control-access)
+ [Affichage de l'identité de la source dans CloudTrail](#id_credentials_temp_control-access_monitor-ct)

## Configuration d'utilisation de l'identité source
<a name="id_credentials_temp_control-access_monitor-setup"></a>

Votre configuration d'utilisation de l'identité source dépend de la méthode employée lorsque vos rôles sont endossés. Par exemple, vos utilisateurs IAM peuvent endosser des rôles directement via l'opération `AssumeRole`. Si vous possédez des identités d'entreprise, également appelées identités du personnel, elles peuvent accéder à vos AWS ressources en utilisant`AssumeRoleWithSAML`. Si des utilisateurs finaux accèdent à vos applications mobiles ou Web, ils peuvent le faire en utilisant `AssumeRoleWithWebIdentity`. La présentation du flux de haut niveau qui suit vous aidera à comprendre comment effectuer une configuration pour utiliser les informations d'identité source dans votre environnement existant.

1. **Configurer les utilisateurs et les rôles test** : en utilisant un environnement de préproduction, configurez les utilisateurs et les rôles test, et configurez leurs politiques afin d'autoriser la définition d'une identité source.

   Si vous utilisez un fournisseur d'identité (IdP) pour vos identités fédérées, configurez-le de sorte à transmettre un attribut utilisateur de votre choix pour l'identité source dans l'assertion ou le jeton.

1. **Assumer le rôle** : testez le fait d'endosser des rôles et de transmettre une identité source avec les utilisateurs et les rôles que vous configurez pour le test.

1. **Révision CloudTrail** : passez en revue les informations d'identité source de vos rôles de test dans vos CloudTrail journaux.

1. **Entraîner vos utilisateurs** : après avoir effectué des tests dans votre environnement de préproduction, vérifiez que vos utilisateurs savent parfaitement comment transmettre les informations d'identité source, si nécessaire. Définissez une date limite à laquelle vous exigerez de vos utilisateurs qu'ils fournissent une identité source dans votre environnement de production.

1. **Configurer des politiques de production** : configurez des politiques pour votre environnement de production, puis ajoutez-les à vos utilisateurs et rôles de production.

1. **Surveiller l'activité** : surveillez l'activité de votre rôle de production à l'aide de CloudTrail journaux.

## Ce qu'il faut savoir sur l'identité source
<a name="id_credentials_temp_control-access_monitor-know"></a>

Gardez ce qui suit à l'esprit lorsque vous travaillez avec l'identité source.
+ Les politiques d'approbation pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:SetSourceIdentity`. Pour les rôles qui ne disposent pas de cette autorisation dans la politique d'approbation de rôle, l'opération `AssumeRole*` échouera. Si vous ne souhaitez pas mettre à jour la politique d'approbation de rôle pour chaque rôle, vous pouvez utiliser une instance de fournisseur d'identité distincte pour transmettre l'identité source. Ajoutez ensuite l'autorisation `sts:SetSourceIdentity` uniquement aux rôles qui sont connectés au fournisseur d'identité distinct.
+ Lorsqu'une identité définit une identité source, la clé `sts:SourceIdentity` est présente dans la demande. Pour les actions qui seront prises ultérieurement durant la session de rôle, la clé `aws:SourceIdentity` est présente dans la demande. AWS ne contrôle la valeur de l'identité source dans aucune des clés `sts:SourceIdentity` ou `aws:SourceIdentity`. Si vous choisissez d'exiger une identité source, vous devez choisir un attribut que vos utilisateurs ou votre IdP doivent fournir. Pour des raisons de sécurité, vous devez vérifier votre capacité à contrôler la façon dont ces valeurs sont fournies.
+ La valeur de l'identité source doit comporter entre 2 et 64 caractères. Elle ne peut contenir que des caractères alphanumériques, des traits de soulignement et les caractères suivants : **. , \$1 = @ -** (tiret). Vous ne pouvez pas utiliser une valeur qui commence par le texte **aws:**. Ce préfixe est réservé à un usage AWS interne.
+ Les informations d'identité source ne sont pas capturées CloudTrail lorsqu'un AWS service ou un rôle lié à un service exécute une action au nom d'une identité fédérée ou d'un personnel. 

**Important**  
Vous ne pouvez pas passer à un rôle dans le AWS Management Console qui nécessite la définition d'une identité source lorsque le rôle est assumé. Pour assumer un tel rôle, vous pouvez utiliser l' AWS API AWS CLI or pour appeler l'`AssumeRole`opération et spécifier le paramètre d'identité source.

## Autorisations requises pour définir l'identité source
<a name="id_credentials_temp_control-access_monitor-perms"></a>

En plus de l'action qui correspond à l'opération d'API, vous devez disposer de l'action d'autorisation suivante dans votre politique : 

```
sts:SetSourceIdentity
```
+ Pour spécifier une identité source, les principaux (utilisateurs et rôles IAM) doivent disposer des autorisations nécessaires pour `sts:SetSourceIdentity`. Votre qualité d'administrateur vous permet de configurer cela dans la politique de confiance de rôle et la politique d'autorisations du principal.
+ Lorsque vous endossez un rôle avec un autre rôle ([chaînage de rôles](id_roles.md#iam-term-role-chaining)), des autorisations sont exigées pour `sts:SetSourceIdentity` tant dans la politique d'autorisations du principal qui endosse le rôle que dans la politique de confiance de rôle du rôle cible. Sinon, l'opération consistant à endosser le rôle échouera.
+ Lorsque vous utilisez l'identité source, les politiques d'approbation de rôle pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:SetSourceIdentity`. L'opération `AssumeRole*` échouera pour tout rôle connecté à un fournisseur d'identité sans cette autorisation. Si vous ne voulez pas mettre à jour la politique de confiance de rôle pour chaque rôle, vous pouvez utiliser une instance IdP distincte pour transmettre l'identité source et ajouter l'autorisation `sts:SetSourceIdentity` aux seuls rôles qui sont connectés à l'instance IdP distincte.
+ Pour définir une identité source au-delà des limites de compte, vous devez inclure l'autorisation `sts:SetSourceIdentity` à deux endroits. Elle doit être présente dans la politique d'autorisations du principal dans le compte d'origine et dans la politique de confiance de rôle du rôle dans le compte cible. Vous devrez peut-être faire cela lorsqu'un rôle est utilisé pour endosser un rôle dans un autre compte ([chaînage de rôles](id_roles.md#iam-term-role-chaining)).

Supposons, par exemple, qu'en tant qu'administrateur de compte, vous vouliez autoriser l'utilisateur IAM `DevUser` dans votre compte à endosser le `Developer_Role`dans le même compte. Mais vous voulez autoriser cette action uniquement si l'utilisateur a défini l'identité source à son nom d'utilisateur IAM. Vous pouvez attacher la politique suivante à l'utilisateur IAM.

**Example Exemple de politique basée sur l'identité attachée à DevUser**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AssumeRole",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/Developer_Role"
    },
    {
      "Sid": "SetAwsUserNameAsSourceIdentity",
      "Effect": "Allow",
      "Action": "sts:SetSourceIdentity",
      "Resource": "arn:aws:iam::123456789012:role/Developer_Role",
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": "${aws:username}"
        }
      }
    }
  ]
}
```

Pour appliquer les valeurs d'identité source acceptables, vous pouvez configurer la politique de confiance de rôle suivante. La politique donne à l'utilisateur IAM les autorisations `DevUser` pour endosser le rôle et définir une identité source. La clé de condition `sts:SourceIdentity` définit la valeur d'identité source acceptable.

**Example Exemple de politique de confiance de rôle pour une identité source**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowDevUserAssumeRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/DevUser"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "sts:SourceIdentity": "DevUser"
        }
      }
    }
  ]
}
```

------

À l'aide des informations d'identification de l'utilisateur IAM`DevUser`, celui-ci tente de supposer qu'il `DeveloperRole` utilise la AWS CLI demande suivante.

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \ 
--source-identity DevUser \
```

Lors de l' AWS évaluation de la demande, le contexte de la demande contient le nom `sts:SourceIdentity` de`DevUser`.

## Spécification d'une identité source lorsqu'un rôle est endossé
<a name="id_credentials_temp_control-access_monitor-specify-sourceid"></a>

Vous pouvez spécifier une identité source lorsque vous utilisez l'une des opérations d' AWS STS `AssumeRole*`API pour obtenir des informations d'identification de sécurité temporaires pour un rôle. L'opération d'API que vous utilisez varie selon votre cas d'utilisation. Par exemple, si vous utilisez des rôles IAM pour donner aux utilisateurs IAM l'accès à AWS des ressources auxquelles ils n'ont normalement pas accès, vous pouvez utiliser cette opération. `AssumeRole` Si vous utilisez la fédération d'identités d'entreprise pour gérer vos utilisateurs de main-d'œuvre, vous pouvez utiliser l'opération `AssumeRoleWithSAML`. Si vous utilisez la fédération OIDC pour autoriser des utilisateurs finaux à accéder à vos applications mobiles ou Web, vous pouvez utiliser l’opération `AssumeRoleWithWebIdentity`. Les sections suivantes détaillent l'utilisation de l'identité source avec chaque opération. Pour en savoir plus sur les scénarios courants d'informations d'identification temporaires, veuillez consulter [Scénarios courants d'informations d'identification temporaires](id_credentials_temp.md#sts-introduction).

## Utilisation de l'identité source avec AssumeRole
<a name="id_credentials_temp_control-access_monitor-assume-role"></a>

L'`AssumeRole`opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Vous pouvez utiliser l'utilisateur ou les informations d'identification du rôle IAM pour appeler `AssumeRole`. Pour transmettre l'identité de la source tout en assumant un rôle, utilisez l'`-–source-identity` AWS CLI option ou le paramètre `SourceIdentity` AWS API. L'exemple suivant vous explique comment spécifier l'identité source avec la AWS CLI.

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \ 
--source-identity Admin \
```

## Utilisation de l'identité source avec AssumeRoleWith SAML
<a name="id_credentials_temp_control-access_monitor-assume-role-saml"></a>

Le principal qui appelle l'opération `AssumeRoleWithSAML` est authentifié à l'aide de la fédération basée sur SAML. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Pour plus d'informations sur l'utilisation de la fédération basée sur SAML pour l' AWS Management Console accès, consultez. [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md) Pour plus de détails sur AWS CLI AWS l'accès à l'API, consultez[Fédération SAML 2.0](id_roles_providers_saml.md). Pour un didacticiel sur la configuration de la fédération SAML pour vos utilisateurs d'Active Directory, consultez la section [Authentification AWS fédérée avec les services de fédération Active Directory (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) dans le AWS blog de sécurité. 

En tant qu'administrateur, vous pouvez autoriser les membres du répertoire de votre entreprise à se fédérer pour AWS utiliser cette AWS STS `AssumeRoleWithSAML` opération. Pour ce faire, effectuez les tâches suivantes :

1. [Configurer un fournisseur SAML dans votre organisation](id_roles_providers_saml_3rd-party.md).

1. [Créer un fournisseur SAML dans IAM](id_roles_providers_create_saml.md)

1. [Configurez un rôle et ses autorisations AWS pour vos principaux fédérés SAML](id_roles_create_for-idp_saml.md).

1. [Achever la configuration de l'IdP SAML et créer des assertions pour la réponse d'authentification SAML](id_roles_providers_create_saml_assertions.md).

Pour définir un attribut SAML pour l'identité source, incluez dans l'élément `Attribute` l'attribut `Name` défini à l'adresse `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Utilisez l'élément `AttributeValue` pour spécifier la valeur de l'identité source. Par exemple, supposons que vous souhaitez transmettre l'attribut d'identité suivant en tant qu'identité source : 

`SourceIdentity:DiegoRamirez`

Pour transmettre cet attribut, incluez l'élément suivant dans votre assertion SAML.

**Example Extrait d'une assertion SAML**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
<AttributeValue>DiegoRamirez</AttributeValue>
</Attribute>
```

## Utilisation de l'identité source avec AssumeRoleWithWebIdentity
<a name="id_credentials_temp_control-access_monitor-assume-role-web-id"></a>

Le principal qui appelle l’opération `AssumeRoleWithWebIdentity` est authentifié à l’aide de la fédération compatible OpenID Connect (OIDC). Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux ressources AWS . Pour de plus amples informations sur l’utilisation de la fédération OIDC pour l’accès à l’ AWS Management Console , consultez [Fédération OIDC](id_roles_providers_oidc.md).

Pour transmettre l'identité source depuis OpenID Connect (OIDC), vous devez inclure l'identité source dans le jeton web JSON (JWT). Incluez l'identité source dans l'espace de noms `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` dans le jeton lorsque vous soumettez la demande `AssumeRoleWithWebIdentity`. Pour en savoir plus sur les jetons OIDC et les revendications, veuillez consulter [Utilisation des jetons avec les groupes d'utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) dans le *Guide du développeur Amazon Cognito *.

Par exemple, le JWT décodé suivant est un jeton utilisé pour appeler `AssumeRoleWithWebIdentity` avec l'identité source `Admin`.

**Example Exemple de jeton web JSON décodé**  

```
{
    "sub": "john",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/source_identity":"Admin"
}
```

## Contrôle de l'accès au moyen des informations d'identité source
<a name="id_credentials_temp_control-access_monitor-control-access"></a>

Lorsqu'une identité source est initialement définie, la SourceIdentity clé [sts :](reference_policies_iam-condition-keys.md#ck_sourceidentity) est présente dans la requête. Une fois qu'une identité source est définie, la SourceIdentity clé [aws :](reference_policies_condition-keys.md#condition-keys-sourceidentity) est présente dans toutes les demandes suivantes effectuées au cours de la session de rôle. En tant qu'administrateur, vous pouvez rédiger des politiques qui accordent une autorisation conditionnelle pour effectuer des AWS actions en fonction de l'existence ou de la valeur de l'attribut d'identité source.

Imaginez que vous souhaitiez demander à vos développeurs de définir une identité source afin d'assumer un rôle essentiel et d'autoriser l'écriture sur une AWS ressource critique de production. Imaginez également que vous accordez AWS l'accès à l'identité de votre personnel en utilisant`AssumeRoleWithSAML`. Comme vous voulez que seuls les développeurs senior Saanvi et Diego aient accès au rôle, vous créez a politique de confiance suivante pour le rôle.

**Example Exemple de politique d'approbation de rôle pour une identité source (SAML)**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "SAMLProviderAssumeRoleWithSAML",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
      },
      "Action": [
        "sts:AssumeRoleWithSAML"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    },
    {
      "Sid": "SetSourceIdentitySrEngs",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
      },
      "Action": [
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": [
            "Saanvi",
            "Diego"
          ]
        }
      }
    }
  ]
}
```

------

La politique d'approbation contient une condition pour l’interface `sts:SourceIdentity` qui exige une identité source de Saanvi ou Diego pour endosser le rôle critique.

Par ailleurs, si vous utilisez un fournisseur OIDC pour la fédération et que les utilisateurs sont authentifiés avec l’interface `AssumeRoleWithWebIdentity`, votre politique d’approbation de rôle peut se présenter comme suit.

**Example Exemple de politique d'approbation de rôle pour l'identité source (fournisseur OIDC)**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
      },
      "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "server.example.com:aud": "oidc-audience-id"
        },
        "StringLike": {
          "sts:SourceIdentity": [
            "Saanvi",
            "Diego"
          ]
        }
      }
    }
  ]
}
```

------

### Chaînage de rôles et exigences entre comptes
<a name="id_credentials_temp_control-access_monitor-chain"></a>

Supposons que vous vouliez autoriser les utilisateurs ayant endossé un `CriticalRole` à endosser un `CriticalRole_2` dans un autre compte. Les informations d'identification de session de rôle qui ont été obtenues pour endosser le `CriticalRole` sont utilisées pour effectuer un [chaînage de rôles](id_roles.md#iam-term-role-chaining) à un second rôle, `CriticalRole_2`, dans un autre compte. Le rôle est endossé au-delà d'une limite de compte. Par conséquent, l'autorisation `sts:SetSourceIdentity` doit être octroyée tant dans la politique d'autorisations sur le `CriticalRole` que dans la politique de confiance de rôle sur le `CriticalRole_2`.

**Example Exemple de politique d'autorisation sur CriticalRole**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AssumeRoleAndSetSourceIdentity",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
    }
  ]
}
```

------

Afin de sécuriser la définition de l'identité source au-delà de la limite du compte, la politique de confiance de rôle suivante fait uniquement confiance au principal de rôle pour `CriticalRole` pour définir l'identité source.

**Example Exemple de politique de confiance dans les rôles sur CriticalRole \$12**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/CriticalRole"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "aws:SourceIdentity": ["Saanvi","Diego"]
        }
      }
    }
  ]
}
```

------

L'utilisateur effectue l'appel suivant en utilisant les informations d'identification de session de rôle obtenues en assumant CriticalRole. L'identité de la source a été définie lors de l'hypothèse de CriticalRole, il n'est donc pas nécessaire de la redéfinir explicitement. Si l'utilisateur tente de définir une identité source différente de la valeur définie lors de la supposition de `CriticalRole`, la demande d'endosser le rôle sera refusée.

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \ 
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```

Lorsque le principal appelant endosse le rôle, l'identité source dans la demande persiste à partir de la première session de rôle endossée. Par conséquent, les clés `aws:SourceIdentity` et `sts:SourceIdentity` sont toutes deux présentes dans le contexte de demande.

## Affichage de l'identité de la source dans CloudTrail
<a name="id_credentials_temp_control-access_monitor-ct"></a>

Vous pouvez l'utiliser CloudTrail pour afficher les demandes faites pour assumer des rôles ou fédérer des utilisateurs. Vous pouvez également afficher les demandes de rôle ou d'utilisateur souhaitant effectuer des actions dans AWS. Le fichier CloudTrail journal contient des informations sur l'identité source définie pour le rôle assumé ou la session utilisateur fédérée. Pour de plus amples informations, consultez [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md).

Supposons, par exemple, qu'un utilisateur fasse une AWS STS `AssumeRole` demande et définisse une identité source. Vous pouvez trouver les `sourceIdentity` informations dans la `requestParameters` clé de votre CloudTrail journal.

**Example Exemple de section RequestParameters dans un journal AWS CloudTrail**  

```
"eventVersion": "1.05",
    "userIdentity": {
        "type": "AWSAccount",
        "principalId": "AIDAJ45Q7YFFAREXAMPLE",
        "accountId": "111122223333"
    },
    "eventTime": "2020-04-02T18:20:53Z",
    "eventSource": "sts.amazonaws.com",
    "eventName": "AssumeRole",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.64",
    "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
    "requestParameters": {
        "roleArn": "arn:aws:iam::123456789012:role/DevRole",
        "roleSessionName": "Dev1",
        "sourceIdentity": "source-identity-value-set"
    }
```

Si l'utilisateur utilise la session de rôle assumé pour effectuer une action, les informations d'identité de la source sont présentes dans la `userIdentity` clé du CloudTrail journal.

**Example Exemple de clé UserIdentity dans un journal AWS CloudTrail**  

```
{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
    "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
    "accountId": "123456789012",
    "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "principalId": "AROAJ45Q7YFFAREXAMPLE",
        "arn": "arn:aws:iam::123456789012:role/DevRole",
        "accountId": "123456789012",
        "userName": "DevRole"
      },
      "webIdFederationData": {},
      "attributes": {
        "mfaAuthenticated": "false",
        "creationDate": "2021-02-21T23:46:28Z"
      },
      "sourceIdentity": "source-identity-value-present"
    }
  }
}
```

Pour voir des exemples AWS STS d'événements d'API dans CloudTrail les journaux, consultez[Exemple d'événements d'API IAM dans le journal CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api). Pour plus de détails sur les informations contenues dans les fichiers CloudTrail journaux, consultez la section [Référence des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) dans le *guide de AWS CloudTrail l'utilisateur*.

# Autorisations pour GetFederationToken
<a name="id_credentials_temp_control-access_getfederationtoken"></a>

L'opération `GetFederationToken` est appelée par un utilisateur IAM et renvoie les informations d'identification temporaires pour cet utilisateur. Cette opération *fédère* l'utilisateur. Les autorisations attribuées à une session utilisateur AWS STS fédérée sont définies à l'un des deux endroits suivants : 
+ Les politiques de session transmises en tant que paramètre de l'appel d'API `GetFederationToken`. (Il s'agit du scénario le plus courant.)
+ Stratégie basée sur les ressources qui nomme explicitement la session utilisateur AWS STS fédérée dans l'`Principal`élément de la stratégie. (Ce scénario est moins courant.)

Les politiques de session sont des politiques avancées que vous transmettez en tant que paramètres lorsque vous créez par programmation une session temporaire. Lorsque vous créez une session utilisateur AWS STS fédérée et que vous adoptez des politiques de session, les autorisations de session qui en résultent sont à l'intersection de la politique basée sur l'identité de l'utilisateur et des politiques de session. Vous ne pouvez pas utiliser la politique de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité de l'utilisateur fédéré.

Cela signifie que dans la plupart des cas, si vous ne transmettez pas de politique avec l'appel d'API `GetFederationToken`, les informations d'identification de sécurité temporaires générées ne disposent d'aucune autorisation. Toutefois, une politique basée sur les ressources peut fournir des autorisations supplémentaires pour la session. Vous pouvez accéder à une ressource avec une politique basée sur les ressources, qui spécifie votre session en tant que principal autorisé. 

Les illustrations suivantes sont une représentation visuelle de la façon dont les politiques interagissent pour déterminer les autorisations accordées aux informations d'identification de sécurité temporaires retournées par un appel à `GetFederationToken`.

![\[Utilisateur IAM Les illustrations suivantes indiquent que les autorisations de session sont à la croisée de la politique basée sur l’identité de l’utilisateur et des politiques de session. Les autorisations de session peuvent également être à la croisée de la politique basée sur l’identité de l’utilisateur et des politiques basées sur les ressources.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)


## Exemple : attribution d'autorisations à l'aide de GetFederationToken
<a name="permissions-get-federation-token-example"></a>

Vous pouvez utiliser l'action d'API `GetFederationToken` avec différents types de politiques. Voici quelques exemples.

### Politique attachée à l'utilisateur IAM
<a name="permissions-get-federation-token-example-iam-user"></a>

Dans cet exemple, une application cliente basée sur un navigateur s'appuie sur deux services web backend. L’un des backend est votre propre serveur d'authentification qui utilise votre système d'identité pour authentifier l'application cliente. L'autre backend est un service AWS qui fournit certaines des fonctionnalités de l'application cliente. L'application cliente est authentifiée par votre serveur, puis ce dernier créée ou récupère la politique d'autorisation appropriée. Ensuite, votre serveur appelle l'API `GetFederationToken` afin d'obtenir des informations d'identification de sécurité temporaires, puis il retourne ces informations d'identification à l'application cliente. L'application cliente peut ensuite adresser des demandes directement au AWS service avec les informations d'identification de sécurité temporaires. Cette architecture permet à l'application cliente de faire des AWS demandes sans intégrer d'informations d' AWS identification à long terme.

Votre serveur d'authentification appelle l'API `GetFederationToken` avec les informations d'identification de sécurité à long terme d'un utilisateur IAM nommé `token-app`. Cependant, les informations d'identification de l'utilisateur IAM à long terme restent sur votre serveur et ne sont jamais distribuées au client. L'exemple de politique suivant est attaché à l'utilisateur `token-app` IAM et définit l'ensemble le plus large d'autorisations dont vos utilisateurs AWS STS fédérés (clients) auront besoin. Notez que l'`sts:GetFederationToken`autorisation est requise pour que votre service d'authentification obtienne des informations d'identification de sécurité temporaires pour les utilisateurs AWS STS fédérés.

**Example Exemple de politique attachée à un `token-app` d'utilisateur IAM qui appelle `GetFederationToken`**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListTables",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sqs:ReceiveMessage",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sns:ListSubscriptions",
      "Resource": "*"
    }
  ]
}
```

La politique précédente accorde plusieurs autorisations à l'utilisateur IAM. Cependant, cette politique à elle seule n'accorde aucune autorisation à l'utilisateur AWS STS fédéré. Si cet utilisateur IAM appelle `GetFederationToken` et ne transmet pas de politique en tant que paramètre de l'appel d'API, l'utilisateur AWS STS fédéré qui en résulte ne dispose d'aucune autorisation effective. 

### Politique de session transmise en tant que paramètre
<a name="permissions-get-federation-token-example-passed-policy"></a>

La méthode la plus courante pour s'assurer que l'utilisateur AWS STS fédéré dispose des autorisations appropriées consiste à transmettre les politiques de session dans l'appel `GetFederationToken` d'API. En reprenant l'exemple précédent, imaginons que `GetFederationToken` est appelé avec les informations d'identification de l'utilisateur `token-app` IAM. Imaginons ensuite que la politique de session suivante est transmise en tant que paramètre de l'appel d'API. L’utilisateur fédéré AWS STS a obtenu l’autorisation de répertorier le contenu du compartiment Amazon S3 nommé `productionapp`. L'utilisateur ne peut pas effectuer les actions Amazon S3 `GetObject` `PutObject` et `DeleteObject` sur les éléments dans le compartiment `productionapp`.

L'utilisateur fédéré se voit attribuer ces autorisations, car elles sont une combinaison des politiques d'utilisateur IAM et les politiques de session que vous transmettez.

L'utilisateur AWS STS fédéré n'a pas pu effectuer d'actions dans Amazon SNS, Amazon SQS, Amazon DynamoDB ou dans aucun compartiment S3 à l'exception de. `productionapp` Ces actions sont refusées, même si ces autorisations sont accordées à l'utilisateur IAM associé à l'appel `GetFederationToken`.

**Example Exemple de politique transmise en tant que paramètre de l'appel d'API `GetFederationToken`**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::productionapp"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::productionapp/*"]
    }
  ]
}
```

### Politiques basées sur les ressources
<a name="permissions-get-federation-token-resource-based-policy"></a>

Certaines AWS ressources prennent en charge les politiques basées sur les ressources, et ces politiques fournissent un autre mécanisme permettant d'accorder des autorisations directement à un utilisateur AWS STS fédéré. Seuls certains AWS services prennent en charge les politiques basées sur les ressources. Par exemple, Amazon S3 comprend des compartiments, Amazon SNS des rubriques, et Amazon SQS des files d'attente auxquelles vous pouvez attacher des politiques. Pour obtenir la liste de tous les services prenant en charge les politiques basées sur les ressources, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et passez en revue la colonne « Politiques basées sur les ressources » des tableaux. Vous pouvez utiliser des politiques basées sur les ressources pour attribuer des autorisations directement à un utilisateur AWS STS fédéré. Pour ce faire, spécifiez l'Amazon Resource Name (ARN) de l'utilisateur AWS STS fédéré dans l'`Principal`élément de la politique basée sur les ressources. L'exemple suivant illustre cette méthode et développe les exemples précédents, à l'aide d'un compartiment S3 nommé `productionapp`. 

La politique basée sur les ressources suivante est attachée au compartiment. Cette politique de compartiment permet à un utilisateur AWS STS fédéré nommé Carol d'accéder au compartiment. Lorsque l'exemple de politique décrit précédemment est attaché à l'utilisateur `token-app` IAM, l'utilisateur AWS STS fédéré nommé Carol est autorisé à effectuer les `s3:DeleteObject` actions `s3:GetObject``s3:PutObject`, et sur le bucket nommé. `productionapp` Cela est vrai même lorsqu'aucune politique de session n'est transmise en tant que paramètre de l'appel d'API `GetFederationToken`. En effet, dans ce cas, l'utilisateur AWS STS fédéré nommé Carol a reçu des autorisations explicites en vertu de la politique basée sur les ressources suivante. 

N'oubliez pas qu'un utilisateur AWS STS fédéré ne reçoit des autorisations que lorsque ces autorisations sont explicitement accordées à la fois à l'utilisateur IAM ***et*** à l'utilisateur AWS STS fédéré. Ils peuvent également être accordés (au sein du compte) par une politique basée sur les ressources qui nomme explicitement l'utilisateur AWS STS fédéré dans l'`Principal`élément de la politique, comme dans l'exemple suivant.

**Example Exemple de politique de compartiment qui autorise l'accès à l'utilisateur fédéré**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Principal": {
            "AWS": "arn:aws:sts::111122223333:federated-user/Carol"
        },
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:DeleteObject"
        ],
        "Resource": [
            "arn:aws:s3:::productionapp/*"
        ]
    }
}
```

Pour plus d'informations sur la manière dont les politiques sont évaluées, consultez la rubrique [Logique d'évaluation des politiques](reference_policies_evaluation-logic.md).

# Autorisations pour GetSessionToken
<a name="id_credentials_temp_control-access_getsessiontoken"></a>

La bonne occasion pour appeler l’`GetSessionToken` opération d'API ou la `get-session-token` commande CLI est lorsqu'un utilisateur doit être authentifié avec l'authentification multi-facteur (MFA). Il est possible d'écrire une politique qui autorise certaines actions uniquement lorsque ces actions sont requises par un utilisateur authentifié à l'aide de MFA. Pour réussir à transmettre le contrôle de l'autorisation d'authentification MFA, un utilisateur doit d'abord appeler `GetSessionToken` et inclure le `SerialNumber` facultatif et `TokenCode` les paramètres. Si l'utilisateur est correctement authentifié par un dispositif MFA, les informations d'identification retournées par l'opération d'API `GetSessionToken` incluent le contexte MFA. Ce contexte indique que l'utilisateur est authentifié par l'authentification MFA et est autorisé pour les opérations d'API nécessitant une authentification MFA.

## Autorisations requises pour GetSessionToken
<a name="getsessiontoken-permissions-required"></a>

Aucune autorisation n'est requise pour qu'un utilisateur obtienne un jeton de session. Le but principal de l'opération `GetSessionToken` est d'authentifier l'utilisateur à l'aide de l'authentification MFA. Vous ne pouvez pas utiliser de stratégies pour contrôler les opérations d’authentification.

Pour autoriser l'exécution de la plupart AWS des opérations, vous devez ajouter l'action portant le même nom à une politique. Par exemple, pour créer un utilisateur, vous devez utiliser l'opération d'API `CreateUser`, la commande CLI `create-user` ou l' AWS Management Console. Pour effectuer ces opérations, vous devez disposer d'une politique qui vous permet d'accéder à l'action `CreateUser` .

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateUser",
            "Resource": "*"
        }
    ]
}
```

------

Vous pouvez inclure l'action `GetSessionToken` dans vos politiques, mais elle n'a aucun effet sur la possibilité de l'utilisateur d'effectuer l'opération `GetSessionToken` .

## Autorisations accordées par GetSessionToken
<a name="getsessiontoken-permissions-granted"></a>

Si `GetSessionToken` est appelée avec les informations d'identification d'un utilisateur IAM, les informations d'identification de sécurité temporaires ont les mêmes autorisations que cet utilisateur IAM. De même, `GetSessionToken` s'ils sont appelés avec des Utilisateur racine d'un compte AWS informations d'identification, les informations d'identification de sécurité temporaires ont des autorisations d'utilisateur root.

**Note**  
Il est recommandé de ne pas appeler `GetSessionToken` avec les informations d'identification d'utilisateur racine. Mettez plutôt en application nos [bonnes pratiques](best-practices-use-cases.md) pour créer des utilisateurs IAM avec les autorisations nécessaires. Utilisez ensuite ces utilisateurs IAM pour vos interactions quotidiennes avec AWS.

Les informations d'identification temporaires que vous obtenez lorsque vous appelez `GetSessionToken` présentent les fonctionnalités et limitations suivantes :
+ Vous pouvez utiliser les informations d'identification pour accéder au AWS Management Console en les transmettant au point de terminaison d'authentification unique de la fédération à l'`https://signin.aws.amazon.com/federation`adresse. Pour de plus amples informations, veuillez consulter [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).
+ Vous **ne pouvez pas** utiliser les informations d'identification pour appeler les opérations IAM ou d'API AWS STS . Vous **pouvez** les utiliser pour appeler des opérations d'API pour d'autres AWS services.

Comparez cette opération d'API et ses limitations et capacités avec les autres opérations d'API qui créent des informations d'identification de sécurité temporaires à [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md)

Pour plus d'informations sur l'accès aux API protégé par MFA à l'aide de `GetSessionToken`, consultez [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md).

# Désactivation des autorisations affectées aux informations d'identification de sécurité temporaires
<a name="id_credentials_temp_control-access_disable-perms"></a>

Les informations d'identification de sécurité temporaires sont valides jusqu'à la fin de leur délai d'expiration. Ces informations d'identification sont valides pendant la durée spécifiée, de 900 secondes (15 minutes) à un maximum de 129 600 secondes (36 heures). La durée de session par défaut est de 43 200 secondes (12 heures). Vous pouvez révoquer ces informations d’identification, mais vous devez également modifier les autorisations de l’utilisateur ou du rôle IAM afin d’empêcher l’utilisation d’informations d’identification compromises pour des activités de compte malveillantes. Les autorisations attribuées aux informations d'identification de sécurité temporaires sont évaluées chaque fois qu'elles sont utilisées pour faire une AWS demande. Une fois que vous avez supprimé toutes les autorisations des informations d'identification, les AWS demandes qui les utilisent échouent.

Les mises à jour des politiques peuvent prendre quelques minutes pour être mises en vigueur. Pour les sessions de rôle IAM, vous pouvez révoquer les informations d’identification de sécurité temporaires du rôle afin d’obliger tous les utilisateurs assumant le rôle à s’authentifier à nouveau et à demander de nouvelles informations d’identification. Pour plus d’informations, consultez [Révoquer les informations d’identification temporaires du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html).

Vous ne pouvez pas modifier les autorisations pour un Utilisateur racine d'un compte AWS. De même, vous ne pouvez pas modifier les autorisations des informations d'identification de sécurité temporaires créées en appelant `GetFederationToken` ou `GetSessionToken` lorsque vous êtes connecté comme utilisateur racine. C'est pour cette raison que nous vous recommandons de ne pas appeler `GetFederationToken` ou `GetSessionToken` en tant qu'utilisateur racine.

Pour les procédures relatives à la modification des autorisations d’un utilisateur IAM, consultez [Modification des autorisations pour un utilisateur IAM](id_users_change-permissions.md).

Pour les procédures relatives à la modification des autorisations d’un rôle IAM, consultez [Mettre à jour les autorisations pour un rôle](id_roles_update-role-permissions.md).

**Important**  
Vous ne pouvez pas modifier les rôles dans IAM qui ont été créés à partir des ensembles d’autorisations d’IAM Identity Center. Vous devez révoquer la session d’ensemble d’autorisations active pour un utilisateur dans IAM Identity Center. Pour plus d’informations, consultez [Révocation des sessions de rôle IAM actives créées par des ensembles d’autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) dans le *Guide de l’utilisateur IAM Identity Center*.

**Topics**
+ [Refus d’accès à toutes les sessions de rôle IAM associées à un rôle](#deny-access-to-all-sessions)
+ [Refus d’accès à une session de rôle IAM spécifique](#deny-access-to-specific-session)
+ [Refus d’accès aux sessions utilisant des informations d’identification de sécurité temporaires avec des clés de contexte de condition](#deny-access-to-specific-session-condition-key)
+ [Refus d’accès à un principal spécifique avec des politiques basées sur les ressources](#deny-access-with-resource-based)

## Refus d’accès à toutes les sessions de rôle IAM associées à un rôle
<a name="deny-access-to-all-sessions"></a>

Cette procédure refuse les autorisations à **toutes** les sessions de rôle IAM associées à un rôle. Utilisez cette méthode lorsque vous craignez un accès suspect des :


+ Principaux d'un autre compte utilisant l'accès intercompte
+ Identités des utilisateurs externes autorisés à accéder aux AWS ressources de votre compte
+ Utilisateurs ayant été authentifiés dans une application mobile ou Web à l’aide d’un fournisseur OIDC

Pour modifier ou supprimer les autorisations affectées aux informations d’identification de sécurité temporaires obtenues en appelant `AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, `GetFederationToken` ou `GetSessionToken`, vous pouvez modifier ou supprimer la politique basée sur l’identité qui définit les autorisations pour le rôle.

**Important**  
S'il existe une politique basée sur les ressources qui autorise l'accès au principal, vous devez également ajouter un refus explicite pour cette ressource. Consultez [Refus d’accès à un principal spécifique avec des politiques basées sur les ressources](#deny-access-with-resource-based) pour plus de détails.

**Pour refuser l’accès à **toutes** les sessions de rôle IAM associées à un rôle**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la.

1. Dans le panneau de navigation, choisissez **Rôles**.

1. Choisissez le nom du rôle à modifier. Vous pouvez utiliser la zone de recherche pour filtrer la liste.

1. Sélectionnez l’onglet **Autorisations**.

1. Sélectionnez la politique concernée à modifier. Avant de modifier une politique gérée par le client, consultez l’onglet **Entités attachées** pour éviter de perturber l’accès à d’autres identités auxquelles la même politique est attachée.

1. Choisissez l'onglet **JSON** et mettez à jour la politique pour refuser toutes les ressources et actions.
**Note**  
Ces autorisations sont les mêmes que celles de la politique AWS gérée [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). Vous pouvez associer cette politique AWS gérée à n'importe quel utilisateur ou rôle IAM auquel vous souhaitez refuser tout accès.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyAll",
               "Effect": "Deny",
               "Action": [
                   "*"
               ],
               "Resource": "*"
           }
       ]
   }
   ```

------

1. Sur la page **Vérification**, vérifiez le **Récapitulatif** de la politique, puis choisissez **Enregistrer les modifications** pour enregistrer votre travail.

Lorsque vous mettez à jour la politique, les modifications affectent les autorisations de toutes les informations d'identification de sécurité temporaires associées au rôle, y compris les informations d'identification émises avant que vous apportiez des changements à la politique d'autorisations du rôle. 

Après avoir mis à jour la politique, vous pouvez [révoquer les informations d'identification de sécurité temporaires du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) pour révoquer immédiatement toutes les autorisations relatives aux informations d'identification émises pour le rôle.

## Refus d’accès à une session de rôle IAM spécifique
<a name="deny-access-to-specific-session"></a>

Lorsque vous mettez à jour les rôles IAM à l’aide d’une politique de refus ou que vous supprimez complètement le rôle, tous les utilisateurs ayant accès au rôle sont perturbés. Vous pouvez refuser l’accès sans affecter les autorisations de toutes les autres sessions associées au rôle.

Le `Principal` peut se voir refuser des autorisations à l'aide des [clés de contexte de condition](#deny-access-to-specific-session-condition-key) ou des [politiques basées sur les ressources](#deny-access-with-resource-based).

**Astuce**  
Vous pouvez trouver les utilisateurs ARNs fédérés à l'aide AWS CloudTrail des journaux. Pour plus d'informations, consultez [Comment identifier facilement vos utilisateurs fédérés à l'aide AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/) de.

## Refus d’accès aux sessions utilisant des informations d’identification de sécurité temporaires avec des clés de contexte de condition
<a name="deny-access-to-specific-session-condition-key"></a>

Vous pouvez utiliser des clés de contexte de condition dans les politiques basées sur l’identité dans les situations où vous souhaitez refuser l’accès à des sessions d’informations d’identification de sécurité temporaires spécifiques sans affecter les autorisations de l’utilisateur ou du rôle IAM qui a créé les informations d’identification. Pour les rôles IAM, après avoir mis à jour la politique, vous pouvez également [révoquer les sessions d’informations d’identification temporaires du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) pour révoquer immédiatement toutes les informations d’identification émises.

Pour plus d'informations sur les clés de contexte de condition, veuillez consulter la rubrique [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md).

### lois : PrincipalArn
<a name="deny-access-condition-key-principalarn"></a>

Vous pouvez utiliser la clé de contexte de condition [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) dans une politique basée sur l’identité pour refuser l’accès à un principal spécifique en utilisant son Amazon Resource Name (ARN). Pour ce faire, spécifiez l'ARN de l'utilisateur, du rôle ou de la session utilisateur AWS STS fédérée IAM auxquels les informations d'identification de sécurité temporaires sont associées dans l'élément Condition d'une politique.

**Pour refuser l’accès à un principal spécifique par son ARN**

1. Dans le volet de navigation de la console IAM, choisissez **Utilisateurs** ou **Rôles**.

1. Choisissez le nom de l’utilisateur ou du rôle IAM à modifier. Vous pouvez utiliser la zone de recherche pour filtrer la liste.

1. Sélectionnez l’onglet **Autorisations**.

1. Sélectionnez la politique concernée à modifier. Avant de modifier une politique gérée par le client, consultez l’onglet **Entités attachées** pour éviter de perturber l’accès à d’autres identités auxquelles la même politique est attachée.

1. Choisissez l'onglet **JSON** et ajoutez une instruction de refus pour l'ARN principal, comme indiqué dans l'exemple suivant.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
           "ArnEquals": {
             "aws:PrincipalArn": [
               "arn:aws:iam::222222222222:role/ROLENAME",
               "arn:aws:iam::222222222222:user/USERNAME",
               "arn:aws:iam::222222222222:federated-user/USERNAME" 
             ]
           }
         }
       }
     ]
   }
   ```

------

1. Sur la page **Vérification**, vérifiez le **Récapitulatif** de la politique, puis choisissez **Enregistrer les modifications** pour enregistrer votre travail.

### lois : SourceIdentity
<a name="deny-access-condition-key-sourceidentity"></a>

Vous pouvez utiliser la clé de contexte de condition [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) dans une politique basée sur l’identité pour refuser l’accès à une identité source spécifique associée à une session de rôle IAM. Cela s'applique tant que la session de rôle a été émise en définissant le paramètre de `SourceIdentity` demande lorsque le principal a assumé un rôle à l'aide de AWS STS `assume-role` commandes\$1 CLI ou d'opérations d'API AWS STS `AssumeRole` \$1. Pour cela, vous spécifiez l’identité source à laquelle les informations d’identification de sécurité temporaires sont associées dans l’élément `Condition` d’une politique. 

Contrairement à la clé de contexte [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname), une fois l’identité source définie, la valeur ne peut plus être modifiée. Elle clé `aws:SourceIdentity` est présente dans le contexte de la requête pour toutes les actions entreprises par le rôle. L’identité source persiste dans les sessions de rôle suivantes lorsque vous utilisez les informations d’identification de la session pour assumer un autre rôle. Le fait d'endosser un rôle à partir d'un autre est appelé [chaînage des rôles](id_roles.md#iam-term-role-chaining).

La politique suivante montre un exemple de la manière dont vous pouvez refuser l’accès à des sessions d’informations d’identification de sécurité temporaires à l’aide d’une clé de contexte de condition `aws:SourceIdentity`. Si vous spécifiez l’identité source associée à une session de rôle, elle interdira les sessions de rôle avec l’identité source nommée sans affecter les autorisations du rôle qui a créé les informations d’identification. Dans cet exemple, l’identité source définie par le principal lors de l’émission de la session de rôle est `nikki_wolf@example.com`. Toute requête effectuée par une session de rôle avec l’identité source `nikki_wolf@example.com` sera refusée, car l’identité source est incluse dans la condition de politique et l’effet de politique est défini sur `Deny`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:SourceIdentity": [
            "nikki_wolf@example.com",
            "<source identity value>"
          ]
        }
      }
    }
  ]
}
```

------

### aws:userid
<a name="deny-access-condition-key-userid"></a>

Vous pouvez utiliser la clé de contexte de condition [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) dans une politique basée sur l’identité pour interdire l’accès à toutes les sessions d’informations d’identification de sécurité temporaires ou à des sessions spécifiques associées à l’utilisateur ou au rôle IAM. Pour ce faire, spécifiez l'identifiant unique (ID) de l'utilisateur, du rôle ou de la session utilisateur AWS STS fédérée IAM auxquels les informations d'identification de sécurité temporaires sont associées dans l'`Condition`élément d'une politique.

La politique suivante montre un exemple de la manière dont vous pouvez refuser l’accès à des sessions d’informations d’identification de sécurité temporaires à l’aide d’une clé de contexte de condition `aws:userid`.
+ `AIDAXUSER1` représente l’ID unique d’un utilisateur IAM. La spécification de l’identifiant unique d’un utilisateur IAM en tant que valeur de la clé de contexte `aws:userid` aura pour effet de refuser l’accès à l’utilisateur IAM. Cela inclut toutes les sessions d’informations d’identification de sécurité temporaires créées lors de l’appel de l’API `GetSessionToken`.
+ `AROAXROLE1:*` représente l’ID unique de toutes les sessions associées au rôle IAM. La spécification de l'ID unique d'un rôle IAM et d'un caractère générique (\$1) dans la partie caller-specified-role-session -name comme valeur de clé de contexte `aws:userid` empêchera toutes les sessions associées au rôle.
+ `AROAXROLE2:<caller-specified-role-session-name>` représente l’ID unique d’une session de rôle assumé. Dans la partie caller-specified-role-session -name de l'ID unique du rôle assumé, vous pouvez spécifier un rôle, un nom de session ou un caractère générique si l' StringLike opérateur de condition est utilisé. Si vous spécifiez le nom de la session de rôle, cela refusera la session de rôle nommée sans affecter les autorisations du rôle qui a créé les informations d'identification. Si vous spécifiez un caractère générique pour le nom de session du rôle, toutes les sessions associées au rôle seront refusées.
**Note**  
Le nom de session de rôle caller-specified, qui fait partie de l’identifiant unique d’une session assumed-role, peut changer pendant le chaînage des rôles. Le chaînage des rôles se produit lorsqu’un rôle assume un autre rôle. Le nom de session du rôle est défini à l'aide du paramètre de `RoleSessionName` requête lorsque le principal assume un rôle à l'aide de l'opération AWS STS `AssumeRole` API.
+ `account-id:<federated-user-caller-specified-name>`représente l'ID unique d'une session utilisateur AWS STS fédérée. Un utilisateur IAM crée cette session en appelant l’API `GetFederationToken`. La spécification de l’ID unique d’une session d’utilisateur fédéré AWS STS a pour effet de refuser la session fédérée nommée sans affecter les autorisations de l’utilisateur IAM qui a créé les informations d’identification.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:userId": [
            "AIDAXUSER1",
            "AROAXROLE1:*",
            "AROAXROLE2:<caller-specified-role-session-name>",
            "123456789012:<federated-user-caller-specified-name>"
          ]
        }
      }
    }
  ]
}
```

------

Pour des exemples spécifiques de valeurs de clé de principal, veuillez consulter la rubrique [Valeurs de la clé du principal](reference_policies_variables.md#principaltable). Pour plus d’informations sur les identifiants uniques IAM et sur la manière de les obtenir, consultez [Identifiants uniques](reference_identifiers.md#identifiers-unique-ids).

## Refus d’accès à un principal spécifique avec des politiques basées sur les ressources
<a name="deny-access-with-resource-based"></a>

Pour restreindre l’accès à un principal spécifique à l’aide d’une politique basée sur les ressources, vous pouvez utiliser des clés contextuelles de condition [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) ou [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) dans l’élément `Condition`. Une politique basée sur les ressources est une politique d’autorisation attachée à une ressource et qui contrôle qui peut accéder à la ressource et quelles actions il peut effectuer sur celle-ci. 

Lorsque vous utilisez la clé de `aws:PrincipalARN` contexte, spécifiez l'ARN de l'utilisateur, du rôle ou de la session utilisateur AWS STS fédérée IAM associé aux informations d'identification de sécurité temporaires dans l'élément Condition d'une politique. L’exemple de politique suivant montre comment utiliser la clé de contexte `aws:PrincipalARN` dans une politique basée sur les ressources :

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Principal": "*",
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {
      "ArnEquals": {
        "aws:PrincipalArn": [
          "arn:aws:iam::222222222222:role/ROLENAME",
          "arn:aws:iam::222222222222:user/USERNAME",
          "arn:aws:sts::222222222222:federated-user/USERNAME"
        ]
      }
    }
  }
}
```

------

Lorsque vous utilisez la clé de contexte `aws:SourceIdentity`, spécifiez la valeur d’identité source associée aux informations de sécurité temporaires du rôle dans l’élément `Condition` d’une politique. Cela s'applique tant que la session de rôle a été émise en définissant le paramètre de `SourceIdentity` demande lorsque le principal a assumé un rôle à l'aide de AWS STS `assume-role` commandes\$1 CLI ou d'opérations d'API AWS STS `AssumeRole` \$1. L’exemple suivant montre comment utiliser la clé de contexte `aws:SourceIdentity` dans une politique basée sur une ressource :

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Principal": "*",
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {
      "StringLike": {
        "aws:SourceIdentity": [
          "nikki_wolf@example.com",
          "<source identity value>"
        ]
      }
    }
  }
}
```

------

Si vous mettez uniquement à jour la politique basée sur l’identité d’un principal, celui-ci peut toujours effectuer les actions autorisées dans la politique basée sur les ressources, sauf lorsque ces actions sont explicitement refusées dans la politique basée sur l’identité.

**Pour refuser l’accès à un principal spécifique dans une politique basée sur les ressources**

1. Reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) pour voir si le service prend en charge les politiques basées sur les ressources.

1. Connectez-vous à la console du service AWS Management Console et ouvrez-la. Chaque service dispose d'un emplacement différent dans la console pour associer des politiques.

1. Modifiez la politique basée sur une ressource. Ajoutez une instruction de politique de refus pour spécifier les informations d’identification de l’identifiant :

   1. Dans l’élément `Principal`, saisissez le caractère générique (\$1). Le principal sera restreint dans l’élément `Condition`.

   1. Dans l’élément `Effect`, saisissez « Deny ».

   1. Dans `Action`, saisissez l'espace de noms du service et le nom de l'action à refuser. Pour refuser toutes les actions, utilisez le caractère générique (\$1). Par exemple : `"s3:*"`.

   1. Dans l’élément `Resource`, saisissez l’ARN de la ressource cible. Par exemple : `"arn:aws:s3:::amzn-s3-demo-bucket"`.

   1. Dans l’élément `Condition`, spécifiez la clé de contexte `aws:PrincipalARN` ou `aws:SourceIdentity`.

      Si vous utilisez la clé de contexte `aws:PrincipalARN`, saisissez l’ARN du principal pour lequel refuser l’accès.

      Si vous utilisez la clé de contexte `aws:SourceIdentity`, saisissez la valeur d’identité source définie dans la session de rôle pour laquelle refuser l’accès.

1. Enregistrez votre travail.

# Octroi d'autorisations pour créer des informations d'identification de sécurité temporaires
<a name="id_credentials_temp_control-access_enable-create"></a>

Par défaut, les utilisateurs IAM n’ont pas l’autorisation de créer des informations d’identification de sécurité temporaires pour des sessions d’utilisateurs fédérés et les rôles AWS STS . Vous devez utiliser une politique pour fournir ces autorisations à vos utilisateurs. Bien que vous puissiez accorder des autorisations directement à un utilisateur, nous vous recommandons vivement d'accorder des autorisations à un groupe. Cela facilite la gestion des autorisations. Lorsqu'un utilisateur n'a plus besoin d'effectuer les tâches associées aux autorisations, il vous suffit de le supprimer du groupe. Si un autre utilisateur doit effectuer cette tâche, ajoutez-le au groupe pour lui accorder les autorisations.

Pour accorder à un groupe IAM l’autorisation de créer des informations d’identification de sécurité temporaires pour des sessions d’utilisateurs fédérés ou des rôles AWS STS , vous attachez une politique qui accorde un ou plusieurs des privilèges suivants :
+ Pour que les principaux fédérés OIDC et SAML puissent accéder à un rôle IAM, accordez l'accès à. AWS STS `AssumeRole`
+ <a name="para_gsy_hxg_1t"></a>Pour les utilisateurs AWS STS fédérés qui n'ont pas besoin de rôle, accordez l'accès à AWS STS `GetFederationToken`.

 Pour plus d'informations sur les différences entre les opérations d'API `AssumeRole` et `GetFederationToken`, consultez [Demande d’identifiants de sécurité temporaires](id_credentials_temp_request.md).

Les utilisateurs IAM peuvent également appeler [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) pour créer des informations d'identification de sécurité temporaires. Aucune autorisation n'est requise pour qu'un utilisateur puisse appeler `GetSessionToken`. Le but principal de cette opération est d'authentifier l'utilisateur à l'aide de l'authentification MFA. Vous ne pouvez pas utiliser les politiques pour contrôler l'authentification. Cela signifie que vous ne pouvez pas empêcher les utilisateurs IAM d'appeler `GetSessionToken` pour créer des informations d'identification temporaires.

**Example Exemple de politique qui accorde l'autorisation d'endosser un rôle**  
L'exemple de politique suivant accorde l'autorisation d'appeler `AssumeRole` pour le `UpdateApp` rôle dans Compte AWS `123123123123`. Quand `AssumeRole` est utilisé, l'utilisateur (ou l'application) qui crée les informations d'identification de sécurité pour le compte d'un utilisateur fédéré ne peut déléguer aucune autorisation non spécifiée dans la politique d'autorisation de rôle.     
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
  }]
}
```

**Example Exemple de politique qui accorde l'autorisation de créer des informations d'identification de sécurité temporaires pour un utilisateur fédéré**  
L'exemple de politique suivant donne l'autorisations d'accéder à `GetFederationToken`.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:GetFederationToken",
    "Resource": "*"
  }]
}
```

**Important**  
Lorsque vous accordez à un utilisateur IAM l’autorisation de créer des informations d’identification de sécurité temporaires pour des utilisateurs fédérés AWS STS avec `GetFederationToken`, sachez que cela lui autorise à déléguer ses propres autorisations. Pour plus d'informations sur la délégation d'autorisations entre les utilisateurs IAM et consultez Comptes AWS. [Exemples de politiques pour la délégation d'accès](id_roles_create_policy-examples.md) Pour plus d'informations sur le contrôle des autorisations dans les informations d'identification de sécurité temporaires, consultez [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md). 

**Example Exemple de politique qui accorde à un utilisateur une autorisation limitée de créer des informations d'identification de sécurité temporaires pour des utilisateurs fédérés**  
Lorsque vous laissez un utilisateur IAM appeler `GetFederationToken`, il s'agit d'une bonne pratique pour limiter les autorisations que l'utilisateur IAM peut déléguer. *Par exemple, la politique suivante indique comment autoriser un utilisateur IAM à créer des informations d'identification de sécurité temporaires uniquement pour les utilisateurs AWS STS fédérés dont le nom commence par Manager.*    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:GetFederationToken",
    "Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
  }]
}
```

# Octroi d’autorisations pour l’utilisation de sessions de console à identité renforcée
<a name="id_credentials_temp_control-access_sts-setcontext"></a>

Les sessions de console à identité améliorée permettent AWS IAM Identity Center d'inclure l'utilisateur et IDs la session dans les sessions de AWS console des utilisateurs lorsqu'ils se connectent. Par exemple, Amazon Q Developer Pro utilise des sessions de console à identité renforcée pour personnaliser l’expérience de service. Pour plus d’informations sur les sessions de console à identité renforcée, consultez la section [Activation des sessions de console à identité renforcée](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. Pour plus d’informations sur la configuration d’Amazon Q Developer, consultez la section [Configuration d’Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) dans le *Guide de l’utilisateur Amazon Q Developer*.

Pour qu’un utilisateur puisse disposer de sessions de console à identité renforcée, vous devez utiliser une politique basée sur l’identité pour accorder au principal IAM l’autorisation `sts:SetContext` pour la ressource qui représente sa propre session de console. 

**Important**  
Par défaut, les utilisateurs n’ont pas l’autorisation de définir le contexte de leurs sessions de console à identité renforcée. Pour ce faire, vous devez accorder l’autorisation `sts:SetContext` au principal IAM dans une politique basée sur l’identité, comme indiqué dans l’exemple de politique ci-dessous.

L'exemple de politique basée sur l'identité suivant accorde l'`sts:SetContext`autorisation à un principal IAM, ce qui permet au principal de définir un contexte de session de console à identité améliorée pour ses propres sessions de console. AWS La ressource de politique représente la AWS session de l'appelant. `arn:aws:sts::account-id:self` Le segment ARN `account-id` peut être remplacé par un caractère générique `*` dans les cas où la même politique d’autorisation est déployée sur plusieurs comptes, par exemple lorsque cette politique est déployée à l’aide des ensembles d’autorisations d’IAM Identity Center.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:SetContext",
            "Resource": "arn:aws:sts::111122223333:self"
        }
    ]
}
```

------

# Gérez AWS STS dans un Région AWS
<a name="id_credentials_temp_enable-regions"></a>

Un point de terminaison régional est l'URL du point d'entrée d'un service AWS Web dans une région donnée. AWS recommande d'utiliser des points de terminaison régionaux AWS Security Token Service (AWS STS) au lieu du point de terminaison global pour réduire la latence, renforcer la redondance et augmenter la validité des jetons de session. Bien que le point de AWS STS terminaison global (ancien) soit hautement disponible, il `https://sts.amazonaws.com` est hébergé dans une seule AWS région, l'est des États-Unis (Virginie du Nord), et comme les autres terminaux, il ne permet pas de basculement automatique vers les points de terminaison situés dans d'autres régions.
+ **Réduisez la latence** : en passant vos AWS STS appels vers un point de terminaison géographiquement plus proche de vos services et applications, vous pouvez accéder à AWS STS des services avec une latence plus faible et de meilleurs temps de réponse.
+ **Intégrer de la redondance :** vous pouvez limiter les effets d'une défaillance au sein d'une charge de travail à un nombre limité de composants avec une portée prévisible de maîtrise des impacts. L'utilisation de AWS STS points de terminaison régionaux vous permet d'aligner la portée de vos composants sur celle de vos jetons de session. Pour plus d'informations sur ce pilier de fiabilité, consultez [Utilisation de l'isolation des défaillances pour protéger votre charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) dans le *cadre AWS Well-Architected*.
+ **Augmenter la validité des jetons** de session — Les jetons de session provenant des AWS STS points de terminaison régionaux sont valides dans tous les Régions AWS cas. Les jetons de session provenant du point de terminaison STS global ne sont valides Régions AWS que s'ils sont activés par défaut. Si vous avez l'intention d'activer une nouvelle région pour votre compte, vous pouvez utiliser des jetons de session provenant des AWS STS points de terminaison régionaux. Si vous choisissez d'utiliser le point de terminaison global, vous devez modifier la compatibilité régionale des jetons de AWS STS session pour le point de terminaison global. Cela garantit que les jetons sont valides dans tous les cas Régions AWS.

Pour obtenir la liste des AWS STS régions et de leurs points de terminaison, voir[AWS STS Régions et points de terminaison](id_credentials_temp_region-endpoints.md).

**Note**  
AWS a apporté des modifications au AWS Security Token Service point de terminaison global (`https://sts.amazonaws.com`) dans les régions [activées par défaut](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) afin d'améliorer sa résilience et ses performances.AWS STS AWS STS les demandes adressées au point de terminaison global sont automatiquement traitées au même Région AWS titre que vos charges de travail. Ces modifications ne seront pas déployées vers des régions d’adhésion. Nous vous recommandons d'utiliser les points de terminaison AWS STS régionaux appropriés. Pour de plus amples informations, veuillez consulter [AWS STS modifications du point de terminaison global](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes).

**Topics**
+ [Activation et désactivation AWS STS dans un Région AWS](#sts-regions-activate-deactivate)
+ [Écrire du code pour utiliser AWS STS Regions](#id_credentials_temp_enable-regions_writing_code)
+ [Gestion des jetons de session de point de terminaison global](#sts-regions-manage-tokens)

## Activation et désactivation AWS STS dans un Région AWS
<a name="sts-regions-activate-deactivate"></a>

Lorsque vous activez des AWS STS points de terminaison pour une région, vous AWS STS pouvez délivrer des informations d'identification temporaires aux utilisateurs et aux rôles de votre compte qui font une AWS STS demande. Ces informations d'identification peuvent ensuite être utilisées dans n'importe quelle région activée par défaut ou activée manuellement. Pour les régions activées par défaut, vous devez activer le point de AWS STS terminaison régional dans le compte sur lequel les informations d'identification temporaires sont générées. Peu importe si un utilisateur est connecté au même compte ou à un compte différent lorsqu'il fait la demande. Lorsque vous demandez des informations d'identification temporaires pour un rôle dans une autre région à Compte AWS l'aide d'une région activée manuellement, le compte cible (le compte contenant le rôle) doit activer cette région pour les AWS STS opérations. Cela garantit que les informations d’identification de sécurité temporaires peuvent être générées correctement.

Par exemple, un utilisateur du compte A veut envoyer une demande d’API `sts:AssumeRole` au [point de terminaison AWS STS régional ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com`. La demande concerne les informations d’identification temporaires du rôle nommé `Developer` dans le compte B. Étant donné qu’il s’agit d’une demande de création d’informations d’identification pour une entité du compte B, la région `ap-southeast-3` doit être activée pour le compte B. Les utilisateurs du compte A (ou de tout autre compte) peuvent appeler le point de terminaison `ap-southeast-3` AWS STS pour demander les informations d'identification pour le compte B, que la région soit activée ou non dans leurs comptes. Pour en savoir plus, consultez la section [Activer ou désactiver Régions AWS dans votre compte](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html).

**Note**  
Les régions actives sont disponibles pour chaque personne qui utilise des informations d'identification temporaires de ce compte. Pour contrôler les utilisateurs ou rôles IAM qui peuvent accéder à la région, utilisez la clé de condition `aws:RequestedRegion` dans vos politiques d'autorisations.

**Pour activer ou désactiver AWS STS dans une région activée par défaut (console)**

1. Connectez-vous en tant qu'utilisateur root ou utilisateur IAM avec les autorisations pour effectuer des tâches d'administration d'IAM.

1. Ouvrez la [console IAM](https://console.aws.amazon.com/iam/home?#home), puis dans le panneau de navigation, sélectionnez [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings) (Paramètres du compte).

1. Dans la section **Security Token Service (STS)** **Points de terminaison**, recherchez la région que vous souhaitez configurer, puis choisissez **Active** ou **Inactive** dans la colonne d’**état STS**.

1. Dans la boîte de dialogue qui s'ouvre, choisissez **Activate** ou **Deactivate** (Activer ou Désactiver).

Pour les régions qui doivent être activées, nous les activons AWS STS automatiquement lorsque vous activez la région. Une fois que vous avez activé une région, elle AWS STS est toujours active pour cette région et vous ne pouvez pas la désactiver. Pour en savoir plus sur l'activation des régions désactivées par défaut, consultez la section [Spécifier les régions que Régions AWS votre compte peut utiliser](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) dans le *Guide de Gestion de compte AWS référence*.

## Écrire du code pour utiliser AWS STS Regions
<a name="id_credentials_temp_enable-regions_writing_code"></a>

Après avoir activé une région, vous pouvez diriger les appels d' AWS STS API vers cette région. L’extrait de code Java suivant illustre comment configurer un objet `AWSSecurityTokenService` pour effectuer des requêtes vers la région Europe (Milan) (eu-south-1).

```
EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1");
AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard()
.withCredentials(credentials)
.withEndpointConfiguration(regionEndpointConfig)
.build();
```

AWS STS vous recommande de passer des appels vers un point de terminaison régional. Pour savoir comment activer manuellement une région, consultez la section [Spécification des Régions AWS que votre compte peut utiliser](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) dans le *Guide de référence Gestion de compte AWS *.

Dans l'exemple, la première ligne instancie un objet `EndpointConfiguration` appelé `regionEndpointConfig`, en transmettant l'URL du point de terminaison et la Région AWS comme paramètres.

Pour savoir comment définir des points de terminaison AWS STS régionaux à l'aide d'une variable d'environnement pour AWS SDKs, consultez la section [Points de terminaison AWS STS régionalisés](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) dans le guide de référence *des outils AWS SDKs et*.

Pour toutes les autres combinaisons de langage et d'environnement de programmation, reportez-vous à la [documentation du kit SDK approprié](https://aws.amazon.com/tools/).

## Gestion des jetons de session de point de terminaison global
<a name="sts-regions-manage-tokens"></a>

La plupart Régions AWS sont activées pour toutes les opérations Services AWS par défaut. Ces régions sont automatiquement activées pour être utilisées avec AWS STS. Certaines régions, telles que l'Asie-Pacifique (Hong Kong), doivent être activées manuellement. Pour en savoir plus sur l’activation et la désactivation des Régions AWS, consultez la section [Spécification des Régions AWS que votre compte peut utiliser](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) dans le *Guide de référence Gestion de compte AWS *. Lorsque vous activez ces AWS régions, elles sont automatiquement activées pour être utilisées avec AWS STS. Vous ne pouvez pas activer le AWS STS point de terminaison pour une région désactivée. Les jetons de session valides dans tous les domaines Régions AWS incluent plus de caractères que les jetons valides dans les régions activées par défaut. La modification de ce paramètre peut avoir un impact sur les systèmes existants où vous stockez temporairement les jetons.

Vous pouvez modifier ce paramètre à l'aide de l' AWS API AWS Management Console AWS CLI, ou.

**Pour modifier la compatibilité régionale des jetons de session pour le point de terminaison global (console)**

1. Connectez-vous en tant qu'utilisateur root ou utilisateur IAM avec les autorisations pour effectuer des tâches d'administration d'IAM. Pour modifier la compatibilité des jetons de session, vous devez posséder une politique qui autorise l'action `iam:SetSecurityTokenServicePreferences`.

1. Ouvrez la [console IAM](https://console.aws.amazon.com/iam/home?#home). Dans le panneau de navigation, choisissez **Paramètres du compte**.

1. Dans la section **Security Token Service (STS)**, **Jetons de session provenant des points de terminaison STS**. Le **point de terminaison global** indique `Valid only in Régions AWS enabled by default`. Choisissez **Change (Modifier)**.

1. Dans la boîte de dialogue **Modifier la compatibilité des régions**, sélectionnez **Tout Régions AWS**. Ensuite, choisissez **Enregistrer les modifications**.
**Note**  
Les jetons de session valides dans tous les domaines Région AWS incluent plus de caractères que les jetons valides dans les régions activées par défaut. La modification de ce paramètre peut avoir un impact sur les systèmes existants où vous stockez temporairement les jetons.

**Pour modifier la compatibilité régionale des jetons de session pour le point de terminaison global (AWS CLI)**  
Définissez la version du jeton de session. Les jetons de version 1 ne sont valides Régions AWS que s'ils sont disponibles par défaut. Ces jetons ne fonctionnent pas dans les régions activées manuellement, par exemple, Asie-Pacifique (Hong Kong). Les jetons de la version 2 sont valides dans toutes les régions. Toutefois, les jetons de version 2 incluent plus de caractères et peuvent avoir un impact sur les systèmes où vous stockez temporairement les jetons.
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html)

**Pour modifier la compatibilité régionale des jetons de session pour le point de terminaison global (AWS API)**  
Définissez la version du jeton de session. Les jetons de version 1 ne sont valides Régions AWS que s'ils sont disponibles par défaut. Ces jetons ne fonctionnent pas dans les régions activées manuellement, par exemple, Asie-Pacifique (Hong Kong). Les jetons de la version 2 sont valides dans toutes les régions. Toutefois, les jetons de version 2 incluent plus de caractères et peuvent avoir un impact sur les systèmes où vous stockez temporairement les jetons.
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) 

# AWS STS Régions et points de terminaison
<a name="id_credentials_temp_region-endpoints"></a>

**Note**  
AWS a apporté des modifications au AWS Security Token Service point de terminaison global (`https://sts.amazonaws.com`) dans les régions [activées par défaut](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) afin d'améliorer sa résilience et ses performances.AWS STS AWS STS les demandes adressées au point de terminaison global sont automatiquement traitées au même Région AWS titre que vos charges de travail. Ces modifications ne seront pas déployées vers des régions d’adhésion. Nous vous recommandons d'utiliser les points de terminaison AWS STS régionaux appropriés. Pour de plus amples informations, veuillez consulter [AWS STS modifications du point de terminaison global](#reference_sts_global_endpoint_changes).

Le tableau suivant répertorie les régions et leurs points de terminaison. Il indique les régions activées par défaut et celles que vous pouvez activer ou désactiver.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)

¹Vous devez [activer la région](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) pour l'utiliser. Cela active automatiquement AWS STS. Vous ne pouvez pas activer ou désactiver manuellement AWS STS dans ces régions.

²Pour l'utiliser AWS en Chine, vous avez besoin d'un compte et d'informations d'identification spécifiques AWS à la Chine.

## AWS STS modifications du point de terminaison global
<a name="reference_sts_global_endpoint_changes"></a>

AWS a apporté des modifications au AWS Security Token Service point de terminaison global (`https://sts.amazonaws.com`) dans les régions [activées par défaut](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) afin d'améliorer sa résilience et ses performances.AWS STS Auparavant, toutes les demandes adressées au point de terminaison AWS STS mondial étaient traitées par un seul terminal Région AWS, l'est des États-Unis (Virginie du Nord). Désormais, dans les régions [activées par défaut](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html), les demandes adressées au point de terminaison AWS STS mondial sont automatiquement traitées dans la même région d'où provient la demande, plutôt que dans la région de l'est des États-Unis (Virginie du Nord). Ces modifications ne seront pas déployées vers des régions d’adhésion.

Avec cette modification, votre demande AWS STS sera traitée en fonction de la région d'origine et du résolveur DNS utilisés. Les demandes adressées au point de terminaison AWS STS mondial sont traitées dans la même région que votre charge de travail AWS déployée si la demande DNS pour le point de terminaison AWS STS mondial est traitée par le serveur Amazon DNS dans les régions activées par défaut. Les demandes adressées au point de terminaison global AWS STS continueront d’être traitées dans la région USA Est (Virginie du Nord) si votre demande provient de régions d’adhésion ou si votre demande a été résolue à l’aide d’un résolveur DNS autre que le serveur DNS Amazon. Pour plus d’informations sur Amazon DNS, veuillez consulter [Serveur Amazon DNS](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.

Le tableau suivant montre comment les demandes adressées au point de terminaison AWS STS global sont acheminées en fonction de votre fournisseur DNS.


| Résolveur DNS | Les demandes adressées au point de terminaison AWS STS global sont-elles acheminées vers le point de terminaison local ? Région AWS | 
| --- | --- | 
|  Résolveur DNS Amazon dans un VPC Amazon dans une région activée par défaut  |  Oui  | 
|  Résolveur DNS Amazon dans un VPC Amazon dans une région d’adhésion  |  Non, la demande sera transmise à la région USA Est (Virginie du Nord)  | 
|  Résolveur DNS fourni par votre FAI, un fournisseur DNS public ou tout autre fournisseur DNS  |  Non, la demande sera transmise à la région USA Est (Virginie du Nord)  | 

Pour garantir une perturbation minimale de vos processus existants, AWS a mis en œuvre les mesures suivantes :
+ AWS CloudTrail les journaux des demandes adressées au point de terminaison AWS STS mondial sont envoyés à la région USA Est (Virginie du Nord). CloudTrail les journaux des demandes traitées par les points de terminaison AWS STS régionaux continueront d'être enregistrés dans CloudTrail leur région respective.
+ CloudTrail les journaux des opérations effectuées par le point de terminaison AWS STS global et les points de terminaison régionaux comportent des champs supplémentaires `endpointType` et `awsServingRegion` indiquent quel point de terminaison et quelle région ont répondu à la demande. Pour des exemples de CloudTrail journaux, voir[Exemple AWS STS d'événement d'API utilisant le point de terminaison global dans le fichier CloudTrail journal](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint).
+ Les demandes adressées au point de terminaison AWS STS global ont une valeur égale à `us-east-1` pour la clé de `aws:RequestedRegion` condition, quelle que soit la région ayant répondu à la demande.
+ Les demandes traitées par le point de terminaison AWS STS global ne partagent pas de quota de demandes par seconde avec les AWS STS points de terminaison régionaux.

Si vous avez des charges de travail dans une région optionnelle et que vous utilisez toujours le point de terminaison AWS STS mondial, nous vous recommandons de migrer vers des points de terminaison AWS STS régionaux pour améliorer la résilience et les performances. Pour plus d'informations sur la configuration des points de AWS STS terminaison régionaux, consultez la section Points de [terminaison AWS STS régionaux](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) dans le guide de *référence des outils AWS SDKs et*.

## AWS CloudTrail et points de terminaison régionaux
<a name="sts-regions-cloudtrail"></a>

Les appels vers les points de terminaison régionaux et globaux sont enregistrés dans le champ `tlsDetails` dans AWS CloudTrail. Les appels vers les points de terminaison régionaux`us-east-2.amazonaws.com`, tels que, sont connectés CloudTrail à la région appropriée. Les appels vers le point de terminaison global, `sts.amazonaws.com`, sont consignés en tant qu'appels à un service international. Les événements relatifs aux AWS STS points de terminaison globaux sont enregistrés dans us-east-1.

**Note**  
 `tlsDetails` peut uniquement être consulté pour les services qui prennent en charge ce champ. Voir les [informations sur les services compatibles avec le protocole TLS CloudTrail dans](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html) le guide de l'*AWS CloudTrail utilisateur*  
Pour de plus amples informations, veuillez consulter [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md).

# Permettre à un courtier d'identité personnalisé d'accéder à la AWS console
<a name="id_roles_providers_enable-console-custom-url"></a>

Vous pouvez écrire et exécuter du code afin de créer une URL qui permet aux utilisateurs qui se connectent au réseau de votre organisation d'accéder en toute sécurité à AWS Management Console. L'URL inclut un jeton de connexion que vous obtenez AWS et qui authentifie l'utilisateur. AWS La session de console obtenue peut inclure un `AccessKeyId` distinct en raison de la fédération. Pour suivre l'utilisation des clés d'accès pour la connexion à la fédération par le biais d' CloudTrail événements connexes, consultez la section Événements [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md) de [AWS Management Console connexion](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html). 

**Note**  
Si votre organisation utilise un fournisseur d'identité (IdP) qui est compatible avec SAML, vous pouvez configurer l'accès à la console sans écrire de code. Cela fonctionne avec des fournisseurs tels que Microsoft Active Directory Federation Services ou Shibboleth (open source). Pour en savoir plus, consultez [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md). 

Pour permettre aux utilisateurs de votre organisation d'accéder au AWS Management Console, vous pouvez créer un *courtier d'identité* personnalisé qui exécute les étapes suivantes :

1. Vérifier que l'utilisateur est authentifié par votre système d'identité local.

1. Appelez les opérations AWS Security Token Service (AWS STS) [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)(recommandé) ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API pour obtenir des informations d'identification de sécurité temporaires pour l'utilisateur. Pour connaître les différentes méthodes que vous pouvez utiliser pour endosser un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md). Pour savoir comment transmettre des balises de session facultatives lorsque vous obtenez vos informations d'identification de sécurité, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).
   + Si vous utilisez l'une des opérations d'API `AssumeRole*` pour obtenir les informations d'identification de sécurité temporaires pour un rôle, vous pouvez inclure le paramètre `DurationSeconds` dans votre appel. Ce paramètre spécifie la durée de la session de votre rôle, entre 900 secondes (15 minutes) et la durée de session maximale pour le rôle. Lorsque vous utilisez `DurationSeconds` dans une opération `AssumeRole*`, vous devez l'appeler en tant qu'utilisateur IAM avec des informations d'identification à long terme. Sinon, l'appel au point de terminaison de fédération de l'étape 3 échoue. Pour savoir comment afficher ou modifier la valeur maximale pour un rôle, consultez [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration).
   + Si vous utilisez l'opération d'API `GetFederationToken` pour obtenir les informations d'identification, vous pouvez inclure le paramètre `DurationSeconds` dans votre appel. Ce paramètre spécifie la durée de votre session de rôle. La valeur peut être comprise entre 900 secondes (15 minutes) et 129 600 secondes (36 heures). Vous ne pouvez effectuer cet appel d'API qu'en utilisant les informations d'identification de AWS sécurité à long terme d'un utilisateur IAM. Vous pouvez également effectuer ces appels à l'aide Utilisateur racine d'un compte AWS d'informations d'identification, mais nous ne le recommandons pas. Si vous effectuez cet appel en tant qu'utilisateur racine, la session par défaut dure une heure. Ou vous pouvez spécifier une session de 900 secondes (15 minutes) à 3 600 secondes (une heure). 

1. Appelez le point de terminaison de la AWS fédération et fournissez les informations d'identification de sécurité temporaires pour demander un jeton de connexion.

1. Créer une URL incluant le jeton pour la console :
   + Si vous utilisez l'une des opérations d'API `AssumeRole*` dans votre URL, vous pouvez inclure le paramètre HTTP `SessionDuration`. Ce paramètre spécifie la durée de la session de la console, de 900 secondes (15 minutes) à 43 200 secondes (12 heures).
   + Si vous utilisez l'opération d'API `GetFederationToken` dans votre URL, vous pouvez inclure le paramètre `DurationSeconds`. Ce paramètre spécifie la durée de la session de console fédérée. La valeur peut être comprise entre 900 secondes (15 minutes) et 129 600 secondes (36 heures). 
**Note**  
Votre `SessionDuration` ne peut être supérieure ou égale à la durée maximale de la session définie pour le rôle que vous endossez. Par exemple, vous fixez à cinq heures la durée maximale de la session pour le rôle que vous souhaitez endosser. Votre paramètre `SessionDuration` peut être 16 524 secondes ou 4 heures et 59 secondes.
N’utilisez pas le paramètre HTTP `SessionDuration` lorsque vous obtenez des informations d’identification temporaires avec `GetFederationToken`. L’opération échouera.
L'utilisation des informations d'identification pour qu'un rôle endosse un rôle différent est appelée [*chaînes de rôles*](id_roles.md#iam-term-role-chaining). Lorsque vous utilisez la création de chaînes de rôles, vos nouvelles informations d'identification sont limitées à une durée maximale d'une heure. Lorsque vous utilisez des rôles pour [accorder des autorisations aux applications qui s'exécutent sur des instances EC2](id_roles_use_switch-role-ec2.md), ces applications ne sont pas soumises à cette limitation.
N’utilisez pas le paramètre HTTP `SessionDuration` lorsque vous obtenez des informations d’identification temporaires via le chaînage de rôles. L’opération échouera.

1. Donner l'URL à l'utilisateur ou appeler l'URL pour le compte de l'utilisateur.

L'URL fournie par le point de terminaison de fédération est valide pendant 15 minutes à compter de sa création. Cette durée est différente de celle (en secondes) de la session des informations d'identification de sécurité temporaires associées à l'URL. Ces informations d'identification sont valides pendant la durée spécifiée lors de leur création et ce, à compter du moment où elles sont créées.

**Important**  
L'URL donne accès à vos AWS ressources via les autorisations AWS Management Console si vous avez activé les autorisations dans les informations d'identification de sécurité temporaires associées. Pour cette raison, vous devez considérer l'URL comme un secret. Nous vous recommandons de retourner l'URL via une redirection sécurisée, par exemple, en utilisant un code de statut de réponse HTTP 302 via une connexion SSL. Pour plus d'informations sur le code de statut de réponse HTTP 302, consultez [RFC 2616, section 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3).

Pour effectuer ces tâches, vous pouvez utiliser l'[API Query HTTPS pour Gestion des identités et des accès AWS (IAM)](https://docs.aws.amazon.com/IAM/latest/APIReference/) et [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/). Vous pouvez également utiliser des langages de programmation tels que Java, Ruby ou C\$1, avec le [kit SDK AWS](https://aws.amazon.com/tools/) approprié. Chacune de ces méthodes est décrite dans les rubriques suivantes.

**Topics**
+ [Exemple de code utilisant les opérations d'API Query IAM](#STSConsoleLink_manual)
+ [Exemple de code utilisant Python](#STSConsoleLink_programPython)
+ [Exemple de code utilisant Java](#STSConsoleLink_programJava)
+ [Exemple montrant comment créer l'URL (Ruby)](#STSConsoleLink_programRuby)

## Exemple de code utilisant les opérations d'API Query IAM
<a name="STSConsoleLink_manual"></a>

Vous pouvez créer une URL qui accorde aux rôles et aux principaux fédérés un accès direct à AWS Management Console. Cette tâche utilise les API de requête IAM et AWS STS HTTPS. Pour de plus amples informations sur les demandes de requête, veuillez consulter [Envoi de demandes de requête](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html).

**Note**  
La procédure suivante contient des exemples de chaînes de texte. Pour faciliter la lecture, des sauts de ligne ont été ajoutés aux exemples les plus longs. Lorsque vous créez ces chaînes pour votre propre utilisation, il convient d'omettre les sauts de ligne.

**Pour donner aux rôles et aux principaux fédérés l'accès à vos ressources depuis AWS Management Console**

1. Authentifiez l'utilisateur dans votre système d'identité et d'autorisation.

1. Obtenez des informations d'identification de sécurité temporaires pour l'utilisateur. Les informations d'identification temporaires incluent un ID de clé d'accès, une clé d'accès secrète et un jeton (token) de session. Pour plus d'informations sur la création d'informations d'identification temporaires, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md).

   Pour obtenir des informations d'identification temporaires, vous devez appeler l' AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API (recommandé) ou l'[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API. Pour plus d'informations sur les différences entre ces opérations d'API, consultez la section [Comprendre les options d'API pour déléguer l'accès à votre AWS compte en toute](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account) sécurité dans le blog sur la AWS sécurité.
**Important**  
Lorsque vous utilisez l'[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)API pour créer des informations d'identification de sécurité temporaires, vous devez spécifier les autorisations que les informations d'identification accordent à l'utilisateur qui assume le rôle. Dès lors que les opérations d'API commencent par `AssumeRole*`, vous utilisez un rôle IAM pour accorder les autorisations. Pour les autres opérations d'API, le mécanisme varie en fonction de l'API. Pour en savoir plus, consultez [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md). De plus, si vous utilisez les opérations d'API `AssumeRole*`, vous devez les appeler en tant qu'utilisateur IAM avec des informations d'identification à long terme. Sinon, l'appel au point de terminaison de fédération de l'étape 3 échoue.  


1. Une fois que vous avez obtenu les informations d'identification de sécurité temporaires, insérez-les dans une chaîne de session JSON pour les échanger contre un jeton de connexion. L'exemple suivant montre comment encoder les informations d'identification. Vous remplacez le texte de l'espace réservé par les valeurs appropriées dans les informations d'identification reçues à l'étape précédente.

   ```
   {"sessionId":"*** temporary access key ID ***",
   "sessionKey":"*** temporary secret access key ***",
   "sessionToken":"*** session token ***"}
   ```

1. [Encodez par URL](https://en.wikipedia.org/wiki/Percent-encoding) la chaîne de session de l'étape précédente. Dans la mesure où les informations que vous encodez sont sensibles, nous vous recommandons de ne pas utiliser de service web pour cette opération. Utilisez, à la place, une fonction installée en local ou une fonctionnalité de votre boîte à outils de développement pour encoder cette information de manière sécurisée. Vous pouvez utiliser la fonction `urllib.quote_plus` dans Python, la fonction `URLEncoder.encode` dans Java ou la fonction `CGI.escape` dans Ruby. Consultez les exemples dans la suite de cette rubrique.

1. <a name="STSConsoleLink_manual_step5"></a>
**Note**  
AWS prend en charge les requêtes POST ici.

   Envoyez votre demande au point de terminaison AWS de la fédération :

   `https://region-code.signin.aws.amazon.com/federation` 

   Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Vous pouvez éventuellement utiliser le point de terminaison de fédération de AWS connexion par défaut :

   `https://signin.aws.amazon.com/federation` 

   La demande doit inclure les paramètres `Action` et `Session`, et (éventuellement), si vous avez utilisé une opération d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html), un paramètre HTTP `SessionDuration` comme illustré dans l'exemple suivant.

   ```
   Action = getSigninToken
   SessionDuration = time in seconds
   Session = *** the URL encoded JSON string created in steps 3 & 4 ***
   ```
**Note**  
Les instructions suivantes de cette étape ne fonctionnent qu'avec les requêtes GET.

   Ce paramètre HTTP `SessionDuration` spécifie la durée de la session de console. Cette durée est différente de celle des informations d'identification temporaires que vous spécifiez à l'aide du paramètre `DurationSeconds`. Vous pouvez spécifier une valeur `SessionDuration` maximale de 43 200 (12 heures). Si le `SessionDuration` paramètre est absent, la session utilise par défaut la durée des informations d'identification que vous avez récupérées AWS STS à l'étape 2 (qui est par défaut d'une heure). Consultez la [documentation de l'API `AssumeRole`](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) pour plus de détails sur la spécification d'une durée à l'aide du paramètre `DurationSeconds`. La possibilité de créer une session de console d'une durée supérieure à une heure fait partie intégrante de l'opération `getSigninToken` du point de terminaison de fédération.
**Note**  
Votre `SessionDuration` ne peut être supérieure ou égale à la durée maximale de la session définie pour le rôle que vous endossez. Par exemple, vous fixez à cinq heures la durée maximale de la session pour le rôle que vous souhaitez endosser. Votre paramètre `SessionDuration` peut être 16 524 secondes ou 4 heures et 59 secondes.
N’utilisez pas le paramètre HTTP `SessionDuration` lorsque vous obtenez des informations d’identification temporaires avec `GetFederationToken`. L’opération échouera.
L'utilisation des informations d'identification pour qu'un rôle endosse un rôle différent est appelée [*chaînes de rôles*](id_roles.md#iam-term-role-chaining). Lorsque vous utilisez la création de chaînes de rôles, vos nouvelles informations d'identification sont limitées à une durée maximale d'une heure. Lorsque vous utilisez des rôles pour [accorder des autorisations aux applications qui s'exécutent sur des instances EC2](id_roles_use_switch-role-ec2.md), ces applications ne sont pas soumises à cette limitation.
N’utilisez pas le paramètre HTTP `SessionDuration` lorsque vous obtenez des informations d’identification temporaires via le chaînage de rôles. L’opération échouera.

   Lorsque vous activez des sessions de console avec une durée prolongée, vous augmentez le risque d'exposition aux informations d'identification. Pour vous aider à réduire ce risque, vous pouvez immédiatement désactiver les sessions de console actives pour un rôle en choisissant **Révoquer les sessions** sur la page **Résumé du rôle** dans la console IAM. Pour plus d’informations, veuillez consulter [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md). 

    Votre demande devrait ressembler à l'exemple suivant : Des retours à la ligne ont été ajoutés ici pour faciliter la lecture, mais vous devez envoyer une chaîne composée d'une seule ligne.

   ```
   https://signin.aws.amazon.com/federation
   ?Action=getSigninToken
   &SessionDuration=1800
   &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22
   %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2
   2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW
   AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8
   FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5
   PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C
   UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D
   ```

   La réponse du point de terminaison de fédération est un document JSON avec une valeur `SigninToken`. Elle sera similaire à l'exemple suivant.

   ```
   {"SigninToken":"*** the SigninToken string ***"}
   ```

1. 
**Note**  
AWS prend en charge les requêtes POST ici.

   Enfin, créez l’URL que vos utilisateurs utiliseront pour accéder à AWS Management Console. L'URL est la même URL de point de terminaison de fédération que celle que vous avez utilisée dans [Step 5](#STSConsoleLink_manual_step5), à laquelle sont ajoutés les paramètres suivants :

   ```
   ?Action = login
   &Issuer = *** the form-urlencoded URL for your internal sign-in page ***
   &Destination = *** the form-urlencoded URL to the desired AWS console page ***
   &SigninToken = *** the value of SigninToken received in the previous step ***
   ```
**Note**  
Les instructions suivantes de cette étape ne fonctionnent qu'avec l'API GET.

   L'exemple suivant montre comment se présentera l'URL finale. L'URL est valide pendant 15 minutes à partir du moment où elle est créée. Les informations d'identification de sécurité temporaires et la session de console intégrées dans l'URL sont valides pendant la durée spécifiée dans le paramètre HTTP `SessionDuration` lors de leur demande initiale. 

   ```
   https://signin.aws.amazon.com/federation
   ?Action=login
   &Issuer=https%3A%2F%2Fexample.com
   &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F
   &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC
   CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1
   WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm
   iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u
   3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv
   9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf
   nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg
   Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ
   nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm
   0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC
   RNhujg
   ```

## Exemple de code utilisant Python
<a name="STSConsoleLink_programPython"></a>

L’exemple suivant montre comment utiliser Python pour créer par programmation une URL qui donne aux utilisateurs un accès direct à AWS Management Console. Voici deux exemples :
+ Fédérez via des requêtes GET pour AWS
+ Fédérez via des requêtes POST pour AWS

Les deux exemples utilisent l'[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API [AWS SDK pour Python (Boto3)](https://aws.amazon.com/tools/)and pour obtenir des informations d'identification de sécurité temporaires.

N’incluez pas `SessionDuration` si vos informations d’identification `AssumeRoleSession` proviennent d’un chaînage de rôles. Si vous incluez `SessionDuration`, l’opération échouera.

### Utiliser des requêtes GET
<a name="post-api-py-example"></a>

```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'

# Step 1: Authenticate user in your own identity system.

# Step 2: Using the access keys for an IAM user in your Compte AWS,
# call "AssumeRole" to get temporary access keys for the role or federated principal

# Note: Calls to AWS STS AssumeRole must be signed using the access key ID 
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables, 
# or in a configuration file, and will be discovered automatically by the 
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
sts_connection = boto3.client('sts')

assumed_role_object = sts_connection.assume_role(
    RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
    RoleSessionName="AssumeRoleSession",
)

# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)

# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials 
# as parameters.
request_parameters = "?Action=getSigninToken"
request_parameters += "&SessionDuration=43200"
if sys.version_info[0] < 3:
    def quote_plus_function(s):
        return urllib.quote_plus(s)
else:
    def quote_plus_function(s):
        return urllib.parse.quote_plus(s)
request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials)
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
r = requests.get(request_url)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)

# Step 5: Create URL where users can use the sign-in token to sign in to 
# the console. This URL must be used within 15 minutes after the
# sign-in token was issued.
request_parameters = "?Action=login" 
request_parameters += "&Issuer=Example.org" 
request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/")
request_parameters += "&SigninToken=" + signin_token["SigninToken"]
request_url = "https://signin.aws.amazon.com/federation" + request_parameters

# Send final URL to stdout
print (request_url)
```

### Utiliser des requêtes POST
<a name="get-api-py-example-1"></a>

```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
import os
from selenium import webdriver # 'pip install selenium', 'brew install chromedriver'

# Step 1: Authenticate user in your own identity system.

# Step 2: Using the access keys for an IAM user in your A Compte AWS,
# call "AssumeRole" to get temporary access keys for the role or federated principal

# Note: Calls to AWS STS AssumeRole must be signed using the access key ID 
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables, 

# or in a configuration file, and will be discovered automatically by the 
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
if sys.version_info[0] < 3:
    def quote_plus_function(s):
        return urllib.quote_plus(s)
else:
    def quote_plus_function(s):
        return urllib.parse.quote_plus(s)

sts_connection = boto3.client('sts')

assumed_role_object = sts_connection.assume_role(
    RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
    RoleSessionName="AssumeRoleDemoSession",
)

# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)

# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials 
# as parameters.
request_parameters = {}
request_parameters['Action'] = 'getSigninToken'
request_parameters['SessionDuration'] = '43200'
request_parameters['Session'] = json_string_with_temp_credentials

request_url = "https://signin.aws.amazon.com/federation"
r = requests.post( request_url, data=request_parameters)

# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)

# Step 5: Create a POST request where users can use the sign-in token to sign in to 
# the console. The POST request must be made within 15 minutes after the
# sign-in token was issued.
request_parameters = {}
request_parameters['Action'] = 'login'
request_parameters['Issuer']='Example.org'
request_parameters['Destination'] = 'https://console.aws.amazon.com/'
request_parameters['SigninToken'] =signin_token['SigninToken']

jsrequest = '''
var form = document.createElement('form');
form.method = 'POST';
form.action = '{request_url}';
request_parameters = {request_parameters}
for (var param in request_parameters) {{
    if (request_parameters.hasOwnProperty(param)) {{
        const hiddenField = document.createElement('input');
        hiddenField.type = 'hidden';
        hiddenField.name = param;
        hiddenField.value = request_parameters[param];
        form.appendChild(hiddenField);
    }}
}}
document.body.appendChild(form);
form.submit();
'''.format(request_url=request_url, request_parameters=request_parameters)

driver = webdriver.Chrome()
driver.execute_script(jsrequest)
input("Press Enter to close the browser window...")
```

## Exemple de code utilisant Java
<a name="STSConsoleLink_programJava"></a>

L’exemple suivant montre comment utiliser Java pour créer par programmation une URL qui donne aux utilisateurs un accès direct à AWS Management Console. L'extrait de code suivant utilise le kit [SDK AWS pour Java](https://aws.amazon.com/documentation/sdkforjava/).

```
import java.net.URLEncoder;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;
// Available at http://www.json.org/java/index.html
import org.json.JSONObject;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.Credentials;
import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest;
import com.amazonaws.services.securitytoken.model.GetFederationTokenResult;


/* Calls to AWS STS API operations must be signed using the access key ID 
   and secret access key of an IAM user or using existing temporary 
   credentials. The credentials should not be embedded in code. For 
   this example, the code looks for the credentials in a 
   standard configuration file.
*/
AWSCredentials credentials = 
  new PropertiesCredentials(
         AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties"));

AWSSecurityTokenServiceClient stsClient = 
  new AWSSecurityTokenServiceClient(credentials);

GetFederationTokenRequest getFederationTokenRequest = 
  new GetFederationTokenRequest();
getFederationTokenRequest.setDurationSeconds(1800);
getFederationTokenRequest.setName("UserName");

// A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console.

String policy = "{\"Version\":\"2012-10-17\",		 	 	 \"Statement\":[{\"Action\":\"sns:*\"," +
  "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}";

getFederationTokenRequest.setPolicy(policy);

GetFederationTokenResult federationTokenResult = 
  stsClient.getFederationToken(getFederationTokenRequest);

Credentials federatedCredentials = federationTokenResult.getCredentials();

// The issuer parameter specifies your internal sign-in
// page, for example https://mysignin.internal.mycompany.com/.
// The console parameter specifies the URL to the destination console of the
// AWS Management Console. This example goes to Amazon SNS. 
// The signin parameter is the URL to send the request to.

String issuerURL = "https://mysignin.internal.mycompany.com/";
String consoleURL = "https://console.aws.amazon.com/sns";
String signInURL = "https://signin.aws.amazon.com/federation";
  
// Create the sign-in token using temporary credentials,
// including the access key ID,  secret access key, and session token.
String sessionJson = String.format(
  "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}",
  "sessionId", federatedCredentials.getAccessKeyId(),
  "sessionKey", federatedCredentials.getSecretAccessKey(),
  "sessionToken", federatedCredentials.getSessionToken());
              
// Construct the sign-in request with the request sign-in token action, a
// 12-hour console session duration, and the JSON document with temporary 
// credentials as parameters.

String getSigninTokenURL = signInURL + 
                           "?Action=getSigninToken" +
                           "&DurationSeconds=43200" + 
                           "&SessionType=json&Session=" + 
                           URLEncoder.encode(sessionJson,"UTF-8");

URL url = new URL(getSigninTokenURL);

// Send the request to the AWS federation endpoint to get the sign-in token
URLConnection conn = url.openConnection ();

BufferedReader bufferReader = new BufferedReader(new 
  InputStreamReader(conn.getInputStream()));  
String returnContent = bufferReader.readLine();

String signinToken = new JSONObject(returnContent).getString("SigninToken");

String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8");

// The issuer parameter is optional, but recommended. Use it to direct users
// to your sign-in page when their session expires.

String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8");

// Finally, present the completed URL for the AWS console session to the user

String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8");
String loginURL = signInURL + "?Action=login" +
                     signinTokenParameter + issuerParameter + destinationParameter;
```

## Exemple montrant comment créer l'URL (Ruby)
<a name="STSConsoleLink_programRuby"></a>

L’exemple suivant montre comment utiliser Ruby pour créer par programmation une URL qui donne aux utilisateurs un accès direct à AWS Management Console. Cet extrait de code utilise le kit [SDK AWS pour Ruby](https://aws.amazon.com/documentation/sdkforruby/). 

```
require 'rubygems'
require 'json'
require 'open-uri'
require 'cgi'
require 'aws-sdk'

# Create a new STS instance
# 
# Note: Calls to AWS STS API operations must be signed using an access key ID 
# and secret access key. The credentials can be in EC2 instance metadata 
# or in environment variables and will be automatically discovered by
# the default credentials provider in the AWS Ruby SDK. 
sts = Aws::STS::Client.new()

# The following call creates a temporary session that returns 
# temporary security credentials and a session token.
# The policy grants permissions to work
# in the AWS SNS console.

session = sts.get_federation_token({
  duration_seconds: 1800,
  name: "UserName",
  policy: "{\"Version\":\"2012-10-17\",		 	 	 \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}",
})

# The issuer value is the URL where users are directed (such as
# to your internal sign-in page) when their session expires.
#
# The console value specifies the URL to the destination console.
# This example goes to the Amazon SNS console.
#
# The sign-in value is the URL of the AWS STS federation endpoint.
issuer_url = "https://mysignin.internal.mycompany.com/"
console_url = "https://console.aws.amazon.com/sns"
signin_url = "https://signin.aws.amazon.com/federation"

# Create a block of JSON that contains the temporary credentials
# (including the access key ID, secret access key, and session token).
session_json = {
  :sessionId => session.credentials[:access_key_id],
  :sessionKey => session.credentials[:secret_access_key],
  :sessionToken => session.credentials[:session_token]
}.to_json

# Call the federation endpoint, passing the parameters
# created earlier and the session information as a JSON block. 
# The request returns a sign-in token that's valid for 15 minutes.
# Signing in to the console with the token creates a session 
# that is valid for 12 hours.
get_signin_token_url = signin_url + 
                       "?Action=getSigninToken" + 
                       "&SessionType=json&Session=" + 
                       CGI.escape(session_json)

returned_content = URI.parse(get_signin_token_url).read

# Extract the sign-in token from the information returned
# by the federation endpoint.
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = "&SigninToken=" + CGI.escape(signin_token)

# Create the URL to give to the user, which includes the
# sign-in token and the URL of the console to open.
# The "issuer" parameter is optional but recommended.
issuer_param = "&Issuer=" + CGI.escape(issuer_url)
destination_param = "&Destination=" + CGI.escape(console_url)
login_url = signin_url + "?Action=login" + signin_token_param + 
  issuer_param + destination_param
```

# Tags pour les Gestion des identités et des accès AWS ressources
<a name="id_tags"></a>

Une *balise* est un attribut personnalisé que vous pouvez attribue à une ressource AWS . Chaque balise se compose de deux parties :
+ Une *clé de balise* (par exemple, `CostCenter`, `Environment`, `Project` ou `Purpose`).
+ Un champ facultatif appelé *valeur de balise* (par exemple, `111122223333`, `Production` ou le nom d’une équipe). Omettre la valeur de balise équivaut à l’utilisation d’une chaîne vide.

Ensemble, ces éléments sont connus sous le nom de paires clé-valeur. Pour connaître les limites de nombre de balises possibles pour les ressources IAM, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md).

**Note**  
Pour plus d'informations sur la sensibilité à la casse des clés de balises et les valeurs de clés de balises, consultez [Case sensitivity](#case-sensitivity) (français non garanti).

Les balises vous aident à identifier et à organiser vos AWS ressources. De nombreux AWS services prennent en charge le balisage. Vous pouvez donc attribuer le même tag aux ressources de différents services pour indiquer que les ressources sont liées. Par exemple, vous pouvez attribuer la même balise à un rôle IAM que vous affectez à un compartiment Amazon S3. Pour plus d'informations sur les stratégies de balisage, consultez le Guide de l'*utilisateur [AWS des ressources de balisage](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)*.

Outre l'identification, l'organisation et le suivi de vos ressources IAM avec des balises, vous pouvez utiliser des balises dans les politiques IAM afin de contrôler qui peut consulter et interagir avec vos ressources. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

**Topics**
+ [Choisissez une convention de dénomination des AWS balises](#id_tags_naming)
+ [Règles de balisage dans IAM et AWS STS](#id_tags_rules)
+ [Balisage des utilisateurs IAM](id_tags_users.md)
+ [Blisage de rôles IAM](id_tags_roles.md)
+ [Balisage des politiques gérées par le client](id_tags_customer-managed-policies.md)
+ [Balisage de fournisseurs d’identité OpenID Connect (OIDC)](id_tags_oidc.md)
+ [Balisage de fournisseurs d’identité SAML IAM](id_tags_saml.md)
+ [Balisage de profils d’instance pour les rôles Amazon EC2](id_tags_instance-profiles.md)
+ [Balisage des certificats de serveur](id_tags_server-certificates.md)
+ [Balisage des dispositifs MFA virtuels](id_tags_virtual-mfa.md)
+ [Transmettez les tags de session AWS STS](id_session-tags.md)

## Choisissez une convention de dénomination des AWS balises
<a name="id_tags_naming"></a>

Lorsque vous commencez à attacher des balises à vos ressources IAM, choisissez soigneusement votre convention de dénomination de balises. Appliquez la même convention à tous vos AWS tags. Cela est particulièrement important si vous utilisez des balises dans les politiques pour contrôler l'accès aux AWS ressources. Si vous utilisez déjà des balises dans AWS, passez en revue votre convention de dénomination et ajustez-la en conséquence.

**Note**  
Si votre compte est membre de AWS Organizations, consultez les [politiques relatives aux balises](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) dans le guide de l' AWS Organizations utilisateur pour en savoir plus sur l'utilisation des balises dans AWS Organizations.

### Bonnes pratiques pour nommer les balises
<a name="id_tags_naming_best_practices"></a>

Voici quelques bonnes pratiques et conventions pour la dénomination des balises.

Veillez à ce que les noms de balises soient utilisés de manière cohérente. Par exemple, les balises `CostCenter` et `costcenter` sont différentes, de sorte que l'une peut être configurée en tant que balise de répartition des coûts pour l'analyse financière et la confection de rapports, alors que l'autre peut ne pas l'être. De même, le `Name` tag apparaît dans la AWS console pour de nombreuses ressources, mais pas le `name` tag. Pour plus d'informations sur la sensibilité à la casse des clés de balises et les valeurs de clés de balises, consultez [Case sensitivity](#case-sensitivity) (français non garanti).

Un certain nombre de balises sont prédéfinies AWS ou créées automatiquement par différents AWS services. De nombreux noms de balises AWS définis utilisent uniquement des minuscules, avec des tirets séparant les mots dans le nom, et des préfixes pour identifier le service source de la balise. Par exemple : 
+ `aws:ec2spot:fleet-request-id`identifie la demande d'instance Amazon EC2 Spot qui a lancé l'instance.
+ `aws:cloudformation:stack-name`identifie la CloudFormation pile qui a créé la ressource. 
+ `elasticbeanstalk:environment-name` identifie l'application qui a créé la ressource.

Pensez à nommer vos balises en minuscules, avec des traits d'union séparant les mots et un préfixe identifiant le nom de l'organisation ou le nom abrégé. Par exemple, pour une société fictive nommée *AnyCompany*, vous pouvez définir des balises telles que :
+ `anycompany:cost-center` pour identifier le code du centre de coûts interne 
+ `anycompany:environment-type` pour déterminer si l'environnement est un environnement de développement, de test ou de production
+ `anycompany:application-id` pour identifier l'application pour laquelle la ressource a été créée 

Le préfixe garantit que les balises sont clairement identifiées comme ayant été définies par votre organisation et AWS non par un outil tiers que vous utilisez peut-être. L'utilisation de minuscules et de traits d'union pour les séparateurs évite toute confusion quant à l'utilisation de majuscules pour le nom d'une balise. Par exemple, `anycompany:project-id`est plus simple à mémoriser que `ANYCOMPANY:ProjectID`, `anycompany:projectID` ou`Anycompany:ProjectId`.

## Règles de balisage dans IAM et AWS STS
<a name="id_tags_rules"></a>

Un certain nombre de conventions régissent la création et l'application des balises dans IAM et AWS STS.

### Dénomination des balises
<a name="id_tags_rules_creating"></a>

Respectez les conventions suivantes lors de la formulation d'une convention de dénomination des balises pour les ressources IAM, les sessions d' AWS STS assume-rôle et AWS STS les sessions utilisateur fédérées :

**Character requirements** (Exigences relatives aux caractères) : les clés et valeurs des balises peuvent inclure n'importe quelle combinaison de lettres, chiffres, espaces et caractères \$1 . : / = \$1 - @.

**Sensibilité à la casse** : la sensibilité à la casse pour les clés de balise diffère selon le type de ressource IAM qui est balisé. Les valeurs clés de balise pour les utilisateurs et les rôles IAM ne sont pas sensibles à la casse, mais la casse est conservée. Cela signifie que vous ne pouvez pas avoir des clés de balise **Department** et **department** distinctes. Si vous avez balisé un utilisateur avec la balise **Department=finance** et que vous ajoutez la balise **department=hr**, elle remplace la première balise. Une deuxième balise n'est pas ajoutée.

Pour les autres types de ressources IAM, les valeurs de clé de balise sont sensibles à la casse. Cela signifie que vous pouvez avoir des clés de balise **Costcenter** et **costcenter** séparées. Par exemple, si vous avez balisé une politique gérée par le client avec la balise **Costcenter = 1234** et que vous ajoutez la balise **costcenter = 5678**, la politique aura à la fois les clés de balise **Costcenter** et **costcenter**.

À titre de bonne pratique, nous vous recommandons d'éviter d'utiliser des balises similaires avec un traitement de casse incohérent. Nous vous recommandons de choisir une stratégie pour l'utilisation de majuscules pour le nom d'une balise et de mettre en œuvre cette stratégie de manière cohérente sur tous les types de ressources. Pour en savoir plus sur les meilleures pratiques en matière de balisage, consultez la section [AWS Ressources relatives au balisage](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) dans le. Références générales AWS

Les listes suivantes présentent les différences de sensibilité à la casse pour les clés de balise attachées aux ressources IAM.

Les valeurs de clé de balise ne sont **pas** sensibles à la casse :
+ Rôles IAM
+ Utilisateurs IAM

Les valeurs de clé de balise sont sensibles à la casse :
+ Politiques gérées par le client
+ Profils d’instance
+ Fournisseurs d'identité OpenID Connect
+ Fournisseurs d'identité SAML
+ Certificats de serveur
+ Appareils MFA virtuels

En outre, les règles suivantes s'appliquent :
+ Vous ne pouvez pas créer une clé ou valeur de balise qui commence par le texte **aws:**. Ce préfixe de balise est réservé à un usage AWS interne.
+ Vous pouvez créer une balise avec une valeur vide comme **phoneNumber = **. Vous ne pouvez pas créer une clé de balise vide.
+ Vous ne pouvez pas spécifier plusieurs valeurs dans une seule balise, mais vous pouvez créer une structure multivaleur personnalisée dans la valeur unique. Par exemple, supposons que l'utilisateur Zhang fonctionne sur l'équipe d'ingénierie et l'équipe d'assurance qualité. Si vous attachez la balise **team = Engineering**, puis attachez la balise **team = QA**, vous modifiez la valeur de la balise de **Engineering** en **QA**. Au lieu de cela, vous pouvez inclure plusieurs valeurs dans une seule balise avec un séparateur personnalisé. Dans cet exemple, vous pouvez attacher la balise **team = Engineering:QA** à Zhang.
**Note**  
Pour contrôler l'accès aux ingénieurs de cet exemple à l'aide de la balise **team**, vous devez créer une politique qui autorise chaque configuration susceptible d'inclure **Engineering**, y compris **Engineering:QA**. Pour en savoir plus sur l'utilisation des balises dans les politiques consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

### Application et modification de balises
<a name="id_tags_rules_applying"></a>

Observez les conventions suivantes lorsque vous attachez des balises aux ressources IAM :
+ Vous pouvez baliser la plupart des ressources IAM, mais pas les groupes, les rôles endossés, les rapports d'accès, les dispositifs MFA matériels.
+ Vous ne pouvez pas utiliser Tag Editor pour baliser les ressources IAM. Tag Editor ne prend pas en charge les balises IAM. Pour plus d'informations sur l'utilisation de Tag Editor avec d'autres services, consultez [Utilisation de Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html) dans le *Guide de l'utilisateur Groupes de ressources AWS *.
+ Vous devez disposer d'autorisations spécifiques pour baliser une ressource IAM. Pour ajouter ou supprimer des balises aux ressources, vous devez également disposer d'une autorisation pour afficher la liste des balises. Pour plus d'informations, consultez la liste des rubriques pour chaque ressource IAM à la fin de cette page. 
+ Le nombre et la taille des ressources IAM d'un AWS compte sont limités. Pour de plus amples informations, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md).
+ Vous pouvez appliquer la même balise à plusieurs ressources IAM. Par exemple, supposons que vous ayez un service nommé `AWS_Development` comprenant 12 membres. Vous pouvez avoir 12 utilisateurs et un rôle avec la clé de balise **department** et la valeur **awsDevelopment** (**department = awsDevelopment**). Vous pouvez également utiliser la même balise sur les ressources d'autres services [ qui prennent en charge le balisage](reference_aws-services-that-work-with-iam.md).
+ Les entités IAM ( utilisateurs ou rôles) ne peuvent pas avoir plusieurs instances de la même clé de balise. Par exemple, si vous avez un utilisateur avec la paire clé-valeur de balise **costCenter = 1234**, vous pouvez ensuite attacher la paire clé-valeur de balise **costCenter = 5678**. IAM met à jour la valeur de la balise **costCenter** à **5678**.
+ Pour modifier une balise qui est attachée à une entité IAM (utilisateur ou rôle), attachez une balise avec une nouvelle valeur pour remplacer la balise existante. Par exemple, supposons que vous disposiez d'un utilisateur avec la paire clé-valeur de balise **department = Engineering**. Si vous devez déplacer l'utilisateur vers le service d'assurance qualité, vous pouvez attacher la paire clé-valeur de balise **department = QA** à l'utilisateur. Il s'ensuit que la valeur **Engineering** de la clé de balise **department** est remplacée par la valeur **QA**.

# Balisage des utilisateurs IAM
<a name="id_tags_users"></a>

Vous pouvez utiliser des paires clé-valeur de balise IAM pour ajouter des attributs personnalisés à un utilisateur IAM. Par exemple, pour ajouter les informations relatives à un utilisateur, vous pouvez ajouter la clé de balise **location** et la valeur de balise **us\$1wa\$1seattle**. Ou vous pouvez utiliser trois paires clé-valeur de balise aux emplacements distincts : **loc-country = us**, **loc-state = wa** et **loc-city = seattle**. Vous pouvez utiliser les balises pour contrôler l'accès d'un utilisateur aux ressources d'une entité ou pour contrôler les balises qui peuvent être attachées à un utilisateur. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

## Autorisations requises pour le balisage des utilisateurs IAM
<a name="id_tags_users_permissions"></a>

Vous devez configurer les autorisations pour permettre à un utilisateur IAM de baliser d'autres utilisateurs. Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListUserTags`
+ `iam:TagUser`
+ `iam:UntagUser`

**Pour autoriser un utilisateur IAM à ajouter, afficher la liste ou supprimer une balise pour un utilisateur spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'utilisateur IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<username>* remplacez-le par le nom de l'utilisateur dont les tags doivent être gérés. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**Pour autoriser un utilisateur IAM à gérer lui-même les balises**  
Ajoutez l'instruction suivante à la politique d'autorisations pour les utilisateurs qui autorisent les utilisateurs à gérer leurs propres balises. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::user/${aws:username}"
}
```

**Pour autoriser un utilisateur IAM à ajouter une balise à un utilisateur spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'utilisateur IAM qui doit ajouter, mais non pas supprimer, les balises d'un utilisateur spécifique.

**Note**  
L'action `iam:TagUser` nécessite d'inclure également l'action `iam:ListUserTags`.

Pour utiliser cette politique, *<username>* remplacez-la par le nom de l'utilisateur dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les utilisateurs IAM (console)
<a name="id_tags_users_procs-console"></a>

Vous pouvez gérer les balises pour les utilisateurs IAM depuis la AWS Management Console.

**Pour gérer les balises sur les utilisateurs (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, choisissez **Users** (Utilisateurs), puis choisissez le nom de l'utilisateur que vous souhaitez modifier.

1. Choisissez l'onglet **Balises**, puis effectuez l'une des actions suivantes :
   + Choisissez **Ajouter une nouvelle balise** si l'utilisateur ne dispose pas encore de balises.
   + Choisissez **Manage tags** (Gérer les balises) pour gérer l'ensemble de balises existant.

1. Ajoutez ou supprimez des balises pour terminer l'ensemble de balises. Ensuite, choisissez **Enregistrer les modifications**.

## Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)
<a name="id_tags_users_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour les utilisateurs IAM. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises pour les utilisateurs IAM.

**Pour répertorier les balises actuellement associées à un utilisateur IAM (AWS CLI ou à une AWS API)**
+ AWS CLI: [cime list-user-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-tags.html)
+ AWS API : [ListUserTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserTags.html)

**Pour associer des balises à un utilisateur IAM (AWS CLI ou à une AWS API)**
+ AWS CLI: [aws iam tag-user](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-user.html)
+ AWS API : [TagUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagUser.html)

**Pour supprimer des balises d'un utilisateur IAM (AWS CLI ou d'une AWS API)**
+ AWS CLI: [aws iam untag-user](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-user.html)
+ AWS API : [UntagUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagUser.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Blisage de rôles IAM
<a name="id_tags_roles"></a>

Vous pouvez utiliser des paires clé-valeur de balises pour ajouter des attributs personnalisés à un rôle IAM. Par exemple, pour ajouter les informations relatives à un rôle, vous pouvez ajouter la clé de balise **location** et la valeur de balise **us\$1wa\$1seattle**. Ou vous pouvez utiliser trois paires clé-valeur de balise aux emplacements distincts : **loc-country = us**, **loc-state = wa** et **loc-city = seattle**. Vous pouvez utiliser les balises pour contrôler l'accès d'un rôle aux ressources d'une entité ou pour contrôler les balises qui peuvent être attachées à un rôle. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

## Autorisations requises pour le balisage des rôles IAM
<a name="id_tags_roles_permissions"></a>

Vous devez configurer les autorisations de manière à permettre à un rôle IAM de baliser d'autres entités (utilisateurs ou rôles). Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListRoleTags`
+ `iam:TagRole`
+ `iam:UntagRole`
+ `iam:ListUserTags`
+ `iam:TagUser`
+ `iam:UntagUser`

**Pour autoriser un rôle IAM à ajouter, afficher la liste ou supprimer une balise pour un utilisateur spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations du rôle IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<username>* remplacez-le par le nom de l'utilisateur dont les tags doivent être gérés. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**Pour autoriser un rôle IAM à ajouter une balise à un utilisateur spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations du rôle IAM qui doit ajouter, mais non pas supprimer, les balises d'un utilisateur spécifique.

Pour utiliser cette politique, *<username>* remplacez-la par le nom de l'utilisateur dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**Pour autoriser un rôle IAM à ajouter, afficher la liste ou supprimer une balise pour un rôle spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations du rôle IAM qui doit gérer les balises. Remplacez *<rolename>* par le nom du rôle dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListRoleTags",
        "iam:TagRole",
        "iam:UntagRole"
    ],
    "Resource": "arn:aws:iam::<account-number>:role/<rolename>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les rôles IAM (console)
<a name="id_tags_roles_procs-console"></a>

Vous pouvez gérer les balises pour les rôles IAM depuis la AWS Management Console.

**Pour gérer les balises sur les rôles (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, choisissez **Roles** (Rôles), puis choisissez le nom du rôle que vous souhaitez modifier.

1. Choisissez l'onglet **Balises**, puis effectuez l'une des actions suivantes :
   + Choisissez **Add new tag** (Ajouter une nouvelle balise) si le rôle ne dispose pas encore de balises.
   + Choisissez **Manage tags** (Gérer les balises) pour gérer l'ensemble de balises existant.

1. Ajoutez ou supprimez des balises pour terminer l'ensemble de balises. Ensuite, choisissez **Save changes** (Enregistrer les modifications).

## Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)
<a name="id_tags_roles_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour les rôles IAM. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises des rôles IAM.

**Pour répertorier les balises actuellement associées à un rôle IAM (AWS CLI ou à une AWS API)**
+ AWS CLI: [cime list-role-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-tags.html)
+ AWS API : [ListRoleTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoleTags.html)

**Pour associer des balises à un rôle IAM (AWS CLI ou à une AWS API)**
+ AWS CLI: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
+ AWS API : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

**Pour supprimer des balises d'un rôle IAM (AWS CLI ou d'une AWS API)**
+ AWS CLI: [aws iam untag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-role.html)
+ AWS API : [UntagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagRole.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Balisage des politiques gérées par le client
<a name="id_tags_customer-managed-policies"></a>

Vous pouvez utiliser des paires clé-valeur de balises IAM pour ajouter des attributs personnalisés à vos politiques gérées par le client. Par exemple, pour baliser une politique avec des informations de service, vous pouvez ajouter la clé de balise **Department** et la valeur de balise **eng**. Ou bien, vous pouvez baliser les politiques pour indiquer qu'elles sont destinées à un environnement spécifique, comme **Environment = lab**. Vous pouvez utiliser les balises pour contrôler l'accès aux ressources ou pour contrôler les balises qui peuvent être attachées à une ressource. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

## Autorisations requises pour baliser les politiques gérées par le client
<a name="id_tags_customer-managed-policies_permissions"></a>

Vous devez configurer des autorisations pour autoriser une entité IAM (utilisateurs ou rôles) à baliser les politiques gérées par le client. Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListPolicyTags`
+ `iam:TagPolicy`
+ `iam:UntagPolicy`

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter, afficher la liste ou supprimer une balise pour une politique gérée par le client**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<policyname>* remplacez-le par le nom de la politique dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListPolicyTags",
        "iam:TagPolicy",
        "iam:UntagPolicy"
    ],
    "Resource": "arn:aws:iam::<account-number>:policy/<policyname>"
}
```

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter une balise à une politique gérée par le client spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit ajouter, mais non pas supprimer, les balises d'une politique spécifique. 

**Note**  
L'action `iam:TagPolicy` nécessite d'inclure également l'action `iam:ListPolicyTags`.

Pour utiliser cette politique, *<policyname>* remplacez-la par le nom de la politique dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListPolicyTags",
        "iam:TagPolicy"
    ],
    "Resource": "arn:aws:iam::<account-number>:policy/<policyname>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les politiques gérées par le client IAM (console)
<a name="id_tags_customer-managed-policies_procs-console"></a>

Vous pouvez gérer les balises pour les politiques gérées par le client IAM à partir de la AWS Management Console.

**Pour gérer les balises sur les politiques gérées par le client (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, choisissez **Policies** (Politiques), puis choisissez le nom de la politique gérée par le client que vous souhaitez modifier.

1. Choisissez l'onglet **Balises**, puis **Gérer les balises**.

1. Ajoutez ou supprimez des balises pour terminer l'ensemble de balises. Ensuite, choisissez **Enregistrer les modifications**.

## Gestion des balises sur les politiques (AWS CLI ou AWS API) gérées par le client IAM
<a name="id_tags_customer-managed-policies_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour les politiques gérées par le client IAM. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises dans le cadre des politiques gérées par les clients IAM.

**Pour répertorier les balises actuellement attachées à une politique (AWS CLI ou AWS API) gérée par le client IAM**
+ AWS CLI: [cime list-policy-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-policy-tags.html)
+ AWS API : [ListPolicyTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListPolicyTags.html)

**Pour associer des balises à une politique (AWS CLI ou AWS API) gérée par le client IAM**
+ AWS CLI : [aws iam tag-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-policy.html)
+ AWS API : [TagPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagPolicy.html)

**Pour supprimer des balises d'une politique (AWS CLI ou AWS API) gérée par le client IAM**
+ AWS CLI : [aws iam untag-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-policy.html)
+ AWS API : [UntagPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagPolicy.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Balisage de fournisseurs d’identité OpenID Connect (OIDC)
<a name="id_tags_oidc"></a>

Vous pouvez utiliser des paires clé-valeur de balises IAM pour ajouter des attributs personnalisés aux fournisseurs d'identité OpenID Connect (OIDC) IAM. Par exemple, pour identifier un fournisseur d'identité OIDC, vous pouvez ajouter la clé de balise **google** et la valeur de balise **oidc**. Vous pouvez utiliser les balises pour contrôler l'accès aux ressources ou pour contrôler les balises qui peuvent être attachées à un objet. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

## Autorisations requises pour baliser les fournisseurs d'identité OIDC IAM
<a name="id_tags_oidc_permissions"></a>

Vous devez configurer les autorisations de manière à permettre à une entité IAM (utilisateur ou rôle) de baliser des fournisseurs d'identité OIDC IAM. Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListOpenIDConnectProviderTags`
+ `iam:TagOpenIDConnectProvider`
+ `iam:UntagOpenIDConnectProvider`

**Pour autoriser une entité IAM à ajouter, afficher la liste ou supprimer une balise pour un fournisseur d’identité OIDC IAM**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<OIDCProviderName>* remplacez-le par le nom du fournisseur OIDC dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListOpenIDConnectProviderTags",
        "iam:TagOpenIDConnectProvider",
        "iam:UntagOpenIDConnectProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:oidc-provider/<OIDCProviderName>"
}
```

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter une balise à un fournisseur d'identité OIDC IAM spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit ajouter, mais non pas supprimer, les balises d'un fournisseur d'identité spécifique.

**Note**  
L'action `iam:TagOpenIDConnectProvider` nécessite d'inclure également l'action `iam:ListOpenIDConnectProviderTags`.

Pour utiliser cette politique, *<OIDCProviderName>* remplacez-la par le nom du fournisseur OIDC dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListOpenIDConnectProviderTags",
        "iam:TagOpenIDConnectProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:oidc-provider/<OIDCProviderName>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les fournisseurs d'identité OIDC IAM (console)
<a name="id_tags_oidc_procs-console"></a>

Vous pouvez gérer les balises pour les fournisseurs d'identité OIDC IAM à partir de la AWS Management Console.

**Pour gérer les balises sur les fournisseurs d'identité OIDC (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, sélectionnez **Identity providers** (Fournisseurs d'identité), puis le nom du fournisseur d'identité que vous souhaitez modifier.

1. Choisissez l’onglet **Balises**, puis dans la section **Balises**, choisissez **Gérer les balises**, puis effectuez l’une des actions suivantes :
   + Choisissez **Add tag** (Ajouter une balise) si le fournisseur d'identité OIDC n'a pas encore de balises ou pour ajouter une nouvelle balise.
   + Modifiez les clés et les valeurs de balise existantes.
   + Choisissez **Remove tag** (Supprimer une balise) pour supprimer une balise.

1. Ensuite, choisissez **Enregistrer les modifications**.

## Gestion des balises sur les fournisseurs d'identité IAM OIDC (AWS CLI ou AWS API)
<a name="id_tags_oidc_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour les fournisseurs d'identité OIDC IAM. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises des fournisseurs d'identité IAM OIDC.

**Pour répertorier les balises actuellement attachées à un fournisseur d'identité (AWS CLI ou AWS API) IAM OIDC**
+ AWS CLI: balises [aws iam -provider-tags list-open-id-connect](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html)
+ AWS API : [ListOpenIDConnectProviderTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html)

**Pour associer des balises à un fournisseur d'identité (AWS CLI ou AWS API) IAM OIDC**
+ AWS CLI: [fournisseur AWS iam tag-open-id-connect](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html)
+ AWS API : [TagOpenIDConnectfournisseur](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html)

**Pour supprimer des balises d'un fournisseur d'identité (AWS CLI ou AWS API) IAM OIDC**
+ AWS CLI: [fournisseur AWS iam untag-open-id-connect](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html)
+ AWS API : [UntagOpenIDConnectfournisseur](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Balisage de fournisseurs d’identité SAML IAM
<a name="id_tags_saml"></a>

Vous pouvez utiliser des paires clé-valeur de balises IAM pour ajouter des attributs personnalisés aux fournisseurs d'identité SAML. Par exemple, pour identifier un fournisseur, vous pouvez ajouter la clé de balise **okta** et la valeur de balise **saml**. Vous pouvez utiliser les balises pour contrôler l'accès aux ressources ou pour contrôler les balises qui peuvent être attachées à un objet. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

## Autorisations requises pour baliser les fournisseurs d'identité SAML
<a name="id_tags_saml_permissions"></a>

Vous devez configurer les autorisations pour permettre à une entité IAM (utilisateurs ou rôles) de baliser les fournisseurs d'identité basés sur SAML 2.0 (). IdPs Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListSAMLProviderTags`
+ `iam:TagSAMLProvider`
+ `iam:UntagSAMLProvider`

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter, afficher la liste ou supprimer une balise pour un fournisseur d'identité SAML**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<SAMLProviderName>* remplacez-le par le nom du fournisseur SAML dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListSAMLProviderTags",
        "iam:TagSAMLProvider",
        "iam:UntagSAMLProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:saml-provider/<SAMLProviderName>"
}
```

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter une balise à un fournisseur d'identité SAML spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit ajouter, mais non pas supprimer, les balises d'un fournisseur d'identité SAML spécifique.

**Note**  
L'action `iam:TagSAMLProvider` nécessite d'inclure également l'action `iam:ListSAMLProviderTags`.

Pour utiliser cette politique, *<SAMLProviderName>* remplacez-la par le nom du fournisseur SAML dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListSAMLProviderTags",
        "iam:TagSAMLProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:saml-provider/<SAMLProviderName>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les fournisseurs d'identité SAML IAM (console)
<a name="id_tags_saml_procs-console"></a>

Vous pouvez gérer les balises pour les fournisseurs d'identité SAML IAM à partir de la AWS Management Console.

**Pour gérer les balises sur les fournisseurs d'identité SAML (console)**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le panneau de navigation de la console, sélectionnez **Identity providers** (Fournisseurs d'identité), puis le nom du fournisseur d'identité SAML que vous souhaitez modifier.

1. Choisissez l’onglet **Balises**, puis dans la section **Balises**, choisissez **Gérer les balises**, puis effectuez l’une des actions suivantes :
   + Choisissez **Add tag** (Ajouter une balise) si le fournisseur d'identité SAML n'a pas encore de balises ou pour ajouter une nouvelle balise.
   + Modifiez les clés et les valeurs de balise existantes.
   + Choisissez **Remove tag** (Supprimer une balise) pour supprimer une balise.

1. Ajoutez ou supprimez des balises pour terminer l'ensemble de balises. Ensuite, choisissez **Enregistrer les modifications**.

## Gestion des balises sur les fournisseurs d'identité IAM SAML (AWS CLI ou AWS API)
<a name="id_tags_saml_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour les fournisseurs d'identité SAML IAM. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises des fournisseurs d'identité IAM SAML.

**Pour répertorier les balises actuellement attachées à un fournisseur d'identité SAML (AWS CLI ou AWS API)**
+ AWS CLI: [cime list-saml-provider-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html)
+ AWS API : [SAMLProviderbalises de liste](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html)

**Pour associer des balises à un fournisseur d'identité (AWS CLI ou AWS API) SAML**
+ AWS CLI: [cime tag-saml-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html)
+ AWS API : [balise SAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html)

**Pour supprimer des balises d'un fournisseur d'identité (AWS CLI ou d'une AWS API) SAML**
+ AWS CLI: [cime untag-saml-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html)
+ AWS API : [Untag SAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Balisage de profils d’instance pour les rôles Amazon EC2
<a name="id_tags_instance-profiles"></a>

Lorsque vous lancez une instance Amazon EC2, vous spécifiez un rôle IAM à associer à celle-ci. Un profil d'instance est un conteneur pour un rôle IAM que vous pouvez utiliser pour transmettre les informations liées au rôle à une instance Amazon EC2 lorsque l'instance démarre. Vous pouvez baliser les profils d'instance lorsque vous utilisez l' AWS API AWS CLI or.

Vous pouvez utiliser des paires clé-valeur de balise IAM pour ajouter des attributs personnalisés à un profil d'instance. Par exemple, pour ajouter des informations de service à un profil d'instance, vous pouvez ajouter la clé de balise **access-team** et la valeur de balise **eng**. Cela donne aux principaux avec des balises correspondantes l'accès aux profils d'instance avec la même balise. Vous pouvez utiliser plusieurs paires clé-valeur de balise pour spécifier une équipe et un projet : **access-team = eng **, et **project = peg**. Vous pouvez utiliser les balises pour contrôler l'accès d'un utilisateur aux ressources d'une entité ou pour contrôler les balises qui peuvent être attachées à un utilisateur. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

## Autorisations requises pour le balisage des profils d'instance
<a name="id_tags_instance-profiles_permissions"></a>

Vous devez configurer les autorisations de manière à permettre à une entité IAM (utilisateur ou rôle) de baliser des profils d'instance. Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListInstanceProfileTags`
+ `iam:TagInstanceProfile`
+ `iam:UntagInstanceProfile`

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter, afficher la liste ou supprimer une balise pour un profil d'instance**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<InstanceProfileName>* remplacez-le par le nom du profil d'instance dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListInstanceProfileTags",
        "iam:TagInstanceProfile",
        "iam:UntagInstanceProfile"
    ],
    "Resource": "arn:aws:iam::<account-number>:instance-profile/<InstanceProfileName>"
}
```

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter une balise à un profil d'instance spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit ajouter, mais non pas supprimer, les balises d'un profil d'instance spécifique. 

**Note**  
L'action `iam:TagInstanceProfile` nécessite d'inclure également l'action `iam:ListInstanceProfileTags`.

Pour utiliser cette politique, *<InstanceProfileName>* remplacez-la par le nom du profil d'instance dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListInstanceProfileTags",
        "iam:TagInstanceProfile"
    ],
    "Resource": "arn:aws:iam::<account-number>:instance-profile/<InstanceProfileName>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les profils d'instance (AWS CLI ou AWS API)
<a name="id_tags_instance-profile_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour des profils d'instance. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises des profils d'instance.

**Pour répertorier les balises actuellement attachées à un profil d'instance (AWS CLI ou à une AWS API)**
+ AWS CLI: [cime list-instance-profile-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html)
+ AWS API : [ListInstanceProfileTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfileTags.html)

**Pour associer des balises à un profil d'instance (AWS CLI ou à une AWS API)**
+ AWS CLI: [cime tag-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html)
+ AWS API : [TagInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html)

**Pour supprimer des balises d'un profil d'instance (AWS CLI ou d'une AWS API)**
+ AWS CLI: [cime untag-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html)
+ AWS API : [UntagInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagInstanceProfile.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Balisage des certificats de serveur
<a name="id_tags_server-certificates"></a>

Si vous utilisez IAM pour gérer les SSL/TLS certificats, vous pouvez baliser les certificats de serveur dans IAM à l'aide de l'API AWS CLI or AWS . Pour les certificats d'une région prise en charge par AWS Certificate Manager (ACM), nous vous recommandons d'utiliser ACM au lieu d'IAM pour provisionner, gérer et déployer vos certificats de serveur. Dans les régions non prises en charge, vous devez utiliser IAM en tant que gestionnaire de certificats. Pour savoir quelles régions sont prises en charge par ACM, consultez [Points de terminaison et quotas AWS Certificate Manager](https://docs.aws.amazon.com/general/latest/gr/acm.html) (français non garanti) dans *Références générales AWS*.

Vous pouvez utiliser des paires clé-valeur de balise IAM pour ajouter des attributs personnalisés à un certificat de serveur. Par exemple, pour ajouter des informations sur le propriétaire ou l'administrateur d'un certificat de serveur, ajoutez la clé de balise **owner** et la valeur de balise **net-eng**. Vous pouvez également spécifier un centre de coûts en ajoutant la clé de balise **CostCenter** et la valeur de balise **1234**. Vous pouvez utiliser les balises pour contrôler l'accès aux ressources ou pour contrôler les balises qui peuvent être attachées à des ressources. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

## Autorisations requises pour le balisage des certificats de serveur
<a name="id_tags_server-certificates_permissions"></a>

Vous devez configurer les autorisations de manière à permettre à une entité IAM (utilisateur ou rôle) de baliser des certificats de serveur. Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListServerCertificateTags`
+ `iam:TagServerCertificate`
+ `iam:UntagServerCertificate`

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter, afficher la liste ou supprimer une balise pour un certificat de serveur**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<CertificateName>* remplacez-le par le nom du certificat de serveur dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListServerCertificateTags",
        "iam:TagServerCertificate",
        "iam:UntagServerCertificate"
    ],
    "Resource": "arn:aws:iam::<account-number>:server-certificate/<CertificateName>"
}
```

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter une balise à un certificat de serveur spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit ajouter, mais non pas supprimer, les balises d'un certificat de serveur spécifique.

**Note**  
L'action `iam:TagServerCertificate` nécessite d'inclure également l'action `iam:ListServerCertificateTags`.

Pour utiliser cette politique, *<CertificateName>* remplacez-la par le nom du certificat de serveur dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListServerCertificateTags",
        "iam:TagServerCertificate"
    ],
    "Resource": "arn:aws:iam::<account-number>:server-certificate/<CertificateName>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les certificats de serveur (AWS CLI ou AWS API)
<a name="id_tags_server-certificates_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour les certificats de serveur. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises des certificats de serveur.

**Pour répertorier les balises actuellement attachées à un certificat de serveur (AWS CLI ou à une AWS API)**
+ AWS CLI: [cime list-server-certificate-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificate-tags.html)
+ AWS API : [ListServerCertificateTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificateTags.html)

**Pour associer des balises à un certificat de serveur (AWS CLI ou à une AWS API)**
+ AWS CLI: [cime tag-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-server-certificate.html)
+ AWS API : [TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html)

**Pour supprimer des balises d'un certificat de serveur (AWS CLI ou d'une AWS API)**
+ AWS CLI: [cime untag-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-server-certificate.html)
+ AWS API : [UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Balisage des dispositifs MFA virtuels
<a name="id_tags_virtual-mfa"></a>

Vous pouvez utiliser des paires clé-valeur de balise IAM pour ajouter des attributs personnalisés à un appareil MFA virtuel. Par exemple, pour ajouter des informations de centre de coûts pour l'appareil MFA virtuel d'un utilisateur, vous pouvez ajouter la clé de balise **CostCenter** et la valeur de balise **1234**. Vous pouvez utiliser les balises pour contrôler l'accès aux ressources ou pour contrôler les balises qui peuvent être attachées à un objet. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).

Vous pouvez également utiliser des balises AWS STS pour ajouter des attributs personnalisés lorsque vous assumez un rôle ou que vous fédérez un utilisateur. Pour de plus amples informations, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).

## Autorisations requises pour le balisage des appareils MFA virtuels
<a name="id_tags_virtual-mfa_permissions"></a>

Vous devez configurer les autorisations de manière à permettre à une entité IAM (utilisateur ou rôle) de baliser des appareils MFA virtuels. Vous pouvez spécifier une ou toutes les actions suivantes d'une balise IAM dans une politique IAM :
+ `iam:ListMFADeviceTags`
+ `iam:TagMFADevice`
+ `iam:UntagMFADevice`

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter, afficher la liste ou supprimer une balise pour un appareil MFA virtuel**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit gérer les balises. Utilisez votre numéro de compte et *<MFATokenID>* remplacez-le par le nom du périphérique MFA virtuel dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListMFADeviceTags",
        "iam:TagMFADevice",
        "iam:UntagMFADevice"
    ],
    "Resource": "arn:aws:iam::<account-number>:mfa/<MFATokenID>"
}
```

**Pour autoriser une entité IAM (utilisateur ou rôle) à ajouter une balise à un dispositif MFA virtuel spécifique**  
Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit ajouter, mais non pas supprimer, les balises d'un appareil MFA spécifique.

**Note**  
L'action `iam:TagMFADevice` nécessite d'inclure également l'action `iam:ListMFADeviceTags`.

Pour appliquer cette politique, *<MFATokenID>* remplacez-la par le nom du périphérique MFA virtuel dont les balises doivent être gérées. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor).

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListMFADeviceTags",
        "iam:TagMFADevice"
    ],
    "Resource": "arn:aws:iam::<account-number>:mfa/<MFATokenID>"
}
```

Vous pouvez également utiliser une politique AWS gérée telle qu'[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) pour fournir un accès complet à IAM.

## Gestion des balises sur les appareils MFA virtuels (AWS CLI ou AWS API)
<a name="id_tags_virtual-mfa_procs-cli-api"></a>

Vous pouvez afficher la liste, attacher ou supprimer des balises pour un appareil MFA virtuel. Vous pouvez utiliser l'API AWS CLI ou l' AWS API pour gérer les balises d'un appareil MFA virtuel.

**Pour répertorier les balises actuellement attachées à un périphérique MFA virtuel (AWS CLI ou AWS API)**
+ AWS CLI: [vison list-mfa-device-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html)
+ AWS API : [MFADevicebalises de liste](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html)

**Pour associer des balises à un périphérique MFA virtuel (AWS CLI ou AWS API)**
+ AWS CLI: [vison tag-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html)
+ AWS API : [balise MFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html)

**Pour supprimer des balises d'un périphérique MFA virtuel (AWS CLI ou AWS d'une API)**
+ AWS CLI: [vison untag-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html)
+ AWS API : [Untag MFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html)

Pour plus d'informations sur l'attachement de balises aux ressources d'autres AWS services, consultez la documentation de ces services. 

Pour plus d'informations sur l'utilisation des balises pour définir d'autres autorisations détaillées avec des politiques d'autorisations IAM, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).

# Transmettez les tags de session AWS STS
<a name="id_session-tags"></a>

Les balises de session sont des attributs de paire clé-valeur que vous transmettez lorsque vous endossez un rôle IAM ou fédérez un utilisateur dans AWS STS. Pour ce faire, vous devez effectuer une AWS CLI demande d' AWS API via AWS STS ou via votre fournisseur d'identité (IdP). Lorsque vous demandez des informations AWS STS d'identification de sécurité temporaires, vous générez une session. Les sessions expirent et disposent [d'informations d'identification](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html), telles qu'une paire de clés d'accès et un jeton de session. Lorsque vous utilisez les informations d'identification de session pour effectuer une demande ultérieure, le [contexte de demande ](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext) inclut la clé de contexte `aws:PrincipalTag`. Vous pouvez utiliser la clé `aws:PrincipalTag` dans l'élément `Condition` de vos politiques pour autoriser ou refuser l'accès en fonction de ces balises.

Lorsque vous utilisez des informations d'identification temporaires pour effectuer une demande, votre principal peut inclure un ensemble d'étiquettes. Ces balises proviennent des sources suivantes :

1. **Balises de session** : balises transmises lorsque vous assumez le rôle ou que vous fédérez l'utilisateur à l'aide de l' AWS API AWS CLI or. Pour plus d'informations sur ces opérations, consultez [Opérations de balisage de session](#id_session-tags_operations).

1. **Incoming transitive session tags** (Balises de session transitive entrantes) : ces balises ont été héritées d'une session précédente dans une chaîne de rôles. Pour plus d'informations, consultez [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining) plus loin dans cette rubrique.

1. **Balises IAM** : balises attachées à votre rôle IAM endossé.

**Topics**
+ [Opérations de balisage de session](#id_session-tags_operations)
+ [Choses à savoir sur les balises de session](#id_session-tags_know)
+ [Autorisations requises pour ajouter des balises de session](#id_session-tags_permissions-required)
+ [Transmission de balises de session en utilisant AssumeRole](#id_session-tags_adding-assume-role)
+ [Transmission de balises de session à l'aide de AssumeRoleWith SAML](#id_session-tags_adding-assume-role-saml)
+ [Transmission de balises de session en utilisant AssumeRoleWithWebIdentity](#id_session-tags_adding-assume-role-idp)
+ [Transmission de balises de session en utilisant GetFederationToken](#id_session-tags_adding-getfederationtoken)
+ [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining)
+ [Utilisation des balises de session pour ABAC](#id_session-tags_using-abac)
+ [Afficher les balises de session dans CloudTrail](#id_session-tags_ctlogs)

## Opérations de balisage de session
<a name="id_session-tags_operations"></a>

Vous pouvez transmettre des balises de session à l'aide des opérations suivantes AWS CLI ou des opérations d' AWS API AWS STS. *La fonctionnalité AWS Management Console **[Switch Role](id_roles_use_switch-role-console.md)** ne vous permet pas de transmettre des balises de session.*

Vous pouvez également définir les balises de session comme transitives. Les balises transitives persistent pendant le chaînage des rôles. Pour de plus amples informations, veuillez consulter [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining).

Le tableau suivant compare les méthodes de transmission des balises de session.


|  Opération |  **Qui peut endosser le rôle**  | **Méthode pour transmettre des balises** |  **Méthode pour définir des balises transitives**  | 
| --- | --- | --- | --- | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | Utilisateur ou session IAM | Paramètre API Tags ou option d'interface de ligne de commande (CLI) --tags | Paramètre API TransitiveTagKeys ou option d'interface de ligne de commande (CLI) --transitive-tag-keys | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) ou API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Tout utilisateur authentifié à l'aide d'un fournisseur d'identité SAML | Attribut SAML PrincipalTag | Attribut SAML TransitiveTagKeys | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) ou API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Tout utilisateur authentifié à l’aide d’un fournisseur OIDC | Jeton PrincipalTag OIDC | Jeton TransitiveTagKeys OIDC | 
| Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/get-federation-token.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-federation-token.html) ou API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | Utilisateur IAM ou utilisateur racine | Paramètre API Tags ou option d'interface de ligne de commande (CLI) --tags | Non pris en charge | 

Les opérations qui prennent en charge le balisage de session peuvent échouer si l'une des conditions suivantes est remplie :
+ Vous transmettez plus de 50 balises de session.
+ Le texte brut de vos clés de balise de session dépasse 128 caractères.
+ Le texte brut des valeurs de vos balises de session dépasse 256 caractères.
+ La taille totale du texte brut des politiques de session dépasse 2 048 caractères.
+ La taille totale des politiques et balises de session combinées est trop grande. Si l'opération échoue, le message d'erreur indique à quel point les politiques et les balises combinées se rapprochent de la limite de taille supérieure, en pourcentage.

## Choses à savoir sur les balises de session
<a name="id_session-tags_know"></a>

Avant d'utiliser des balises de session, veuillez consulter les détails suivants concernant les sessions et les balises.
+ Lorsque vous utilisez des balises de session, les politiques d'approbation pour tous les rôles connectés au fournisseur d'identité qui transmet des balises doivent disposer de l'autorisation [`sts:TagSession`](#id_session-tags_permissions-required). Pour les rôles qui ne disposent pas de cette autorisation dans la politique d'approbation, l'opération `AssumeRole` échoue.
+ Lorsque vous demandez une session, vous pouvez spécifier des balises de principal comme balises de session. Les balises s'appliquent aux demandes que vous effectuez à l'aide des informations d'identification de la session.
+ Les balises utilisent des paires clé-valeur. Par exemple, pour ajouter des informations de contact à une session, vous pouvez ajouter la clé de balise de session `email` et la valeur de balise `johndoe@example.com`.
+ Les balises de session doivent suivre les [règles de dénomination des balises dans IAM et AWS STS](id_tags.md#id_tags_rules_creating). Cette rubrique contient des informations sur la sensibilité à la casse et les préfixes restreints qui s'appliquent à vos balises de session.
+ Les nouvelles balises de session remplacent les balises de session de rôle ou d’utilisateur fédéré existantes avec la même clé de balise, quel que soit le cas de caractères.
+ Vous ne pouvez pas transmettre de balises de session à l'aide du AWS Management Console.
+ Les balises de session ne sont valides que pour la session en cours. 
+ Les balises de session prennent en charge le [chaînage des rôles](id_roles.md#iam-term-role-chaining). Par défaut, AWS STS ne transmet pas de balises aux sessions de rôle suivantes. Toutefois, vous pouvez définir les balises de session comme transitives. Les balises transitives persistent durant le chaînage des rôles et remplacent la mise en correspondance de valeurs `ResourceTag` après l’évaluation de la politique de confiance de rôle. Pour de plus amples informations, veuillez consulter [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining).
+ Vous pouvez utiliser des balises de session pour contrôler l'accès aux ressources ou pour contrôler les balises qui peuvent être transmises à une session ultérieure. Pour plus d'informations, veuillez consulter [Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC](tutorial_abac-saml.md).
+ Vous pouvez afficher les balises principales de votre session, y compris les balises de session, dans les journaux AWS CloudTrail . Pour de plus amples informations, veuillez consulter [Afficher les balises de session dans CloudTrail](#id_session-tags_ctlogs).
+ Vous devez transmettre une valeur unique pour chaque balise de session. AWS STS ne prend pas en charge les balises de session à valeurs multiples. 
+ Vous pouvez transmettre un maximum de 50 balises de session. Le nombre et la taille des ressources IAM d'un AWS compte sont limités. Pour de plus amples informations, veuillez consulter [IAM et quotas AWS STS](reference_iam-quotas.md).
+ Une AWS conversion compresse les politiques de session et les balises de session adoptées combinées dans un format binaire compressé avec une limite distincte. Si vous dépassez cette limite, le message d'erreur de l' AWS API AWS CLI or indique dans quelle mesure les politiques et les balises combinées se rapprochent de la limite de taille supérieure, en pourcentage.

## Autorisations requises pour ajouter des balises de session
<a name="id_session-tags_permissions-required"></a>

En plus de l'action qui correspond à l'opération d'API, vous devez disposer de l'action d'autorisation suivante dans votre politique :

```
sts:TagSession
```

**Important**  
Lorsque vous utilisez des balises de session, les politiques d'approbation de rôle pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:TagSession`. L'opération `AssumeRole` échoue pour tout rôle connecté à un fournisseur d'identité qui transmet des balises de session sans cette autorisation. Si vous ne souhaitez pas mettre à jour la politique d'approbation de rôle pour chaque rôle, vous pouvez utiliser une instance de fournisseur d'identité distincte pour transmettre les balises de session. Ajoutez ensuite l'autorisation `sts:TagSession` uniquement aux rôles qui sont connectés au fournisseur d'identité distinct.

Vous pouvez utiliser l'action `sts:TagSession` avec les clés de condition suivantes.
+ `aws:PrincipalTag` : compare la balise attachée au principal effectuant la demande avec la balise spécifiée dans la politique. Par exemple, vous pouvez autoriser un principal à transmettre des balises de session uniquement si le principal qui effectue la demande possède les balises spécifiées.
+ `aws:RequestTag` : compare la paire clé-valeur de balise qui a été transmise dans la demande avec la paire de balises que vous indiquez dans la politique. Par exemple, vous pouvez autoriser le principal à transmettre les balises de session spécifiées, mais uniquement avec les valeurs spécifiées.
+ `aws:ResourceTag` : compare la paire clé-valeur de balise que vous avez spécifiée dans la politique avec la paire clé-valeur attachée à la ressource. Par exemple, vous pouvez autoriser le principal à transmettre des balises de session uniquement si le rôle qu'il endosse inclut les balises spécifiées.
+ `aws:TagKeys` : compare les clés de balise d'une demande avec les clés que vous avez spécifiées dans la politique. Par exemple, vous pouvez autoriser le principal à transmettre uniquement les balises de session avec les clés de balise spécifiées. Cette clé de condition limite l'ensemble maximal de balises de session pouvant être passé.
+ `sts:TransitiveTagKeys` : compare les clés des balises de session transitive de la demande à celles spécifiées dans la politique. Par exemple, vous pouvez écrire une politique pour permettre à un principal de définir uniquement des balises spécifiques comme transitives. Les balises transitives persistent pendant le chaînage des rôles. Pour plus d'informations, veuillez consulter [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining).

Par exemple, la [politique d'approbation de rôle](id_roles.md#term_trust-policy) suivante permet à l'utilisateur `test-session-tags` d'endosser le rôle auquel la politique est attachée. Lorsque cet utilisateur assume le rôle, il doit utiliser l' AWS API AWS CLI or pour transmettre les trois balises de session requises et l'[ID externe](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) requis. En outre, l'utilisateur peut choisir de définir les balises `Department` et `Project` comme transitives.

**Example Politique d'approbation de rôle pour les balises de session**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowIamUserAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
              "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*",
                    "aws:RequestTag/Department": "*"
                },
                "StringEquals": {"sts:ExternalId": "Example987"}
            }
        },
        {
            "Sid": "AllowPassSessionTagsAndTransitive",
            "Effect": "Allow",
            "Action": "sts:TagSession",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*"
                },
                "StringEquals": {
                    "aws:RequestTag/Department": [
                        "Engineering",
                        "Marketing"
                    ]
                },
                "ForAllValues:StringEquals": {
                    "sts:TransitiveTagKeys": [
                        "Project",
                        "Department"
                    ]
                }
            }
        }
    ]
}
```

**À quoi sert cette politique ?**
+ La instruction `AllowIamUserAssumeRole` permet à l'utilisateur `test-session-tags` d'endosser le rôle auquel la politique est attachée. Lorsque cet utilisateur endosse le rôle, il doit passer les balises de session et l'[ID externe](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) requis.
  + Le premier bloc de condition de cette instruction nécessite que l'utilisateur transmette les balises de session `Project`, `CostCenter` et `Department`. Les valeurs de balise n'ont pas d'importance dans cette instruction, vous pouvez donc utiliser des caractères génériques (\$1) pour les valeurs de balise. Ce bloc garantit que l'utilisateur transmette au moins ces trois balises de session. Sinon, l’opération échoue. L'utilisateur peut transmettre des balises supplémentaires.
  + Le deuxième bloc de condition nécessite que l'utilisateur transmette un [ID externe](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) avec la valeur `Example987`.
+ L'instruction `AllowPassSessionTagsAndTransitive` autorise l'action d'autorisations `sts:TagSession`. Cette action doit être autorisée avant que l'utilisateur puisse transmettre des balises de session. Si votre politique inclut la première instruction sans la deuxième, l'utilisateur ne peut pas endosser le rôle.
  + Le premier bloc de condition de cette instruction permet à l'utilisateur de transmettre n'importe quelle valeur pour les balises de session `CostCenter` et `Project`. Pour ce faire, utilisez des caractères génériques (\$1) pour la valeur de balise dans la politique, ce qui nécessite l'utilisation de l'opérateur de [StringLike](reference_policies_elements_condition_operators.md#Conditions_String)condition.
  + Le deuxième bloc de condition permet à l'utilisateur de transmettre uniquement la valeur `Engineering` ou `Marketing` de la balise de session `Department`.
  + Le troisième bloc de condition répertorie l'ensemble maximal de balises que vous pouvez définir comme transitives. L'utilisateur peut choisir de définir un sous-ensemble ou aucune balise comme transitive. Il ne peut pas définir de balises supplémentaires comme transitives. Vous pouvez exiger qu'il définisse au moins une des balises comme transitive en ajoutant un autre bloc de condition qui inclut `"Null":{"sts:TransitiveTagKeys":"false"}`. 

## Transmission de balises de session en utilisant AssumeRole
<a name="id_session-tags_adding-assume-role"></a>

L'`AssumeRole`opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Vous pouvez utiliser l'utilisateur ou les informations d'identification du rôle IAM pour appeler `AssumeRole`. Pour transmettre des balises de session tout en assumant un rôle, utilisez l'`--tags` AWS CLI option ou le paramètre `Tags` AWS API. 

Pour définir les balises comme transitives, utilisez l'`--transitive-tag-keys` AWS CLI option ou le paramètre `TransitiveTagKeys` AWS API. Les balises transitives persistent pendant le chaînage des rôles. Pour plus d'informations, veuillez consulter [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining).

L'exemple suivant montre un exemple de demande qui utilise `AssumeRole`. Dans cet exemple, lorsque vous endossez le rôle `my-role-example`, vous créez une session nommée `my-session`. Vous ajoutez les paires clé-valeur de balise de session `Project` = `Automation`, `CostCenter` = `12345` et `Department` = `Engineering`. Vous définissez également les balises `Project` et `Department` comme transitives en spécifiant leurs clés. Vous devez transmettre une valeur unique pour chaque balise de session. AWS STS ne prend pas en charge les balises de session à valeurs multiples.

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/my-role-example \
--role-session-name my-session \
--tags Key=Project,Value=Automation Key=CostCenter,Value=12345 Key=Department,Value=Engineering \
--transitive-tag-keys Project Department \
--external-id Example987
```

## Transmission de balises de session à l'aide de AssumeRoleWith SAML
<a name="id_session-tags_adding-assume-role-saml"></a>

L'opération `AssumeRoleWithSAML` authentifie à l'aide de la fédération basée sur SAML. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Pour plus d'informations sur l'utilisation de la fédération basée sur SAML pour l' AWS Management Console accès, consultez. [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md) Pour plus de détails sur AWS CLI AWS l'accès à l'API, consultez[Fédération SAML 2.0](id_roles_providers_saml.md). Pour un didacticiel sur la configuration de la fédération SAML pour vos utilisateurs d'Active Directory, consultez la section [Authentification AWS fédérée avec les services de fédération Active Directory (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) dans le AWS blog de sécurité. 

En tant qu'administrateur, vous pouvez autoriser les membres du répertoire de votre entreprise à se fédérer pour AWS utiliser cette AWS STS `AssumeRoleWithSAML` opération. Pour ce faire, effectuez les tâches suivantes :

1. [Configurer votre réseau en tant que fournisseur SAML pour l'interface AWS](id_roles_providers_saml_3rd-party.md)

1. [Créer un fournisseur SAML dans IAM](id_roles_providers_create_saml.md)

1. [Création d’un rôle pour la fédération SAML 2.0 (console)](id_roles_create_for-idp_saml.md)

1. [Achever la configuration de l'IdP SAML et créer des assertions pour la réponse d'authentification SAML](id_roles_providers_create_saml_assertions.md)

AWS inclut des fournisseurs d'identité dotés d'une end-to-end expérience certifiée en matière de balises de session dans le cadre de leurs solutions d'identité. Pour savoir comment utiliser ces fournisseurs d'identité pour configurer des balises de session, veuillez consulter [Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md).

Pour transmettre les attributs SAML en tant que balises de session, incluez l'élément `Attribute` dont l'attribut `Name` est défini sur `https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}`. Utilisez l'élément `AttributeValue` pour spécifier la valeur de la balise. Incluez un élément `Attribute` distinct pour chaque balise de session.

Par exemple, supposons que vous souhaitez transmettre les attributs d'identité suivants en tant que balises de session :
+ `Project:Automation`
+ `CostCenter:12345`
+ `Department:Engineering`

Pour transmettre ces attributs, incluez les éléments suivants dans votre assertion SAML.

**Example Extrait d'une assertion SAML**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Automation</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department">
  <AttributeValue>Engineering</AttributeValue>
</Attribute>
```

Pour définir les balises précédentes ci-dessus comme transitives, incluez un autre élément `Attribute` dont l'attribut `Name` est défini sur `https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys`. Les balises transitives persistent pendant le chaînage des rôles. Pour plus d'informations, veuillez consulter [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining).

Pour définir les balises `Department` et `Project` comme transitives, utilisez l'attribut à valeurs multiples suivant :

**Example Extrait d'une assertion SAML**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>Department</AttributeValue>
</Attribute>
```

## Transmission de balises de session en utilisant AssumeRoleWithWebIdentity
<a name="id_session-tags_adding-assume-role-idp"></a>

Utilisez la fédération conforme à OpenID Connect (OIDC) pour authentifier l’opération `AssumeRoleWithWebIdentity`. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Pour plus d'informations sur l'utilisation de la fédération d'identité Web pour AWS Management Console l'accès, consultez[Fédération OIDC](id_roles_providers_oidc.md).

Pour transmettre les balises de session depuis OpenID Connect (OIDC), vous devez inclure les balises de session dans le JWT (JSON Web Token) lorsque vous soumettez la requête `AssumeRoleWithWebIdentity`. Pour en savoir plus sur les jetons OIDC et les revendications, veuillez consulter [Utilisation des jetons avec les groupes d'utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) dans le *Guide du développeur Amazon Cognito *.

AWS prend en charge deux formats de réclamation pour inclure des balises de session dans le JWT : 
+ Format de demande imbriqué
+ Format de demande aplati

### Format de demande imbriqué
<a name="id_session-tags_adding-assume-role-idp-nested-format"></a>

Le format de demande imbriqué utilise une structure au sein de l’espace de noms `https://aws.amazon.com/tags` du JWT. Dans ce format :
+ Les balises des principaux sont représentées sous la forme d’un objet imbriqué sous la clé `principal_tags`.
+ Chaque balise de principal est une valeur de chaîne unique.
+ Les clés de balise transitives sont représentées dans un tableau sous la clé `transitive_tag_keys`.
+ `principal_tags` et `transitive_tag_keys` sont imbriquées sous l’espace de noms `https://aws.amazon.com/tags`.

L’exemple suivant illustre un JWT décodé utilisant le format d’objet imbriqué : 

**Example Exemple de jeton Web JSON décodé utilisant le format de demande imbriqué**  

```
{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags": {
        "principal_tags": {
            "Project": ["Automation"],
            "CostCenter": ["987654"],
            "Department": ["Engineering"]
        },
        "transitive_tag_keys": [
            "Project",
            "CostCenter"
        ]
    }
}
```

### Format de demande aplati
<a name="id_session-tags_adding-assume-role-idp-flattened-format"></a>

Le format de demande aplati est compatible avec les fournisseurs d’identité qui ne prennent pas en charge les objets imbriqués dans les demandes JWT, tels que Microsoft Entra ID. Dans ce format :
+ Les balises de principaux sont représentées sous forme de demandes distinctes avec le préfixe `https://aws.amazon.com/tags/principal_tags/`. 
+ Chaque balise de principal est une valeur de chaîne unique.
+ Les clés de balise transitives sont représentées dans une seule demande sous la forme d’un tableau de chaînes avec le préfixe `https://aws.amazon.com/tags/transitive_tag_keys`.

Voyons maintenant comment les mêmes informations sont représentées à l’aide du format de demande aplati :

**Example Exemple de jeton Web JSON décodé utilisant le format de demande aplati**  

```
{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags/principal_tags/Project": "Automation",
    "https://aws.amazon.com/tags/principal_tags/CostCenter": "987654",
    "https://aws.amazon.com/tags/principal_tags/Department": "Engineering",
    "https://aws.amazon.com/tags/transitive_tag_keys": [
        "Project",
        "CostCenter"
    ]
}
```

Les deux exemples JWT décodés montrent un appel à `AssumeRoleWithWebIdentity` avec les balises de session `Project`, `CostCenter`, et `Department`. Les deux jetons définissent les balises `Project` et `CostCenter` comme transitives. Les balises transitives persistent pendant le chaînage des rôles. Pour de plus amples informations, veuillez consulter [Chaînage des rôles avec des balises de session](#id_session-tags_role-chaining).

Le format de demande aplati permet d’obtenir le même résultat que le format de demande imbriqué, mais utilise une structure aplatie pour les balises. Il vous permet d’inclure des balises de session dans des environnements où les objets JSON imbriqués ne sont pas pris en charge dans les demandes JWT. Lorsque vous utilisez l’un ou l’autre format, assurez-vous que votre fournisseur d’identité est configuré pour émettre des jetons avec les structures de demande appropriées. AWS prend en charge les deux formats de demande, de sorte que vous pouvez choisir celui qui répond le mieux aux exigences spécifiques de votre fournisseur d’identité.

## Transmission de balises de session en utilisant GetFederationToken
<a name="id_session-tags_adding-getfederationtoken"></a>

Le `GetFederationToken` vous permet de fédérer votre utilisateur. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Pour ajouter des balises à votre session utilisateur fédérée, utilisez l'`--tags` AWS CLI option ou le paramètre `Tags` AWS API. Vous ne pouvez pas définir les balises de session comme transitives lorsque vous utilisez le `GetFederationToken`, car vous ne pouvez pas utiliser les informations d'identification temporaires pour endosser un rôle. Vous ne pouvez pas utiliser le chaînage de rôles dans ce cas. 

Voici un exemple de réponse à l'aide de `GetFederationToken`. Dans cet exemple, lorsque vous demandez le jeton, vous créez une session nommée `my-fed-user`. Vous ajoutez les paires clé-valeur de la balise de session `Project` = `Automation` et `Department` = `Engineering`.

**Example Exemple de demande GetFederationToken CLI**  

```
aws sts get-federation-token \
--name my-fed-user \
--tags key=Project,value=Automation key=Department,value=Engineering
```

Lorsque vous utilisez les informations d'identification temporaires renvoyées par l'opération `GetFederationToken`, les balises principales de la session incluent les balises de l'utilisateur et les balises de session transmises.

## Chaînage des rôles avec des balises de session
<a name="id_session-tags_role-chaining"></a>

Vous pouvez endosser un rôle, puis utiliser les informations d'identification temporaires pour en endosser un autre. Vous pouvez continuer d'une session à une autre. C'est ce qu'on appelle le [chaînage des rôles](id_roles.md#iam-term-role-chaining). Lorsque vous transmettez des balises de session en endossant un rôle, vous pouvez définir les clés comme transitives. Cela garantit que ces balises de session sont transmises aux sessions suivantes dans une chaîne de rôles. Vous ne pouvez pas définir les balises de rôle comme transitives. Pour transmettre ces balises aux sessions suivantes, indiquez-les en tant que balises de session.

**Note**  
Les balises transitives persistent durant le chaînage des rôles et remplacent la mise en correspondance de valeurs `ResourceTag` après l’évaluation de la politique de confiance de rôle.

L'exemple suivant montre comment transmettre AWS STS les balises de session, les balises transitives et les balises de rôle aux sessions suivantes d'une chaîne de rôles.

Dans cet exemple de scénario de chaînage de rôles, vous utilisez une clé d'accès utilisateur IAM dans le AWS CLI pour assumer un rôle nommé. `Role1` Vous utilisez ensuite les informations d'identification de session résultantes pour endosser un second rôle nommé `Role2`. Vous pouvez ensuite utiliser les informations d'identification de la deuxième session pour endosser un troisième rôle nommé `Role3`. Ces demandes se déroulent sous la forme de trois opérations distinctes. Chaque rôle est déjà balisé dans IAM. Et lors de chaque demande, vous transmettez des balises de session supplémentaires.

![\[Création de chaînes de rôles\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/session-tags-chaining-simple.png)


Lorsque vous enchaînez des rôles, vous pouvez vous assurer que les balises d'une session antérieure persistent jusqu'aux sessions ultérieures. Pour ce faire à l'aide de la commande de la CLI `assume-role`, vous devez transmettre la balise en tant que balise de session et la définir comme transitive. Vous transmettez la balise `Star` = `1` en tant que balise de session. La commande attache également la balise `Heart` = `1` au rôle et s'applique en tant que balise principale lorsque vous utilisez la session. Cependant, vous voulez également que la balise `Heart` = `1` transmette automatiquement à la deuxième ou troisième session. Pour ce faire, vous l'incluez manuellement en tant que balise de session. Les balises de principal de session résultantes incluent ces deux balises et les définissent comme transitives.

![\[Endosser le premier rôle dans une chaîne de rôles\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/session-tags-chaining-role1.png)


Vous effectuez cette demande à l'aide de la AWS CLI commande suivante :

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role1 \
--role-session-name Session1 \
--tags Key=Star,Value=1 Key=Heart,Value=1 \
--transitive-tag-keys Star Heart
```

Vous utilisez ensuite les informations d'identification pour cette session pour endosser `Role2`. La commande attache la balise `Sun` = `2` au deuxième rôle et s'applique en tant que balise principale lorsque vous utilisez la deuxième session. Les balises `Heart` = `Star` héritent des balises de session transitive de la première session. Les balises principales résultantes de la deuxième session sont `Heart` = `1`, `Star` = `1` et `Sun` = `2`. `Heart` et `Star` continueront d'être transitives. La balise `Sun` attachée à `Role2` n'est pas marquée comme transitive, car il ne s'agit pas d'une balise de session. Les sessions futures n'héritent pas de cette balise. 

![\[Endosser le deuxième rôle dans une chaîne de rôles\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/session-tags-chaining-role2.png)


Vous effectuez cette deuxième demande à l'aide de la AWS CLI commande suivante :

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role2 \
--role-session-name Session2
```

Vous utilisez ensuite les informations d'identification de la deuxième session pour endosser `Role3`. Les balises principales de la troisième session proviennent de toutes les nouvelles balises de session, des balises de session transitive héritées et des balises de rôle. Les balises `Heart` = `1` et `Star` = `1` de la deuxième session ont été héritées de la balise de session transitive de la première session. Si vous essayez de transmettre la balise de session `Sun` = `2`, l'opération échoue. La balise de session `Star` = 1 héritée remplace la balise du rôle `Star` = `3`. Dans le chaînage des rôles, la valeur d’une balise transitive remplace le rôle correspondant à la valeur `ResourceTag` avant l’évaluation de la politique de confiance de rôle. Dans cet exemple, si `Role3` utilise `Star` en tant que `ResourceTag` dans la politique de confiance de rôle, et définit la valeur `ResourceTag` à la valeur de balise transitive à partir de la session de rôle appelant. La balise du rôle `Lightning` s'applique également à la troisième session et n'est pas définie comme transitive.

![\[Endosser le troisième rôle dans une chaîne de rôles\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/session-tags-chaining-role3.png)


Vous effectuez la troisième demande à l'aide de la AWS CLI commande suivante :

**Example Exemple de demande AssumeRole CLI**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role3 \
--role-session-name Session3
```

## Utilisation des balises de session pour ABAC
<a name="id_session-tags_using-abac"></a>

Le contrôle d'accès basé sur les attributs (ABAC) utilise une stratégie d'autorisation qui définit les autorisations en fonction des attributs de balise. 

Si votre entreprise utilise un fournisseur d'identité (IdP) basé sur OIDC ou SAML pour gérer les identités des utilisateurs, vous pouvez configurer votre assertion pour transmettre les balises de session à AWS. Par exemple, dans le cas des identités d'utilisateur d'entreprise, lorsque vos employés se fédérent dans AWS, leurs attributs sont AWS appliqués au principal qui en résulte. Vous pouvez ensuite utiliser l'ABAC pour autoriser ou refuser des autorisations sur la base de ces attributs. Pour en savoir plus, consultez [Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC](tutorial_abac-saml.md).

Pour plus d'informations sur l'utilisation d'IAM Identity Center avec ABAC, consultez la section [Attributs pour le contrôle d'accès](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributesforaccesscontrol.html) dans le *Guide de l'utilisateur de AWS IAM Identity Center *.

## Afficher les balises de session dans CloudTrail
<a name="id_session-tags_ctlogs"></a>

Vous pouvez l'utiliser AWS CloudTrail pour afficher les demandes utilisées pour assumer des rôles ou fédérer des utilisateurs. Le fichier journal CloudTrail contient des informations sur les balises principales de la session utilisateur endossée ou fédérée. Pour de plus amples informations, veuillez consulter [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md).

Supposons, par exemple, que vous fassiez une AWS STS `AssumeRoleWithSAML` demande, que vous transmettiez des balises de session et que vous définissiez ces balises comme transitives. Vous trouverez les informations suivantes dans votre journal CloudTrail .

**Example Exemple de AssumeRoleWith journal SAML CloudTrail**  

```
    "requestParameters": {
        "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE",
        "roleSessionName": "MyRoleSessionName",
        "principalTags": {
            "CostCenter": "987654",
            "Project": "Unicorn"
        },
        "transitiveTagKeys": [
            "CostCenter",
            "Project"
        ],
        "durationSeconds": 3600,
        "roleArn": "arn:aws:iam::123456789012:role/SAMLTestRoleShibboleth",
        "principalArn": "arn:aws:iam::123456789012:saml-provider/Shibboleth"
    },
```

Vous pouvez consulter les exemples de CloudTrail journaux suivants pour visualiser les événements utilisant des balises de session.
+ [Exemple d'événement d'API de chaînage de AWS STS rôles dans un fichier CloudTrail journal](cloudtrail-integration.md#stscloudtrailexample-assumerole)
+ [Exemple d'événement d' AWS STS API SAML dans un fichier CloudTrail journal](cloudtrail-integration.md#stscloudtrailexample_saml)
+ [Exemple d'événement d' AWS STS API OIDC dans un fichier CloudTrail journal](cloudtrail-integration.md#stscloudtrailexample_web-identity)