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

Octroi d'autorisations à un utilisateur pour changer de rôle

Lorsqu'un administrateur crée un rôle pour l'accès inter-comptes, il établit l'approbation entre le compte qui possède le rôle et les ressources (compte d'approbation) et celui qui contient les utilisateurs (compte approuvé). Pour ce faire, l'administrateur du compte d'approbation spécifie le numéro de compte approuvé en tant que Principal dans la stratégie d'approbation du rôle. Cela permet potentiellement à n'importe quel utilisateur du compte approuvé d'assumer le rôle. Pour achever la configuration, l'administrateur du compte approuvé doit accorder l'autorisation d'assumer ce rôle à des groupes ou utilisateurs spécifiques du compte.

Pour accorder à un utilisateur l'autorisation de basculer vers un rôle, l'administrateur du compte approuvé crée une nouvelle stratégie pour l'utilisateur. L'administrateur peut également modifier une stratégie existante pour ajouter les éléments requis. L'administrateur peut ensuite envoyer à l'utilisateur un lien qui le dirige vers la page 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 assume un rôle, consultez Changement de rôle (console).

Notez que pour assumer 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 d'un 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.

Remarques
  • Cette rubrique décrit les stratégies 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 stratégies 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é à 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, et non celles de RoleA.

Création ou modification de la stratégie

Une stratégie 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 stratégie (via l'appartenance à un groupe ou par la stratégie directement attachée) sont autorisés à assumer le rôle spécifié.

Note

Si la valeur Resource est définie sur *, l'utilisateur peut assumer n'importe quel rôle dans n'importe quel compte qui approuve le compte de l'utilisateur. (En d'autres termes, la stratégie d'approbation du rôle spécifie le compte de l'utilisateur comme 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 stratégie qui permet à l'utilisateur d'endosser des rôles dans un seul compte. En outre, la stratégie 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-WITHOUT-HYPHENS: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 assume 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 stratégie 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 envoyer vos utilisateurs vers la rubrique Changement de rôle (console) pour les guider tout au long du processus.

Considérations

  • Si vous créez le rôle par programme, vous pouvez utiliser un chemin d'accès 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) d'AWS Management Console. Par exemple : division_abc/subdivision_efg/role_XYZ.

  • Si vous créez le rôle par programme, vous pouvez ajouter une valeur Path maximale de 512 caractères en plus d'un attribut RoleName. La longueur maximale du nom de rôle est de 64 caractères. Toutefois, pour utiliser un rôle avec la fonction Change de rôle dans la AWS Management Console, Path et RoleName combinés ne doivent 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 aws:RoleSessionName dans la stratégie d'approbation de rôle pour exiger des utilisateurs qu'ils spécifient un nom de session lorsqu'ils assument un rôle. Par exemple, vous pouvez exiger que les utilisateurs IAM spécifient leur propre nom d'utilisateur comme nom de session. Pour de plus amples informations, consultez aws:RoleSessionName.