AWS Identity and Access Management
Guide de l'utilisateur

Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS à un tiers

Parfois, vous devez accorder à des tiers l'accès à vos ressources AWS (déléguer l'accès). Un aspect important de ce scénario est l'ID externe. Il s'agit d'une information facultative que vous pouvez utiliser dans une stratégie d'approbation de rôle IAM afin de désigner l'utilisateur autorisé à assumer le rôle.

Important

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

Par exemple, disons que vous décidez d'embaucher une entreprise tierce appelée Example Corp pour surveiller votre compte AWS et vous aider à optimiser les coûts. Pour effectuer le suivi de vos dépenses quotidiennes, Example Corp doit accéder à vos ressources AWS. 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 visant à autoriser un tiers à accéder à vos ressources AWS sans avoir besoin de communiquer vos informations d'identification à long terme (par exemple, une clé d'accès d'utilisateur IAM).

Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre compte AWS; et le compte Exemple Corp. Une fois cette relation établie, un membre du compte Exemple Corp peut appeler l'API AWS STS AssumeRole pour obtenir des informations d'identification de sécurité temporaires. Il peut ensuite s'en servir pour accéder aux ressources AWS de votre compte.

Note

Pour plus d'informations sur AssumeRole et sur les autres opérations d'API AWS que vous pouvez appeler pour obtenir des informations d'identification temporaires, consultez Obtention 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 votre ID client unique et leur numéro de compte AWS. Vous avez besoin de ces informations pour créer un rôle IAM à l'étape suivante.

    Note

    Exemple Corp peut utiliser n'importe quelle valeur de chaîne pour l'ExternalId, tant qu'elle est 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 valeur ExternalId à chaque client. Ce qui compte, c'est qu'elle soit générée par Example Corp et non par ses clients.

  2. Vous vous connectez à AWS et vous créez un rôle IAM qui accorde à Example Corp l'accès à vos ressources. Comme tout autre rôle IAM, celui-ci dispose de deux stratégies, une stratégie d'autorisation et une stratégie d'approbation. La stratégie d'approbation du rôle spécifie qui peut assumer le rôle. Dans notre exemple de scénario, la stratégie spécifie le numéro de compte AWS d'Example Corp comme Principal. Cela permet aux identités de ce compte d'assumer le rôle. En outre, vous ajoutez un élément Condition à la stratégie 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. Par exemple :

    "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. La stratégie 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 stratégie 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 doit accéder à vos ressources AWS, quelqu'un de l'entreprise appelle l'API AWS sts:AssumeRole. L'appel inclut l'ARN du rôle à assumer et le paramètre ExternalID qui correspond à son ID client.

Si la demande émane d'une personne utilisant le compte AWS d'Example Corp et que l'ARN du rôle et l'ID externe sont corrects, la demande aboutit. Elle fournit alors des informations d'identification de sécurité temporaires que le membre d'Example Corp peut utiliser pour accéder aux ressources AWS autorisées par le rôle.

Autrement dit, quand une stratégie de rôle inclut un ID externe, tous ceux qui souhaitent assumer le rôle doivent non seulement être spécifiés comme mandataires 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 assume 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 assumé uniquement dans des circonstances spécifiques. La fonction principale de l'ID externe consiste à traiter et à prévenir le problème du « député confus ».

Le problème du député confus

Pour continuer avec l'exemple précédent, Example Corp a besoin d'accéder à certaines ressources de votre compte AWS. Mais, en plus de vous, Example Corp a d'autres clients et doit trouver un moyen d'accéder aux ressources AWS de chaque client. Plutôt que demander à ses clients leurs clés d'accès au compte AWS, qui sont des secrets à ne jamais révéler, Example Corp demande un ARN de rôle à chacun de ses clients. Cependant, un autre client d'Exemple Corp pourrait deviner ou obtenir votre rôle ARN. Il pourrait alors utiliser votre rôle ARN pour accéder à vos ressources AWS par le biais d'Example Corp. Cette forme d'escalade d'autorisation est appelée le « problème du député confus ».

Le graphique suivant illustre le problème du député confus.


            Description d'un problème de député confus.

Ce diagramme suppose ce qui suit :

  • AWS1 est votre compte AWS.

  • AWS1:ExampleRole est un rôle de votre compte. La stratégie d'approbation du rôle approuve Example Corp en désignant le compte AWS d'Example Corp comme celui qui peut assumer le rôle.

Voici ce qui se produit :

  1. Lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN AWS1:ExampleRole à Example Corp.

  2. Example Corp utilise cet ARN de rôle pour obtenir des informations d'identification de sécurité temporaires pour accéder aux ressources de votre compte AWS. Ainsi, vous approuvez Example Corp en tant que « député » autorisé à agir pour votre compte.

  3. Un autre client AWS commence également à utiliser les services d'Example Corp et ce client fournit également l'ARN de AWS1:ExampleRole pour que Example Corp l'utilise. Supposons que l'autre client apprenne ou devine AWS1:ExampleRole, qui n'est pas secret.

  4. Lorsque l'autre client demande à Example Corp d'accéder aux ressources AWS de (ce qu'il prétend être) son compte, Example Corp utilise AWS1:ExampleRole pour accéder aux ressources de votre compte.

C'est ainsi que l'autre client peut obtenir un accès non autorisé à vos ressources. Du fait que cet autre client a été en mesure de tromper Example Corp pour agir involontairement sur vos ressources, Example Corp est à présent un « député confus ».

Comment l'ID externe empêche-t-il le problème du député confus ?

Pour traiter le problème du député confus, vous incluez le contrôle de la condition ExternalId dans la stratégie d'approbation du rôle. L'entreprise « député » insert la valeur d'un ID externe unique pour chaque client dans la demande informations d'identification AWS. L'ID externe est une valeur d'ID client qui doit être unique pour chaque client d'Example Corp et être hors de portée des clients d'Example Corp. C'est pourquoi vous l'obtenez d'Example Corp et que vous ne créez pas le vôtre. Cela permet d'empêcher un client d'usurper l'identité d'un autre client. Example Corp insère toujours l'ID externe affecté au client, afin que vous ne receviez jamais de demande d'Example Corp avec un ID externe autre que le vôtre.

Dans notre scénario, imaginez que l'identifiant unique d'Example Corp pour vous soit « 12345 », et que son identifiant pour l'autre client soit « 67890 ». Ces identifiants sont simplifiés pour ce scénario. En général, ces identifiants sont des GUID. Supposons que ces identifiants sont uniques pour chaque client d'Example Corp, ils constituent des valeurs sensibles à utiliser pour l'ID externe.

Example Corp vous attribue la valeur d'ID externe « 12345 ». Vous devez ensuite ajouter un élément Condition à la stratégie d'approbation du rôle qui nécessite que la valeur de sts:ExternalId soit 12345, comme suit :

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "12345"}} } }

L'élément Condition de cette stratégie autorise Example Corp à assumer le rôle uniquement si l'appel d'API AssumeRole inclut la valeur d'ID externe « 12345 ». Example Corp s'assure que chaque fois qu'elle assume un rôle pour le compte d'un client, elle inclut toujours la valeur d'ID externe de ce client dans l'appel AssumeRole. Même si un autre client fournit à Example Corp votre ARN, il ne peut pas contrôler l'ID externe qu'Example Corp inclut dans sa demande à AWS. Cela permet d'éviter qu'un client non autorisé obtienne l'accès à vos ressources, comme dans le schéma suivant.


            Procédure pour résoudre un problème de député confus.
  1. Comme précédemment, lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN de AWS1:ExampleRole à Example Corp.

  2. Lorsque Example Corp utilise cet ARN de rôle pour assumer le rôle AWS1:ExampleRole, Example Corp inclut votre ID externe (« 12345 ») dans l'appel d'API AssumeRole. Cet ID externe correspond à la stratégie d'approbation du rôle, afin que l'appel d'API AssumeRole et Example Corp obtiennent des informations d'identification de sécurité temporaires permettant d'accéder aux ressources de votre compte AWS.

  3. Un autre client AWS commence également à utiliser les services d'Example Corp et, comme précédemment, ce client fournit également l'ARN de AWS1:ExampleRole pour que Example Corp l'utilise.

  4. Mais cette fois, quand Example Corp tente d'assumer le rôle AWS1:ExampleRole, elle fournit l'ID externe associé à l'autre client (« 67890 »). L'autre client est dans l'impossibilité de changer cela. Example Corp procède ainsi, car la demande pour utiliser le rôle provient de l'autre client, « 67890 » indique donc les circonstances dans lesquelles Example Corp agit. Étant donné que vous avez ajouté une condition avec votre propre ID externe (« 12345") à la stratégie d'approbation de AWS1 : ExampleRole, l'appel de l'API AssumeRole échoue. L'autre client se voit refuser l'autorisation d'accéder aux ressources de votre compte (indiqué par la croix « X » rouge dans le diagramme).

L'ID externe permet empêcher tout autre client de tromper Example Corp pour accéder involontairement à vos ressources : cela résout le problème de « député confus ».

Quand dois-je utiliser l'ID externe ?

Utilisez un ID externe dans les situations suivantes :

  • Vous êtes propriétaire d'un compte AWS et vous avez configuré un rôle afin de permettre à un tiers d'accéder à d'autres comptes AWS en plus du 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 stratégie 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'assumer 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 stratégie d'approbation du rôle. Vous devez ensuite vous assurer de toujours inclure l'ID externe correct dans vos demandes pour assumer 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 assumer 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 stratégie 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.