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. # Surveiller et contrôler les actions prises avec les rôles endossés Un [rôle IAM](id_roles.md) est un objet dans IAM auquel sont affectées des [autorisations](access_policies.md). Lorsque vous [ assumez ce rôle à ](id_roles_manage-assume.md) l'aide d'une identité IAM ou d'une identité externe AWS, vous recevez une session avec les autorisations attribuées au rôle. Lorsque vous effectuez des actions AWS, les informations relatives à votre session peuvent être enregistrées AWS CloudTrail pour que l'administrateur de votre compte puisse les surveiller. Les administrateurs peuvent configurer les rôles de sorte à exiger des identités qu'elles transmettent une chaîne personnalisée identifiant la personne ou l'application qui effectue des actions dans AWS. Ces informations d'identité sont stockées en tant qu'*identité source* dans AWS CloudTrail. Lorsque l'administrateur passe en revue l'activité dans CloudTrail, il peut consulter les informations d'identité de la source pour déterminer qui ou quoi a effectué des actions dans le cadre de sessions de rôles supposés. Une fois qu'une identité de source est définie, elle est présente dans les demandes pour toute AWS action entreprise au cours de la session de rôle. La valeur définie persiste lorsqu'un rôle est utilisé pour assumer un autre rôle via l' AWS API AWS CLI or, ce que l'on appelle le chaînage [ de ](id_roles.md#iam-term-role-chaining) rôles. La valeur définie ne peut pas être modifiée durant la session de rôle. Les administrateurs peuvent configurer des autorisations granulaires en fonction de la présence ou de la valeur de l'identité source afin de mieux contrôler les AWS actions entreprises avec les rôles partagés. Vous pouvez décider si l'attribut d'identité source peut être utilisé, s'il est requis ; et quelle valeur peut être utilisée. L'utilisation de l'identité source est radicalement différente de celle du nom de session de rôle et des balises de session. La valeur d'identité source ne peut pas être modifiée une fois qu'elle est définie, et elle persiste pour toutes les actions supplémentaires qui sont prises durant la session de rôle. Voici comment utiliser les balises de session et le nom de session de rôle : + **Session tags** (Balises de session) : vous pouvez transmettre des balises de session lorsque vous endossez un rôle ou fédérez un utilisateur. Les balises de session sont présentes lorsqu'un rôle est endossé. Vous pouvez définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Vous pouvez ensuite consulter CloudTrail les demandes faites pour assumer des rôles ou fédérer des utilisateurs. Pour en savoir plus sur les balises de session, veuillez consulter [Transmettre les balises de session AWS STS](id_session-tags.md). + **Role session name** (Nom de la session de rôle) : vous pouvez utiliser la clé de condition `sts:RoleSessionName` dans une politique d'approbation de rôle pour exiger que vos utilisateurs fournissent un nom de session spécifique lorsqu'ils endossent un rôle. Le nom de session de rôle peut servir à différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux. Pour en savoir plus sur le nom de la session de rôle, voir [ sts : RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname). Nous vous recommandons d'utiliser l'identité source pour contrôler l'identité qui endosse un rôle. L'identité de la source est également utile pour l'exploration CloudTrail des journaux afin de déterminer qui a utilisé le rôle pour effectuer des actions. **Topics** + [Configuration d'utilisation de l'identité source](#id_credentials_temp_control-access_monitor-setup) + [Ce qu'il faut savoir sur l'identité source](#id_credentials_temp_control-access_monitor-know) + [Autorisations requises pour définir l'identité source](#id_credentials_temp_control-access_monitor-perms) + [Spécification d'une identité source lorsqu'un rôle est endossé](#id_credentials_temp_control-access_monitor-specify-sourceid) + [Utilisation de l'identité de la source avec AssumeRole](#id_credentials_temp_control-access_monitor-assume-role) + [Utilisation de l'identité de la source avec AssumeRoleWithSAML](#id_credentials_temp_control-access_monitor-assume-role-saml) + [Utilisation de l'identité de la source avec AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id) + [Contrôle de l'accès au moyen des informations d'identité source](#id_credentials_temp_control-access_monitor-control-access) + [Affichage de l'identité de la source dans CloudTrail](#id_credentials_temp_control-access_monitor-ct) ## Configuration d'utilisation de l'identité source Votre configuration d'utilisation de l'identité source dépend de la méthode employée lorsque vos rôles sont endossés. Par exemple, vos utilisateurs IAM peuvent endosser des rôles directement via l'opération `AssumeRole`. Si vous possédez des identités d'entreprise, également appelées identités de personnel, elles peuvent accéder à vos AWS ressources en utilisant`AssumeRoleWithSAML`. Si des utilisateurs finaux accèdent à vos applications mobiles ou Web, ils peuvent le faire en utilisant `AssumeRoleWithWebIdentity`. La présentation du flux de haut niveau qui suit vous aidera à comprendre comment effectuer une configuration pour utiliser les informations d'identité source dans votre environnement existant. 1. **Configurer les utilisateurs et les rôles test** : en utilisant un environnement de préproduction, configurez les utilisateurs et les rôles test, et configurez leurs politiques afin d'autoriser la définition d'une identité source. Si vous utilisez un fournisseur d'identité (IdP) pour vos identités fédérées, configurez-le de sorte à transmettre un attribut utilisateur de votre choix pour l'identité source dans l'assertion ou le jeton. 1. **Assumer le rôle** : testez le fait d'endosser des rôles et de transmettre une identité source avec les utilisateurs et les rôles que vous configurez pour le test. 1. **Révision CloudTrail ** : vérifiez les informations d'identité de la source pour vos rôles de test dans vos CloudTrail journaux. 1. **Entraîner vos utilisateurs** : après avoir effectué des tests dans votre environnement de préproduction, vérifiez que vos utilisateurs savent parfaitement comment transmettre les informations d'identité source, si nécessaire. Définissez une date limite à laquelle vous exigerez de vos utilisateurs qu'ils fournissent une identité source dans votre environnement de production. 1. **Configurer des politiques de production** : configurez des politiques pour votre environnement de production, puis ajoutez-les à vos utilisateurs et rôles de production. 1. **Surveillez l'activité ** : surveillez l'activité de votre rôle de production à l'aide de CloudTrail journaux. ## Ce qu'il faut savoir sur l'identité source Gardez ce qui suit à l'esprit lorsque vous travaillez avec l'identité source. + Les politiques d'approbation pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:SetSourceIdentity`. Pour les rôles qui ne disposent pas de cette autorisation dans la politique d'approbation de rôle, l'opération `AssumeRole*` échouera. Si vous ne souhaitez pas mettre à jour la politique d'approbation de rôle pour chaque rôle, vous pouvez utiliser une instance de fournisseur d'identité distincte pour transmettre l'identité source. Ajoutez ensuite l'autorisation `sts:SetSourceIdentity` uniquement aux rôles qui sont connectés au fournisseur d'identité distinct. + Lorsqu'une identité définit une identité source, la clé `sts:SourceIdentity` est présente dans la demande. Pour les actions qui seront prises ultérieurement durant la session de rôle, la clé `aws:SourceIdentity` est présente dans la demande. AWS ne contrôle la valeur de l'identité source dans aucune des clés `sts:SourceIdentity` ou `aws:SourceIdentity`. Si vous choisissez d'exiger une identité source, vous devez choisir un attribut que vos utilisateurs ou votre IdP doivent fournir. Pour des raisons de sécurité, vous devez vérifier votre capacité à contrôler la façon dont ces valeurs sont fournies. + La valeur de l'identité de la source doit comporter entre 2 et 256 caractères et ne peut contenir que des caractères alphanumériques, des traits de soulignement et les caractères suivants :**., \+ = @ - ** (tiret). Vous ne pouvez pas utiliser une valeur qui commence par le texte **aws:**. Ce préfixe est réservé à un usage AWS interne. + Les informations d'identité de la source ne sont pas capturées CloudTrail lorsqu'un AWS service ou un rôle lié à un service effectue une action pour le compte d'une identité fédérée ou d'un personnel. **Important** Vous ne pouvez pas passer à un rôle dans le Console de gestion AWS qui nécessite la définition d'une identité de source lorsque le rôle est assumé. Pour assumer ce rôle, vous pouvez utiliser l' AWS API AWS CLI or pour appeler l'`AssumeRole`opération et spécifier le paramètre d'identité de la source. ## Autorisations requises pour définir l'identité source En plus de l'action qui correspond à l'opération d'API, vous devez disposer de l'action d'autorisation suivante dans votre politique : ``` sts:SetSourceIdentity ``` + Pour spécifier une identité source, les principaux (utilisateurs et rôles IAM) doivent disposer des autorisations nécessaires pour `sts:SetSourceIdentity`. Votre qualité d'administrateur vous permet de configurer cela dans la politique de confiance de rôle et la politique d'autorisations du principal. + Lorsque vous endossez un rôle avec un autre rôle ([chaînage de rôles](id_roles.md#iam-term-role-chaining)), des autorisations sont exigées pour `sts:SetSourceIdentity` tant dans la politique d'autorisations du principal qui endosse le rôle que dans la politique de confiance de rôle du rôle cible. Sinon, l'opération consistant à endosser le rôle échouera. + Lorsque vous utilisez l'identité source, les politiques d'approbation de rôle pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:SetSourceIdentity`. L'opération `AssumeRole*` échouera pour tout rôle connecté à un fournisseur d'identité sans cette autorisation. Si vous ne voulez pas mettre à jour la politique de confiance de rôle pour chaque rôle, vous pouvez utiliser une instance IdP distincte pour transmettre l'identité source et ajouter l'autorisation `sts:SetSourceIdentity` aux seuls rôles qui sont connectés à l'instance IdP distincte. + Pour définir une identité source au-delà des limites de compte, vous devez inclure l'autorisation `sts:SetSourceIdentity` à deux endroits. Elle doit être présente dans la politique d'autorisations du principal dans le compte d'origine et dans la politique de confiance de rôle du rôle dans le compte cible. Vous devrez peut-être faire cela lorsqu'un rôle est utilisé pour endosser un rôle dans un autre compte ([chaînage de rôles](id_roles.md#iam-term-role-chaining)). Supposons, par exemple, qu'en tant qu'administrateur de compte, vous vouliez autoriser l'utilisateur IAM `DevUser` dans votre compte à endosser le `Developer_Role`dans le même compte. Mais vous voulez autoriser cette action uniquement si l'utilisateur a défini l'identité source à son nom d'utilisateur IAM. Vous pouvez attacher la politique suivante à l'utilisateur IAM. **Example Exemple de politique basée sur l'identité associée à DevUser** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::{{123456789012}}:role/{{Developer_Role}}" }, { "Sid": "SetAwsUserNameAsSourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::{{123456789012}}:role/{{Developer_Role}}", "Condition": { "StringLike": { "sts:SourceIdentity": "${aws:username}" } } } ] } ``` Pour appliquer les valeurs d'identité source acceptables, vous pouvez configurer la politique de confiance de rôle suivante. La politique donne à l'utilisateur IAM les autorisations `DevUser` pour endosser le rôle et définir une identité source. La clé de condition `sts:SourceIdentity` définit la valeur d'identité source acceptable. **Example Exemple de politique de confiance de rôle pour une identité source** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDevUserAssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{{123456789012}}:user/{{DevUser}}" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "sts:SourceIdentity": "{{DevUser}}" } } } ] } ``` ------ À l'aide des informations d'identification de l'utilisateur IAM`DevUser`, celui-ci tente de supposer qu'il `DeveloperRole` utilise la AWS CLI requête suivante. **Example Exemple de requête AssumeRole CLI** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \ ``` Lors de l' AWS évaluation de la demande, le contexte de la demande contient le signe `sts:SourceIdentity` de`DevUser`. ## Spécification d'une identité source lorsqu'un rôle est endossé Vous pouvez spécifier une identité de source lorsque vous utilisez l'une des opérations d' AWS STS `AssumeRole*`API pour obtenir des informations d'identification de sécurité temporaires pour un rôle. L'opération d'API que vous utilisez varie selon votre cas d'utilisation. Par exemple, si vous utilisez des rôles IAM pour permettre aux utilisateurs IAM d'accéder à AWS des ressources auxquelles ils n'ont pas normalement accès, vous pouvez utiliser cette opération. `AssumeRole` Si vous utilisez la fédération d'identités d'entreprise pour gérer vos utilisateurs de main-d'œuvre, vous pouvez utiliser l'opération `AssumeRoleWithSAML`. Si vous utilisez la fédération OIDC pour autoriser des utilisateurs finaux à accéder à vos applications mobiles ou Web, vous pouvez utiliser l’opération `AssumeRoleWithWebIdentity`. Les sections suivantes détaillent l'utilisation de l'identité source avec chaque opération. Pour en savoir plus sur les scénarios courants d'informations d'identification temporaires, veuillez consulter [Scénarios courants d'informations d'identification temporaires](id_credentials_temp.md#sts-introduction). ## Utilisation de l'identité de la source avec AssumeRole L'`AssumeRole`opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Vous pouvez utiliser l'utilisateur ou les informations d'identification du rôle IAM pour appeler `AssumeRole`. Pour transmettre l'identité de la source tout en assumant un rôle, utilisez l'`-–source-identity` AWS CLI option ou le paramètre `SourceIdentity` AWS d'API. L'exemple suivant vous explique comment spécifier l'identité source avec la AWS CLI. **Example Exemple de requête AssumeRole CLI** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \ ``` ## Utilisation de l'identité de la source avec AssumeRoleWithSAML Le principal qui appelle l'`AssumeRoleWithSAML`opération est authentifié à l'aide de SAML-based la fédération. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Pour plus d'informations sur l'utilisation SAML-based de la fédération pour Console de gestion AWS l'accès, consultez[Permettre aux principaux fédérés SAML 2.0 d'accéder au Console de gestion AWS](id_roles_providers_enable-console-saml.md). Pour plus de détails sur AWS CLI notre accès à l' AWS API, consultez[Fédération SAML 2.0](id_roles_providers_saml.md). Pour un didacticiel sur la configuration de la fédération SAML pour vos utilisateurs Active Directory, consultez la section Authentification [AWS fédérée avec Active Directory Federation Services (ADFS) ](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) dans le AWS blog de sécurité. En tant qu'administrateur, vous pouvez autoriser les membres de l'annuaire de votre entreprise à se fédérer pour AWS utiliser l' AWS STS `AssumeRoleWithSAML`opération. Pour ce faire, effectuez les tâches suivantes : 1. [Configurer un fournisseur SAML dans votre organisation](id_roles_providers_saml_3rd-party.md). 1. [Créer un fournisseur SAML dans IAM](id_roles_providers_create_saml.md) 1. [Configurez un rôle et ses autorisations AWS pour vos principaux fédérés SAML. ](id_roles_create_for-idp_saml.md) 1. [Achever la configuration de l'IdP SAML et créer des assertions pour la réponse d'authentification SAML](id_roles_providers_create_saml_assertions.md). Pour définir un attribut SAML pour l'identité source, incluez dans l'élément `Attribute` l'attribut `Name` défini à l'adresse `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Utilisez l'élément `AttributeValue` pour spécifier la valeur de l'identité source. Par exemple, supposons que vous souhaitez transmettre l'attribut d'identité suivant en tant qu'identité source : `SourceIdentity:DiegoRamirez` Pour transmettre cet attribut, incluez l'élément suivant dans votre assertion SAML. **Example Extrait d'une assertion SAML** ``` DiegoRamirez ``` ## Utilisation de l'identité de la source avec AssumeRoleWithWebIdentity Le principal qui appelle l’opération `AssumeRoleWithWebIdentity` est authentifié à l’aide de la fédération compatible OpenID Connect (OIDC). Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux ressources AWS . Pour de plus amples informations sur l’utilisation de la fédération OIDC pour l’accès à l’ Console de gestion AWS , consultez [Fédération OIDC](id_roles_providers_oidc.md). Pour transmettre l'identité source depuis OpenID Connect (OIDC), vous devez inclure l'identité source dans le jeton web JSON (JWT). Incluez l'identité source dans l'espace de noms `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` dans le jeton lorsque vous soumettez la demande `AssumeRoleWithWebIdentity`. Pour en savoir plus sur les jetons OIDC et les revendications, veuillez consulter [Utilisation des jetons avec les groupes d'utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) dans le *Guide du développeur Amazon Cognito *. Par exemple, le JWT décodé suivant est un jeton utilisé pour appeler `AssumeRoleWithWebIdentity` avec l'identité source `Admin`. **Example Exemple de jeton web JSON décodé** ``` { "sub": "john", "aud": "ac_oic_client", "jti": "ZYUCeRMQVtqHypVPWAN3VB", "iss": "https://xyz.com", "iat": 1566583294, "exp": 1566583354, "auth_time": 1566583292, "https://aws.amazon.com/source_identity":"Admin" } ``` ## Contrôle de l'accès au moyen des informations d'identité source Lorsqu'une identité de source est initialement définie, la SourceIdentity [ clé ](reference_policies_iam-condition-keys.md#ck_sourceidentity) sts : est présente dans la demande. Une fois l'identité de source définie, la SourceIdentity [ clé ](reference_policies_condition-keys.md#condition-keys-sourceidentity) aws : est présente dans toutes les demandes suivantes effectuées au cours de la session de rôle. En tant qu'administrateur, vous pouvez rédiger des politiques qui accordent une autorisation conditionnelle pour effectuer des AWS actions en fonction de l'existence ou de la valeur de l'attribut d'identité source. Imaginez que vous souhaitiez demander à vos développeurs de définir une identité de source pour qu'ils assument un rôle essentiel et soient autorisés à écrire sur une AWS ressource critique pour la production. Imaginez également que vous accordiez AWS l'accès aux identités de vos employés en utilisant`AssumeRoleWithSAML`. Comme vous voulez que seuls les développeurs senior Saanvi et Diego aient accès au rôle, vous créez a politique de confiance suivante pour le rôle. **Example Exemple de politique d'approbation de rôle pour une identité source (SAML)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SAMLProviderAssumeRoleWithSAML", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::{{111122223333}}:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://{{region-code}}.signin.aws.amazon.com/saml" } } }, { "Sid": "SetSourceIdentitySrEngs", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::{{111122223333}}:saml-provider/name-of-identity-provider" }, "Action": [ "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ La politique d'approbation contient une condition pour l’interface `sts:SourceIdentity` qui exige une identité source de Saanvi ou Diego pour endosser le rôle critique. Par ailleurs, si vous utilisez un fournisseur OIDC pour la fédération et que les utilisateurs sont authentifiés avec l’interface `AssumeRoleWithWebIdentity`, votre politique d’approbation de rôle peut se présenter comme suit. **Example Exemple de politique d'approbation de rôle pour l'identité source (fournisseur OIDC)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::{{111122223333}}:oidc-provider/{{server.example.com}}" }, "Action": [ "sts:AssumeRoleWithWebIdentity", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "{{server.example.com}}:aud": "{{oidc-audience-id}}" }, "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ ### Chaînage de rôles et exigences entre comptes Supposons que vous vouliez autoriser les utilisateurs ayant endossé un `CriticalRole` à endosser un `CriticalRole_2` dans un autre compte. Les informations d'identification de session de rôle qui ont été obtenues pour endosser le `CriticalRole` sont utilisées pour effectuer un [chaînage de rôles](id_roles.md#iam-term-role-chaining) à un second rôle, `CriticalRole_2`, dans un autre compte. Le rôle est endossé au-delà d'une limite de compte. Par conséquent, l'autorisation `sts:SetSourceIdentity` doit être octroyée tant dans la politique d'autorisations sur le `CriticalRole` que dans la politique de confiance de rôle sur le `CriticalRole_2`. **Example Exemple de politique d'autorisations sur CriticalRole** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::{{222222222222}}:role/CriticalRole_2" } ] } ``` ------ Afin de sécuriser la définition de l'identité source au-delà de la limite du compte, la politique de confiance de rôle suivante fait uniquement confiance au principal de rôle pour `CriticalRole` pour définir l'identité source. **Example Exemple de politique de confiance des rôles sur CriticalRole \_2** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{{111111111111}}:role/CriticalRole" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "aws:SourceIdentity": ["Saanvi","Diego"] } } } ] } ``` ------ L'utilisateur effectue l'appel suivant à l'aide des informations d'identification de session de rôle obtenues en supposant CriticalRole. L'identité de la source a été définie lors de l'hypothèse de CriticalRole, il n'est donc pas nécessaire de la définir à nouveau explicitement. Si l'utilisateur tente de définir une identité source différente de la valeur définie lors de la supposition de `CriticalRole`, la demande d'endosser le rôle sera refusée. **Example Exemple de requête AssumeRole CLI** ``` aws sts assume-role \ --role-arn arn:aws:iam::{{222222222222}}:role/CriticalRole_2 \ --role-session-name Audit \ ``` Lorsque le principal appelant endosse le rôle, l'identité source dans la demande persiste à partir de la première session de rôle endossée. Par conséquent, les clés `aws:SourceIdentity` et `sts:SourceIdentity` sont toutes deux présentes dans le contexte de demande. ## Affichage de l'identité de la source dans CloudTrail Vous pouvez l'utiliser CloudTrail pour afficher les demandes faites pour assumer des rôles ou fédérer des utilisateurs. Vous pouvez également afficher les demandes de rôle ou d'utilisateur souhaitant effectuer des actions dans AWS. Le fichier CloudTrail journal contient des informations sur l'identité de source définie pour la session utilisateur fédérée ou avec rôle assumé. Pour de plus amples informations, consultez [Journalisation IAM et AWS STS Appels d'API avec AWS CloudTrail](cloudtrail-integration.md). Supposons, par exemple, qu'un utilisateur fasse une AWS STS `AssumeRole` demande et définisse une identité de source. Vous trouverez les `sourceIdentity` informations contenues dans la `requestParameters` clé de votre CloudTrail journal. **Example Exemple de section RequestParameters dans un AWS CloudTrail journal** ``` "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "111122223333" }, "eventTime": "2020-04-02T18:20:53Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.64", "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86", "requestParameters": { "roleArn": "arn:aws:iam::123456789012:role/DevRole", "roleSessionName": "Dev1", "sourceIdentity": "{{source-identity-value-set}}" } ``` Si l'utilisateur utilise la session de rôle supposée pour effectuer une action, les informations d'identité de la source sont présentes dans la `userIdentity` clé du CloudTrail journal. **Example Exemple de clé UserIdentity dans un AWS CloudTrail journal** ``` { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1", "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAJ45Q7YFFAREXAMPLE", "arn": "arn:aws:iam::123456789012:role/DevRole", "accountId": "123456789012", "userName": "DevRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-02-21T23:46:28Z" }, "sourceIdentity": "source-identity-value-present" } } } ``` Pour voir des exemples AWS STS d'événements d'API dans CloudTrail les journaux, consultez[Exemples d'événements d'API IAM dans le journal CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api). Pour plus de détails sur les informations contenues dans les fichiers CloudTrail journaux, consultez la section Référence des [ CloudTrail événements ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) dans le Guide de *AWS CloudTrail l'utilisateur*.