Octroyer l'accès à un utilisateur IAM dans un autre Compte AWS vous appartenant

Vous pouvez accorder à vos utilisateurs IAM l'autorisation de basculer vers des rôles dans votre propre Compte AWS ou vers des rôles définis dans d'autres Comptes AWS vous appartenant.

Note

Si vous souhaitez accorder l'accès à un compte que ne vous appartenant pas ou que vous ne contrôlez pas, consultez Octroyer un accès à des Comptes AWS appartenant à des tierces parties 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 d' AWS Management Console ou assumer le rôle à l'aide de l'AWS CLI ou de l'API AWS.

• 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 Configuration de l'accès aux API protégé par MFA.

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 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 ?.

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

Imaginons que votre organisation 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.

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 la console AWS) ou l'Amazon Resource Name (ARN) (pour l'accès à l'aide de l’interface AWS CLI ou de l'API AWS). 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 Configuration de l'accès aux API protégé par MFA.

2. Dans le compte de développement, un administrateur accorde aux membres du groupe Développeurs l'autorisation de changer de rôle. Pour cela, il accorde au groupe Développeurs l'autorisation d'appeler l'API AWS Security Token Service (AWS STS) AssumeRole du rôle UpdateApp. 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.

3. L'utilisateur demande les changements de rôle :

   • Console AWS : l'utilisateur choisit le nom du compte sur la barre de navigation et choisit Changer de rôle. 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.

   • API AWS/AWS CLI : Un utilisateur appartenant au groupe Développeurs du compte de développement appelle la fonction AssumeRole pour obtenir les informations d'identification du rôle UpdateApp. 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.

4. AWS STS renvoie les informations d'identification temporaires :

   • Console AWS : AWS STS vérifie la demande par rapport à la politique d'approbation du rôle pour s'assurer que la demande est émise par une entité approuvée (ce qui est le cas : le compte de développement). Après vérification, AWS STS renvoie les informations d'identification de sécurité temporaires à la console AWS.

   • API/CLI : AWS STS vérifie la demande par rapport à la politique d'approbation du rôle pour s'assurer que la demande est émise par une entité approuvée (ce qui est le cas : le compte Développement). Après vérification, AWS STS renvoie les informations d'identification de sécurité temporaires à l'application.

5. Les informations d'identification temporaires autorisent l'accès à la ressource AWS :

   • Console AWS : La console AWS utilise les informations d'identification temporaires pour le compte de l'utilisateur pour toutes les actions suivantes sur la console, afin de lire et d'écrire dans le compartiment productionapp. 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.

En savoir plus

Pour plus d'informations, consultez les ressources suivantes :

• Didacticiel IAM : déléguer l'accès entre des comptes AWS à l'aide des rôles IAM