Comment utiliser un identifiant externe lorsque vous accordez l'accès à vos AWS ressources à un tiers - AWS Identity and Access Management

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.

Comment utiliser un identifiant externe lorsque vous accordez l'accès à vos AWS ressources à un tiers

Vous devez parfois autoriser un tiers à accéder à vos AWS ressources (accès délégué). Un aspect important de ce scénario est l'ID externe, informations facultatives que vous pouvez utiliser dans une politique d'approbation des rôles IAM afin de désigner l'utilisateur autorisé à endosser le rôle.

Important

AWS ne traite pas l'identifiant externe comme un secret. Une fois que vous avez créé un secret, tel qu'une paire de clés d'accès ou un mot de passe AWS, vous ne pouvez plus le consulter. L'ID externe d'un rôle peut être vu par n'importe qui ayant l'autorisation de consulter le rôle.

Dans un environnement mutualisé où vous prenez en charge plusieurs clients avec différents AWS comptes, nous vous recommandons d'utiliser un identifiant externe par Compte AWS client. Cet ID doit être une chaîne aléatoire générée par le tiers.

Pour exiger que le tiers fournisse un ID externe lors de la prise en charge d'un rôle, mettez à jour la politique d'approbation du rôle avec l'ID externe de votre choix.

Pour fournir un identifiant externe lorsque vous assumez un rôle, utilisez l' AWS API AWS CLI or pour assumer ce rôle. Pour plus d'informations, consultez l'opération de l'AssumeRoleAPI STS ou l'opération de la CLI STS assume-role.

Supposons, par exemple, que vous décidiez de faire appel à une société tierce appelée Example Corp pour surveiller vos coûts Compte AWS et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Example Corp surveille également de nombreux autres comptes AWS pour d'autres clients.

Ne donnez pas à Exemple Corp l'accès à un utilisateur IAM et à ses informations d'identification à long terme dans votre compte AWS . Utilisez plutôt un rôle IAM et ses informations d'identification de sécurité temporaires. Un rôle IAM fournit un mécanisme permettant à un tiers d'accéder à vos AWS ressources sans avoir à partager des informations d'identification à long terme (telles qu'une clé d'accès utilisateur IAM).

Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre compte Compte AWS et le compte Example Corp. Une fois cette relation établie, un membre du compte Example Corp peut appeler l' AWS Security Token Service AssumeRoleAPI pour obtenir des informations d'identification de sécurité temporaires. Les membres d'Example Corp peuvent ensuite utiliser les informations d'identification pour accéder aux AWS ressources de votre compte.

Note

Pour plus d'informations sur les opérations d' AWS API AssumeRole et sur les autres opérations que vous pouvez appeler pour obtenir des informations d'identification de sécurité temporaires, consultezDemande d'informations d'identification temporaires de sécurité.

Voici comment s'articule ce scénario :

  1. Vous embauchez Example Corp qui crée un identifiant client unique pour vous. Ils vous fournissent cet identifiant client unique et leur Compte AWS numéro. Vous avez besoin de ces informations pour créer un rôle IAM à l'étape suivante.

    Note

    Example Corp peut utiliser n'importe quelle valeur de chaîne pour le ExternalId, à condition qu'elle soit unique pour chaque client. Il peut s'agir d'un numéro de compte client ou encore d'une chaîne aléatoire de caractères, à condition que chaque client ait une valeur différente. Elle n'est pas censée être « secrète ». Example Corp doit fournir la ExternalId valeur à chaque client. Ce qui compte, c'est qu'elle soit générée par Example Corp et non par ses clients afin de garantir que chaque ID externe est unique.

  2. Vous vous connectez AWS et créez un rôle IAM qui permet à Example Corp d'accéder à vos ressources. Comme tout autre rôle IAM, celui-ci dispose de deux politiques, une politique d'autorisation et une politique d'approbation. La politique d'approbation du rôle spécifie qui peut endosser le rôle. Dans notre exemple de scénario, la politique spécifie le Compte AWS nombre d'Example Corp comme étant lePrincipal. Cela permet aux identités de ce compte d'endosser le rôle. En outre, vous ajoutez un élément Condition à la politique d'approbation. Cette Condition teste la clé de contexte ExternalId afin de s'assurer qu'elle correspond à l'ID client unique issu d'Exemple Corp. Exemple :

    "Principal": {"AWS": "Example Corp's Compte AWS ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. La politique d'autorisation du rôle spécifie ce que le rôle permet à un utilisateur de faire. Par exemple, vous pouvez spécifier que le rôle permet à un utilisateur de gérer uniquement vos ressources Amazon EC2 et Amazon RDS, mais pas vos utilisateurs ou groupes IAM. Dans notre exemple de scénario, vous utilisez la politique d'autorisation pour accorder à Example Corp un accès en lecture seule à toutes les ressources de votre compte.

  4. Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle à Example Corp.

  5. Lorsque Example Corp a besoin d'accéder à vos AWS ressources, un membre de l'entreprise appelle l' AWS sts:AssumeRoleAPI. L'appel inclut l'ARN du rôle à assumer et le ExternalId paramètre correspondant à leur identifiant client.

Si la demande provient d'une personne utilisant Example Corp Compte AWS, et si l'ARN du rôle et l'ID externe sont corrects, la demande aboutit. Il fournit ensuite des informations de sécurité temporaires qu'Example Corp peut utiliser pour accéder aux AWS ressources autorisées par votre rôle.

Autrement dit, quand une politique de rôle inclut un ID externe, tous ceux qui souhaitent endosser le rôle doivent non seulement être spécifiés comme principaux dans le rôle, mais également inclure l'ID externe correct.

Pourquoi utiliser un ID externe ?

De manière abstraite, l'ID externe autorise l'utilisateur qui endosse le rôle d'indiquer les circonstances dans lesquels il travaille. Il permet également au titulaire du compte d'autoriser que le rôle soit endossé uniquement dans des circonstances spécifiques. La fonction principale de l'ID externe consiste à traiter et à prévenir Le problème de l'adjoint confus.

Quand est-il conseillé d'utiliser un ID externe ?

Utilisez un ID externe dans les situations suivantes :

  • Vous êtes Compte AWS propriétaire et vous avez configuré un rôle pour un tiers qui accède Comptes AWS à d'autres rôles que le vôtre. Vous devez demander à ce tiers un ID externe qu'il inclura lorsqu'il endossera votre rôle. Ensuite, vous vérifiez cet ID externe dans la politique d'approbation de votre rôle. Ainsi, la tierce partie peut endosser votre rôle uniquement lorsqu'elle agit en votre nom.

  • Vous êtes en position d'endosser des rôles pour le compte de différents clients comme Exemple Corp dans notre précédent scénario. Vous devez attribuer un ID externe unique à chaque client et leur demander de l'ajouter à leur politique d'approbation du rôle. Vous devez ensuite vous assurer de toujours inclure l'ID externe correct dans vos demandes pour endosser des rôles.

    Vous disposez probablement déjà d'un identifiant unique pour chacun de vos clients, et cet ID unique est suffisant pour être utilisé comme ID externe. L'ID externe n'est pas une valeur spéciale que vous devez créer de manière explicite, ou suivre séparément, juste à cette fin.

    Vous devez toujours spécifier l'ID externe dans vos appels d'API AssumeRole. De plus, lorsqu'un client vous fournit un ARN de rôle, vérifiez que vous pouvez endosser le rôle avec et sans l'ID externe correct. Si vous pouvez endosser le rôle sans l'ID externe approprié, ne stockez pas l'ARN du rôle du client dans votre système. Attendez que le client mette à jour la politique d'approbation du rôle pour demander l'ID externe. Ainsi, vous aidez vos clients à faire ce qu'il faut, ce qui vous permet de vous protéger tous les deux contre le problème du député confus.