Accès à des Comptes AWS sites appartenant à des tiers - AWS Gestion de l’identité et des accès

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 à des Comptes AWS sites appartenant à des tiers

Lorsque des tiers ont besoin d'accéder aux AWS ressources de votre organisation, vous pouvez utiliser des rôles pour leur déléguer l'accès. Par exemple, un tiers peut fournir un service de gestion de vos ressources AWS . Grâce aux IAM rôles, vous pouvez autoriser ces tiers à accéder à vos AWS ressources sans partager vos informations AWS de sécurité. Au lieu de cela, le tiers peut accéder à vos AWS ressources en assumant un rôle que vous créez dans votre Compte AWS. 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 ? .

Les tiers doivent vous fournir les informations suivantes pour vous permettre de créer un rôle qu'ils peuvent endosser :

  • L' Compte AWS identifiant du tiers. Vous spécifiez leur ID d' Compte AWS en tant que principal lorsque vous définissez la politique d'approbation pour le rôle.

  • Un identifiant externe à associer de manière unique au rôle. L'ID externe peut être n'importe quel identifiant qui n'est connu que de vous et de la tierce partie. Par exemple, vous pouvez utiliser un ID de facture entre les tiers et vous-même, mais n'utilisez aucun élément pouvant être deviné, tels que le nom ou le numéro de téléphone du tiers. Vous devez spécifier cet ID lorsque vous définissez la politique d'approbation pour le rôle. Les tiers doivent fournir cette ID lorsqu'ils endosser le rôle.

  • Les autorisations dont le tiers a besoin pour utiliser vos AWS ressources. Vous devez spécifier ces autorisations lors de la définition de la politique d'autorisation du rôle. Cette politique définit les actions que les utilisateurs tiers peuvent entreprendre et les ressources auxquelles ils peuvent accéder.

Après avoir créé le rôle, vous devez fournir le nom de ressource Amazon du rôle (ARN) au tiers. Ils ont besoin de votre ARN rôle pour pouvoir l'assumer.

Important

Lorsque vous accordez à des tiers l'accès à vos AWS ressources, ils peuvent accéder à toutes les ressources que vous spécifiez dans la politique. L'utilisation de vos ressources par ces tiers vous est facturée. Veillez à limiter leur utilisation de vos ressources de façon appropriée.

IDsExterne pour accès par des tiers

Un identifiant externe permet à l'utilisateur qui assume le rôle d'affirmer les circonstances dans lesquelles il opère. 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.

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.

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'identifiant externe lors de vos AssumeRole API appels. En outre, lorsqu'un client vous attribue un rôleARN, vérifiez si vous pouvez assumer ce rôle avec ou sans le bon identifiant externe. Si vous pouvez assumer le rôle sans l'identifiant externe approprié, ne stockez pas le rôle du client ARN 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.

Exemple de scénario utilisant un identifiant externe

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 à Example Corp l'accès à un IAM utilisateur et à ses informations d'identification à long terme sur votre AWS compte. Utilisez plutôt un IAM rôle et ses informations de sécurité temporaires. Un IAM rôle 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é IAM d'accès utilisateur).

Vous pouvez utiliser un IAM rôle 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 le AWS Security Token Service AssumeRoleAPIpour 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 AssumeRole et les autres AWS API opérations que vous pouvez effectuer pour obtenir des informations d'identification de sécurité temporaires, consultezComparez les AWS STS informations d'identification.

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 IAM rôle à 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 IAM rôle qui permet à Example Corp d'accéder à vos ressources. Comme tout IAM rôle, il possède deux politiques, une politique d'autorisation et une politique de confiance. 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 à quelqu'un de gérer uniquement vos RDS ressources Amazon EC2 et Amazon, mais pas vos IAM utilisateurs ou vos groupes. 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 fournissez le nom de ressource Amazon (ARN) du rôle à Example Corp.

  5. Lorsque Example Corp a besoin d'accéder à vos AWS ressources, un membre de l'entreprise appelle le AWS sts:AssumeRoleAPI. L'appel inclut ARN le 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 le rôle ARN 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.

Points clés pour l'extérieur IDs

  • 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 le AWS CLI ou AWS API pour assumer ce rôle. Pour plus d'informations, consultez l'STSAssumeRoleAPIopération ou l'opération STS assume-rôleCLI.

Ressources supplémentaires

Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d'accès à des Comptes AWS sites appartenant à des tiers.