Accès pour un IAM utilisateur à un autre utilisateur Compte AWS que vous possédez

Vous pouvez autoriser vos IAM utilisateurs à passer à des rôles au sein du vôtre 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'EC2instances 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 du AWS Management Console ou assumer le rôle à l'aide du AWS CLI ou AWS API.

• Vous pouvez ajouter une protection d'authentification multifactorielle (MFA) au rôle afin que seuls les utilisateurs qui se connectent avec un MFA appareil puissent assumer le rôle. Pour savoir comment configurer un rôle afin que les utilisateurs qui assument le rôle soient d'abord authentifiés à l'aide de l'authentification multifactorielle (MFA), voir. APIAccès sécurisé 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 responsables de comptes situés en dehors de votre zone de confiance (organisation de confiance ou compte) ont accès à vos rôles, voir Qu'est-ce qu'IAMAccess 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.

1. Dans le compte de production, un IAM administrateur crée le UpdateApp rôle 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 la ressource Amazon (ARN) (pour AWS CLI ou pour AWS API l'accès). Le rôle ARN peut ressembler arn:aws:iam::123456789012:role/UpdateApp à l'endroit où le rôle est nommé UpdateApp et où le rôle a été créé sous le numéro de compte 123456789012.

   Note

   L'administrateur peut éventuellement configurer le rôle de telle sorte que les utilisateurs qui assument le rôle doivent d'abord être authentifiés à l'aide de l'authentification multifactorielle ()MFA. Pour de plus amples informations, veuillez consulter APIAccès sécurisé 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 des développeurs l'autorisation d'appeler le AWS Security Token Service (AWS STS) AssumeRole API pour le UpdateApp rôle. Tout IAM utilisateur appartenant au groupe Développeurs dans le compte de développement peut désormais passer au UpdateApp rôle dans le 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 ARN le UpdateApp rôle dans le cadre de l'appel. Si un utilisateur du groupe Testeurs fait la même demande, celle-ci échoue car les testeurs ne sont pas autorisés à appeler AssumeRole pour le UpdateApp rôleARN.

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 d'identification 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 productionapp compartiment. 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'est pas obligée de quitter le rôle, mais cesse d'utiliser les informations d'identification temporaires et utilise les informations d'identification d'origine lors des API appels suivants.

Ressources supplémentaires

Pour plus d’informations, consultez les ressources suivantes :

• IAMtutoriel : Déléguer l'accès à travers AWS comptes utilisant des IAM rôles