Octroi d'autorisations à un utilisateur pour endosser un rôle - AWS Identity and Access Management
Création ou modification de la politiqueFourniture d'informations à l'utilisateur

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.

Octroi d'autorisations à un utilisateur pour endosser un rôle

Lorsqu'un administrateur crée un rôle pour un accès intercompte, 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 plus de détails, consultez Création ou modification de la politique.

  2. 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 plus de détails, consultez Fourniture d'informations à l'utilisateur.

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 ExternalIdvaleur. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API AssumeRole 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.

Création ou modification de la politique

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 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 (*) pour spécifier que l'utilisateur ne peut passer à un rôle que si le nom du rôle commence par les lettres Test.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::account-id: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

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 Changement de rôle (console) 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.

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 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 plus d’informations, consultez sts:SourceIdentity. Vous pouvez utiliser sts: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.