Accès pour un utilisateur IAM dans un autre Compte AWS vous appartenant - AWS Identity and Access Management
Exemple de scénario utilisant des comptes de développement et de production distinctsRessources supplémentaires

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.

Accès pour un utilisateur IAM dans un autre Compte AWS vous appartenant

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 ultérieurement dans cette rubrique.

Imaginez que vous disposez d' EC2 instances Amazon essentielles 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.

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

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

  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.

  2. 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'AssumeRoleAPI 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.

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

  4. 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 de sécurité temporaires à 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 à l'application.

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

Pour plus d’informations, consultez les ressources suivantes :