Octroi d'autorisations à un utilisateur pour endosser un rôle - AWS Identity and Access Management

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

Lorsqu'un administrateur crée un rôle pour un accès entre comptes, 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 de confiance spécifie le numéro du compte approuvé en tant que Principal dans la politique de confiance 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 octroyer à un utilisateur l'autorisation d'endosser un rôle, l'administrateur du compte approuvé crée une nouvelle politique pour l'utilisateur. Ou bien l'administrateur peut modifier une politique existante afin d'ajouter les éléments requis. L'administrateur peut ensuite envoyer à l'utilisateur un lien qui le dirige vers la page Switch Role (Changer de rôle) dans laquelle tous les détails sont déjà remplis. Sinon, l'administrateur peut lui fournir l'ID ou l'alias du compte contenant le rôle, ainsi que le nom du rôle. L'utilisateur accède ensuite à la page Switch Role (Changer de rôle) et ajoute les détails manuellement. Pour plus d'informations sur la façon dont un utilisateur endosse un rôle, consultez Changement de rôle (console).

Notez que pour endosser un rôle, vous devez être connecté en tant qu'utilisateur IAM. Vous ne pouvez pas changer de rôle lorsque vous vous connectez en tant qu'utilisateur racine Compte AWS.

Important

Vous ne pouvez pas passer d'un rôle qui se trouve dans AWS Management Console à un rôle qui requiert une valeur ExternalId. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API AssumeRole qui prend en charge le paramètre ExternalId.

Notes
  • Cette rubrique décrit les politiques applicables à un utilisateur car au final, nous accordons des autorisations à un utilisateur pour lui permettre d'effectuer une tâche. Toutefois, la bonne pratique consiste à ne pas accorder d'autorisations directement à un utilisateur individuel. Pour faciliter la gestion, il est recommandé d'affecter des politiques et d'accorder des autorisations à des groupes IAM, puis de faire de ces utilisateurs des membres des groupes appropriés.

  • Lorsque vous changez de rôles dans AWS Management Console, la console continue d'utiliser les 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, les informations d'identification d'utilisateur ou du rôle fédéré d'origine déterminent si vous êtes autorisé à endosser 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

Cela est illustré dans l'exemple suivant. Les utilisateurs disposant de la politique (via l'appartenance à un groupe ou par la politique directement attachée) sont autorisés à endosser le rôle spécifié.

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 la tâche aux utilisateurs, vous pouvez leur envoyer un lien préconfiguré contenant l'ID du compte et le nom du rôle. Le lien est fourni sur la page finale de l'assistant Créer un rôle ou sur la page Résumé du rôle pour n'importe quel rôle entre 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.

Considerations

  • Si vous créez le rôle par programmation, vous pouvez créer le rôle avec un chemin en plus d'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 élément Path de 512 caractères au maximum en plus de l'élément RoleName. Le nom du rôle peut comporter jusqu'à 64 caractères. Toutefois, pour utiliser un rôle avec la fonction Switch Role (Changer de rôle) dans la AWS Management Console, l'ensemble Path et RoleName ne doit pas comporter plus de 64 caractères.

  • Pour des raisons de sécurité, vous pouvez consulter les journaux AWS CloudTrail 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. 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.