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. # Scénarios courants de rôles IAM Scénarios courants Comme pour la plupart des AWS fonctionnalités, vous pouvez généralement utiliser un rôle de deux manières : de manière interactive dans la console IAM ou par programmation avec les outils pour Windows PowerShell ou l' AWS CLI API. + Les utilisateurs IAM de votre compte qui utilisent la console IAM peuvent *basculer* vers un rôle leur permettant d'utiliser temporairement les autorisation du rôle dans la console. Les utilisateurs abandonnent leurs autorisations d'origine et acceptent les autorisations attribuées au rôle. Lorsque les utilisateurs quittent le rôle, leurs autorisations d'origine sont restaurées. + Une application ou un service proposé par AWS (comme Amazon EC2) peut *assumer* un rôle en demandant des informations d'identification de sécurité temporaires pour un rôle auquel envoyer des demandes programmatiques. AWS Vous utilisez ce rôle ainsi pour éviter de partager ou de conserver des informations d'identification de sécurité à long terme (par exemple, en créant un utilisateur IAM) pour chaque entité qui doit accéder à une ressource. **Note** Ce manuel utilise les phrases *passer à un rôle* et *endosser un rôle* de manière interchangeable. La forme d'utilisation des rôles la plus simple consiste à accorder à vos utilisateurs IAM l'autorisation de basculer vers des rôles que vous créez au sein de votre propre entreprise ou d'une autre Compte AWS. Ils peuvent changer de rôles facilement à l'aide de la console IAM pour utiliser des autorisations dont vous ne souhaitez pas qu'ils disposent d'ordinaire et il leur suffit de quitter le rôle pour renoncer à ces autorisations. Cela permet d'empêcher un accès *accidentel* à des ressources sensibles ou leur modification involontaire. Pour utiliser les rôles de manière plus complexe, comme accorder l'accès à des applications et des services, ou à des utilisateurs externes fédérés, vous pouvez appeler l'API `AssumeRole`. Cet appel d'API renvoie un ensemble d'informations d'identification temporaires que l'application peut utiliser dans les appels d'API suivants. Les tentatives d'actions avec les informations d'identification temporaires ne disposent que des autorisations accordées par le rôle associé. Une application n'a pas besoin de « quitter » le rôle de la même manière qu'un utilisateur dans la console. L'application arrête simplement d'utiliser les informations d'identification temporaires et reprend ses appels avec les informations d'identification d'origine. Les utilisateurs fédérés se connectent à l'aide des informations d'identification d'un fournisseur d'identité (IdP). AWS fournit ensuite des informations d'identification temporaires à l'IdP de confiance à transmettre à l'utilisateur pour les inclure dans les demandes de AWS ressources ultérieures. Ces informations d'identification fournissent des autorisations accordées au rôle attribué. Cette section présente les scénarios suivants : + [Donnez accès à un utilisateur IAM dans un compte Compte AWS que vous possédez pour accéder aux ressources d'un autre compte que vous possédez](id_roles_common-scenarios_aws-accounts.md) + [Fournir un accès aux charges de travail qui n'appartiennent pas à AWS](id_roles_common-scenarios_non-aws.md) + [Octroyer un accès aux utilisateurs IAM dans des Comptes AWS appartenant à des tierces parties](id_roles_common-scenarios_third-party.md) + [Fournir un accès aux services offerts par AWS deux AWS ressources](id_roles_common-scenarios_services.md) + [Octroi de l'accès à des utilisateurs authentifiés en externe (fédération d'identité)](id_roles_common-scenarios_federated-users.md) # Accès pour un utilisateur IAM à un autre utilisateur Compte AWS dont vous êtes le propriétaire Accès à travers Comptes AWS 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](id_roles_common-scenarios_third-party.md) ultérieurement dans cette rubrique. Imaginons que vous disposez d'instances Amazon EC2 qui sont critiques 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](id_credentials_mfa_configure-api-require.md). 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](cloudtrail-integration.md) 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 ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). 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\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-usingroletodelegate.png) 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](id_credentials_mfa_configure-api-require.md). 1. 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'`AssumeRole`API 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. 1. 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`. 1. 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](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) à 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](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) à l'application. 1. 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 : + [Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md) # Accès pour les applications autres que les charges AWS de travail Accès pour les applications autres que les charges AWS de travail [Un [rôle IAM](id_roles.md) est un objet dans Gestion des identités et des accès AWS (IAM) auquel des autorisations sont attribuées.](access_policies.md) Lorsque vous [assumez ce rôle](id_roles_manage-assume.md) en utilisant une identité IAM ou une identité extérieure AWS, cela vous fournit des informations d'identification de sécurité temporaires pour votre session de rôle. Il se peut que des charges de travail s'exécutent dans votre centre de données ou dans d'autres infrastructures extérieures AWS qui doivent accéder à vos AWS ressources. Au lieu de créer, de distribuer et de gérer des clés d'accès à long terme, vous pouvez utiliser Gestion des identités et des accès AWS Roles Anywhere (IAM Roles Anywhere) pour authentifier vos applications non AWS liées à des charges de travail. IAM Roles Anywhere utilise les certificats X.509 de votre autorité de certification (CA) pour authentifier les identités et fournir un accès sécurisé à l' Services AWS aide des informations d'identification temporaires fournies par un rôle IAM. **Pour utiliser Rôles Anywhere IAM** 1. Configurez une autorité de certification à l’aide de [AWS Autorité de certification privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) ou utilisez une autorité de certification issue de votre propre infrastructure PKI. 1. Après avoir configuré une autorité de certification, vous créez un objet dans Rôles Anywhere IAM appelé *ancre d’approbation*. Ce point d’ancrage établit une approbation entre Rôles Anywhere IAM et votre autorité de certification pour l’authentification. 1. Vous pouvez ensuite configurer vos rôles IAM existants ou créer de nouveaux rôles qui font confiance au service IAM Roles Anywhere. 1. Authentifiez vos tâches non liées aux AWS charges de travail avec IAM Roles Anywhere à l'aide de l'ancre de confiance. AWS accorde les informations d'identification temporaires non liées à la AWS charge de travail au rôle IAM qui a accès à vos AWS ressources. ## Ressources supplémentaires Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d’un accès aux charges de travail non AWS . + Pour plus d'informations sur IAM Roles Anywhere, consultez [Présentation de Gestion des identités et des accès AWS Rôle Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) dans le *Guide de l'utilisateur d'IAM Roles Anywhere*. + Pour savoir comment configurer une infrastructure à clé publique (PKI) pour Rôles Anywhere IAM, consultez la section [Rôles Anywhere IAM avec une autorité de certification externe](https://aws.amazon.com/blogs/) sur le *Blog de sécuritéAWS *. # Accès à des Comptes AWS sites appartenant à des tiers Accès à un tiers Comptes AWS 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 . Avec les rôles IAM, vous pouvez accorder à ces tiers l'accès à vos AWS ressources sans partager vos informations d'identification 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 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 ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). 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 ID externe à attacher uniquement à ce 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 ressources  AWS **. 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 l'Amazon Resource Name (ARN) du rôle au tiers. Il a besoin de l'ARN de votre rôle pour endosser le rôle. **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. ## IDs Externe pour accès par des tiers Un identifiant externe permet à l’utilisateur qui assume le rôle d’affirmer les circonstances dans lesquelles 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](confused-deputy.md). **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 toute personne autorisée à 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'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. ## Exemple de scénario utilisant un ID 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 à 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 AWS et le compte Exemple Corp. Une fois cette relation établie, un membre du compte Example Corp peut appeler l' AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API 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, consultez[Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md). 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. 1. 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 le`Principal`. Cela permet aux identités de ce compte d'endosser le rôle. En outre, vous ajoutez un élément `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#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"}} ``` 1. 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. 1. Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle à Example Corp. 1. Lorsque Example Corp a besoin d'accéder à vos AWS ressources, un membre de l'entreprise appelle l' AWS `sts:AssumeRole`API. 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. ## Points clés pour les acteurs externes 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 l' AWS API AWS CLI or pour assumer ce rôle. Pour plus d'informations, consultez l'opération de l'[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API STS ou l'opération de la [CLI STS assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html). + La valeur `ExternalId` peut avoir un minimum de 2 caractères et un maximum de 1 224 caractères. La valeur doit être alphanumérique sans espaces. Elle peut également inclure les symboles suivants : signe plus (\$1), signe égal (=), virgule (,), point (.), arobase (@), deux points (:), barre oblique (/) et tiret (-). ## Ressources supplémentaires Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d’un accès aux Comptes AWS appartenant à des tiers. + Pour savoir comment autoriser d'autres personnes à effectuer des actions dans le vôtre Compte AWS, consultez[Création d’un rôle à l’aide de politiques d’approbation personnalisées](id_roles_create_for-custom.md). + Pour savoir comment accorder l’autorisation de basculer vers un rôle, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md) + Pour savoir comment créer et fournir à des utilisateurs de confiance des informations d’identification de sécurité temporaires, [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md). # Accès à un AWS service Accès aux AWS services De nombreux AWS services nécessitent que vous utilisiez des rôles pour contrôler les accès auxquels ils peuvent accéder. Un rôle qu'un service endosse pour effectuer des actions en votre nom s'appelle un [rôle de service](id_roles.md#iam-term-service-role). Lorsqu’un rôle de service remplit un objectif spécial pour un service, il peut être défini comme [rôle lié à un service](id_roles.md#iam-term-service-linked-role). Consultez la [documentation AWS](https://docs.aws.amazon.com/) spécifique à chaque service pour vérifier s'il utilise des rôles et apprendre à attribuer un rôle au service afin qu'il l'utilise. Pour plus de détails sur la création d'un rôle permettant de déléguer l'accès à un service proposé par AWS, consultez[Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md). # Accès aux utilisateurs authentifiés en externe (fédération d’identité) Accès par le biais de la fédération d’identité Vos utilisateurs ont peut-être déjà une identité extérieure AWS, par exemple dans votre annuaire d'entreprise. Si ces utilisateurs doivent utiliser des AWS ressources (ou utiliser des applications qui accèdent à ces ressources), ils ont également besoin d'informations d'identification AWS de sécurité. A l'aide d'un rôle IAM, vous pouvez définir des autorisations pour des utilisateurs dont l'identité est fédérée par votre organisation ou un fournisseur d'identité (IdP) tiers. **Note** En tant que bonne pratique de sécurité, nous vous recommandons de gérer l'accès des utilisateurs dans [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) à l'aide de la fédération d'identité plutôt que de créer des utilisateurs IAM. Pour en savoir plus sur les situations spécifiques dans lesquelles un utilisateur IAM est nécessaire, veuillez consulter [Quand créer un utilisateur IAM (au lieu d'un rôle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose). ## Fédération d'utilisateurs d'une application mobile ou web à l'aide d'Amazon Cognito Si vous créez une application mobile ou Web qui accède aux AWS ressources, l'application a besoin d'informations d'identification de sécurité pour pouvoir envoyer des demandes programmatiques à. AWS Pour la plupart des scénarios impliquant des applications mobiles, nous recommandons d'utiliser [Amazon Cognito](https://aws.amazon.com/cognito/). Vous pouvez utiliser ce service avec le [SDK AWS mobile pour iOS et AWS le SDK mobile pour](https://aws.amazon.com/sdkforios/) [Android et Fire OS afin de créer des identités uniques pour les utilisateurs et](https://aws.amazon.com/sdkforandroid/) de les authentifier afin de sécuriser l'accès à vos ressources. AWS Amazon Cognito prend en charge les mêmes fournisseurs d'identité que ceux répertoriés dans la section suivante, ainsi que les [identités authentifiées par le développeur](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) et les accès non authentifiés (invité). Amazon Cognito fournit également des opérations d'API pour la synchronisation des données utilisateur afin de les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour plus d’informations, veuillez consulter [Amazon Cognito pour les applications mobiles](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito). ## Fédération d'utilisateurs à l'aide de fournisseurs d'identité publics ou d'OpenID Connect Dans la mesure du possible, utilisez Amazon Cognito pour les scénarios d'applications mobiles et Web. Amazon Cognito effectue la majeure partie du behind-the-scenes travail avec les services des fournisseurs d'identité publics pour vous. Il fonctionne avec les mêmes services tiers et prend également en charge les connexions anonymes. Toutefois, dans le cas de scénarios plus complexes, vous pouvez avoir directement recours à un service tiers tel que Login with Amazon, Facebook, Google, ou tout autre IdP compatible avec OpenID Connect (OIDC). Pour plus d’informations sur l’utilisation de la fédération OIDC avec l’un de ces services, consultez [Fédération OIDC](id_roles_providers_oidc.md). ## Fédération d'utilisateurs avec SAML 2.0 Si votre organisation utilise déjà un progiciel de fournisseur d'identité compatible avec le SAML 2.0 (Security Assertion Markup Language 2.0), vous pouvez créer un climat de confiance entre votre organisation en tant que fournisseur d'identité (IdP) et en AWS tant que fournisseur de services. Vous pouvez ensuite utiliser SAML pour fournir à vos utilisateurs une authentification unique (SSO) fédérée AWS Management Console ou un accès fédéré aux opérations d'API d'appel. AWS Par exemple, si votre entreprise utilise Microsoft Active Directory et Active Directory Federation Services, vous pouvez utiliser la fédération à l'aide de SAML 2.0. Pour plus d'informations sur l'utilisation des utilisateurs fédérés avec SAML 2.0, consultez [Fédération SAML 2.0](id_roles_providers_saml.md). ## Fédération d'utilisateurs via la création d'une application de broker d'identité personnalisé Si votre base d'identités n'est pas compatible avec SAML 2.0, vous pouvez créer une application de broker d'identité personnalisé capable d'exécuter une fonction similaire. L'application broker authentifie les utilisateurs, leur demande des informations d'identification temporaires AWS, puis les fournit à l'utilisateur pour qu'il accède aux AWS ressources. Par exemple, de nombreux employés d'Example Corp. doivent exécuter des applications internes qui accèdent aux AWS ressources de l'entreprise. Ils disposent déjà d'identités dans le système d'identité et d'authentification de l'entreprise et, par conséquent, Example Corp. ne souhaite pas créer un utilisateur IAM séparé pour chacun de ses employés. Bob est développeur chez Example Corp. Pour permettre aux applications internes d'Example Corp. d'accéder aux AWS ressources de l'entreprise, Bob développe une application personnalisée de courtier d'identité. L'application vérifie que les employés sont connectés au système d'identité et d'authentification existant d'Example Corp., par exemple LDAP, Active Directory ou un autre système. L'application de broker d'identité obtient ensuite des informations d'identification de sécurité temporaires pour les employés. Ce scénario est similaire au précédent (une application mobile utilisant un système d'authentification personnalisé), sauf que les applications qui ont besoin d'accéder aux AWS ressources s'exécutent toutes sur le réseau de l'entreprise et que l'entreprise dispose d'un système d'authentification existant. Pour obtenir les informations d'identification de sécurité temporaires, l'application de broker d'identité appelle `AssumeRole` ou `GetFederationToken`, selon la façon dont Bob veut gérer les politiques des utilisateurs et le délai d'expiration des informations d'identification. Pour plus d'informations sur les différences entre ces opérations d'API, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md) et [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md).) L'appel renvoie des informations de sécurité temporaires composées d'un identifiant de clé d' AWS accès, d'une clé d'accès secrète et d'un jeton de session. L'application de broker d'identité rend ensuite ces informations d'identification de sécurité temporaires accessibles à l'application interne de l'entreprise. L'application peut alors utiliser ces informations d'identification de sécurité temporaires pour appeler directement AWS . L'application met en cache les informations d'identification jusqu'à ce qu'elles parviennent à expiration, puis demande un nouvel ensemble d'informations d'identification temporaires. L'illustration suivante décrit ce scénario. ![\[Exemple de flux avec une application de broker d'identité personnalisé\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png) Ce scénario utilise les attributs suivants : + L'application de broker d'identité dispose d'autorisations d'accès à l'API du service de jeton (STS) d'IAM pour créer des informations d'identification de sécurité temporaires. + L'application de broker d'identité peut vérifier que les employés sont authentifiés dans le système d'authentification existant. + Les utilisateurs peuvent obtenir une URL temporaire qui leur donne accès à la console de AWS gestion (appelée authentification unique). Pour plus d'informations sur la création d'informations d'identification de sécurité temporaires, consultez [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md). Pour plus d'informations sur l'accès des principaux fédérés SAML à la console de AWS gestion, consultez. [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md)